Pass-the-Hash Attacks: How Credential Theft Bypasses Password Checks
Attackers can hijack your session by stealing encrypted password hashes, completely bypassing the need to know your actual password or crack it first.
Pass-the-hash attacks allow adversaries to authenticate using stolen password hashes rather than plaintext passwords. This exploits legacy authentication protocols that accept hashes directly. You prevent this by enforcing modern authentication standards that reject hash replay and require cryptographic proofs of identity.
What exactly is a pass-the-hash attack?
A pass-the-hash attack is a technique where an adversary uses a stolen password hash to authenticate to a remote server, bypassing the need to decrypt the password. In systems like Windows, the operating system never sends the actual password over the network; it sends a cryptographic hash, which is a fixed-length string derived from the password. If an attacker obtains this hash from memory or a local database, they can present it as their own credential. The target system verifies the hash against its stored records and grants access, unaware that the original user is not present.
Why can't attackers just use the hash directly?
Most modern authentication protocols, such as Secure Password Authentication, are designed to prevent this specific type of replay. These protocols require the client to prove knowledge of the password through a challenge-response mechanism that cannot be satisfied with a static hash. However, older protocols like NTLM (NT LAN Manager) lack this protection. They accept the hash as if it were the password itself. This legacy support remains enabled by default in many enterprise environments for backward compatibility with older applications.
How do attackers obtain these hashes in the first place?
Attackers typically extract hashes from the Security Account Manager database on a compromised Windows machine. This database stores user accounts and their corresponding password hashes. Malware or manual extraction tools can read this file if the attacker has administrative privileges. Alternatively, attackers can dump hashes from the computer's memory, where they reside temporarily during the authentication process. This method is often quieter and leaves fewer forensic traces than accessing the database file directly.
Does a strong password stop this attack?
No, because the attacker does not need to know the password to use the hash. A complex, long password produces a complex hash, but the hash itself is the key to the door. If the underlying protocol accepts the hash as a valid credential, the strength of the original password is irrelevant. The vulnerability lies in the authentication mechanism, not the secrecy of the password. This is why relying solely on password complexity is insufficient against credential theft.
What is the difference between pass-the-hash and pass-the-ticket?
Pass-the-hash uses the NTLM hash to authenticate, while pass-the-ticket uses Kerberos tickets. Kerberos is a network authentication protocol that uses tickets to allow nodes to prove their identity. In a pass-the-ticket attack, the adversary steals an active ticket-granting ticket or a service ticket. This allows them to impersonate the user without needing the password hash at all. Kerberoasting, a related technique, involves requesting service tickets for service accounts and cracking them offline. Understanding this distinction helps you tailor your detection rules to the specific protocol being abused.
See also: Microsegmentation: Why Flat Cloud Networks Fail Your Security · Tor browser privacy risks and small firm protection
Can multi-factor authentication prevent this?
Multi-factor authentication adds a second layer of verification, but it does not always stop pass-the-hash attacks. If the attacker has already authenticated successfully and captured the session token or hash, they may bypass the second factor. Some implementations of multi-factor authentication only trigger during the initial login, not during subsequent lateral movement. If the legacy NTLM protocol is still in use, the attacker can replay the hash to other systems without triggering the multi-factor challenge. See our guide on golden ticket attacks for a deeper look at how adversaries sustain access.
How do you detect a pass-the-hash attack?
Detection relies on monitoring for anomalous authentication patterns rather than failed logins. Since the hash is valid, the login will appear successful in standard logs. Look for authentications that originate from unexpected source machines or occur at unusual times. A single user account authenticating to many different servers in a short period is a strong indicator of lateral movement. You can also monitor for NTLM authentication events, as modern systems should prefer Kerberos. Integrating these signals into your detection platform allows you to spot the behaviour early.
| Detection Signal | What It Indicates | Recommended Action |
|---|---|---|
| NTLM Auth on Domain Controller | Legacy protocol usage | Audit and disable NTLM where possible |
| Multiple Logins from One Host | Lateral movement | Isolate the host and investigate |
| Auth from Unusual Location | Compromised credential | Validate with the user and reset creds |
What is the most effective defence?
The most effective defence is to eliminate the conditions that allow hash replay. Enforce Kerberos authentication across your environment and disable NTLM where feasible. Implement Least Privilege Access, ensuring that standard users cannot extract hashes from their local machines. Regularly rotate credentials for service accounts, as these are high-value targets. Additionally, monitor for unusual process behaviour that might indicate credential dumping. For a structured approach to defensive controls, review the MITRE D3FEND framework.
Why is lateral movement so dangerous here?
Once an attacker has a valid hash, they can move laterally across the network without triggering password-based alerts. They can jump from a low-privilege workstation to a high-value server if the same password is used. This allows them to escalate privileges and access sensitive data without ever knowing the plaintext password. The speed of this movement often outpaces manual detection. Automating the analysis of authentication logs is necessary to catch these rapid transitions.
Key takeaways
- Legacy NTLM authentication allows hashes to be used as valid credentials, enabling lateral movement without password cracking.
- Kerberoasting targets service account tickets, allowing offline brute-force attacks that bypass account lockout policies.
- Multi-factor authentication alone does not stop pass-the-hash if the compromised protocol accepts single-factor hash replay.
Pass-the-hash attacks exploit legacy authentication protocols that accept hashes as valid credentials, rendering password strength irrelevant. Audit your environment for NTLM usage and enforce modern authentication standards to close this gap.
Frequently asked questions
Can I use a firewall to stop pass-the-hash?
No, firewalls control network traffic but do not inspect the validity of authentication hashes. The attack uses legitimate protocols to move laterally, which typically looks like normal internal traffic.
Does changing the password stop an active pass-the-hash session?
Changing the password invalidates future attempts, but it does not automatically terminate existing sessions or stolen hashes held in memory. You must also log off the compromised user from all systems.
Are Linux systems vulnerable to pass-the-hash?
Linux systems using Samba or other Windows-compatible authentication services can be vulnerable if they support NTLM. However, native Linux authentication mechanisms like PAM do not use NTLM hashes in the same way.
How does this relate to scheduled task abuse?
Attackers often use pass-the-hash to gain the privileges needed to create or modify scheduled tasks. This allows them to maintain persistence and execute commands automatically, even after the initial hash is rotated.
How this guide was produced: written by the DarkWeb Dispatch editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
