Credential Dumping from LSASS: What the Logs Actually Show

Guides on LSASS credential dumping usually focus on the attacker tooling. This one focuses on what you actually see in Windows event logs and Sysmon telemetry when it happens in a monitored environment, based on controlled testing across all common techniques on Windows 10 22H2 with Sysmon 15.

Why LSASS is targeted

LSASS (Local Security Authority Subsystem Service) holds plaintext credentials, NTLM hashes, and Kerberos tickets for every authenticated user session on the system. Dumping it provides immediate access to every credential currently cached on that machine. It is one of the highest-value actions an attacker can take after gaining code execution, and it is attempted in nearly every significant intrusion.

Lab test setup

// Sysmon configuration for LSASS monitoring
// Add this to your Sysmon config to catch ALL LSASS access

<ProcessAccess onmatch="include">
  <TargetImage condition="is">C:\Windows\System32\lsass.exe</TargetImage>
</ProcessAccess>
<ProcessAccess onmatch="exclude">
  // Known legitimate LSASS accessors to filter as baseline
  <SourceImage condition="is">C:\Windows\System32\werfault.exe</SourceImage>
  <SourceImage condition="is">C:\Windows\System32\WerFaultSecure.exe</SourceImage>
  <SourceImage condition="is">C:\Windows\System32\csrss.exe</SourceImage>
</ProcessAccess>

Technique 1: ProcDump

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

// What Sysmon sees - Event ID 10:
EventID:        10
UtcTime:        2024-04-02 22:14:33.441
SourceProcessGUID: {a1b2c3d4...}
SourceImage:    C:\Users\attacker\Desktop\procdump.exe
TargetImage:    C:\Windows\System32\lsass.exe
GrantedAccess:  0x1fffff
CallTrace:      C:\Windows\SYSTEM32\ntdll.dll+9f0d4|C:\Windows\SYSTEM32\KERNELBASE.dll+27bc2|C:\Users\attacker\Desktop\procdump.exe+12a34

// What Sysmon sees - Event ID 11 (file creation of the dump):
EventID:        11
TargetFilename: C:\Windows\Temp\lsass.dmp
CreationUtcTime: 2024-04-02 22:14:34.112
Image:          C:\Users\attacker\Desktop\procdump.exe

The access mask 0x1fffff is PROCESS_ALL_ACCESS. No legitimate tool needs all access rights to LSASS. The Event ID 11 tells you where the credential dump was staged for exfiltration.

Technique 2: comsvcs.dll via rundll32

// Attacker command (uses built-in Windows DLL, no additional tools needed):
rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump [LSASS_PID] C:\Windows\Temp\out.dmp full

// What Sysmon sees - Event ID 10:
SourceImage:    C:\Windows\System32\rundll32.exe
TargetImage:    C:\Windows\System32\lsass.exe
GrantedAccess:  0x1410

// 0x1410 breakdown:
// PROCESS_QUERY_LIMITED_INFORMATION = 0x1000
// PROCESS_VM_READ                   = 0x0010
// PROCESS_DUP_HANDLE                = 0x0040
// This is the minimum access needed for a minidump
// It appears consistently across non-ProcDump techniques

Technique 3: Task Manager

// Built-in: Right-click lsass.exe in Task Manager, Create dump file
// This is legitimate admin activity but generates the same Sysmon events

// What Sysmon sees - Event ID 10:
SourceImage:    C:\Windows\System32\taskmgr.exe
TargetImage:    C:\Windows\System32\lsass.exe
GrantedAccess:  0x1fffff

// Add taskmgr.exe to your filter for this specific access mask
// to avoid false positives from legitimate IT admin activity

Technique 4: Mimikatz sekurlsa::logonpasswords

// Attacker command:
// privilege::debug
// sekurlsa::logonpasswords

// What Sysmon sees - Event ID 10:
SourceImage:    C:\Users\attacker\mimikatz.exe
TargetImage:    C:\Windows\System32\lsass.exe
GrantedAccess:  0x1010

// 0x1010 breakdown:
// PROCESS_VM_READ                    = 0x0010
// PROCESS_QUERY_LIMITED_INFORMATION  = 0x1000
// This is the Mimikatz default access mask
// Appears consistently across Mimikatz variants regardless of packing

Detection rule covering all variants

// Sigma rule for LSASS credential dumping
title: LSASS Memory Access for Credential Dumping
id: 32d0d3e2-e58d-4d41-a703-4b606902d533
status: stable
description: Detects process access to LSASS memory with suspicious access masks
references:
    - https://attack.mitre.org/techniques/T1003/001/
logsource:
    product: windows
    category: process_access
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
            - '0x1fffff'
            - '0x1410'
            - '0x1010'
            - '0x1038'
            - '0x40'
    filter_legit_av:
        SourceImage|startswith:
            - 'C:\Program Files\Windows Defender\'
            - 'C:\ProgramData\Microsoft\Windows Defender\'
    filter_legit_system:
        SourceImage|startswith:
            - 'C:\Windows\System32\werfault.exe'
            - 'C:\Windows\System32\WerFaultSecure.exe'
    condition: selection and not 1 of filter_legit_*
falsepositives:
    - EDR products (add your specific EDR to the filter)
    - Backup software (add to filter)
    - Task Manager (add C:\Windows\System32\taskmgr.exe to filter)
level: high

// Convert to Splunk SPL:
// index=sysmon EventCode=10 TargetImage="*\lsass.exe"
// (GrantedAccess="0x1fffff" OR GrantedAccess="0x1410" OR GrantedAccess="0x1010")
// NOT SourceImage IN ("C:\Windows\System32\werfault.exe", "C:\Program Files\Windows Defender\*")

The direct syscall blind spot

Tools like Mimikatz variants using SysWhispers, Hell’s Gate, or custom direct syscall implementations bypass userland hooks. Sysmon Event ID 10 never fires because the hook DLL never executes. Only the Microsoft-Windows-Threat-Intelligence ETWTI provider captures these operations at the kernel level.

// Test whether your environment catches direct syscall credential dumping
// Using NanoDump as a test tool (direct syscall LSASS dumper)
// https://github.com/fortra/nanodump

// After running NanoDump, check:
// 1. Did Sysmon Event ID 10 fire? (It should not if direct syscalls are used)
// 2. Did your EDR alert? (Only if it has kernel driver coverage)
// 3. Did Windows Defender alert? (Tests built-in coverage)

// If nothing fires, you have a coverage gap for direct syscall techniques
// The fix is ensuring your EDR has an active kernel driver

// Verify kernel driver presence for your security product
Get-WmiObject Win32_SystemDriver | Where-Object {$_.State -eq "Running"} |
    Select-Object Name, PathName |
    Where-Object {$_.PathName -match "defender|crowdstrike|sentinelone|cylance|edr_name"}

Monitoring for .dmp file creation

// Sysmon Event ID 11 catches dump files being created
// Alert on .dmp files created outside of known crash dump directories

// Sigma rule for suspicious dump file creation
title: Potential LSASS Dump File Creation
logsource:
    product: windows
    category: file_event
detection:
    selection:
        TargetFilename|endswith: '.dmp'
    filter_legit:
        TargetFilename|startswith:
            - 'C:\Windows\MEMORY.DMP'
            - 'C:\Windows\Minidump\'
            - 'C:\ProgramData\Microsoft\Windows\WER\'
    condition: selection and not filter_legit
falsepositives:
    - Application crash dumps from legitimate software
    - Backup software creating system images
level: medium