Credential Dumping Detection: Mimikatz, LSASS, and SAM (T1003) Queries
Every ransomware crew on earth has the same middle step: dump credentials from LSASS. Mimikatz, Pypykatz, ProcDump, comsvcs.dll — different tools, same prize. Once an attacker has domain credentials, the rest of the intrusion is just clicking through. Everything before credential theft is access. Everything after is the game.
This post walks through how to detect the three sub-techniques under MITRE T1003 — OS Credential Dumping: LSASS memory dumping, SAM/SYSTEM hive extraction, and NTDS.dit theft from domain controllers. Every query below is pulled verbatim from the df00tech detection library — nothing hallucinated, all ready to paste into Sentinel or Splunk.
Why LSASS Is the Crown Jewel
The Local Security Authority Subsystem Service (lsass.exe) is the process that holds credentials in memory for every logged-in user on a Windows host. NTLM hashes. Kerberos tickets. On older builds with WDigest enabled, plaintext passwords. When a user authenticates — interactively, via RDP, via a scheduled task running as a service account — their credential material ends up cached in LSASS so the system doesn’t have to re-prompt them.
This makes LSASS a single-shot jackpot. One successful dump on a jump box or a Citrix server where five domain admins logged in last week, and the attacker walks away with five sets of domain admin credentials. No keylogger, no phishing, no brute force. Just a memory read.
The problem for defenders: LSASS is legitimately accessed all the time. Windows Defender scans it. EDR agents inspect it. WerFault writes crash dumps of it. The trick isn’t detecting access — it’s distinguishing legitimate access patterns from the ones Mimikatz uses. That comes down to two things: which process is doing the accessing, and what access mask it requested.
Detecting Direct LSASS Access (T1003.001)
Here’s the production KQL query from the T1003.001 detection, covering three dumping vectors in one union:
let LsassAccessTools = dynamic([
"procdump", "procdump64", "mimikatz", "mimilib", "wce", "gsecdump",
"lsass.exe", "sqldumper", "werfault", "taskmgr"
]);
let SuspiciousLsassAccess = DeviceEvents
| where Timestamp > ago(24h)
| where ActionType == "ProcessAccessed"
| where FileName =~ "lsass.exe"
| where InitiatingProcessFileName !in~ (
"MsMpEng.exe", "csrss.exe", "services.exe", "lsm.exe",
"svchost.exe", "winlogon.exe", "wmiprvse.exe", "wininit.exe",
"SecurityHealthService.exe", "SenseIR.exe"
)
| where InitiatingProcessGrantedAccessMask in (
"0x1fffff", "0x1f3fff", "0x143a", "0x1410", "0x1010", "0x40"
)
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
InitiatingProcessAccountName, InitiatingProcessGrantedAccessMask;
let ComsvcsMinidump = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "rundll32.exe"
| where ProcessCommandLine has_all ("comsvcs.dll", "MiniDump")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine;
let ProcDumpLsass = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("procdump.exe", "procdump64.exe")
| where ProcessCommandLine has "lsass"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine;
union SuspiciousLsassAccess, ComsvcsMinidump, ProcDumpLsass
| sort by Timestamp descThe access mask filter is the core of this detection. When a process opens a handle to another process, Windows records which rights were requested. The values in the filter are the specific masks attacker tools need:
0x1fffff— PROCESS_ALL_ACCESS. This is Mimikatz’s default. It requests every possible permission. No legitimate monitoring tool needs all of them.0x1f3fff— Slightly reduced version of ALL_ACCESS that some Cobalt Strike variants request.0x1410and0x1010— PROCESS_QUERY_INFORMATION + PROCESS_VM_READ. This is the minimum needed to read LSASS memory. ProcDump uses this. Custom dumpers that try to stay low-profile use this.0x143a— A variant seen in HandleKatz and Dumpert, both designed to evade EDR by avoiding suspicious masks. The value was reverse-engineered from public releases.0x40— PROCESS_DUP_HANDLE. Used by NanoDump and other tools that duplicate an existing handle rather than opening a new one.
Why the system processes are excluded. lsm.exe, winlogon.exe, csrss.exe, wininit.exe — these are core Windows processes that legitimately talk to LSASS as part of normal authentication flow. MsMpEng.exe is Defender, SenseIR.exe is Microsoft Defender for Endpoint’s investigation service, SecurityHealthService.exe is the Windows Security UI. Filter them out and you’re left with a list of processes that almost never have a legitimate reason to touch LSASS.
The second branch (ComsvcsMinidump) catches a specific LOLBin technique: rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump <PID> <output.dmp> full. This is a signed Microsoft DLL with a built-in MiniDump function. HAFNIUM used this during the ProxyLogon exploitation campaigns because it didn’t require dropping a tool — comsvcs.dll is already on every Windows box. The third branch catches ProcDump with lsass anywhere in the command line.
For Splunk shops, the equivalent SPL query uses Sysmon Event ID 10 (ProcessAccess) with the same mask values and exclusion list.
Detecting SAM/SYSTEM Hive Extraction (T1003.002)
LSASS is for active sessions. The Security Account Manager (SAM) database is for local account hashes at rest. On any Windows host — workstation, server, DC — the SAM stores NTLM hashes for every local account that exists on that machine. To extract and crack them offline, the attacker needs the SAM hive (the hashes) and the SYSTEM hive (the bootkey to decrypt them).
Here’s the KQL detection from T1003.002:
let SAMRegistryDump = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "reg.exe"
| where ProcessCommandLine has_all ("save", "hklm\\sam")
or ProcessCommandLine has_all ("save", "hklm\\system")
or ProcessCommandLine has_all ("save", "hklm\\security")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName;
let SAMShadowCopyAccess = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("esentutl.exe", "ntdsutil.exe")
| where ProcessCommandLine has_any ("sam", "ntds", "shadow")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName;
let MimikatzSAM = DeviceProcessEvents
| where Timestamp > ago(24h)
| where ProcessCommandLine has_any ("lsadump::sam", "lsadump::cache", "sekurlsa::msv")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine;
let VSSForSAM = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "vssadmin.exe"
| where ProcessCommandLine has_any ("create shadow", "list shadows")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine;
union SAMRegistryDump, SAMShadowCopyAccess, MimikatzSAM, VSSForSAM
| sort by Timestamp descThe first branch is the money query. reg save HKLM\sam and reg save HKLM\system are the two commands that dump the required hives to disk. On a properly locked-down endpoint, this pattern has a false positive rate near zero. The only legitimate use case is a sysadmin doing registry backups before a risky change — and that should be documented in a change ticket with a specific source account.
The fourth branch catches Volume Shadow Copy abuse. Because the SAM and SYSTEM hives are locked files while Windows is running, attackers often use vssadmin create shadow /for=C: to create a point-in-time snapshot of the volume, then copy the hives out of the shadow. The T1003.002 playbook recommends correlating vssadmin creation events with subsequent registry access from the same host within the same hour — the combination is a much stronger signal than either alone.
The T1003.004 LSA Secrets detection covers the related technique of extracting the SECURITY hive, which contains cached domain credentials and service account passwords stored by the LSA. Same detection principle, different registry path.
Detecting NTDS.dit Extraction on DCs (T1003.003)
This is the apex credential theft. NTDS.dit is the Active Directory database. Every domain user. Every domain admin. Every service account. Their NTLM hashes. The krbtgt hash that, once stolen, lets you forge Kerberos tickets for any identity in the forest — the Golden Ticket attack.
From the T1003.003 detection:
let NtdsutilAccess = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "ntdsutil.exe"
| where ProcessCommandLine has_any (
"ifm", "install from media", "create full",
"ac i ntds", "activate instance ntds"
)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine;
let SecretsDumpNTDS = DeviceProcessEvents
| where Timestamp > ago(24h)
| where ProcessCommandLine has_any ("ntds.dit", "secretsdump", "drsuapi", "dcsync")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine;
let VSSCopyNTDS = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("cmd.exe", "powershell.exe", "vssadmin.exe", "esentutl.exe", "robocopy.exe", "xcopy.exe")
| where ProcessCommandLine has_all ("ntds", "dit") or ProcessCommandLine has_all ("shadow", "ntds")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine;
let DCSync = DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemotePort == 389 or RemotePort == 636 or RemotePort == 3268
| where InitiatingProcessFileName in~ ("powershell.exe", "cmd.exe", "python.exe", "python3.exe")
| where InitiatingProcessCommandLine has_any ("dcsync", "drsuapi", "secretsdump")
| project Timestamp, DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine;
union NtdsutilAccess, SecretsDumpNTDS, VSSCopyNTDS, DCSync
| sort by Timestamp descntdsutil.exe with IFM is the legitimate way to create a Read-Only Domain Controller install medium. ac i ntds activates the NTDS instance, ifm create full C:\path writes out a full copy of the database and the SYSTEM hive. Attackers use the exact same commands — APT28, Sandworm, Volt Typhoon, LAPSUS$ have all been documented running this sequence. Because legitimate ntdsutil use is rare (only during RODC provisioning or DR tests), any execution should be validated against a change ticket.
The fourth branch catches DCSync — the most elegant NTDS attack because it never touches the DC filesystem. Instead, the attacker uses a compromised account with the DS-Replication-Get-Changes right (or stolen domain admin creds) to make a directory replication request. The DC happily hands over every account’s password hash over the network, thinking it’s talking to another DC. Mimikatz’s lsadump::dcsync and Impacket’s secretsdump.py implement this.
For network-layer DCSync detection, Security Event ID 4662 on the DC with access mask 0x100 and the GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes) from a non-machine account is the signal. The full T1003.003 hunting query includes this.
If a DC’s NTDS.dit is confirmed extracted, the playbook is non-negotiable: reset the krbtgt password twice, 10 hours apart. Assume every domain credential is burned. This is the scenario that ends CISO careers.
Hunting for the Patterns EDR Misses
The queries above catch the known techniques. But credential dumping is an arms race — attackers iterate specifically to evade the detections defenders ship. Here’s what to hunt for beyond the rule set:
Unusual access masks you haven’t seen before. Maintain a baseline of every InitiatingProcessGrantedAccessMask value that has ever accessed lsass.exe in your environment. When a new mask appears from a non-trusted process, investigate. New evasion tools like NanoDump and HandleKatz specifically use uncommon masks to stay under signature-based rules.
.dmp files with interesting names. Hunt for DeviceFileEvents where the filename ends in .dmp and the creator process is rundll32.exe, werfault.exe, sqldumper.exe, or anything in C:\Windows\Temp\. Sometimes the process access is masked or missed, but the resulting dump file on disk is unmistakable. The file itself is the prize the attacker needs to exfiltrate — catching it at rest is a last line of defense.
Silent process exit abuse. Attackers configure HKLM\Software\Microsoft\Windows NT\CurrentVersion\Silent Process Exit\lsass.exe with DumpType=2 and MonitorProcess=<path-to-evil>, then crash LSASS. Windows writes a full memory dump via WerFault, and the malicious “monitor process” gets invoked. The dump looks like a normal WerFault crash dump. Registry auditing on this key catches the setup phase.
Cross-host patterns within a short window. A single LSASS access alert is bad. Five LSASS access alerts on five different hosts in 20 minutes is a ransomware crew running automation. Aggregate by time and alert on the cluster, not just the individual events.
Credential theft followed by lateral movement. The whole point of dumping creds is to use them. Correlate any T1003 alert with subsequent T1021.001 RDP lateral movement, SMB admin share access, or WMI execution from the same host within 60 minutes. The chain is the story.
Browse the Library
The T1003 family — LSASS, SAM, LSA Secrets, NTDS, DCSync — is the hinge point of virtually every serious intrusion. Coverage here is non-optional.
Browse the full df00tech detection library — 700+ KQL and SPL queries mapped to MITRE ATT&CK, free forever. Each detection includes multi-SIEM queries (KQL, SPL, Elastic EQL, QRadar AQL, Sumo Logic, Chronicle YARA-L, CrowdStrike CQL), false positive guidance, atomic red team tests you can run to validate coverage, and full IR playbooks for triage, containment, and evidence collection.