💡 LSA Dumps: The EDR Blind Spot

Source: Dev.to

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 bullet‑proof against credential dumping. We had robust signatures, API‑hook monitoring on MiniDumpWriteDump, and strict parent‑child process checks.

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 no longer using Mimikatz as their first resort; that ship sailed in 2017. Modern threat actors—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 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:

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. Because 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 intent without deep context or expensive behavior analysis.

---

Methodology / Investigation Process

To investigate this blind spot, I built 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, plausible temporary directory, e.g., 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 examined the logs generated by the environment, focusing specifically on:

• Sysmon Event ID 10 – Process Access
• Sysmon Event ID 1 – Process Creation

The goal was to see 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 simple renaming and execution from an unusual path effectively evaded basic file‑hashing and signature checks. More critically, behavioral detection often faltered on the Process Access event.

Key Technical Observations

Real‑World Context – Advanced threat actors (e.g., those 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 tend to tune out low‑volume, generic “suspicious file execution” alerts, expecting a high‑fidelity “Mimikatz detected” alert that never arrives.

---

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, credential‑theft‑as‑a‑service, and persistence escalation across the enterprise.

---

End of cleaned markdown segment.

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 used techniques that minimized their forensic footprint, including memory‑only credential access and 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.

• Enable LSA Protection / PPL
  Enable Protected Process Light (PPL) for LSASS. This raises the bar significantly—only signed Windows code or specific security services can open a handle to LSASS. While not unassailable, it blocks most user‑level dumpers (including ProcDump) unless the attacker has a kernel‑level exploit or bypass.

• Implement Granular Auditing (Sysmon/EDR)
  Mandate auditing of Process Access (Sysmon Event ID 10) specifically targeting the LSASS process. Filter 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).

• 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.

• 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 appears 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 an 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:

1. Granular Process Access auditing.
2. Enforcing PPL protection where possible.
3. 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:
• GitHub:
• Personal Portfolio:
• Community: