Once your on an internal network your next thought maybe how can I man in the middle (MITM) systems on the network? OR How can I identify vulnerabilities in what appears to be a fully patched environment across systems? One way that often works while performing an internal pentest is to intercept broadcast protocols like LLMNR/NBNS or HTTP/SMB traffic and relay NTLM authentication handshakes to other hosts. By establishing a malicious server on the network we can relay these network authentication handshake attempts from legitimate server exchanges to our own with an outcome of obtaining access to system resources that we couldn’t access before. This blog post is a follow-on to “5 Ways We Get On Your Network” with a closer look at relaying SMB techniques.

SMB Relay Attacks, essentially occur once an attacker inserts themselves in the middle of the NTLM challenge/response protocol. In order for a SMB relay attack to occur the attacker just needs to cause the victim to initiate an HTTP or SMB connection back to the attacker. The multicast name resolution manipulation of NBNS/LLMNR spoofing is only one means of accomplishing this. Typically with SMB Relay attacks the attacker inserts themselves into the middle of an exchange after selecting a target server to authenticate to, which we will cover in our attacker scenario later. The attacker then waits for a system on the network to authenticate to their machine while being connected to the network.

Sometimes patch management systems, antivirus updates, vulnerability scanners, administrator scripts, etc. will attempt to authenticate to hosts systematically across systems on the network. Typically the way to weaponize this is to have the automated process connect to the attackers system with the intention of authenticating to a system on the local network (that the attacker is targeting) for the MITM process to begin (assuming SMB signing doesn’t prevent us). Later in this blog you will see an example of Nessus a vulnerability scanner that has been given credentials to perform an automated scan against a host falling victim to a SMB relay attack.

High Level Overview of SMB Relay Attacks:
Once the authentication process is started the attackers target generates a challenge and sends it back to the attacker. The attacker then sends the challenge back to the originating automated process and/or system. The automated process and/or system then encrypts the challenge with the appropriate password hash and sends it to the attackers system. The attacker finally passes the encrypted response back to his target and with success authenticates to the targeted system.

Now to better understand this attack and process lets jump into a lab scenario that exploits the exchange between a windows client and its domain controller that leads to a meterpreter shell spawning to our attacker system once successful.

Attackers Scenario:

– Attackers IP: 192.168.56.103
– Windows Client Target IP: 192.168.56.105
– Windows DC Target IP: 192.168.56.102

1. Create Your Payload: Lets say that in this scenario we know these systems and their IP’s after we reviewed traffic on the network potentially through a network capture or using a tool like Responder, which we covered in another post. First thing that we can do is build our executable payload with msfvenom:

Once we successfully build out our reverse TCP meterpreter payload “meterz1.exe” we can check the file type to verify that our executable creation and command was indeed successful:

2. Establish Your Listener: Now that we have created our payload we can start msfconsole and use the “/exploit/multi/handler” to stage our listener on our attacker IP. Once the LHOST, LPORT, PAYLOAD and AutoRunScript setting are established we can then type exploit to start our listener. Make sure that you set your multi handler options (we set them to default settings) to the same configured in your msfvenom payload created. Additionally we set the AutoRunScript portion of our multi handler in order to migrate our meterpreter shell to another process to maintain a stronger persistence.

3. Start Your SMB Relay Script: With our malicious executable created and our multi handler started now we can leverage the smbrelayx.py script in another terminal window from our attacker system. In this scenario we know that we want to target the windows client connection (.105) to its domain controller (.102). We need to start our smbrelayx.py script within the same directory as our msfvemom executable created. Below we specify our target host with (-h) and point our script to our payload (-e) for upload upon successful smbrelay attacks that allow writable access to shares.

4. Invoke A Connection Between the Windows Systems: With our script now running let’s navigate to our domain controller system and open a command prompt. Once open type a simple dir command making a connection to the windows client on the domain like so “\192.168.56.105c” and here we can see our connection worked. But when we make a connection from the DC to the “.103” (the attacker IP) for a share our smbrelayx.py running will relay this authentication attempt to login to the “.105” (windows client).

5. Spawn Your Meterpreter Shell: If we switch back to our Attacker instance we should see that the terminal running smbrelayx is attempting to intercept the connection request from the DC (.102) to the attacker IP (.103). During this exchange the script receives the SMB authentication connection from the DC and attempts to authentication against the windows client that we are targeting (.105) with the Administrator account on the CRT domain. Once authenticated the tool begins to request shares on the client and eventually finds a writeable share “ADMIN$” on the windows client and uploads the executable file we created with a generated name and migrate services to maintain persistence with our now spawned meterpreter shell! #profit

SMB Relay Attack Nessus:

As stated before many local networks will have patch management systems, antivirus updates, vulnerability scanners, administrator scripts, etc. will attempt to authenticate to hosts systematically. Often the exchange of credentials being passed between these automated tools or scripts can fall prey to SMB relay attacks. Recently we wanted to test this notion for ourselves with a commercial vulnerability scanner so we leveraged a trial edition of Nessus.

Nessus is commonly deployed in an enterprise environment on a windows server that scans clients for vulnerabilities while leveraging potentially domain or local administrative credentials. We configured the trial of Nessus on our DC server (.102) and set domain administrative credentials for authentication to scan the windows client for vulnerabilities. Before starting our authenticated Nessus scan we set our multi handler, smbrelayx.py and msfvenom payload to the same configuration used in our prior example. Once the multi handler was listening and the smbrelayx script was running, we started our Nessus scan against the windows client. As a result during the scan the smbrelayx script was successful in intercepting the credentials and relayed them over to access the windows client, find a writable share and upload our payload with meterpreter shell access.

How Do I Prevent SMB Relay Attacks and LLMNR, NBNS Spoofing?

The attack vector of performing SMB relay attacks as a MITM is nothing new in the security world, but still absolutely effective across many internal networks. The vulnerability had a major Microsoft Security Bulletin released back in 2008 (MS08-068) . Currently many companies and their local networks lack the proper remediation necessary in order to prevent these types of attacks. Below are several suggestions and potential remediation approaches that could prevent these MITM attacks:

1) Require SMB Signing
2) Disable Broadcast Protocols: LLMNR (Link Local Multicast Name Resolution) and NBNS (NetBios Name Resolution)
3) Prevent WPAD Poisoning with DNS entries
4) Prevent SMB Traffic Outbound
5) Enable EPA (Extended Protection and Authentication)