Pass-the-Hash & Pass-the-Ticket: How Attackers Move Laterally — and How to Catch Them

Your domain controller logs show a perfectly normal Kerberos authentication at 2:47 AM. A service ticket was requested, access was granted, and the session ended cleanly. The problem: the user it belongs to has been on vacation for a week — and never logged in.

That’s a Pass-the-Ticket attack in the wild. No password was cracked. No alert fired. The attacker borrowed a credential they already had and walked through the front door.

TL;DR

• Pass-the-Hash (PtH) abuses NTLM hashes to authenticate without knowing the plaintext password
• Pass-the-Ticket (PtT) abuses stolen Kerberos tickets to authenticate without touching NTLM at all
• Both techniques leave detectable traces in Windows event logs — if you know what to look for
• Key Event IDs: 4624 (logon), 4648 (explicit credentials), 4768/4769 (Kerberos TGT/ST requests)
• Sigma rules can catch both techniques with surprisingly low false-positive rates when tuned correctly

What These Attacks Actually Are

Before diving into the technical details, it helps to understand what authentication material is being abused — and why Windows allows it.

Pass-the-Hash (PtH)

Windows NTLM authentication works by sending a hash of a password across the network, not the password itself. The design intent was to avoid transmitting plaintext credentials. The unintended consequence: if you capture the hash, you don’t need the password. The hash is the credential.

When an attacker runs PtH, they inject a stolen NTLM hash directly into a new process. Windows accepts it as a valid authentication token. The attacker now has access to any resource that user can reach — without ever knowing their actual password.

Pass-the-Ticket (PtT)

Kerberos authentication uses tickets instead of hashes. When you log in, a Ticket Granting Ticket (TGT) is issued by the domain controller. You then use that TGT to request Service Tickets (ST) for specific resources.

PtT steals either a TGT (powerful — allows requesting any service ticket) or a Service Ticket (narrower — access to one specific resource). The stolen ticket is injected into memory and used as if it were legitimately issued to the attacker’s session.

The key difference: PtH touches NTLM and leaves NTLM-specific log entries. PtT uses Kerberos entirely — and looks like normal Kerberos traffic unless you know what anomalies to watch for.

The Attacker’s Perspective

Step 1: Getting the Hash or Ticket

Both attacks require first obtaining credentials from a compromised machine. The most common source is LSASS memory — Windows stores authentication material there for active sessions.

# Mimikatz: dump all hashes from LSASS
sekurlsa::logonpasswords

# Mimikatz: dump Kerberos tickets from memory
sekurlsa::tickets /export

The logonpasswords command dumps NTLM hashes for every user with an active session. On a workstation where a domain admin recently logged in interactively, this means the attacker now has domain admin credentials — as a hash.

The tickets /export command writes .kirbi ticket files to disk for every active Kerberos session. These can be reimported later, even on a different machine.

See LSASS Dumping Techniques for a detailed breakdown of how attackers access LSASS and how to detect it.

Step 2: Pass-the-Hash in Practice

With a hash in hand, the attacker has several options:

# Mimikatz: spawn a new process authenticated with the hash
sekurlsa::pth /user:Administrator /domain:corp.local /ntlm:<hash> /run:cmd.exe

# Impacket: remote code execution via SMB using the hash
impacket-psexec corp.local/Administrator@192.168.1.10 -hashes :<ntlm_hash>

# CrackMapExec: spray the hash across the entire subnet
crackmapexec smb 192.168.1.0/24 -u Administrator -H <ntlm_hash>

The Mimikatz command opens a new cmd.exe window running under the context of the target user — using only the hash. No password prompt. No Kerberos ticket needed.

Impacket’s psexec creates a temporary Windows service on the target to achieve code execution. It leaves more traces than smbexec or wmiexec, but all three use the same hash-based authentication.

CrackMapExec’s spray approach is particularly dangerous during engagements — it can identify which machines accept the hash in seconds, mapping the entire blast radius of a single compromised account.

Step 3: Pass-the-Ticket in Practice

# Mimikatz: inject a stolen .kirbi ticket into current session
kerberos::ptt ticket.kirbi

# Rubeus: request a TGT using an NTLM hash (Overpass-the-Hash)
Rubeus.exe asktgt /user:Administrator /rc4:<ntlm_hash> /ptt

# Impacket: use a ccache ticket file for authentication
export KRB5CCNAME=/tmp/ticket.ccache
impacket-psexec -k -no-pass corp.local/Administrator@dc01.corp.local

The Rubeus asktgt command deserves special attention — it bridges PtH and PtT. It takes an NTLM hash, requests a legitimate Kerberos TGT from the domain controller, and injects it into memory. The result: a real, valid Kerberos ticket obtained without knowing the password. This technique (called Overpass-the-Hash or Pass-the-Key) is increasingly preferred because it produces cleaner Kerberos traffic that blends with legitimate activity.

What These Attacks Leave Behind

This is where the attacker’s operational security meets the defender’s detection opportunity. Both techniques leave evidence — the question is whether your logging is configured to capture it.

Pass-the-Hash: Event Log Signatures

Event ID 4624 — Successful Logon

PtH over the network produces a LogonType 3 event with specific fields that differ from legitimate NTLM logins:

The KeyLength: 0 combined with SubjectUserSid: S-1-0-0 is the most reliable indicator. Legitimate NTLMv2 sessions use a 128-bit session key. PtH sessions have no session key — it’s zeroed out because the authentication bypassed the normal challenge-response mechanism.

Event ID 4648 — Logon Using Explicit Credentials

This fires when a process authenticates using credentials different from the currently logged-in user. Mimikatz’s sekurlsa::pth always triggers this because it spawns a new process with injected credentials.

Watch for: 4648 events where SubjectUserName and TargetUserName differ, originating from unexpected processes (not runas.exe, svchost.exe, or other expected callers).

Pass-the-Ticket: Event Log Signatures

Event ID 4768 — Kerberos TGT Request

A TGT request from an unusual source IP or at an unusual time is a PtT indicator. Legitimate users request TGTs at login from their workstation’s IP. A TGT request from a server or from an IP that doesn’t match the user’s known workstation warrants investigation.

Event ID 4769 — Kerberos Service Ticket Request

The encryption type field is your best friend here:

RC4 (0x17) ticket requests in an environment that should be using AES indicate either a legacy misconfiguration or an attacker using older tools (Mimikatz’s default) or deliberately downgrading. In a modern AD environment, this alone is worth alerting on.

Event ID 4771 — Kerberos Pre-Authentication Failed

Unusual pre-auth failures from unexpected IPs, especially followed by a successful 4768, can indicate ticket enumeration or brute-force attempts preceding a PtT attack.

Building the Detections

Sigma Rule: Pass-the-Hash (PtH)

title: Pass-the-Hash Attack Detection
id: e54979bd-c5f9-4d6c-967b-a04b19ac4c74
status: stable
description: Detects Pass-the-Hash attacks via anomalous NTLM network logon characteristics
references:
  - https://attack.mitre.org/techniques/T1550/002/
author: HiveSecurity
date: 2026/04/18
tags:
  - attack.lateral_movement
  - attack.t1550.002
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 3
    LogonProcessName: 'NtLmSsp'
    KeyLength: 0
    SubjectUserSid: 'S-1-0-0'
  filter_local:
    # Exclude loopback and machine accounts
    IpAddress: '127.0.0.1'
  filter_machine:
    TargetUserName|endswith: '$'
  condition: selection and not 1 of filter_*
falsepositives:
  - Some legacy applications using older NTLM implementations
  - Misconfigured services using null sessions
level: high

This rule catches the core PtH signature: a network logon authenticated via NtLmSsp with no session key (KeyLength: 0) and a null subject SID. The filters remove machine account logins (which end in $) and loopback connections that can produce similar-looking events legitimately.

Sigma Rule: Pass-the-Ticket via RC4 Downgrade

title: Kerberos RC4 Ticket Request - Possible Pass-the-Ticket
id: 8a3b2c1d-4e5f-6789-abcd-ef0123456789
status: experimental
description: Detects Kerberos service ticket requests using RC4 encryption, which may indicate PtT or Kerberoasting
references:
  - https://attack.mitre.org/techniques/T1550/003/
author: HiveSecurity
date: 2026/04/18
tags:
  - attack.lateral_movement
  - attack.t1550.003
  - attack.credential_access
  - attack.t1558.003
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'  # RC4-HMAC
    Status: '0x0'                  # Success only
  filter_known_legacy:
    # Tune this to your environment's known legacy systems
    ServiceName|endswith: '$'
  condition: selection and not filter_known_legacy
falsepositives:
  - Legacy systems that legitimately require RC4
  - Environments with older domain functional levels
level: medium

Note the dual-purpose nature of this rule: RC4 ticket requests are a signature of both PtT (using older tools) and Kerberoasting. The distinction matters for response, but either warrants investigation.

Wazuh Configuration

Wazuh can detect both techniques using its built-in Windows log decoder combined with custom rules. Add these to your local_rules.xml:

<!-- Pass-the-Hash: KeyLength=0 + NtLmSsp + Network Logon -->
<rule id="100200" level="12">
  <if_group>windows</if_group>
  <field name="win.system.eventID">^4624$</field>
  <field name="win.eventdata.logonType">^3$</field>
  <field name="win.eventdata.logonProcessName">NtLmSsp</field>
  <field name="win.eventdata.keyLength">^0$</field>
  <description>Possible Pass-the-Hash: NTLM network logon with zero key length</description>
  <mitre>
    <id>T1550.002</id>
  </mitre>
</rule>

<!-- Pass-the-Ticket: RC4 service ticket request -->
<rule id="100201" level="10">
  <if_group>windows</if_group>
  <field name="win.system.eventID">^4769$</field>
  <field name="win.eventdata.ticketEncryptionType">^0x17$</field>
  <field name="win.eventdata.status">^0x0$</field>
  <description>Kerberos RC4 ticket request - possible Pass-the-Ticket or Kerberoasting</description>
  <mitre>
    <id>T1550.003</id>
  </mitre>
</rule>

<!-- Explicit credential use from unexpected process -->
<rule id="100202" level="8">
  <if_group>windows</if_group>
  <field name="win.system.eventID">^4648$</field>
  <field name="win.eventdata.processName" negate="yes">runas.exe|svchost.exe|lsass.exe</field>
  <description>Explicit credential logon from potentially unexpected process</description>
  <mitre>
    <id>T1550.002</id>
  </mitre>
</rule>

Set the severity levels based on your environment. Rule 100200 (PtH signature) should be at least level 12 — this is a high-fidelity detection with low expected false positives in properly configured environments.

Microsoft Sentinel KQL

For Sentinel users, the equivalent query for hunting PtH activity:

SecurityEvent
| where EventID == 4624
| where LogonType == 3
| where LogonProcessName == "NtLmSsp"
| where KeyLength == 0
| where SubjectUserSid == "S-1-0-0"
| where IpAddress != "127.0.0.1"
| where TargetUserName !endswith "$"
| project TimeGenerated, Computer, TargetUserName, IpAddress, WorkstationName
| sort by TimeGenerated desc

Run this as a scheduled analytics rule with a 5-minute window and severity High. In most environments this will produce zero results — which is why a single hit is worth investigating immediately.

Reducing Your Attack Surface

Detection is essential, but these attacks succeed partly because of configuration gaps that can be closed:

Enforce AES-only Kerberos — disable RC4 (DES and RC4 support) in Group Policy under Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Configure encryption types allowed for Kerberos. This breaks most PtT tools that default to RC4 and eliminates a class of Kerberoasting as well.

Enable Protected Users Security Group — add privileged accounts to this group. Members cannot authenticate using NTLM, cannot use DES or RC4 for Kerberos, and have their TGT lifetime capped at 4 hours. This directly blocks PtH for protected accounts and limits PtT blast radius.

Credential Guard — available on Windows 10/11 and Server 2016+. Moves LSASS into a virtualization-based isolated environment, making sekurlsa::logonpasswords fail. This doesn’t prevent all credential theft but eliminates the most common vector.

Tiered administration model — don’t let domain admins log in interactively to workstations or member servers. Kerberos tickets and NTLM hashes are only exposed on systems where accounts authenticate. If your domain admins only ever touch domain controllers via jump hosts, PtH from a compromised workstation can’t escalate to DA.

What You Can Do Today

1. Enable audit logon events — make sure Audit Logon and Audit Kerberos Service Ticket Operations are set to Success and Failure in your audit policy. Without this, the Event IDs above don’t exist.
2. Run the Sentinel KQL query against your last 30 days of logs — if you get hits, investigate now.
3. Check RC4 usage — query Event ID 4769 with TicketEncryptionType = 0x17 and see which accounts and services are generating it. Unexpected RC4 is a finding even without an active attack.
4. Add privileged accounts to Protected Users — test with one non-critical admin account first to verify no application dependencies break.
5. Deploy the Wazuh rules — low false-positive rate, high value. If you don’t have Wazuh, the same logic applies to any SIEM that ingests Windows Security logs.

Related Posts

• Kerberoasting: A Deep Dive — the credential attack that shares the RC4 signature with PtT, often confused with each other
• LSASS Dumping Techniques — how attackers obtain the hashes and tickets that PtH/PtT depend on
• AD Attack Chains: Initial Access to Domain Admin — where PtH and PtT fit in the full compromise chain
• Windows Event Log Security Analysis — broader guide to building detections from Windows event logs
• Active Directory Attacks Guide — the full map of AD attack techniques including credential abuse

Sources

• MITRE ATT&CK T1550.002 — Pass the Hash
• MITRE ATT&CK T1550.003 — Pass the Ticket
• SigmaHQ — Pass the Hash Activity 2
• Qualys ETM: Detect Pass-the-Hash and Pass-the-Ticket
• The Hacker Recipes — Pass the Hash
• Praetorian — Inside Mimikatz Pass-the-Hash