Detecting LSASS Credential Dumping

Detecting LSASS credential dumping comes down to one event: a process that has no business reading LSASS opening a handle to it with read access. LSASS holds the credential material attackers need to move laterally — NTLM hashes, Kerberos tickets, sometimes plaintext — so dumping its memory is one of the most common post-exploitation steps. The detection is precise and high-fidelity if you collect the right telemetry. This guide ships the Sysmon signal, the Sigma rule, and the LSA protections that stop it.

Credential dumping from LSASS maps to MITRE ATT&CK T1003.001 — OS Credential Dumping: LSASS Memory. It is the bridge between a single compromised host and domain-wide movement, which is why it deserves a dedicated, well-tuned detection.

What is LSASS credential dumping?

LSASS (the Local Security Authority Subsystem Service) authenticates users and keeps their credential material cached in memory so they don’t re-enter passwords constantly. That cache — NTLM hashes, Kerberos tickets, and on older or misconfigured systems plaintext — is exactly what an attacker wants. They open a handle to lsass.exe, read its memory, and extract the secrets, then reuse them to authenticate elsewhere.

The tooling varies (Mimikatz, a living-off-the-land rundll32 comsvcs.dll MiniDump, a custom handle-opener), but the behavior is constant: a process reads LSASS memory. That invariant is what makes detection reliable — you watch the access, not the tool.

What does an LSASS dump look like in telemetry?

The GrantedAccess mask is the key discriminator. Reads that include PROCESS_VM_READ (0x10) combined with query rights — masks like 0x1010 or 0x1410 — are what memory-dumping needs. Your own security agents also read LSASS, so the detection is which process with which access, allowlisted against the known-good.

Reading the GrantedAccess mask

The mask is a bitfield, and understanding it is what lets you tune this rule precisely instead of guessing at a list of magic numbers. The relevant bits:

So 0x1410 decomposes to QUERY_LIMITED | QUERY_INFORMATION | VM_READ — the minimum useful combination for reading credential material. 0x1010 is the same idea with fewer query rights.

The practical rule: alert on any mask containing 0x10 from a non-allowlisted source, rather than matching an enumerated list of exact values. Enumerated lists are how these rules go stale, because a tool that requests one unusual extra right produces a mask nobody listed.

0x1000 alone is genuinely benign and enormously common — it is what task managers and monitoring tools use to enumerate processes. Alerting on it will bury you.

What telemetry do you need to detect LSASS dumping?

This detection has hard prerequisites. Without them the rule is valid and permanently silent.

1. Sysmon with ProcessAccess enabled. Event ID 10 is not collected by a default Sysmon config, and several community baselines scope it narrowly for volume reasons. Confirm your config includes an onmatch="include" rule targeting lsass.exe — see Sysmon configuration for threat detection.

2. The CallTrace field preserved end to end. It is verbose, and log pipelines sometimes truncate or drop it to save ingest cost. Losing it removes the single best discriminator you have. Verify a real event in the SIEM still carries the full stack.

3. Driver-load events (ID 6). BYOVD is the modern precursor, so the LSASS rule without driver-load telemetry catches only the second half of the attack.

4. File-create events (ID 11). These locate the dump artifact during triage and confirm whether the read actually produced a file.

Without Sysmon, the fallback is Windows Security Event ID 4656/4663 (handle to object) against LSASS with SACL auditing configured. It is noisier, carries no call stack, and requires an audit policy most estates have not enabled — workable, but distinctly second-best.

How to detect LSASS credential dumping

The detection is a Sysmon ProcessAccess rule on LSASS with a high-permission mask, allowlisting your legitimate agents. This is the same behavior-over-tooling philosophy behind command injection detection, applied to Windows memory.

title: Suspicious Process Access to LSASS
id: 5a2f9c41-darkpwn-illustrative
status: experimental
logsource:
  product: windows
  category: process_access
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess: ['0x1010','0x1410','0x143a','0x1438','0x1f0fff','0x1fffff']
  filter_known:
    SourceImage|endswith:
      - '\MsMpEng.exe'          # Defender
      - '\wininit.exe'
      - '\csrss.exe'
  condition: selection and not filter_known
falsepositives:
  - EDR/AV agents and backup tools that read LSASS (allowlist by SourceImage/signer)
level: high

The same detection on Splunk and Sentinel

index=windows source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10
  TargetImage="*\\lsass.exe"
| eval mask = tonumber(replace(GrantedAccess, "0x", ""), 16)
| where (mask AND 16) == 16
| search NOT SourceImage IN ("*\\MsMpEng.exe", "*\\wininit.exe", "*\\csrss.exe")
| eval severity = if(match(CallTrace, "UNKNOWN"), "critical", "high")
| table _time, Computer, SourceImage, SourceProcessId, GrantedAccess, severity, CallTrace
| sort - _time

let allowlist = dynamic(["MsMpEng.exe", "wininit.exe", "csrss.exe"]);
Event
| where Source == "Microsoft-Windows-Sysmon" and EventID == 10
| extend TargetImage = tostring(EventData.TargetImage),
         SourceImage = tostring(EventData.SourceImage),
         GrantedAccess = tostring(EventData.GrantedAccess),
         CallTrace = tostring(EventData.CallTrace)
| where TargetImage endswith @"\lsass.exe"
| where binary_and(toint(strcat("0x", replace_string(GrantedAccess, "0x", ""))), 16) == 16
| where not (SourceImage has_any (allowlist))
| extend Severity = iff(CallTrace contains "UNKNOWN", "Critical", "High")
| project TimeGenerated, Computer, SourceImage, GrantedAccess, Severity, CallTrace

Both compute the bitwise test rather than matching a list of literal masks, which is the portable version of the tuning argument above.

Which false positives will you actually see?

This rule is high-fidelity once tuned, but it is not silent on day one. Every entry below is legitimate behaviour that will trip it.

Allowlist by code-signing certificate plus path, never by process name alone. A rule that excludes anything named MsMpEng.exe is trivially defeated by naming a tool MsMpEng.exe, and that is a well-known evasion rather than a theoretical one.

Re-verify allowlists after every EDR upgrade. Vendors change binary paths and add helper processes between versions, and the usual symptom is a rule that quietly starts firing on a newly-renamed component — or worse, an allowlist entry that no longer matches anything and has silently stopped protecting you from the noise it was written for.

How do you triage an LSASS access alert?

Order matters here, because by the time this alert fires the credentials may already be gone. Contain first, investigate second.

1. Isolate the host. Do not begin analysis on a live, networked machine. If a dump succeeded, every credential cached on that host should be considered compromised already.
2. Identify the source process and its parent. A dumper spawned by a web server, a scripting engine, or an Office application tells you the initial access vector immediately.
3. Read the CallTrace. UNKNOWN frames mean injected code and effectively confirm the alert as malicious without further analysis.
4. Look for the artifact. Search Sysmon Event ID 11 on that host for a .dmp file written within a minute either side of the access, then check whether it was moved or archived.
5. Check for a preceding driver load. A new or unsigned driver (Event ID 6) shortly before the access indicates BYOVD — meaning protections were disabled deliberately and the intrusion is well-resourced.
6. Enumerate what was on the box. Query the logon sessions active on that host: every one of those identities is in scope, including service accounts and the machine account.
7. Reset in dependency order. Service accounts first (they are reused most widely), then privileged users, then the computer account. Resetting the user and forgetting the machine account leaves a durable foothold.
8. Hunt for reuse. Pivot to lateral movement detection and check authentication logs for those identities appearing on hosts they never touch.

Step 6 is the one that determines the real scope, and it is regularly skipped. A domain admin who logged into that workstation once, three weeks ago, may still have credential material resident — and that single session is what turns a host compromise into a domain compromise.

How to test your LSASS detection

On a lab machine you own:

1. Use a benign minidump method (e.g. Task Manager → Create dump file on lsass.exe, or procdump in a lab) and confirm Event ID 10 fires with a read mask.
2. Confirm your allowlisted agents do not trip the rule.
3. Simulate BYOVD by loading a known-vulnerable test driver in an isolated VM and confirm the driver-load alert fires.
4. Verify the rule survives a renamed dumping tool — it should, because it keys on the access, not the name.

How to prevent LSASS credential dumping

• Block vulnerable drivers with the Microsoft vulnerable-driver blocklist to blunt BYOVD.
• Reduce cached credentials and prefer phishing-resistant auth (YubiKeys) so a dumped hash is less useful.
• Patch and isolate — least privilege limits who can run a dumper at all.

Which protection should you deploy first?

These three controls are frequently discussed as alternatives. They are not — they defeat different parts of the attack, and the deployment order matters because their prerequisites and breakage risks differ sharply.

Start with LSA protection in audit mode. It logs what would have been blocked without breaking anything, which surfaces the legacy components that inject into LSASS in your estate before they become an outage. Credential Guard is the stronger control but has firmer hardware requirements and will break anything depending on WDigest or unconstrained delegation — both of which you want gone anyway, so treat the audit output as a remediation backlog rather than a blocker.

Note the shared bypass row: every one of these is defeated by an attacker who reaches kernel mode. That is precisely why detection is not optional here. Prevention raises the cost; driver-load monitoring and the LSASS access rule catch the adversary who paid it.

What evades this detection, and what to do about it

A detection you cannot describe the limits of is a detection you are overtrusting. Four documented evasion classes matter here, and each has a defensive answer that does not require knowing the specific tool.

Handle duplication. Rather than opening LSASS directly, an attacker obtains a handle that another process already holds and duplicates it. The read still happens, but the source of the original open looks legitimate. The defensive answer is to watch for PROCESS_DUP_HANDLE (0x0040) requests against processes that themselves hold LSASS handles, and to treat any process acquiring a handle to a security agent as suspicious in its own right.

Deferred or indirect dumping. Instead of reading memory, an attacker induces the operating system to write the dump for them through legitimate crash-handling or diagnostic paths. There is no anomalous ProcessAccess event because the dump was produced by a trusted component. The answer is artifact-side: monitor Event ID 11 for dump-shaped files appearing in unusual locations, and treat a .dmp written outside the expected crash directories as an alert regardless of which process wrote it.

Kernel-mode reads. With a vulnerable driver loaded, memory can be read without a userland handle, producing no Event ID 10 at all. This is the reason driver-load alerting is not an optional extra to this detection but half of it.

Sensor removal. Unloading Sysmon produces silence rather than an alert. The countermeasure is agent-silence monitoring, covered in Sysmon configuration — a host that stops reporting is an alert, not an absence.

Common LSASS detection mistakes

• No Sysmon, or no ProcessAccess logging. Without Event ID 10, the core signal is uncollected.
• No allowlist. The rule pages on Defender and gets muted.
• Watching tool names. Renamed or custom dumpers evade name-based rules.
• Ignoring driver loads. BYOVD disables protection before the quiet dump.

LSASS credential dumping detection checklist

1. Deploy Sysmon with ProcessAccess (EID 10) logging on lsass.exe.
2. Alert on read-access masks (0x1010, 0x1410, …) from non-allowlisted sources.
3. Allowlist legitimate agents by SourceImage and code-signing certificate.
4. Alert on new/unsigned kernel driver loads (EID 6) — BYOVD precursor.
5. Enable LSA protection (RunAsPPL) and Credential Guard.
6. Turn on the ASR “block credential stealing from LSASS” rule.
7. Apply the Microsoft vulnerable-driver blocklist.
8. Test detection with a benign lab dump and a renamed tool.
9. Test the bitwise mask condition, not an enumerated list of literal values.
10. Confirm CallTrace survives your log pipeline untruncated, and escalate on UNKNOWN frames.
11. Alert on dump-shaped files (Event ID 11) written outside expected crash directories.
12. Monitor for Sysmon agent silence, so a sensor unload is itself an alert.
13. Re-verify agent allowlists after every EDR upgrade.
14. Rehearse the triage runbook, including the machine-account reset step.

The last item is worth rehearsing rather than documenting. Credential-theft response is time critical and involves resets that break things, so the first time a team performs it should not be during a live intrusion at 02:00. Walk it end to end once on a lab host and the real incident becomes a procedure instead of an improvisation.

The takeaway

Detecting LSASS credential dumping is a tuned Sysmon ProcessAccess rule on lsass.exe with a high-permission mask, allowlisted to your real security agents, and paired with driver-load alerting for the BYOVD that precedes modern dumps. Prevent with LSA protection and Credential Guard; detect for what bypasses them. Continue with NTLM relay detection, Sysmon configuration and detecting the BYOVD attacks that disable those protections, then follow the stolen credential into detecting lateral movement, or browse the full Detection Engineering pillar.