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.

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

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.

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.

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, or browse the full Detection Engineering pillar.