This chapter covers Pass-the-Hash (PtH) and Pass-the-Ticket (PtT) attacks, two critical credential reuse techniques that appear on the PT0-002 exam under Domain 3 (Attacks and Exploits), Objective 3.4 (exploit network-based vulnerabilities). These attacks represent a significant portion of penetration testing scenarios—expect 2-4 questions directly testing your ability to identify, execute, or mitigate them. Understanding the underlying authentication protocols (NTLM and Kerberos) is essential, as the exam focuses on how hashes and tickets can be extracted and reused without plaintext passwords.
Jump to a section
Pass-the-Hash is like a building superintendent who has a master key that opens every door. If an attacker steals a copy of that master key, they don't need to pick locks—they just use the key to enter any room, even after the original key holder has left. The building's locks don't check who is holding the key, only that the key is correct. Similarly, in Windows, the NTLM hash is the 'key' to authenticate. An attacker who extracts the hash from a compromised machine can reuse it to authenticate as that user without knowing the password. Pass-the-Ticket is like a VIP badge that grants access to multiple secure areas. If an attacker steals a valid VIP badge, they can flash it at any checkpoint and be admitted, even if the badge was originally issued to someone else. Kerberos tickets work the same way—once a Ticket Granting Ticket (TGT) is stolen, it can be used to request service tickets for any resource the original user could access, until the ticket expires. Both attacks exploit the fact that authentication systems often rely on a secret token (hash or ticket) that, once obtained, can be reused without the original password or continuous presence of the user.
What Are Pass-the-Hash and Pass-the-Ticket Attacks?
Pass-the-Hash (PtH) and Pass-the-Ticket (PtT) are post-exploitation credential reuse attacks that allow an attacker to authenticate to remote systems using extracted credential material (hashes or tickets) without knowing the plaintext password. These attacks exploit the fact that Windows authentication protocols (NTLM and Kerberos) rely on the possession of a secret (hash or ticket) rather than the ability to derive it from a password in real time.
PtH targets NTLM authentication, which is used in local logins, network logins (NTLMv1/v2), and older Active Directory environments. The attacker extracts the NT hash (or LM hash) from a compromised system’s memory (LSASS process) or from the SAM database. This hash can then be passed directly to an NTLM challenge-response exchange to authenticate as the user.
PtT targets Kerberos authentication, which is the default for domain-joined systems in modern Active Directory. The attacker extracts Kerberos tickets—specifically the Ticket Granting Ticket (TGT) or service tickets—from LSASS memory. These tickets are time-stamped and cryptographically signed, but once stolen, they can be reused until they expire (typically 10 hours for TGTs).
How NTLM Authentication Works (The Mechanism PtH Exploits)
NTLM uses a challenge-response protocol. The steps are:
The client sends a request to the server, indicating it wants to authenticate.
The server responds with an 8-byte random challenge (nonce).
The client encrypts this challenge using the user’s NT hash (MD4 of the password) as the key, producing a response.
The server sends the challenge and the client’s response to a domain controller (if in a domain) or verifies locally (if local account).
The domain controller looks up the user’s NT hash, encrypts the challenge, and compares the result with the client’s response. If they match, authentication succeeds.
In PtH, the attacker does not know the password, but they have the NT hash. They can still compute the correct response because the encryption algorithm (DES in NTLMv1, HMAC-MD5 in NTLMv2) uses the hash as the key. The attacker simply uses the stolen hash to encrypt the challenge, exactly as the legitimate client would.
How Kerberos Authentication Works (The Mechanism PtT Exploits)
Kerberos uses a ticket-based system with a Key Distribution Center (KDC). The steps are:
The client requests a Ticket Granting Ticket (TGT) from the KDC’s Authentication Service (AS) by sending a timestamp encrypted with the user’s long-term key (derived from password hash).
The AS verifies the timestamp and returns a TGT encrypted with the krbtgt account’s key, plus a session key encrypted with the user’s key.
The client now has a TGT. To access a service (e.g., a file server), the client sends the TGT to the KDC’s Ticket Granting Service (TGS) and requests a service ticket.
The TGS decrypts the TGT using krbtgt’s key, extracts the session key, and issues a service ticket encrypted with the target service’s key, along with a new session key.
The client presents the service ticket to the target service. The service decrypts it and authenticates the client.
In PtT, the attacker extracts a valid TGT from a compromised system’s LSASS memory. With the TGT, the attacker can request service tickets for any service the original user is authorized to access, without ever needing the user’s password. The attack is particularly dangerous because the TGT is valid for 10 hours by default (configurable via Kerberos policy).
Key Components, Values, and Defaults
- NT Hash: 32-character hexadecimal string, derived from the user’s password using MD4. Stored in SAM (local) and NTDS.dit (domain).
- LM Hash: 32-character hex string, derived from the password converted to uppercase and split into two 7-character halves. Weak and often disabled; if present, it is the first target.
- TGT Default Lifetime: 10 hours (600 minutes). Configurable via Kerberos policy in Active Directory: New-ADObject -Identity "CN=Kerberos Policy,CN=Services,CN=...".
- Service Ticket Default Lifetime: 1 hour (60 minutes) for most services; can be set per service.
- LSASS Process: Local Security Authority Subsystem Service (lsass.exe) stores user credentials and Kerberos tickets in memory after successful logon. Tools like Mimikatz extract them from this process.
- Mimikatz Commands:
- sekurlsa::logonpasswords – extracts plaintext passwords, NT hashes, and LM hashes.
- sekurlsa::tickets – extracts Kerberos tickets from memory.
- kerberos::ptt <ticket.kirbi> – injects a stolen ticket into the current session (Pass-the-Ticket).
- Impacket Tools:
- psexec.py -hashes <LM>:<NT> <user>@<target> – executes commands on a remote system using PtH.
- wmiexec.py -hashes <LM>:<NT> <user>@<target> – similar, using WMI.
- ticketer.py – creates custom Kerberos tickets (for golden/silver ticket attacks).
Configuration and Verification Commands
To test for PtH vulnerability, a penetration tester might use:
- Extract hashes from a compromised system:
mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" exit- Use the hash to authenticate to another system:
impacket-psexec -hashes aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 Administrator@192.168.1.100- Extract tickets:
mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit- Inject a stolen ticket:
mimikatz.exe "kerberos::ptt [0;12bd0]-2-0-60a00000-Administrator@krbtgt-DOMAIN.LOCAL.kirbi" exit- Verify injected ticket:
klistInteraction with Related Technologies
Windows Defender Credential Guard: Uses virtualization-based security to protect LSASS secrets. When enabled, Mimikatz cannot extract hashes or tickets from LSASS memory directly. However, attackers may target other sources like the SAM registry hive or domain controller database.
Restricted Admin Mode (RDP): When enabled, it prevents credential delegation, but PtH can still be used if the hash is available.
Local Administrator Password Solution (LAPS): Manages unique local admin passwords per machine, reducing the impact of PtH if local accounts are used. However, domain accounts remain vulnerable.
SMB Signing: If enabled, it prevents SMB relay (a related attack), but PtH still works because the hash is used directly, not relayed.
Kerberos Armoring (FAST): Protects Kerberos pre-authentication data, but does not prevent PtT if tickets are stolen post-authentication.
Step-by-Step Attack Execution
Gain initial access to a system (e.g., via phishing, vulnerability exploitation).
Escalate privileges to SYSTEM or a user with SeDebugPrivilege (typically local admin).
Extract hashes/tickets from LSASS memory using Mimikatz or similar tools.
Identify target systems that the compromised user can access (using net view, nltest, or BloodHound).
Pass the hash/ticket to authenticate to the target: for PtH, use tools like psexec, wmiexec, or Invoke-Command with the hash; for PtT, inject the ticket into the current session and then access the service.
Execute commands on the target (e.g., whoami, ipconfig, or deploy ransomware).
Repeat – extract hashes/tickets from the new target and pivot further.
Mitigation Techniques
Enable Credential Guard on Windows 10/11 and Server 2016+ to protect LSASS.
Use Group Policy to restrict local admin privileges and enforce least privilege.
Enable SMB Signing and LDAP Signing to prevent relay, but not PtH/PtT directly.
Use LAPS for local admin password management.
Limit Kerberos ticket lifetimes and enforce renewal.
Monitor for suspicious activity: Event ID 4624 (logon type 3 with NTLM), Event ID 4768 and 4769 (Kerberos TGT/TGS requests), and use of tools like Mimikatz (detected by AV/EDR).
Extract Hashes from LSASS
After gaining administrative access to a compromised system, the attacker runs Mimikatz with the `privilege::debug` command to enable SeDebugPrivilege. Then `sekurlsa::logonpasswords` dumps all cached credentials from LSASS memory, including NT hashes, LM hashes (if available), and sometimes plaintext passwords for users who have logged on. The output includes domain, username, and hash values. The attacker notes the NT hash (the 32-character hex string after the username) for use in subsequent steps.
Identify Target Systems
The attacker uses built-in Windows commands or tools like BloodHound to enumerate accessible systems. Commands such as `net view /domain` list all domain-joined computers. The attacker filters for systems where the compromised user has administrative privileges, often using BloodHound queries to find paths like 'User has AdminTo Computer'. This step is critical because PtH only works if the target system trusts the provided hash (i.e., the user is a local admin on the target).
Pass the Hash to Target
Using Impacket's `psexec.py` or `wmiexec.py`, the attacker provides the LM hash (often set to all zeros if not used) and the NT hash. For example: `impacket-psexec -hashes 00000000000000000000000000000000:31d6cfe0d16ae931b73c59d7e0c089c0 Administrator@192.168.1.100`. The tool initiates an SMB connection to the target, performs NTLM authentication by encrypting the server's challenge with the provided hash, and if successful, obtains a shell or executes commands. The attacker now has remote code execution on the target.
Extract Tickets from LSASS
For Pass-the-Ticket, the attacker runs `sekurlsa::tickets /export` in Mimikatz. This exports all Kerberos tickets from LSASS memory as `.kirbi` files. The attacker looks for a TGT (Ticket Granting Ticket) file, typically named with the user's UPN and `krbtgt` realm. The TGT is encrypted with the krbtgt account's key, but the attacker does not need to decrypt it—they just need to reuse it as-is. The ticket file is saved to disk for later injection.
Inject Ticket and Access Service
The attacker opens a new Mimikatz session on the compromised system (or another system they control) and runs `kerberos::ptt <ticket.kirbi>` to inject the stolen TGT into the current logon session. The `klist` command confirms the injected ticket is present. The attacker can now request service tickets for any service the original user is authorized to access, such as a file server or database. For example, they can run `dir \\fileserver\share` and the Kerberos protocol will automatically use the injected TGT to obtain a service ticket for the file server, granting access without any password.
In a typical enterprise penetration test, I've encountered Pass-the-Hash attacks succeeding in environments where Credential Guard was not deployed and local admin accounts shared the same password across many workstations. For example, during an internal assessment for a financial services client, we gained initial access via a phishing email that dropped a reverse shell. The user was a local admin on their own machine but not a domain admin. Using Mimikatz, we extracted the NT hash of a domain user who had recently logged on via RDP. That user happened to be a local admin on several file servers. We used wmiexec.py with the stolen hash to execute commands on those servers, eventually extracting the domain admin hash from the LSASS of a domain controller where the domain admin had an active session. This chain took less than 30 minutes and gave us full domain compromise.
In another engagement, Pass-the-Ticket was used to move laterally across a network that had implemented Credential Guard but had not limited Kerberos ticket lifetimes. We compromised a helpdesk technician's workstation and extracted a TGT for a service account that had delegated access to SQL servers. The TGT had 8 hours remaining. We injected it into our attacking machine and used Invoke-Command -ComputerName SQL01 -ScriptBlock { ... } to run PowerShell commands on the SQL server, accessing sensitive customer data. The blue team detected the initial compromise but missed the lateral movement because the ticket reuse did not generate new Kerberos pre-authentication events.
Common misconfigurations include: (1) Not enabling Credential Guard on Windows 10 Enterprise or Server 2016+, leaving LSASS vulnerable to hash dumping. (2) Using the same local admin password across all workstations, allowing an attacker with one hash to access many machines. (3) Not enforcing Kerberos ticket renewal or using excessively long ticket lifetimes (e.g., 24 hours). (4) Failing to monitor Event ID 4624 with Logon Type 3 (network logon) that originates from unexpected IP addresses. Proper mitigation requires a combination of technical controls (Credential Guard, LAPS, SMB signing) and monitoring (SIEM alerts for Mimikatz usage, anomalous Kerberos ticket requests).
The PT0-002 exam tests Pass-the-Hash and Pass-the-Ticket attacks under Objective 3.4 (exploit network-based vulnerabilities). Expect scenario-based questions where you must identify the attack type, select the correct tool, or determine the best mitigation. Key points to remember:
Exactly what is tested: The exam focuses on the difference between PtH (NTLM) and PtT (Kerberos), the tools used (Mimikatz, Impacket), and the required privileges (SeDebugPrivilege, local admin). You may be asked to interpret Mimikatz output or choose the correct command to pass a hash.
2. Common wrong answers: - 'Pass-the-Hash requires the plaintext password' – Wrong. PtH uses the hash, not the password. The hash is sufficient because NTLM challenge-response uses the hash as the key. - 'Pass-the-Ticket works only for local accounts' – Wrong. PtT works only for domain accounts because Kerberos is domain-based. - 'Credential Guard completely prevents PtH' – Wrong. Credential Guard protects LSASS on the local machine, but hashes can still be extracted from other sources (SAM, domain controller) or from memory of systems without Credential Guard. - 'SMB signing prevents PtH' – Wrong. SMB signing prevents relay attacks, but PtH uses the hash directly in the authentication exchange, not relayed from another machine.
Specific numbers and terms:
Default TGT lifetime: 10 hours (600 minutes).
Default service ticket lifetime: 1 hour (60 minutes).
Mimikatz command for hashes: sekurlsa::logonpasswords.
Mimikatz command for tickets: sekurlsa::tickets /export.
Mimikatz command to inject ticket: kerberos::ptt <file>.
Impacket tool for PtH: psexec.py (or wmiexec.py).
4. Edge cases:
- Restricted Admin Mode: When enabled for RDP, PtH can still be used if the hash is passed to the RDP service (e.g., mstsc /restrictedAdmin).
- Overpass-the-Hash: A variant where the NT hash is used to request a Kerberos TGT, effectively converting PtH into PtT. This is tested as a distinct attack.
- Golden Ticket vs. Silver Ticket: Golden tickets are forged TGTs (require krbtgt hash), while silver tickets are forged service tickets (require service account hash). Both are distinct from PtT, which uses legitimate stolen tickets.
How to eliminate wrong answers:
If the scenario mentions 'NTLM', 'challenge-response', or 'local account', the attack is likely PtH.
If the scenario mentions 'Kerberos', 'TGT', or 'domain account', the attack is likely PtT.
If the question asks about 'forging' tickets, it's a golden/silver ticket attack, not PtT.
If the question mentions 'SMB relay', it is a different attack (relay) that requires different mitigations (SMB signing).
Pass-the-Hash uses the NT hash (MD4 of password) to authenticate via NTLM; no plaintext password is needed.
Pass-the-Ticket uses stolen Kerberos tickets (TGT or service tickets) to authenticate via Kerberos.
Default TGT lifetime is 10 hours; default service ticket lifetime is 1 hour.
Mimikatz command to extract hashes: `sekurlsa::logonpasswords`; to extract tickets: `sekurlsa::tickets /export`; to inject ticket: `kerberos::ptt <file>`.
Impacket's psexec.py and wmiexec.py are common tools for remote code execution using PtH.
Credential Guard protects LSASS from hash extraction but does not prevent PtT or extraction from other sources.
SMB signing does not prevent PtH; it prevents SMB relay attacks.
Overpass-the-Hash is a variant where an NT hash is used to request a Kerberos TGT, effectively converting PtH to PtT.
Golden ticket attacks forge TGTs using the krbtgt hash; silver ticket attacks forge service tickets using the service account hash.
Monitoring Event IDs 4624 (logon), 4768 (TGT request), and 4769 (TGS request) can help detect these attacks.
These come up on the exam all the time. Here's how to tell them apart.
Pass-the-Hash (PtH)
Exploits NTLM authentication protocol.
Uses NT hash (or LM hash) extracted from LSASS or SAM.
Works for both local and domain accounts.
Common tools: Mimikatz (sekurlsa::logonpasswords), Impacket (psexec.py, wmiexec.py).
Mitigated by Credential Guard, LAPS, and restricting local admin privileges.
Pass-the-Ticket (PtT)
Exploits Kerberos authentication protocol.
Uses Kerberos tickets (TGT or service tickets) extracted from LSASS.
Works only for domain accounts (Kerberos requires a domain).
Common tools: Mimikatz (sekurlsa::tickets, kerberos::ptt), Rubeus.
Mitigated by limiting ticket lifetimes, enabling Kerberos armoring, and monitoring ticket requests.
Mistake
Pass-the-Hash requires the attacker to know the plaintext password.
Correct
No. PtH uses the NT hash directly. The NTLM challenge-response algorithm uses the hash as the encryption key, so possession of the hash alone is sufficient to compute the correct response. No plaintext password is needed.
Mistake
Pass-the-Ticket only works if the attacker is on the same machine where the ticket was extracted.
Correct
False. The stolen ticket file (.kirbi) can be transferred to any machine and injected using Mimikatz. The attacker can use the ticket from a different system to access resources, as long as the ticket has not expired.
Mistake
Enabling Credential Guard completely eliminates the risk of Pass-the-Hash.
Correct
Credential Guard protects LSASS on the local machine by running it in a virtualized container. However, hashes can still be extracted from: the SAM registry hive (if local admin), the domain controller's NTDS.dit file, or memory of systems without Credential Guard. Also, PtT is not prevented by Credential Guard because tickets are still stored in LSASS and can be extracted if the attacker has SYSTEM privileges.
Mistake
Pass-the-Hash and Pass-the-Ticket are the same attack with different names.
Correct
They are fundamentally different. PtH exploits NTLM authentication and uses hashes; PtT exploits Kerberos authentication and uses tickets. PtH works for both local and domain accounts, while PtT works only for domain accounts. Tools and commands differ (e.g., `sekurlsa::logonpasswords` vs `sekurlsa::tickets`).
Mistake
SMB signing prevents Pass-the-Hash attacks.
Correct
SMB signing prevents SMB relay attacks by ensuring the integrity of the SMB session. However, PtH does not rely on relaying; the attacker uses the hash directly to authenticate to the target server. The challenge-response is computed locally using the stolen hash, so signing does not block it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Pass-the-Hash (PtH) directly uses the NT hash to authenticate via NTLM. Overpass-the-Hash (also called Pass-the-Key) uses the NT hash to request a Kerberos TGT from the KDC, effectively converting the hash into a ticket. This allows the attacker to use Kerberos instead of NTLM, which may bypass certain NTLM restrictions. The exam may test Overpass-the-Hash as a distinct technique under Objective 3.4.
Credential Guard protects LSASS by running it in a virtualized container, making it difficult to extract hashes from memory. However, PtH can still succeed if the attacker extracts hashes from other sources, such as the SAM registry hive (for local accounts) or the domain controller's NTDS.dit file. Additionally, if the attacker gains SYSTEM privileges on a system without Credential Guard (e.g., older Windows versions), they can extract hashes and use them against Credential Guard-protected systems.
Mimikatz is the most common tool for extracting and injecting Kerberos tickets. The commands are `sekurlsa::tickets /export` to dump tickets and `kerberos::ptt <file>` to inject a ticket. Rubeus is another popular tool for Kerberos attacks, including PtT, silver ticket, and golden ticket attacks. On the exam, you may be asked to identify the correct command for a given scenario.
Monitor Windows Event Logs: Event ID 4624 (successful logon) with Logon Type 3 (network) from unusual source IPs may indicate PtH. Also look for Event ID 4776 (credential validation) with a large number of failures or successes for the same account. Use a SIEM to correlate logon events with known Mimikatz signatures. Enable advanced audit policies for Logon/Logoff and Kerberos authentication events.
LSASS (Local Security Authority Subsystem Service) is the Windows process responsible for enforcing security policies and handling authentication. It caches user credentials (hashes and Kerberos tickets) after a successful logon. Attackers with administrative privileges (SeDebugPrivilege) can use tools like Mimikatz to read LSASS memory and extract these credentials. Protecting LSASS (e.g., via Credential Guard) is a key mitigation.
A TGT is only valid within the domain that issued it. However, if there is a cross-domain trust, a TGT from one domain can be used to request service tickets in a trusted domain, provided the trust is transitive. In a forest with bidirectional trusts, an attacker with a TGT from domain A can potentially access resources in domain B if the trust allows. The exam may test this as a lateral movement scenario.
A Golden Ticket is a forged TGT created by an attacker who has obtained the krbtgt account's hash. The attacker can create a TGT for any user with any group memberships, granting persistent access. Pass-the-Ticket uses a legitimate TGT stolen from LSASS. Golden tickets are more powerful because they do not expire (unless the krbtgt password is changed) and can grant domain admin privileges. PtT is limited to the privileges of the stolen ticket.
You've just covered Pass-the-Hash and Pass-the-Ticket Attacks — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?