💡 LSA Dumps: The EDR Blind Spot

Abstract

This analysis investigates the pervasive security gap associated with endpoint detection and response (EDR) systems failing to reliably detect credential harvesting via LSASS memory dumping. We examine how simple defense evasion techniques, specifically leveraging native binaries and manipulating execution context, bypass common behavioral models and API hooks designed to catch tools like Mimikatz or conventional ProcDump usage. This article provides technical findings, actionable threat hunting queries, and mitigation strategies essential for hardening critical assets against sophisticated post-exploitation activity (MITRE T1003).

High-Retention Hook

A few months ago, I was certain my custom EDR rule set was bulletproof against credential dumping. We had robust signatures, API hook monitoring on MiniDumpWriteDump, and strict parent-child process checks. Then, during a simple internal red team simulation, a colleague executed a subtly renamed ProcDump binary from a deeply nested, non-standard path targeting LSASS. It worked silently. Zero alerts. Zero logs that triggered our high-fidelity rules. The realization was immediate: we were hunting the tool (Mimikatz), not the behavior (accessing critical memory). The cat-and-mouse game demands we shift focus from execution signatures to memory access context.

Research Context

Credential harvesting is the foundation of lateral movement. Since Windows Vista, LSASS (Local Security Authority Subsystem Service) has been the primary target, holding NTLM hashes, Kerberos tickets, and plaintext passwords (depending on configuration). The industry’s defensive response led to features like Protected Process Light (PPL) and specific API monitoring by EDR vendors.

However, attackers are not using Mimikatz anymore as their first resort; that ship sailed in 2017. Modern threat actors, from financially motivated groups to state-sponsored operations, prioritize Living-Off-The-Land (LOTL) techniques. Credential dumping is now an established sub-technique under MITRE ATT&CK T1003, and the evasion focuses on abusing trusted processes or disguising the memory access request itself.

Problem Statement

The core security gap lies in EDR systems relying too heavily on two brittle indicators:

1. Known Signatures/Hashes: Easily bypassed by renaming, packing, or custom compilations.
2. Specific API Hooking: Relying on intercepting the MiniDumpWriteDump call from specific, suspicious processes.

The failure occurs when an attacker uses a legitimate Windows debugger (or a tool like ProcDump which operates similarly) from a seemingly benign location with sufficient privileges to access the LSASS process memory. Since the memory access request is often initiated by a clean, signed binary, the EDR interprets the behavior as permissible debugging activity rather than malicious data exfiltration. The EDR sees Process A dumping Process B via a legitimate function call; it struggles to determine the intent without deep context or expensive behavior analysis.

Methodology or Investigation Process

To investigate this blind spot, I established a lab environment with a standard Windows 10 client, configured to represent a typical enterprise endpoint running standard security configurations (simulating EDR with behavioral logging via Sysmon and PowerShell tracing).

Setup Steps:

1. Target: LSASS process on the Windows 10 VM.
2. Tool: ProcDump (Sysinternals, signed binary).
3. Evasion: Rename procdump.exe to cleanup.exe and place it in a non-standard, but plausible temporary directory like C:\Users\Public\Documents\Temp.
4. Execution: Run the renamed tool with debugger flags to generate a dump file: .\cleanup.exe -accepteula -ma lsass.exe lsass.dmp.

Analysis Focus: We analyzed the logs generated by the environment, focusing specifically on Sysmon Event ID 10 (Process Access) and Event ID 1 (Process Creation). We observed whether the EDR or logging system flagged the process access with the required permissions (0x1000, 0x1400, or similar PROCESS_VM_READ flags) targeting the LSASS process ID.

Findings and Technical Analysis

Our tests confirmed that the simple renaming and execution from an unusual path effectively evaded basic file hashing and signature checks. More critically, the behavioral detection often faltered on the Process Access event.

Key Technical Observations:

1. Process Access Rights: Successful credential dumping requires the accessing process to open a handle to LSASS with specific rights, primarily PROCESS_QUERY_INFORMATION and PROCESS_VM_READ. Even if the EDR doesn’t flag the cleanup.exe creation, it must flag the attempt by that process to open LSASS memory.
2. Sysmon Blindness (Default Configuration): Default Sysmon configurations often do not log Process Access (Event ID 10) globally due to volume. Unless specifically configured to monitor LSASS, this critical interaction is missed.
3. The Context Trap: If the execution context of the renamed binary is unusual (e.g., spawned by a generic shell or script runner), EDRs might raise a low-severity alert. But they often miss high-fidelity alerts because the dumping function is called correctly by a legitimate binary. The detection focuses on the payload, not the pipeline.

Real-World Context: Advanced threat actors like the ones behind the post-exploitation phase of the LockBit 3.0 campaigns often use custom, obfuscated dumpers or legitimate administrator tools to perform this exact action. They rely on the fact that SOC analysts often tune out low-volume, generic 'suspicious file execution' alerts, expecting a high-fidelity 'Mimikatz detected' alert which never comes.

Risk and Impact Assessment

The failure to detect LSASS dumping is a critical indicator of defense collapse. Once successful, the attacker gains high-value domain credentials, enabling immediate lateral movement, privilege escalation, and domain dominance. This technique transforms a low-level compromise into a network-wide incident.

Case Study Relevance: Following the devastating SolarWinds supply chain attack, sophisticated actors utilized techniques that minimized forensic footprint, including memory-only credential access, often avoiding disk-based Mimikatz usage. This evasion allowed them to maintain persistence and navigate the victim network undetected for extended periods, highlighting the criticality of monitoring LSASS access, not just tool signatures.

Mitigation and Defensive Strategies

Defending against this behavior requires shifting from signature-based detection to deep behavioral and access control auditing.

1. Enable LSA Protection / PPL: Enabling Protected Process Light (PPL) for LSASS significantly raises the bar. Only signed Windows code or specific security services can open a handle to LSASS. While not unassailable, this blocks most user-level dumpers (including ProcDump) unless the attacker finds a kernel-level exploit or bypass.
2. Implement Granular Auditing (Sysmon/EDR): Mandate auditing of Process Access (Sysmon Event ID 10) specifically targeting the LSASS process. Focus on filtering for GrantedAccess values that include 0x1400 (PROCESS_VM_READ) or 0x1000 (PROCESS_QUERY_INFORMATION) when the requesting process is not a known system service (e.g., Task Manager, Dump-related diagnostics).
3. Harden ACLs (Advanced): Consider applying System Access Control Lists (SACLs) to the LSASS process itself. This requires careful implementation but allows monitoring for specific process access attempts that violate expected behavior, independent of the EDR vendor’s internal logic.
4. Threat Hunting Query Focus: Hunt for any new executable (.exe, .dll) created in temporary, user, or public directories that subsequently attempts to open a handle to LSASS within seconds of execution. This temporal correlation is a strong indicator of malicious intent, even if the binary itself is benign.

Researcher Reflection

The security industry, including myself, often makes the mistake of preparing for the last war. We spend resources perfecting detection logic for Mimikatz, while attackers move on to abusing built-in operating system features. If the attacker can rename a signed binary, execute it in a forgotten path, and use it to access the gold mine, our multi-million dollar EDR stack often fails. We must prioritize monitoring what the attacker accesses (LSASS memory) over what the attacker runs (a specific binary name). Credential dumping evasion is a game of context and privilege control.

Conclusion

EDR solutions are essential but are not a panacea against sophisticated LSASS credential dumping. Evasion through renaming and leveraging benign tools highlights a persistent blind spot when detection relies on weak indicators. Robust security requires granular Process Access auditing, enforcing PPL protection where possible, and continuously refining threat hunting queries to focus on unauthorized memory access to critical processes (T1003) rather than outdated signatures.

Discussion Question

Beyond PPL, what are the most effective, scalable behavioral rules you’ve implemented in your SIEM or EDR platform to detect LSASS memory access attempts by LOTL binaries without generating excessive false positives?

---

Written by - Harsh Kanojia

LinkedIn - https://www.linkedin.com/in/harsh-kanojia369/

GitHub - https://github.com/harsh-hak

Personal Portfolio - https://harsh-hak.github.io/

Community - https://forms.gle/xsLyYgHzMiYsp8zx6