The SMB Relay attack is one of those awesome tactics that really helps penetration testers demonstrate significant risk in a target organization; it is reliable, effective, and almost always works. Even when the organization has good patch management practices, the SMB Relay attack can still get you access to critical assets. Most networks have several automated systems that connect to all the hosts on the network to perform various management tasks. For example, software inventory systems, antivirus updates, nightly backups, software updates and patch management, desktop backups, event log collectors, and other processes will routinely connect to every host on the network, login with administrative credentials and perform some management function.
In some organizations, active defense systems such as Antivirus Rogue host detection will immediately attempt to login to any host that shows up on the network. These systems will typically try long lists of administrative usernames and passwords as they try to gain access to the unknown host that has mysteriously appeared on the network. SMB Relay attacks allow us to grab these authentication attempts and use them to access systems on the network. In a way, SMB Relays are the network version of Pass the Hash attacks Let’s look at how these attacks work.
? NTLM is a challenge/response protocol. The authentication happens something like this: First, the client attempts to login and the server responds with a challenge. In effect the server says, “If you are who you say you are, then encrypt this thing (Challenge X) with your hash.” Next, the client encrypts the challenge and sends back the encrypted challenge response. The server then attempts to decrypt that encrypted challenge response with the user’s password hash. If it decrypts to reveal the challenge that it sent, then the user is authenticated. Here is an illustration of a challenge/response authentication.
With SMB Relay attacks, the attacker inserts himself into the middle of that exchange. The attacker selects the target server he wants to authenticate to and then the attacker waits for someone on the network to authenticate to his machine. This is where rogue host detection, vulnerability scanners, and administrator scripts that automatically authenticate to hosts become a penetration tester’s best friends. When the automated process connects to the attacker, he passes the authentication attempt off to his target (another system on the network, perhaps a server). The target generates a challenge and sends it back to the attacker. The attacker sends the challenge back to the originating scanning system. The scanning system encrypts the hash with the correct password hash and sends it to the attacker. The attacker passes the correctly encrypted response back to his target and successfully authenticates. This process is shown in the next illustration. The BLUE arrows are the original communications and the RED arrows are slightly modified versions of those communications that the attacker is relaying to his target, so that he can gain access to it.
Although this may seem complicated, it is actually very easy to exploit.In this example, the attacker (let’s say he’s at IP address 10.10.12.10) wants to gain access to the server at the IP address 10.10.12.20 (perhaps a juicy file server).There is a nightly software inventory process on the server at 10.10.12.19 that inventories all the hosts on the network.
Scenario
Attacker IP – 10.10.12.10Target IP – 10.10.12.20Nightly Inventory Scanner IP – 10.10.12.19
Metasploit has an SMB Relay Module and it works wonderfully. The attacker at 10.10.12.10 sets up Metasploit as follows:
I’ll use a simple Windows FOR loop to simulate an administrative server scanning the network and doing inventory. On host 10.10.12.19 I run the following command.
When the scanner (10.10.12.19) connects to 10.10.12.10 (our Metasploit listener) the authentication attempt is relayed to the target server (10.10.12.20). The relayed authentication happens like magic and Metasploit automatically uses the authenticated SMB session to launch the meterpreter payload on the target. Notice in the figure below that Metasploit sends an “Access Denied” back to the inventory scanner when it attempted to connect to 10.10.12.10. However, the damage is done and we get a Meterpreter shell on the attacker’s machine running on the target (10.10.12.20).
Today, Metasploit’s SMB Relay only supports NTLMv1, so organizations can protect themselves from this attack by changing the AD policy from this setting (available in secpol.msc) …
To this…
After we make the change to NTLMv2, we try Metasploit again.
Now when we run the exploit, Metasploit gets a “Failed to authenticate” error message. DRAT, our dastardly plan has been foiled by modern security protocols. Metasploit has support for NTLMv2 in other exploits such as http_ntlmrelay, so I imagine this exploit will eventually support NTLMv2.
But, don’t worry. We’ve got you covered. Until then, it is PYTHON TO THE RESCUE! Two weeks ago, I showed you psexec.py in my blog post about using a Python version of psexec.
Because we are using a meterpreter reverse shell, we also have to setup Metasploit so that it is ready to receive the payload connection after it executes on the target. That is what the multi/handler exploit is for, as shown below:
Now, I’ll simulate the scanner by attempting to connect to the C$ of our attacker’s Linux box (10.10.12.10) from the scanner server (10.10.12.19).
Instead of getting back an “Access Denied” like we did from Metasploit, we get back a “System cannot find the path specified” error. I like this error message. I think a system admin might question why his username and password didn’t work on a target before he would question why the path doesn’t exist. The smbrelayx.py script’s message back to the admin seems therefore more subtle than the Metasploit message and less likely to get noticed. Immediately we see the relay occur in the Python script. It authenticates to 10.10.12.20 and launches the meterpreter process as a service using the username and password provided by 10.10.12.19.
The payload is delivered to the target after authenticating over NTLMv2 and meterpreter is launched on the target. To keep our shell, we need to quickly migrate to another more stable process (to help automate that migration, we could use one of the migration scripts available for the meterpreter).
Thank you!
