NTLM relay remains one of the most effective attack techniques against Active Directory environments — not because it exploits a software bug, but because it abuses two configuration gaps that persist in most Windows domains deployed without deliberate hardening. Missing SMB signing, missing LDAP signing, and a basic network poisoning technique: that combination is enough to hand over an entire domain. Here is how the chain works and, more importantly, how to break it.
The attack surface: unsigned SMB and LDAP sessions
Windows does not require SMB signing by default on sessions between workstations. Domain controllers negotiate it for inbound sessions, but nothing forces clients to enforce it. That gap lets an attacker intercept an authentication exchange, replay it toward a different target, and gain access without ever knowing the password.
LDAP is an even bigger problem. On port 389, neither encryption nor message signing is enforced out of the box in most legacy configurations. LDAP signing and LDAP channel binding are two separate controls, neither of which Windows Server applies forcibly without administrator action. That is the window attackers use to write into the directory.
How the attack chain works: from poisoning to Domain Admin
Step 1 — Network poisoning via LLMNR and NBT-NS
It starts with a forged response. When a workstation tries to resolve a hostname that does not exist in DNS, it broadcasts an LLMNR or NBT-NS query on the local segment. An attacker on the same network answers, impersonating the requested host. The victim sends its NTLM credentials straight to the attacker. Tools like Responder are built exactly for this.
Step 2 — Relaying to SMB or LDAP
The attacker does not try to crack the hash offline. Instead, it is relayed in real time. If the relay target is an SMB server without required signing, file system access is granted immediately. The more dangerous scenario targets the domain controller over LDAP. Using ntlmrelayx from the impacket toolkit, the attacker can forward the NTLM authentication of a machine account or user account to the DC and, if that account holds sufficient permissions, write directly into the directory.
Step 3 — Escalating to Domain Admin
Once LDAP access on the DC is obtained, several escalation paths open up. The attacker can add a computer object to the domain using the ms-DS-MachineAccountQuota attribute (often left at 10 by default), then abuse a constrained delegation or a misconfigured ACE. If the relayed account already holds DCSync rights or belongs to a delegated admin group, escalation is immediate. Resource-Based Constrained Delegation (RBCD) has become one of the most common paths from LDAP write access to Domain Admin without any exploit code.
GPO settings to enforce SMB signing
Two separate settings govern SMB signing: one on the server side, one on the client side. Both are required for real protection.
- Server side (DCs and member servers):
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server: Digitally sign communications (always)— set to Enabled. - Client side: same path, setting
Microsoft network client: Digitally sign communications (always)— set to Enabled. - For domain controllers specifically, applying this GPO through the Domain Controllers OU with high precedence ensures no DC accepts unsigned SMB sessions.
Compatibility risk is real but limited. Older network printers and NAS devices running Samba versions prior to 3.x may not support SMB signing. An inventory of non-Windows network devices before production rollout is essential. A phased approach — enforcing on DCs first, then extending to member servers after validation — reduces operational risk considerably.
GPO settings to enforce LDAP signing and channel binding
LDAP signing is configured through a registry key pushed via GPO, separate from SMB controls.
- LDAP signing (server):
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server signing requirements— set to Require signing. This GPO applies to DCs only. - LDAP channel binding: configured via the registry key
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding, DWORD value 2 to enforce binding. This value can be deployed through a GPO registry preference or a Microsoft-provided CSP. - LDAP client side:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LDAP client signing requirements— set to Require signing.
The main compatibility friction here involves applications that query LDAP through anonymous connections or simple binds — common in HR platforms, older ERPs, and some monitoring tools. For these cases, migrating to LDAPS (port 636) with a valid certificate is the cleaner fix. Leaving exceptions open on port 389 to accommodate legacy apps negates much of the protection.
To practice these scenarios hands-on before touching production, the Active Directory labs in CyberAct's catalog let you simulate the full relay chain and verify that your GPO changes actually block the attack.
What these two GPOs do not cover
Enforcing SMB signing and LDAP signing does not disable NTLM. A captured hash can still be cracked offline with enough time and compute. Disabling LLMNR and NBT-NS via GPO removes the poisoning vector that feeds the relay in the first place. The relevant settings are: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution set to Enabled, and NetBIOS over TCP/IP disabled via DHCP scope options or a WMI filter script. These two actions together form the absolute baseline for serious AD hardening.
Before deploying these controls, it is worth mapping which attack paths currently exist in your environment. A structured cyber maturity assessment surfaces the highest-priority gaps without requiring a full red team engagement first.
Frequently asked questions
Will enforcing SMB signing slow down file transfers?
The performance overhead is measurable but generally low on modern infrastructure. On heavily loaded file servers serving legacy clients, a slight latency increase is possible. In most current enterprise environments, the impact is negligible and the security gain clearly justifies the configuration change.
Can NTLM relay be blocked without enabling signing?
Partially. Disabling LLMNR and NBT-NS removes the main initial capture vector, making relay attacks significantly harder. But as long as NTLM remains active and SMB/LDAP signing is not required, an attacker with another capture method — ARP spoofing, rogue IPv6 DHCP — can still attempt a relay. Signing enforcement remains the most reliable control.
Is LDAP signing the same thing as LDAPS?
No. LDAP signing authenticates and protects message integrity over port 389 using Kerberos or NTLM. LDAPS encrypts the entire session over port 636 using TLS. They are complementary: LDAPS protects confidentiality, LDAP signing prevents tampering and relay. The recommended approach is to migrate third-party applications to LDAPS while requiring signing for all internal directory connections.
What breaks if these GPOs are applied without a prior inventory?
Legacy applications using simple LDAP binds or unsigned SMB connections may stop working immediately. The most common casualties are multifunction printers, older network monitoring tools, and some ERPs. Setting the policy to Negotiate signing before switching to Require signing lets you detect non-compliant clients through Windows event logs before making the change permanent.