In this week’s Defend(er) Against, we are going to look at the project called DumpThatLSASS by D1rkMtr, where the objective is to leverage MiniDumpWriteDump. I have seen many people talking about this one, so I figured it was a good one to start with.
You can find the project that we’re discussing right here (currently the page is down, not sure if the owner pulled it):
https://github.com/D1rkMtr/DumpThatLSASS
In an Enterprise setting, this technique/POC has very little chance of success on properly configured devices. The roadblocks were significant, and, in the end, I could not overcome them without disabling the core components. If you are going to test a POC, do not do it on your grandma’s Windows 10 Home box unless that’s who you are trying to own. Towards the end, I was needing to recompile the app however the project was taken down. Here are some of the protections you can count on here for this:
- ASR Rules
- Block executable files from running unless they meet a prevalence, age, or trusted list criterion.
- Block credential stealing from the Windows local security authority subsystem
- Cloud Delivered Protection, or MAPS
- Credential guard (I did not have it enabled, however I never made it that far)
Before we get started, let’s talk a little about components used in this; LSASS, MiniDumpWriteDump and the DbgHelp.dll. Learning more about these components will help you understand their importance, as well as help you identify other tools that potentially use the same techniques.
- LSASS
- LSASS (Local Security Authority Subsystem Service) is a service in the Windows operating system responsible for enforcing security policies, managing user authentication, and protecting the computer from unauthorized access. To perform its functions, LSASS stores user credentials in memory, including hashed passwords, so that it can quickly and efficiently authenticate users when they try to log in. You can guess why it’s so targeted now.
- DbgHelp.dll
- Provides a set of functions that can be used to debug and troubleshoot software issues by creating and analyzing memory dump files.
- MiniDumpWriteDump
- In short, MiniDumpWriteDump is a function provided by the Windows operating system that allows for the creation of a small memory dump file.
Alright, with that out of the way let’s get into this. I’ll cover some of the prep first in case others were curious. I’m using Visual Studio to compile the project into the desired MiniDump.exe as shown below in Figure 1.1 and 1.2.
Choose “Clone a project” and paste the URL from above.
Then, right-click on “Solution ‘MiniDump’ (1 of 1 project)” and choose “Build solution.”
If you’re interested in ensuring the code you’re compiling is safe, Microsoft Secure Code Analysis is an option (now called Microsoft Security DevOps?), I’ll write a blog about that because I think that’s the right thing to do. – Microsoft Security Code Analysis documentation overview | Microsoft Learn
If we think back to how our lab device is configured from The Blue Stack Cybersecurity Blog | Properly Configure MDE for Windows, we know we have a few things in place that should give us some protection against this. I’m expecting the ASR Rule “Block credential stealing from the Windows local security authority subsystem” to block this tool, but let’s see, maybe it won’t! Remember, we’re trying to learn both sides of this, what can protect us from these types of bypasses as well as what can we gleam from it if we cannot. I would also expect Credential Guard to block the dump too.
First round of testing, the MiniDump.exe binary was getting blocked by the ASR rule “Block executable Files from running unless they meet a prevalence, age, or trusted list criterion.” I’m going to switch that rule into Audit mode for this test and see what we get.
I went ahead and flipped that ASR rule to Audit mode within that Group Policy, Figure 1.4 shows that took.
Okay, for the second test, the LSASS ASR rule got in the way as expected…as we can see below in Figure 1.5 the dump was created however it was empty, a telltale sign the LSASS dump attempt was blocked.
Since my testing was broken up into a few days because…incident response life…I broke my lab box and didn’t save the MP logs off like a good human being after this point, so no juice on that block…sorry. Now, I had kicked it off one more time but realized I must go recompile because Cloud Delivered Protection (CDP), or MAPS, already sent me a signature for it as you can see below.
Checking the alert in the M365D portal (security.microsoft.com), we can see “Client,Cloud” as the detection source, nifty ey? This in my opinion is one of Defender’s best features, the ability to create signatures on the fly. And now everyone gets it too. #SharingIsCaring
And here it is the correlating detection from the MPDetection.log (UTC time):
I was going to go compile it again, however it was at this point I noticed the git project was taken down, so for now we will leave this here. Despite not at all getting what I wanted out of this blog, which would have been deeper dives into the logs to show how the system evaluated the situation (my fault), I felt this was still worth sharing as it covers at face value the various ways we can stop this particular attack.
Whether we catch things based on low prevalence which can slow new, never seen binaries, to various protections over the LSASS service and on the fly, cloud delivered protections. Sometimes it’s not about the initial block, it’s about making enough noise and providing containment elsewhere.
Thanks