How to Detect LSASS Credential Dumping (Mimikatz and Others)

Technique 1: Mimikatz sekurlsa::logonpasswords

Requires: SYSTEM or SeDebugPrivilege
Action: Opens lsass.exe handle with PROCESS_VM_READ access
Sysmon Event 10: SourceImage = mimikatz.exe, TargetImage = lsass.exe
Access mask: 0x1010 (PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION)

Technique 2: ProcDump (legitimate Microsoft tool, frequently abused)

# Attacker command:
procdump.exe -ma lsass.exe C:\Windows\Temp\lsass.dmp

Sysmon Event 10: SourceImage = procdump.exe, TargetImage = lsass.exe
Also: Sysmon Event 11 (FileCreate) for the .dmp file

Technique 3: comsvcs.dll MiniDump (lives-off-the-land, no custom tool)

# No external tools required: uses a built-in Windows DLL
$lsassPID = (Get-Process lsass).Id
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump $lsassPID C:\Windows\Temp\lsass.dmp full

Sysmon Event 10: SourceImage = rundll32.exe, TargetImage = lsass.exe
Sysmon Event 7 (ImageLoad): comsvcs.dll loaded by rundll32.exe

Technique 4: Task Manager (interactive, lower stealth)

Details tab > lsass.exe > right-click > Create dump file
Sysmon Event 10: SourceImage = taskmgr.exe, TargetImage = lsass.exe

Technique 5: Custom process injection / direct syscalls (advanced evasion)

Evades by:
- Not opening a handle to lsass.exe directly (uses kernel handles)
- Using direct syscalls to avoid EDR API hooks
- Dumping via a remote process (another machine reads LSASS over SMB)
Harder to detect: behavioral analysis of the resulting dump file or
correlation with network connections is required

Sysmon Event ID 10 fires when any process opens a handle to another process. Configure Sysmon to log LSASS access:

Sysmon config for LSASS monitoring:

<RuleGroup name="" groupRelation="or">
  <ProcessAccess onmatch="include">
    <!-- Any process accessing LSASS -->
    <TargetImage condition="end with">lsass.exe</TargetImage>
  </ProcessAccess>
</RuleGroup>

<!-- Optionally, exclude known legitimate LSASS accessors to reduce noise -->
<ProcessAccess onmatch="exclude">
  <SourceImage condition="end with">MsMpEng.exe</SourceImage>  <!-- Windows Defender -->
  <SourceImage condition="end with">csrss.exe</SourceImage>
  <SourceImage condition="end with">wininit.exe</SourceImage>
  <SourceImage condition="end with">services.exe</SourceImage>
  <GrantedAccess condition="is">0x1000</GrantedAccess>  <!-- PROCESS_QUERY_LIMITED only -->
</ProcessAccess>

Microsoft Sentinel KQL: LSASS access detection:

SysmonEvent
| where EventID == 10  // ProcessAccess
| where TargetImage endswith "lsass.exe"
| where SourceImage !in (
    "C:\\Windows\\System32\\MsMpEng.exe",
    "C:\\Windows\\System32\\csrss.exe",
    "C:\\Windows\\System32\\wininit.exe",
    "C:\\Windows\\System32\\svchost.exe",
    "C:\\Windows\\System32\\services.exe",
    "C:\\Program Files\\Windows Defender\\MsMpEng.exe"
  )
// Alert specifically on access masks used for memory reading
| where GrantedAccess in~ ("0x1010", "0x1038", "0x40", "0x1410", "0x1fffff")
    or GrantedAccess has "0x10"  // PROCESS_VM_READ bit
| project
    TimeGenerated,
    Computer,
    SourceImage,
    SourceUser,
    TargetImage,
    GrantedAccess,
    CallTrace
| sort by TimeGenerated desc

Splunk SPL: LSASS dump file creation:

(index=sysmon EventCode=11 TargetFilename="*.dmp")
OR (index=sysmon EventCode=10 TargetImage="*lsass*" NOT SourceImage IN ("*MsMpEng*","*csrss*","*wininit*"))
| eval risk=case(
    match(TargetFilename, "lsass"), "CRITICAL",
    EventCode==10 AND match(GrantedAccess, "0x1010|0x1fffff"), "HIGH",
    true(), "MEDIUM"
  )
| table _time, ComputerName, SourceImage, TargetImage, TargetFilename, GrantedAccess, risk
| sort -_time

Detection alerts you after the fact. Mitigation prevents credential extraction even when LSASS is accessed.

Credential Guard (most effective mitigation):

Credential Guard stores NTLM hashes and Kerberos tickets in a Hyper-V isolated container (Virtual Secure Mode). Even with SYSTEM access, tools like Mimikatz cannot extract these credentials because they never appear in the regular OS memory space.

Requirements: Windows 10/11 Enterprise or Education, Server 2016+, UEFI Secure Boot, 64-bit CPU with virtualization extensions.

# Enable via Group Policy:
# Computer Configuration > Administrative Templates >
# System > Device Guard >
# "Turn On Virtualization Based Security" = Enabled
# > Credential Guard Configuration = Enabled with UEFI lock

# Or via registry:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v RequirePlatformSecurityFeatures /t REG_DWORD /d 3 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 1 /f

# Verify Credential Guard is running
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
# 1 = VSM, 2 = Credential Guard: should see 2 in the output

LSASS Protected Process Light (PPL):

PPL marks LSASS as a protected process: standard user-mode tools cannot open a debug handle to it:

# Enable via registry (reboot required)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f

# Or via Group Policy:
# Computer Configuration > Administrative Templates >
# System > Local Security Authority >
# "Configure LSASS to run as a protected process" = Enabled

Note: PPL blocks many LSASS dump techniques but can be bypassed by kernel-level rootkits. Credential Guard is more robust.

Disable WDigest authentication (prevents plaintext password caching):

# WDigest is disabled by default in Windows 8.1 and Server 2012 R2+
# Verify it is disabled:
(Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest).UseLogonCredential
# Should return 0 or not exist

# If it is 1 (enabled), disable it:
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest \
  -Name UseLogonCredential -Value 0