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
\nSysmon 15 and Windows 10 22H2.<\/p>\n
Sysmon config used the SwiftOnSecurity template with one addition \u2014 Event ID 10 (ProcessAccess) configured to log all access to lsass.exe regardless of source. The relevant section:<\/p>\n
<ProcessAccess onmatch=\"include\">\n <TargetImage condition=\"is\">C:\\Windows\\System32\\lsass.exe<\/TargetImage>\n<\/ProcessAccess><\/pre>\nTechnique 1: ProcDump<\/h3>\n
Running
procdump.exe -ma lsass.exe lsass.dmp<\/code> from an admin prompt generates two Sysmon events in sequence. First, Event ID 10:<\/p>\nEventID: 10\nUtcTime: 2024-04-01 22:14:33.441\nSourceImage: C:\\Users\\analyst\\Desktop\\procdump.exe\nTargetImage: C:\\Windows\\System32\\lsass.exe\nGrantedAccess: 0x1fffff\nCallTrace: C:\\Windows\\SYSTEM32\\ntdll.dll+9f0d4|\n C:\\Windows\\SYSTEM32\\ntdll.dll+1e8e5|\n C:\\Windows\\system32\\KERNELBASE.dll+27bc2|\n C:\\Users\\analyst\\Desktop\\procdump.exe+1234a<\/pre>\nNote the access mask
0x1fffff<\/code> \u2014 PROCESS_ALL_ACCESS. Legitimate processes accessing LSASS (AV, EDR) typically use far more restricted masks. Then Event ID 11 for the dump file creation:<\/p>\nEventID: 11\nTargetFilename: C:\\Users\\analyst\\Desktop\\lsass.dmp\nCreationUtcTime: 2024-04-01 22:14:34.112<\/pre>\nTechnique 2: comsvcs.dll via rundll32<\/h3>\n
The command
rundll32.exe C:\\Windows\\System32\\comsvcs.dll MiniDump <PID> C:\\Windows\\Temp\\out.dmp full<\/code> generates the same Event ID 10, but now SourceImage is rundll32.exe \u2014 a signed Microsoft binary. The GrantedAccess mask
\nchanges to0x1410<\/code>:<\/p>\nSourceImage: C:\\Windows\\System32\\rundll32.exe\nTargetImage: C:\\Windows\\System32\\lsass.exe\nGrantedAccess: 0x1410<\/pre>\nThe mask
0x1410<\/code> 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
\nnon-ProcDump techniques.<\/p>\nTechnique 3: Task Manager<\/h3>\n
Right-clicking lsass.exe in Task Manager and selecting “Create dump file” produces access mask
0x1fffff<\/code> with SourceImage as Taskmgr.exe. Worth knowing so you can build an exclusion \u2014 this will fire the same rule as ProcDump.<\/p>\nDetection rule logic<\/h3>\n
A Sigma rule covering the most common patterns:<\/p>\n
title: LSASS Memory Access\nstatus: stable\nlogsource:\n product: windows\n category: process_access\ndetection:\n selection:\n TargetImage|endswith: \\lsass.exe\n GrantedAccess|contains:\n - \"0x1fffff\"\n - \"0x1410\"\n - \"0x1010\"\n - \"0x40\"\n filter_legit:\n SourceImage|startswith:\n - \"C:\\Program Files\\Windows Defender\\\"\n - \"C:\\ProgramData\\Microsoft\\Windows Defender\\\"\n condition: selection and not filter_legit\nfalsepositives:\n - AV and EDR products\n - Task Manager (add Taskmgr.exe to filter)\nlevel: high<\/pre>\nWhat you will not catch without kernel telemetry<\/h3>\n
Direct syscall techniques \u2014 tools that use NtReadVirtualMemory via a hand-written syscall stub rather than going through kernel32.dll \u2014 will not appear in Sysmon Event ID 10 because the hook never fires. The kernel still processes the operation,
\nso 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.<\/p>\n","protected":false},"excerpt":{"rendered":"Most guides on LSASS credential dumping focus on the attacker
\nside. This one focuses on what you actually see in the event logs when it happens in your environment.<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-182","post","type-post","status-publish","format-standard","hentry","category-dfir"],"_links":{"self":[{"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/posts\/182","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/comments?post=182"}],"version-history":[{"count":2,"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/posts\/182\/revisions"}],"predecessor-version":[{"id":224,"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/posts\/182\/revisions\/224"}],"wp:attachment":[{"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/media?parent=182"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/categories?post=182"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/tags?post=182"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}