Case File: Hunting LSASS Credential Dumping — Catching Mimikatz-Style Access Before the Hashes Leave

The Incident Pattern

A workstation in finance starts behaving normally — until it doesn't. A single process opens the Local Security Authority Subsystem Service (lsass.exe), requests high-privilege memory handles, and seconds later an encoded blob of credentials is sitting on disk or in a remote session. Credential dumping is the gateway technique for nearly every domain-compromise story ever told: Mimikatz, Secretsdump, SafetyKatz, comsvcs.dll abuse, even the humble Task Manager dump.

This hunt doesn't wait for an alert. It assumes an adversary — or a red teamer — is already attempting credential access and asks: who touched lsass.exe, and why?

The Hypothesis

Hypothesis: If an actor is harvesting credentials on this estate, we will find non-system processes requesting high-privilege access (granted access masks like 0x1410, 0x1438, 0x143a, 0x1fffff) to lsass.exe, or processes launching known dump utilities (procdump, comsvcs #24, rundll32 loading suspicious DLLs) — and lsass.exe has no legitimate reason to be opened by anything other than the OS itself.

Data You'll Need

Source	What we're after
Sysmon Event ID 10 (ProcessAccess)	Source image, target image, granted access mask
Microsoft Defender `DeviceProcessEvents`	Process creation with suspicious command lines
Security Event 4656 / 4663	Handle requests to lsass.exe (object access auditing)
Sysmon Event ID 1	comsvcs.dll / rundll32 dump command lines

Enable Sysmon ProcessAccess logging for lsass.exe as a target in your config — without it, this technique is nearly invisible.

Hunting with KQL

Microsoft Sentinel / Defender for Endpoint — find high-privilege opens of lsass by unusual parents:

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "ProcessAccess"
| where FileName == "lsass.exe"
| where InitiatingProcessFileName !in ("services.exe", "wininit.exe", "csrss.exe", "smss.exe", "lsass.exe", "MpCmdRun.exe")
| extend GrantedAccess = tostring(parse_json(AdditionalFields).GrantedAccess)
| where GrantedAccess in ("0x1010", "0x1410", "0x1438", "0x143a", "0x1fffff")
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName, GrantedAccess, InitiatingProcessAccountName
| order by Timestamp desc

What this does: filters process-access telemetry to opens of lsass.exe, excludes the small set of legitimate system parents, and keeps only the granted-access masks associated with memory-read / dump operations (0x1410 and 0x1438 are classic Mimikatz masks). The parent process is surfaced because dumping tools are often launched from scripts, LOLBins, or injected threads.

True-positive example: 2026-09-20 14:03:11 | WS-FIN-014 | procdump64.exe | procdump64.exe -accepteula -ma lsass.exe C:\Temp\lsass.dmp | GrantedAccess: 0x1410 | Account: FINANCE\jchen — an unapproved copy of ProcDump opening lsass with a dump mask and writing a .dmp file. That's the whole case in one row.

Companion query — command-line signatures of common dumpers:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("MiniDumpWriteDump", "sekurlsa::logonpasswords", "comsvcs", "#24", "procdump", "-ma lsass")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName

Hunting with Splunk

Equivalent hunt across Sysmon logs (assumes a sysmon index or the Endpoint data model):

index=sysmon EventCode=10 TargetImage="*lsass.exe"
| search NOT SourceImage IN ("*\\services.exe", "*\\wininit.exe", "*\\csrss.exe", "*\\smss.exe", "*\\MpCmdRun.exe")
| search GrantedAccess IN ("0x1010", "0x1410", "0x1438", "0x143a", "0x1fffff")
| stats count by Computer, SourceImage, SourceProcessId, GrantedAccess, CallTrace
| sort - count

What this does: the same logic — Sysmon Event ID 10 targeting lsass, legitimate parents excluded, dump-associated access masks kept, aggregated per host with the call trace for validation.

Example hit: Computer=WS-FIN-014 | SourceImage=C:\Windows\Temp\svchost_upd.exe | GrantedAccess=0x1438 | CallTrace=UNKNOWN|+...|+mimilib.dll+... — a lookalike "svchost" dropped in Temp loading mimilib.dll in its call trace. Mimikatz, wearing a costume.

Analyst walkthrough (click to expand)

Run the KQL/SPL query over the last 7 days, sorted by newest.
For each hit, pivot on DeviceName ±10 minutes: look for .dmp writes, encoded PowerShell, or outbound connections.
Check the call trace (Sysmon) — dbghelp.dll/dbgcore.dll loads strongly corroborate a dump.
Cross-reference the account: was it interactive, and does the user do admin tooling?

Validating the Hit

Isolate the process tree. Confirm the source image path, hash, and signer. Unsigned binaries in user-writable paths are damning.
Look for the artifact. Search the host for *.dmp, large memory writes, or renamed dumpers (procdump renamed to svchost.exe is a classic).
Check privilege. Credential dumping needs admin/Debug privilege — confirm the account had it and whether it should have.
Scope the blast radius. One dumped host means harvested hashes; hunt for those credentials' reuse across the fleet (logon anomalies) for the next 72 hours.

Tuning Out False Positives

EDR / AV agents (Defender's MsMpEng.exe, third-party sensors) legitimately open lsass for behavioral inspection — baseline and allowlist by signed publisher.
Backup and monitoring tools occasionally request handles during inventories; their access masks are usually lower-privilege.
Windows Error Reporting can touch lsass during crash dumps — correlate with actual crash events.
Tune by combining mask + parent + path + signer: a signed AV engine from Program Files with a dump mask is noise; an unsigned binary from Temp is signal.

What to Do Next

Contain: isolate the host, kill the dumping process, and preserve the .dmp file and process memory for forensics.
Assume compromise of harvested credentials: force password resets for accounts logged on to the host, prioritizing privileged and service accounts.
Harden: enable LSA Protection (PPL), Credential Guard / VBS on supported builds, and block unsigned process access to lsass via Attack Surface Reduction rules.
Detect durably: promote this hunt to a scheduled Sentinel analytics rule or Splunk correlation search with the tuned exclusions baked in.

Filed from the hunt floor: the fastest credential-dump investigations end when the analyst trusts the access mask. 0x1410 on lsass from an unsigned binary is not a gray area — it's a case.