Pass-the-Hash in 2026: Why It Still Works (and How to Stop It)

The Incident That Made Me Question My Sanity

I was knee-deep in forensic analysis on a Sunday morning. The attacker had lateral-moved from a user workstation to domain controller in under 12 minutes. How?

The audit log showed the attacker using a service account's NTLM hash—no password, just the hash—to authenticate directly to the domain controller. The account didn't even have admin rights.

I looked at my laptop. I looked at the domain controller. I checked my notes from 2015 when I wrote my first blog post about Pass-the-Hash.

2026, and we're still seeing this in production environments. Not because it's difficult to prevent—because organizations haven't actually implemented the controls they've had available for years.

Why Pass-the-Hash Works in 2026

Pass-the-Hash (PtH) is not a vulnerability. It's how Windows authenticates using NTLM. The attacker doesn't need the password—just the hash. And if you're still using NTLM, or if your domain has legacy protocols enabled, the attacker can extract hashes from memory and use them directly.

Let me break down exactly how this happens in modern environments—and what actually stops it.

The Three Ways Attackers Get NTLM Hashes

1. Credential Dumping from Memory

When a user logs in with NTLM, Windows stores both the LM hash and NT hash in memory (LSASS process). Tools like Mimikatz can extract these hashes in seconds.

What actually stops this:

• Disable NTLM everywhere: Use Kerberos for all authentication
• Restrict local administrator rights: Attackers can only dump hashes for accounts logged into that machine
• Use LAPS or similar: Unique local passwords reduce the blast radius

2. Harvesting from Network Traffic

NTLM authentication happens over the network. An attacker in position to capture traffic can replay hashes or use them for lateral movement.

What actually stops this:

• Block LM traffic: Disable LM on all clients and servers
• Use SMB signing: Require signing on all SMB traffic
• Network segmentation: Prevent attackers from positioned to capture traffic

3. Golden Ticket Attacks

If the attacker gets domain controller access and extracts the KRBTGT hash, they can create Golden Tickets—forged Kerberos TGTs that grant any access they want.

What actually stops this:

• Reset KRBTGT password: Change both the current and previous KRBTGT passwords after compromise
• Monitor for Golden Ticket events: Event ID 4768 with suspicious flags
• Use Privileged Access Workstations: Keep admin machines isolated

The Modern Windows Environment Isn't Safe by Default

Microsoft has been pushing for Kerberos and disabling NTLM, but the defaults still leave environments vulnerable:

• Windows 10/11: NTLM is enabled by default for backward compatibility
• Active Directory: LM/NTLM authentication allowed unless explicitly disabled
• Group Policy: No default policies disabling legacy protocols

Here's what I configure on every engagement.

Disabling NTLM in Practice

Step 1: Audit Current Usage

Before disabling anything, you need to know what's using NTLM:

Step 2: Configure Domain Controller to Audit NTLM

Step 3: Disable NTLM via Group Policy

1. Open Group Policy Management Console (GPMC)
2. Create new GPO: "Disable NTLM"
3. Navigate to:
   • Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options
4. Configure these settings:
   • Network security: Do not store LAN Manager hash value on next password change → Enabled
   • Network security: LAN Manager authentication level → Send NTLMv2 response only\Refuse LM & NTLM
   • Network security: Minimum session security for NTLM SSP → Require NTLMv2 session security, Require 128-bit encryption

Step 4: Block NTLM Traffic at the Firewall

Even if clients try to use NTLM, block it at network boundaries:

• Block ports 137, 138, 139 (NetBIOS)
• Block SMB traffic from untrusted networks
• Require SMB signing on all SMB connections

What I Actually Recommend for Each Environment Type

Small Environments (< 500 Users)

Immediate actions:

• Disable NTLM via Group Policy—apply to all domain controllers
• Enable LAPS on all workstations and servers
• Require SMB signing on all systems

Timeline:

• Week 1: Audit NTLM usage, disable legacy protocols
• Week 2: Deploy LAPS, enable SMB signing
• Week 3: Verify no breaking changes, monitor for issues

Medium Environments (500–5,000 Users)

Additional considerations:

• Isolate legacy applications that require NTLM on separate network segment
• Deploy conditional access policies for Entra ID to block NTLM from cloud services
• Implement privileged access workstations for all admin tasks

Timeline:

• Week 1–2: Audit and segmentation
• Week 3–4: Deploy LAPS, PAWs, conditional access
• Week 5–6: Testing and monitoring

Large Enterprises (> 5,000 Users)

Enterprise-scale recommendations:

• Phased rollout: Start with pilot groups, expand based on findings
• Application inventory: Identify all applications using NTLM
• Modern authentication: Migrate to Entra ID with conditional access

Timeline:

• Month 1–2: Audit and application inventory
• Month 3–4: Pilot with selected groups
• Month 5–6: Full rollout with monitoring

The Real Problem Isn't Technology—It's Prioritization

I've seen environments with:

• Modern Entra ID conditional access policies
• LAPS deployed everywhere
• AD tiering implemented correctly

And still using NTLM for internal communications.

The attacker doesn't care about your cool technology. They only need one weak point—and NTLM is still available everywhere by default.