Atomic Red Team — DumpLSASS

Red Canary Threat Research released 2 new AtomicTestHarnesses —

Invoke-ATHDumpLsass and Invoke-ATHLogonUser

Today I am going to showcase Invoke-ATHDumpLSASS and how I validated my current coverage. As a defender, this really assists with validating depth of coverage with an EDR product or SIEM content. Lots of moving parts here, but we want to see the TargetImage as lsass.exe, Access Requested, SourceUser, and DLL loaded.

To begin, the analytic I will be using is https://research.splunk.com/endpoint/e4723b92-7266-11ec-af45-acde48001122/ or

`sysmon` EventCode=10 TargetImage=*lsass.exe GrantedAccess IN ("0x01000", "0x1010", "0x1038", "0x40", "0x1400", "0x1fffff", "0x1410", "0x143a", "0x1438", "0x1000") CallTrace IN ("*dbgcore.dll*", "*dbghelp.dll*", "*ntdll.dll*")

First, let’s break this down. I initially updated this analytic by utilizing Atomic Red Team T1003.001 outlined in this blog. First, I added specific GrantedAccess requests made by these credential dumping utilities. Some may be noisier than others, filter as needed. From there, I use the CallTrace to look for 3 specific DLLs being loaded — dbgcore, dbhhelp and ntdll. These 3 DLL’s are most commonly used for dumping credentials as they have functions that allow for it.

Now, ATHDumpLsass offers some behind the scenes action of what the Atomic tests are doing, but all within a single harness.

Let’s check it out:

First, RequestedAccess , which in Sysmon is GrantedAccess

• AllAccess
• QueryLimitedInformation
• QueryInformation
• VirtualMemoryRead
• QueryLimitedInformation, VirtualMemoryRead
• QueryInformation, VirtualMemoryRead

Reference my prior blog, and you’ll see the names to values:

From here, the next thing that stood out to me is the Variant values:

• Dbghelp!MiniDumpWriteDump
• Dbgcore!MiniDumpWriteDump
• Kernel32!ReadProcessMemory
• api-ms-win-core-memory-l1–1–0!ReadProcessMemory
• Kernelbase!ReadProcessMemory
• Kernel32!CreateToolhelp32Snapshot
• DuplicateHandle
• Ntdll!NtReadVirtualMemory

Now this is the magic. We can now play with variants and different permissions against lsass and see what the result is. Between it all, they will each load their function from the DLL needed — whether that is dbghelp, dbgcore or kernelbase.dll and so forth. The part that matters here, is we can test this all out.

Simulate

If you have never used ATH, it’s pretty easy to get going by following the wiki or

Install-Module -Name AtomicTestHarnesses -Scope CurrentUser

or

Download the repo and run something similar:

Import-Module C:\Users\Test\Desktop\AtomicTestHarnesses\AtomicTestHarnesses.psd1

easy! Done.

Now, let’s run it:

Now some variations:

Invoke-ATHDumpLSASS -Variant Dbgcore!MiniDumpWriteDump -AccessRights ‘QueryInformation, VirtualMemoryRead’

Invoke-ATHDumpLSASS -Variant Kernel32!CreateToolhelp32Snapshot -AccessRights AllAccess

Alright, now let’s check our current query against all this testing. Now, I ran this prior to writing the blog so I will have more data.

Validate

Current query:

`sysmon` EventCode=10 TargetImage=*lsass.exe GrantedAccess IN ("0x01000", "0x1010", "0x1038", "0x40", "0x1400", "0x1fffff", "0x1410", "0x143a", "0x1438", "0x1000") CallTrace IN ("*dbgcore.dll*", "*dbghelp.dll*", "*ntdll.dll*")

result:

Breaking this down a bit —

• 5000+ events over 7 days
• SourceUser is all over the place
• GrantedAccess values all over
• SourceImage is regular software
• High False Positives

This got me thinking, how can I make this more high fidelity using the new AtomicTestHarness?

Tuning

we already simulated with the harness above, now let’s drill in to see what we can find in our data all while identifying new adds to the query.

Something off the bat already bugs me about the formatting of TargetImage and SourceImage

Let’s flip those.

A way to make this more high fidelity is SourceUser. Why would an adversary as SYSTEM want to dump credentials? Let’s go ahead and remove these:

NOT SourceUser IN (“NT AUTHORITY\\SYSTEM”, “NT AUTHORITY\\NETWORK SERVICE”)

That really helped clean up the results.

Now on to the CallTrace. Let’s first remove it and add it in our stats to see all the values.

Just the CallTrace here. Noticing dbgcore, dbghelp, ntdll — but the two I don’t have in my query — kernelbase.dll and kernel32.dll. I’ll add those.

Re-run it and results without CallTrace:

At a minimum, based on this ATHDumpLSASS and Atomic Tests T1003.001, this will capture most all things. Let’s run T1003.001 for fun.

Results:

Solid capture! I think we’re in a good place now!

Happy Hunting :-)

I’ll leave us here today and next time we will dive into Invoke-ATHLogonUser