Credential dumping is one of the most damaging techniques an attacker can execute post-compromise. By reading Windows LSASS (Local Security Authority Subsystem Service) memory, an attacker extracts NTLM hashes, Kerberos tickets, and in some configurations cleartext passwords for every account that has logged into the machine — including domain admins. This takes the attack from a single compromised workstation to potential full domain takeover within minutes.
The core challenge is that LSASS access is also performed by legitimate processes: antivirus, backup agents, and Windows itself. The difference is who is accessing LSASS, from what process, with what access rights, and whether the call is accompanied by known dumping signatures. This SOP provides the exact event IDs, MDE portal paths, and KQL queries to separate legitimate LSASS access from credential theft in real time.
01
Background
CONTEXTB1MITRE ATT&CK Mapping & Credential Dump Methods
| MITRE | Method | Tool / Command | What Is Extracted |
|---|---|---|---|
| T1003.001 | OS Credential Dumping — LSASS Memory | Mimikatz sekurlsa::logonpasswords; Task Manager minidump; procdump lsass.exe; comsvcs.dll MiniDump | NTLM hashes, Kerberos TGTs, WDigest cleartext passwords (if WDigest enabled), DPAPI master keys |
| T1003.002 | OS Credential Dumping — SAM | reg save HKLM\SAM, reg save HKLM\SYSTEM; secretsdump; Mimikatz lsadump::sam | Local account NTLM hashes from the Security Account Manager database |
| T1003.003 | OS Credential Dumping — NTDS | ntdsutil "activate instance ntds" ifm "create full C:\temp"; Mimikatz lsadump::dcsync; Volume Shadow Copy ntds.dit extraction | ALL domain account hashes from Active Directory database — complete domain takeover potential |
| T1003.004 | OS Credential Dumping — LSA Secrets | Mimikatz lsadump::secrets; secretsdump; reg save HKLM\SECURITY | Service account credentials, cached domain credentials, DPAPI keys stored in LSA secrets |
| T1055.001 | Process Injection into LSASS | Reflective DLL injection into lsass.exe; custom Mimikatz variants using direct syscalls | Avoids creating a process dump file — extracts credentials via injected code in LSASS address space |
B2Log Sources, Event IDs & Prerequisites
| Source | Event / Table | Key Signal | Required Setting |
|---|---|---|---|
| MDE Process Events | DeviceProcessEvents | procdump.exe, comsvcs.dll, ntdsutil.exe, reg save HKLM\SAM — process creation with dumping arguments | MDE onboarded |
| MDE Alerts | DeviceAlertEvents | MDE built-in: "Credential dumping", "Suspicious access to LSASS service", "LSASS memory read" — MDE raises these automatically | MDE P2; Tamper Protection enabled |
| Windows Security (Sysmon EID 10) | Event (Sysmon EventID 10) | ProcessAccess: SourceImage → TargetImage=lsass.exe, GrantedAccess=0x1010 or 0x1410 — these access masks signal memory read for credential extraction | Sysmon deployed with ProcessAccess rule targeting lsass.exe |
| Windows Security (EID 4656) | SecurityEvent | Object access to SAM/SECURITY/SYSTEM registry hives — ObjectName contains \REGISTRY\MACHINE\SAM | Audit Object Access: Registry enabled in GPO |
| MDE File Events | DeviceFileEvents | lsass.dmp files created — procdump and comsvcs.dll write LSASS dump to disk before transfer | MDE onboarded |
02
Identification
DETECT & INVESTIGATE◈ Credential Dumping (LSASS / SAM / NTDS) — Investigation Workflow
I1Confirm LSASS Memory Access or Dump File CreationMANUAL + KQL
WHY
LSASS memory access is the ground truth for credential theft — if an unauthorized process read LSASS memory with the right access mask, the attacker has credentials regardless of whether a dump file was written to disk. The access mask value in Sysmon Event 10 or Windows Event 4656 determines the intent: read-only access (0x1010) is sufficient to extract hashes without any file being written. You must check the accessor process and the access mask together.
◈ Where to Check — MDE Alert & Process Timeline
security.microsoft.com→Incidents & alerts→[Alert: LSASS access]→Evidence & response
- 1Open the MDE alert. In Evidence and response, check the Process tree — the process that accessed LSASS will be shown as a child of the dumper process. Note: the accessor binary name, the parent process, and whether the binary is signed.
- 2Navigate to Device timeline → File created. Search for
lsass.dmp,lsass.exe.dmp, or any.dmpfile created in a user-writable path around the alert time. A dump file on disk means the attacker planned to exfiltrate it — check for network outbound from the same process immediately after. - 3Check the Accounts tab on the device page — MDE shows all accounts with active logon sessions on the device. Every account listed here must be treated as potentially compromised and have their credentials reset. This is the blast radius of the dump.
◈ Where to Check — Sysmon Event 10 (LSASS ProcessAccess)
Event Viewer→Applications and Services Logs→Microsoft→Windows→Sysmon→Operational (EID 10)
- 4Filter for Event ID 10. The TargetImage field must be
C:\Windows\System32\lsass.exe. The GrantedAccess field shows the access mask — see Key Indicators table below for which values indicate credential dumping vs legitimate access. - 5Note the SourceImage — the process that opened the LSASS handle. If it is
procdump.exe,taskmgr.exe(Task Manager dump),comsvcs.dllvia rundll32, or an unknown binary — this is malicious. If it isMsMpEng.exe,csrss.exe, or your known AV binary — this is likely a false positive.
Key Indicators — LSASS Access Masks & Credential Dump Patterns
| Indicator | Meaning | Analyst Action |
|---|---|---|
| GrantedAccess 0x1010 | PROCESS_VM_READ + PROCESS_QUERY_LIMITED_INFORMATION — minimum access needed to read LSASS memory. Classic Mimikatz sekurlsa access mask. | Confirmed credential dumping access. Escalate to SEV1 immediately if SourceImage is not a known AV/backup tool. |
| GrantedAccess 0x1410 | Includes PROCESS_VM_READ + PROCESS_QUERY_INFORMATION + PROCESS_DUP_HANDLE — used by some Mimikatz variants and advanced tools | Same as 0x1010 — confirmed malicious LSASS read. |
| GrantedAccess 0x1fffff | PROCESS_ALL_ACCESS — full access to the LSASS process. Very aggressive — used by raw memory dumpers. | Highest severity LSASS access. Isolate device immediately. |
| procdump.exe -ma lsass | Sysinternals ProcDump used to create a full minidump of LSASS. Legitimate tool abused by attackers — creates .dmp file on disk that contains all credentials. | Find the .dmp file (DeviceFileEvents). Block procdump.exe hash if attacker-supplied. Check for exfiltration of the dump file. |
| comsvcs.dll MiniDump | rundll32.exe C:\Windows\System32\comsvcs.dll,MiniDump [lsass PID] [output.dmp] full — signed Windows DLL abused to create LSASS dump without external tools | Search DeviceProcessEvents for rundll32.exe with comsvcs.dll argument. Output .dmp file name will be in the command line. |
| ntdsutil "create full" | Creates an offline copy of the Active Directory database (ntds.dit + SYSTEM hive) — contains hashes of ALL domain accounts. Only valid on Domain Controllers. | AUTOMATIC SEV1. Treat as full domain compromise. All domain account passwords must be reset — this includes krbtgt (twice) for Golden Ticket defence. |
| reg save HKLM\SAM | Saves the SAM registry hive to disk — contains NTLM hashes of all local accounts. Combined with SYSTEM hive: offline cracking possible. | Find both SAM and SYSTEM save commands (often run together). Identify destination path. Check for exfiltration of the saved files. |
DETECTS: All processes accessing lsass.exe via Sysmon Event 10 with high-risk access masks (0x1010, 0x1410, 0x1fffff) or full access — identifies LSASS memory reads from non-whitelisted processes in the last 7 days.
KQL — Microsoft Sentinel: Sysmon LSASS ProcessAccess (Event 10)
let knownAV = dynamic(["MsMpEng.exe","avgnt.exe","avp.exe","bdagent.exe","ekrn.exe",
"csrss.exe","wininit.exe","lsm.exe","svchost.exe"]);
Event
| where TimeGenerated > ago(7d)
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 10
| extend SourceImage = extract(@"SourceImage: (.+?)\\r",1,RenderedDescription)
| extend TargetImage = extract(@"TargetImage: (.+?)\\r",1,RenderedDescription)
| extend GrantedAccess = extract(@"GrantedAccess: (.+?)\\r",1,RenderedDescription)
| where TargetImage has "lsass.exe"
| where GrantedAccess in ("0x1010","0x1410","0x1fffff","0x1f1fff","0x143a")
| where not(SourceImage has_any (knownAV))
| project TimeGenerated, Computer, SourceImage, TargetImage, GrantedAccess
| order by TimeGenerated desc
DETECTS: Process creation events for known credential dumping tools — procdump, comsvcs MiniDump, ntdsutil, Mimikatz binary names, and SAM/SYSTEM hive saves via reg.exe.
KQL — MDE: Credential dumping tool execution
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where (FileName =~ "procdump.exe" and ProcessCommandLine has "lsass")
or (FileName =~ "rundll32.exe" and ProcessCommandLine has "comsvcs" and ProcessCommandLine has "MiniDump")
or (FileName =~ "ntdsutil.exe")
or (FileName =~ "reg.exe" and ProcessCommandLine has "save" and ProcessCommandLine has_any ("SAM","SYSTEM","SECURITY"))
or (ProcessCommandLine has_any ("sekurlsa","lsadump","logonpasswords","dcsync","dumpcreds"))
| project TimeGenerated, DeviceName, AccountName, FileName,
ProcessCommandLine, InitiatingProcessFileName
| order by TimeGenerated desc
SPL — Splunk: LSASS dump and credential tool detection
index=windows (EventCode=10 OR EventCode=4688)
((TargetImage="*lsass.exe" (GrantedAccess=0x1010 OR GrantedAccess=0x1410 OR GrantedAccess=0x1fffff))
OR (process_name="procdump.exe" CommandLine="*lsass*")
OR (process_name="rundll32.exe" CommandLine="*comsvcs*MiniDump*")
OR (process_name="ntdsutil.exe")
OR (process_name="reg.exe" (CommandLine="*SAM*" OR CommandLine="*SYSTEM*") CommandLine="*save*"))
| eval Method=case(
match(CommandLine,"comsvcs"),"comsvcs MiniDump",
match(CommandLine,"procdump"),"ProcDump",
match(CommandLine,"ntdsutil"),"ntdsutil NTDS",
match(CommandLine,"SAM"),"SAM hive save",
1=1,"LSASS direct access")
| table _time, ComputerName, user, Method, CommandLine
| sort -_time
I2Scope the Blast Radius — Identify All Exposed AccountsMANUAL + KQL
WHY
The dump itself does not tell you which credentials were exposed — the device's logon session history does. Every account that authenticated to this device (interactively, via network, via RDP, via service) within the LSASS session window has credentials in the dump. Identifying those accounts determines the credential reset scope — miss one domain admin and the attacker retains access to the entire environment.
◈ Where to Check — Logon Sessions on Affected Device
security.microsoft.com→Endpoints→[Device]→Logged on users
- 1Navigate to the device page in MDE. Check the Logged on users section — this lists all accounts with recent logon sessions on the device. Every account here is in scope for credential reset.
- 2Additionally check Windows Security Event 4624 (successful logon) on the device for the 30 days before the dump — any account that logged in during that window had their credentials in LSASS at some point. Logon type 3 (network) and type 10 (remote interactive) are especially common for lateral movement credentials.
- 3If a Domain Admin or Service Account with broad access was in the session list — treat this as a full domain compromise. Escalate to CISO and IR before any further triage steps. The credential reset scope now includes krbtgt, all privileged accounts, and all service accounts visible to this device.
DETECTS: All accounts that had successful logon sessions on the compromised device in the 30 days before the dump — establishes the full credential reset scope. Grouped by logon type to prioritise service accounts and admin logons.
KQL — All accounts with logon sessions on affected device (blast radius)
let deviceName = "AFFECTED-DEVICE-NAME"; // replace with actual device name
let dumpTime = datetime(2026-06-24T00:00:00Z); // replace with dump timestamp
SecurityEvent
| where TimeGenerated between (dumpTime - 30d .. dumpTime)
| where Computer has deviceName
| where EventID == 4624
| where LogonType in (2,3,4,5,7,10,11) // exclude system logon type 0
| where TargetUserName !endswith "$" // exclude computer accounts
| summarize LastSeen=max(TimeGenerated), LogonTypes=make_set(LogonType),
LogonCount=count() by TargetUserName, TargetDomainName
| order by LastSeen desc
DETECTS: Network activity from the dumping process or same device around the dump time — identifies whether the dump file was exfiltrated to an attacker-controlled host before containment.
KQL — Was the dump file exfiltrated?
let deviceName = "AFFECTED-DEVICE-NAME";
let dumpTime = datetime(2026-06-24T00:00:00Z);
DeviceNetworkEvents
| where TimeGenerated between (dumpTime - 5m .. dumpTime + 30m)
| where DeviceName has deviceName
| where not(ipv4_is_private(RemoteIP))
| where ActionType == "ConnectionSuccess"
| project TimeGenerated, DeviceName, InitiatingProcessFileName,
InitiatingProcessCommandLine, RemoteIP, RemoteUrl, RemotePort
| order by TimeGenerated asc
If ntdsutil or DCSync was used on a Domain Controller — the blast radius is ALL domain accounts, not just those logged into that specific device. In this case, the entire domain credential set must be treated as compromised. krbtgt must be reset TWICE (with a delay between resets) to invalidate all existing Kerberos tickets including any Golden Tickets already issued.
03
Containment
STOP ITBased on Identification Findings:
Confirmed
Unknown process accessed LSASS with 0x1010/0x1410/0x1fffff mask, OR procdump/comsvcs/Mimikatz execution confirmed in process events, OR .dmp file created in user-writable path, OR reg save HKLM\SAM/SYSTEM executed, OR ntdsutil "create full" on DC → SEV1. Execute C1 immediately and notify CISO in parallel.
Uncertain
LSASS accessed by unknown process but access mask is low-risk (0x0400 = query info only), no dump file created, no known dumping tool name — could be an unlisted AV/monitoring agent → Verify the accessor binary (check certificate, hash, vendor). If unsigned or unknown vendor: treat as confirmed and proceed to C1.
False Pos.
LSASS accessor is a known, signed AV or backup agent (CrowdStrike, Carbon Black, Veeam, Windows Task Manager by IT admin performing routine memory snapshot), GrantedAccess is not 0x1010 or higher, no dump file created → Document the process name and hash. Add an exclusion for this binary in your Sysmon LSASS ProcessAccess rule to reduce future alert noise.
C1Isolate Device & Begin Emergency Credential ResetSEV1 — Immediate
- 1Isolate the device immediately: MDE → Device → Isolate device → Full isolation. This stops any ongoing dump exfiltration and prevents the attacker using harvested credentials from this device's network position for lateral movement.
- 2Delete the dump file if present on disk: Via Live Response:
del /F /Q "C:\path\to\lsass.dmp". Also check for.dmpfiles in common output paths (TEMP, current directory of the dumper process). The dump file may have already been exfiltrated — assume it was until proven otherwise. - 3Initiate emergency credential reset for all accounts in the blast radius (from I2 Step 1 account list). Priority order: (1) Domain Admins and Tier-0 accounts, (2) Service accounts with broad permissions, (3) Standard user accounts on the device. Do NOT rely on password expiry — issue forced resets immediately.
- 4Revoke all active sessions for blast-radius accounts: Entra ID → Users → [UPN] → Revoke sessions for each. Changed passwords do not invalidate existing NTLM hashes in use — session revocation is required to kill active credential reuse in progress.
- 5If ntdsutil or DCSync confirmed: Reset krbtgt account password twice with a 10-hour interval between resets (Kerberos ticket lifetime). This invalidates all existing Kerberos tickets including any pre-issued Golden Tickets. Coordinate with Active Directory team — this will cause disruption to Kerberos-authenticated services.
04
Eradication
CLEAN UPE1Full Credential Remediation & Defensive Hardening
- 1Complete credential reset for ALL blast-radius accounts. Track completion in a spreadsheet. Do not close this incident until every account from the I2 logon list has a confirmed password reset with MFA re-enrolment.
- 2Enable Windows Credential Guard on the affected device and across the org if not already active: Credential Guard moves LSASS into a Hyper-V isolated container (VTL1), making sekurlsa-style memory reads return empty — Mimikatz returns "ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory" when Credential Guard is active.
- 3Disable WDigest authentication if not already done:
reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 0 /f. WDigest enabled means cleartext passwords are stored in LSASS memory — this should be set org-wide via GPO. - 4Enable LSA Protection (PPL):
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL /t REG_DWORD /d 1 /f+ reboot. PPL (Protected Process Light) prevents non-PPL processes from opening handles to LSASS — blocks most user-mode dumping tools without requiring Credential Guard. - 5Hunt for lateral movement using the dumped credentials: Run the following KQL to find unusual logons using the blast-radius accounts from I2 — any logon from an unexpected IP or device after the dump time may indicate credential reuse by the attacker.
DETECTS: Logon events from blast-radius accounts after the dump time — identifies whether the attacker successfully used harvested credentials to authenticate to other systems in the environment.
KQL — Hunt for credential reuse after dump
let blastRadiusAccounts = dynamic(["[email protected]","[email protected]"]); // replace with I2 account list
let dumpTime = datetime(2026-06-24T00:00:00Z);
SigninLogs
| where TimeGenerated > dumpTime
| where UserPrincipalName in~ (blastRadiusAccounts)
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, IPAddress,
LocationDetails, AppDisplayName, DeviceDetail,
RiskLevelDuringSignIn
| order by TimeGenerated asc
Eradication Complete When
- All blast-radius accounts have confirmed password reset and MFA re-enrolment
- krbtgt reset twice (with 10-hour interval) if ntdsutil/DCSync confirmed on a Domain Controller
- Dump file deleted from disk; no evidence of successful exfiltration to external IP
- Credential Guard or LSA Protection (PPL) deployed on affected device and enabled org-wide via GPO
- WDigest UseLogonCredential set to 0 org-wide via GPO
- Lateral movement hunt (credential reuse KQL) returns clean for all blast-radius accounts
- Sysmon LSASS ProcessAccess rule confirmed deployed and ingesting into Sentinel
05
Escalation
TIERSESCEscalation Decision Table
| Tier | Trigger Condition | Who to Notify | Action |
|---|---|---|---|
| L1 → L2 (SEV2) | Single workstation, LSASS dump confirmed but no Domain Admin in blast radius, no evidence of dump exfiltration, no lateral movement detected after dump time | L2 SOC Analyst | Emergency credential reset for blast-radius accounts. Hand off: device name, dump method, full account list from I2, containment actions taken, Credential Guard status |
| L2 → IR + CISO (SEV1) | Any of: Domain Admin or service account with broad privileges in blast radius; ntdsutil or DCSync used on Domain Controller (all domain creds compromised); dump file exfiltrated to external IP confirmed; lateral movement using dumped credentials detected on other devices | IR Team + CISO + Legal | Declare SEV1. Full domain credential reset (krbtgt twice). Map all lateral movement. Legal assessment for regulatory notification if personal data was accessible from compromised accounts. |
| L2 → Security Engineering | Credential Guard not deployed; LSA Protection (PPL) not enabled; WDigest enabled; Sysmon LSASS ProcessAccess rule not alerting; no MDE built-in rule for procdump/comsvcs | Security Architecture | Priority: deploy Credential Guard via GPO immediately. Enable LSA PPL. Disable WDigest. Deploy Sysmon with LSASS ProcessAccess rule. Enable MDE attack surface reduction rule "Block credential stealing from the Windows local security authority subsystem". |
The single most impactful control against LSASS dumping is Credential Guard. Once enabled, WDigest cleartext passwords are eliminated from LSASS memory, sekurlsa returns empty, and process injection into LSASS is blocked. Enable it via GPO: Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security → Credential Guard Configuration = Enabled with UEFI lock. Requires VT-x/AMD-V and Secure Boot.
Authorized security research & penetration testing only. Unauthorized use is illegal. Built by Rudra Verma | Senior Cyber Security Architect & Researcher | CyberHawk Threat Intel
◈ Stay Connected
Follow CyberHawk Threat Intel for threat intelligence, SOC playbooks, and detection engineering content.
"They can't exploit you if you are the Exploit."