Password Hashes and Kerberos Keys: Active Directory Sign-In

Why It Matters

NTLM and Kerberos prove a password with values made from it, so a stolen hash or key works as well as the password does. Knowing which store holds which secret tells you what a theft gave away and what to reset.

What Happens

Unless reversible encryption is switched on, account stores keep values made from a password, never the password itself. The NT hash is an MD4 hash of the password with no salt, so the same password gives the same hash for every account. NTLM proves knowledge of it, and Kerberos uses it unchanged as its RC4 key.

Kerberos also makes AES keys from the password, salted with the realm in capitals and the user name, so dana's salt is CORP.EXAMPLEdana. The same password therefore gives each account different AES keys, and only the RC4 key is simply the NT hash. The old LM hash, made from the password in capitals split into two halves, is not stored by default and is far weaker where a system still keeps it.

Three kinds of account matter most. The krbtgt key seals and signs the domain's ticket-granting tickets (TGTs), so whoever holds it can make them. Each computer has an account ending in $ whose password Windows sets and changes itself, while a service run by a user account uses a password someone chose, which can be guessed.

A group managed service account removes that risk, because no person chooses its password and Windows computes and changes it.

Local accounts rest in the SAM hive of each machine, and domain accounts rest in NTDS.dit on every domain controller. Both are locked with a key held in the SYSTEM hive, so a theft of either takes a copy of SYSTEM with it. Credential Guard protects neither store, only the copies in memory.

What One Password Becomes

One password gives an account several secrets, and each protocol uses a different one. This table shows what each secret is made from and which protocol uses it, so you know what a stolen value is good for.

Secret	Made From	Used By
NT hash	MD4 of the password, with no salt	NTLM, and Kerberos as the RC4 key
AES keys	The password, salted with the realm and the user name	Kerberos (AES128 and AES256)
LM hash	The password in capitals, in two halves	LM only, and not stored by default

Where the Secrets Rest

Each secret is stored in a known place, and that place decides what a theft needs and what it gives away. Use this table to work out what someone who copied one of these stores now holds.

Store	Holds	Found On
SAM hive	Local accounts and their NT hashes	Every Windows machine
SECURITY hive	Cached domain logons and LSA secrets	Every Windows machine
NTDS.dit	Every domain account's NT hash and Kerberos keys, krbtgt's included	Every domain controller
SYSTEM hive	The key needed to read a copy of the SAM or NTDS.dit	Every Windows machine
LSASS memory	The hashes, keys and tickets of the sessions signed in now	Every running machine

What Is Logged

Each event below names the log it is written to, the machine that writes it and the audit setting that switches it on, then what to read in it for this page.

Event and Log	Written On	Switch It On	What It Tells You
4776 `The computer attempted to validate the credentials for an account` (opens in a new tab) Security log	The computer that holds the account, a domain controller for a domain account or the computer itself for a local one	Audit Credential Validation	An NTLM check of an answer computed with the account's NT hash, which is all pass-the-hash needs.NTLM Authenticate and Validation explains how to read it.
4768 `A Kerberos authentication ticket (TGT) was requested` (opens in a new tab) Security log	Domain controllers	Audit Kerberos Authentication Service	Pre-Authentication EncryptionType shows which form of the account's key sealed the timestamp, and Session Encryption Type shows the session key's type. 0x11 and 0x12 are AES, and 0x17 is RC4, whose key is the NT hash.AS Reply: The TGT explains how to read it.
4769 `A Kerberos service ticket was requested` (opens in a new tab) Security log	Domain controllers	Audit Kerberos Service Ticket Operations	Ticket Encryption Type shows which form of the service's key sealed the ticket, either AES (0x11 or 0x12) or RC4 (0x17).TGS Reply: The Service Ticket explains how to read it.

Check It on a Machine

These Windows Registry keys hold the settings this page names. Open one to see where it lives and how to read it on a machine.

Attacks That Hook in Here

These attacks work through what this page describes. Each card says what the attack is and, where it uses one of these steps, what it does there.

Pass-the-Hash
Signs in over NTLM with a stolen NT hash, never needing the password.
Overpass-the-Hash
Uses a stolen NT hash or AES key to get a real TGT, turning a hash into Kerberos.
Kerberoasting
Asks for service tickets, then guesses the service account's password offline.
LSASS Memory Theft
Reads the hashes and tickets that sign-ins left on a machine out of LSASS memory.
SAM, LSA Secrets and Cached Logons
Takes local hashes, stored passwords and cached domain logons from a machine's hives.
NTDS.dit Theft
Copies a domain controller's database to read every account's keys, krbtgt's included.
DCSync
Asks a domain controller to replicate account secrets, as another DC would.
Silver Ticket
Forges a service ticket with the service's own key, so no DC ever issues it.
Golden Ticket
Forges a TGT with the krbtgt key, for any account and groups, that every DC accepts.
Shadow Credentials
A key added to an account lets a certificate sign in as it, past a password reset.
Zerologon
A Netlogon flaw let a domain controller's own account password be reset without proof.
Delegated Managed Service Account Abuse
A superseded service account hands a new managed account its reach.
LAPS and gMSA Password Reads
Reads a managed local-admin or service-account password straight from the directory.