We Love Relaying Credentials: A Technical Guide to Relaying Credentials Everywhere

A deep dive into NTLM relay attacks, the Impacket ntlmrelayx.py toolset, and the latest offensive techniques from multi-relay to shadow credentials and AD CS abuse.

NTLM relay attacks remain one of the most impactful classes of vulnerabilities in Windows enterprise environments. Despite decades of mitigations, misconfigurations in session signing, LDAP channel binding, and certificate services continue to expose organizations to credential forwarding at scale. This guide examines how the Impacket library’s ntlmrelayx.py tool has evolved to exploit these weaknesses, covering multi-relay, cross-protocol forwarding, AD CS abuse, shadow credential injection, and StartTLS bypasses.

Relay target protocols

Coercion server types

ESC1-8

AD CS attack surface

Passwords transmitted

1. NTLM Relay Explained

NTLM (NT LAN Manager) is a challenge-response authentication protocol used across Windows networks. Unlike Kerberos, NTLM does not provide mutual authentication by default, making it inherently susceptible to Man-in-the-Middle relay attacks. The protocol operates through a three-message handshake:

NTLM Three-Way Handshake

Step 1Client → Server

NEGOTIATE_MESSAGE

Client sends NEGOTIATE_MESSAGE declaring supported NTLM features and flags (e.g., NTLMv2, 56-bit/128-bit encryption, signing/sealing capabilities).

Step 2Server → Client

CHALLENGE_MESSAGE

Server responds with CHALLENGE_MESSAGE containing a random 8-byte nonce (ServerChallenge), negotiated flags, and server information (TargetInfo AV_PAIRs).

Step 3Client → Server

AUTHENTICATE_MESSAGE

Client computes NTProofStr using HMAC-MD5 over the ServerChallenge and client blob, sends AUTHENTICATE_MESSAGE with NtChallengeResponse, LmChallengeResponse, domain, username, and optional MIC.

The client’s password hash is never transmitted over the wire. Only the challenge-response proof is sent, which a Man-in-the-Middle attacker can relay to another target.

The critical observation is that the client’s secret (NT hash) is never transmitted. Instead, the client proves knowledge of the secret by computing a response to the server’s challenge. An attacker positioned between the client and a legitimate server can intercept these messages and forward (relay) them to a different target, effectively authenticating as the victim on that target without ever knowing their password.

Session Signing Limitation: The primary mitigation for NTLM relay is session signing (SMB signing, LDAP signing, HTTP Extended Protection for Authentication). However, signing only protects the session after authentication — it does not protect the authentication exchange itself. If the target requires signing but the attacker cannot provide it (because they lack the session key derived from the victim’s NT hash), the post-authentication session will fail. Critically, many environments leave signing as “not required” on servers by default, and LDAP channel binding is not enforced unless explicitly configured.

SMB Signing

Required by default only on domain controllers. Workstations default to 'enabled but not required', allowing relay.

LDAP Signing

Not required by default. GPO 'Domain controller: LDAP server signing requirements' must be set to 'Require signing'.

HTTP EPA

Extended Protection for Authentication (channel binding) is disabled by default on IIS, Exchange, and AD CS web enrollment.

LDAP Channel Binding

Disabled by default. Must be explicitly set to 'Required' via LdapEnforceChannelBinding registry key (value 2).

2. NTLMrelayx Basics

ntlmrelayx.py is Impacket’s Swiss-army knife for NTLM relay attacks. It operates multiple inbound servers to capture NTLM authentication attempts and relays them to configurable targets across several protocols.

Inbound Servers (Credential Capture)

SMB Server — Listens on TCP/445. Most common coercion target (PetitPotam, PrinterBug, DFSCoerce).
HTTP/HTTPS Server — Listens on TCP/80 and TCP/443. Captures NTLM via WWW-Authenticate negotiation.
WCF Server — Windows Communication Foundation endpoint for .NET service coercion.
RAW Server — Low-level TCP listener for custom NTLM extraction scenarios.

Outbound Relay Targets

SMB — Execute commands, dump SAM/LSA secrets, enumerate shares.
LDAP/LDAPS — Modify AD objects, add computer accounts, configure RBCD, dump domain info.
HTTP/HTTPS — Target Exchange (EWS), AD CS web enrollment, OWA, and other web services.
IMAP/IMAPS — Access mailboxes, exfiltrate email data.
MSSQL — Execute SQL queries, enable xp_cmdshell, pivot through database links.
SMTP — Send email as the relayed user.

Cross-Protocol Relaying: One of ntlmrelayx’s most powerful features is cross-protocol relay. NTLM authentication tokens are protocol-agnostic at the message level — a NEGOTIATE/CHALLENGE/AUTHENTICATE exchange captured over SMB can be forwarded to an LDAP, HTTP, or MSSQL target. This dramatically expands the attack surface because signing requirements differ across protocols.

# Capture over SMB, relay to LDAP
ntlmrelayx.py -t ldap://dc01.corp.local -smb2support

SOCKS Mode

When invoked with the -socks flag, ntlmrelayx maintains authenticated sessions in a SOCKS proxy rather than executing a one-shot attack. Operators can then point arbitrary tools (smbclient.py, secretsdump.py, mssqlclient.py) through the proxy to reuse the relayed session interactively. This is especially valuable when only one coercion opportunity exists.

SOCKS proxy usage:

# Start relay in SOCKS mode
ntlmrelayx.py -t smb://target01.corp.local -socks -smb2support

# Use relayed session via proxychains
proxychains smbclient.py -no-pass CORP/admin@target01.corp.local

3. Multi-Relay (Impacket 0.9.21+)

Prior to the multi-relay feature, each inbound NTLM authentication could only be relayed to a single target. If an operator wanted to relay to five targets, they needed the victim to authenticate five separate times. The multi-relay feature, introduced in Impacket 0.9.21, solves this by identifying the connecting user before committing to a relay target, then forcing re-authentication to relay a single victim connection to multiple targets simultaneously.

Multi-Relay Attack Flow

Phase 1 — Identity Capture

Victim connects to attacker's rogue SMB/HTTP server. Attacker completes the first NTLM exchange to extract the username and domain from the AUTHENTICATE_MESSAGE without forwarding it to any real target.

Phase 2 — Forced Re-authentication

Attacker replies with STATUS_SESSION_EXPIRED (SMB) or HTTP 307 Temporary Redirect (HTTP), forcing the victim client to restart the NTLM handshake. The client transparently re-authenticates using the same cached credentials.

Phase 3 — Parallel Relay

For each configured target matching this user, the attacker initiates a fresh NTLM handshake with the real target server. The victim’s NEGOTIATE is forwarded; each target’s CHALLENGE is relayed back; each AUTHENTICATE is forwarded to authenticate on every target simultaneously.

Phase 4 — Post-Exploitation

Authenticated sessions are established on all targets. Actions are executed per-target: secretsdump on SMB, LDAP modifications, ADCS certificate enrollment, shadow credential injection, etc. SOCKS mode can keep sessions alive for manual tool use.

A single victim connection is amplified across every matching target, eliminating the need for repeated coercion.

SMB Multi-Relay Mechanism

In SMB, multi-relay exploits the STATUS_SESSION_EXPIRED error code. After completing the initial NTLM exchange to identify the user, the attacker’s rogue SMB server returns STATUS_SESSION_EXPIRED on the victim’s first SMB request. The Windows SMB client automatically re-authenticates by performing a new Session Setup with a fresh NTLM exchange. This re-authentication is transparent to the user and does not trigger any prompts or warnings.

The attacker repeats this cycle for each configured target: complete an NTLM exchange, relay it to the next target, then trigger another STATUS_SESSION_EXPIRED to obtain yet another fresh authentication. Each relay is a completely independent NTLM handshake with a unique ServerChallenge from the real target.

4. Defining Targets

Targets in ntlmrelayx use a URI format following the structure scheme://authority/path. The scheme defines the relay protocol, the authority specifies the target host (and optional port), and the path can encode additional parameters.

Target URI examples:

# Basic targets
smb://192.168.1.100
ldap://dc01.corp.local
https://mail.corp.local/ews/
mssql://sqlserver.corp.local

# Targets file (-tf)
smb://192.168.1.100
smb://192.168.1.101
ldap://dc01.corp.local

Named vs. General Candidates

Multi-relay introduces a distinction between named candidates and general candidates. Named candidates are targets associated with a specific user — for example, “relay CORP\admin to smb://target01”. General candidates accept any relayed user. When a victim authenticates, the multi-relay engine first checks for named candidates matching the victim’s identity, then falls back to general candidates.

Named Candidates

Specific user-to-target mappings. High-value targets reserved for specific privileged accounts (e.g., relay Domain Admin to DC).

General Candidates

Any authenticated user is relayed. Useful for broad-scope attacks like RBCD delegation or shadow credential injection on many machines.

Targets File (-tf)

Specify targets in a file, one URI per line. Supports mixing protocols and named/general candidates for complex engagements.

Dynamic Target Generation

Combine with --remove-target to auto-remove targets after successful relay, preventing duplicate attacks in large environments.

5. What’s New in Recent Releases

Key features added across Impacket 0.9.21 through 0.10.0 and beyond.

Multi-Relay in HTTP Server (v0.10.0)

The HTTP server gained multi-relay support using HTTP 307 Temporary Redirect. After the initial NTLM AUTHENTICATE_MESSAGE is received and the victim’s identity is extracted, the server responds with a 307 redirect to the same URL. The client’s browser or HTTP client follows the redirect and performs a completely new NTLM handshake on the redirected request.

This mirrors the SMB STATUS_SESSION_EXPIRED technique but for HTTP contexts. It is particularly effective when combined with coercion methods that use HTTP callbacks (e.g., WebDAV-based coercion via PetitPotam over HTTP, or abusing Outlook home-page links). Each redirect yields a fresh NTLM exchange that can be relayed to a different target.

Disabling Multi-Relay

Multi-relay can fail when the victim’s SMB client enforces signing. In this scenario, the STATUS_SESSION_EXPIRED trick causes the client to attempt session re-establishment with signing negotiation, which the attacker’s rogue server cannot satisfy (since it lacks the session key). This results in the client disconnecting entirely.

The --no-multirelay flag disables the identification-then-reauth cycle and reverts to classic single-target relay behavior. This ensures the one available authentication is not wasted on identity capture.

Target Type	Multi-Relay Default	Notes
SMB	Enabled	Fails if client enforces signing
HTTP	Enabled (v0.10.0+)	Uses 307 redirect
LDAP/LDAPS	N/A (outbound only)	Relay target, not capture server
WCF	Not supported	Single-relay only
RAW	Not supported	Single-relay only

Attacking Active Directory Certificate Services (AD CS)

AD CS is a high-value relay target because its web enrollment endpoint (/certsrv/) typically does not enforce EPA. The ESC8 attack relays NTLM authentication to the Certificate Authority’s HTTP enrollment interface to request a certificate on behalf of the victim. This certificate can then be used for Kerberos PKINIT authentication, effectively converting a one-time NTLM relay into persistent credential access.

Combined with ESC1 (permissive certificate template allowing arbitrary SANs) or ESC6 (EDITF_ATTRIBUTESUBJECTALTNAME2 flag on the CA), the --altname parameter allows the attacker to request a certificate for any user — including Domain Admins — regardless of who was relayed.

AD CS relay command example:

ntlmrelayx.py -t http://ca01.corp.local/certsrv/certfnsh.asp \
  --adcs --template DomainController \
  --altname administrator@corp.local \
  -smb2support

ESC8: Relay to /certsrv/ web enrollment — no EPA by default.
ESC1: Template allows requester-supplied SAN — request cert as any user.
ESC6: CA-level flag allows SAN override — same effect as ESC1 but CA-wide.
Output: Base64 PFX certificate usable with Rubeus, Certipy, or PKINITtools.

Shadow Credentials

Shadow Credentials exploit Kerberos PKINIT pre-authentication by manipulating the msDS-KeyCredentialLink attribute on an Active Directory computer or user object. When an attacker has write access to this attribute (obtained via NTLM relay to LDAP), they can inject a new key credential containing their own public/private key pair. The target object can then be authenticated via PKINIT using the attacker’s private key, yielding a TGT without knowing the object’s password.

This technique is stealthier than modifying the msDS-AllowedToActOnBehalfOfOtherIdentity attribute (RBCD) because msDS-KeyCredentialLink is less commonly monitored and does not require adding a new computer account.

Shadow Credentials flags:

ntlmrelayx.py -t ldap://dc01.corp.local \
  --shadow-credentials \
  --shadow-target ws01$ \
  --pfx-password "P@ssw0rd" \
  --export-type PEM \
  --cert-outfile-path /tmp/ws01_shadow \
  -smb2support

--shadow-credentials: Enable shadow credential injection via LDAP relay.
--shadow-target: Specify the target AD object (computer$ or user) to modify.
--pfx-password: Password to protect the exported PFX/PEM certificate.
--export-type: Output format — PFX (PKCS#12) or PEM.
--cert-outfile-path: File path for the generated certificate and private key.

StartTLS Bypass for LDAP Channel Binding

LDAP Channel Binding (CBT) ties the NTLM authentication to the TLS channel, preventing relay to LDAPS (TCP/636). However, plain LDAP (TCP/389) with StartTLS uses a different channel binding mechanism that ntlmrelayx can exploit. When targeting LDAP, ntlmrelayx automatically attempts to upgrade the connection using StartTLS after the initial TCP handshake but before the NTLM bind.

Because the TLS session is initiated by the attacker (not the victim), the channel binding token in the victim’s NTLM AUTHENTICATE_MESSAGE does not match the attacker-to-DC TLS channel. If the DC does not enforce channel binding (the default), the mismatch is ignored and the relay succeeds over a TLS-protected connection. This provides encryption for the relay traffic while bypassing the intended security of channel binding.

StartTLS relay:

# Target plain LDAP — ntlmrelayx auto-upgrades to StartTLS
ntlmrelayx.py -t ldap://dc01.corp.local -smb2support

# vs. LDAPS (blocked by channel binding if enforced)
ntlmrelayx.py -t ldaps://dc01.corp.local -smb2support

6. Defensive Recommendations

Hardening configurations to neutralize NTLM relay across all vectors.

No single mitigation is sufficient. NTLM relay attacks exploit the gap between authentication and session security. A defense-in-depth approach is essential: enforce signing, enable channel binding, restrict NTLM usage, and monitor for relay indicators.

Enforce SMB Signing

Set 'Microsoft network server: Digitally sign communications (always)' to Enabled on ALL machines, not just domain controllers.

Require LDAP Signing + Channel Binding

Set LDAP server signing to 'Require signing' and LdapEnforceChannelBinding to 2 (Required) on all domain controllers.

Enable EPA on All HTTP Services

Configure Extended Protection for Authentication on IIS, Exchange, AD CS, and any internal web application using Windows Authentication.

Disable NTLM Where Possible

Use GPO 'Network security: Restrict NTLM' policies to audit and progressively block NTLM authentication in favor of Kerberos.

Monitor for Relay Indicators

Alert on Event ID 4624 with logon type 3 (Network) where source and destination IPs differ from the authenticated account's expected workstation.

Harden AD CS Templates

Remove the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag from templates. Disable EDITF_ATTRIBUTESUBJECTALTNAME2 on the CA. Require manager approval for sensitive templates.

NTLM relay is not a vulnerability in a single product — it is an architectural weakness in challenge-response authentication without channel binding. Mitigation requires hardening every protocol endpoint independently.
— SecureAuth Technology Team

Explore Related SecureAuth Solutions

Products

Workforce Authority

Secure employee access with adaptive MFA and continuous verification

Assurance Authority

Intelligent risk engine with behavioral analytics and continuous risk scoring

Industry Solutions

Technology

Identity infrastructure for SaaS providers and tech companies

Ready to transform your identity security?

See how SecureAuth's Continuous Authority platform can protect your organization.

Request a Demo Explore Platform

About SecureAuth

SecureAuth provides identity and access management solutions that enable enterprises to implement customized, resilient authentication infrastructure. Through Continuous Authority, flexible deployment options, and deep composable capabilities, SecureAuth helps organizations defend against modern identity threats while maintaining usability and operational efficiency.

Platform• Customer Authority• Workforce Authority