NTLM relay is dangerous because an attacker does not need to learn the user’s password or crack a captured response before abusing it. If a victim is induced to authenticate to an attacker-controlled intermediary, that authentication can sometimes be forwarded to another service that accepts NTLM without sufficient protection against relaying. The attacker is exploiting the relationship between endpoints, not simply guessing a secret.
Microsoft continues to recommend reducing NTLM usage in favor of Kerberos and stronger protections. NTLM lacks the mutual server authentication available in Kerberos, and legacy services can create relay opportunities when signing, channel binding, or Extended Protection for Authentication are not enforced. For authorized network and penetration testing, understanding those prerequisites is more useful than memorizing relay tools.
The central defensive question is: where can NTLM authentication be triggered, and which target services would accept that authentication without binding it tightly to the intended channel or server? Answering that requires visibility into Windows authentication, SMB, LDAP, web services, service accounts, legacy applications, and the network paths that connect them.
NTLM relay is an authentication forwarding problem
NTLM uses a challenge-response exchange. In a relay scenario, an attacker positions themselves so the victim performs the exchange with the attacker, while the attacker forwards the authentication messages to a different target. If the target accepts the exchange and the protocol does not require enough integrity or channel binding, the target may believe it has authenticated the victim directly.
This is why the broader authentication architecture matters. A protocol can validate that a claimant knows a credential-derived secret while still fail to prove that the authentication was intended for the specific service receiving it. Mutual authentication and channel protections address that distinction.
SMB signing changes whether relay can produce a useful session
SMB signing provides integrity protection that helps prevent a relay intermediary from using an unsigned SMB session as though it were the victim. Current Windows Server guidance increasingly enables or requires signing in more scenarios, but mixed environments and older systems can still contain exceptions. Defenders should inventory which clients and servers require signing rather than assuming a domain-wide policy has reached every device.
Protocol visibility helps here. Common ports and protocols gives the basic network context, but relay risk depends on application-layer security properties, not only whether TCP 445 is reachable. A firewall rule that permits SMB may be necessary for business, while mandatory signing determines whether that allowed connection is harder to abuse as a relay target.
LDAP protections matter when directory operations are the goal
Directory services are another important target class because a relayed identity may have permission to modify objects, group memberships, delegation settings, or computer accounts. LDAP signing and channel binding protections make it harder to transplant an authentication exchange into a separate session. Their exact deployment requires compatibility testing, especially with older clients and third-party applications.
The operational distinction in LDAP on ports 389 and 636 helps teams avoid oversimplifying the fix. TLS, signing, channel binding, and the authentication protocol are related but not identical controls. A secure migration needs to know which applications use which transport and what breaks when stronger binding is required.
Name resolution and coercion paths create the initial opportunity
Relay chains often begin when a system attempts to authenticate automatically to a resource name or network service. Legacy name-resolution behavior, misdirected UNC paths, embedded resource references, printer or file workflows, and application callbacks can all influence where authentication is sent. Defenders should limit unnecessary outbound authentication and reduce protocols that allow untrusted systems to become attractive destinations.
The safest mindset is not to chase every individual coercion trick. Build policy around the invariant: high-value systems should not emit reusable legacy authentication to arbitrary destinations, and high-value services should require protections that make forwarded authentication insufficient. That strategy survives changes in individual attack techniques.
Kerberos adoption reduces but does not automatically eliminate identity risk
Moving services to Kerberos removes an important class of NTLM relay opportunities and adds mutual authentication, but a poorly managed Kerberos environment can still contain ticket theft, weak service accounts, or delegation risk. Protocol migration should therefore be accompanied by service principal cleanup, DNS reliability, supported encryption, and monitoring.
The relationship with Active Directory security is direct: authentication protocol choice is one part of directory security, not a replacement for least privilege. If a relayed or otherwise compromised identity has excessive rights, impact grows regardless of how the initial access occurred.
Inventory NTLM before attempting to disable it
Large Windows environments often retain NTLM because of old devices, appliances, applications, scripts, local accounts, or misconfigured services that cannot use Kerberos. Abruptly blocking it can produce widespread outages and encourage emergency exceptions. A safer program begins with auditing, identifies where NTLM is used, classifies the dependency, and fixes the underlying reason when possible.
Prioritize high-value targets first. Domain controllers, certificate services, administrative servers, file servers with sensitive data, and management systems deserve stronger protections early. Then work outward through application dependencies. This staged approach reduces relayable paths without turning modernization into an all-or-nothing project.
Detection should correlate authentication with the target and source
Useful telemetry includes NTLM authentication events, SMB signing state, LDAP protection state, unusual source hosts, privileged accounts authenticating from unexpected systems, and a rapid sequence of authentication followed by sensitive changes. A single NTLM event is not proof of an attack; the value comes from context and correlation.
Centralized logging and monitoring can help identify these patterns across endpoints and directory services. Analysts should know which systems legitimately use NTLM so deviations stand out. A mature environment treats unexplained NTLM as a dependency to investigate even when it is not malicious, because every unnecessary legacy use preserves future relay surface.
Authorized testing should validate controls, not create uncontrolled exposure
A relay assessment should be scoped to approved targets and identities, with clear rules about whether state-changing actions are permitted. Often the tester can prove exposure through configuration evidence or a limited non-destructive authentication result rather than modifying directory objects. The goal is to verify whether protections prevent relay, not to maximize disruption.
For CompTIA PenTest+ and CompTIA PT0-003 learners, this is an important professional boundary. Relay knowledge is valuable when it produces better remediation: reduce NTLM, require appropriate signing and channel protections, constrain outbound authentication, and remove excessive privileges. The success metric is a smaller reachable attack path after the engagement.
HTTP-based Integrated Windows Authentication can also participate in relay scenarios when applications accept NTLM and do not bind authentication strongly to the TLS channel or target service. Extended Protection for Authentication was designed to strengthen that relationship. Application owners should verify support before enforcement, then remove exceptions as legacy dependencies are upgraded. The important point is that relay mitigation is service-specific: SMB signing does not protect an unrelated web or LDAP endpoint.
Certificate enrollment services deserve special attention in environments that expose Windows authentication over HTTP. If a service can accept relayed credentials and issue a certificate or other long-lived authentication artifact, the immediate NTLM session can become persistent access. Defenders should review which enrollment interfaces are enabled, how they authenticate clients, and whether channel protections and role restrictions are enforced.
Network segmentation can reduce the set of reachable relay targets but should be treated as a supporting control. If ordinary workstation segments cannot directly reach administrative SMB, LDAP, or management services, the attacker has fewer places to forward authentication. However, segmentation does not fix the protocol weakness itself, and legitimate proxy or management paths can still create reachability. Combine network restriction with protocol hardening and privilege reduction.
Name-based access also affects whether Kerberos is selected. Accessing a service by IP address, an alias without the right SPN, or a legacy name can cause Negotiate to fall back to NTLM even though the same service would use Kerberos under its canonical name. Operations teams should investigate why NTLM occurs before simply documenting it as “required.” Fixing DNS, SPNs, and application configuration can remove relay surface without changing the user experience.
Test evidence should include the target service’s protections, not only the fact that a victim can emit NTLM. An environment may still generate NTLM for a legacy workflow while the reachable SMB targets require signing and directory targets enforce binding, substantially reducing practical relay impact. Conversely, one unprotected administrative service can make a small amount of NTLM far more dangerous. Risk is the intersection of authentication source, network reachability, target acceptance, and the victim identity’s privileges.
Privileged access design determines how damaging a successful relay could become. An ordinary user who can only reach a low-value file share presents a different risk from a help-desk or server administrator whose credentials can administer endpoints, certificate services, or directory objects. Reduce standing privilege, separate administrative accounts, and prevent high-value identities from authenticating to lower-trust systems where possible. These measures do not “fix” NTLM, but they reduce the impact available to any authentication forwarding path that survives protocol hardening. During an assessment, document the victim identity and target permission together. A relay proof involving a low-privilege test account should not be exaggerated into domain compromise, while a reachable administrative service accepting legacy authentication should not be dismissed simply because no destructive action was attempted.
