What Is an NTLM Hash Leak and How Attackers Use It

An NTLM hash leak happens when a Windows client authenticates to a server an attacker controls and sends a challenge-response derived from the user's password. The attacker never sees the password itself, but the captured NTLMv2 response is enough to attempt offline cracking or to relay the login to another service. The November 2026 Outlook zero-day, CVE-2026-124194, is the latest bug to cause one.

What is an NTLM hash leak?

An NTLM hash leak is the exposure of a user's NTLM authentication material to a system the user did not intend to log in to. It usually happens silently, triggered by a file or link that makes Windows reach out to a remote server.

The trigger is often small. A document, shortcut or message file references a resource on a remote host. When Windows tries to load that resource, it offers the current user's credentials to the host as part of the normal single sign-on behavior that makes file shares work inside a domain. If the host belongs to an attacker, the attacker records the exchange.

In the Outlook zero-day CVE-2026-124194, opening a crafted message file made Outlook connect to an attacker-controlled location without showing its usual external-content warning. The missing warning is the bug. The credential exposure is what makes it worth exploiting.

How does NTLM authentication work?

NTLM is a challenge-response protocol: the server sends a random challenge, and the client answers with a value computed from the challenge and a hash of the user's password. The password never crosses the wire, but the answer is tied to it.

That design is the weakness. Anyone who holds the challenge and the response can test password guesses against them offline, as fast as their hardware allows. NTLMv2 made this harder than the original protocol, but it did not make it impossible. A short or common password can still fall quickly.

The second weakness is relay. Because the client is answering whatever server asked, an attacker in the middle can pass the challenge and response through to a real server and log in as the user without ever cracking anything. Our glossary entry on NTLM relay covers the mechanics; the defense is to require signing or channel binding on the services that accept NTLM.

Why do attackers want NTLMv2 hashes?

Attackers want NTLMv2 hashes because they turn one opened attachment into a working credential. Depending on the environment, that credential can unlock email, file shares, VPN access or a foothold for moving deeper into the network.

Three factors decide how bad a leak is:

• Password strength. A long, unique passphrase makes offline cracking expensive enough that attackers move on. A seasonal password with a number at the end does not.
• Relay protections. If SMB signing, LDAP signing and Extended Protection for Authentication are enforced on internal services, a relayed response gets rejected. Where they are not, cracking is unnecessary.
• Account privilege. A leaked hash from a help desk technician or an administrator who reads email on the same account is far more valuable than one from a standard user.

Where NTLM hash leaks come from

Outlook bugs are a recurring source because email is the easiest way to put a file in front of a user. They are not the only one. Common triggers include:

• Documents and message files that reference remote content
• Shortcut and library files that point icons or paths at a remote share
• Links in web pages or chat messages that point to a network path
• Misconfigured applications that fetch resources from user-supplied paths

The common thread is a client that will authenticate to any host it is told to contact. That is why patching each individual bug only closes one door. The structural fixes are limiting where clients can authenticate and reducing how much NTLM is used at all.

How do you reduce the impact of an NTLM hash leak?

You reduce the impact by stopping the hash from leaving your network, making it useless if it does and shrinking the number of systems that still accept NTLM. No single control does all three.

Start with egress. Workstations have little reason to open SMB sessions to the internet, and blocking outbound TCP 445 stops the most common leak path. Our step-by-step guide on how to block outbound SMB to stop NTLM hash leaks covers testing and rollout.

Then work on the hash itself:

1. Enforce long passphrases, especially for privileged and shared accounts.
2. Require signing on SMB and LDAP so relayed authentication fails.
3. Inventory which applications still need NTLM and move them to Kerberos.
4. Keep administrators out of email on their privileged accounts.

Finally, patch the client bugs that trigger leaks. For Outlook that means the Office update channel, which runs separately from Windows Update. We explain why that matters in why Office update patching needs its own track.

What to do if you suspect a leak

If a user opened a suspicious attachment and your firewall logs show an outbound SMB connection to an unfamiliar external address around the same time, treat the user's password as compromised. Reset it, review recent sign-ins for that account from unfamiliar hosts, and check whether the account had access to anything that should now be reviewed. A reset makes the captured response worthless for cracking, because it was derived from the old password.