Dumping LSASS Like it’s 2019

By Red Siege | March 4, 2024

By Alex Reid, Current Red Siege Intern

 

A long-time tactic of threat actors and offensive security professionals alike, tampering with LSASS.exe in order to recover credentials remains a highly relevant technique in 2024. The means by which this is done has evolved, with the industry moving away from running tools like Mimikatz on target systems and turning instead to creating memory dumps of LSASS which can then be exfiltrated and parsed on the attacker side in order to extract sensitive information. It’s hard to keep track of all the different methods of dumping LSASS available today, but Fortra’s nanodump does an excellent job of collecting and implementing a good number of them.

Of course, as offensive security TTPs evolve, defenders perform the vital work of identifying, mitigating, and implementing controls that render them ineffective. It isn’t all that surprising then that AV products like Microsoft Defender (Defender) and EDR services like Microsoft Defender for Endpoint (MDE) detect and alert on several of the techniques available within nanodump. For example, using nanodump --shtinkering from a Cobalt Strike Beacon results in both a local Defender and an MDE alert, as well as the outright blocking of the attempt:

Microsoft Defender Alert

Microsoft Defender Alert

 

MDE Alert

MDE Alert

 

Similarly, while nanodump --spoof-callstack --snapshot completes successfully and isn’t flagged by Defender, MDE recognizes and alerts on the behavior:

 

MDE Alert

 

The endless cat-and-mouse game between Red and Blue has continually driven the complexity of attacks and tools to new heights. As a security researcher, it can be tempting to focus solely on the new and unexplored, losing sight of older TTPs which are easily discarded as obsolete or nonviable. Some of these TTPs, while no longer able to be simply git-cloned, fired, and forgotten about, are just a quick modification or two away from re-entering the game as serious contenders.

To demonstrate this, we will revisit a 2019-era technique for dumping LSASS using the MiniDumpW export of comsvcs.dll. The primary reference to this technique is Modexp’s blogpost, MiniDumpWriteDump via COM+ Services DLL, which provides a remarkably short and simple code snippet demonstrating the technique:

 

In essence, comsvcs.dll is loaded using LoadLibrary, after which the MiniDumpW export is resolved using GetProcAddress. After ensuring that SeDebugPrivilege is enabled within the process, MiniDumpW is called using the process ID of LSASS.exe and a location on disk to write output to as arguments. This results in a memory dump of the LSASS process being captured and written to disk at the specified location.

This technique is maybe surprisingly still in use by real threat actors today, with Microsoft releasing threat intelligence concerning Volt Typhoon, an APT observed employing the method:

 

Porting this code to BOF format is trivial, with a passing version shown below:

 

This very simple POC doesn’t include the enabling of SeDebugPrivilege, but this is easily accomplished using the Cobalt Strike getprivs command.

An equally simple Aggressor script facilitates the use of the BOF:

 

After spawning an elevated beacon (an admin or System work equally well), the  getprivs command can be used to enable  SeDebugPrivilege in the process:

 

Running the BOF requires providing the LSASS PID and a path to write the dump file to:

 

Unsurprisingly, both Defender and MDE flag this:

Defender Alert

 

MDE Alert

 

Taking a closer look at the Defender alert offers a helpful hint:

 

Defender identifies the dump file itself as malicious. This again isn’t all that surprising; nanodump offers several features to try and mitigate alerts like this, including the ability to alter the signature of the dump file before it is written to disk, as well as methods to dump LSASS and download the dump file without touching disk at all. This information ultimately raises the question: if we can prevent the dump file being written to disk, does the use of  MiniDumpW to dump LSASS from an arbitrary process trigger alerts by itself?

To test this theory, we can make use of a public project of mine, MemFiles. This is a (in my opinion) very powerful Cobalt Strike toolkit that creates a rudimentary in-memory file system within a Cobalt Strike Beacon. The impact is that, by providing a specific non-existent path (c:\redteam\…), tooling ran within the Beacon process (like BOFs) can write files to memory instead of to disk.

After pulling the project from GitHub, compiling it, and importing the Aggressor script to Cobalt Strike, we can prepare for the test by again spawning an elevated x64 Beacon and using  getprivs:

 

MemFiles requires that the Beacon process be free of any userland hooks placed by EDRs. Neither Defender nor MDE utilize userland hooking, but it is something to consider if attempting this against a different security product. MemFiles can be initialized in the Beacon using  meminit :

 

The BOF can now be ran, using the same LSASS PID as before, but this time specifying that the dump file should be written to  c:\redteam\dump.bin . The  redteam directory does not exist on the target file system; this keyword triggers MemFiles to intercept the file operation and write the file content to memory:

 

Using the  memlist command shows the dump file in memory, which can then be downloaded using  memfetch :

 

Defender remains silent this time, with no alerts raised in MDE either:

 

Yep, that’s right. In 2024, an unsigned, random executable running a Cobalt Strike Beacon can dump LSASS using a 2019-era technique without MDE batting an eye, provided you don’t write the dump file to disk.

This is a quick and dirty example of how old tools, often discarded and considered no longer viable, can be revived with relatively little effort. With the infosec arms race ever accelerating, the temptation to only look forward for solutions and TTPs should be tempered with the occasional look backwards at existing ones that, with minor modifications, can sail past industry-leading security products.

 


 

About Alex Reid, Current Red Siege Intern:

Alex got started in offensive security 4 years ago on the United States Navy Red Team, and has been awarded several medals for his work there as an Advanced Capabilities Developer and Red Team Technical Lead. He has presented at several DoD Red Team conferences and is an active contributor to the offensive security community via open source tooling published on his personal GitHub.

Certifications:

OSCP, OSEP, and RTJC

Connect on Twitter and Linkedin

Adventures in Shellcode Obfuscation! Part 4: RC4 with a Twist

By Red Siege | July 8, 2024

by Mike Saunders, Principal Security Consultant This blog is the fourth in a series of blogs on obfuscation techniques for hiding shellcode. You can find the rest of the series […]

Learn More
Adventures in Shellcode Obfuscation! Part 4: RC4 with a Twist

Adventures in Shellcode Obfuscation! Part 3: Encryption

By Red Siege | July 1, 2024

By Mike Saunders, Principal Security Consultant   This blog is the third in a series of blogs on obfuscation techniques for hiding shellcode. You can find the rest of the […]

Learn More
Adventures in Shellcode Obfuscation! Part 3: Encryption

Phone Switch Labs CTF – Walk-Through

By Red Siege | June 26, 2024

by Douglas Berdeaux, Senior Security Consultant CTF redsiege.com/phoneswitch Getting Started Phone phreaking is the practice of exploring and hacking telephones, telephone switches, telephone test equipment, and physically exploring the telephone […]

Learn More
Phone Switch Labs CTF – Walk-Through

Find Out What’s Next

Stay in the loop with our upcoming events.