Pass-the-Hash in 2026: Why Microsoft’s Mitigations Aren’t Enough

Last updated: April 26, 2026

Pass-the-Hash (PtH) is a 1997 attack that should have died in 2014 when Microsoft shipped LSA Protection, Credential Guard, and Restricted Admin RDP. It did not die. In 2026, on most Indian enterprise pentests, PtH still works — sometimes natively, sometimes after a small additional step. This article explains why, demonstrates the modern technique, and shows what the actual fix looks like.

The technique in 60 seconds

NTLM authentication does not transmit passwords. It transmits a challenge-response computed from the NT hash. If you have the NT hash, you can authenticate without ever knowing the password. This is the entire premise.

Once you have an NT hash for a privileged account (from secretsdump, mimikatz, NTDS.dit dump, registry hive extraction), you can authenticate to any service that accepts NTLM as that user, no cracking needed.

impacket-psexec -hashes :a87f3a337d73085c45f9416be5787d86 [email protected]

The leading colon and empty LM hash field are the giveaway pattern. From there, SYSTEM shell on the target, lateral movement, and persistence.

Why “Microsoft fixed this” is wrong

Microsoft has shipped multiple mitigations:

• LSA Protection (Windows 8.1+) — runs LSASS as a Protected Process Light, blocking userland access to memory.
• Credential Guard (Windows 10+) — runs LSA secrets in a Hyper-V virtualised security boundary, isolated from the OS.
• Restricted Admin mode for RDP — does not push credentials to the remote endpoint.
• Protected Users group — disables NTLM, caching, and DES/RC4 for members.
• Disabling NTLM at network and domain levels.

Each of these works. Combined, they would substantially mitigate PtH. The problem is that almost no Indian enterprise environment we audit has them all enabled, correctly configured, and consistently enforced.

What we typically find on a fresh BFSI pentest:

• LSA Protection: enabled on Domain Controllers, disabled or in audit-only mode elsewhere.
• Credential Guard: enabled on a few executive laptops, disabled on every server and most workstations because “it breaks application X.”
• Restricted Admin RDP: not enforced.
• Protected Users group: empty or contains 2-3 admins out of 30.
• NTLM: enabled because legacy applications.

Result: PtH from a single compromised host to lateral movement across the estate.

Modern PtH variants you should know

Stock PtH against SMB/MSRPC services still works in most environments. But the pentester’s toolkit has evolved:

Pass-the-Ticket (PtT)

Instead of hash, steal the Kerberos TGT from memory and reuse it. Mimikatz exports tickets:

mimikatz # sekurlsa::tickets /export
mimikatz # kerberos::ptt <ticket.kirbi>

From a Linux box with Impacket, the same idea via ticketer.py or by extracting from secretsdump output.

PtT bypasses some PtH-specific mitigations because it operates at the Kerberos layer, not NTLM.

Over-Pass-the-Hash (OPtH)

You have an NT hash but want a Kerberos TGT. Use the hash as the long-term key in a TGT request:

impacket-getTGT -hashes :a87f3a337d73085c45f9416be5787d86 corp.local/administrator

Now you have a TGT for the user. Useful when the target service prefers Kerberos and PtH would fail.

Pass-the-Cache (Linux)

If you have stolen Kerberos credential cache (ccache) files from a compromised Linux machine that authenticated to AD, copy them to your attack box:

export KRB5CCNAME=/tmp/krb5cc_1000_alice
impacket-psexec corp.local/[email protected] -k -no-pass

Common in environments with Linux servers domain-joined for SSO. The ccache lives in /tmp with predictable filenames.

Detection — what works and what does not

Standard guidance is “watch for Event ID 4624 with logon type 3 from suspicious sources.” That is the floor. The signal is noisy because legitimate Kerberos and NTLM traffic looks similar in the event log.

Better detections:

• Event 4624 with NTLM as authentication package, on machines that do not normally use NTLM. A network with predominantly Kerberos auth that suddenly sees NTLM from a workstation IP is suspicious.
• Event 4625 (logon failure) followed by 4624 (success) with the same source IP and target account, in quick succession — credential spraying or token reuse pattern.
• Process creation events showing impacket, psexec, wmiexec, smbexec-style command lines on the destination host. Defenders running EDR with command-line capture see these as cmd.exe /Q /c <command> 1> \\\127.0.0.1\ADMIN$\__<timestamp> 2>&1 — the __<timestamp> filename is an Impacket fingerprint.
• SMB write to ADMIN$ followed by service-control creation — the canonical Impacket-PSExec sequence.

For threat hunters, the highest-value Sigma rule is:

title: Suspicious NTLM Authentication via Network Logon Type 3
detection:
  selection:
    EventID: 4624
    LogonType: 3
    AuthenticationPackageName: 'NTLM'
  filter:
    SourceWorkstation: ['known_legacy_systems']
  condition: selection and not filter

Tune by carving out your known legacy NTLM clients (legacy printers, scanners, that one HR app from 2008). Anything else triggers investigation.

The actual fix — in priority order

1. Move all administrator accounts into Protected Users. Single highest-impact change. Disables NTLM, weak Kerberos encryption, and credential caching for those accounts.
2. Enforce Authentication Policies that restrict where Tier-0 admins can authenticate (Domain Controllers + Privileged Access Workstations only). Prevents PtH from a compromised tier-2 host even if hash is stolen.
3. Enable LSA Protection (RunAsPPL) everywhere, not just DCs. The compatibility-break risk is overstated; most environments can roll it out with a few days of testing.
4. Enable Credential Guard on every Windows 10/11 host and every Server 2019+. Test against application compatibility (some legacy auth-intercepting tools break) but plan to enable progressively.
5. Disable NTLMv1 entirely at the domain level. NTLMv2 if compatibility allows.
6. Block lateral SMB with host-based firewall — workstations should not accept inbound SMB from other workstations.
7. Reduce admin tier overlap — no Domain Admin should ever log into a workstation.

How to find your next PtH path

For attackers:

• Map credential exposure with BloodHound’s HasSession edges. Every privileged session on a non-tier-0 machine is a PtH waiting to happen.
• Look for stale local administrator accounts with the same password across the fleet (LAPS not deployed). One hash works on hundreds of machines.
• Check for Restricted Admin RDP not enforced — if a privileged account RDPs to a target without Restricted Admin, their credentials land in LSASS on that target.

For defenders:

• Run Get-ADUser -Filter * -Properties MemberOf | ?{$_.MemberOf -like '*Protected Users*'} — see who is in Protected Users. The list should include every admin.
• Audit local administrator passwords across the estate. Without LAPS, identical-password issues are near-universal.
• Check whether Authentication Policies are configured. Most environments have not set them up.

Compliance angle

• RBI Cyber Security Framework — privileged-access management is explicitly required.
• SEBI CSCRF — MITRE T1550.002 (Pass the Hash) is in scope; defenders need a detection rule.
• ISO 27001:2022 A.5.16, A.8.5 — identity and authentication controls.

The takeaway

Pass-the-Hash is not a 2014 problem. It is a 2026 problem because the mitigations that solve it are individually effective but collectively unenforced. Protected Users group, Authentication Policies, Credential Guard, LSA Protection — every one of these is configurable today. The work is operational rollout discipline, not technical novelty.

If you compromise an admin’s NT hash and Protected Users + Authentication Policies are correctly enforced, you have a hash that works nowhere. That is the goal state.