LSASS Process Dumping

What LSASS process dumping actually means

LSASS process dumping is a memory extraction technique against Windows’ Local Security Authority Subsystem Service. Because LSASS holds active credential material and authentication state, dumping it turns one running system process into a high-value source of reusable secrets.

The key security issue is not the dump file itself, but what it can reveal. If an attacker can read LSASS memory, they may recover plaintext passwords, hashes, Kerberos tickets, or other authentication artefacts that enable immediate lateral movement and follow-on compromise.

Why LSASS is such a valuable target

LSASS sits at the centre of Windows logon and local security authority functions, so its memory often contains material that is far more useful than ordinary disk-stored credentials. That makes it attractive after initial access, especially when defenders rely on weak local admin hygiene or allow debugging-style access too broadly.

This is why hardening LSASS matters even on otherwise well-managed endpoints. Defenses such as protected process features, Credential Guard, and rights restriction are designed to make memory theft materially harder and to reduce the chance that one privileged foothold becomes a full domain compromise.

For defenders who want a broader Windows context, NHIMG’s Windows Internals for Defenders Guide covers LSASS protection alongside tokens, privileges, and telemetry that help explain why the process is so sensitive.

How attackers dump LSASS memory and what they gain

Attackers commonly reach LSASS dumping after obtaining local administrative privileges, abusing debug rights, or using dual-use tools that can create a minidump. The technique is often paired with credential theft tooling because the recovered material can be replayed directly or cracked offline.

Once the attacker has the dump, the impact can extend well beyond the infected host. Stolen credentials can unlock remote administration, service accounts, privileged sessions, cached tickets, or other trust relationships that were never meant to leave memory.

NHIMG’s ATT&CK Credential Access Tactic Guide places LSASS dumping in the wider credential theft landscape, while the Credential Dumping Guide ties it to adjacent techniques such as SAM, NTDS.dit, LSA secrets, and DCSync.

Detection and hardening priorities

Defenders should treat suspicious access to LSASS as a high-signal event, especially when it comes from unusual parent processes, unexpected tools, or endpoints that should never be creating memory dumps of security-sensitive processes. Correlating process creation, handle access, and dump-file creation helps distinguish legitimate troubleshooting from hostile collection.

Hardening should focus on reducing who can open or debug LSASS, protecting the process with platform controls, and ensuring telemetry is preserved before an attacker can erase traces. A practical Windows control set here is least privilege, protected process settings, endpoint monitoring, and alerting on common dump artefacts and post-exploitation tooling.

For detection engineering, Credential Dumping Guide is the most direct operational reference, and the ATT&CK Credential Access Tactic Guide helps map suspicious activity to known attacker techniques and log sources.

What recovery should include after suspected dumping

If LSASS dumping is confirmed or strongly suspected, response should assume credential exposure until proven otherwise. That means reviewing privileged sessions, rotating affected passwords and secrets, invalidating tickets or tokens where appropriate, and checking whether the attacker used the captured material for persistence or lateral movement.

Post-incident review should also ask a harder question: was the compromise limited to one endpoint, or did the exposed material include accounts that can move across servers, domains, or cloud-connected services? The answer determines whether containment ends with one host or becomes an identity-wide reset exercise.

Because LSASS dumping is fundamentally a credential-theft event, the safest recovery posture is to validate both host integrity and identity integrity before restoring trust.

Related resources from NHI Mgmt Group

• How do you detect LSASS credential dumping on Windows?
• Why do NHI programmes need stronger process ownership than many human identity programmes?
• How should organisations govern API partner onboarding as a non-human identity process?
• How can security teams apply GRC maturity benchmarks without creating process bloat?