NTLM Relay Attacks: Hijacking Authentication in AD

NTLM Relay Attacks remain relevant because many Active Directory environments still allow at least one relayable path: unsigned SMB, weak LDAP handling, AD CS web enrollment exposure, coercion paths, or legacy name-resolution behavior that causes machines to authenticate where they should not.

What Is NTLM Relay?

NTLM Relay Attacks are network attack techniques where an attacker captures an NTLM authentication exchange from one system and forwards it to another service in real time. The attacker does not need to crack the password hash to do that. The target service accepts the relayed authentication because the NTLM challenge-response exchange is still valid for that session.

In practice, NTLM relay matters when three conditions line up:

• a victim can be coerced or tricked into authenticating over NTLM
• the attacker can reach the victim and the target service on the network
• the target service still accepts NTLM in a way that does not require the protection that would block the relay path

That is why relay is not one single bug. It is the combination of NTLM usage, weak name resolution or coercion paths, and permissive service settings such as unsigned SMB or weak LDAP handling.

How It Works

NTLM is a challenge-response protocol:

1. the client sends a negotiate message
2. the server sends a challenge
3. the client returns an authenticate message derived from that challenge

In a relay attack, the attacker forwards those messages between the victim and the target service. The attacker is not breaking the protocol cryptographically. The attacker is abusing the fact that the target service is willing to accept the relayed authentication context.

Victims are commonly coerced into authenticating through weak name resolution paths such as LLMNR or NBT-NS, or through application and service coercion paths that trigger outbound authentication.

Microsoft's SMB hardening documentation states that SMB signing helps prevent relay attacks and that requiring signing causes clients and servers to reject unsigned packets. That is why SMB signing is a control against SMB relay outcomes, not a cosmetic setting.

NTLM Relay Attacks: Common Relay Paths and What Blocks Them

A useful review should therefore separate the relay transport from the outcome. Blocking SMB relay does not automatically remove LDAP or AD CS relay opportunities.

It is also worth separating workstation exposure from server exposure. A relay path that only lands on low-value member hosts is still a problem, but the response priority changes immediately when the same path can reach domain controllers, management servers, certificate services, or heavily delegated service accounts.

Why reducing NTLM is not the same as one registry value

NTLM restrictions, SMB signing, LDAP signing, EPA/channel binding, name-resolution hardening, and certificate-service hardening address different parts of the attack. A tenant can set one NTLM-related policy and still expose relay if a target service accepts the relayed exchange.

Treat the control set as layered:

• reduce unnecessary NTLM use where the application path supports Kerberos or stronger authentication
• require signing or equivalent protection on services that still accept NTLM
• remove name-resolution behaviors that create easy authentication capture opportunities
• harden AD CS and LDAP paths that turn a relay into domain escalation
• monitor NTLM usage so exceptions remain visible

The Attack Chain

Step 1 - Stand Up the Relay Infrastructure

responder -I eth0 -rdw --no-HTTP-Server --no-SMB-Server
ntlmrelayx.py -tf targets.txt -smb2support -socks

Step 2 - Capture and Forward Authentication

When a victim system tries to authenticate to an attacker-controlled listener, the attacker forwards that NTLM exchange to the chosen target.

# Example success output
# [*] Authenticating against smb://10.10.0.50 as CORP/jsmith SUCCEED

Step 3 - Use the Relayed Identity Where It Matters

# Example LDAP target
ntlmrelayx.py -t ldap://dc01.corp.local --escalate-user attacker

# Example SMB target
ntlmrelayx.py -tf targets.txt -smb2support -c 'whoami'

# Example AD CS path
ntlmrelayx.py -t http://ca.corp.local/certsrv/certfnsh.asp --adcs --template Machine

The relayed session is only as powerful as the target and the relayed identity allow. The important review question is not whether a tool can issue the request. It is whether the environment still exposes a target where the request results in meaningful privilege.

Detection

Windows Event IDs

Microsoft documents event 4776 as NTLM credential validation. For domain accounts, the domain controller is authoritative and can show NTLM validation attempts for domain accounts. That is useful, but it does not show every detail of the destination service, so it must be correlated with target-side logon and service logs.

Practical Detection Clues

• the same account authenticates to several hosts in a short window from one source
• server-side NTLM activity appears from workstations that do not normally initiate that traffic
• relayed authentication is followed immediately by directory modification, local admin activity, or certificate enrollment behavior
• a machine account authenticates to an unusual service after a coercion-like trigger
• NTLM validation appears where Kerberos should normally be used

SIEM Detection Query (Elastic KQL)

event.code: '4624' AND
winlog.event_data.LogonType: '3' AND
winlog.event_data.AuthenticationPackageName: 'NTLM'

That query is not relay-specific on its own. It becomes useful when you enrich it with host role, expected authentication paths, and time clustering.

Better detection through correlation

A strong relay detection usually needs at least two of these signals:

• NTLM validation from an unexpected workstation or server
• target-side type 3 logon using NTLM
• access to coercion-relevant services or named pipes
• immediate directory, local admin, or certificate enrollment action after authentication
• source host that is not expected to initiate authentication to the target

This correlation is more defensible than alerting on all NTLM. Many environments still have legitimate NTLM dependencies, so broad NTLM alerts create noise unless the team has already reduced usage.

Remediation

Quick win: require SMB signing on the systems that still accept unsigned SMB. That removes the most common SMB relay outcome, but it does not replace LDAP and certificate-path hardening.

1. Require SMB Signing

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature

Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbServerConfiguration -RequireSecuritySignature $true

Review both servers and clients. A partial rollout leaves relayable paths behind. Microsoft documents that requiring SMB signing makes the client or server reject unsigned packets, which is the behavior needed to stop SMB relay outcomes.

2. Disable Weak Name Resolution Paths

# GPO setting
# Computer Configuration > Administrative Templates > Network > DNS Client
# Turn off multicast name resolution = Enabled

Microsoft's policy documentation for DNS Client states that enabling the policy disables LLMNR on all available network adapters. Also review legacy NetBIOS name resolution where it still exists in the environment.

3. Restrict NTLM Where the Business Path Allows It

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel -Value 5

Do not deploy NTLM restrictions blindly. Start with audit mode and dependency discovery. Then restrict by server, account, and application path where the business dependency is understood.

4. Harden Directory and Certificate Targets

If domain controllers or certificate services are still reachable through relay-friendly NTLM paths, the remediation is not finished. Review:

• LDAP signing requirements on domain controllers
• LDAP channel binding and Extended Protection where applicable
• AD CS web enrollment and certificate template exposure
• whether high-value servers still accept NTLM where Kerberos or stronger controls should be used instead
• whether certificate enrollment paths can issue authentication-capable certificates to relayed machine or user identities

5. Validate service-by-service, not policy-by-policy

The relay question is always concrete: can this captured or coerced authentication be relayed to this target and produce this outcome? Validate SMB, LDAP, AD CS, and management-server paths independently. A green GPO report is not enough if an exception OU, legacy appliance, or certificate-service endpoint remains relayable.

Validate After Hardening

The success condition is not 'the GPO exists'. It is that the target service no longer accepts the relayed path that mattered.

• re-test representative SMB targets and confirm they require signing
• verify the victim path that previously generated LLMNR, NBT-NS, or other outbound NTLM traffic no longer produces the same result
• confirm the directory and certificate targets that mattered most are no longer relayable from the same foothold
• review recent 4624 and 4776 activity to make sure the environment still works for legitimate users while the abusive path is gone
• review SMB client and server signing configuration from endpoints in each major OU or device management group
• verify AD CS web enrollment and certificate template exposure were remediated if they were part of the relay chain

That validation should be performed against production-relevant systems, not only against a lab machine that was never part of the original risk.

How EtcSec Detects This

EtcSec correlates the conditions that make relay practical: NTLM usage, relay-friendly targets, and nearby configuration weaknesses such as weak SMB, LDAP, or certificate enrollment exposure. That is more useful than a single isolated flag because the same network can contain both harmless NTLM traffic and a small number of paths that are actually exploitable.

Related Reading

• Active Directory Password Security: Misconfigurations That Matter
• GPO Misconfigurations: How Group Policy Becomes an Attack Vector
• Active Directory Monitoring: Security Event IDs That Matter
• ACL Abuse and DCSync: The Silent Paths to Domain Admin
• Active Directory Attack Paths to Domain Admin
• SMB Signing Disabled: Why It Still Enables NTLM Relay

Primary References

• SMB security hardening in Windows Server and Windows Client
• Control SMB signing behavior
• 4776: The computer attempted to validate the credentials for an account
• Audit Credential Validation
• ADMX DNS Client policy: Turn off multicast name resolution
• Protect SMB traffic from interception