Pass-the-Hash
Also known as: PtH, NTLM hash reuse, Pass the hash, Credential reuse over NTLM
A lateral-movement technique in which an intruder authenticates to other Windows systems using a stolen NTLM password hash instead of the password, so strong passwords alone do not stop it.
Watch it in 60 seconds
How it works
Pass-the-hash is the reuse of a captured NTLM password hash to authenticate as a user, without ever learning the plaintext password. NTLM challenge-response proves knowledge of the hash, so possession of the hash is enough to answer the challenge on any system that accepts NTLM for that account.
The hash has to be obtained first, usually from memory or local account stores on a machine the intruder already controls. That is why the technique is a second-stage move: it turns one compromised workstation into access to file servers, other workstations and eventually administrative systems, using accounts that were legitimately cached on the first machine.
It is hard to spot because every step uses a real credential through a normal protocol. There is no failed-password noise and no malware on the target. The tells are behavioural: network logons from hosts that never normally authenticate there, NTLM appearing where Kerberos is the norm, and privileged accounts authenticating from ordinary workstations.
Defence therefore focuses on limiting where a privileged hash can ever exist and be used. Tiered administration keeps domain admin credentials off workstations, LAPS makes every local administrator password unique, Credential Guard isolates secrets from memory theft, and restricting NTLM removes the protocol the technique depends on.
Walk through it
- 1The alert fires
- 2Read the logon event
- 3Spot the protocol anomaly
- Scope the lateral movement
- Contain and harden
Your SIEM raised a medium-severity alert: a domain admin account authenticated to a file server from a marketing workstation at 02:14. Nobody is awake to explain it. Read the alert before you touch a single host.
Privileged account authenticated from an unusual workstation
Account: FABRIKAM\adm.rkhan (Domain Admins)
Source: MKT-WS-044 (marketing workstation, 10.20.4.44)
Target: FS-02 (file server, 10.10.1.12)
Time: 02:14 local. This account has never signed in from MKT-WS-044 in 90 days.
Spot it
- Event 4624 with Logon Type 3 and Authentication Package NTLM for an account that normally authenticates with Kerberos.
- A privileged or administrative account authenticating from an ordinary workstation instead of a dedicated admin host.
- One account reaching several servers within minutes, outside its normal hours, in a fan-out pattern.
- Event 4624 Logon Type 9 (new credentials) followed by network logons from the same source, which suggests credentials were swapped in a running session.
- Event 4648 (explicit credentials) and bursts of 4625 failures or 4672 special-privilege assignments clustered on one source host.
Windows Security log on FS-02
EventID=4624 TimeCreated=2026-10-11T02:14:07Z LogonType=3 TargetUserName=adm.rkhan TargetDomainName=FABRIKAM WorkstationName=MKT-WS-044 IpAddress=10.20.4.44 AuthenticationPackageName=NTLM LogonProcessName=NtLmSsp
EventID=4672 TimeCreated=2026-10-11T02:14:07Z SubjectUserName=adm.rkhan PrivilegeList=SeBackupPrivilege,SeDebugPrivilege,SeImpersonatePrivilegeWindows Security log on SQL-03
EventID=4624 TimeCreated=2026-10-11T02:18:31Z LogonType=3 TargetUserName=adm.rkhan WorkstationName=MKT-WS-044 IpAddress=10.20.4.44 AuthenticationPackageName=NTLMkqlMicrosoft Sentinel — NTLM network logons by privileged accounts from workstations
SecurityEvent
| where EventID == 4624 and LogonType == 3
| where AuthenticationPackageName == "NTLM"
| where TargetUserName in (PrivilegedAccountList)
| where WorkstationName !startswith "ADMIN-JUMP"
| summarize Targets = dcount(Computer), First = min(TimeGenerated) by TargetUserName, WorkstationName, IpAddress
| where Targets >= 2PrivilegedAccountList is a watchlist you maintain. Expect noise from legacy applications that only speak NTLM; baseline them first.
splSplunk — account seen over NTLM after a Kerberos-only history
index=wineventlog EventCode=4624 Logon_Type=3
| eval proto=if(Authentication_Package="NTLM","ntlm","other")
| stats count(eval(proto="ntlm")) as ntlm_n count as total dc(ComputerName) as hosts by Account_Name, Workstation_Name
| where ntlm_n>0 AND hosts>=2Join against a list of privileged accounts to cut noise.
Stop it
Tier administration so privileged hashes never land on workstations
Domain and server administrators sign in only from dedicated, hardened admin hosts. If a domain admin credential is never cached on a marketing workstation, a compromise of that workstation yields nothing worth reusing. This is the answer exams expect.
Make local administrator passwords unique
Deploy LAPS (or Windows LAPS) so each machine has a different, rotating local admin password. A hash stolen from one machine then opens that machine only, instead of every machine built from the same image.
Protect secrets and restrict NTLM
Enable Credential Guard to isolate credential material from memory theft, place privileged users in Protected Users, and audit then restrict NTLM so Kerberos is the only accepted path for administration.
Policy intent for privileged sign-ins
Hardened
IF account IN privileged-groups
THEN allow interactive and network logon ONLY on tier-0/tier-1 admin hosts
AND deny logon to standard workstations
AND require Kerberos (NTLM blocked)
ELSE standard policyExpressed as intent; implement with 'Deny log on' user rights assignments, authentication policy silos and NTLM restriction settings in your environment.
- Enable Windows LAPS on all workstations and member servers and retire shared local administrator passwords.
- Turn on Credential Guard on supported endpoints and servers.
- Add privileged accounts to the Protected Users group and set them as sensitive, not delegable.
- Audit NTLM usage first, then restrict it for administrative and server access; keep an exceptions list with owners.
- Forward 4624, 4625, 4648, 4672 and 4768/4769 to the SIEM and baseline per-account protocol and source host.
- Block lateral SMB and RPC between workstations with host firewall rules.
If it already happened
Isolate the source workstation and any host the account reached, disable or reset the affected accounts, and block the source from authenticating to servers while you scope.
Identify every account whose credentials were present on the compromised hosts and reset them. If a domain admin or domain controller was involved, reset the krbtgt account twice, spaced by the ticket lifetime, and rebuild what cannot be trusted.
Return hosts from known-good images, re-enable accounts under the tiered model, and confirm no new NTLM sessions from the former source appear.
Find how the first machine was compromised, add the detection that would have caught it sooner, and close the gap with LAPS, Credential Guard and NTLM restriction.
Check yourself
1. Why can an intruder authenticate with a stolen NTLM hash without knowing the password?
2. Which log pattern most strongly suggests pass-the-hash lateral movement?
3. Which control best limits the blast radius when one workstation is compromised and its hashes are stolen?