Detecting Mimikatz with Sysmon

MITRE ATT&CK

Security Relevance

Mimikatz or its derivatives appear in nearly every hands-on-keyboard Windows intrusion. Credential extraction from LSASS provides NTLM hashes for pass-the-hash, Kerberos tickets for pass-the-ticket, and Kerberos service account hashes for Kerberoasting. A single successful Mimikatz run against a domain controller gives the attacker the entire domain's credential material. Detection before the credentials are used for lateral movement is the critical window.

Indicators of Malicious Use

• ⚑Sysmon 10: GrantedAccess 0x1010 (PROCESS_VM_READ | PROCESS_QUERY_INFORMATION) against lsass.exe — the sekurlsa module access pattern
• ⚑Sysmon 10: GrantedAccess 0x1fffff (PROCESS_ALL_ACCESS) against lsass.exe — comsvcs.dll MiniDump or full-access variant
• ⚑Sysmon 7: sekurlsa.dll, wdigest.dll, or kerberos.dll loading into lsass.exe from a path outside System32
• ⚑Sysmon 1: OriginalFileName = 'mimikatz.exe' regardless of the Image path (renamed binary detection)
• ⚑Sysmon 10: CallTrace entries containing unbacked memory (no named DLL) — injected Mimikatz shellcode
• ⚑Sysmon 1: powershell.exe with Invoke-Mimikatz or Invoke-Katz in CommandLine (PowerShell-based variant)

Example Log Entry

// Sysmon Event 10 — Mimikatz sekurlsa::logonpasswords
EventID: 10
SourceImage: C:\Users\attacker\Downloads\svchost.exe
TargetImage: C:\Windows\System32\lsass.exe
GrantedAccess: 0x1010
CallTrace: C:\Windows\SYSTEM32\ntdll.dll|C:\Windows\System32\KERNELBASE.dll|UNKNOWN(0000028B...)

// Sysmon Event 1 — Renamed Mimikatz binary
EventID: 1
Image: C:\Windows\Temp\windowsupdate.exe
OriginalFileName: mimikatz.exe
CommandLine: windowsupdate.exe privilege::debug sekurlsa::logonpasswords
ParentImage: C:\Windows\System32\cmd.exe

Investigation Steps

1. 1.Confirm LSASS access: search Sysmon 10 for TargetImage = lsass.exe with GrantedAccess 0x1010 or 0x1fffff. Identify the SourceImage and its launch chain via Sysmon 1 — was it spawned by cmd.exe, PowerShell, or a delivery document?
2. 2.Check for renamed binary: search Sysmon 1 for OriginalFileName = 'mimikatz.exe' across all hosts. The attacker almost always renames the binary but rarely recompiles it, leaving the PE header intact.
3. 3.Look for credential DLL loads: Sysmon 7 — ImageLoaded = sekurlsa.dll, wdigest.dll, or kerberos.dll loading into lsass.exe with Signed = false or from a non-System32 path.
4. 4.Determine what was extracted: if GrantedAccess = 0x1010 succeeded and the CallTrace is clean, assume all cached credentials on the host are compromised — NTLM hashes and Kerberos tickets for every account that authenticated to this machine.
5. 5.Hunt for lateral movement: pivot to Sysmon 3 for outbound connections from the attacker's process, and to 4624 events for Type 3 (network) logons using NTLM shortly after the Mimikatz timestamp — these are pass-the-hash using captured credentials.
6. 6.Check for dcsync: if the compromised host had network connectivity to a domain controller, search for 4662 events on the DC for DS-Replication-Get-Changes-All (Mimikatz lsadump::dcsync) — this bypasses LSASS entirely and extracts all domain hashes.

Common False Positives

• ◎Security products (CrowdStrike, SentinelOne, Defender for Endpoint) access lsass.exe with similar but distinct access masks — verify the SourceImage is not a known security tool path
• ◎Windows Task Manager (taskmgr.exe) with GrantedAccess 0x1410 is legitimate — it creates process dumps with that mask
• ◎WinDbg and other debuggers may access lsass.exe in development environments — not expected on production servers

Remediation

• ✓Enable RunAsPPL (Protected Process Light) for lsass.exe via registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa — RunAsPPL = 1. Forces Mimikatz to use a vulnerable driver (BYOVD) rather than direct access.
• ✓Enable Windows Defender Credential Guard — moves credential material into a Hyper-V isolated enclave; even a successful LSASS handle open returns no usable data
• ✓Disable WDigest authentication via GPO (HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest — UseLogonCredential = 0) to eliminate plaintext credential caching
• ✓Reset all domain account passwords if a DC was targeted — NTLM hashes are usable for pass-the-hash indefinitely until the password changes
• ✓If krbtgt hash may have been extracted, perform a double krbtgt password reset (reset, wait 10 hours for ticket expiry, reset again) to invalidate all outstanding Golden Tickets

Related Event IDs

Related Detection Guides

Frequently Asked Questions

What makes GrantedAccess 0x1010 such a reliable Mimikatz indicator?

The value 0x1010 is the combination of PROCESS_VM_READ (0x0010) and PROCESS_QUERY_INFORMATION (0x0400) — the minimum rights Mimikatz sekurlsa::logonpasswords needs to read LSASS memory. Mimikatz requests exactly this mask because requesting more would be unnecessary and potentially more detectable. Very few legitimate processes need this specific combination on lsass.exe: security scanners use higher-level API calls, Windows authentication uses different masks, and debuggers typically request more rights. Alert specifically on 0x1010 + TargetImage = lsass.exe + SourceImage not in your security tool whitelist — the false positive rate in production environments is near zero.

Can Mimikatz be detected if it runs entirely in memory without touching disk?

Yes, but the detection point shifts from Sysmon 1 (process creation) to Sysmon 10 (process access). PowerShell-based Mimikatz variants (Invoke-Mimikatz) load the Mimikatz assembly reflectively into PowerShell's memory — no .exe is created. However, the LSASS handle open still happens and Sysmon 10 still fires with GrantedAccess 0x1010 against lsass.exe. The SourceImage will be powershell.exe, which is itself suspicious for LSASS access. Sysmon 7 may also fire if sekurlsa.dll loads reflectively. Combine Sysmon 10 alerting with PowerShell Script Block Logging (Event 4104) to catch the de-obfuscated Invoke-Mimikatz command.

What should I do if I see Mimikatz ran on a domain controller?

Treat it as a full domain compromise and follow the worst-case response: (1) Assume the krbtgt hash is known to the attacker — perform a double krbtgt password reset. (2) Assume all domain account hashes are compromised — prioritize resetting privileged accounts (Domain Admins, service accounts) immediately. (3) Assume all Kerberos tickets in use are potentially forged — force re-authentication across the domain. (4) Review 4662 events on the DC for DS-Replication-Get-Changes-All (dcsync) which would have been run alongside or instead of direct LSASS access. A Mimikatz execution on a DC is not a standard security incident — it is a domain compromise.