LSASS Memory Credential Dumping — Detection Beyond Mimikatz

MITRE ATT&CK

Security Relevance

LSASS holds the keys to the kingdom: every account that has logged into the system has credential material sitting in LSASS memory. A single successful dump yields NTLM hashes usable for pass-the-hash, Kerberos tickets usable for pass-the-ticket, and — if WDigest is enabled — plaintext passwords. Because LSASS runs as SYSTEM and is protected by the kernel, accessing it requires elevated rights, but any local admin can dump it without specialized tools. Detection is complicated by the diversity of dump methods: there are at least a dozen distinct techniques ranging from fully legitimate Windows tools (Task Manager) to kernel-mode driver abuse, and each has a different detection footprint. The dump file itself — not the access event — is what the attacker exfiltrates and parses.

Indicators of Malicious Use

• ⚑Event 4663 (object access) on lsass.exe from any process not in your EDR/AV allowlist — requires 'Audit Object Access → Success' and a SACL placed on the lsass.exe image path
• ⚑Event 4688 (process creation): procdump.exe with -ma and lsass as target; taskmgr.exe spawned from unexpected parent; rundll32.exe with comsvcs.dll and MiniDump in command line; sqldumper.exe or createdump.exe targeting lsass
• ⚑Event 4656 (handle opened to object): GrantedAccess 0x1010 (PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION) or 0x1410 (adds PROCESS_QUERY_INFORMATION) on lsass.exe from a non-system process
• ⚑Event 4672 (special privileges): SeDebugPrivilege granted to a process that is not a known system tool or admin utility — Mimikatz always calls privilege::debug before sekurlsa::logonpasswords
• ⚑Event 4657 (registry modified): UseLogonCredential under HKLM\...\WDigest set to 1 from any non-system process — enables plaintext credential caching for future logins
• ⚑Event 4104 (PowerShell script block): Invoke-Mimikatz, Out-Minidump, Get-ProcessMiniDump, or any script referencing sekurlsa, lsass, or minidump
• ⚑File creation event (via Sysmon 11 or EDR telemetry) for *.dmp / *.mdmp in user-writable paths with file size > 20 MB — the dump artifact regardless of which tool created it
• ⚑Driver load event for known vulnerable drivers (RTCore64.sys, DBUtil_2_3.sys, iqvw64e.sys) — BYOVD technique to bypass RunAsPPL from kernel mode

Example Log Entry

-- Method 1: ProcDump (most common) --
Event ID: 4688 — Process created
  Process Name:  C:\Windows\Temp\procdump64.exe
  Command Line:  procdump64.exe -accepteula -ma lsass.exe C:\Windows\Temp\lsass.dmp
  Parent Process: C:\Windows\System32\cmd.exe

Event ID: 4663 — Object access
  Object Name:   \Device\HarddiskVolume3\Windows\System32\lsass.exe
  Process Name:  C:\Windows\Temp\procdump64.exe
  Access Mask:   0x40  (ReadData)

-- Method 2: comsvcs.dll MiniDump (Living-off-the-Land, no external tools) --
Event ID: 4688 — Process created
  Process Name:  C:\Windows\System32\rundll32.exe
  Command Line:  rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump 756 lsass.dmp full
                 ← 756 is the lsass.exe PID; no procdump.exe needed

-- Method 3: WDigest re-enablement (stealth — collects on next logon) --
Event ID: 4657 — Registry value modified
  Object Name:   \REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control\
                 SecurityProviders\WDigest
  Value Name:    UseLogonCredential
  New Value:     1    ← plaintext passwords now cached in LSASS on next logon
  Process Name:  C:\Windows\System32\cmd.exe

Investigation Steps

1. 1.Identify the dump method: check Event 4688 for procdump.exe, taskmgr.exe, rundll32.exe (comsvcs.dll), sqldumper.exe, or unknown executables with lsass in their command line. Each method generates a distinct process creation signature. If none of these appear, check for driver load events — BYOVD techniques avoid userland process creation detections.
2. 2.Find the dump file: after confirming LSASS was accessed, search for .dmp or .mdmp files created within the same minute on that host. Check %TEMP%, %USERPROFILE%, C:\Windows\Temp, and any user-writable path. The dump file contains the actual credentials — its location tells you whether exfiltration is still pending or already occurred.
3. 3.Check Event 4672 for SeDebugPrivilege immediately before the dump event. The account and process that received SeDebugPrivilege is the dumping identity. If it differs from the logged-on user, the attacker used token impersonation or ran as SYSTEM.
4. 4.Audit WDigest: run reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential. If the value is 1 and was recently set (check Event 4657), assume every account that logged in after that timestamp has its plaintext password in the dump. Scope affected accounts from Event 4624 logon history.
5. 5.Trace the parent process of the dump tool (Event 4688 ParentProcessName). Legitimate admins rarely dump LSASS — any dump initiated from cmd.exe, PowerShell, a web browser, or a network service is an IOC. The parent chain reveals the initial access vector.
6. 6.Check for exfiltration signals: large file transfers (firewall logs, DNS queries to unusual domains) occurring within minutes of the dump file creation. The dump file is typically 20–150 MB — look for corresponding upload events in network telemetry.
7. 7.Verify RunAsPPL status: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1. If RunAsPPL is enabled and the dump succeeded, the attacker used a kernel-level bypass (BYOVD or kernel exploit). Check Event 6 (driver load) in Sysmon or Windows event log for unexpected driver loads immediately before the dump attempt.

Common False Positives

• ◎EDR and AV agents legitimately access LSASS for memory scanning — they will appear in Event 4663 and 4656 with their own process names. Maintain an allowlist of known security product processes and exclude them from alerting; do not exclude lsass.exe access events entirely.
• ◎Windows Error Reporting (WER) creates LSASS dumps when LSASS crashes — these are legitimate but should be investigated anyway, as LSASS crashes can themselves indicate attack attempts (PPLdump failures, kernel exploits). WER dumps appear under C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps.
• ◎IT operations using ProcDump for legitimate application crash dumps — ProcDump targeting lsass.exe specifically has no legitimate operational use case. Any procdump targeting lsass.exe is suspicious regardless of who ran it.
• ◎Vulnerability scanners and identity monitoring tools (CyberArk PAS, BeyondTrust) may open handles to LSASS as part of privilege monitoring. Verify against your installed product list.

Remediation

• ✓Enable RunAsPPL (LSA Protection): set HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1 and restart. This makes LSASS a Protected Process Light — unsigned or Microsoft-unsigned code cannot open it with read access. Most commodity tools (procdump, Task Manager dump) fail immediately. Verify via HKLM\SYSTEM\CurrentControlSet\Control\Lsa\PPLConfig.
• ✓Deploy Credential Guard: available on Windows 10/Server 2016+ with virtualization-based security enabled. Moves credential secrets into LSAIso (isolated LSASS) protected by the hypervisor — even kernel-mode code cannot read it. Credential Guard renders LSASS dumps credential-free for domain accounts.
• ✓Disable WDigest: confirm HKLM\...\WDigest\UseLogonCredential is 0 or absent on all endpoints. Set via GPO: Computer Configuration → Administrative Templates → MS Security Guide → WDigest Authentication (requires security baselines addon). Monitor Event 4657 for any write to this key.
• ✓Restrict SeDebugPrivilege: by default only local Administrators have this right. Audit via GPO → Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment → Debug programs. Remove any non-admin accounts.
• ✓Deploy attack surface reduction rules: Microsoft Defender ASR rule 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b3 blocks credential stealing from LSASS. Enable in audit mode first, validate no false positives, then switch to block.
• ✓Rotate all credentials from affected systems immediately — assume every hash and ticket in LSASS memory is compromised. Prioritize service accounts and domain-admin-equivalent accounts that had active sessions.
• ✓Block known BYOVD drivers: Microsoft's Vulnerable Driver Blocklist (deployed via Windows Defender Application Control / WDAC) blocks known exploited drivers. Enable WDAC with the default blocklist and monitor for driver load events of known vulnerable signed drivers.

Related Event IDs

Related Detection Guides

Frequently Asked Questions

What is the difference between an LSASS dump and a DCSync attack?

An LSASS dump reads credential material from the memory of the local LSASS process — it gets hashes for accounts that are currently logged into that specific machine. DCSync impersonates a domain controller and pulls password hashes remotely from Active Directory replication — it can retrieve any account's hash from anywhere in the domain without touching a specific machine's memory. LSASS dumps require local access to the target system; DCSync requires domain replication rights but only network access to a DC. Both yield NTLM hashes, but DCSync is the bigger threat because it can dump every account in the domain.

Does RunAsPPL stop all LSASS dumping?

RunAsPPL blocks most commodity tools — procdump, Task Manager dump, and Mimikatz running as a normal process will fail with access denied. It does not stop BYOVD (Bring Your Own Vulnerable Driver) attacks, which load a signed but vulnerable kernel driver to read LSASS from kernel mode (where PPL protections don't apply). PPLdump and similar tools also target RunAsPPL itself using kernel vulnerabilities. Credential Guard is the stronger defense — it moves secrets into a hypervisor-protected enclave that even kernel-mode code cannot access.

How does the comsvcs.dll MiniDump technique work and why is it hard to detect?

comsvcs.dll is a legitimate Windows DLL (part of COM+ services) that exports a MiniDump function. Attackers call it via rundll32.exe — a signed Windows binary — with the LSASS process ID and an output path. Because both rundll32.exe and comsvcs.dll are Microsoft-signed Windows components, signature-based AV and allowlisting tools often miss it. Detection requires command-line argument inspection: rundll32.exe appearing with comsvcs.dll and MiniDump in the same command line, especially with a numeric argument (the LSASS PID) and a .dmp output path.

Why would an attacker enable WDigest instead of just dumping LSASS immediately?

If only non-privileged accounts are currently logged in, LSASS contains those accounts' hashes — useful but limited. WDigest re-enablement is a staged attack: set UseLogonCredential = 1, then wait. When a domain admin or privileged account logs into the machine (for maintenance, incident response, or scheduled tasks), LSASS caches their plaintext password. The attacker dumps LSASS later and retrieves plaintext credentials for accounts that were not present at initial compromise. It converts a low-privilege foothold into a waiting trap for high-value credentials.