NTLM Relay in Active Directory – Secure Active Directory

NTLM relay is an attack technique where an attacker captures NTLM authentication from one system and relays it to another service. Instead of cracking a password or directly stealing plaintext credentials, the attacker abuses the authentication exchange itself. The simplest way to think about NTLM relay is: an attacker convinces one system to authenticate, then forwards that authentication to another system that accepts it.

This can be dangerous because the target service may believe the attacker is the authenticating user or computer. If the relayed identity has useful permissions on the target, the attacker may be able to access data, modify configuration, enroll certificates, create accounts, or perform other actions.

What is NTLM?

NTLM, short for New Technology LAN Manager, is a Windows authentication protocol family that uses a challenge-response mechanism. Microsoft’s NTLM overview explains that NTLM authenticates users and computers by proving knowledge of the password associated with an account, without sending the password itself across the network.

At a high level, NTLM authentication works like this:

A client tries to access a service.
The server sends a challenge.
The client calculates a response using information derived from the account password.
The server or domain controller validates the response.
If validation succeeds, the client is authenticated.

NTLM is still present in many Windows environments because it is used for compatibility, legacy applications, local accounts, workgroup scenarios, IP-based access, and situations where Kerberos cannot be used.

What is NTLM relay?

NTLM relay abuses the fact that NTLM authentication can sometimes be forwarded to another service.

A simplified NTLM relay flow looks like this:

An attacker positions themselves where they can receive or coerce NTLM authentication.
A victim system authenticates to the attacker-controlled listener.
The attacker relays the NTLM authentication to another service.
The target service accepts the authentication.
The attacker gains access to the target service as the relayed user or computer account.

The attacker does not need to know the user’s password. The attacker also does not necessarily need to crack the NTLM response. The value comes from relaying a valid authentication attempt to a target that accepts it. MITRE ATT&CK describes relay activity under Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay, noting that adversaries may relay NTLM authentication material to services such as LDAP, MSSQL, HTTP, and SMB.

Why NTLM relay matters

NTLM relay matters because many Active Directory environments still have services that accept NTLM authentication without enough protections.

The risk increases when:

NTLM is still widely used.
SMB signing is not required.
LDAP signing is not required.
LDAP channel binding is not enforced where appropriate.
AD CS web enrollment endpoints accept NTLM without sufficient protections.
Legacy applications depend on NTLM.
Name resolution poisoning is possible.
Attackers can coerce authentication from servers or domain controllers.
Relayed accounts have useful privileges on the target service.

NTLM relay is especially concerning because it can turn ordinary authentication behavior into an access path. A user or computer may simply attempt to access a resource, while the attacker relays that authentication somewhere more valuable.

NTLM relay vs pass-the-hash

NTLM relay and pass-the-hash are related to NTLM, but they are not the same attack.

Attack	What the attacker uses	Main idea	Requires cracking?
NTLM relay	A live NTLM authentication exchange	Forward authentication to another service	No
Pass-the-hash	An NTLM password hash	Authenticate using the hash directly	No
Password cracking	Captured password-derived material	Recover the plaintext password	Yes

In NTLM relay, the attacker forwards an authentication exchange. In pass-the-hash, the attacker already has a reusable NTLM hash. In password cracking, the attacker attempts to recover the actual password.

How attackers obtain NTLM authentication

Attackers need a way to receive or coerce authentication before they can relay it.

Common paths include:

LLMNR poisoning
NBT-NS poisoning
mDNS poisoning
WPAD abuse
Malicious file shares
Phishing links to internal resources
Coerced authentication from servers
Printer-related coercion techniques
RPC or HTTP-based coercion paths
Misconfigured applications that automatically authenticate

MITRE tracks forced authentication separately as T1187, describing scenarios where adversaries cause a system or user to authenticate to a controlled system, which can then support NTLM relay activity.

Common NTLM relay targets

NTLM relay impact depends heavily on the target service.

Common relay targets include:

Target	Why it matters
SMB	May allow file access, remote operations, or administrative actions if signing is not required
LDAP	May allow directory changes if LDAP signing and channel binding protections are not enforced
HTTP	May expose web applications, management portals, or enrollment endpoints
AD CS web enrollment	May allow certificate enrollment abuse in vulnerable configurations
MSSQL	May allow database access or privilege paths depending on permissions
WinRM	May support remote management if authentication and authorization allow it

Not every relay attempt succeeds. Protections such as signing, channel binding, Extended Protection for Authentication, and proper authorization can prevent or limit relay impact.

LDAP relay and domain controllers

LDAP relay is one of the most important NTLM relay scenarios in Active Directory. If an attacker relays NTLM authentication to LDAP on a domain controller, and the domain controller accepts the authentication without requiring appropriate protections, the attacker may be able to perform LDAP operations as the relayed identity.

Potential impact depends on the relayed account’s permissions, but could include:

Modifying group membership
Changing account attributes
Creating or modifying computer accounts
Modifying delegation-related attributes
Setting resource-based constrained delegation
Abusing weak object permissions

This is why LDAP signing and channel binding are frequently discussed as NTLM relay mitigations.

AD CS relay risk

Active Directory Certificate Services, or AD CS, can become a high-impact NTLM relay target when enrollment endpoints are configured insecurely. One well-known scenario is NTLM relay to AD CS web enrollment or certificate enrollment web services. If an attacker can relay authentication from a privileged user or computer to a vulnerable AD CS endpoint, the attacker may be able to request a certificate that can later be used for authentication.

Microsoft published KB5005413 specifically for mitigating NTLM relay attacks on AD CS. Microsoft recommends protections such as Extended Protection for Authentication, disabling NTLM on AD CS web enrollment servers where possible, and removing vulnerable enrollment services if they are not needed. Microsoft Defender for Identity also identifies AD CS ESC8 exposure, where web enrollment endpoints may be vulnerable to NTLM relay attacks. Microsoft notes that relay attacks against vulnerable AD CS configurations can lead to serious domain compromise paths.

How SMB signing helps

SMB signing helps protect SMB communication by requiring messages to be signed. When SMB signing is required, it becomes much harder for an attacker to relay NTLM authentication to SMB successfully because the authentication is bound to message integrity requirements. SMB signing should be reviewed on both servers and clients.

Important questions include:

Is SMB signing required on domain controllers?
Is SMB signing required on file servers?
Is SMB signing required on administrative systems?
Are legacy systems preventing enforcement?
Are there servers where signing is enabled but not required?

In many environments, SMB signing gaps are common on member servers, older systems, appliances, or file services.

How LDAP signing helps

LDAP signing helps protect LDAP communication by requiring LDAP messages to be signed. This reduces the risk of attackers relaying or tampering with LDAP communication to domain controllers.

For domain controllers, the important policy is Domain controller: LDAP server signing requirements. The stronger setting is Require signing.

LDAP signing is especially important because LDAP operations can affect Active Directory objects. If attackers can relay authentication to LDAP and perform changes as the relayed identity, the impact can be much broader than simple resource access.

How LDAP channel binding helps

LDAP channel binding helps bind LDAP authentication to the TLS channel when LDAPS is used. This helps reduce certain relay scenarios against LDAPS by making it harder to forward authentication from one TLS channel to another.

LDAP signing and LDAP channel binding are related, but they are not the same control.

Control	Primary purpose
LDAP signing	Helps protect LDAP message integrity
LDAP channel binding	Helps bind authentication to the TLS channel
LDAPS	Encrypts LDAP traffic using TLS
Extended Protection for Authentication	Helps protect integrated authentication by using service binding and channel binding concepts

Microsoft describes LDAP signing and channel binding as separate protections that improve LDAP communication security with Active Directory domain controllers.

How Extended Protection for Authentication helps

Extended Protection for Authentication, or EPA, helps protect Integrated Windows Authentication by strengthening how authentication is bound to the intended service or TLS channel. Microsoft describes EPA as a feature that enhances protection and handling of credentials during Integrated Windows Authentication. EPA is especially relevant for HTTP-based services that use Windows authentication, including some AD CS web enrollment scenarios. When properly configured, EPA can help prevent relayed authentication from being accepted by a service.

PowerShell: Check domain controller LDAP signing policy

LDAP signing is usually controlled through Group Policy. A practical first step is to generate a GPO report and search for the relevant setting.

Get-GPOReport -All -ReportType Html -Path .\GPOReport.html

Search the report for “Domain controller: LDAP server signing requirements”.

You can also review effective policy on a domain controller:

gpresult /h C:\Temp\dc-gpo-report.html

Then search the report for the LDAP signing requirement.

PowerShell: Find domain controllers

Use this to identify domain controllers that should be included in review and monitoring:

Get-ADDomainController -Filter * |
    Select-Object HostName, Site, OperatingSystem, IPv4Address

Domain controllers should receive special attention because LDAP relay to domain controllers can create high-impact directory modification paths.

PowerShell: Review MachineAccountQuota

MachineAccountQuota can matter in relay scenarios because attackers may try to create or modify computer accounts as part of escalation paths.

Get-ADDomain | Select-Object DistinguishedName, ms-DS-MachineAccountQuota

Many organizations reduce this value to 0.

Before changing it, confirm whether any provisioning, imaging, or domain join workflows rely on non-admin computer account creation.

PowerShell: Find AD CS web enrollment role services

If AD CS is installed, review whether web enrollment components are present. On a certificate authority server, you can start with:

Get-WindowsFeature ADCS-Web-Enrollment, ADCS-Enroll-Web-Svc, ADCS-Enroll-Web-Pol

Relevant role services include:

ADCS-Web-Enrollment
ADCS-Enroll-Web-Svc
ADCS-Enroll-Web-Pol

If these services are installed, review whether NTLM is allowed, whether EPA is enabled, whether HTTPS is required, and whether the services are still needed.

Detection opportunities

Detection should include both authentication behavior and configuration monitoring.

Authentication monitoring

Look for:

NTLM authentication to unusual servers
NTLM authentication from servers that should use Kerberos
Authentication attempts to attacker-controlled or unusual hosts
Spikes in NTLM authentication
NTLM authentication to domain controllers over LDAP
NTLM authentication to AD CS web enrollment endpoints
Service ticket or authentication activity following name resolution poisoning

Useful Windows events and telemetry sources include:

Event ID or source	Purpose
4624	Successful logon
4625	Failed logon
4776	NTLM authentication attempt validated by a domain controller
4768	Kerberos authentication ticket requested
4769	Kerberos service ticket requested
Directory Service event 2889	LDAP unsigned or simple bind visibility when configured
IIS logs	HTTP authentication activity on web enrollment or management endpoints
Defender for Identity alerts	Suspicious NTLM relay or AD CS-related activity

Event ID 4776 is especially useful for understanding where NTLM is still being used, but it should be correlated with host, application, and network context.

Configuration monitoring

Watch for changes to:

LDAP signing settings
LDAP channel binding settings
SMB signing settings
AD CS web enrollment configuration
Extended Protection for Authentication
MachineAccountQuota
Computer account creation
Delegation-related attributes
Local administrator membership on servers
Name resolution configuration

NTLM relay is often prevented through configuration hardening, so configuration drift matters.

How to reduce NTLM relay exposure

NTLM relay is best addressed through layered controls. No single setting solves every scenario.

Require SMB signing where feasible

Require SMB signing on domain controllers, file servers, administrative systems, and other sensitive servers. Review legacy systems before broad enforcement.

Require LDAP signing

Configure domain controllers to require LDAP signing where feasible. Monitor first to identify incompatible clients.

Enforce LDAP channel binding where appropriate

LDAP channel binding helps protect LDAPS authentication from relay scenarios. Test before enforcement because legacy clients or applications may need remediation.

Harden AD CS web enrollment

If AD CS web enrollment services are installed, review whether they are needed. If they are required, enable HTTPS, enable EPA, and reduce NTLM exposure where possible. Microsoft’s AD CS NTLM relay mitigation guidance specifically recommends EPA and other protections.

Disable unnecessary NTLM

Audit NTLM usage before disabling it. Many environments still have legacy dependencies. Use a phased approach that starts with visibility, then exceptions, then enforcement.

Disable LLMNR and NBT-NS where possible

Name resolution poisoning often provides attackers with authentication material to relay. Reducing legacy name resolution protocols can reduce opportunities for capture and relay.

Reduce MachineAccountQuota

If ordinary users do not need to create computer accounts, consider reducing MachineAccountQuota to zero.

Protect privileged accounts

Privileged accounts should avoid authenticating to lower-trust systems. Use administrative workstations, tiering, and account protections to reduce exposure.

Monitor and alert on NTLM usage

NTLM is not always malicious, but unexpected NTLM usage is worth investigating, especially on domain controllers, certificate authorities, administrative systems, and sensitive servers.

Common mistakes

Assuming NTLM relay requires password cracking

NTLM relay does not require cracking the password. The attacker relays a live authentication exchange to another service.

Thinking NTLMv2 alone prevents relay

NTLMv2 is stronger than older NTLM versions, but NTLMv2 can still be relayed if the target service does not require appropriate protections.

Only focusing on SMB

SMB relay is important, but NTLM can be relayed to multiple services, including LDAP, HTTP, MSSQL, and AD CS enrollment endpoints.

Ignoring AD CS

AD CS web enrollment exposure can make NTLM relay much more serious. Certificate-based authentication paths can have long-lasting impact.

Enforcing controls without monitoring

LDAP signing, channel binding, SMB signing, and NTLM restrictions can break legacy systems. Monitor and test before broad enforcement.

Leaving legacy name resolution enabled

LLMNR and NBT-NS can help attackers collect authentication attempts. They should be reviewed as part of relay reduction.

Treating all NTLM usage as malicious

Many environments still use NTLM for legitimate reasons. The goal is to reduce unnecessary NTLM and protect services that accept it.

Practical recommendation

A practical NTLM relay reduction plan should include:

Inventory where NTLM is still used.
Identify systems accepting NTLM authentication.
Require SMB signing on sensitive servers.
Require LDAP signing on domain controllers.
Review LDAP channel binding settings.
Identify AD CS web enrollment endpoints.
Enable EPA on HTTP-based Windows authentication services where appropriate.
Disable or restrict unnecessary NTLM.
Disable LLMNR and NBT-NS where feasible.
Review MachineAccountQuota.
Protect privileged accounts from authenticating to lower-trust systems.
Monitor NTLM authentication patterns over time.

The goal is not to break every NTLM dependency overnight. The goal is to reduce relayable authentication paths and make remaining NTLM usage visible, justified, and protected.

Summary

NTLM relay is an attack technique that abuses live NTLM authentication. Instead of stealing a password or cracking a hash, the attacker forwards authentication from one system to another service that accepts it. In Active Directory environments, NTLM relay is especially important because targets such as LDAP and AD CS can create serious privilege escalation paths. Defenders should focus on reducing NTLM usage, requiring SMB signing, requiring LDAP signing, reviewing LDAP channel binding, hardening AD CS enrollment services, disabling legacy name resolution where feasible, and monitoring NTLM authentication.

NTLM may still exist for compatibility, but it should not be invisible or unprotected. In a mature environment, NTLM usage should be known, minimized, and defended with layered controls.