SMB Relay Attack in AD Lab (Step-by-Step)

Welcome back again to my cybersecurity blog! I'm Basit Hassan, a Vulnerability Assessment and Penetration Tester passionate about ethical hacking. On this blog, I’ll be sharing tutorials, walkthroughs, and real-world exploitation techniques that I’ve personally tested all designed to help you get started and grow in the penetration testing field.


Today’s post, I’ll demonstrate how I leveraged SMB Relay attacks in my Active Directory lab to understand how attackers exploit network misconfigurations and relay authentication requests. This simulation was done in my own isolated lab environment to show how these attacks work  and more importantly, how to secure your network against them.

 What is an SMB Relay Attack?

SMB Relay is a man-in-the-middle (MITM) attack technique where an attacker intercepts and relays authentication requests from one system to another, without cracking any password. Instead of capturing and brute-forcing hashes, SMB Relay forwards the authentication to a target that trusts the sender effectively authenticating as the victim.

Attackers often combine this with LLMNR/NBT-NS poisoning to capture credentials and escalate privileges within a Windows environment.

Yesterday, I kicked off my Active Directory Attack Simulation Journey on LinkedIn, starting with LLMNR/NBT-NS Poisoning. Today, I’m continuing that journey by demonstrating how I leveraged an SMB Relay Attack within my lab environment  showing how attackers can exploit misconfigurations and how to prevent them in a real-world setting.

Lab Setup(The same lab setup i simulated on linkedln)

I built a custom Active Directory lab on my own isolated network, consisting of:

  • 1 Windows Server (Domain Controller)

  • 2 Windows Clients joined to the domain

  • A configured SQL Service with a registered SPN (Service Principal Name)

No intentional misconfigurations were made; however, I disabled Windows Defender across the domain using Group Policy (GPO) to allow my simulation to run smoothly.


 Step 1: SMB Signing Enumeration

Before running any attacks, I wanted to check whether SMB signing was enabled or required across my network. SMB signing helps protect against relay attacks by ensuring message integrity.

I used Nmap to sweep across my entire network and check SMB signing status as seen below ๐Ÿ‘‡


This scan revealed three devices on my network with port 445 (SMB) open.
(Note: If SMB wasn’t open by default, I enabled file sharing across my network to make sure SMB was active.)

  • On Windows Server, SMB signing is enabled and required by default.

  • On Windows Clients, SMB signing is enabled but not required, making them vulnerable to relay attacks.

Step 2: Starting Responder

Next, I launched Responder, just as I did in my LLMNR attack, to listen for incoming authentication requests:

Responder poisoned name resolution requests on the network, capturing NTLMv2 authentication attempts that could later be relayed.

Before the third step in my setup, I added the vulnerable Windows client IPs to targets.txt. as seen below๐Ÿ‘‡



Step 3: Running NTLMRelayX

To perform the actual relay, I used ntlmrelayx.py (from Impacket) to capture incoming hashes and relay them to a target with SMB signing not required:


Step 4: Triggering the Relay

To trigger the authentication, I manually initiated a connection to my attacker machine by typing its IP address in File Explorer:


This action caused the victim machine to authenticate using NTLM, which was then relayed to the target by ntlmrelayx.

As a result, I successfully captured an NTLMv2 hash which can be cracked with a cracking tool like hashcat or johntheripper here is a redacted image of the captured NTLMv2 hash below๐Ÿ‘‡


Step 5: Gaining an SMB Shell

With a successful relay, ntlmrelayx can also open an SMB shell on the target, allowing an attacker to execute commands, list shares, or even drop payloads  depending on permissions.


So after this i started a listener as seen to gain SMB shell


Mitigation

To defend against SMB Relay attacks:

  • Enable SMB signing and require it on all hosts (even if it slightly slows down file sharing the security benefits are worth it!)Disable LLMNR and NBT-NS through Group Policy.

  •  Use strong authentication like Kerberos instead of NTLM.

  •  Segment the network and enforce least privilege.

That’s all for today’s post! In the next part of my AD lab journey, I’ll explore more stay tuned! ๐Ÿ”ฅ

Comments

Popular posts from this blog

Using Hydra to Brute-Force SSH And WI-Fi Login Portal

Discover AWS Organization ID Via S3 Bucket