Why PtH and PtT Remain Core Detection Priorities
Pass-the-Hash (PtH) and Pass-the-Ticket (PtT) are credential material reuse attacks. Rather than cracking a password, an attacker presents a stolen credential artefact directly to authentication protocols — an NTLM hash in the case of PtH, a Kerberos TGT or service ticket in the case of PtT. Both techniques are tool-independent: Impacket, Mimikatz, Rubeus, and CrackMapExec all implement them, but so does every capable red team framework.
They appear consistently across the attack chains of ransomware operators (Qilin, Black Basta, Akira affiliates), APT groups (APT28, APT29, Lazarus), and criminal intrusion clusters. If an attacker has obtained NTLM hashes via LSASS dumping, DCSync, or NTLM capture — and they usually have — lateral movement via PtH or PtT is the next logical step.
Pass-the-Hash (T1550.002)
How it works
NTLM authentication does not require a cleartext password — only the NT hash. An attacker who extracts NTLM: aad3b... from LSASS memory, an SAM dump, or a DCSync operation can use that hash directly with any tool that implements the NTLM handshake. No cracking required.
The attack works on local accounts (where the NT hash alone is sufficient), and on domain accounts where NTLM fallback is enabled. Pass-the-Hash does not work against services enforcing Kerberos-only authentication — a hardening control covered below.
Common tooling:
sekurlsa::pth(Mimikatz) — opens a process with a new logon session using the hashpth-winexe/pth-smbclient(Impacket suite)CrackMapExec --hash
Detection telemetry
Windows Event Log 4624 — Logon Success
A PtH logon produces Event ID 4624 with specific characteristics:
LogonType: 3(Network logon)AuthenticationPackageName: NTLMKeyLength: 0(indicates NTLMv2 with full hash, not challenge-response with password)
The combination of Type 3 + NTLM + KeyLength 0 is the primary PtH indicator. Most legitimate domain logons use Kerberos; NTLM Type 3 for lateral movement is elevated suspicion in well-configured environments.
Windows Event Log 4648 — Explicit Credential Logon
Mimikatz sekurlsa::pth creates a new logon session with alternate credentials, producing 4648 on the source host. The Subject (caller) differs from the Account Name (being impersonated).
Sigma rules
# Pass-the-Hash via NTLM Network Logon
title: Pass-the-Hash Lateral Movement via NTLM (T1550.002)
id: c3b4d8f2-9a11-4c6e-b773-d2ef3b4c1a90
status: test
description: Detects NTLM network logon with KeyLength 0, indicative of Pass-the-Hash
references:
- https://attack.mitre.org/techniques/T1550/002/
author: SOC Analyst Hub
date: 2026-06-14
tags:
- attack.lateral_movement
- attack.t1550.002
logsource:
product: windows
service: security
detection:
selection:
EventID: 4624
LogonType: 3
AuthenticationPackageName: 'NTLM'
KeyLength: 0
filter_anonymous:
SubjectUserName|endswith: '$'
TargetUserName: 'ANONYMOUS LOGON'
filter_local_admin:
TargetUserName|startswith: 'Administrator'
IpAddress: '127.0.0.1'
condition: selection and not filter_anonymous and not filter_local_admin
falsepositives:
- Legacy applications using NTLM authentication with no password
- Service accounts on old hardware without Kerberos support
level: medium
# Explicit Credential Logon from Non-Expected Process
title: Mimikatz Pass-the-Hash via Explicit Credential Logon (T1550.002)
id: e8a2d991-4b77-40c8-a3fe-8f1d4c90b262
status: test
description: Detects 4648 explicit credential logon events from suspicious process contexts
tags:
- attack.lateral_movement
- attack.t1550.002
logsource:
product: windows
service: security
detection:
selection:
EventID: 4648
filter_known_processes:
ProcessName|endswith:
- '\svchost.exe'
- '\taskhost.exe'
- '\services.exe'
- '\lsass.exe'
- '\winlogon.exe'
filter_same_user:
SubjectUserName: TargetUserName
condition: selection and not filter_known_processes and not filter_same_user
falsepositives:
- Scheduled tasks running under alternate credentials
- Administrative tooling that uses explicit credential logon by design
level: medium
KQL for Microsoft Sentinel
// Pass-the-Hash: NTLM Network Logon with KeyLength 0
SecurityEvent
| where EventID == 4624
| where LogonType == 3
| where AuthenticationPackageName == "NTLM"
| where KeyLength == 0
| where TargetUserName !endswith "$"
| where TargetUserName != "ANONYMOUS LOGON"
| where IpAddress !in ("127.0.0.1", "::1")
| project TimeGenerated, Computer, TargetUserName, TargetDomainName,
IpAddress, WorkstationName, ProcessName
| sort by TimeGenerated desc
Pass-the-Ticket (T1550.003)
How it works
Kerberos authenticates using encrypted tickets issued by the KDC. A Ticket Granting Ticket (TGT) is the primary session credential; Service Tickets (ST) grant access to specific services. Both are stored in memory and can be exported.
Overpass-the-Hash converts an NTLM hash into a Kerberos TGT using sekurlsa::pth /rc4: in Mimikatz or Rubeus asktgt /rc4:. This produces a full Kerberos ticket usable without the cleartext password.
Golden Ticket forges a TGT signed with the KRBTGT account hash. If the KRBTGT hash is compromised (via DCSync), an attacker can forge TGTs for any user, any time, valid for up to 10 years by default.
Silver Ticket forges a Service Ticket for a specific service using the service account’s hash. No KDC contact required.
Rubeus is the dominant tool for modern PtT attacks: Rubeus.exe asktgt, Rubeus.exe ptt /ticket:, Rubeus.exe dump.
Detection telemetry
Event ID 4768 — Kerberos TGT Request
Golden ticket usage produces anomalies in 4768:
TicketEncryptionType: 0x17(RC4-HMAC) in environments configured for AES — Golden Tickets are often forged with RC4 even when AES is available- Requests from machine accounts to user TGT (shouldn’t happen)
Event ID 4769 — Kerberos Service Ticket Request
Silver ticket usage typically skips TGT issuance — the forged ST is injected directly without a 4768 event. Absence of a corresponding 4768 before a 4769 is an anomaly.
Event ID 4776 — NTLM Credential Validation
Overpass-the-hash requests a TGT from the DC using NTLM hash material — this triggers 4776 on the DC before producing a 4768.
Sigma rules
# Golden Ticket: Kerberos TGT with RC4 Encryption in AES Environment
title: Possible Golden Ticket — Kerberos TGT with RC4 in AES-Capable Environment (T1550.003)
id: f2c9e741-8b33-4d1e-a99f-7c2e50b8d431
status: test
description: Detects Kerberos TGT requests using RC4-HMAC encryption in environments
where AES is available — indicative of forged Golden Tickets
references:
- https://attack.mitre.org/techniques/T1550/003/
- https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/kerberos-golden-tickets
tags:
- attack.credential_access
- attack.lateral_movement
- attack.t1550.003
logsource:
product: windows
service: security
detection:
selection:
EventID: 4768
TicketEncryptionType: '0x17'
Status: '0x0'
filter_computer_accounts:
AccountName|endswith: '$'
condition: selection and not filter_computer_accounts
falsepositives:
- Legacy clients (Windows XP era) in mixed environments
- Service accounts configured for RC4-only
level: high
# Rubeus Ticket Injection: Process Creating Suspicious Kerberos Artifact
title: Suspicious Kerberos Ticket Injection via Rubeus or Mimikatz (T1550.003)
id: a19d3e88-57c4-42b1-b6e7-934a71bc0529
status: experimental
description: Detects process command lines associated with Rubeus or Mimikatz Kerberos ticket manipulation
tags:
- attack.lateral_movement
- attack.t1550.003
logsource:
category: process_creation
product: windows
detection:
selection_rubeus:
CommandLine|contains:
- 'Rubeus.exe ptt'
- 'Rubeus ptt'
- 'asktgt'
- '/ticket:'
selection_mimikatz:
CommandLine|contains:
- 'kerberos::ptt'
- 'kerberos::golden'
- 'kerberos::silver'
- 'sekurlsa::tickets'
condition: selection_rubeus or selection_mimikatz
falsepositives:
- Authorised red team testing
level: critical
KQL for Microsoft Sentinel
// Golden Ticket detection: RC4 TGT in AES environment
SecurityEvent
| where EventID == 4768
| where TicketEncryptionType == "0x17"
| where Status == "0x0"
| where AccountName !endswith "$"
| extend AccountDomain = split(AccountName, "@")[1]
| project TimeGenerated, Computer, AccountName, AccountDomain,
ClientAddress, TicketEncryptionType
| sort by TimeGenerated desc
// Overpass-the-hash: NTLM validation followed by Kerberos TGT on same host
let ntlmEvents = SecurityEvent
| where EventID == 4776
| where Status == "0x0"
| project NtlmTime = TimeGenerated, Computer, AccountName;
let kerbEvents = SecurityEvent
| where EventID == 4768
| where TicketEncryptionType == "0x17"
| project KerbTime = TimeGenerated, Computer, AccountName;
ntlmEvents
| join kind=inner kerbEvents on Computer, AccountName
| where datetime_diff('second', KerbTime, NtlmTime) between (0 .. 30)
| project NtlmTime, KerbTime, Computer, AccountName
Hardening to Reduce Attack Surface
Enable Protected Users security group. Adding accounts to Protected Users forces Kerberos-only authentication, disables NTLM, and prevents credential caching. Domain admins and privileged service accounts should all be in Protected Users.
Disable NTLM where possible. Group Policy: Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers → Deny all. Audit mode first to identify dependencies. NTLM is required for some legacy systems and certain SMB configurations.
Enable Credential Guard. Windows Defender Credential Guard isolates LSASS in a virtualisation-based security container, making NTLM hash extraction from LSASS memory significantly harder.
Rotate KRBTGT password. The KRBTGT account password should be rotated twice (due to password history) after any suspected domain compromise. This invalidates all existing TGTs, including forged Golden Tickets.
Enforce AES Kerberos encryption. Disable RC4-HMAC (0x17) for Kerberos in Group Policy: Network Security: Configure encryption types allowed for Kerberos. Removing RC4 from permitted types forces AES for all ticket operations and breaks most Golden Ticket forgeries targeting lower encryption.
Monitor privileged account logons. Tier 0 accounts (Domain Admins, Enterprise Admins) should only appear in authentication logs on domain controllers and dedicated privileged access workstations. Any 4624/4768 event for these accounts on standard workstations or servers warrants immediate investigation.