What mitigations reduce the risk of an NTLM relay attack?

How NTLM relay attacks are reduced in practice

ntlm relay is hardest to stop when systems still accept NTLM, accept it without integrity protections, or expose paths where an attacker can coerce and forward authentication between internal services. The main mitigations are to remove NTLM where possible, enforce protections on protocols that support them, and close the network and service paths that make relaying practical.

Relay resistance is strongest when you combine protocol hardening with service hardening. That means signing or channel binding where supported, restricting where high-value services will accept authentication, and reducing the chance that a machine can be tricked into authenticating to an attacker-controlled endpoint in the first place.

One useful way to think about this is that the attack needs both an authentication surface and a forwarding opportunity. The Lateral Movement Guide covers how NTLM relay fits into broader lateral movement paths, while the Active Directory and Entra ID Hardening Guide is useful for prioritising the tier-zero and privileged systems that should not be reachable through weak authentication paths.

Why NTLM relay succeeds

NTLM relay works when an attacker can intercept an authentication exchange and present it to another service that accepts it without proving the original connection is still the same one. If the target service lacks signing, channel binding, or comparable protections, the attacker may be able to reuse the victim’s authentication without ever learning the password itself.

That is why relay risk is not just an “NTLM problem”, it is also a service configuration and trust-boundary problem. Name resolution poisoning, exposed internal endpoints, and permissive service-to-service authentication can all create the conditions the attacker needs. The Identity Threat Detection and Response (ITDR) Guide is relevant here because the detection challenge is often to spot abnormal authentication sequences before the relayed access is used for privilege escalation or lateral movement.

In practice, the most dangerous relay targets are high-value services that trust internal traffic too broadly. If those systems accept forwarded authentication from lower-trust segments, the relay is not just an authentication issue, it becomes a path to administrative access, data exposure, or persistence.

What to harden first

Start with systems that can enforce stronger authentication and integrity checks, then move to the systems that are most attractive relay targets. If a protocol or application supports signing or channel protections, enable them consistently rather than selectively, because partial deployment leaves enough weak endpoints for attackers to pivot through.

Where NTLM cannot be removed immediately, treat it as a constrained legacy dependency and reduce its blast radius. Segment sensitive services, block unnecessary inbound access paths, and prevent machines from authenticating to untrusted or unneeded internal destinations. The Identity Threat Detection and Response (ITDR) Guide helps with the response side of that decision, especially when you need to determine whether relayed authentication was used to reach sensitive services.

The Cisco Active Directory credentials leak 2025 is a reminder that credential material exposed through one path can be reused in others, so a relay mitigation plan should also assume that any credential or hash exposure increases the value of network hardening and privilege containment.

Risk and Threat Considerations

NTLM relay is attractive because it converts a legitimate authentication event into unauthorized access without requiring password cracking. The highest risk appears when relayable protocols, predictable name resolution, and over-trusting internal services overlap, especially around systems that hold administrative or sensitive business access.

Failure mechanism: An attacker induces authentication to a controlled endpoint, forwards the authentication to a second service that does not verify the original channel strongly enough, and then uses the relayed session to access resources as the victim.

Impact: The attacker can gain authenticated access, move laterally, reach privileged services, or use the relayed foothold to escalate toward domain-wide compromise.

Practitioner Guidance

What to verify: Confirm which internal services still accept NTLM, which ones enforce signing or channel protections, and which business-critical systems remain reachable from lower-trust segments. Do not assume a control is effective until you have tested the exact protocol path that an attacker would abuse.

Decision rule: If a service can be reached through unauthenticated name resolution or can accept forwarded authentication without integrity protection, treat it as a priority hardening target before you spend time on lower-value detections. If you cannot remove NTLM immediately, narrow its use and protect the highest-value targets first.

What practitioners underestimate: Relay mitigation is often broken by one forgotten exception, not by the primary control itself. A single legacy server, misconfigured internal resolver, or permissive tier-zero service can preserve the attack path even when the rest of the environment is hardened.

Practitioner takeaway: The goal is not to eliminate every legacy authentication path at once, but to remove the attacker’s ability to combine relayable authentication with an unprotected, high-value target.

Related resources from NHI Mgmt Group

• How should teams reduce the risk of exposed AI credentials being abused?
• How should teams reduce risk from malicious npm package installs?
• How should security teams reduce NTLM relay risk in Active Directory?
• What mitigations reduce the risk of Safe Mode Boot Attack?