Credential Dumping: Detection and Defense for Blue Teams

Credential dumping is one of the most consequential techniques an intruder can execute after gaining a foothold, because stolen secrets convert a single compromised host into lateral movement, privilege escalation, and eventually domain-wide control. This article is written for defenders. It explains what credential dumping is, how it works at a conceptual level, and — most importantly — how to detect the behavior in your telemetry and harden your environment so the technique becomes noisy, expensive, or impossible. There are no operational attack recipes here; the goal is to understand the threat well enough to defeat it.

What credential dumping actually is

Credential dumping (mapped to MITRE ATT&CK T1003, OS Credential Dumping) is the act of extracting account material — password hashes, plaintext passwords, Kerberos tickets, or authentication tokens — from the places an operating system stores them at runtime or at rest. On Windows, the canonical targets are the memory of the LSASS process, the local SAM database, cached domain credentials, and, in Active Directory, the replication interface of a domain controller. On Linux and macOS the equivalents include /etc/shadow, keyrings, and process memory. Understanding these storage locations is the first defensive step: you cannot monitor what you have not inventoried.

How the technique works at a high level

Modern operating systems keep authentication material in memory so users are not re-prompted for every network resource — this is what enables single sign-on. An attacker with sufficient privilege abuses that convenience by reading the process or database that holds the material and reconstructing usable secrets from it. Conceptually there are three families: reading live process memory (for example, the memory of the authentication subsystem), reading on-disk stores and their protective keys, and abusing legitimate replication or backup protocols to request the secrets through a supported interface. In every case the attacker needs elevated privilege first, which is a crucial point for defense: credential theft is a post-exploitation activity, so controls that limit privilege escalation directly reduce exposure.

The attack surface: where credentials live

Map your exposure by the storage location. LSASS memory holds interactive and cached credentials on any Windows host where privileged users have logged on. The SAM and SYSTEM hives hold local account hashes. LSA secrets retain service account passwords and cached secrets. On domain controllers, the NTDS.dit database and the directory replication interface expose every domain credential. Backups of any of these — VM snapshots, shadow copies, unprotected NTDS.dit exports — are equally dangerous. Finally, credential managers, browser vaults, and configuration files holding tokens or connection strings are increasingly targeted because they require less privilege than LSASS access. A defender should treat every one of these as a monitored asset.

Detection: signals in your telemetry

Detection focuses on the access pattern, not the tool name, because tooling changes constantly. On Windows, enable and forward the following. Sysmon Event ID 10 (ProcessAccess) is the highest-value signal: alert on any process that opens a handle to lsass.exe with access masks that permit memory reads (for example 0x1010, 0x1410), especially from non-standard callers. Baseline the legitimate readers of LSASS in your environment — a small set of security and system processes — and treat everything else as suspicious.

Complement that with Sysmon Event ID 11 (FileCreate) for dump files written to disk with LSASS-sized footprints, Event ID 4656/4663 (object access) on the SAM and SECURITY registry hives, and Event ID 4688 (process creation with command line auditing enabled) to catch known dumping utilities and their arguments. For Active Directory replication abuse (DCSync), the decisive signal is Windows Security Event ID 4662 where a non-domain-controller principal requests the replication rights identified by the control access GUIDs for DS-Replication-Get-Changes and DS-Replication-Get-Changes-All. Legitimate replication only ever originates from domain controllers, so any other source is a strong indicator.

EDR platforms add behavioral coverage: handle-open telemetry to LSASS, unusual parent-child process chains, in-memory reads from the authentication subsystem, and access to the shadow-copy service used to snapshot locked hives. On Linux, watch for reads of /etc/shadow by non-root-owned processes, ptrace attaches to authentication daemons, and unexpected use of memory-inspection utilities. Correlate credential-access alerts with preceding privilege-escalation and lateral-movement events; credential dumping rarely appears alone, and the surrounding sequence raises confidence and reduces false positives.

Build your detections around durable indicators rather than fragile ones. Access to lsass.exe, requests for directory-replication rights, and reads of the SAM and SECURITY hives are behaviors an attacker cannot avoid if they want the material, so they age well as detection logic. File hashes, process names, and command-line strings, by contrast, are trivially changed and should be treated as weak enrichment, never as the primary signal. Where possible, deploy honeytoken accounts — decoy privileged credentials that no legitimate process ever uses — so that any authentication or any read of their secret is an unambiguous, high-fidelity alert. Feed all of these signals into a central SIEM with a retention window long enough to reconstruct an intrusion timeline, because credential theft is often discovered weeks after the initial foothold, and short log retention erases exactly the evidence you need.

Mitigation and hardening

Start by removing the material attackers want. Enable Credential Guard (virtualization-based security) so LSASS secrets are isolated in a protected container that ordinary code cannot read. Turn on LSASS as a Protected Process Light (PPL) with RunAsPPL so only signed, protected processes can open it. Disable WDigest plaintext caching (it should already be off on modern builds) and clear cached plaintext where legacy settings linger.

Reduce where privileged credentials are ever exposed. Adopt a tiered administration model so domain-admin credentials never log on to workstations or servers where they can be harvested. Use Windows LAPS to randomize and rotate local administrator passwords, eliminating the shared local password that makes SAM theft valuable. Require Protected Users group membership and Authentication Policy Silos for high-value accounts to prevent credential caching and restrict where they can authenticate. Enforce phishing-resistant MFA so a stolen hash or password alone is insufficient. For DCSync specifically, audit and minimize which principals hold directory replication rights, and alert whenever that access set changes.

Layer in application control (WDAC or AppLocker) to block unsigned tooling, restrict debug and backup privileges (SeDebugPrivilege, SeBackupPrivilege) to the minimum set of accounts, and protect shadow-copy and backup interfaces. Rotate the krbtgt account password on a schedule and after any suspected compromise, since it underpins Kerberos ticket integrity. Every one of these controls raises the privilege bar or removes the reward, shrinking the window in which dumping is even possible.

Common pitfalls and blind spots

The most frequent mistake is alerting on tool names or file hashes instead of behavior; renaming a binary defeats that entirely, so anchor detections on the access pattern to LSASS and to replication rights. A second blind spot is forwarding logs without baselining — LSASS is legitimately read by antivirus and system processes, and without a tuned allowlist the ProcessAccess alert drowns in noise and gets ignored. Third, teams enable Credential Guard on new laptops but forget servers and domain controllers, leaving the highest-value hosts exposed. Fourth, backups and VM snapshots of domain controllers are often stored with weaker controls than the live systems, offering an offline path to NTDS.dit. Finally, do not neglect non-Windows and cloud identity stores; tokens in configuration files and cloud metadata services are increasingly the softest target.

Defender checklist

Use this as a hardening and detection baseline. 1. Enable Credential Guard on all supported endpoints, servers, and domain controllers. 2. Configure LSASS as PPL (RunAsPPL). 3. Deploy Sysmon and alert on Event ID 10 handle opens to lsass.exe, baselined to known readers. 4. Alert on Event ID 4662 replication-rights access from non-domain-controller sources. 5. Audit SAM/SECURITY hive access (4656/4663) and dump-file creation (Event ID 11). 6. Deploy Windows LAPS and confirm no shared local admin password. 7. Implement tiered administration and Protected Users for privileged accounts. 8. Enforce phishing-resistant MFA. 9. Minimize accounts holding replication, debug, and backup privileges. 10. Protect and monitor DC backups and shadow copies. 11. Rotate krbtgt regularly. 12. Correlate credential-access alerts with privilege-escalation and lateral-movement telemetry.

FAQ

Is disabling LSASS reads enough on its own? No single control is sufficient. Credential Guard and PPL dramatically raise the bar, but determined intruders pivot to on-disk hives, replication abuse, or token theft. Defense in depth — isolation, least privilege, tiered administration, MFA, and behavioral detection together — is what makes credential theft unreliable for an attacker.

How do I tell a real dumping attempt from legitimate LSASS access? Baseline your environment: identify the small set of signed security and system processes that legitimately open LSASS, then alert on everything outside that allowlist, weighting by the requested access mask and the calling process lineage. Correlating with nearby privilege-escalation events sharply reduces false positives and confirms intent.

Conclusion

Credential dumping is dangerous precisely because it turns one compromise into many, but it is also highly detectable and largely preventable once you understand where credentials live and how the access looks in telemetry. Isolate secrets with Credential Guard and PPL, remove the reward with LAPS and tiered administration, enforce phishing-resistant MFA, and instrument LSASS access and replication rights so abnormal access surfaces immediately. Understand the technique in order to defend against it — and make credential theft the noisiest, most expensive step in an attacker's path rather than the easiest.