The Smb Relay Attack

The Smb Relay Attack

You're not safe even with your strong passwords....

The most basic knowledge everybody knows, irrespective of whether they are tech savvy or not is “Never use weak passwords!”. This does not need much justification and it does not take a prophet to predict that using weak passwords is a recipe for disaster. When you use a weak password, if an attacker can get your password hash, he can crack it easily and get access to your system. Judging by this, using strong passwords are the no-brainer thing to do when choosing passwords for an account. However, I’m afraid I have some bad news. With SMB relay attack, using strong passwords is really not enough and we are going to see why this is, in a bit.

First, we need to understand what SMB is. SMB stands for Server Message Block. Essentially, it is a protocol that allows a system communicate with a server and other network resources to share and access files, ports etc. Typically, SMB runs over the TCP/IP and uses port 445 to communicate. During this communication, an SMB request is made from the system trying to access a file and an SMB response is made by the server but before the server responds to the request, it has to make an authentication check to see if the SMB request is signed or not. So, what happens if there is no signing? Well, you guessed it! There is no authentication check!! No authentication check means we can perform a man-in-the-middle attack because we can intercept requests without anybody verifying our identity.

That said, remember from the last article on LLMNR Poisoning(See link soksonjr.hashnode.dev/llmnr-poisoning), I explained how you can get a user’s password hash and how you can crack it but what if you can’t crack the hash because the password is strong? This is where SMB relay comes into play. You don’t need to crack the hash; you can simply relay it to another user’s machine, and you can get on that user’s machine. This way, you have moved laterally from one user’s machine to another user’s machine in the network.

For this attack to work though, two conditions must be met:

  1. SMB signing must be disabled on the target: Without SMB signing, there is no need to check for authentication which makes it possible for us to intercept packets between the requesting system and the responding system. This attack also works if SMB signing is enabled but NOT required.

  2. The user whose credentials we are relaying has to be an admin on the system we are relaying to. What this means is that if we have user A’s password hash, and User A is an admin on another system with user B. We can intercept traffic on that system and use user A’s hash to gain control of user B’s system. To verify if there is SMB signing enabled on the target, we can run a Nessus scan or simply just use Nmap. We can run the following Nmap scan with syntax nmap --script=smb2-security-mode.nse -p445 192.168.230.0/24. This sweeps across the entire network and tells us where SMB signing is enabled and required and where it is not. As such, we can identify our point of attack.

image.png

With this out of the way, the most important takeaway is that domain admins should never be logged in on other user’s systems because if User B is a domain admin, you have basically hacked the entire network once you get domain admin control.

Now, how do we actually perform this attack? Just like we did in the LLMNR Poisoning attack, we would also need to use responder (remember we are intercepting traffic) except that this time, we are not actually responding to the traffic like LLMNR Poisoning, instead we are simply listening. To demonstrate this attack, we will use a Kali machine (for the attack), two windows systems (we already have the hash of one of them from the last attack). Hence the goal here is to use the hash we already have to pivot into the second system using SMB relay.

So, the first thing we want to do is to open responder’s configuration file and turn off HTTP and SMB. To do this, run the command gedit /etc/responder/Responder.conf and edit it as shown below.

image.png

Doing this ensures we do not respond back to the traffic we intercept. Then we run responder exactly as we did in the last attack. Syntax is responder -I eth0 -dwv

image.png

The next thing we want to do is to use another impacket tool called “ntlmrelayx”. This tool takes the relay and passes it into a target file (target.txt which contains the ip address of the target machine i.e. the machine we are trying to pivot to). This relay basically takes the hash of the first machine we pawned and relays it to the other machine for authentication. The syntax for this is ntlmrelayx -tf target.txt -smb2support where -tf indicates target file.

In a real world scenario, all we would have to do is wait for a user to access the wrong network drive, create a DNS problem and our responder can intercept that traffic while our relay relays the packet to the other user’s machine but we can speed this up here exactly as we did previously. We load the wrong drive (our attacker IP) and get an access denied error:

image.png

But fret not because….

image.png

Just like that, we have the hash to the second machine and a bunch of other hashes which we could take offline and crack. Mission accomplished.

giphy.gif

We could actually take this up a notch by gaining an interactive shell in the other machine using this syntax “ntlmrelayx -tf hash.txt -smb2support -i”. The “-i” stands for interactive which creates the interactive shell for us.

image.png

Notice that line that says “Started interactive SMB client shell via TCP on 127.0.0.1:11000". All we have to do now is navigate to another terminal and run netcat to connect to that port and get a shell with the syntax nc 127.0.0.1 11000 .

image.png

Now we have our shell in the other machine and we can type “help” to get a list of commands we can work with in the shell. Something like :

image.png

To mitigate this attack, the obvious routine is to enable message signing on all devices. This would stop the attack even though it could cause some performance losses. Other mitigation techniques include disabling NTLM authentication on the network and account tiering. It is important for domain admins to only login to servers only when absolutely necessary.

Finally, SMB relay attacks are effective for moving laterally across networks and can be devastating if domain admins are lying around too casually. Understanding this technique as an attacker is going to give you an edge during pentest assessments. Before going into those complicated attacks, LLMNR poisoning and SMB relay attacks represent a good starting point. Never ignore them.