Pass-the-Hash
Also calledPtH
Signs in over NTLM with a stolen NT hash, never needing the password.
- Technique
- MITRE ATT&CK T1550.002: Use Alternate Authentication Material: Pass the Hash (opens in a new tab)
- Needs
- NT Hash
- Gives
- Account AccessandLocal Admin
How the Attack Works
An NTLM response is computed from the account's NT hash, never from the password itself, so whoever holds the hash can answer any server's challenge as that account. The server, or the DC it asks, checks the answer exactly as it checks the real user's, and nothing in the exchange can tell them apart. Local accounts work the same way, checked against the target's own SAM.
Read first Authentication and Authorisation, Password Hashes and Kerberos Keys, Credentials on a Running Machine, NTLM Authenticate and Validation, Where Sign-In Evidence Lands
How It Plays Out
The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.
srv-app-01 Foothold
- dana's key
srv-fin-01 File server
- srv-fin-01 key
- Netlogon key
dc-01 Domain controller
- dana's key
- Netlogon key
Step 1 of 5: Hash in a New Session
On srv-app-01 Foothold
On srv-app-01 a new logon session is given dana's NT hash in place of a password, for its network sign-ins.
Logged
4624 An account was successfully logged on
On srv-app-01, in the Security log
Logon Type 9 (NewCredentials), Network Account Name dana
Reading Logon Events explains how to read it.4648 A logon was attempted using explicit credentials
On srv-app-01, in the Security log
Explicit credentials for dana, and the process that used them
Explicit Credentials on the Source Machine explains how to read it.
What Defenders See
The Security log on srv-app-01 shows event 4624 with Logon Type 9 and Network Account Name dana. It also shows event 4648.
Step 2 of 5: NTLM Answer From Hash
srv-app-01 Foothold to srv-fin-01 File server
Answer made from dana's hash
AUTHENTICATE_MESSAGESMB, port 445srv-app-01 answers srv-fin-01's challenge with an NTLMv2 response computed from dana's NT hash, as her own machine would.
What Travels in This Step
Who is signing in
dana, CORP and the workstation name SRV-APP-01
In the clear Anyone who sees the traffic can read it.
The NTLMv2 response
NtChallengeResponseA keyed hash over the challenge, a client challenge, the time and the target
Computed with dana's NT hash Only srv-app-01 and dc-01 can make or check it.
What Defenders See
Nothing shows in any log yet, because srv-fin-01 must ask dc-01 whether the answer is right.
Hooks into NTLM authenticate
Step 3 of 5: Pass-Through
srv-fin-01 File server to dc-01 Domain controller
srv-fin-01 cannot check a domain account's answer itself, so it passes the challenge and response to dc-01.
What Defenders See
On its own, the pass-through from srv-fin-01 to dc-01 writes nothing to either machine's logs.
Step 4 of 5: DC Approves
dc-01 Domain controller to srv-fin-01 File server
dc-01 works out the answer from its copy of dana's NT hash. It matches, so dc-01 approves it as it would hers.
Logged
4776 The computer attempted to validate the credentials for an account
On dc-01, in the Security log
Logon Account dana, Source Workstation SRV-APP-01, Error Code 0x0
NTLM Authenticate and Validation explains how to read it.8004 Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller
On dc-01, in the Microsoft-Windows-NTLM/Operational log When enabled
dana's NTLM sign-in, checked for srv-fin-01 over its secure channel
What Defenders See
The Security log on dc-01 shows event 4776 for dana with Source Workstation SRV-APP-01 and Error Code 0x0. Where NTLM auditing is on, dc-01 also writes event 8004 to its Microsoft-Windows-NTLM/Operational log.
Hooks into NTLM DC Answer
Step 5 of 5: Access as dana
srv-fin-01 File server to srv-app-01 Foothold
srv-fin-01 accepts the session and builds dana's token, and the share opens to whatever she may read.
Logged
4624 An account was successfully logged on
On srv-fin-01, in the Security log
Logon Type 3, Authentication Package NTLM, Workstation Name SRV-APP-01
Reading Logon Events explains how to read it.
What Defenders See
The Security log on srv-fin-01 shows event 4624 with Logon Type 3 and NTLM for dana from 192.0.2.25, though her account normally signs in with Kerberos.
Hooks into NTLM access
Needs First
What the attacker must already hold for this attack to be possible.
- An NT HashThe account's NT hash, from LSASS, the SAM, NTDS.dit or DCSync.
Gives the Attacker
What running it hands the attacker to use next.
- Access as Another AccountAccess as that account to every server it may use that still accepts NTLM.
- Local Admin RightsAdmin rights wherever the account is an administrator.
Leads To
What Defenders See
What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.
| Event and Log | Written On | Look For | Switch It On |
|---|---|---|---|
| 4624 An account was successfully logged on (opens in a new tab) Security log | The computer that was logged on to | On the target, Logon Type 3 over NTLM for an account that normally uses Kerberos. On the source, Logon Type 9 naming the account as Network Account Name.Reading Logon Events explains how to read it. | Audit Logon |
| 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 | NTLM checks for the account from a workstation it does not use, or, on a member server or workstation, a local account.NTLM Authenticate and Validation explains how to read it. | Audit Credential Validation |
| 4648 A logon was attempted using explicit credentials (opens in a new tab) Security log | The computer the credentials were used from | On the source, explicit credentials for another account, and the process that used them.Explicit Credentials on the Source Machine explains how to read it. | Audit Logon |
| 8004 Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller (opens in a new tab) Microsoft-Windows-NTLM/Operational log | Domain controllers | The NTLM sign-ins a DC checked, with the server and workstation each came through, once NTLM auditing is on. | Network security: Restrict NTLM: Audit NTLM authentication in this domain, set to Enable all, on domain controllers |
What It Looks Like
One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.
4624 An account was successfully logged on
In the Security log on srv-fin-01,
dana's NT hash used from srv-app-01 to open a share on srv-fin-01.
A network sign-in to a share or a service.
As Windows writes it:
Logon Type3A domain user whose own sign-ins to srv-fin-01 use Kerberos.
As Windows writes it:
Account NamedanaThe name the client gave for itself, which is not ws-017, where dana works.
As Windows writes it:
Workstation NameSRV-APP-01srv-app-01's address. A new pair of source and target for this account is the lead.
As Windows writes it:
Source Network Address192.0.2.25NTLM where Kerberos is normal for her, because the hash answers NTLM, not Kerberos.
As Windows writes it:
Authentication PackageNTLMAn NTLMv2 response, as pass-the-hash needs no weaker version.
As Windows writes it:
Package Name (NTLM only)NTLM V2
Defender for Identity Alerts
Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.
- Suspected identity theft (pass-the-hash) (opens in a new tab)
- Suspicious authentication attempt (opens in a new tab)
- Suspicious SMB NTLM authentication attempt (opens in a new tab)
- Suspicious NTLM authentication (opens in a new tab)
Blind Spots
Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.
- From a device outside your logging nothing is recorded at the source, and the target's 4624 and the DC's 4776 look ordinary. A new pair of source and target for the account is the lead.
- With a local account no DC is asked, so the 4776 lands on the target itself, and only that machine keeps it.
Look for It on a Machine
The Registry keys on an endpoint that hold a trace of this, each opening its own page.
Hunt It
The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.
Needs Defender for Identity sensors on every DC. The LogonSuccess value is listed only in the portal's schema reference. A new pair of account and source is a lead, not proof, because address-based connections and old devices use NTLM too.
// NTLM sign-ins seen by Defender for Identity, first seen per account, source and targetIdentityLogonEvents| where Timestamp > ago(How to Prevent It
The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.
Protected Users group (opens in a new tab)
Add privileged accounts to Protected Users, so they cannot sign in with NTLM at all and their NT hash opens nothing over it.
NTLM restrictions (opens in a new tab)
Audit, then refuse, NTLM wherever Kerberos works, leaving a stolen hash nothing to answer.
Windows LAPS (opens in a new tab)
Give each machine its own local administrator password, so one local hash does not open the rest.
Local admins kept off the network (opens in a new tab)
Keep local admin accounts off the network, so their hashes cannot pass between machines.
Check it on a machine: User Account Control SettingsCredential Guard (opens in a new tab)
Turn on Credential Guard, so domain accounts' NT hashes sit outside LSASS and fewer are there to steal in the first place.
Check it on a machine: Credential Guard (LsaCfgFlags)Tiered administration (opens in a new tab)
Keep admin hashes off ordinary machines, where they could be taken and passed.
Sources
- MITRE ATT&CK T1550.002: Use Alternate Authentication Material: Pass the Hash (opens in a new tab)
- [MS-NLMP] 3.3.2: NTLM v2 authentication (opens in a new tab)
- [MS-APDS] 1.4.1: NTLM logon (opens in a new tab)
- Microsoft Learn: Local accounts (opens in a new tab)
- Microsoft: Mitigating Pass-the-Hash (PtH) attacks and other credential theft (opens in a new tab)
- Microsoft Learn: Event 4776 (opens in a new tab)