Your Hashes are mine!!

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.

blog1

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.

blog2.jpg

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.

blog3

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”.

blog15


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

blog52.  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.

blog6

blog7

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.

blog8

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).

blog9

5.  In Empire, we have received an agent.

blog10

Scenario 3:
1.  In another case when victim1 logged in as local administrator accesses a non-existent share we also receive an agent.

blog11

2.  Responder.py responds to the LLMNR query.

blog12

3. Ntlmrelayx captures the hash and relays it against the target.

blog13

9.  Here we go!! another agent in Empire.

blog14

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.

blog16

2.  Setup smbserver using the following command.

smbserver.py <name of the share> <path of the share>

blog17

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.

blog18

blog19

5. Finally, crack the hash using hashcat.

hashcat64.exe -m 5600 hash.txt password_list.txt -o cracked.txt

blog20

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.

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: