NTLM relay defence: SMB, LDAP and EPA

NTLM relay does not crack a password or reverse a challenge–response value. An intermediary forwards a legitimate client’s authentication exchange to another service and then uses the resulting session within that identity’s permissions. The chain requires a client to emit NTLM towards the intermediary, a target protocol that does not bind authentication to the correct channel or service, and useful rights for the relayed account.

The answer-first defence is layered: SMB signing protects an SMB session, LDAP signing protects LDAP message integrity, LDAP channel binding ties authentication to TLS, and Extended Protection for Authentication provides corresponding binding for Windows Authentication in IIS. These controls are not interchangeable. HTTPS alone and “we use NTLMv2” do not close every relay path.

This guide describes safe assessment and detection without payloads, coercion commands or domain-compromise instructions. Active validation belongs between dedicated systems and test identities with harmless permissions.

How does NTLM challenge–response work?

NTLM is a family of authentication protocols used by Windows and many appliances. In a simplified exchange, the client advertises capabilities, the server sends a challenge, and the client responds with a value derived from its secret and session data. The server or a domain controller validates the response. The password need not travel across the network in cleartext.

Keeping the password off the wire does not prevent relay. An intermediary does not need the secret: it obtains a challenge from the target, forwards that challenge to the client and returns the client’s response to the target. If the target cannot prove that authentication was generated for its specific channel or service, it can establish a session for the intermediary.

NTLMv2 strengthens many elements compared with NTLMv1, but it is not a universal relay defence. Message Integrity Code, channel binding and target-protocol signing depend on variant, negotiation and updates. An assessment cannot stop at LMCompatibilityLevel; it needs a matrix of clients, targets and enforced protections.

Three components of every relay chain

1. An authentication source

The client must send NTLM to an intermediary-controlled destination. The cause can be a mistaken name, automatic discovery, a reference to a remote resource, an application that fetches a URL or an RPC behaviour that initiates a connection. The existence of an authentication-coercion primitive is only the first precondition; it does not prove successful relay.

Catalogue services capable of initiating authentication, network zones, outbound SMB/HTTP policy, name resolution and service identities. Computer accounts for high-value servers deserve particular attention because their directory rights may exceed those of an ordinary user.

2. A target without integrity or binding

The destination must accept authentication without a control that prevents forwarding. SMB needs required signing. LDAP depends on transport and mechanism: signing protects SASL messages, while channel binding protects authentication over TLS. IIS Windows Authentication uses EPA through channel or service binding.

3. Useful identity permissions

Relay creates a session as the client, not “an administrator by default”. Impact depends on target rights. A normal user may have read-only access, a computer may control a specific directory object, and a service operator may alter application configuration. Reports should separate successful authentication from operations the destination authorises.

That distinction prevents scanner severity inflation. A permission graph may still show that a modest session enables another step, such as changing delegation or a certificate template. Assess relay alongside the broader Active Directory security model.

SMB signing: message integrity and relay resistance

SMB signing uses a session key and dialect-dependent algorithm to sign messages. The receiver verifies integrity and that a packet belongs to the negotiated session. A relay intermediary cannot simply use an SMB session when the destination requires valid signatures it cannot produce without the appropriate session key.

The critical word is requires. “Enabled if negotiated” does not guarantee protection when a peer can negotiate an unsigned session. Assess client outbound and server inbound behaviour separately and observe actual negotiation for each device class. Domain controllers, file servers, NAS appliances, printers and legacy systems can have different settings.

Microsoft hardened defaults in Windows 11 24H2 and Windows Server 2025. Its documentation distinguishes editions and directions, however; do not project one statement about default signing onto every host. An upgrade preserving old GPO can also differ from a new deployment. Collect configuration and validate sessions rather than infer solely from OS version.

SMB encryption protects confidentiality and integrity but remains a distinct setting. Require signing regardless of whether individual shares mandate encryption. Disabling signing for a legacy appliance weakens the whole destination; modernisation, replacement or isolation is safer.

LDAP signing: what does a domain controller reject?

LDAP signing cryptographically protects LDAP messages in SASL sessions such as Negotiate, Kerberos or NTLM. When a domain controller requires signing, it rejects a SASL bind that does not request integrity and rejects a simple bind over an unencrypted channel. Microsoft documents Domain controller: LDAP server signing requirements and an audit-first rollout.

Port 389 does not always mean cleartext; it can carry STARTTLS or SASL signing. Port 636 does not automatically mean full relay resistance; LDAPS provides TLS, but selected scenarios remain if NTLM over TLS is not bound to the channel with CBT. A report must describe the bind and protection rather than the port number alone.

Events 2886–2889 support migration. Event 2887 summarises unsafe binds, while detailed diagnostics produce 2889 with client address and identity. Observe a full business cycle: a monthly job or infrequent HR system may not appear in a short capture window.

Enabling “Require signing” without inventory can stop applications, network devices and scanners. A safe sequence is observe → identify owner → upgrade or reconfigure → pilot → enforce → monitor rejects. Reverting globally after the first failure restores exposure; a segmented, expiring exception is preferable.

LDAP channel binding: why TLS is not sufficient

A Channel Binding Token derives a value from the TLS session and carries it in authentication. The server compares that value with its own channel. If an intermediary terminates one TLS session from the client and opens another to the server, values differ. Authentication becomes bound to the particular tunnel.

LDAP channel-binding policy supports compatibility observation and enforcement. Microsoft documents events 3039–3041 for unsupported clients, failures and success. Before full enforcement, identify NTLM or simple-bind-over-TLS clients, libraries that omit CBT and appliances without vendor fixes.

Signing and channel binding solve different problems. LDAP signing gives SASL message integrity; CBT binds authentication to TLS. An organisation may need both across its used paths. Do not treat LDAPS as a substitute for signing policy without analysing bind types.

EPA in IIS: channel binding and service binding

Extended Protection for Authentication extends Windows Authentication with two concepts. Channel binding uses CBT primarily over TLS. Service binding uses SPNs so client and server agree on the intended service, which matters without TLS or when a reverse proxy or load balancer terminates it.

EPA configuration requires a correct topology model. With TLS termination, the backend may not observe the same channel as the client; a wrong mode can break sign-in or provide no effective protection. Inventory SPNs, kernel-mode authentication, application-pool identity, proxies, host headers and allowed scenarios. Validate in a representative environment before phased enforcement.

AD CS Web Enrollment and CES are particularly sensitive: a successful session may let the relayed identity request a certificate from an available template. Microsoft Defender for Identity identifies endpoints without HTTPS/EPA as ESC8 exposure. The full PKI model is in our AD CS certificate attacks and ESC assessment guide.

Other IIS applications using Windows Authentication need review too: management panels, deployment tools and reporting systems. Each creates different post-authentication impact, so prioritise by user and computer-account privileges.

Cross-protocol relay

An intermediary need not forward SMB to SMB. NTLM received in one context can be directed to LDAP or HTTP if negotiated properties and target protections permit it. That is why SMB signing on file servers does not close relay to a directory or web endpoint.

Use a source-to-target defence matrix:

NTLM source	Potential target	Target-side control
SMB/UNC	SMB	required SMB signing
SMB/HTTP/RPC	LDAP SASL	required LDAP signing
NTLM over TLS	LDAPS	LDAP channel binding / CBT
Windows Authentication	IIS HTTPS	EPA channel binding
Windows Authentication behind proxy	IIS	correct service binding/SPN and EPA architecture

This table is not an exploit list. It helps defenders verify that each service rejects authentication moved into another context.

A safe NTLM relay assessment methodology

Passive phase

Collect NTLM policies, SMB signing requirements, LDAP signing/channel-binding settings, Windows Authentication and EPA configurations, SPNs, reverse proxies and logs. Identify legacy systems and applications using IP addresses or aliases, which often cause fallback from Kerberos to NTLM.

Flow modelling

Build client/service → protocol → destination → authentication package → binding/integrity → effective rights. Explain why Kerberos is absent: missing SPN, IP connection, alias, trust limitation or an application that explicitly uses NTLM.

Controlled validation

An active scenario uses only client-owned source, intermediary and destination hosts, a dedicated non-admin account and a harmless resource. Agree limits, addresses, monitoring and emergency stop first. Do not coerce authentication from a domain controller, CA or administrator identity in production.

Evidence can be confirmed negotiation without required protection plus access to a test resource. Where configuration proves a critical chain unambiguously, active compromise is unnecessary. Penetration testing should reduce risk, not maximise demonstration impact.

Cleanup and retest

Rotate the test identity secret, remove artefacts, restore approved state and confirm that signing, CBT or EPA causes the same negative scenario to fail. Also verify that legitimate clients continue to work.

Detecting NTLM relay

The best detection combines anomalous authentication with a destination session. NTLM events alone are common. Look for inconsistencies: a computer account authenticates from an unexpected host; source network does not match the device; one identity opens near-simultaneous sessions to unrelated services; authentication is followed by an unusual directory change or certificate issuance.

Useful telemetry includes the NTLM Operational log, 4624 sign-ins using NTLM, 4776 credential validation, SMB and IIS logs, Directory Service 2887/2889 and 3039–3041, directory modifications and AD CS events. Microsoft Defender for Identity detects selected relay variants, but detection never replaces protocol integrity enforcement.

Create correlations for:

new or rare NTLM from a server that normally uses Kerberos;
a critical server computer account reaching an unusual endpoint;
an LDAP bind followed by an ACL, RBCD, group or credential change;
HTTP enrolment after unusual authentication and subsequent certificate issuance;
2889/3039 growth during rollout and continued attempts after enforcement;
GPO or IIS changes that disable SMB signing, LDAP protection or EPA.

Send events to an isolated SIEM and protect SOC identities under the principles in our Microsoft 365 security and PAM guide.

Migrate away from NTLM without an outage

The destination state is Kerberos and modern authentication, followed by NTLM restriction or blocking. Do not begin with a global deny. Enable auditing and catalogue process, owner, target and fallback reason. Fix SPNs and DNS, IP and alias use, service identities, libraries and appliances.

Give exceptions a minimal scope, segmentation and retirement date. A legacy host should not reach domain controllers and management panels beyond strict need. Microsegmentation is part of Zero Trust architecture, but it does not replace cryptographic session binding.

Roll out in waves:

audit NTLM, unsigned LDAP and missing CBT;
require SMB signing on critical resources;
repair LDAP clients and require server signing;
enforce channel binding for LDAPS after observation;
enable EPA on IIS, prioritising AD CS and management;
restrict outbound NTLM with managed exceptions;
monitor rejects and retire exceptions.

Anti-relay checklist

Conclusion

NTLM relay is a context problem: a cryptographically valid response for one identity is used in the wrong session or service. Effective defence makes every destination answer not only “is this the correct identity?” but also “does this authentication belong to this channel and this service?”

If you need an exposure map, safe signing/CBT/EPA pilot or technical migration retest, contact Breachroad. The assessment will show real prerequisites, permission impact and telemetry controls without distributing authentication-coercion techniques.