Top Active Directory Misconfigurations Exploited in the Wild

Why Active Directory Is the Crown Jewel

If you work in enterprise security, you’ve heard this before: compromise Active Directory and you own the network. But let’s actually talk about why that’s true and not just repeat it like a mantra.

Active Directory (AD) is Microsoft’s directory service. It sits at the center of most enterprise Windows environments and handles authentication, authorization, group policy enforcement, and resource access across every Windows machine in the organization. When a user logs in, AD verifies them. When a machine needs to find a printer, AD tells it where to look. When a policy gets pushed to lock down USB ports company-wide, AD does it.

The problem is that AD is complex, it has been around since Windows 2000, and most environments have accumulated years of misconfigurations, legacy settings, and overpermissioned accounts that nobody has touched in years. Attackers know this and they study it. Then, they exploit it systematically.

Active Directory sits at the center of enterprise environments - and at the center of most attacks

Here are the most commonly abused misconfigurations, why they exist, and what you can actually do about them.

---

1. Kerberoasting

What it is:

Kerberos is the authentication protocol AD uses. When a user needs to access a service (like a database or a web application), they request a Ticket Granting Service (TGS) ticket from AD for that service. The ticket is encrypted with the NTLM hash of the service account’s password.

Here’s the thing: any authenticated domain user can request this ticket. And once you have it, you can take it offline and try to crack the password without touching any live system.

Why it works:

Service accounts are often created with weak, human-memorable passwords. They get set up years ago, nobody changes them, and they’re never subject to the same password policies as regular user accounts. Some environments have service accounts with passwords that haven’t changed in five years.

How attackers do it:

# With Impacket (from Linux)
GetUserSPNs.py domain.local/user:password -dc-ip 10.10.10.10 -request

# With Rubeus (from Windows)
Rubeus.exe kerberoast /outfile:hashes.txt

Then crack offline:

hashcat -m 13100 hashes.txt wordlist.txt

How to defend against it:

• Set service account passwords to 25+ random characters
• Use Group Managed Service Accounts (gMSA) - AD manages and rotates the password automatically
• Monitor for TGS requests in Event Log (Event ID 4769) - especially bulk requests from a single source
• Run BloodHound to find which service accounts have SPNs and audit their permissions

---

2. AS-REP Roasting

What it is:

Similar to Kerberoasting, but this one targets accounts that have Kerberos pre-authentication disabled. Normally, when you request a ticket from AD, your client first proves it knows your password (pre-authentication). If pre-auth is disabled, anyone can request an AS-REP for that account and get a blob of data encrypted with the account’s password hash - without authenticating at all.

Why it exists:

Some legacy applications and configurations require pre-authentication to be disabled. It gets set once and forgotten.

How attackers do it:

# Enumerate accounts without pre-auth (no credentials needed)
GetNPUsers.py domain.local/ -usersfile users.txt -dc-ip 10.10.10.10

# Crack the hash
hashcat -m 18200 asrep_hashes.txt wordlist.txt

How to defend:

• Audit all accounts for “Do not require Kerberos preauthentication” (Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true})
• Enable pre-authentication on every account that doesn’t genuinely need it disabled
• Strong passwords on any accounts where you absolutely cannot enable pre-auth

---

3. LLMNR / NBT-NS Poisoning

What it is:

LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) are fallback name resolution protocols. When DNS fails to resolve a name, Windows falls back to broadcasting on the local network asking “does anyone know where HOST-X is?”

An attacker running Responder on the same network segment can respond to these broadcasts and say “yes, I’m HOST-X, connect to me.” The victim’s machine then tries to authenticate, sending an NTLMv2 hash.

Why it still exists:

It is enabled by default. Always has been. Most IT teams never turn it off.

How attackers do it:

# Run Responder on the network
responder -I eth0 -wrf

# Captured hashes appear automatically
# Crack with hashcat
hashcat -m 5600 ntlmv2_hashes.txt wordlist.txt

Or relay the hash directly without cracking:

ntlmrelayx.py -tf targets.txt -smb2support

How to defend:

• Disable LLMNR via Group Policy: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution
• Disable NBT-NS: Network adapter settings > IPv4 Properties > Advanced > WINS > Disable NetBIOS
• Deploy 802.1X network authentication so rogue devices can’t just sit on your network

---

4. Unconstrained Delegation

What it is:

Delegation allows one service to authenticate to another service on behalf of a user. Unconstrained delegation means a server can impersonate any user to any other service in the domain.

If you compromise a server with unconstrained delegation enabled, and you can coerce a Domain Controller to authenticate to that server (via techniques like PrinterBug or PetitPotam), you capture the DC’s Kerberos ticket. From there you own the domain.

How to find it:

# Find computers with unconstrained delegation
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation

How to defend:

• Audit and remove unconstrained delegation from any machine that doesn’t need it
• Mark sensitive accounts (Domain Admins, etc.) as “Account is sensitive and cannot be delegated”
• Use constrained delegation or resource-based constrained delegation instead

---

5. Password in SYSVOL / Group Policy Preferences

What it is:

In older AD environments (pre-2014), administrators could set local administrator passwords through Group Policy Preferences. The passwords were stored in SYSVOL - a network share accessible by every authenticated domain user - encrypted with a key that Microsoft publicly published.

How attackers find it:

# With Metasploit
use post/windows/gather/credentials/gpp

# Manual search
findstr /S /I cpassword \\domain\sysvol\domain\policies\*.xml

How to defend:

• Delete all GPP files containing cpassword values
• Use LAPS (Local Administrator Password Solution) to manage local admin passwords instead - it generates unique, random passwords per machine and stores them in AD

---

Using BloodHound to Find Everything

BloodHound is a tool that maps out Active Directory relationships and visually shows attack paths to high-value targets like Domain Admin. It uses graph theory to answer questions like “what is the shortest path from this unprivileged user to Domain Admin?”

# Collect AD data (run as domain user)
SharpHound.exe --CollectionMethods All

# Import into BloodHound and run pre-built queries:
# - Find all Domain Admins
# - Find shortest paths to Domain Admin
# - Find Kerberoastable accounts with high value targets

The most powerful thing about BloodHound is that defenders should run it just as much as attackers. Find your attack paths before someone else does.

---

Summary Table

Misconfiguration	Risk	Quick Fix
Kerberoasting (weak service account passwords)	High	Use gMSA or long random passwords
AS-REP Roasting	High	Enable Kerberos pre-authentication
LLMNR/NBT-NS enabled	High	Disable via Group Policy
Unconstrained delegation	Critical	Remove, use constrained delegation
Passwords in SYSVOL	Critical	Delete GPP files, deploy LAPS

Active Directory is a rich target and attackers know it deeply. The best defense is understanding your own environment better than they do.