Dump LSASS when Debug Privilege is disabled
To dump LSASS, weather using Mimikatz, ProcDump or other ways, the user will need to have DebugPrivilege in order to create a memory dump.
Last updated
To dump LSASS, weather using Mimikatz, ProcDump or other ways, the user will need to have DebugPrivilege in order to create a memory dump.
Last updated
SeDebugPrivilege is managed by a Local GPO Policy on Group Policy Management Editor → Windows Settings → Security Settings → Local Policies → User Rights Assignment → Debug programs → Define these policy settings. There you can configure the users/groups that can debug programs. By default Local Administrators are configured.
This Privilege is needed when a program crashes and a memory dump needs to be created for the support to troubleshoot.
I found this (https://gytpol.com/how-a-simple-group-policy-setting-can-prevent-a-privilege-escalation-from-becoming-a-lateral-movement/) article that said if we minimize the privileges on LSASS, we can prevent credential dumping. Let's see.
A domain administrator can create a GPO that only allows Domain Admins to debug programs.
This way, even with a Local Administrator Account and High Integrity, creating dumps will fail.
Opening the LSASS Process Permissions, we can see that SYSTEM and Local Administrators only have Read and Execute Permissions, which are not enough to dump the memory:
But, TrustedInstaller has Full Control over the process:
The TrustedInstaller (https://softwarekeep.com/help-center/what-is-trustedinstaller-and-should-i-remove-it-from-windows-10) is a Windows Modules Installer component, responsible for helping you install, modify and remove updates and other Windows components. It’s essentially a built-in, hidden “user account” in Windows 10, as well as Windows 8 and Windows 7.
To interact with TrustedInstaller as a Local Administrator, we can either use its session token (using something like Incognito), or run a process on TrustedInstaller Service.
Running whoami as TrustedInstaller with the output added to a file will result in the creation of the file but no output. Meaning we executed a command with TrustedInstaller permissions:
To dump LSASS, we can use something like Procmon (but you can use anything you want):
As we can see, it did manage to dump the LSASS memory using procdump as TrustedInstaller. (Something to notice, procdump is flaged as malicious by Windows Defender, so prior to dumping the memory, either try to make it undetectable or use another method)
Finally, we dump the credentials with mimikatz:
Another thing an Administrator can do, is remove all the users from debugging the programs. Using this, they prevent admins from creating memory dumps, but also prevent hackers from dumping LSASS.
Or do they?
We remove every user/group from the GPO which allows Program Debugging and retry everything:
Again, TrustedInstaller has full access to the process:
We try again to do the same thing:
As we can see, we can dump LSASS and credentials dump again:
So, not assigning anyone did not make any change.
We remove all privileges from TrustedInstaller on LSASS.
We can still dump LSASS:
Needless to say, the credentials too:
In the end, we managed to dump LSASS even with minimized permissions on it. Of course, all of these examples need Local Admin Rights, but you get the idea.
As for detection, I would say EDR catches TrustedInstaller modifications, so monitoring them is a good start. Another thing you can do is monitor TrustedInstaller's binary and commands. Adversaries can change the name ofc, but again, that's a good start.
