In this week’s Defend(er) Against, we are going to look at the project called OmriToolZ, another LSASS dumping tool. This project can be found here – https://github.com/OmriBaso/RToolZ. Let’s go see what within the MDE stack steps up to it.
Summary up front:
- 2 Attack Surface Reduction rules battle for the block
- Cloud Delivered Protection plays a role
- Controlled Folder Access makes a cameo
- The Defender for Endpoint stack is tested but wins.
- Use the command line to manage Microsoft Defender Antivirus | Microsoft Learn
- Retrieval of MpLog
Okay let’s get into it. I want to focus on the 3rd method of running this as I think that as the best chance, the first two I’ve tested in the past and they get stomped by the LSASS ASR rule.
Loading the driver for use with method 3 as described above.
Kicking off with method 3, PID for lsass and location for the dump file. (I was trying these command lines twice in succession, one with the .\ and one with a full path just to make sure.)
Running into this error, tried installing some Visual C++ Redistributable installs but no luck.
In usual fashion I had to step away, because life, and 4 hours later I see I have let it sit too long and we now have a hit on the prevalence check ASR rule that is going to battle me. Any time I opened that directory I got the toast notification below.
Let’s head to the MPLog to see what that flow looks like. Below we can see that Real-time Protection (RTP) is triggering this as a lowfi and requests a cloud check.
Peep the 0x1443614 highlighted below, my guess is this was the result of the cloud check.
0x1443614 is the first part of the GUID for that rule. Attack surface reduction rules reference | Microsoft Learn
I’ll put this ASR rule in audit mode to see where else this gets caught, but the “Block executable files from running unless they meet a prevalence, age, or trusted list criterion” rule has been by far the most underrated protection since really getting into testing various projects. I have tested a lot, more than I write about, and this rule usually balks first.
Okay, check, that rule won’t hinder us anymore. (You’ll see these outputs in blogs, it’s from a Protections Check script I cobbled together. I will share it when it’s ready)
After banging my head against the wall trying to figure out why this tool hates me, I looked back in Visual Studio and realized I had the active solution configuration set to debug, so I changed to Release and recompiled.
As soon as the new build touched disk…
Restoring the sample and continuing on. As you can see up to this point, there are already a few things in the way of commodity malware that when well configured, give your systems a few layers of protection.
Running again…WOOHOO! I got something…although I don’t see the dump file. To the logs!
I started searching for “9e6c4e1f”as that is the first part of the “Block credential stealing from the Windows local security authority subsystem (lsass.exe)” ASR rule, however, look what we have here. We actually see a Controlled Folder Access Block hit first. I’m not entirely sure what CFA was blocking here, perhaps the attempt to write the dump to disk; however, the ASR blocked the access to the lsass process anyway
No “OMG Amazing!” or “Jackpot” today, but we were close!
Thanks!