Pass-the-Hash and Pass-the-Ticket Defence Guide

Windows authentication material left in memory after a logon can be replayed to sign in as that user elsewhere, without ever knowing the password. Pass-the-Hash reuses the NTLM password hash and Pass-the-Ticket reuses a Kerberos ticket, and together they are the main way intruders move from one compromised workstation to servers and domain controllers. This guide is for identity, Active Directory and endpoint administrators and the analysts who watch their logs. It describes each technique briefly from the defender's side and then concentrates on what stops it: tiered administration, Protected Users, LAPS, Credential Guard, Remote Credential Guard, reducing NTLM, AES-only Kerberos, event monitoring and recovery. Ticket forgery is covered in the Golden Ticket, Silver Ticket and DCSync Guide and Kerberos fundamentals in the Kerberos Security Guide.

Key takeaways

Replay works because credentials are left behind. Every interactive logon by a privileged account on a lower-trust machine leaves material that can be reused, so logon restrictions by tier matter more than any single tool.
Shared local administrator passwords turn one machine into many. Windows LAPS gives each device a unique, rotated password and removes the most common replay path.
Credential Guard protects the secrets that are replayed. It isolates NTLM hashes and Kerberos ticket-granting tickets in virtualisation-based security on clients and member servers, though not on domain controllers.
NTLM is deprecated and should be shrinking. Audit it, remove NTLMv1, require SMB signing and LDAP channel binding, and restrict NTLM by exception list.
Recovery means rotating what was exposed. Resetting a user's password invalidates a replayed hash, but tickets already issued live until they expire, and machine, service and local admin secrets need rotation too.

How the attack works

Both techniques fall under MITRE ATT&CK T1550 Use Alternate Authentication Material and are described here only in the terms a defender needs.

Pass-the-Hash (T1550.002): NTLM authentication proves knowledge of a password by using its hash, so whoever holds the hash can authenticate as that account to any service that accepts NTLM. The hash typically comes from memory or the local account database of a machine the intruder already controls. What the defender sees is a network logon (event 4624, logon type 3) using NTLM from a workstation that the account does not normally use, often for a local administrator or a privileged domain account, followed by remote service creation or administrative share access.
Pass-the-Ticket (T1550.003): a Kerberos ticket, once issued, can be presented by any machine until it expires. An intruder who extracts a user's ticket-granting ticket or service tickets from one host can use them from another. What the defender sees is a ticket in use from a different client address than the one it was issued to, Kerberos logons with no corresponding ticket request from that source, or one account authenticating from two machines at the same time.

A related pattern, sometimes called overpass-the-hash, uses a stolen hash to request Kerberos tickets. It is defeated by the same controls, and Protected Users plus AES-only Kerberos make it far noisier.

Where it shows up

Exposure	Why replay works there	Control that closes it
Same local administrator password on many machines	One hash opens every device	Windows LAPS; deny network logon for local accounts
Domain admins signing in to workstations or member servers	Tier 0 secrets cached on lower-trust hosts	Tiered logon restrictions, privileged access workstations
Helpdesk using RDP with full credentials	Credentials land on the target and can be harvested after disconnect	Remote Credential Guard or Restricted Admin mode
NTLM still accepted widely	Hashes are directly usable	NTLM audit and restriction, SMB signing, LDAP channel binding and EPA
Service accounts with interactive or batch logons on many servers	Long-lived service secrets exposed on each host	gMSA, logon rights limited to the hosts that need them
No virtualisation-based protection of LSA secrets	Hashes and tickets readable by anyone with admin on the host	Credential Guard on clients and member servers

For the wider picture of movement between hosts, see the Lateral Movement Guide; for how the secrets are obtained in the first place, see the Credential Dumping Guide.

Impact

Rapid spread: a reused local administrator password lets an intruder move across every machine sharing it in minutes, which is why replay often precedes ransomware deployment.
Privilege escalation: each hop exposes the credentials of whoever logged on there; one domain admin session on a workstation is enough to reach Tier 0.
Weak attribution: activity appears to come from legitimate accounts, so investigation and scoping take longer.
Persistence: a replayed hash keeps working until the password changes. For local and service accounts that may be years.

Detection

Enable "Audit Logon", "Audit Credential Validation" and the Kerberos audit subcategories on domain controllers, collect member server and workstation Security logs centrally, and turn on NTLM auditing before you start restricting it.

Event or log	Logged on	What to look for	Technique
4624, logon type 3 with NTLM	Target hosts	Privileged or local admin accounts authenticating with NTLM from unusual sources; workstation to workstation admin logons	Pass-the-Hash
4776	Domain controllers (domain accounts), local machine (local accounts)	NTLM credential validation for privileged accounts, or from hosts that should use Kerberos	Pass-the-Hash
4768 and 4769	Domain controllers	Service tickets used from a client address different from the one that requested the TGT; ticket encryption types other than AES (0x11, 0x12)	Pass-the-Ticket, overpass-the-hash
4648	Source host	Explicit credential use toward many targets	Both
4672	Target hosts	Special privileges assigned at logon for accounts outside their tier	Both
Microsoft-Windows-NTLM/Operational	Clients, servers, DCs	NTLM usage recorded by the "Restrict NTLM: Audit" policies, used to find dependencies before blocking	Pass-the-Hash
Authentication logs (Protected Users events 100, 104, 303, 304)	Domain controllers	Failed NTLM or weak-cipher attempts by protected accounts; these logs are disabled by default	Both

Correlation that works: the Logon GUID field links 4769 on the domain controller with 4624 on the target, which allows a check that the ticket was used from the host that requested it.
Identity threat detection: Microsoft Defender for Identity documents classic alerts for suspected Pass-the-Hash (2017), Pass-the-Ticket (2018) and overpass-the-hash (2002, 2008). The ITDR Guide covers the product-neutral approach.
Baselines: keep a list of the administration hosts each privileged account may use. Most replay detection is simply "this account, from that machine, should never happen".

Metrics that show the controls are working

LAPS coverage: percentage of Windows devices with a LAPS-managed, recently rotated local admin password (target: 100 percent).
Credential Guard coverage: percentage of eligible clients and member servers with Credential Guard running.
NTLM volume: NTLM authentications per day, and the number of distinct servers still accepting it (target: steadily falling).
Tier violations: Tier 0 or Tier 1 account logons on lower-tier hosts per week (target: zero).
Protected Users membership: percentage of human privileged accounts in the group.
Time to rotate: hours from confirmed exposure to reset of every affected account and machine secret.

Prevention and hardening

Tiering and logon restrictions

The enterprise access model separates control, management and data planes so that a credential from a higher plane is never exposed on a lower one. In practice: privileged access workstations for Tier 0 and Tier 1 administration; "Deny log on locally", "Deny log on through Remote Desktop Services" and "Deny access to this computer from the network" assigned to higher-tier groups on lower-tier hosts; and the built-in "Local account" SID denied network and RDP logon on workstations and member servers. See the Tiered Administration and Enterprise Access Model Guide.

Protected Users

Members of Protected Users cannot authenticate with NTLM, cannot use DES or RC4 in Kerberos pre-authentication, cannot be delegated, have a four-hour ticket-granting ticket lifetime and do not leave cached verifiers or reusable long-term keys on the devices they sign in to. That removes Pass-the-Hash for those accounts and shortens the life of any stolen ticket. Add human privileged users after testing, never service or computer accounts, and keep a break-glass account outside the group. The domain functional level must be Windows Server 2012 R2 or higher for the domain controller protections.

LAPS

Windows LAPS rotates a unique local administrator password per device and stores it in Active Directory or Microsoft Entra ID, and can back up the DSRM password of domain controllers. Microsoft lists protection against Pass-the-Hash and lateral traversal as a core benefit. See the LAPS Guide.

Credential Guard and Remote Credential Guard

Credential Guard: uses virtualisation-based security to isolate NTLM password hashes, Kerberos ticket-granting tickets and stored domain credentials. It is enabled by default on domain-joined Windows 11 22H2 and later and Windows Server 2025 devices that meet the requirements (not domain controllers), without UEFI lock. It does not protect the AD database or the local SAM, and it blocks DES, unconstrained delegation and NTLMv1 for protected credentials, so test applications that rely on them.
Remote Credential Guard and Restricted Admin mode: both stop credentials being left on the remote host during RDP. Remote Credential Guard redirects Kerberos requests back to the client and requires Kerberos; Restricted Admin mode signs in with the target's local administrator, which suits helpdesk use alongside LAPS.

Endpoint baselines for both features are covered in the Windows Endpoint Hardening Guide.

Reduce NTLM

Know the direction of travel: Microsoft deprecated all versions of NTLM in June 2024, and NTLMv1 has been removed from Windows 11 24H2 and Windows Server 2025.
Audit, then restrict: set "Network security: Restrict NTLM: Audit NTLM authentication in this domain" and the matching incoming-traffic audit policy, review the NTLM Operational log, then move to "Restrict NTLM" deny settings with an exception list of servers.
Harden what remains: set "Network security: LAN Manager authentication level" to refuse LM and NTLMv1, require SMB signing, and enable LDAP channel binding and Extended Protection for Authentication, as the joint Five Eyes guidance recommends.

AES-only Kerberos

Restricting Kerberos to AES makes stolen hashes far less useful for requesting tickets and makes downgraded tickets easy to spot. Inventory RC4 with the encryption type fields in 4768 and 4769, reset old account passwords to create AES keys, then apply "Network security: Configure encryption types allowed for Kerberos" with AES128_HMAC_SHA1 and AES256_HMAC_SHA1 only. Windows Server 2025 domain controllers no longer issue RC4 ticket-granting tickets.

Implementation sequence

Deploy Windows LAPS to all devices and deny network logon for local accounts; this has the biggest effect for the least risk.
Define tiers and enforce logon restrictions in audit first: report violations for two to four weeks, fix workflows, then apply the deny rights by GPO. Roll back by unlinking the GPO.
Add human Tier 0 administrators to Protected Users in a pilot group, check events 100, 104, 303 and 304, then extend to Tier 1.
Enable Credential Guard through a pilot ring of devices, confirm application compatibility, then expand; avoid UEFI lock until you are confident, since it makes rollback harder.
Require Remote Credential Guard or Restricted Admin mode for administrative RDP.
Turn on NTLM auditing domain-wide, remove NTLMv1, then restrict NTLM server by server.
Move Kerberos to AES only, pilot OU first, watching for failure code 0xE in 4769.

Decision guidance

Remote Credential Guard or Restricted Admin: use Remote Credential Guard where administrators need their own identity on the remote host and Kerberos is available; use Restricted Admin for helpdesk tasks where the target's LAPS-managed local admin is enough.
Small organisations: LAPS, Protected Users for the few administrators, separate admin accounts and Credential Guard on Windows 11 deliver most of the benefit without a full tiering project.
Large estates: the hard part is NTLM and RC4 dependencies in legacy applications and appliances; budget time for the audit phase and track exceptions with an owner and an end date.

Framework mapping

Framework	Reference	How it applies
MITRE ATT&CK	T1550, T1550.002, T1550.003	Use of alternate authentication material: hashes and tickets
MITRE D3FEND	D3-CH Credential Hardening, D3-CRO Credential Rotation, D3-DAM Domain Account Monitoring	Credential Guard, LAPS rotation, logon monitoring
NIST SP 800-53 Rev. 5	AC-6(5), IA-5, AU-12, SI-4	Privileged account restriction, authenticator management, audit generation, monitoring
NIST CSF 2.0	PR.AA-01, PR.AA-05, DE.CM-01, RS.MI-02	Credential management, least privilege, monitoring, eradication

Incident response and recovery

Contain: isolate the source hosts and disable or reset the accounts seen replaying, starting with the most privileged.
Rotate: reset passwords for every account that logged on to compromised hosts, rotate LAPS passwords on affected devices, and reset computer account and service account secrets. A password reset invalidates a replayed hash; Kerberos tickets already issued stay valid until they expire, so also revoke sessions where possible.
Escalate if Tier 0 was touched: if any domain admin credential or domain controller was exposed, treat it as domain compromise and follow the krbtgt double reset described in the Golden Ticket, Silver Ticket and DCSync Guide and the Identity Recovery Guide.
Preserve evidence: keep domain controller and host Security logs and NTLM Operational logs for the incident window before any rebuild.

Lessons from incidents

Leaked hashes outlive the breach: the Cisco Active Directory credentials leak saw NTLM hashes of administrator, user, service and machine accounts from a 2022 intrusion republished in 2025. Any hash whose password was never changed would still be replayable, which is why rotation must cover non-human accounts as well as people.
One local admin password everywhere: the most common reason a single infected workstation becomes an estate-wide incident.
Administrators on ordinary workstations: a convenient domain admin logon to fix a desktop exposes Tier 0 credentials.
NTLM restrictions skipped because of one legacy system: the exception should be scoped to that server, not the domain.
Password reset without ticket expiry: responders reset an account and assume access is gone while existing tickets remain valid for hours.

Practitioner checklist

Deploy Windows LAPS to every Windows device and deny network and RDP logon for local accounts.
Enforce tiered logon restrictions so privileged accounts never sign in to lower-tier hosts.
Place human privileged accounts in Protected Users, keeping a tested break-glass account outside it.
Run Credential Guard on all eligible clients and member servers.
Require Remote Credential Guard or Restricted Admin mode for administrative RDP.
Audit NTLM, remove NTLMv1, require SMB signing and LDAP channel binding, and restrict NTLM by exception.
Move Kerberos to AES only and alert on RC4 in 4768 and 4769.
Alert on privileged NTLM network logons (4624 type 3) and on tickets used from unexpected hosts.
Include service, machine and LAPS secrets in every credential rotation after an incident.

Pass-the-Hash and Pass-the-Ticket Guide: Detecting and Preventing Credential Replay