Active Directory Penetration Testing 3: BloodHound, Detection, and Case Study
Active Directory Penetration Testing is a controlled, authorized simulation of how an attacker would break into your company’s Active Directory environment.
Think of it like hiring someone to try to break into your house – but instead of picking locks or climbing through windows, they’re trying to steal digital keys, trick users, and find hidden doors inside your network.
What Makes Active Directory Different From Other Systems?
Here’s the thing that keeps me up at night. Most security assessments focus on finding vulnerabilities in individual systems. That’s like checking if your front door has a good lock. Important, yes. But not enough.
Active Directory is different. It’s not just another system – it’s the central nervous system of your entire Windows environment. It controls:
| What It Controls: Why | y It Matters |
|---|---|
| Who can log into what | Every user authentication in your organization flows through Active Directory. |
| Who has access to what | Active Directory manages every permission and privilege |
| How systems trust each other | Every machine’s identity and trust relationship is defined in Active Directory. |
| Where data lives and who can see it | Active Directory enforces every resource’s access control |
When you compromise Active Directory, you’re not just breaking one system. You’re gaining control over everything that uses it for authentication, which in most organizations is everything.
What an Active Directory Penetration Test Actually Answers
When I run an Active Directory assessment, I’m answering these questions:
| Question: What | t I’m Really Checking |
|---|---|
| Can I find valid Active Directory usernames without any credentials? | Yes – often through LinkedIn, email enumeration, or breach databases |
| Can I capture an Active Directory password hash just by listening to network traffic? | Yes – LLMNR poisoning usually works in over 70% of environments |
| Are there Active Directory users storing passwords in their description field? | Surprisingly, yes – in about 30% of environments |
| Can a regular Active Directory user request a Kerberos ticket for a Domain Admin account? | Yes – that’s Kerberoasting, and it works almost everywhere |
| Can I relay someone’s authentication to an Active Directory Domain Controller? | Sometimes – depends on SMB signing configuration. |
| How many unique paths exist from a standard Active Directory user to Domain Admin? | Usually, 5-20 – BloodHound shows me every single one |
| Are there legacy GPP credentials still sitting in SYSVOL? | Often, GPP passwords are still found in meaningful percentages of environments. |
The Three-Layered Value of Active Directory Penetration Testing
1. Technical Validation
This is the obvious layer. We actually run the attacks. We prove they work. We don’t just theorize – we demonstrate.
We crack the password in the description field.
We extract the hash from the Domain Controller.
We show the path from a standard user to Domain Admin.
We document exactly how long each step takes
2. Operational Understanding
This is the layer most organizations miss. We don’t just tell you “Kerberoasting works.” We tell you how an attacker would do it and how you would detect them.
Event 4769 is what you monitor for Kerberoasting.
Event 4662 is what you monitor for DCSync.
LLMNR poisoning leaves no Windows Event ID — you need network monitoring
3. Strategic Improvement
This is the layer that makes the investment worth it. We give you a prioritized roadmap.
What to fix first – highest risk, easiest to exploit
What to fix next – medium risk, moderate effort
What to plan for – longer-term architectural changes
What Active Directory Penetration Testing Is NOT
| This is NOT because | e |
|---|---|
| Just running BloodHound | BloodHound shows paths, but doesn’t validate if they actually work in practice |
| A vulnerability scan | Nessus finds missing patches. Active Directory testing finds design flaws, misconfigurations, and protocol-level issues. |
| Something you do once | Attackers evolve. Your Active Directory should be tested at least annually, plus after major changes. |
| A fully automated process | Tools help, but interpretation, prioritization, and stealth require human judgment. |
| A compliance checkbox | Compliance says, “You tested.” Real security says, “Here’s what you fix and why” |
The Active Directory Attack Lifecycle We Simulate
Here’s the arc of every Active Directory penetration test I run:
| Phase: What | t We Do | Example Finding |
|---|---|---|
| 1. Reconnaissance | Harvest information without touching the network | Employee names from LinkedIn → Active Directory username format |
| 2. Active Network Mapping | Find Domain Controllers, map the Active Directory footprint | DNS SRV records reveal DCs; SMB banner reveals domain name |
| 3. Enumeration | Query Active Directory LDAP with valid credentials | Description fields contain plaintext passwords |
| 4. Initial Access | Get that first set of credentials | LLMNR poisoning → NTLM hash → cracked password |
| 5. Exploitation | Use Active Directory features to escalate | Kerberoasting → service account credentials → Domain Admin |
| 6. Lateral Movement | Move through the Active Directory forest | Pass-the-Hash → admin access → cross-domain trust |
| 7. Reporting | Document everything with precision | Screenshots, proof-of-concept commands, prioritized remediation |
Active Directory Penetration Testing answers one question before the bad guys do:
“If someone got a standard Active Directory domain user account on your network today, how quickly could they reach Domain Admin – and what would you see when they did?”
We simulate the attack. We document every step. We tell you what to fix first. And we teach your blue team what to look for when someone tries it for real.
Because in 2026, it’s not a matter of if someone will target your Active Directory. It’s a matter of when – and whether you’ll know about it before they own everything.
BloodHound Fundamentals
Let me be sincere with you. If you only master one tool for Active Directory penetration testing, make it BloodHound.
Every other tool gives you data. BloodHound gives you paths through Active Directory.
Think about the difference. LDAP enumeration of Active Directory gives you a list of users, groups, and computers. That’s data. Useful, but overwhelming. BloodHound takes that same raw Active Directory information – thousands of users, groups, computers, and permissions – and transforms it into a navigable graph that answers one question better than any other tool:
“From where I am right now in Active Directory, what’s the shortest path to Domain Admin?”
That question is the entire game of Active Directory privilege escalation. BloodHound answers it in seconds.
The Graph Model: Why It Matters for Active Directory
Here’s something I want you to understand about Active Directory. Privilege escalation is inherently a graph traversal problem.
The question “Can this Active Directory user reach Domain Admin?” is equivalent to asking “Is there a path in this graph from node A (my user) to node B (Domain Admin)?”
When an Active Directory environment has thousands of users, groups, computers, and ACL entries, there can be tens of thousands of relationships. Humans are terrible at mentally traversing graphs of that size. We miss paths through Active Directory. We overlook indirect relationships. We don’t see the chain of “User A is in Group B, which can modify Group C, which contains Domain Admin.”
BloodHound was built specifically for this Active Directory problem. It does the graph traversal for you.
The Four Types of Active Directory Data BloodHound Collects
| Collection Category: What | t It Captures in Active Directory: Why | y It Matters |
|---|---|---|
| Group memberships | Who is in what Active Directory group, including nested memberships | Groups are the primary way Active Directory grants privileges |
| ACL relationships | Which Active Directory objects have what permissions on other objects | ACL misconfigurations are the hidden paths to privilege in Active Directory |
| Session data | Which Active Directory users have active or recent sessions on which machines | Sessions let you steal Active Directory credentials from one machine to another. |
| Trust relationships | Active Directory domain and forest trust edges | Trusts let you hop between Active Directory domains |
Together, these create a complete relational model of the Active Directory domain’s identity infrastructure. The same model that an attacker would need to mentally construct manually. BloodHound gives it to you in seconds.
Installation: BloodHound Community Edition (2026)
BloodHound Community Edition (CE) is the current actively maintained version. It has a redesigned API-driven backend, a rebuilt query interface, and now supports Entra ID and Azure attack paths alongside on-prem Active Directory.
Simplest install – Docker Compose:
One command gets you a full BloodHound CE instance curl -L https://ghst.ly/getbhce | docker compose -f - up Access the interface at: http://localhost:8080. Set your admin credentials on the first run
Alternative – direct binary:
Download from the official GitHub releases: https://github.com/SpecterOps/BloodHound/releases
Collecting Active Directory Data: SharpHound
SharpHound is the official BloodHound data collector. It runs on any domain-joined Windows machine with valid Active Directory credentials and produces a ZIP file you import into BloodHound CE.
Basic collection (start here):
Standard full collection — gets you everything from Active Directory .\SharpHound.exe -c All --zipfilename domain_collection.zip
Stealth-optimized collection (use this in monitored Active Directory environments):
The throttle slows down LDAP queries against Active Directory. Jitter randomizes timing. This looks less like a tool and more like normal traffic. .\SharpHound.exe -c All \ --throttle 5000 \ --jitter 25 \ --zipfilename collection.zip
DC-only collection (fastest, lowest noise, but less complete):
Only collects from the Active Directory Domain Controller — fewer queries, less data .\SharpHound.exe -c DCOnly --zipfilename dc_only.zip
Specify a target Active Directory Domain Controller explicitly:
.\SharpHound.exe -c All \ -d corp.example.com \ --domaincontroller 192.168.1.100 \ --zipfilename collection.zip
From Linux with NetExec (no Windows machine needed):
Yes, you can collect BloodHound data entirely from Linux against Active Directory netexec ldap 192.168.1.100 -u jsmith -p 'Password1' \ --bloodhound \ --collection All \ --dns-server 192.168.1.100
Fundamental Analysis Workflow in BloodHound
Once you’ve imported your Active Directory collection into BloodHound CE, work through these steps in order. Don’t skip around.
Step 1 – Run the Foundational Queries
BloodHound CE comes with pre-built queries for Active Directory analysis. Run these first:
| Query: What | t It Tells You About Active Directory |
|---|---|
| “Shortest Paths to Domain Admins from Owned Principals” | Run this immediately after marking compromised Active Directory accounts as Owned — your primary view |
| “Find All Paths from Domain Users to High Value Targets” | Reveals structural Active Directory misconfigurations |
| “Shortest Paths to Unconstrained Delegation Systems” | High-value for TGT theft paths across Active Directory |
| “Find Kerberoastable Users with Most Privileges” | Cross-references Active Directory SPN accounts with privilege levels |
Step 2 – Mark Compromised Active Directory Accounts as Owned
Right-click any node → “Mark as Owned.”
This enables the “Shortest Paths from Owned Principals” query, which becomes your primary working view once you have a foothold in Active Directory. BloodHound will now only show you paths that start from Active Directory accounts you actually control.
Step 3 – Explore Outbound Control for Each Owned Active Directory Account
Click any Owned node → “Outbound Object Control” → “Transitive Object Control.”
This shows you every object in the Active Directory domain your current account can influence — directly or through chains of permissions. You might be surprised how far a seemingly low-privileged Active Directory account can reach.
Step 4 – Use Custom Cipher Queries for Specific Active Directory Risks
BloodHound CE supports direct Cipher queries against the Neo4j backend. This is where the real power lives for Active Directory analysis.
Find all Kerberoastable Active Directory accounts with paths to Domain Admin:
MATCH p=shortestPath( (u:User {hasspn:true})-[*1..]->(g:Group) ) WHERE g.name =~ "(?i)domain admins.*" RETURN p LIMIT 10
Find computers with unconstrained delegation in Active Directory (excluding Domain Controllers):
MATCH (c:Computer {unconstraineddelegation: true}) WHERE NOT c.distinguishedname CONTAINS "OU=Domain Controllers" RETURN c.name, c.distinguishedname
Find all Active Directory users with DCSync rights (replication extended rights):
MATCH p=(u:User)-[:GetChanges|GetChangesAll]->(d:Domain) RETURN u.name, d.name
Find paths between two specific Active Directory accounts:
MATCH p=shortestPath( (u:User {name:"JSMITH@CORP.EXAMPLE.COM"})-[*1..10]-> (t:User {name:"ADMINISTRATOR@CORP.EXAMPLE.COM"}) ) RETURN p
Find accounts with local admin rights on high-value Active Directory servers:
MATCH (u:User)-[:AdminTo]->(c:Computer) WHERE c.name CONTAINS "DC" OR c.name CONTAINS "SQL" OR c.name CONTAINS "BACKUP" RETURN u.name, c.name
Reading BloodHound Edge Types
The edges in a BloodHound graph represent specific Active Directory relationships and permissions. These are the ones you absolutely need to understand.
| Edge: What | t It Means in Active Directory | How to Exploit It |
|---|---|---|
| MemberOf | Direct or transitive Active Directory group membership | Inherit all rights of that Active Directory group |
| AdminTo | Local admin on a computer in Active Directory | Connect and dump LSASS credentials |
| HasSession | An Active Directory user has an active session on a computer | Go to that machine, dump their hash |
| GenericAll | Full control over the Active Directory object | Reset password, add to group, modify ACEs |
| GenericWrite | Write access to non-protected Active Directory attributes | Set malicious SPN, modify logon script |
| WriteDACL | Can modify the Active Directory object’s DACL | Grant yourself GenericAll |
| WriteOwner | Can take ownership of the Active Directory object | Become the owner, then modify DACL |
| ForceChangePassword | Can reset the Active Directory password without knowing the current | Direct account takeover |
| AllExtendedRights | All extended rights on the Active Directory object | Reset password, DCSync (if on domain object) |
| DCSync | Replication rights in Active Directory | secretsdump the entire Active Directory domain |
| CanPSRemote | WinRM access enabled for Active Directory account | Remote PowerShell session |
| AllowedToDelegate | Constrained delegation configured in Active Directory | Kerberos delegation abuse |
| AllowedToAct | Resource-Based Constrained Delegation in Active Directory | RBCD attack |
BloodHound for Blue Teams (Defending Active Directory)
Here’s something I want to emphasize. BloodHound is not just a red team tool for Active Directory attacks. If you’re defending Active Directory, you should run BloodHound against your own Active Directory environment regularly.
Run as a domain user in read-only mode — no special Active Directory privileges required .\SharpHound.exe -c DCOnly --zipfilename quarterly_review.zip
Then import the data and check the built-in blue team queries, especially “Find Shortest Path to Domain Admins.” If that query resolves through unexpected paths — like a regular Active Directory user account having a permission chain to Domain Admin — you have a misconfiguration to fix.
Why regular BloodHound analysis matters for Active Directory defenders:
Attack paths through Active Directory DACL misconfigurations accumulate silently over time. Each new IT change. Each permissions adjustment made “just temporarily.” Each new Active Directory service account added without a full review. Each one adds a potential edge to the graph.
An attacker only needs one path through Active Directory. Quarterly BloodHound runs catch these paths before an attacker does.
Quick Recap: BloodHound for Active Directory
| Question | Answer |
|---|---|
| What does BloodHound do? | Maps Active Directory relationships into a graph and finds shortest paths to high-value targets |
| What Active Directory data does it collect? | Group memberships, ACLs, sessions, trusts |
| How do I collect Active Directory data? | SharpHound on Windows, or NetExec from Linux |
| What’s the first query to run in Active Directory? | “Shortest Paths to Domain Admins from Owned Principals” |
| What’s the most valuable Active Directory edge type? | GenericAll, WriteDACL, and DCSync — these are direct privilege paths |
| Can defenders use BloodHound for Active Directory? | Absolutely — run it quarterly to find misconfigurations before attackers do |
Bottom Line
BloodHound transforms Active Directory enumeration from “I have a list of users and groups” to “I have a map of exactly how to get from my current user to Domain Admin.” Master the graph. Master the edge types. Run the custom Cypher queries against your Active Directory data. BloodHound isn’t just a tool for Active Directory penetration testing – it’s the difference between guessing at Active Directory attack paths and knowing them.
Common Active Directory Enumeration Mistakes
Experience across many Active Directory engagements reveals a consistent set of mistakes that hold practitioners back – particularly those who’ve learned the tools without fully internalizing the methodology. These aren’t basic errors. They’re the subtle missteps that reduce the quality of Active Directory findings, burn operational security, or cause engagement failures.
Let me walk you through the six most common Active Directory enumeration mistakes I see, and how to avoid each one.
Mistake 1: Not Reading the Active Directory Password Policy Before the First Spray
This deserves to be listed first because the consequences are asymmetric. A wrong assumption about Active Directory’s password policy doesn’t just waste time — it can lock out hundreds of domain accounts and turn a productive engagement into a crisis management exercise.
The fix is simple and non-negotiable:
This must be your first command after obtaining any Active Directory credentials, every time netexec smb 192.168.1.100 -u jsmith -p 'Password1' --pass-pol Without Active Directory credentials: enum4linux-ng 192.168.1.100 -P
Document these Active Directory policy values before anything else:
Minimum password length
Password history count
Account lockout threshold ← is most critical
Lockout observation window ← is most critical
Lockout duration
What these values tell you about Active Directory:
| Lockout Threshold | Safe Spray Attempts Strategy | y |
|---|---|---|
| 5 attempts in 30 minutes | 4 | Spray 4 passwords max, wait 30+ minutes |
| 10 attempts in 15 minutes | 9 | Spray 9 passwords max, wait 15+ minutes |
| No lockout policy | Aggressive | You can spray more freely, but still be cautious |
Not knowing your Active Directory lockout policy before spraying is inexcusable. I’ve seen engagements derailed on day one because someone assumed a 10-attempt threshold when it was actually 5.
Mistake 2: Running Full SharpHound Collection Without Throttling in Monitored Active Directory Environments
SharpHound’s default collection behavior against Active Directory generates thousands of LDAP queries in seconds. This is textbook anomalous behavior — every modern MDR service and Microsoft Defender for Identity baseline alert list includes “excessive LDAP query volume from a single source.”
Running SharpHound in this mode against Active Directory in a mature environment is often the fastest way to trigger a SOC response.
The fix is two flags:
Always use throttle and jitter in Active Directory environments with MDI or MDR coverage .\SharpHound.exe -c All --throttle 5000 --jitter 25 --zipfilename collection.zip
For maximum stealth against Active Directory: DCOnly collection to start, expand later .\SharpHound.exe -c DCOnly --throttle 5000 --jitter 25
Alternative approach: Collect via NetExec from a Linux host. The query pattern against Active Directory looks different and may be less correlated with known BloodHound signatures in some detection platforms.
Collect Active Directory data from Linux — different signature profile netexec ldap 192.168.1.100 -u jsmith -p 'Password1' \ --bloodhound --collection All --dns-server 192.168.1.100
Mistake 3: Only Looking at User Objects in Active Directory
User accounts are the obvious target in Active Directory, but some of the most impactful findings hide in objects that most pentesters walk past.
What you’re missing in Active Directory if you only look at users:
| Active Directory Object: What | hat You’re Missing | Why It Matters |
|---|---|---|
| Computer accounts | Can have local admin rights to other computers | Lateral movement paths that don’t require user credentials |
| Unconstrained delegation computers (non-DCs) | Allow TGT theft | When a privileged user authenticates to the machine, their TGT is cached and extractable |
| Trust relationship objects | May have exploitable SID history or weaker authentication | Cross-domain escalation paths |
| Entra Connect server | Often holds credentials of the sync account | Typically has DCSync rights on-premises Active Directory |
Don’t skip computer account enumeration in Active Directory:
Enumerate all Active Directory computer objects netexec ldap 192.168.1.100 -u jsmith -p 'Password1' \ --query "(objectClass=computer)" \ "name,operatingSystem,userAccountControl,msDS-AllowedToDelegateTo" Find Active Directory computers with unconstrained delegation ldapsearch -x -H ldap://192.168.1.100 \ -D "jsmith@corp.example.com" -w 'Password1' \ -b "DC=corp,DC=example,DC=com" \ "(&(objectClass=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))" \ name dNSHostName
Mistake 4: Using BloodHound as a Substitute for Manual Active Directory Enumeration
BloodHound is extraordinary at what it does – graph-based relationship mapping of Active Directory. It is not a substitute for:
| Active Directory Technique: What | t BloodHound Misses |
|---|---|
| Certipy for ADCS misconfiguration enumeration | ESC1 through ESC8 vulnerabilities in Active Directory Certificate Services |
| Manual LDAP queries for description-field passwords | Passwords in description fields aren’t captured in BloodHound’s Active Directory data model |
| SYSVOL inspection for GPP credentials and logon scripts | Legacy Active Directory artifacts that BloodHound doesn’t collect |
| Share enumeration for sensitive files | Embedded credentials in Active Directory file shares |
| LSA Secrets extraction for service account credentials | Service account passwords stored in Active Directory-joined machines |
The right approach: The most thorough Active Directory engagements use BloodHound as the relational backbone while layering other enumeration tools and manual checks on top of it. Neither replaces the other.
Mistake 5: Not Validating Each Step in an Active Directory Attack Chain Before Executing the Next
Attack chains in Active Directory frequently have temporal validity issues:
An Active Directory password might have just been changed.
A session might have ended.
A GPO refresh might have corrected an ACE
Executing a five-step Active Directory attack chain where step three relies on an invalid assumption means steps four and five generate noise for no gain.
Validate every step in your Active Directory attack chain:
Validate every Active Directory credential before building a chain from it netexec smb 192.168.1.100 -u svc_account -p 'Cracked!' --no-brute Validate Active Directory ACE permissions before abusing them Get-DomainObjectAcl -Identity "target_account" -ResolveGUIDs | Where-Object {$_.SecurityIdentifier -eq (Get-DomainUser jsmith).objectsid} Confirm Active Directory session data is current before traveling to a machine (SharpHound session data can be hours old) netexec smb MACHINE01 -u admin -p 'Password1' --sessions
Mistake 6: Ignoring Active Directory Trust Relationships
Forest and domain trusts are frequently the highest-impact finding in multi-domain Active Directory environments, and they’re consistently underexplored.
What you’re missing in Active Directory trusts:
A bidirectional forest trust with SID filtering disabled
A parent-child trust where a misconfigured account in the child domain has rights in the parent
External trusts with weaker authentication requirements
These can make cross-domain Active Directory escalation trivial.
Always enumerate Active Directory trusts as part of initial domain mapping:
Enumerate all Active Directory trusts Get-DomainTrust Get-ForestTrust Check for SID filtering status on external Active Directory trusts Get-DomainTrust | Select-Object TargetName, TrustType, TrustAttributes TrustAttributes: 0x4 = quarantined (SID filtering enabled) Absence of 0x4 on external trust = SID filtering disabled = exploitation path in Active Directory
BloodHound query for cross-domain Active Directory paths:
MATCH p=shortestPath( (u: User)-[*1..]->(g:Group) ) WHERE u.domain <> g.domain RETURN p LIMIT 25
Quick Recap: Active Directory Enumeration Mistakes to Avoid
| Mistake: Why | y It Hurts Your Active Directory Assessment | How to Fix |
|---|---|---|
| Not reading the password policy | Locks out hundreds of Active Directory accounts | Run --pass-pol before any spray |
| Full SharpHound without throttling | Triggers SOC alerts in monitored Active Directory environments | Use --throttle 5000 --jitter 25 |
| Only looking at user objects | Misses computer accounts, delegation, and trust paths in Active Directory | Enumerate all Active Directory object types |
| BloodHound as a substitute | Misses description fields, GPP, shares, and LSA Secrets in Active Directory | Use BloodHound + manual enumeration together |
| Not validating attack chain steps | Wastes time and generates noise in Active Directory | Validate each credential and permission before proceeding |
| Ignoring trust relationships | Misses cross-domain Active Directory escalation paths | Always enumerate trusts and check SID filtering |
Learning the methodology is important, but mastering it requires hands-on practice.
If you’re serious about penetration testing, red teaming, or Active Directory security assessments, try realistic cybersecurity CTF labs that let you practice reconnaissance, enumeration, credential attacks, privilege escalation, and exploitation techniques in a safe environment.
Active Directory enumeration mistakes are the difference between a smooth engagement and a painful one. The password policy check takes 10 seconds. The throttling flags take 5 seconds to type. Looking at computer objects takes one extra query. Validating each step takes a few minutes per chain. Trust enumeration takes 30 seconds.
None of these fixes is difficult. They require discipline. Build them into your Active Directory methodology until they become a habit. Your engagements will be smoother, your findings will be better, and your clients won’t have to explain to their management why hundreds of Active Directory accounts got locked out on day one.
Detection During Early Attack Stages of Active Directory
This section is written for both Active Directory perspectives simultaneously: pentesters need to know what generates alerts in Active Directory to report accurately and plan stealth accordingly; defenders need to know exactly what to monitor in Active Directory and what each signal means.
The best Active Directory penetration test report doesn’t just say “Kerberoasting succeeded” – it says “Kerberoasting succeeded against Active Directory and would have been detectable via Event 4769 with RC4 encryption type, for which no alert was configured on your Active Directory Domain Controllers.”
Reconnaissance and Active Directory Enumeration Detection
| Activity | What to Monitor in Active Directory | Event / Tool | Signal Quality |
|---|---|---|---|
| Nmap / port scan | Network IDS | Suricata/Snort rules | Medium — easily tuned |
| DNS zone transfer attempt | DNS debug logs | Event 6004 | High — almost always malicious |
| LDAP query volume spike | Volume baseline against Active Directory | MDI alert / SIEM | Medium — tuning required |
| SMB share enumeration | File access events in Active Directory | Event 5145 | Low alone, high in aggregate |
| SharpHound collection | LDAP query pattern against Active Directory | MDI behavioral | High — distinctive pattern |
Microsoft Defender for Identity (MDI) ships with pre-built detections for Active Directory attacks:
-
Reconnaissance using Active Directory account enumeration (4768/4769 patterns)
-
Active Directory attributes reconnaissance
-
SMB session enumeration against Active Directory
-
BloodHound-specific collection patterns (distinct LDAP query fingerprint against Active Directory)
MDI should be treated as a reality in any enterprise Active Directory assessment. Its behavioral analytics are significantly harder to evade than signature-based detection.
Password Attack Detection Against Active Directory
Password spraying — Event 4625:
The characteristic pattern is multiple Active Directory accounts failing authentication with the same source IP, within a short window, with only one or two failure attempts per account.
Blue team query — detect spray pattern against Active Directory Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} | Group-Object {$_.Properties[19].Value} | # Group by source IP Where-Object {$_.Count -gt 20} | # More than 20 failures from one IP Select-Object Name, Count
LLMNR poisoning – no native Windows Event ID:
LLMNR poisoning against Active Directory environments is invisible to Windows event logging because it operates below the application layer. Detection requires network-level monitoring:
| Detection Method | What to Look For |
|---|---|
| Zeek/Suricata | Alert on LLMNR responses from sources that aren’t your Active Directory DNS servers |
| NetFlow analysis | Unusual broadcast/multicast traffic patterns in your Active Directory environment |
| Network Access Control | Alert on LLMNR traffic from machines that shouldn’t be generating it |
Important: This detection gap is worth documenting explicitly in Active Directory pentest reports — many organizations don’t realize there’s no native Windows visibility into LLMNR poisoning of Active Directory environments.
Kerberoasting and AS-REP Roasting Detection in Active Directory
Kerberoasting — Event 4769 in Active Directory:
Detect RC4 TGS requests for Active Directory user account SPNs Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} | Where-Object { $_.Properties[5].Value -eq '0x17' -and # EncryptionType: RC4-HMAC $_.Properties[7].Value -eq '0x0' # Status: Success } | Where-Object { Exclude Active Directory computer accounts (they legitimately use RC4 in some scenarios) $_.Properties[2].Value -notmatch '\$$' } | Select-Object TimeCreated, @{N='AccountName'; E={$_.Properties[0].Value}}, @{N='ServiceName'; E={$_.Properties[2].Value}}, @{N='ClientIP'; E={$_.Properties[9].Value}}
Key insight for Active Directory defenders:
RC4 TGS requests for user accounts are the primary Kerberoasting signal. In Active Directory environments where AES has been enforced for service accounts, you’ll see AES tickets – which are still worth alerting on if you observe multiple TGS requests for different Active Directory service accounts from a single source in a short window.
AS-REP Roasting – Event 4768 in Active Directory:
AS-REP Roasting produces Event 4768 with a specific characteristic: the Active Directory account requested has pre-authentication disabled. Establish a baseline of which Active Directory accounts have DONT_REQ_PREAUTH set, then alert on:
-
Any 4768 for those Active Directory accounts from an unexpected source IP
-
Multiple 4768 events from a single source for multiple Active Directory accounts within a short window (username enumeration)
Find all pre-auth-disabled Active Directory accounts for your detection baseline Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties * | Select-Object SamAccountName, DistinguishedName, DoesNotRequirePreAuth | Export-Csv asrep_roastable_accounts.csv
Credential Dumping Detection in Active Directory Environments
| Method | Primary Detection | Event / Tool | Notes |
|---|---|---|---|
| LSASS direct access | Process handle request | Sysmon Event 10 | Very reliable with proper Sysmon config |
| Mimikatz sekurlsa | Handle to lsass.exe from unusual process | Sysmon Event 10 + 4656 | EDR typically catches this in Active Directory environments |
| secretsdump remote | RPC to registry, then NTLM negotiation | Event 4656, 4663 | Less distinctive |
| DCSync | DS-Replication-Get-Changes-All | Event 4662 | Gold standard detection |
| GPP credential access | Share access to SYSVOL | Event 5145 | Low signal on its own |
DCSync detection is exceptionally reliable in Active Directory:
Event 4662 on the Active Directory domain object with the GUID {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} (DS-Replication-Get-Changes-All) from a source that isn’t an Active Directory Domain Controller is one of the clearest possible signals of active compromise. Any environment running Windows auditing at a reasonable level and forwarding to a SIEM should have this alert firing within seconds of a DCSync execution against Active Directory.
Detect DCSync against Active Directory — Event 4662 with specific GUID Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662} | Where-Object { $_.Properties[10].Value -match '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' } | Select-Object TimeCreated, @{N='SubjectAccount'; E={$_.Properties[1].Value}}, @{N='ObjectDN'; E={$_.Properties[6].Value}}, @{N='AccessMask'; E={$_.Properties[10].Value}}
Frequently Asked Questions
What is Active Directory enumeration and why does it matter for penetration testing?
Active Directory enumeration is the systematic querying of the Active Directory LDAP directory using valid credentials to extract structured intelligence: user accounts, group memberships, computer objects, permissions, Service Principal Names, trust relationships, and configuration details.
It matters because any authenticated Active Directory domain user – including the most low-privileged account in the organization – can read most of this data by design. Active Directory was built for accessibility, not minimal disclosure.
Enumeration transforms a single set of Active Directory domain credentials into a complete map of every privilege escalation path in the environment. Skipping thorough Active Directory enumeration is the most common reason pentesters miss high-impact findings.
How does Kerberoasting work against Active Directory and why is it so common?
Kerberoasting exploits a legitimate Active Directory Kerberos feature: any Active Directory domain user can request a TGS service ticket for any SPN-registered service account. The Active Directory Key Distribution Center (KDC) encrypts that ticket using the service account’s NTLM hash and delivers it to the requester. The attacker takes this encrypted Active Directory ticket offline and attempts to crack it – the KDC never knows the ticket was compromised.
It’s common because Active Directory service accounts with SPNs exist in virtually every environment, and many of them have human-chosen passwords that haven’t been rotated in years. The fix – Group Managed Service Accounts (gMSAs) with auto-rotating 120-character passwords – exists in Active Directory but requires deliberate migration work that most organizations haven’t completed.
What’s the difference between Kerberoasting and AS-REP Roasting in Active Directory?
Both are offline credential attacks against Active Directory Kerberos authentication material, but they target different conditions and require different levels of prior access:
| Aspect | Kerberoasting | AS-REP Roasting |
|---|---|---|
| Credentials required | Valid Active Directory domain user account | None (just a valid username) |
| Target condition in Active Directory | SPN registered on the account | Pre-authentication disabled (DONT_REQ_PREAUTH) |
| Ticket type | TGS (Service Ticket) | AS-REP (Authentication Reply) |
| Hash format | $krb5tgs$ | $krb5asrep$ |
| Hashcat mode | 13100 (RC4) or 19700 (AES-256) | 18200 |
| Prevalence in Active Directory | Very high | Moderate |
| Detection Event ID | 4769 | 4768 |
Kerberoasting is more prevalent in Active Directory environments. AS-REP Roasting is more dangerous when applicable because it requires no Active Directory credentials whatsoever.
How does BloodHound help during an Active Directory penetration test?
BloodHound models Active Directory relationships as a graph, making complex privilege escalation paths instantly visible. It collects four Active Directory data categories – group memberships, ACL permissions, user sessions, and trust relationships — and represents them as nodes and edges.
The critical value is path-finding: BloodHound can answer “given this compromised Active Directory account, what is the shortest path to Domain Admin?” in seconds, through Active Directory chains that would take days to trace manually. It’s particularly valuable for identifying non-obvious paths through Active Directory DACL misconfigurations, delegation relationships, and nested group memberships.
What Event IDs should defenders monitor for early-stage Active Directory attacks?
The highest-priority Event IDs for early-stage Active Directory detection are:
| Event ID | What It Detects in Active Directory | Why It Matters |
|---|---|---|
| 4625 | Failed logon | Pattern-match for spraying: many Active Directory accounts, one source, few failures per account |
| 4769 | Kerberos service ticket request | Alert on RC4 encryption type from Active Directory user-account SPNs (Kerberoasting) |
| 4768 | Kerberos TGT request | Alert on multiple failures from one source, and on requests for pre-auth-disabled Active Directory accounts |
| 4662 | Directory object access | DCSync uses the replication GUID against Active Directory — very high signal |
| Sysmon Event 10 | Process access | Critical for detecting LSASS access attempts in Active Directory environments |
Important: LLMNR poisoning has no native Windows Event ID and requires network-level monitoring in Active Directory environments.
Is a low-privileged domain user account sufficient to perform significant Active Directory enumeration?
Yes dramatically so. By default, any authenticated Active Directory domain user can query nearly the full LDAP directory:
All Active Directory user accounts and their attributes (including description fields)
All Active Directory group memberships
All Active Directory computer objects and OS versions
All SPNs (enabling Kerberoasting against Active Directory)
All Active Directory accounts without pre-authentication (enabling AS-REP Roasting)
All Active Directory trust relationships
Most Active Directory ACL entries
The principle of least privilege in Active Directory enumeration access would require significant non-default configuration to enforce. In practice, a single low-privilege Active Directory domain credential is sufficient to run BloodHound, identify Kerberoasting targets, and find most of the high-impact misconfigurations in an Active Directory environment.
Conclusion
Two articles in, and a pattern has emerged: the most impactful findings in Active Directory environments aren’t sophisticated.
A password in a description field. A service account with a three-year-old password. An Active Directory account with pre-authentication disabled for a legacy application nobody thought to audit. SMB signing not enforced on half the network. GPP credentials still sitting in SYSVOL.
These aren’t exotic vulnerabilities – they’re Active Directory configuration debt, accumulated over years of operational decisions made without full consideration of their security implications.
Kerberoasting works against Active Directory because services need to authenticate and administrators don’t always choose strong passwords. AS-REP Roasting works against Active Directory because someone disabled a security feature for a legacy system and never re-enabled it. The credential access techniques work against Active Directory because LSASS protection requires deliberate configuration and most organizations haven’t configured it. BloodHound reveals paths through Active Directory that exist because permissions were added over time without a corresponding process to audit and remove them.
For Active Directory Practitioners
The quality of an Active Directory engagement is determined almost entirely by the thoroughness of enumeration and the patience of analysis. Tools are abundant and well-documented for Active Directory testing.
What separates good Active Directory engagements from great ones is:
Reading the Active Directory password policy before spraying
Checking description fields before running complex exploits against Active Directory
Running BloodHound and actually reading the Active Directory graph rather than just taking screenshots
Documenting Active Directory findings with enough specificity that a sysadmin can fix them the week the report lands
For Active Directory Defenders
Everything in this three-part series is detectable in Active Directory, and most of it is preventable with free tooling and configuration changes that don’t require new budget:
| Action | What It Protects in Active Directory |
|---|---|
| Run BloodHound against your own Active Directory environment | Find paths before attackers do |
| Disable LLMNR via GPO | Remove a primary Active Directory initial access vector |
| Enable Credential Guard | Protect LSASS in Active Directory environments |
| Migrate service accounts to gMSAs | Eliminate Kerberoastable Active Directory accounts |
| Audit SYSVOL for legacy GPP files | Remove ancient Active Directory credentials |
| Enable Sysmon with process-access rule on LSASS | Detect Active Directory credential dumping |
| Configure SIEM to alert on Event 4662 with DCSync GUID | Detect Active Directory domain compromise |
None of these require purchasing new products. All of them would have prevented or immediately detected every technique demonstrated in the case study above.
What’s Next in Active Directory Penetration Testing
The attack lifecycle covered across Parts 1, 2 and 3 — reconnaissance, enumeration, initial access, exploitation, Kerberoasting, AS-REP Roasting, credential access, BloodHound analysis – represents the first complete arc of an Active Directory penetration test: getting in, understanding the Active Directory environment, and accessing sensitive resources.
The next phase of the series covers:
Privilege escalation — Moving from standard Active Directory user to Domain Admin
Lateral movement — Navigating through the Active Directory forest
Post-exploitation persistence — Maintaining access to Active Directory
ADCS abuse — Attacking Active Directory Certificate Services
These are the techniques that turn “significant Active Directory access” into “full Active Directory domain compromise.”
Active Directory is the central nervous system of most enterprise networks. It’s where authentication happens, where permissions live, and where trust is defined. Attackers know this. Defenders know this. The question is who acts on that knowledge first.
The techniques in this series work because Active Directory was built for accessibility, not security. The fixes exist because the industry has learned from decades of Active Directory attacks. The gap between “we know we should” and “we actually did” is where most organizations lose.
Close that gap. Test your Active Directory environment. Find the paths. Fix the problems. And keep testing – because Active Directory changes, attackers adapt, and the only constant is that someone is always trying to find a way in.