Pass-the-hash uses a stolen password hash to authenticate without recovering the password. Pass-the-ticket uses Kerberos ticket credentials to impersonate an account. Both can turn a compromised device into access elsewhere, but the credential, protocol and defensive response differ.
The useful question for a Windows security team is what an intruder could reuse from a particular computer, where that credential would be accepted, and what authority it carries. A successful authentication is not evidence that the rightful user initiated it.
The difference between hashes and tickets
| Question | Pass-the-hash | Pass-the-ticket |
|---|---|---|
| Credential reused | An NT password hash | A Kerberos ticket and associated session key |
| Typical mechanism | NTLM challenge-response authentication | Kerberos authentication using ticket credentials |
| Reach | Services accepting that account and authentication method | Depends on ticket type, validity, permissions and service checks |
| What the attacker can avoid | Recovering or typing the original password | Repeating the original user sign-in |
MITRE ATT&CK documents pass-the-hash and pass-the-ticket as distinct ways to reuse authentication material. Ticket forgery is another operation: a forged ticket can subsequently be used in a pass-the-ticket attempt. These labels describe actions, not mutually exclusive categories of intruder.
Why a password hash can be enough
In NTLM authentication, the client calculates a response to a challenge using password-derived secret material. The raw NT hash is not simply transmitted for the server to compare. Someone who obtains the hash may be able to calculate an accepted response without knowing the readable password.
Acceptance still depends on the account, destination and policy. A local administrator credential reused on several machines creates a different exposure from a domain account restricted to a small set of systems. Local and domain accounts should therefore be assessed separately.
A hash also has implications beyond classic NTLM pass-the-hash. Where Kerberos RC4-HMAC remains usable, the NT hash serves as a Kerberos key. Using key material to obtain new tickets differs from reusing an existing ticket. Our Aorato-era Active Directory RC4-HMAC explainer examines that distinction and the historical password-change disclosure.
What a Kerberos ticket lets someone do
Microsoft’s Kerberos overview explains the two main ticket roles. A ticket-granting ticket, or TGT, is used to request service tickets from the domain’s key distribution centre. A service ticket is presented to a particular service. Neither is an unrestricted master key: validity, identity, permissions and service-side validation matter.
Protect ticket credentials as secrets. Requiring a smart card or another strong method for the initial sign-in does not by itself stop reuse of ticket material stolen afterwards. The sign-in method and the security of an established session solve different parts of the problem.
Controls that reduce exposure
- Separate administrative work. Use dedicated administrative identities and trusted management devices. Reduce the number of lower-trust computers on which privileged accounts sign in.
- Protect stored credentials. Credential Guard uses virtualisation-based isolation to protect supported secrets, including NTLM hashes and Kerberos TGTs. Check its actual running state and deployment requirements; an operating-system name alone does not prove protection is active.
- Avoid shared local administrator passwords. Windows LAPS manages and rotates local administrator passwords. Unique passwords reduce reuse between devices. This does not replace controls for domain accounts.
- Reduce unnecessary authentication paths. Audit NTLM dependencies before restricting them. Plan application changes and rollback rather than disabling a protocol without knowing who depends on it.
- Review remote administration. Decide which credential-protection mode fits each connection. Our Restricted Admin guide explains why protection from remote credential theft and acceptance of an incoming stolen hash are separate questions.
Detection and response need context
Investigate account use from unfamiliar devices, unexpected access between systems and changes in administrative behaviour. Correlate authentication records with endpoint and network evidence. A normal-looking logon alone cannot distinguish the legitimate owner from someone using reusable secrets.
For containment, identify which account secrets, tickets and devices may be compromised before deciding what to reset or isolate. A password change replaces the current password-derived secret, but it does not universally terminate established connections or make every previously issued ticket unusable immediately. Logging off one computer also does not erase copies held elsewhere.
The separate Windows account-revocation guide explains why account disabling, ticket validity, existing sessions and offline cached sign-in must not be treated as one mechanism.
What changed after the 2014 research?
Microsoft’s 2014 security advisory 2871997 describes credential-protection improvements associated with that period. It is historical documentation, with later revisions, rather than a claim that one update eliminated every pass-the-hash route. Modern deployments need current supported software, verified settings and a clear inventory of exposed identities.
My recommendation is to start with privileged sign-in locations and shared local administrator credentials. Then verify credential isolation and remote-access policy. This produces a concrete reduction in reusable secrets without mistaking any single control for complete protection.
Share this article
Stuart Kerr Spindlow is Impulsec’s Publisher, Chief Editor and Lead Reviewer. He writes and maintains coverage of consumer cybersecurity and digital-safety software, with a focus on practical suitability, limitations and the evidence behind product claims. Read Stuart’s full profile.