Detecting Pass-the-Hash attacks

Arun Kumar

2 months ago

Pass-the-Hash (PtH) is a credential abuse technique where an attacker uses a captured NTLM password hash to authenticate to other systems—without ever knowing the user’s plaintext password. In an Active Directory environment, PtH is primarily a lateral movement and privilege expansion tactic: once a usable hash is obtained (often from a workstation), the attacker pivots to servers, file shares, or admin endpoints until they reach high-value targets.

This guide focuses on how to detect PtH using Windows security telemetry, behavioral patterns, and identity-centric tooling—so you can spot it early, confirm it quickly, and contain it before it becomes a domain-wide incident.

What PtH looks like (and what it is not)

Core idea

What the attacker has: an NTLM hash for an account (often local admin, service account, or a domain user with admin rights somewhere).
What the attacker does: authenticates to remote systems via NTLM-based mechanisms (commonly SMB/RPC, remote service creation, WMI, scheduled tasks, WinRM in some cases).
Why it works: NTLM authentication can succeed using the hash material directly in certain flows.

Common confusion

PtH vs Pass-the-Ticket (PtT): PtT abuses Kerberos tickets, PtH abuses NTLM hashes. Many real intrusions use both depending on what’s available.
“Overpass-the-Hash” / “Pass-the-Key”: a related technique where the attacker uses hash/key material to obtain Kerberos tickets. You’ll often see Kerberos activity that “doesn’t match” typical user behavior.

If you want a solid refresher on how NTLM and Kerberos differ (and why NTLM-centric movement still happens in modern environments), start here: NTLM authentication and Kerberos Authentication Protocols Explained.

Detection mindset: focus on behavior, not just artifacts

PtH detection works best when you combine:

Authentication evidence (NTLM logons, credential validation, logon types, source hosts)
Lateral movement evidence (remote service creation, admin share access, remote management activity)
Credential access evidence (attempts to read LSASS memory, suspicious process access)
Account context (privileged users, service accounts, tier boundaries)

In practice, you rarely “prove PtH” from one event. You confirm PtH by correlating: who authenticated, from where, to what, how (NTLM), and what happened next.

Telemetry prerequisites (don’t skip this)

1) Windows Security auditing (Domain Controllers + endpoints)

You need Account Logon and Logon/Logoff auditing to reliably see NTLM usage and logon patterns. If you’re also using Microsoft Defender for Identity, getting your advanced audit policy right is foundational:

Event collection with Microsoft Defender for Identity (practical steps to enable advanced audit policy and ensure the right events are collected).

2) Centralize logs (SIEM / Sentinel / whatever you trust)

PtH detection is correlation-heavy. You’ll want a single place to query across DCs, member servers, and key workstations. If you’re hybrid, also consider identity events from the cloud side:

How to monitor and report security events in Microsoft Entra ID

3) Identity Threat Detection & Response (ITDR) signals

Defender for Identity (MDI) can enrich and detect identity-based attack behaviors. Make sure the deployment prerequisites and connectivity are correct so sensors can actually do their job:

Key requirements to implement Microsoft Defender for Identity

Where to look first: the “big 3” event views

View A: Target machine logons (member server / workstation)

On the destination system (where the attacker is trying to access), the most common anchor is:

Successful logons (look for Network-style logons)
Authentication method indicating NTLM usage
Source workstation / source IP that doesn’t fit normal patterns

What you’re hunting for:

Admin or privileged accounts authenticating to many endpoints (especially “east-west” movement).
Servers receiving NTLM network logons from unusual workstation subnets.
Logons occurring at odd times, or with “impossible travel” inside the LAN (same account across many hosts in minutes).

View B: Domain Controller credential validation (NTLM)

On Domain Controllers, NTLM credential validation is often visible through credential validation attempts. This helps you identify:

Which account was validated
Which workstation requested validation
Success vs failure patterns

This view is especially powerful for spotting password spraying or brute force that precedes hash theft—and for mapping unusual NTLM usage that might indicate legacy or abuse.

View C: Lockouts and repeated failures (early warning)

Attackers often generate noise before the “clean” successful PtH logons happen—especially if they’re testing access paths, trying multiple hashes, or hitting protected systems.

Use lockout/failure analysis as an early tripwire:

Account Lockout Event ID: How to Find Account Lockouts

High-signal PtH patterns to alert on

1) “NTLM used where it shouldn’t be”

If your environment is mostly Kerberos, NTLM usage stands out—especially for privileged identities.

Flag NTLM authentications for Tier 0 / Tier 1 admins.
Flag NTLM to sensitive servers (DCs, CA servers, ADFS/Entra Connect servers, management jump hosts).
Flag NTLM from workstation-to-workstation paths (common in intrusions, uncommon in disciplined ops).

2) “Fan-out” lateral movement

Classic PtH movement often looks like one source host authenticating to many targets in a short time window, using the same account (or a small set of accounts).

Same source workstation → many servers (or many workstations)
Same account → many targets
New or rare pairings: (Account A, Host X) that has little/no historical precedent

3) Privileged logon sequences that don’t match admin workflow

Most admin work has rhythm: jump host → management tools → a known server set. PtH often breaks that rhythm.

Privileged user logs into a random user workstation (unusual)
Privileged user logs into a server they never touch
Service account used interactively or from a workstation subnet

4) Evidence of credential dumping (the “before” of PtH)

PtH requires hashes. Hashes are typically stolen from LSASS memory, cached credential stores, or local SAM/SECURITY hives.

Alert when non-standard processes access LSASS
Alert on suspicious process injection / memory access patterns
Correlate with subsequent NTLM lateral movement from the same host

A practical detection playbook (triage flow)

Step 1: Start from a suspicious authentication

Pick your anchor event: a suspicious NTLM network logon to a server, or a spike in NTLM validations on a DC.

Step 2: Answer the 5 questions

Who authenticated? (user/service account; privilege level; tier)
From where? (source device, subnet, asset owner, posture)
To what? (target server role; business criticality)
How? (NTLM vs Kerberos; logon type; remote management path)
What next? (remote service creation, share access, new sessions, new processes)

Step 3: Pivot to “same account” and “same source”

Show all targets touched by that account in the last 1–6 hours
Show all authentications from that source device in the last 1–6 hours
Compare to historical baseline (last 7–30 days): is this new behavior?

Step 4: Confirm with supporting signals

Did the same source device show signs of credential access (LSASS access, suspicious tooling, unusual admin share activity)?
Did the attacker “fan out” to multiple hosts?
Is the account privileged or unusually powerful on those targets?

Step 5: Contain and scope

Isolate the suspected source endpoint (often the initial dumping host).
Reset credentials for impacted accounts (prioritize admins and service accounts).
Invalidate sessions where possible; rotate secrets used on multiple machines.
Hunt for additional compromised hosts using the same “fan-out” and NTLM anomaly patterns.

Reducing false positives (so alerts stay actionable)

NTLM isn’t always evil. Legacy apps, old devices, specific access paths (e.g., using IP instead of hostname) can trigger NTLM. The goal is not “alert on NTLM everywhere” but alert on risky NTLM.

Scope alerts to critical assets first (Tier 0 servers, admin jump hosts).
Scope alerts to privileged accounts first (Domain Admins, server admins, helpdesk elevation roles).
Baseline allowed NTLM (approved legacy systems) and create exceptions with ownership.
Use “new pairing” logic: (account, target) or (account, source) never seen before.

Hardening that improves detection (and reduces PtH success)

Even though this article is about detecting PtH, a few controls dramatically improve both signal quality and blast-radius reduction:

Tiering / admin separation: don’t let high-privilege creds touch low-trust endpoints.
Reduce NTLM surface: migrate to Kerberos where possible; control NTLM usage with policy.
Protect credential material: Credential Guard / LSASS protections where feasible.
Use strong local admin controls: unique local admin passwords and reduced lateral reuse opportunities.
Centralized logging + correlation: the difference between “we saw it later” and “we stopped it early”.

Quick “starter alerts” you can implement this week

Alert 1: Privileged account uses NTLM to access a Tier 0 / Tier 1 server.
Alert 2: Same account authenticates to > N distinct hosts in 10 minutes (fan-out).
Alert 3: A workstation authenticates via NTLM to multiple servers it has never touched before (new pairing burst).
Alert 4: Spike in NTLM validations on a DC from a single source workstation.
Alert 5: Lockouts/failures for admin identities originating from workstation subnets (early tripwire).