When LSASS gets dumped in a real environment the first question is always the same: what did the logs actually capture? Most write-ups stop at the attacker tooling. This one works from the defender side using a controlled test environment with
Sysmon 15 and Windows 10 22H2.
Test setup
Sysmon config used the SwiftOnSecurity template with one addition — Event ID 10 (ProcessAccess) configured to log all access to lsass.exe regardless of source. The relevant section:
<ProcessAccess onmatch="include"> <TargetImage condition="is">C:\Windows\System32\lsass.exe</TargetImage> </ProcessAccess>
Technique 1: ProcDump
Running procdump.exe -ma lsass.exe lsass.dmp from an admin prompt generates two Sysmon events in sequence. First, Event ID 10:
EventID: 10
UtcTime: 2024-04-01 22:14:33.441
SourceImage: C:\Users\analyst\Desktop\procdump.exe
TargetImage: C:\Windows\System32\lsass.exe
GrantedAccess: 0x1fffff
CallTrace: C:\Windows\SYSTEM32\ntdll.dll+9f0d4|
C:\Windows\SYSTEM32\ntdll.dll+1e8e5|
C:\Windows\system32\KERNELBASE.dll+27bc2|
C:\Users\analyst\Desktop\procdump.exe+1234a
Note the access mask 0x1fffff — PROCESS_ALL_ACCESS. Legitimate processes accessing LSASS (AV, EDR) typically use far more restricted masks. Then Event ID 11 for the dump file creation:
EventID: 11 TargetFilename: C:\Users\analyst\Desktop\lsass.dmp CreationUtcTime: 2024-04-01 22:14:34.112
Technique 2: comsvcs.dll via rundll32
The command rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump <PID> C:\Windows\Temp\out.dmp full generates the same Event ID 10, but now SourceImage is rundll32.exe — a signed Microsoft binary. The GrantedAccess mask
changes to 0x1410:
SourceImage: C:\Windows\System32\rundll32.exe TargetImage: C:\Windows\System32\lsass.exe GrantedAccess: 0x1410
The mask 0x1410 breaks down as PROCESS_QUERY_LIMITED_INFORMATION (0x1000) + PROCESS_VM_READ (0x0010) + PROCESS_DUP_HANDLE (0x0040). This is the minimum required for a minidump and is the value that appears most consistently across
non-ProcDump techniques.
Technique 3: Task Manager
Right-clicking lsass.exe in Task Manager and selecting “Create dump file” produces access mask 0x1fffff with SourceImage as Taskmgr.exe. Worth knowing so you can build an exclusion — this will fire the same rule as ProcDump.
Detection rule logic
A Sigma rule covering the most common patterns:
title: LSASS Memory Access
status: stable
logsource:
product: windows
category: process_access
detection:
selection:
TargetImage|endswith: \lsass.exe
GrantedAccess|contains:
- "0x1fffff"
- "0x1410"
- "0x1010"
- "0x40"
filter_legit:
SourceImage|startswith:
- "C:\Program Files\Windows Defender\"
- "C:\ProgramData\Microsoft\Windows Defender\"
condition: selection and not filter_legit
falsepositives:
- AV and EDR products
- Task Manager (add Taskmgr.exe to filter)
level: high
What you will not catch without kernel telemetry
Direct syscall techniques — tools that use NtReadVirtualMemory via a hand-written syscall stub rather than going through kernel32.dll — will not appear in Sysmon Event ID 10 because the hook never fires. The kernel still processes the operation,
so ETW-based kernel telemetry (Microsoft-Windows-Threat-Intelligence provider) will catch it. This is the provider that EDR kernel drivers tap into. If your coverage is Sysmon-only, direct syscall dumps are a blind spot.