SANS Penetration Testing

SANS Penetration Testing

SMB Relay Demystified and NTLMv2 Pwnage with Python

By Mark Baggett

[Editor's Note: In this _excellent_ article, Mark Baggett explains in detail how the very powerful SMBRelay attack works and offers tips for how penetration testers can operationalize around it. And, bet yet, about 2/3rds of the way in, Mark shows how you can use a Python module to perform these attacks in an environment that uses only NTLMv2, a more secure Windows authentication mechanism. Really good stuff! --Ed.]

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 (which Ed Skoudis described briefly in the context of psexec in his Pen Tester's Pledge article). 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.10
Target IP - 10.10.12.20
Nightly 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 athttp://pen-testing.sans.org/blog/2013/03/27/psexec-python-rocks) It is a Python implementation of psexec that is distributed with the IMPACKET modules. The team writing the IMPACKET module for Python is doing some really awesome work. First of all, the modules they have written are awesome. Beyond that, they have created several example programs that demonstrate the power of their Python modules. Best of all, the SMBRELAYX.PY script that comes with IMPACKET supports NTLMv2! Sweetness, thy name is IMPACKET!

Getting the script running will take a little bit of work. You'll need to download the latest version of IMPACKET and fix the module paths to get it up and running. To fix this, I put all of the examples in the same directory as the other modules and then change the import statements to reflect the correct directories. SMBRELAYX needs an executable to run on the remote host after it authenticates. What could be better than the meterpreter? Let's use msfpayload to create a Meterpreter EXE and then setup SMBRELAYX. Smbrelayx.py requires two parameters: —h is the host you are going to attack and —e is the process to launch on the remote host. You just provide those options and sit back and wait for that inventory scanner to connect to your system. Below, I show msfpayload creating the Meterpreter executable, and the invocation of smbrelayx.py:


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).


Ah, the delicious smell of a brand new meterpreter shell. And of course, because it is a Python module, you can incorporate this script into your own automated attack tools. Would you like more information about how you can create your own Python-powered attack tools? I'm sure you do! :) Join me for my brand-new SANS course, SEC573 Python for Penetration tester.

http://www.sans.org/course/python-for-pen-testers

Thank you!

--Mark Baggett

Follow me on twitter: @MarkBaggett

11 Comments

Posted April 26, 2013 at 8:03 PM | Permalink | Reply

Mike Pilkington

Cool stuff. Thanks Mark!

Posted April 27, 2013 at 7:09 AM | Permalink | Reply

Yuhong Bao

The best way to prevent this attack I think is to require SMB signing, though the NTLMv2 switch still should be done anyway because v1 only encrypts your password hash with the strength of 56-bit DES.

Posted April 29, 2013 at 2:20 PM | Permalink | Reply

fin

awesome post Mark. Keep up the good work

Posted May 23, 2013 at 10:15 PM | Permalink | Reply

Daniel

Very informative post. Thanks! Can we run SMBRelay through a meterpreter session?

Imagine I run: run autoroute -s 10.1.13.0/24 and the IP of the meterpreter client is 10.1.13.26. If I set the SRVHOST to listen on this address would that work?

I have tried this an received an error saying that port 445/139 are busy. But if I elevated to SYSTEM, closed these ports and then ran SMBRelay. Would that work? Nobody seems to be able to answer this question.

Posted October 20, 2013 at 1:55 AM | Permalink | Reply

John

I've tried this but I cannot get it to work. Could you please tell me the settings.

Log:

Log on my attack machine:
[*]Server started
[*]Started bind handler
msf exploit (smb_relay) > [-] Error connecting to 192.168.80.138:445 Rex: :ConnectionRefused The connection was refused by the remote host (192.168.80.138:445).
[*]Received 192.168.80.135:1076 \ LMHASH:00 NTHASH: OS:Windows 2002 Service Pack 3 2600 LM:Windows 2002 5.1
[*]Sending Access Denied to 192.168.80.135:1076 \
[*]Received 192.168.80.135:1076 AOUN-BDFF96\Test LMHASH:........................... NTHASH:....................................... OS:Windows 2002 Service Pack3 2600 LM:Windows 2002 5.1
[*]Authenticating to 192.168.80.138 as AOUN-BDFF96\Test
[-]Failed to autenticate as AOUN-BDFF96\Test...
[*]Sending Access Denied to 192.168.80.135.1076 AOUN-BDFF96\Test

Posted October 24, 2013 at 1:04 PM | Permalink | Reply

Mark Baggett

John,
It is difficult to tell exactly what the problem is based on the information you provided. It does appear that you were unable to connect to port 445 on the target you were relaying to. There are also some older versions of windows in play here. You may try setting the "protocol" option to "139/SMB" to see if that works. Also if the targets are speaking NTLMv1 then you can also use the Metasploit SMB Relay module show above. It works great for NTLMv1.

Posted December 09, 2013 at 3:08 PM | Permalink | Reply

Fintch

Hi,

i have this setup win7x64sp1 client on a AD win2008r2 domain full updated with kalix64 has attack machine.

i can use the psexec.py command to have a shell on the DC but using the smbrelayx.py i only get back this messages:

Posted December 10, 2013 at 4:49 PM | Permalink | Reply

Fintch

[*] HTTPD: Received connection from 192.168.246.205, attacking target 192.168.246.207
[*] SMBD: Received connection from 192.168.246.205, attacking target 192.168.246.207
[*] Authenticating against 192.168.246.207 as HACK\Administrator SUCCEED
[*] Requesting shares on 192.168.246.207.....
[!] Error requesting shares on 192.168.246.207, aborting.....
[!] Error performing the installation, cleaning up: SMB SessionError: class: ERRNT, code: STATUS_ACCESS_DENIED(Access is denied.)
[*] Service Installed.. CONNECT!
[*] Opening SVCManager on 192.168.246.207.....
[!] Error performing the uninstallation, cleaning up

Posted September 24, 2014 at 11:42 AM | Permalink | Reply

Kali

DCs require by default SMB signing.

Posted December 21, 2013 at 4:07 AM | Permalink | Reply

vuong chieu

you can send to me script SMBRELAYX.PY and all module python. I don't find it on website. thanks all

Posted September 25, 2014 at 12:24 PM | Permalink | Reply

Mark Baggett

vuong chieu,

I provide some links and talk about the installation on this post:

http://pen-testing.sans.org/blog/pen-testing/2013/05/21/tds-mssql-and-python-oh-my

Mark

Post a Comment






Captcha

* Indicates a required field.