Inside LSASS Dumping: A Defender’s Guide to Protecting Windows Credentials

 What is LSASS and “LSASS dumping”?

LSASS (Local Security Authority Subsystem Service) is the Windows process that enforces local security policy and manages authentication. After a user logs on, credential material (e.g., NTLM password hashes, Kerberos tickets, and, in some configurations, plaintext) resides in LSASS memory for the session. LSASS dumping is the act of extracting that in‑memory credential material (typically after an attacker already has admin/SYSTEM privileges) to facilitate account impersonation, privilege escalation, and lateral movement. 

Why attackers target LSASS

• High payoff: A single host may contain credentials for privileged users (e.g., domain admins), enabling rapid lateral movement and full domain compromise. 
• Pervasive technique: LSASS dumping is among the most prevalent credential‑access techniques seen across APT and cybercrime operations, including ransomware campaigns.
• Windows internals: Because LSASS legitimately stores authentication artifacts during normal operation, an attacker with sufficient privileges can attempt to extract them unless the host is hardened.

Common approaches (high‑level only)

Attackers can attempt in‑memory access to LSASS or create memory dumps for offline parsing with credential‑theft utilities. Variants include abusing signed/LOLBAS binaries (living‑off‑the‑land), leveraging error‑reporting paths, or deploying custom tooling to evade EDR. (Deliberately omitting command‑level detail.)

Operational prerequisites for an attacker

• Local admin/SYSTEM privileges are typically required to read LSASS memory, so LSASS dumping is usually a post‑compromise technique.
• Misconfigurations (e.g., legacy WDigest settings that allow plaintext caching) can worsen the impact if present.

Detection: what to watch for

Aim to detect both attempted access to LSASS and the downstream use of stolen material.

1. Process and handle‑access telemetry

• Alerts when non‑system processes open LSASS with suspicious access rights (e.g., memory‑read/duplicate handle). Modern EDRs and Sysmon telemetry are key here.

2. Anomalous child processes / LOLBAS abuse

• Signed Windows binaries or admin tools unexpectedly interacting with LSASS (e.g., “living‑off‑the‑land” patterns).

3. Dump‑artifact forensics

• Appearance of crash/dump files in temp or system folders, or unusual Windows Error Reporting activity tied to LSASS.

4. Post‑dump behavior

• Sudden spikes in Kerberos ticket requests, pass‑the‑hash attempts, or lateral RDP/SMB authentication using previously unseen accounts or workstations.

Microsoft reports that modern endpoint solutions (e.g., Defender for Endpoint) include attack-surface reduction (ASR) rules and detections specifically designed to block or alert on LSASS credential theft, with demonstrated effectiveness in independent tests.

Mitigation: harden, limit, and monitor

Goal: Make LSASS hard to access, reduce the value of what’s inside it, and ensure attempts are noisy.

1. Enable LSASS protection features

• LSA Protection / RunAsPPL (Protected Process Light): Launches LSASS as a protected process, allowing only trusted, signed code with appropriate privileges to interact with it. [microsoft.com]
• Credential Guard: Uses virtualization‑based security (VBS) to isolate derived credentials, preventing many in‑memory theft scenarios. 

2. Apply Attack Surface Reduction (ASR) and EDR controls

• Use ASR rules to block credential stealing from LSASS, and ensure EDR policies alert on suspicious handle access and dump patterns. 

3. Reduce credential exposure

• Disable/avoid WDigest plaintext credential caching where possible; ensure modern auth packages and patches are in place.
• Prefer Kerberos and constrained delegation; avoid unnecessary credential caching on servers that host many privileged logons.

4. Least privilege & endpoint hygiene

• Minimize local admin rights; use Privileged Access Workstations (PAWs) and Just‑Enough/Just‑In‑Time Administration to limit where high‑value credentials ever land. 

5. Memory‑dump and handle‑access controls

• Remove “Debug programs” rights from standard administrators; restrict who can create process dumps; monitor/alert on dump‑tool invocation and WerFault anomalies.

6. Network & identity protections

• Detect reuse of stolen credentials (pass‑the‑hash/ticket) via anomalous authentication patterns and enforce MFA where feasible to blunt the theft value.

Incident response: if LSASS dumping is suspected

• Isolate the endpoint from the network to stop lateral movement.
• Acquire volatile evidence (carefully, to avoid destroying forensics) and collect EDR/Sysmon logs around the time of suspected access.
• Hunt for credential reuse across the domain (failed logons, unusual source hosts, ticket anomalies).
• Rotate sensitive credentials (admin/service accounts), re‑issue Kerberos tickets (e.g., KRB TGT resets per policy), and reimage if necessary.
• Retrospective detection: Search for the same TTPs fleet‑wide; many attackers execute this technique on multiple hosts.

Legal and ethical note

Attempting to access LSASS memory on systems you do not own, or without explicit, written authorization, is illegal and unethical. All guidance here is intended solely to help defenders understand, detect, and mitigate this technique.

Quick FAQ

Is LSASS dumping the same as pass‑the‑hash?

• No. LSASS dumping is a collection technique (to obtain secrets). Pass‑the‑hash/ticket are use techniques that may follow.

Does enabling Credential Guard stop all LSASS dumping?

• It significantly reduces exposure by isolating secrets, but you should still enable RunAsPPL, ASR, and robust EDR detection; defense‑in‑depth is essential.

Where else do Windows credentials live?

• Beyond LSASS memory, credentials/hashes can exist in the SAM, NTDS.dit (on DCs), LSA Secrets, cached domain credentials, and Credential Manager, each with its own risks and defenses.