Detecting LSASS Memory Dumping via Access Mask Analysis

Credential dumping targeting the Local Security Authority Subsystem Service (LSASS) remains one of the most reliable techniques for attackers to harvest plaintext passwords, Kerberos tickets, and NTLM hashes. While attackers continuously iterate on execution methods—shifting from standard Win32 API calls to direct syscalls and unhooked NT APIs—the underlying OS primitive rarely changes: a handle must be opened to lsass.exe with sufficient memory read permissions.

Instead of relying solely on binary signatures or command-line parameters, detection engineers can build high-confidence alerts by auditing handle creation events and analyzing the specific bitmasks requested against LSASS.

Understanding Process Access Masks

When a process calls OpenProcess or NtOpenProcess targeting lsass.exe, the kernel evaluates the requested permissions and records the result. In Sysmon, these actions generate Event ID 10 (ProcessAccess), which logs the process requesting access (SourceImage), the target process (TargetImage), the granted permissions (GrantedAccess), and the execution stack (CallTrace).

The GrantedAccess field is represented as a hexadecimal bitmask corresponding to specific process access rights:

• 0x0010 (PROCESS_VM_READ): Required to read memory from the target process space.
• 0x0008 (PROCESS_VM_OPERATION): Required to perform operations on the virtual memory of the process.
• 0x0020 (PROCESS_VM_WRITE): Required to write memory in the target process.
• 0x0400 (PROCESS_QUERY_INFORMATION): Required to retrieve process token and status details.
• 0x1000 (PROCESS_QUERY_LIMITED_INFORMATION): Required to retrieve a subset of process information.
• 0x1F0FFF (PROCESS_ALL_ACCESS): Full access rights to the process.

When dumping LSASS memory using functions like MiniDumpWriteDump, an attacker requires at minimum PROCESS_VM_READ (0x0010) combined with query rights. Common access masks generated by offensive tools include 0x1010 (PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION), 0x1410, 0x143A, and the broad 0x1F0FFF mask.

Filtering Signal from Noise

A baseline Windows installation generates numerous ProcessAccess events against lsass.exe daily. Legitimate system binaries like svchost.exe, csrss.exe, and identity management services routinely inspect LSASS. To isolate malicious access without flooding the alert queue, your detection strategy must evaluate three criteria: target process, access mask, and call stack context.

First, filter strictly for TargetImage ending in \lsass.exe. Next, flag handles where GrantedAccess includes sensitive read operations like 0x0010 or matches high-risk masks (0x1010, 0x1410, 0x1438, 0x143A, 0x1F0FFF).

To strip away benign system baseline activity, inspect the CallTrace field. In legitimate Windows operations, the call trace resolves cleanly through signed, disk-backed system DLLs such as ntdll.dll, kernelbase.dll, or sechost.dll. Offensive payloads utilizing reflective DLL injection, shellcode, or direct syscalls frequently leave unbacked memory references in the CallTrace (manifesting as calls originating from unmapped memory space, often flagged with UNKNOWN modules).

Implementing Detection Rules

In SIEM or log management platforms, a practical query isolates non-standard binaries requesting sensitive access masks while highlighting anomalous call traces. Below is a structured KQL detection query for hunting LSASS access anomalies:

Sysmon_EventID_10
| where TargetImage endswith @"\lsass.exe"
| where GrantedAccess in ("0x1010", "0x1410", "0x1438", "0x143a", "0x1f0fff")
| where not(SourceImage endswith @"\svchost.exe" or SourceImage endswith @"\csrss.exe")
| extend IsUnbacked = iff(CallTrace contains "UNKNOWN", true, false)
| project TimeGenerated, Hostname, SourceImage, GrantedAccess, CallTrace, IsUnbacked

Tuning and Baseline Maintenance

Initial deployment will likely surface legitimate enterprise utilities, such as remote management agents, password managers, or security drivers. Rather than creating broad exclusions for process paths, refine your baseline suppressions by combining SourceImage, GrantedAccess, and specific CallTrace module sequences.

If an attacker attempts to execute a known administrative binary (such as procdump.exe), the process name may appear legitimate, but anomalous invocation patterns or memory call traces will expose the activity. Monitoring handle access masks provides a resilient detection layer that holds up even when attackers rename binaries or obfuscate command-line parameters.

Photo by Stephen Dawson on Unsplash.