Detecting Credential Dumping via LSASS Memory Forensics

In the lifecycle of a sophisticated cyberattack, lateral movement is often the most critical phase. To move from a compromised workstation to a Domain Controller, an adversary requires identity. The most efficient way to acquire these identities is through the extraction of secrets from the Local Security Authority Subsystem Service (LSASS).

For security practitioners, detecting this activity is a high-stakes game of cat and mouse. Attackers are moving away from noisy,-signature-based tools like Mimikatz toward "Living off the Land" (LotL) techniques that leverage legitimate Windows binaries to perform memory dumps. To defend against this, we must move beyond simple process monitoring and dive into the forensics of memory access and handle manipulation.

The Anatomy of the Attack: Why LSASS?

LSASS is a critical Windows component responsible for enforcing security policies, handling user logins, and managing access tokens. Crucially, it caches various forms of credentials in its memory space to facilitate Single Sign-On (SSO) experiences. Depending on the configuration and legacy protocols enabled (such as WDigest or NTLM), this memory can contain:

• NTLM hashes.
• Kerberos Ticket Granting Tickets (TGTs) and Service Tickets (TGSs).
• In some vulnerable configurations, plaintext passwords.

Credential dumping is the process of reading the virtual memory space of `lsass.exe` and writing it to a file. Once an attacker has a `.dmp` file, they can perform offline analysis on their own infrastructure, bypassing any EDR (Endpoint Detection and Response) presence on the victim machine.

The Mechanics of Memory Extraction

To dump LSASS, an attacker must first obtain a handle to the LSASS process with sufficient privileges. This typically involves the `OpenProcess` API. The level of access requested is the primary indicator of malicious intent.

The `MiniDumpWriteDump` Technique

The most common method involves using the `MiniDumpWriteDump` function from `dbghelp.dll`. This is a legitimate API used by developers for debugging, but it is also the engine behind tools like `procdump.exe` and the `comsvcs.dll` exploit.

A common, "stealthy" execution pattern looks like this:

```cmd

rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump C:\temp\lsass.dmp full

```

In this scenario, the attacker isn't running a known malware binary; they are using a trusted Windows DLL to perform the dump. This bypasses many basic process-name-based detection rules.

Detection Strategies: Beyond the Process Name

Effective detection requires monitoring the behavior of the interaction between processes, rather than the identity of the process itself.

1. Monitoring Process Access (Sysmon Event ID 10)

The most robust way to detect LSASS dumping is through Sysmon Event ID 10: `ProcessAccess`. This event triggers whenever a process opens a handle to another process.

When analyzing these events, focus on the `GrantedAccess` field. An attacker needs specific access rights to read the memory of LSASS. Look for the following hex patterns in the `GrantedAccess` mask:

• `0x1410`: (PROCESS_QUERY_INFORMATION | PROCESS_VM_READ)
• `0x1010`: (PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION)
• `0x1fffff`: (PROCESS_ALL_ACCESS)

Detection Logic:

A high-fidelity alert can be constructed by searching for any process (excluding known-good security agents like `MsMpEng.exe` or `SentinelOne.exe`) that requests `0x1410` or higher against the `lsass.exe` target.

2. File System Artifacts and File Creation

The output of a dump is a file. Monitoring for the creation of large files in unusual directories is a vital secondary layer.

• Target Directories: `C:\Windows\Temp\`, `C:\Users\Public\`, and `%AppData%`.
• File Extensions: `.dmp`, `.tmp`, or files with no extension but large sizes (LSASS dumps can be hundreds of megabytes).
• Sysmon Event ID 11: Monitor for `FileCreate` events where the target process is `rundll32.exe` or `procdump.exe` and the file path is suspicious.

3. Memory Scanning with YARA

For proactive hunting, you can use YARA rules to scan the memory of running processes. While scanning the entirety of `lsass.exe` is computationally expensive, scanning the memory of newly created processes that have recently interacted with LSASS can reveal the presence of credential-extracting strings or patterns associated with known tools.

Operational Considerations and Challenges

Implementing these detections is not without friction. A "detect everything" approach will inevitably lead to alert fatigue.

The False Positive Problem

Security software is the primary source of noise. Antivirus, EDR, and even certain Windows debugging components legitimately access LS

Conclusion

As shown across "The Anatomy of the Attack: Why LSASS?", "The Mechanics of Memory Extraction", "Detection Strategies: Beyond the Process Name", a secure implementation for detecting credential dumping via lsass memory forensics depends on execution discipline as much as design.

The practical hardening path is to enforce strict token/claim validation and replay resistance, deterministic identity policy evaluation with deny-by-default semantics, and host hardening baselines with tamper-resistant telemetry. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track false-allow rate and time-to-revoke privileged access and time from suspicious execution chain to host containment, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.