The Incident That Made Me Question My Sanity

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

The logs showed the attacker authenticating to the domain controller with a service account's NTLM hash - no password, just the hash. The account wasn't in Domain Admins, so nobody had ever looked at it. But years earlier it had been nested into a group that sat inside the domain's built-in Administrators group. On a DC, that's all you need.

Pass-the-Hash was already well documented when I started in IT. It's 2026, and we're still seeing it 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 NTLM works: the NT hash is the secret. NTLM authentication proves you know the hash, so if an attacker steals the hash, they can authenticate as you without ever knowing the password.

Two things follow from that, and most guidance only mentions the first:

Let me break down where attackers get hashes - and what actually stops each one.

The Three Ways Attackers Get NTLM Hashes

1. Credential Dumping from Memory

When someone logs on interactively - at the console, over RDP, via a service or scheduled task - Windows keeps their NT hash (and Kerberos keys) in the LSASS process so it can do single sign-on. That's true whether the logon itself used NTLM or Kerberos. Anyone with local admin rights on that machine can read LSASS with Mimikatz or a dozen similar tools. (LM hashes aren't stored by default on anything since Windows Vista.)

What actually stops this:

2. Capturing Authentication on the Network

NT hashes aren't sent over the network - NTLM sends a challenge-response instead (often called Net-NTLMv2). Attackers get those by poisoning LLMNR/NBT-NS name resolution (Responder) or by coercing a server to authenticate to them. A captured response can't be passed like a hash, but it can be cracked offline if the password is weak, or relayed in real time to another server.

What actually stops this:

3. Pulling Them from the Domain Database

With replication rights (DCSync) or a copy of ntds.dit - from a DC, a DC backup, or a volume shadow copy - an attacker gets every hash in the domain at once, including KRBTGT (which enables Golden Tickets).

What actually stops this:

Don't Forget Local Accounts

The most common PtH I see isn't a domain account at all. It's the local Administrator account with the same password on every machine - dump it from one workstation and you're admin on all of them. Two controls close this:

The Modern Windows Environment Isn't Safe by Default

Microsoft has announced NTLM's deprecation and has already removed NTLMv1 from the newest Windows releases, but in the environments I actually work in:

Here's how I approach it on engagements.

Restricting NTLM in Practice

Step 1: Audit Current Usage

Before restricting anything, you need to know what's using NTLM. Turn on NTLM auditing via Group Policy (Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options):

Events land in Applications and Services Logs → Microsoft → Windows → NTLM → Operational. On DCs, event 8004 shows each NTLM authentication, including which server the client was connecting to - that's your dependency list.

# On a DC: which clients use NTLM, for which accounts, against which servers? Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-NTLM/Operational'; Id=8004} -MaxEvents 5000 | ForEach-Object { $x = [xml]$_.ToXml(); $d = @{} foreach ($n in $x.Event.EventData.Data) { $d[$n.Name] = $n.'#text' } [pscustomobject]@{ User = $d.UserName; Client = $d.WorkstationName; Server = $d.SChannelName } } | Group-Object User, Client, Server | Sort-Object Count -Descending | Select-Object Count, Name -First 50 # On any server: NTLM logons, and whether any are still NTLMv1 Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5000 | ForEach-Object { $x = [xml]$_.ToXml(); $d = @{} foreach ($n in $x.Event.EventData.Data) { $d[$n.Name] = $n.'#text' } if ($d.AuthenticationPackageName -eq 'NTLM') { [pscustomobject]@{ Time = $_.TimeCreated; User = $d.TargetUserName; Source = $d.IpAddress; Version = $d.LmPackageName } } }

Let this run for at least a few weeks, including a month-end. The dependencies that bite you are the ones that only run occasionally.

Step 2: Kill LM and NTLMv1 (Quick Win)

This part is low-risk in almost every environment, and it removes the weakest, most crackable responses. Same Security Options location:

Be clear about what this does and doesn't do. It stops LM and NTLMv1. It does not stop Pass-the-Hash - PtH works fine over NTLMv2. Actually restricting NTLM is Step 3.

Step 3: Restrict NTLM, Starting With Privileged Accounts

You don't have to turn NTLM off for the whole domain at once. The highest-value, lowest-risk move comes first:

Step 4: Cut the Network Paths

You can't block "NTLM" at a firewall - it rides inside SMB, HTTP, LDAP and other protocols. What you can do is remove the paths lateral movement depends on:

What I Actually Recommend for Each Environment Type

Small Environments (< 500 Users)

Medium Environments (500-5,000 Users)

Large Enterprises (> 5,000 Users)

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

I've seen environments with:

And still: Domain Admins logging on to workstations, Credential Guard off, and NTLM accepted everywhere.

The attacker doesn't care about your cool technology. They only need one place where a privileged hash is exposed and one place that will accept it.

Key Takeaways

Pass-the-Hash still works in 2026 because hashes are still easy to steal and NTLM is still accepted almost everywhere.

  • Stop the theft: Credential Guard, LSA protection, and keeping privileged accounts off lower-tier machines
  • Stop the reuse: LAPS, the S-1-5-114 restriction, Protected Users, and restricting NTLM
  • You can do all of it with existing Microsoft controls - no new tools required
  • Restricting NTLM will surface dependencies. Audit first, fix them, then enforce