Pass-the-Hash in Active Directory: Detection and Mitigation

What Is Pass-the-Hash?

Pass-the-Hash is a method of authenticating with stolen NTLM-derived credential material instead of the user's cleartext password. In practice, the attacker steals reusable authentication material from a compromised Windows system and uses it to access another host or service as that user.

For this article, the scope is deliberately narrow: Windows, Active Directory, NTLM, and lateral movement. This is not a generic credential-theft article. The focus is the specific operating model that makes Pass-the-Hash relevant in enterprise AD environments: a compromised workstation or server, reusable credential material on that system, and a second host that still accepts NTLM-based authentication.

That distinction matters because Pass-the-Hash is often mixed together with several adjacent techniques:

Password spraying guesses common passwords across many accounts and does not require stolen hashes.
Pass-the-Ticket uses stolen Kerberos tickets, not NTLM-derived material.
Overpass-the-Hash uses NTLM-derived material to obtain Kerberos authentication material and then pivots into Kerberos-based access.
Kerberoasting requests service tickets and cracks them offline to recover service-account passwords.

Pass-the-Hash is its own problem: the attacker already has reusable authentication material and does not need to know the password in clear text to keep moving.

How Pass-the-Hash Works

MITRE classifies Pass-the-Hash as T1550.002, a sub-technique of Use Alternate Authentication Material. The core idea is simple: Windows and related authentication flows generate and retain authentication material after a user logs on, and that material can sometimes be reused if an attacker steals it.

In Windows environments, NTLM remains the main reason Pass-the-Hash is still operationally relevant. If a remote target accepts NTLM, the attacker may be able to present stolen NTLM-derived material and authenticate without ever learning the cleartext password. That is why reducing NTLM usage and reducing where reusable credentials land are both central defenses.

The practical source of reusable material is usually one of these paths:

LSASS memory on a compromised endpoint or server after the victim has signed in
SAM / SECURITY hives for local-account material on the host
Shared local administrator credentials reused across many systems
Credential-dumping after the attacker already has local admin or equivalent execution on a host

Microsoft's Credential Guard documentation is useful here because it explains what the feature is actually protecting: NTLM, Kerberos, and Credential Manager secrets are isolated with virtualization-based security instead of being left only in the normal LSASS process space. That does not eliminate all credential-theft risk, but it materially changes the attack surface for classic PtH workflows.

Preconditions for a Successful Pass-the-Hash Attack

Pass-the-Hash usually succeeds only when several conditions line up.

1. The attacker already compromised a Windows host

Pass-the-Hash is rarely the first move. The attacker typically begins with phishing, malware, exploited remote access, weak local admin hygiene, or another initial foothold. PtH then becomes a lateral-movement technique.

2. Reusable credential material is present on the compromised system

This is the central requirement. If privileged users log on to lower-trust systems, if administrators use RDP without stronger protections, or if servers accumulate reusable admin credentials in LSASS, the attacker has something to steal.

3. The next target still accepts NTLM authentication

The technique is much harder to use if the environment has reduced NTLM reliance, hardened remote admin patterns, or moved critical workflows away from reusable NTLM-backed authentication paths.

4. The compromised credential still has meaningful rights elsewhere

A stolen low-value account hash is far less useful than the material of a local administrator reused across endpoints, a helpdesk account with broad admin reach, or a privileged AD account that signs into member servers.

5. Administrative hygiene is weak enough to let the attacker chain hosts

This is why Pass-the-Hash is tightly connected to lateral movement, not just credential theft. If local admin passwords are unique, privileged admins use dedicated workstations, and privileged credentials do not land on lower-tier systems, the attacker loses the path that makes PtH valuable.

The Attack Chain

A typical Pass-the-Hash sequence in an AD environment looks like this.

Step 1 - Gain code execution on an initial host

The attacker compromises a workstation or server through phishing, malware, vulnerable software, or a preexisting access path.

Step 2 - Dump reusable material

Once the attacker has the required privileges on that host, they target LSASS or local credential stores and extract reusable material. MITRE explicitly maps tooling such as Mimikatz to Pass-the-Hash use: its SEKURLSA::Pth module "can impersonate a user, with only a password hash, to execute arbitrary commands."

Step 3 - Identify the best account to reuse

The attacker does not need every account. They need the account that can reach the next system. In real environments this often means:

a reused local administrator account
a helpdesk or endpoint admin identity
a server admin account that touched many hosts
a privileged AD account that should never have landed on that endpoint

Step 4 - Authenticate to another host using NTLM-backed access

At this point the attacker moves laterally through administrative protocols, remote service creation, SMB-based admin access, WMI, scheduled tasks, or other Windows management paths that still accept the reused material.

Step 5 - Repeat until the attacker reaches a privileged tier

The danger of Pass-the-Hash is not one hop. The danger is the chain. One compromised workstation leads to another admin context, then to a management server, then to a server where higher-value credentials are present, and eventually to domain or enterprise control. That is the same operational logic described more broadly in Active Directory Attack Paths to Domain Admin: each weak credential boundary makes the next hop easier.

Pass-the-Hash vs. Overpass-the-Hash vs. Pass-the-Ticket

These techniques are related but they are not interchangeable.

Pass-the-Hash stays centered on NTLM-derived authentication material and NTLM-accepted access paths.

Overpass-the-Hash starts from NTLM-derived material but uses it to obtain Kerberos authentication material, effectively pivoting from NTLM-derived secrets into Kerberos-based access.

Pass-the-Ticket skips NTLM-derived material and reuses stolen Kerberos tickets directly.

That distinction matters for both detection and remediation. If defenders collapse them into one concept, they usually build a weak detection strategy and apply the wrong mitigations to the wrong path.

Detection

There is no single Windows event that says "this was Pass-the-Hash." A usable detection strategy is a correlation strategy.

MITRE's Windows detection strategy for T1550.002 is directionally correct: it flags anomalous NTLM LogonType 3 authentications that occur without accompanying domain logon events, correlated with process, session, and network context rather than relying on one indicator in isolation.

What to look for

4624 patterns

4624 (An account was successfully logged on) is useful when you care about where the session appeared, what logon type it used, and which account context is unexpected on that system.

High-value examples include:

a network logon that places an admin identity on a host it rarely touches
repeated lateral movement from one compromised workstation into multiple peers or servers
a reused local admin identity showing up across several endpoints

4672 on the destination

4672 (Special privileges assigned to new logon) is helpful when a new logon receives special privileges on the target system. It is not a PtH detector by itself, but it helps identify which remote logons actually matter.

NTLM context where available

Where your telemetry captures NTLM authentication context, that is valuable because PtH lives or dies on NTLM-accepted access paths. The goal is not to alert on every NTLM event. The goal is to identify unexpected NTLM-backed administrative activity involving accounts, systems, or paths that do not normally pair together.

Unusual privileged movement across hosts

The strongest signals often come from behavior, not a single event ID:

the same admin identity appearing across multiple hosts in a short window
local administrator context reused on hosts that should each have unique admin passwords
administrative access starting from a workstation that is not part of the normal admin workflow

EDR signals for credential dumping and LSASS access

Pass-the-Hash typically depends on credential theft first. If your EDR shows suspicious LSASS access, credential-dumping behavior, or follow-on remote admin activity from the same host, that correlation is usually more valuable than a standalone event-based rule.

Example detection framing

Do not frame detections as "4624 means Pass-the-Hash." A better frame is:

suspicious credential-access behavior on host A
followed by NTLM-backed remote logon or admin activity on host B
using an account context that does not match the normal source system or admin workflow

That is the level at which defenders actually catch PtH.

Monitoring dependency

If you are weak on AD and Windows monitoring, this technique will be easy to miss. That is why Active Directory Monitoring: Security Event IDs That Matter belongs in the same control family as PtH detection.

Remediation

Pass-the-Hash remediation is not one setting. It is a strategy to reduce where reusable credential material exists, reduce where NTLM is still accepted, and reduce how far one stolen admin context can travel.

1. Enable Credential Guard where it is supported

Microsoft states that Credential Guard protects NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials, by isolating them with virtualization-based security. This is one of the most direct mitigations against classic credential-theft workflows that enable PtH.

Before you plan a rollout, check what is already on. Since Windows 11, version 22H2 and Windows Server 2025, Credential Guard is enabled by default on domain-joined systems that meet the hardware and licensing requirements and are not domain controllers. In many current estates the work is confirming it is still enabled, not switching it on from scratch.

Important caveats, from Microsoft's Credential Guard protection limits:

some authentication capabilities are blocked, so applications must be tested before rollout
local accounts and Microsoft accounts are not protected. Credential Guard covers domain-derived secrets, so the local-account material behind a reused local administrator stays exposed
supplied credentials for NTLM authentication are not protected: Microsoft states that if a user is prompted for and enters credentials for NTLM authentication, those credentials are vulnerable to be read from LSASS memory
Kerberos service tickets are not protected either; only the Kerberos TGT is
Microsoft explicitly says enabling Credential Guard on domain controllers is not recommended — it adds no security there and can cause application compatibility issues

2. Use Remote Credential Guard or Restricted Admin for RDP workflows

Microsoft documents two different protections for RDP-based admin workflows and credits both with preventing Pass-the-Hash. Which one to use depends on how much you trust the remote host.

Remote Credential Guard redirects Kerberos requests back to the connecting device, so neither the credential nor its derivatives are ever passed to the remote host. It suits connections to a host you consider trustworthy.

Restricted Admin is the one Microsoft recommends for helpdesk support scenarios, and this is the part most often gotten backwards. Microsoft states that Remote Credential Guard isn't recommended for helpdesk work: if the session is opened to an already compromised client, the attacker can use that open channel to create sessions on the user's behalf and reach the user's resources for a limited time after the session disconnects. For helpdesk, Microsoft says RDP connections should only be initiated with the /RestrictedAdmin switch.

Important caveats from Microsoft documentation:

Remote Credential Guard only works with RDP
the server and the client must authenticate using Kerberos, and Remote Credential Guard does not allow NTLM fallback, because that would expose credentials
it is supported only for direct connections to target machines, not through Remote Desktop Connection Broker or Remote Desktop Gateway
the remote host must be joined to an Active Directory domain; it cannot be used to connect to a device joined to Microsoft Entra ID (a Microsoft Entra joined client can still connect to an AD-joined host)
it does not support compound authentication, so compatibility testing matters
Restricted Admin has its own cost: it requires membership of the Administrators group on the remote host and gives no single sign-on to other systems

3. Eliminate local administrator password reuse with Windows LAPS

Shared local admin passwords are one of the easiest ways to make Pass-the-Hash scale. Microsoft lists "protection against pass-the-hash and lateral-traversal attacks" as the first benefit of Windows LAPS. Deploy the built-in Windows LAPS rather than the legacy Microsoft LAPS MSI, which Microsoft deprecated as of Windows 11 23H2.

If the same local admin password exists on dozens or hundreds of endpoints, one host compromise can become a broad lateral-movement campaign. Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter should therefore be treated as a direct PtH exposure article, not a separate hygiene topic.

4. Keep privileged credentials off lower-trust hosts

Microsoft's own Credential Guard guidance is blunt here. Credential Guard does not prevent an attacker with malware on the PC from using the privileges associated with any credential, so Microsoft recommends "using dedicated PCs for high value accounts, such as IT Pros and users with access to high value assets". This is one of the most practical anti-PtH controls because it reduces the chance that privileged credential material ever lands on commodity workstations.

That can take several forms:

dedicated admin workstations
admin jump hosts with strict role scope
tiered administration where lower-tier systems cannot collect higher-tier credentials
separate admin identities rather than daily-use admin behavior

5. Reduce NTLM use where feasible

Pass-the-Hash remains operationally useful because NTLM remains operationally useful. If critical administrative paths still rely on NTLM, the attacker has more room to move. Reducing NTLM usage, removing unnecessary NTLM dependencies, and preventing silent fallback all lower PtH exposure.

This is also why PtH and NTLM Relay Attacks: Hijacking Authentication in AD belong in the same review motion. They are different techniques, but both survive on the same underlying protocol debt.

6. Protect the accounts most worth stealing

For highly privileged identities, consider controls that make NTLM usage and reusable credential storage less acceptable operationally:

avoid signing into general-purpose systems with privileged identities
use the Protected Users group where the environment can support its restrictions
review Stale Privileged Accounts: Hidden Risk in Active Directory and remove old identities that keep unnecessary reach into many systems
tighten Active Directory Password Security: Misconfigurations That Matter so weak password hygiene does not amplify the damage of one stolen admin context

Protected Users is powerful but not free. Microsoft documents that members cannot authenticate with NTLM, cannot use DES or RC4 encryption in Kerberos preauthentication, cannot be delegated with unconstrained or constrained delegation, and cannot renew Kerberos TGTs beyond an initial four-hour lifetime. On the device side, CredSSP and Windows Digest stop caching plaintext credentials, NTLM stops caching the NT one-way function, and offline sign-in stops working. Microsoft also warns against adding Domain Admins or Enterprise Admins members before testing, because it is possible to lock those accounts out. That makes it a strong high-value-account control, but not a drop-in change for every environment.

Validation After Hardening

Do not close Pass-the-Hash remediation because one setting was enabled. Validate the path end to end.

confirm that privileged accounts no longer sign into lower-tier systems that expose their credential material
verify that Windows LAPS is actually rotating unique local admin passwords on the systems in scope
test Credential Guard compatibility on representative systems before broad rollout, then confirm it remained enabled after deployment
validate that RDP admin workflows use Remote Credential Guard or Restricted Admin where intended
review whether the remaining administrative paths still rely on NTLM or silent fallback
test whether a compromised endpoint could still reach other endpoints using a reused local admin context

The right success criterion is not "we enabled a control." The right success criterion is "one stolen admin context can no longer move the attacker through the same chain."

EtcSec does not need a fake Pass-the-Hash taxonomy tag to be useful here. The value is in the related exposures that make PtH viable.

The most relevant control families around PtH are:

Together, those checks tell you whether the environment still has the ingredients that let one stolen Windows credential become a lateral-movement chain.

Pass-the-Hash is rarely the only identity problem in the estate. If you want to reduce real attacker movement rather than improve one checklist item, review PtH together with Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter, WDigest Enabled: Why Cleartext Credentials Reappear in LSASS, NTLM Relay Attacks: Hijacking Authentication in AD, Stale Privileged Accounts: Hidden Risk in Active Directory, Active Directory Monitoring: Security Event IDs That Matter, and Kerberoasting Detection Prevention Guide: How to Find and Protect Crackable Service Accounts. Those are the neighboring controls that decide whether PtH remains a practical operator technique in your AD environment.