Pass-the-Hash Attacks in Active Directory: A Pentester’s Guide

Hey, grab a seat. Let me tell you about one of my favorite techniques that still works way too often in enterprise environments—Pass-the-Hash (PtH) attacks. It’s been around since the late 90s, and you’d be amazed how many networks are still vulnerable to it today.

What is Pass-the-Hash, Really?

So here’s the thing about Windows authentication that a lot of people misunderstand. When you log into a Windows domain, you’re probably thinking, “I type my password, it gets sent to the domain controller, and I’m authenticated.” But that’s not quite how it works.

The NTLM (NT LAN Manager) authentication protocol never actually sends your cleartext password across the network. Instead, Windows computes a hash of your password—specifically, the NTLM hash—and uses that for authentication. Here’s the kicker: the domain controller doesn’t need your actual password to authenticate you. It just needs the hash.

This design was meant to be a security feature. No cleartext passwords flying around the network, right? But it created a fundamental flaw: if an attacker can obtain your NTLM hash, they can authenticate as you without ever knowing your password. That’s Pass-the-Hash.

How NTLM Authentication Actually Works

Let me break this down without getting too deep into the crypto weeds:

1. Password Storage: When you set your password, Windows computes the NTLM hash and stores it in the SAM (Security Account Manager) database locally, or in NTDS.dit on domain controllers.

2. The NTLM Hash: It’s an MD4 hash of your password in UTF-16LE encoding. Yes, MD4—that algorithm from 1990 that’s been broken for decades. The hash can’t be reversed algorithically, but it can be cracked with rainbow tables or brute force.

3. Challenge-Response: When you try to authenticate:

4. The server sends a random challenge (nonce)
5. Your client encrypts this challenge using your NTLM hash
6. The server does the same with the stored hash

7. If they match, you’re in

8. The Problem: The server can’t tell the difference between “I computed this response from my password” and “I computed this response from a hash I stole.” As far as NTLM is concerned, possessing the hash is proof of identity.

Modern Windows uses Kerberos by default, which is more secure—but NTLM is still supported for backward compatibility, and many environments still rely on it heavily.

Where Do These Hashes Come From?

Before we talk about tools, you need to understand where pentesters actually find these hashes:

• LSASS Memory: The Local Security Authority Subsystem Service process holds credentials for active sessions. This is the big one.
• SAM Database: Local account hashes on individual machines.
• NTDS.dit: The Active Directory database on domain controllers—this is the jackpot.
• Cached Credentials: Windows caches domain credentials for offline login.
• Network Capture: NTLM hashes can be relayed or captured from the network (though typically you’re capturing the challenge-response, not the hash itself).

Okay, now let’s talk about the tools that make this all practical.

Tools of the Trade

Impacket

If there’s one toolkit I reach for constantly, it’s Impacket. It’s a Python collection of network protocol implementations, and the PtH-related tools are pure gold.

The key tool here is psexec.py with the -hashes flag:

python3 psexec.py -hashes aad3b435b51404ee :5f4dcc5b5aa765d61d8327deb882cf99 domain.local/admin@target-workstation

Wait, what’s with that weird format? The aad3b435b51404ee part is the LM hash—ancient history at this point. Modern systems don’t use it, so we just pass that empty placeholder. The second value is your NTLM hash.

Impacket also gives you:

• wmiexec.py: Execute commands via WMI. Stealthier than psexec.
• smbexec.py: Uses SMB to execute commands. Another evasion option.
• atexec.py: Leverages the Task Scheduler service.
• secretsdump.py: Extract hashes from LSASS, SAM, or NTDS.dit.

Here’s a realistic scenario: you’ve compromised a workstation, dumped local hashes, and found a local admin account with the same password across multiple machines (trust me, this happens constantly). You grab the hash and start moving:

# Test credentials across the network
python3 secretsdump.py -hashes aad3b435b51404ee :5f4dcc5b5aa765d61d8327deb882cf99 domain.local/admin@10.0.0.50

# Once you find a good target, execute commands
python3 wmiexec.py -hashes aad3b435b51404ee :5f4dcc5b5aa765d61d8327deb882cf99 domain.local/admin@webserver01

Mimikatz

The legendary Benjamin Delpy created Mimikatz, and honestly, it’s probably the most impactful Windows security tool ever made. It pioneered the technique of extracting plaintext passwords and hashes directly from LSASS memory.

Getting hashes with Mimikatz:

mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords

This dumps all credentials from LSASS—passwords, hashes, Kerberos tickets, the works. It’s loud and will trigger every decent EDR, but when you need it, nothing beats it.

For PtH specifically:

mimikatz # sekurlsa::pth /user:admin /domain:corp.local /ntlm:5f4dcc5b5aa765d61d8327deb882cf99

This injects the hash into memory and spawns a new process running under that context. You get a command prompt that thinks you’re that user.

Mimikatz also extracts hashes from the SAM:

mimikatz # lsadump::sam

Or from cached domain credentials:

mimikatz # lsadump::cache

CrackMapExec (now NetExec)

Okay, this one’s become my go-to for large-scale engagements. CrackMapExec (recently renamed NetExec due to trademark issues) combines enumeration, credential testing, and exploitation in one tool.

Basic PtH with CME:

crackmapexec smb 10.0.0.0/24 -u admin -H 5f4dcc5b5aa765d61d8327deb882cf99

This will spray your hash across an entire subnet and tell you which hosts accept it. Beautiful for mapping privilege boundaries.

CME has a modular architecture. Want to dump SAM hashes from every host where you have admin access?

crackmapexec smb 10.0.0.0/24 -u admin -H 5f4dcc5b5aa765d61d8327deb882cf99 --sam

Or execute a command across all accessible hosts (with a nice, ethical message first, right?):

crackmapexec smb 10.0.0.0/24 -u admin -H 5f4dcc5b5aa765d61d8327deb882cf99 -x 'whoami'

Lateral Movement Techniques

Alright, you’ve got a hash. Now what? Let me walk you through how pentesters actually move through networks.

The Pivot Chain

Real environments rarely have flat networks. You’ll typically start in a user workstation segment and need to pivot through multiple hosts to reach the juicy targets—domain controllers, database servers, file servers with sensitive data.

A typical pivot looks like this:

1. Initial Access: Phishing, initial compromise, whatever gets you that first foothold.

2. Local Privilege Escalation: Get SYSTEM on your initial host. Exported tools like BLEeping-Computer or Potato attacks help here.

3. Credential Harvesting: Dump LSASS, get those hashes.

4. Host Discovery: Scan the network, find targets.

5. PtH Lateral Movement: Use harvested hashes to access new hosts.

6. Repeat: Each new host potentially gives you new credentials—the domain admin hash on that server you just hit.

Common PtH Targets

Local administrator accounts are the most common target for PtH. Many organizations use the same local admin password across all workstations (this used to be the default with imaging). Once you have that hash, you own every endpoint.

Domain accounts are even juicier. Service accounts running with domain privileges are often a gold mine—they frequently have unrestricted login rights and rarely rotate passwords.

Overpass-the-Hash

Here’s where it gets clever. Overpass-the-Hash is a variant where we take an NTLM hash and use it to request a Kerberos ticket. Tools like Mimikatz and Rubeus make this trivial.

The process is: obtain NTLM hash → request Kerberos TGT → use TGT for Kerberos authentication. You’re passing the hash to get a ticket, which feels like cheating, but completely works.

Detection and Prevention

Let’s flip hats for a minute and talk defense. If you’re on the blue team side, here’s what actually helps.

Detection Strategies

1. Windows Event Logs

Look for:
– Event ID 4624 with Logon Type 3 (network logon) from unusual sources
– Event ID 4624 without a corresponding event from a domain controller (suggests local account usage)
– NTLM authentication from accounts that should be using Kerberos

2. LSASS Access Monitoring

Any process accessing LSASS memory that isn’t a legitimate Windows component should trigger alerts. This is where EDR tools shine—Cortex XDR, Defender for Endpoint, CrowdStrike, they all watch for this.

3. Network Analysis

NTLM authentication traffic has recognizable patterns. Look for multiple authentication requests with the same hash across different hosts—classic PtH behavior.

4. Honey Tokens

Deploy decoy accounts with hashes that should never be used. Anyone attempting PtH with these credentials is definitely an attacker. Canary tokens are fantastic for this.

Prevention

This is where most organizations fail. Let me be blunt: you can’t fully prevent PtH without fundamentally changing your environment.

Mitigation measures that actually help:

1. Restrict Local Admin Rights: Use LAPS (Local Administrator Password Solution) to ensure every machine has a unique local admin password. PtH against local accounts becomes much less useful.

2. Credential Guard: Windows 10+ Enterprise has a feature that isolates credentials in a virtualization-based environment. LSASS dumps become much harder.

3. Protected Users Group: Put high-privilege accounts in this group. They can only authenticate via Kerberos with strong encryption—no NTLM fallback, no cached credentials.

4. Network Segmentation: Limit where privileged accounts can authenticate from. If a domain admin hash can only be used from certain workstations, lateral movement is constrained.

5. NTLM Blocking: Force Kerberos where possible. This breaks legacy systems in many organizations (a real problem) but ideally removes NTLM from the equation.

But here’s the truth: even with all of these, if an attacker compromises a domain controller or a host where a privileged user is logged in, they will get usable credentials. There’s no silver bullet.

Real-World Attack Scenarios

Let me share some actual patterns I’ve seen in real engagements.

Scenario 1: The Service Account Pivot

A large financial services firm had a complex Active Directory environment. Our initial access was a compromised workstation via a phishing simulation. Standard stuff.

Running Mimikatz, we extracted hashes from LSASS. Among them: an SQL service account running with domain privileges.

Now here’s the revelation. This service account had “Log on as a service” rights, enabling it to authenticate across numerous servers in the environment.

That one hash gave us access to a dozen database servers. We found domain admin credentials cached on one of those—cached credentials are great because the domain controller doesn’t need to be online.

Game over.

Lesson: Service accounts are frequently overprivileged and use predictable naming (svc_sql, svc_backup, etc.). They’re prime PtH targets.

Scenario 2: The Helpdesk Heist

Another engagement, different approach. We had no initial access, but the helpdesk team did password resets via a web portal.

We noticed the helpdesk staff had local admin rights on their own machines. A quick social engineering test showed that physical security at the helpdesk was minimal—anyone could walk by.

The reality? A real attacker could easily compromise a helpdesk workstation. Helpdesk accounts often have reset rights for other accounts. Once you’re on a helpdesk machine, those cached credentials are a skeleton key to the domain.

Lesson: Privileged users often have less-protected endpoints. Target the people with keys.

Scenario 3: Lateral Movement From Web Shell

Believe it or not, a company engaged us because they found a web shell. They wanted us to demonstrate scope impact.

Impact demonstration started with that web shell on an external-facing web server. The server was in a DMZ, but guess what? The service account running the web application had domain privileges and could authenticate to internal hosts.

We used the web shell to run Mimikatz (loud, sure, but they asked for proof of impact), pulled hashes from LSASS, and jumped straight to their domain controller.

Defense in depth? They had none.

Wrapping Up

Pass-the-Hash works because NTLM was designed before we understood these attack patterns. The protocol fundamentally can’t distinguish between a user who knows their password and an attacker who stole the hash.

For pentesters, PtH is a powerful technique that should appear in most internal assessments. It’s reliable precisely because it’s based on how Windows actually works, not a vulnerability to be patched.

For defenders, the hard truth: you can’t eliminate PtH, you can only raise the bar. Credential Guard, Protected Users, LAPS, proper segmentation, behavioral monitoring—stack these controls and you make the attacker’s job substantially harder.

The organizations that resist PtH best are those that assume breach. They operate as if attackers will get credentials and design their network to limit what those credentials access. That’s the future of Windows security.

Alright, coffee’s empty. Time to go find some hashes.

This guide is intended for authorized security testing and educational purposes only. Always obtain proper authorization before testing any systems you don’t own.

Further Reading & Tools:

• Impacket: https://github.com/SecureSphere/pythons-impacket
• CrackMapExec/NetExec: https://github.com/Pennyw0rth/NetExec
• Mimikatz: https://github.com/gentilkiwi/mimikatz
• Microsoft LAPS: https://www.microsoft.com/en-us/download/details.aspx?id=46899
• MITRE ATT&CK T1550.002: https://attack.mitre.org/techniques/T1550/002/