How NTLM Relay Attacks Bypass Authentication

An NTLM relay attack is one of the most durable techniques in the Windows attacker's toolkit, and it is behind a long line of Exchange vulnerabilities, including the CVE-2026-62911 authentication bypass that left tens of thousands of mail servers exposed. What makes it so effective is that it never breaks any cryptography. It simply forwards a valid authentication to a place it was never meant to go.

The Problem With NTLM

NTLM is a challenge-response authentication protocol that predates the modern web. When a client authenticates to a server, the server issues a challenge, the client proves it knows the account's secret by responding correctly, and access is granted. Crucially, in its basic form the challenge and response are not tied to the specific connection or service they were meant for. That missing binding is the whole vulnerability class.

Because the authentication is not anchored to a particular destination, an attacker positioned in the middle can take the client's response and present it to a completely different server. The victim's credentials are never revealed and never cracked. The attacker is not the client, but as far as the target server can tell, a valid authentication just arrived.

How the Relay Works

A relay attack has three moving parts: a victim that will authenticate, an attacker in the path, and a target server that accepts NTLM.

• First the attacker coerces or waits for a victim, often a machine account or a privileged service, to initiate an NTLM authentication toward attacker-controlled infrastructure.
• The attacker relays that authentication in real time to the target server, passing the challenge back to the victim and the victim's response forward to the target.
• The target completes the handshake and grants the attacker a session with the victim's privileges.

In Active Directory environments the most valuable victims are machine accounts, because a computer or service account frequently holds far more privilege than an ordinary user. This is exactly what happened in the Exchange case: the flaw let an attacker relay the authentication of an Exchange machine account, which carries enough rights to pivot toward full mailbox access and beyond.

Why It Keeps Working

Relay attacks persist because the defenses against them are protections that have to be deliberately switched on, and often are not. Two matter most.

The first is signing. When SMB or LDAP signing is required, the target can detect that a session has been tampered with and refuse a relayed authentication. The second is channel binding, delivered through Extended Protection for Authentication, which ties an authentication token to the exact TLS channel it was issued on. If a token shows up on a different channel, it is rejected. Learning how to enable Extended Protection for Authentication on Exchange is one of the most direct ways to shut this technique down.

Multi-factor authentication does not help here, which surprises many administrators. The attacker is not entering credentials into a login prompt, so there is no second factor to satisfy. The relayed authentication is already complete before any MFA policy would apply. This is why a patched-but-misconfigured server can still fall.

Reducing Your Exposure

The same principles that stopped older Exchange relay bugs apply now. Require SMB and LDAP signing across the environment. Enable Extended Protection on internet-facing services, especially any that expose Windows authentication. Where possible, disable NTLM outright in favor of Kerberos, which binds tickets far more tightly. And keep authentication endpoints off the open internet: an attacker who cannot reach the endpoint cannot start the relay in the first place.

Relay attacks are a reminder that authentication is not just about proving who you are, but about proving it to the right party over the right channel. When either of those guarantees is missing, a valid login becomes a skeleton key. If you want to see how a specific missing control turned into a real incident, read the breakdown of the Exchange CVE-2026-62911 exposure and the companion guide on reducing an internet-facing Exchange server's attack surface.