> sekurlsa::logonpasswords —— NTLM hash captured —— lateral movement in progress<span class="cursor-blink">_</span>_
In most authentication systems, a password is something you know and a hash is something the system stores. The assumption is that knowing the hash is not the same as knowing the password — the one-way nature of hashing should prevent an attacker from reversing the process. In NTLM authentication, this assumption is irrelevant. The protocol never transmits the plaintext password. It transmits a response derived from the hash. If you have the hash, you can authenticate. You do not need to crack it. You do not need to know the original password. The hash is the credential.
This is Pass-the-Hash (PtH) — an attack technique that has existed since 1997 and remains one of the most effective methods for lateral movement in Windows Active Directory environments. It is not a vulnerability in the traditional sense. There is no CVE. There is no patch that eliminates it. It is a fundamental consequence of how NTLM authentication works, and while mitigations exist, the technique continues to appear in the majority of internal penetration testing engagements we conduct.
The techniques described in this article are used by penetration testers under explicit, written authorisation. Extracting credentials, performing lateral movement, or accessing systems without authorisation is a criminal offence under the Computer Misuse Act 1990 and equivalent legislation worldwide. This article is published for defensive education — understanding how the attack works is essential to defending against it.
To understand Pass-the-Hash, you must first understand NTLM — the NT LAN Manager authentication protocol that Windows has used since the mid-1990s. Although Kerberos replaced NTLM as the preferred authentication protocol in Windows 2000, NTLM remains enabled by default in every modern Windows environment for backwards compatibility. It activates automatically whenever Kerberos cannot be used: when connecting to a system by IP address rather than hostname, when the domain controller is unreachable, when connecting to systems outside the domain, or when legacy applications demand it.
NTLM authentication follows a challenge-response model. The client never sends the password or even the hash directly. Instead, the server sends a random challenge, the client encrypts that challenge using a value derived from the password hash, and the server verifies the response by performing the same computation against its stored copy of the hash. If the results match, authentication succeeds.
The NT hash itself is computed as the MD4 digest of the UTF-16LE encoded password. It has no salt — every instance of the same password produces the same hash, across every system, every domain, every time. This means that if a user sets the same password on two different systems, the NT hash is identical on both. It also means that pre-computed rainbow tables and lookup databases are effective against NT hashes, although for Pass-the-Hash, cracking is unnecessary — the hash is used directly.
Pass-the-Hash follows a predictable sequence: gain initial access to a system, extract password hashes from memory or storage, and use those hashes to authenticate to other systems without ever knowing the plaintext passwords. Each successful authentication potentially yields new hashes from additional systems, creating a cascading chain that can traverse an entire domain in minutes.
| Phase | Action | Detail |
|---|---|---|
| 1. Initial Compromise | Gain local administrator access on any domain-joined workstation or server. | This might come from exploiting a vulnerability, phishing, physical access, a misconfigured service, or default credentials. The method does not matter — what matters is local admin rights on one machine. |
| 2. Hash Extraction | Dump NTLM hashes from the compromised system's memory or SAM database. | Windows caches credentials in the LSASS (Local Security Authority Subsystem Service) process for single sign-on. Tools like Mimikatz extract these cached hashes. The local SAM database contains hashes for local accounts. |
| 3. Hash Analysis | Identify which extracted hashes are valuable. | Domain admin hashes grant full domain access. Service account hashes often have elevated privileges across multiple systems. Local admin hashes may be reused across the estate if a common local admin password was deployed via Group Policy or imaging. |
| 4. Lateral Movement | Use extracted hashes to authenticate to additional systems. | Pass the hash using tools like Mimikatz, CrackMapExec, Impacket's psexec.py, or Metasploit's PsExec module. Each new system potentially yields new hashes — IT staff logged in, service accounts cached, further local admin access. |
| 5. Privilege Escalation | Move from standard user hashes to privileged account hashes. | If a domain administrator has ever logged into a compromised workstation, their hash may be cached in LSASS. One domain admin hash from one workstation is typically sufficient for full domain compromise. |
| 6. Domain Compromise | Authenticate to domain controllers using privileged hashes. | With domain admin credentials, the attacker can DCSync (replicate the entire Active Directory database), extract the krbtgt hash for Golden Ticket attacks, create persistence accounts, or simply access any system in the domain. |
Windows stores and caches password hashes in several locations. Understanding where they are is essential both for attackers (who need to find them) and defenders (who need to protect them). Each location has different access requirements and yields different types of credentials.
| Source | What It Contains | Access Required |
|---|---|---|
| LSASS Process Memory | NT hashes, Kerberos tickets, and sometimes plaintext passwords for all users currently logged in — including interactive logons, RDP sessions, RunAs sessions, and service accounts. This is the primary target for Pass-the-Hash. | Local administrator or SYSTEM. Access LSASS via sekurlsa::logonpasswords in Mimikatz or equivalent. Protected by Credential Guard if enabled. |
| SAM Database | NT hashes for local accounts only — the local Administrator account, any other local user accounts. Does not contain domain account hashes. | Local administrator or SYSTEM. Stored in C:\Windows\System32\config\SAM, encrypted with the SYSKEY. Can be extracted offline from disk or Volume Shadow Copies. |
| NTDS.dit | The Active Directory database on domain controllers. Contains NT hashes for every domain account — every user, every computer, every service account, the krbtgt account. | Domain Administrator or equivalent. Accessible via DCSync (remote replication request) or offline extraction from the domain controller's disk or backup. |
| Cached Domain Credentials | DCC2 (Domain Cached Credentials v2) hashes. Windows caches the last 10 domain logons locally so users can authenticate when the domain controller is unreachable (e.g., laptops offline). | Local administrator or SYSTEM. Stored in the registry at HKLM\Security\Cache. DCC2 hashes cannot be used for Pass-the-Hash — they must be cracked first (computationally expensive). |
| LSA Secrets | Service account credentials, auto-logon passwords, VPN credentials, and other secrets stored in the registry by the Local Security Authority. | Local administrator or SYSTEM. Stored encrypted in HKLM\Security\Policy\Secrets. Often contains service account passwords in recoverable form. |
Once hashes have been extracted, the attacker uses them to authenticate to other systems. Multiple tools support Pass-the-Hash, each with different advantages depending on the target environment, the security controls in place, and what the attacker needs to achieve on the remote system.
The CrackMapExec example above illustrates why local administrator password reuse is devastating. A single local admin hash tested against a /24 subnet can compromise dozens of systems in seconds. Each compromised system potentially contains new cached credentials — domain users who have logged in, service accounts running scheduled tasks, IT administrators who connected via RDP. The attacker harvests these new hashes and repeats the process, expanding laterally until a privileged domain account is found.
Pass-the-Hash is rarely a standalone attack. It is the movement mechanism within a broader compromise chain. Understanding the full chain — from initial foothold to domain domination — illustrates why this technique is so consistently effective and why defending against it requires layered controls rather than a single mitigation.
Four hashes. Zero passwords known. Forty-seven minutes. This is not a theoretical exercise — it closely mirrors what we observe in real engagements. The attack succeeded not because of a single failure but because of multiple compounding weaknesses: unpatched workstation, reused local admin password, privileged account logging into standard workstations, no credential tiering, no lateral movement detection.
Pass-the-Hash is one member of a family of credential abuse techniques that exploit Windows authentication mechanisms. Each targets a different credential type or protocol, but all share the same fundamental principle: if you can obtain the authentication material, you can impersonate the user without knowing their password.
| Technique | Credential Used | Key Difference from PtH |
|---|---|---|
| Pass-the-Hash (PtH) | NTLM hash (NT hash) | The original. Uses the static NT hash to authenticate via NTLM. Works against any service accepting NTLM authentication — SMB, WMI, RDP (with restrictions), LDAP, HTTP with NTLM. |
| Pass-the-Ticket (PtT) | Kerberos TGT or TGS ticket | Uses a stolen Kerberos ticket instead of a hash. Tickets are time-limited (default 10 hours for TGT), so the window for use is shorter. However, tickets work against Kerberos-authenticated services that NTLM cannot reach. |
| Overpass-the-Hash | NTLM hash → converted to Kerberos ticket | Uses an NTLM hash to request a Kerberos TGT from the domain controller. Combines the persistence of a static hash with the versatility of Kerberos authentication. Particularly effective in environments that have disabled NTLM. |
| NTLM Relay | NTLM authentication in transit | Does not require extracting hashes. Instead, the attacker intercepts an NTLM authentication attempt in progress and relays it to a different target. The victim authenticates to the attacker's machine, and the attacker forwards the authentication to the real target. Requires network position (man-in-the-middle). |
| Golden Ticket | krbtgt NTLM hash | Uses the krbtgt account hash (extracted via DCSync) to forge arbitrary Kerberos tickets with any privileges, for any user, with any lifetime. Provides persistent domain access that survives password resets for all accounts except krbtgt itself. |
| Silver Ticket | Service account NTLM hash | Forges Kerberos service tickets for a specific service using the service account's hash. More targeted than a Golden Ticket — accesses one service rather than the entire domain. Harder to detect because authentication does not touch the domain controller. |
Pass-the-Hash is detectable, but not by looking for a single event. Detection requires correlating multiple indicators that, individually, appear normal but together reveal anomalous authentication behaviour. The following detection strategies should be implemented in combination.
| Detection Method | What to Monitor | Implementation |
|---|---|---|
| Logon Type Anomalies | Event ID 4624 with Logon Type 9 (NewCredentials) — this is generated when sekurlsa::pth creates a new logon session with passed credentials. Also monitor for NTLM authentication (Event ID 4624 with Authentication Package 'NTLM') in environments where Kerberos should be the norm. |
SIEM correlation rule: alert on Logon Type 9 from workstation accounts. Baseline normal NTLM vs Kerberos ratios and alert on deviations. |
| Impossible Travel | The same account authenticating to multiple geographically or logically separated systems in rapid succession. A domain admin hash used on 15 systems across 3 subnets within 60 seconds is not legitimate administration. | SIEM rule: for each privileged account, alert when authentication events span more than N distinct hosts within a time window shorter than human interaction speed. |
| Service Creation Events | Event ID 7045 (new service installed). PsExec-based PtH tools create a temporary service on the target system. The service name is often random or follows a known pattern (e.g., PSEXESVC). |
Monitor for service creation events where the service binary path contains cmd.exe, powershell.exe, or temporary paths. Alert on services created by accounts that do not normally deploy services. |
| LSASS Access | Event ID 4663 (object access) or Sysmon Event ID 10 (process access) targeting lsass.exe. Mimikatz and equivalent tools must read LSASS memory to extract hashes — this access is detectable. |
Enable auditing on lsass.exe object access. Deploy Sysmon with a configuration that monitors LSASS access. Alert on any non-whitelisted process accessing LSASS. |
| Credential Guard Events | If Credential Guard is deployed, failed PtH attempts generate specific events. Event ID 6155 in the Credential Guard log indicates a blocked credential theft attempt. | Enable Credential Guard event logging and forward to SIEM. Any occurrence is a confirmed credential theft attempt and warrants immediate investigation. |
There is no single control that eliminates Pass-the-Hash. Because the technique exploits a fundamental property of NTLM authentication, mitigation requires a layered approach that reduces the number of extractable hashes, limits where those hashes can be used, and detects when they are misused.
Pass-the-Hash appears in the majority of our internal penetration testing engagements. The specific findings vary, but the patterns are remarkably consistent across organisations of every size and sector.
| Finding | Frequency | Impact |
|---|---|---|
| Shared local admin password | Found in approximately 60% of engagements. Often a legacy of gold-image deployment where the same local admin password was baked into the build and never randomised. | One compromised workstation yields a hash that works on every system with the same password. Lateral movement across the entire estate from a single foothold. |
| Domain admin on workstation | Found in approximately 50% of engagements. IT teams using domain admin accounts for daily workstation support, software installations, or troubleshooting. | Domain admin hash cached in LSASS on a standard workstation. Any compromise of that workstation yields domain admin credentials. Direct path to domain compromise. |
| No Credential Guard | Found in approximately 70% of engagements. Often due to hardware incompatibility, lack of awareness, or deployment complexity. | LSASS memory is unprotected. Mimikatz and equivalent tools extract hashes without restriction. |
| No LAPS deployment | Found in approximately 55% of engagements. Sometimes partially deployed — servers covered but workstations excluded. | Local admin passwords are either shared (from imaging) or set manually and rarely rotated. Either case enables hash reuse across multiple systems. |
| No NTLM auditing or restriction | Found in approximately 80% of engagements. NTLM is enabled by default and most organisations have never assessed whether it can be restricted. | Every NTLM authentication is a potential PtH vector. Without auditing, the organisation cannot even quantify their exposure. |
The remediation priority should follow the chain: deploy LAPS first (eliminates the most common lateral movement vector — shared local admin hashes), implement credential tiering second (prevents domain admin exposure on workstations), enable Credential Guard third (protects LSASS memory), and audit NTLM fourth (identifies remaining exposure). Each control addresses a different stage of the attack chain. Together, they make Pass-the-Hash significantly harder — not impossible, but hard enough that most attackers move to other techniques or are detected in the attempt.
Pass-the-Hash is not a vulnerability. It is a consequence of how NTLM authentication works — the hash is the credential, and anyone who possesses it can authenticate. The technique has been known for nearly thirty years and remains one of the most reliable methods for lateral movement in Active Directory environments because the conditions that enable it — shared local admin passwords, privileged accounts on standard workstations, unprotected LSASS memory, unrestricted NTLM — persist in the majority of enterprise networks.
Defending against Pass-the-Hash requires accepting that credential theft will happen and building an environment where stolen credentials have limited value. LAPS ensures that one hash does not unlock every machine. Credential tiering ensures that a workstation compromise does not yield domain admin credentials. Credential Guard ensures that LSASS cannot be dumped even with local admin access. NTLM restriction removes the protocol that makes it all possible.
No single control is sufficient. But layered correctly, these mitigations transform Pass-the-Hash from a forty-seven-minute path to domain compromise into a noisy, detectable, and ultimately unsuccessful attack — which is exactly what a mature security posture looks like.
Our internal penetration testing engagements specifically test for Pass-the-Hash, credential reuse, and lateral movement paths. We do not just report that the technique works — we show you exactly where the chain breaks and where it does not.