Every credential attack on Windows — dumping LSASS, reading the SAM, extracting NTDS.dit, abusing DPAPI — is an attack on a specific place where Windows keeps a secret. This page is the map: where credentials live, what form they take, and how Windows tries to protect them. The specific extraction techniques live in the Vulns & Misconfigs section; this is the mechanism that makes all of them possible.
Passwords are rarely stored — derivations are
Windows almost never stores a cleartext password. It stores values derived from the password, and it stores authentication material (tickets, keys) that a logged-on session needs. The security of the whole system rests on the fact that these derivations are supposed to be one-way or access-controlled — and credential attacks are, in essence, the discovery that they are neither one-way enough nor access-controlled enough.
The stores, one by one
The SAM — local accounts
The Security Account Manager is a registry hive
(HKLM\SAM) that holds the NT hashes of local accounts
— the local Administrator and any other local users. The NT hash is an unsalted MD4
of the password. It is encrypted in the hive with a boot key stored in the
SYSTEM hive, so both are needed to extract it.
Two facts make the SAM dangerous. First, the NT hash is a password equivalent: because authentication proves knowledge of the hash (see NTLM), possessing it is as good as the password for pass-the-hash. Second, if the same local administrator password is used across many machines, one stolen SAM hash unlocks all of them.
LSASS — the live session vault
The Local Security Authority Subsystem Service (lsass.exe)
is the process that performs authentication and, critically, caches the
credential material of every interactive session so the user is not prompted
again. In its memory sit NT hashes, Kerberos tickets and keys, and — where legacy
providers such as WDigest are enabled — cleartext passwords.
LSASS is the single richest credential target on a host because it holds the secrets of whoever is currently or recently logged on. Dumping LSASS on a server an administrator has RDP'd into commonly yields a Domain Admin credential — which is why protecting LSASS (below) matters so much.
LSA secrets and cached domain credentials
Under HKLM\SECURITY, the LSA secrets store persistent
machine secrets: service-account passwords, auto-logon credentials, the computer's
own machine-account key, and more. Separately, Windows caches the last several
domain logons (the "MSCACHEv2" / DCC2 values) so a domain user can
log on to a laptop that is off the corporate network.
| Item | Form |
|---|---|
| Service-account secrets | Often reversibly stored — recoverable as cleartext |
| Cached domain logons (DCC2) | A slow-to-crack hash, not replayable — crack offline for the password |
| Machine account key | The computer's own credential in the domain |
NTDS.dit — the whole domain
On a domain controller, the directory database
NTDS.dit contains the password hashes and Kerberos keys of
every account in the domain — including krbtgt and every
Domain Admin. It is the crown jewel: reading it is total domain compromise. It is a
locked, live database, so extraction uses a volume shadow copy or the replication
protocol rather than a plain file read.
DPAPI — per-user application secrets
The Data Protection API is how Windows and applications encrypt per-user secrets: browser passwords and cookies, saved RDP and Wi-Fi credentials, Credential Manager entries, and application data. Each user has DPAPI master keys, derived from their password; a domain also keeps a DPAPI backup key on its DCs so secrets can be recovered if a user forgets their password.
The domain backup key is the reason DPAPI matters at the domain level: a single
.pvk from a DC decrypts every domain user's DPAPI secrets on
every host. That frequently exposes credentials to systems and third parties
entirely outside Active Directory.
Kerberos keys and tickets
For Kerberos, the material that matters is
the account's long-term keys (RC4 — which equals the NT hash — and AES128/AES256)
and the tickets issued to a session (the TGT and service tickets). These live in
LSASS while a session is active. Stealing a key enables overpass-the-hash /
pass-the-key; stealing a ticket enables pass-the-ticket; stealing the
krbtgt key enables Golden Tickets.
Why these stores fall
| Design reality | Consequence |
|---|---|
| Local admin can read process memory and registry hives | Local admin = access to SAM, LSASS, LSA secrets |
| NT hash is unsalted and static | It is a password equivalent (pass-the-hash) until the password changes |
| Single sign-on requires caching secrets | LSASS must hold reusable material for logged-on users |
| Recoverability requires a backup key | The DPAPI domain backup key is a single domain-wide skeleton key |
| DCs must replicate password data | The replication protocol is a supported path to every hash (DCSync) |
The defences
Modern Windows adds protections that specifically target these stores. Knowing them is how you read a host's real exposure:
| Control | What it protects |
|---|---|
| LSA Protection (RunAsPPL) | Runs LSASS as a protected process so normal admin tools cannot read its memory |
| Credential Guard | Moves secrets into a VBS-isolated container away from LSASS entirely |
| Disable WDigest | Stops cleartext passwords being cached in LSASS |
| LAPS | Gives every host a unique, rotated local admin password — breaks SAM-hash reuse |
| gMSA | Service passwords are 120+ chars, managed by the DC — LSA secret is uncrackable |
| Tiered administration | Keeps Tier-0 credentials off machines where they could be dumped |
The takeaway
There is no single "password file" on Windows — there is a landscape of stores, each holding a different form of secret for a different purpose: the SAM for local accounts, LSASS for live sessions, LSA secrets for services, NTDS.dit for the whole domain, DPAPI for per-user application data, and Kerberos keys/tickets threaded through it all. Every credential-access technique is the exploitation of one of these, and every defence hardens one of them. Match the store to the attack and to the control, and a host's credential exposure becomes legible on sight.
The extraction techniques — LSASS dumping, SAM/LSA secrets, NTDS.dit, DPAPI abuse, and stored-application harvesting — are documented with commands in the Vulns & Misconfigs section under Credential Access.