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.


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:


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


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: ./ -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:


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:


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.

Active Directory & Group Policy Privilege Escalation Vulnerability

So you’ve had a successful phishing trip and obtained a shell on a target machine that is joined up a Windows domain. Obviously, the goal is escalate privileges and pivot across the network…which is easier said than done.  This is just one technique (of many) to consider employing on your travels.

We can see below that the target computer’ s domain controller is CN-DC04.


We should now map a drive to the sysvol share on the DC.


We are ultimately trying to find groups.xml, which can be done by using the command below:


Once found, we want to identify the one with the most recent date.


Once we’ve found the file we want, we need to enter the below command: Type groups.xml

Inside this file, if we’re lucky, we’ll be able to determine the name of a local administrator account (redacted in the picture below) and also an encrypted password (in the red box, but also redacted).


Using a tool like gpp-decrypt in Kali Linux, we can easily determine the password.


In a nutshell, organizations should not use Group Policy Preferences to manage local administrator passwords for domain computers.  Instead they should use something like Microsoft LAPS, which is significantly more secure. In addition, Microsoft LAPS will ensure that all of the local administrator passwords are changed on a regular basis AND also randomized on each domain joined machine.  Those credentials are then stored in Active Directory.

Cracking The Name of a Hidden SSID

The process outlined below can be used for obtaining the name of a wireless network that is “hiding” it’s SSID.

We can see on my Windows box, that there is a hidden wireless network in range:


Within our Kali Linux VM, we type iwconfig to obtain the interface name of our wireless card. For any of this to work, you’ll need a compatible Wifi adapter (not covered in this post).


Running the following command will list all of the available wireless networks within range: airodump-ng wlan0

We can easily determine that the hidden wireless network’s BSSID is: E0:1C:41:C9:2D:57 and that it’s broadcasting on channel 1.  We need both pieces of information for the next command.


We can now focus solely on the target BSSID on channel 1 by running the command: airodump-ng wlan0 -c 1 –bssid E0:1C:41:C9:2D:57

If there are any connected clients to the hidden wireless network, this will tell us their network card’s MAC address, which can be seen below.


With this information, we now run the next command: aireplay-ng -0 5 -a E0:1C:41:C9:2D:57 -c 1C:5C:F2:17:C0:BB


The above command, when run, will forcibly disconnect/boot the connected user off the BSSID.  When this happens, a device will automatically attempt to reconnect to the wireless network.  Upon reconnection, we should be able to glean the name of the hidden wireless network (ESSID).


Cracking WPA2 Personal PSKs

Below is the process I use for testing the strength of a wireless network’s password (WPA2 Personal in this example). This guide is intended for someone who already has a working knowledge of Kali Linux and an external WIFI adapter that is capable of operating in monitor mode and also capable of packet injection.

With my WIFI adapter connected, we can see that it’s listed as wlan0.


We type airmon-ng to make sure our adapter is listed in the output.  If not, resolve that issue before proceeding.


We gathered the name of the wireless interface from the first step, so we can now type the below command.  Notice the the interface name has now changed to wlan0mon.  Make note of what it changes to, as it it will be needed later.


Ifconfig confirms the interface name change as mentioned above.


The below command will list all of the wireless networks in the vicinity of the wireless adapter.


Below is the list of available wireless networks.  In this example, we are targeting the wireless network named “Nick’s iPhone”.  We need to make note the the BSSID and the channel.


We copy out the BSSID so that we don’t have to type it in manually.


To monitor only the target network (Nick’s iPhone in this example), issue the below command:


We can see that there is a single device connected (listed under station).


From here, we need to open a new terminal and issue the below command.  The command will send two “deauth” packets to the device/station connected to the wireless network named Nick’s iPhone.  When this happens, the device will be disconnected and will typically try to automatically reconnect.  When the device reconnected, we should (hopefully) capture the WPA2 4-way handshake.


In the top right hand side of the original terminal window we should see “WPA handshake” when the device has successfully reconnected. There will also be capture files on the desktop as well.


Issue the below command.  Note: When using wpaclean, you must list the name of the OUTPUT file first.  This is confusing.  The name can be anything, but the output file comes first.


As we are using hashcat to brute force the PSK, we need to convert the capture files into a format that is usable by hashcat.


A continuation of the above screen shot:


Below is the hashcat command needed to attempt to brute force the PSK against your favorite wordlists.  As we can see below, the password was found in the wordlist and the WIFI password for the target is: wireless123.


Capturing And Cracking NTLMv2 Hashes On The LAN

Target Name: John Doe
Target box: (domain joined)
Attack/facilitator box: (Kali Linux)
Wireshark box: (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 \\ (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.


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.


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.


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


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.


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


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


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