Recently I’ve been reading up on so many blog posts from red teamers/researchers over the year that I’ve decide to make my own lab environment to test some of the fun stuff. The aim of this blog series is to consolidate some of tools and techniques (none of my own) tested in a lab environment and very likely used by pentesters.
This post will be mainly focussed on getting a foothold in an internal network of windows systems which is widely used in every organisation. In subsequent posts, I will include some techniques on attacking clients externally.
Gaining a foothold – Part 1
Establishing a foothold into an organisation is probably the most crucial part of an assessment. Because, it showcases what an attacker can do to compromise a system and also use the information obtained to laterally move in the network. We will cover a few scenarios to establish a foothold in an internal network. The scenarios, tools and techniques mentioned here is not an exhaustive list and was never meant to be one. Some might be even be old but still relevant.
On the internal network simulating an insider attack:
Responder.py – LLMNR/NBT-NS/mDNS Poisoner
Author: Laurent Gaffie (https://github.com/lgandx/Responder)
Responder is a LLMNR, NBT-NS and MDNS poisoner. Basically in a typical network if a client system is unable to resolve a name using DNS, it falls back to NBT-NS (NetBIOS Name Service) and LLMNR (Link-Local Multicast Name Resolution). Responder listens for NBT-NS and LLMNR requests and responds to them. The result is that the client system sends its Net-NTLMv1/v2 (a.k.a NTLMv1/v2) hashes to responder which makes Responder a very powerful and yet a stealthy tool. A lot of pentesters claim to use Responder at the very beginning of their pentests.
Its important to note that Net-NTLMv1/v2 hashes are completely different from NTLM hashes. NTLM hashes are stored in the Security Account Manager (SAM) database and in the Domain Controller’s NTDS.dit database. NTLM hashes looks like this:
921988BA001DC8E14A3B108F3FA6CB6D:E19CCF75EE54E06B06A5907AF13CEF42
Net-NTLMv1/v2 hashes are used for network authentication (they are derived from a challenge/response algorithm and are based on the user’s NT hash). Net-NTLMv1/v2 hashes cannot be used for pass-the-hash attacks. However, Net-NTLMv1/v2 hashes can be relayed to another host or used for offline cracking. Net-NTLM hashes look like this:
jamesfernandes::CORP:b8567c8bf08c2dce:313CAF418D44C801164C1DA591FF836E:010100000000000097CB0E20B403D30195D1E4067CA0EDBC000000000200060053004D0042000100160053004D0042002D0054004F004F004C004B00490054000400120073006D0062002E006C006F00630061006C000300280073006500720076006500720032003000300033002E0073006D0062002E006C006F00630061006C000500120073006D0062002E006C006F00630061006C00080030003000000000000000000000000020000047F906F76612AB565F5E389EA27FEBE3CCCBA510859F541A020BDBF5F55090EA0A001000000000000000000000000000000000000900160048005400540050002F0067006F006F0067006C0065000000000000000000
Lets make this theory clearer with an example.
Scenario 1:
A client system (192.168.230.224) is surfing the web and misspells the website http://google instead of http://google.com.
Since DNS resolution fails for http://google, the client system falls back to LLMNR for name query. Our Attacker system (192.168.230.131) responds to the LLMNR request and captures the Net-NTLMv1/v2 hash.
Lets look at it in wireshark to understand it better. After DNS name resolution fails, the client system(192.168.230.224) sends a LLMNR query requesting the A record for name google using its IPv4 and IPv6 address. Also observe our responder system(192.168.230.131) responds to the client system (192.168.230.224) with its own IP address as the A record.
Like I mentioned earlier, we can do two things with hash obtained earlier
- Crack the hash offline using a dictionary.
- Relay the hash to another machine.
Note since MS08-068, we cannot relay hashes to the machine from where we obtained it in the first place. But we can relay hashes to other machines.
Lets attempt to crack the hash offline using hashcat.
Use the following command in hashcat to crack net-ntlm hashes:
hashcat64.exe -m 5600 hash.txt password_list.txt -o cracked.txt
Observe we’ve cracked the password for domain account CORP\james fernandes “P@ssw0rd”.
To relay hashes we will use ntlmrelayx from CoreSecurity’s Impacket. Ntlmrelayx has this cool feature to also execute a command on the machine after successfully relaying a hash and authenticating on the target machine.
Lets look at this in the following example:
Scenario 2:
In a typical corporate network, for convenience sake the Windows administrator creates a single local administrator account for all the machines using Group Policy.
Here is our simulated setup:
- Attacker: 192.168.230.131 (machine running Responder, Ntlmrelayx and Empire).
- Victim1: 192.168.230.223 (machine from where we capture the Net-NTLM hash)
Note: Victim1 is logged in as the local administrator account. - Victim2: 192.168.230.227 (machine to where we relay the Net-NTLM hash)
Note: Victim2 is logged in as a regular domain account.
1. Setup Responder.py without SMB and HTTP server. We will use ntlmrelayx for SMB and HTTP.
python Responder.py -I eth0 -r -d -w
2. Generate a one-liner stage0 launcher using Empire so that when we run a command (powershell) on the victim2 machine(192.168.230.227) we will get an agent in Empire. If your not familiar with Powershell Empire, its a fully functional RAT tool. Kudos to the developers for giving this to the community.
3. Setup ntlmrelayx to relay captured Net-NTLM hashes to machines in the targets.txt file followed by a command. In our case, the targets.txt file contains victim2 machine(192.168.230.227) and the command is the powershell stager generated by Empire.
4. When the victim1 machine (192.168.230.223) logged in as local administrator accesses a non-existent name via the browser like http://google (without the .com), responder responds to the LLMNR request. But this time the net-ntlm hash is captured by ntlmrelayx and relayed to the target victim2 machine (192.168.230.227).
5. In Empire, we have received an agent.
Scenario 3:
1. In another case when victim1 logged in as local administrator accesses a non-existent share we also receive an agent.
2. Responder.py responds to the LLMNR query.
3. Ntlmrelayx captures the hash and relays it against the target.
9. Here we go!! another agent in Empire.
There are many more scenarios where you can use Responder for e.g: tricking users into downloading malicious exe files. This has been posted here . Another known trick is to prompt users to enter their windows credentials which gets captured in clear text. This can be found here.
Since we are already talking so much about capturing Net-NTLMv1/v2 hashes. Lets include another scenario in this post. This one can also be leveraged in an external pentest too.
Microsoft has this function to load remote images using UNC paths in RTF file extensions.
While looking for some research thats already out there, I found Wordsteal by Infogen AL. Wordsteal generates a malicious rtf file pointing to the attacker’s SMB server and also automates the metasploit’s auxilliary/server/capture/smb module to capture Net-NTLMv1/v2 hashes.
However I decided to use Impacket’s smbserver.py script to capture Net-NTLMv1/v2 hashes. So I’ve removed the metasploit piece from the script.
Scenario 4:
1. Generate a malicious RTF file using wordsteal.
2. Setup smbserver using the following command.
smbserver.py <name of the share> <path of the share>
3. Take sometime to dress the rtf file(mine looks lame!). Send it to the victim via email or any other means. When a victim opens the rtf file, we capture their Net-NTLMv1/v2 hash on our smbserver.
5. Finally, crack the hash using hashcat.
hashcat64.exe -m 5600 hash.txt password_list.txt -o cracked.txt
Solution:
To prevent LLMNR/NBNS poisoning which is what Responder mostly relies on, you must disable LLMNR and NBT-NS. You need to disable both because if LLMNR is disabled, it will automatically attempt to use NBT-NS instead.
To prevent Net-NTLMv1/v2 relaying, SMB Signing needs to be enabled on the machine you’re relaying to.
Do note that with the exception of Windows Server OS’s, all Windows operating systems have SMB signing disabled by default.
