The LDAP relay attack is one of the most reliable privilege escalation paths against Active Directory environments. It requires no CVE, no cracked password, and no initial foothold beyond a standard domain-joined machine. It can be executed in minutes. Yet two configuration parameters, correctly set, make the entire chain impossible. Here is how it works, from the first packet to the interactive shell.
The trigger: why LLMNR and NBT-NS open the door
When a Windows machine fails to resolve a hostname through DNS, it falls back to broadcast protocols: first LLMNR (Link-Local Multicast Name Resolution), then NBT-NS (NetBIOS Name Service). These requests are broadcast across the local network segment — anyone on the same VLAN can respond.
An attacker listening on that segment answers the broadcast, impersonating the requested host. The victim machine then sends NTLMv2 credentials to authenticate. These are not cleartext passwords; they are challenge-response tokens. They cannot be replayed directly against the same target — but they can be relayed, in real time, to a completely different service that will accept them as valid.
From NTLMv2 relay to an authenticated LDAP session
This is where the relay kicks in. Tools like ntlmrelayx intercept the NTLMv2 exchange and forward it to the domain controller on port 389 (LDAP) or 636 (LDAPS). If the domain controller does not require LDAP signing, it accepts the relayed authentication as legitimate — the attacker never sees the victim's password.
At this point, the attacker holds an authenticated LDAP session with the victim's permissions. Even a standard domain user account gives meaningful access: full directory enumeration, ACL inspection, group membership queries. But if the relayed account has write permissions on directory objects, the next step becomes trivial.
Escalation: creating a user and adding it to Domain Admins
With an active LDAP session, write operations on directory objects become possible — subject to the relayed account's permissions. In a typical scenario, ntlmrelayx can be configured to open an interactive LDAP shell, giving the attacker a command-line interface to run arbitrary LDAP queries against the domain.
From that shell, the escalation sequence is straightforward:
- Create a new user object in the directory using an LDAP
addrequest. - Set a password on that account by modifying the
unicodePwdattribute. - Add the new account to the Domain Admins group by updating the group's
memberattribute.
Within minutes of capturing the first NTLMv2 challenge, a domain admin account exists in the directory. The attacker can then authenticate directly via WinRM, RDP, or psexec without ever cracking a single hash. This exact sequence is regularly reproduced in Active Directory Red Team lab scenarios to demonstrate real escalation timelines in unhardened environments.
Why LDAP signing stops the relay
LDAP signing forces the domain controller to require that every LDAP packet be cryptographically signed by the client. In a relay attack, the attacker does not hold the session key derived from the victim's password — they cannot produce valid signatures. The domain controller rejects the connection before any session is established.
This is configured through Group Policy: Domain controller: LDAP server signing requirements must be set to Require signing. The default value on most Windows Server versions, including recent ones, is effectively permissive until that GPO is explicitly enforced.
The complementary role of channel binding
LDAP channel binding (EPA — Extended Protection for Authentication) addresses TLS-based connections specifically, meaning LDAPS on port 636. It ties the NTLM authentication token to the specific TLS channel by embedding a cryptographic identifier of the server's TLS certificate. If an attacker relays that token over a different TLS session, the binding check fails and the connection is rejected.
Without channel binding, even LDAPS connections can be relayed — the attacker establishes their own TLS tunnel to the domain controller and forwards the captured token through it. Channel binding closes that gap precisely.
The two controls are complementary by design: LDAP signing covers plaintext connections on port 389, channel binding covers encrypted connections on port 636. Both must be enforced to eliminate the full attack surface.
What this means for security teams in practice
Enabling both settings is a GPO change that takes minutes. The real work before flipping the switch is auditing legacy LDAP clients — older business applications, some SIEM connectors, and network devices often speak unsigned LDAP and will break if Require signing is enforced without warning. Starting with Negotiate signing and monitoring the logs before enforcing is the standard approach.
Teams looking to measure their actual exposure before making changes can use a structured cyber maturity assessment to map the highest-priority attack vectors in their Active Directory environment.
Disabling LLMNR and NBT-NS via GPO removes the problem at its source: without broadcast name resolution, there are no NTLMv2 challenges to capture. It is the simplest control available and one of the most consistently overlooked. Combined with LDAP signing and channel binding, these three measures collapse the entire relay chain.
Frequently asked questions
Can a standard domain user account be enough to pull off an LDAP relay?
In many environments, yes. Standard user accounts often accumulate write permissions on directory objects through delegation settings or misconfigured ACLs. A relayed session using such an account can be enough to create or modify sensitive objects without ever touching a privileged account.
Will enabling LDAP signing break existing applications?
It can affect applications that connect over unsigned LDAP, including some HR systems, ERP platforms, and older network devices. Microsoft recommends starting with Negotiate signing mode and reviewing error logs before switching to Require, to identify incompatible clients in advance.
What is the difference between LDAP signing and LDAP channel binding?
LDAP signing protects plaintext connections on port 389 by requiring cryptographic packet signatures. Channel binding protects encrypted TLS connections on port 636 by binding the authentication token to the specific TLS session. Both are needed to cover the full relay attack surface.
Is disabling LLMNR enough to prevent this attack?
Disabling LLMNR and NBT-NS removes the most common source of captured NTLMv2 credentials, which is the strongest upstream control. However, LDAP signing remains essential because other relay paths — such as capturing credentials through SMB or HTTP — can still feed into an LDAP relay if signing is not enforced.