Agent, your mission—code-named “Digital Lockpick”—is set within the cyber walls of Active Directory, the nexus of network security. Your mission, should you choose to accept it: to exploit the Server Message Block (SMB) protocol, a seemingly innocuous yet vital pathway through which information travels.
This operation hinges on mastering the SMB Relay Attack, a tactic that will allow you to navigate through secured checkpoints without detection, bypassing traditional credentials. With Impacket as your toolkit and its -i switch as your master key, you’ll be able to open doors that were never meant to be unlocked.
Expect resistance. The network is vigilant, and time is of the essence. Your skills in maneuvering through these digital corridors must be precise. The objective? To demonstrate the art of the possible and to expose the chinks in the armor of network security.
Setting up the stage for our SMB Relay Attack
Before diving into the mechanics of the attack, let’s set up our virtual stage. Our lab consists of a modern setup with a Windows Server 2022 acting as the cornerstone of our Active Directory domain. Alongside it, we have two virtual machines—let’s call them smouk1 and smouk2—both joined to the domain, mimicking a typical enterprise environment. Our attack platform is a Kali Linux machine, strategically positioned within the same network to interact directly with these Windows entities.
Introducing the Responder tool
To kick things off, we’ll start with a critical tool in our arsenal: Responder For those unfamiliar, Responder is a powerful network tool for protocol analysis and network forensics. It’s especially notorious for its ability to listen to network traffic and respond to service requests such as LLMNR, NBT-NS, and MDNS, which are often used as a fallback when DNS fails. By doing so, it can poison the service request and redirect the traffic to the attacker’s machine, essentially enabling us to intercept or manipulate these communications.
In our scenario, we’ll launch Responder with a specific set of options to maximize its effectiveness:
Here’s what each switch means:
-I eth0: Specifies the network interface to listen on, which is eth0 in our case. This should be adapted if your network interface has a different name.
-d: Enables SMB and HTTP server functionalities, critical for the types of attacks we’re focusing on.
-P: Enables Responder’s proxy functionalities, allowing it to forward traffic after manipulating it, providing a seamless yet deceptive flow.
-v: Runs Responder in verbose mode, giving us a detailed output of all the operations it’s performing, which is invaluable for understanding the attack’s progression in real-time.
By setting up Responder this way, we’re effectively preparing to intercept and manipulate the SMB communications, laying the groundwork for executing our SMB Relay Attack. This strategic use of Responder not only illustrates the vulnerabilities present in network configurations but also underscores the importance of securing network protocols against such intrusions, also make sure that SMB and HTTP options are turned off.
Launching the attack with Impacket’s-ntlmrelayx
With Responder quietly laying the groundwork by capturing traffic, the next step is to introduce a more direct attack tool—Impacket’s-ntlmrelayx. This tool is designed to perform the actual SMB Relay Attack by relaying NTLM authentication sessions and attempting unauthorized access to the network resources.
How ntlmrelayx fits into our strategy
Once we’ve intercepted the authentication requests with Responder, ntlmrelayx takes the baton and uses those credentials to gain unauthorized access. To set this up in our lab environment, we use the following command:
Here’s the breakdown of the command options:
-tf iptargets.txt: This option tells ntlmrelayx where to find the list of target IP addresses. In our case, iptargets.txt contains the IPs of our Windows Server 2022 and the two domain-joined VMs.
-smb2support: Enables the tool to support SMB2, which is crucial given the modern Windows environments we are dealing with that likely use SMB2 or SMB3 by default.
-i: This critical switch initiates an interactive SMB shell on successful relay, allowing us to execute commands directly on the target system.
Using ntlmrelayx with these parameters allows us to not just authenticate as the intercepted user but also to interact with the compromised system as if we were legitimately logged in. This can be incredibly powerful and dangerous, providing direct access to execute commands, deploy payloads, or even create new user accounts for persistent access.
This step is where theory meets practice, and we see the real-time effects of how intercepted credentials can be leveraged to breach network defenses. It’s a potent demonstration of why network security measures, such as SMB Signing and proper network segmentation, are crucial for protecting against such sophisticated attacks.
Upon launching ntlmrelayx with our targeted approach, the screen comes alive with confirmation of our preparatory steps. The output indicates that various protocol clients have been successfully loaded, including those for SMB, HTTP(S), LDAP(S), and more. These are the tools of the trade for ntlmrelayx, each representing a different method of communication that the tool can exploit.
The line “Running in relay mode to hosts in targetfile” is especially significant. It means our relay setup is armed and active, ready to intercept any authentication request sent to the IPs listed in our iptargets.txt file.
With services for HTTP and SMB set up and listening, and a RAW Server waiting on port 6666, our digital trap is set. We’re effectively standing by, waiting for network conversations to eavesdrop on or hijack—this is the hacker’s stakeout. The simplicity of the output belies the complexity and potential impact of what’s happening under the hood: we’ve created a multifaceted surveillance system that’s waiting for the opportune moment to strike.
As we see the final message, “Servers started, waiting for connections,” the anticipation builds. We are now in the critical phase of the attack, where any moment could lead to the breakthrough we need to access the targeted systems. This is where patience pays off in the world of network penetration testing.
The moment of truth: attack execution and user interaction
As the user on the network reaches out to a shared resource, a login prompt stands guard, denying entry to the digital trove. Little do they know, this routine action triggers a cascade within our attack framework. The terminal on the left springs to life, logging each step of our orchestrated ambush—Responder springs its trap, capturing the query, and poisoning the network’s attempts at resolution.
The symphony of protocols listed confirms the preparedness of our tools, from IMAP to LDAP, ready to impersonate and deceive. As Responder lays the false tracks, ntlmrelayx waits in the shadows, primed for action. Suddenly, the connection is made—our target unwittingly shakes hands with the enemy, and the attack sequence initiates. Success and failure messages flicker in real-time; this is the ebb and flow of cyber combat.
In the face of an ‘Access Denied’ prompt, the real drama unfolds out of sight, recorded in the logs of our Kali machine. Here, every attempt is a potential key to the kingdom. Each “Authenticating against” line is a narrative of siege warfare, as ntlmrelayx relentlessly probes for a chink in the armor.
As the digital dust settles from the initial engagement, we open a new line of communication on our attacker machine—a command line interface that serves as the gateway to our newly compromised domain. By executing nc 127.0.0.1 11000, we invoke Netcat, the network utility dubbed the Swiss Army knife of networking, to connect to a local port opened by the ntlmrelayx attack.
This simple, yet powerful command, nc (Netcat), followed by the loopback address 127.0.0.1 and port 11000, is our secret knock on the backdoor we’ve just installed. The prompt that follows, “Type help for list of commands”, is the whisper of a hidden world now at our fingertips. We are in—inside a shell that grants us the power to commandeer the target system.
The # symbol at the command prompt is the new ground zero, from where we can launch further reconnaissance, escalate privileges, or exfiltrate data, all depending on the commands we choose to execute next. This is the culmination of our SMB Relay Attack, where we step through the looking glass into the heart of the target system, poised to explore the secrets it holds.
Conclusion and a technical debrief on the SMB Relay attack
Setting aside the playful spirit of the narrative, aspiring hackers, pentesters, red teamers, and even blue teamers must grasp the essence of what we’ve accomplished here. We commenced with a controlled lab setup, using a Windows Server 2022 and two VMs within an Active Directory domain, along with our attack platform, a Kali Linux machine.
Utilizing the Responder tool, we initiated the first phase by capturing network traffic and exploiting the trust of fallback protocols like LLMNR and NBT-NS, leading to the poisoning of these service requests. This step is crucial as it allows for the interception of NTLM authentication attempts.
Following this setup, we introduced the ntlmrelayx utility from the Impacket suite to execute the relay attack. The command-line flags were meticulously chosen: -tf to target a predefined list of IP addresses, -smb2support to enable compatibility with the prevalent SMB protocol version in modern systems, and -i to trigger an interactive shell upon successful exploitation.
As the user on the target network attempted to access a shared resource, our interception techniques via Responder manipulated the network traffic, redirecting the authentication process to our attacker-controlled machine. With ntlmrelayx, these intercepted credentials were then used to authenticate against the target, allowing us to gain unauthorized access.
The terminal output displayed the status of our engagement, capturing the to-and-fro of network requests and the attempts at relayed authentication — a testament to the potency of our strategy. Upon achieving a successful relay, we utilized Netcat to connect to the listening port established by ntlmrelayx, granting us an interactive command shell on the target system. This access marked the culmination of the attack, providing us the capability to execute arbitrary commands within the compromised environment.
This exercise illustrates the vulnerability of network protocols and the importance of securing them against such intrusions. It also highlights the necessity for rigorous security measures, like enforcing SMB signing and educating network users to prevent credential interception and relay attacks. As you reflect on this operation, remember that the true strength of a cybersecurity professional lies not only in understanding how to execute these attacks but also in applying this knowledge to defend and secure networks against potential threats.
Smouk out!
If you want to learn more about Hacking Active Directory take a look at our brand new course Active Directory for Hackers part of our Subscriber Training Level.
