A compromised identity can become a domain-control problem before a response team has finished triaging the initial access alert. In 2026 incident data, attackers reached the Active Directory server in a median of 3.4 hours, while identity-related initial access dominated the reported cases, with brute force at 15.6% and exploitation at 16%. (LastPass incident data)
That pace changes the purpose of an Active Directory penetration test. The engagement isn't a collection of dramatic commands against a Domain Controller. It's a diagnostic exercise that verifies whether a low-privilege foothold can become privileged access, whether the SOC can see each transition, and whether the customer receives evidence an assessor can use.
Table of Contents
- Why Active Directory Is the New Center of Gravity for Attackers
- The Active Directory Attack Surface in Modern Environments
- Recon and Enumeration That Sets Up Every AD Attack
- Credential Harvesting Through Kerberoasting and AS-REP Roasting
- Lateral Movement, Privilege Escalation, and Domain Compromise
- Manual, Automated, and AI-Driven Pentest Workflows Compared
- Evidence Collection and Compliance-Mapped Reporting for MSSPs
- Defender Playbook for Detection and Mitigation
Why Active Directory Is the New Center of Gravity for Attackers
Active Directory sits at the intersection of authentication, authorization, policy, and trust. A successful attack against the directory can expose far more than one workstation because the directory governs who can access systems, which groups carry privilege, how policies reach endpoints, and how on-premises identities connect to cloud services.
The risk is measurable. A major 2023 survey found that 50% of organizations had experienced an Active Directory attack in the prior 1–2 years, more than 40% said the attack succeeded, and penetration testers exploited AD exposures 82% of the time. 86% planned to increase investment in AD protection, which shows how organizations already viewed directory compromise as a probable, high-impact event rather than a specialist scenario. (Semperis Active Directory exploitation survey)
Microsoft's historical identity telemetry reinforces the scale of the pressure. Azure Active Directory blocked more than 25.6 billion attempted account hijacks by brute-forcing stolen passwords between January and December 2021. Microsoft also reported that about 0.5% of enterprise accounts on its system were compromised each month, or roughly 50 out of every 10,000 users in a hypothetical organization. (Microsoft Cyber Signals PDF)
Why identity beats the perimeter
Traditional perimeter testing asks whether an exposed service can be exploited. Active Directory testing asks whether legitimate identity relationships can be chained into control. Kerberos tickets, delegated rights, nested groups, Group Policy permissions, certificate templates, and synchronization paths often give an attacker a quieter route than a software exploit.
That distinction matters for MSSPs. A meaningful report should pair each offensive action with the evidence a defender should have collected, the control that should have blocked it, and the business consequence of leaving the path open.
Practical rule: Treat every AD technique as a detection validation exercise. If the tester can reach a privileged object but the SOC can't reconstruct how, the customer has two findings, not one.
The rest of the assessment should therefore answer three questions: what access was available, what path converted it into impact, and which logs or controls failed to interrupt the chain. That framing turns attacking Active Directory into a risk-reduction deliverable instead of a theatrical break-in.
The Active Directory Attack Surface in Modern Environments
Active Directory is best understood as an identity plane, not just a database hosted on Domain Controllers. Authentication, authorization, Group Policy, certificate enrollment, machine trust, and administrative delegation converge in one logical fabric. A weakness in one layer can become an advantage in another.
MSSPs commonly encounter three operating models:
- Legacy on-premises forests: Domain Controllers, LDAP, Kerberos, SMB, RPC, file shares, service accounts, and GPOs form the primary trust boundary.
- Hybrid identity estates: On-premises AD synchronizes identities to Entra ID through Entra Connect, creating dependencies around synchronization accounts, privileged groups, and cloud-linked authentication.
- Cloud-first tenants with an AD anchor: Entra ID carries much of the application access, but legacy AD can still control privileged groups, workstation administration, or authentication flows.
Reconnaissance differs from ordinary network discovery. Port scans can identify reachable services, but authenticated directory queries reveal relationships. Once a valid foothold exists, the tester can examine users, groups, computers, organizational units, trusts, SPNs, ACLs, policy links, certificate templates, application registrations, and managed identities.
Prioritize the surface by deployment model
On-premises testing usually produces the highest yield from SPN and service-account review, privileged group analysis, delegation checks, and GPO permission inspection. Hybrid testing adds synchronization paths, cloud-connected administrators, and the question of whether a compromise in one plane grants authority in the other. Cloud-first testing shifts attention toward application registrations, managed identities, conditional access, and the remaining AD dependencies.
A useful attack surface mapping workflow helps organize those relationships before exploitation begins. The point isn't to collect every object indiscriminately. It's to identify which identities can reach Tier Zero assets, which permissions are excessive, and which trust relationships create an unexpected bridge.
The current surface also includes AD Certificate Services. Recent coverage found the weakest security scores in AD infrastructure and ADCS, while a separate 2025 survey reported 88% of enterprise hybrid AD environments had critical vulnerabilities and only 17% effectively monitored sensitive AD changes. (Purple Knight hybrid AD and Entra ID report)
Recon and Enumeration That Sets Up Every AD Attack
Strong AD engagements begin by defining what the tester can prove. External work identifies leaked credentials, exposed remote access services, and public infrastructure. Internal work establishes what a foothold can query, authenticate to, modify, or impersonate. Capture collection scope and authorization before gathering data, then preserve timestamps, source hosts, and relevant event records.
Start with identity and topology, not ticket requests or privilege escalation. Enumerate users, groups, computers, organizational units, trusts, sessions, local administrators, delegation settings, and policy objects. LDAP supplies the directory view. Kerberos, SMB, and RPC add authentication and host relationships that a port scan cannot explain.
SPN enumeration identifies service accounts that may be exposed to Kerberoasting. ACL analysis should examine GenericAll, WriteDacl, WriteOwner, AddMember, and related rights on high-value users and groups. Validate each relationship in the approved test environment. The practical question is whether the current principal can reach a Domain Admin or another Tier Zero asset, and whether the path is documented well enough for remediation and retesting.
Tool selection should follow the question
BloodHound and SharpHound support graph-based collection and attack-path analysis. CrackMapExec helps with authenticated sweeps across Windows hosts and shares. Certipy exposes ADCS templates and certificate enrollment paths. Impacket supports protocol-level validation when controlled authentication or replication checks are in scope. Tool output is evidence, not a finding, until the relevant permission or access path is verified.
Skipping enumeration remains a frequent engagement failure. A host list hides the permission relationships that determine impact. The 2023 AD exploitation survey reported an 82% penetration-testing exploitation rate for exposed AD conditions, reinforcing the value of identifying and validating those paths before testing escalation. (Semperis survey on AD exposure exploitation)
| Technique | Primary Tool | Output / Attack Primitive |
|---|---|---|
| LDAP identity discovery | BloodHound, SharpHound | Users, groups, computers, trusts, and sessions |
| Authenticated host sweep | CrackMapExec | Reachable systems, shares, authentication behavior |
| SPN enumeration | BloodHound, LDAP tooling | Service accounts and Kerberoasting candidates |
| ACL analysis | BloodHound | GenericAll, WriteDacl, AddMember, and privilege paths |
| ADCS review | Certipy | Certificate templates, enrollment rights, escalation paths |
| External footprinting | Recon tooling | Leaked credentials, exposed remote access, public assets |
Deliver an attack-path register rather than a raw export. Record the starting identity, every permission edge, the target asset, validation evidence, expected defender telemetry, and the related control or compliance requirement. That format lets an MSSP sell the pentest as a risk-reduction deliverable, with findings that support remediation, detection tuning, and a repeatable retest.
Credential Harvesting Through Kerberoasting and AS-REP Roasting
Think of a Kerberos service ticket as a locked vault. A normal authenticated domain user can request a ticket for an account with a Service Principal Name, or SPN. The ticket contains encrypted material protected by a key derived from the service account password, allowing the tester to extract it and attempt password recovery offline without continued interaction with the service or Domain Controller. (Kerberoasting technical paper)
The engagement flow is straightforward:
- Enumerate SPNs and identify service accounts.
- Request the relevant TGS tickets.
- Extract the encrypted ticket material.
- Perform offline password analysis in the approved test environment.
- Validate whether recovered credentials provide additional access.
RC4, represented by encryption type 0x17, is a useful detection anchor. A service account with a long-lived password and broad privilege is especially dangerous because the attacker doesn't need to exploit the service itself. The recovered identity can provide lateral movement or escalation through existing permissions. CrowdStrike describes the same core behavior, an authenticated user requests a service ticket, extracts the encrypted portion, and cracks it offline. (CrowdStrike Kerberoasting overview)
AS-REP roasting changes the starting condition
AS-REP Roasting targets accounts configured without Kerberos preauthentication. Those accounts can return crackable AS-REP material before the usual preauthentication exchange, making them a valuable discovery target. Some testing paths can use such an account without first controlling a normal domain account, depending on the configuration. (Vaadata Active Directory pentesting methodology)
Defenders should monitor Windows event 4769 for unusual service-ticket volume, repeated requests from one user, and RC4 use. Mitigation includes enforcing service-account passwords of 25 or more characters, preferring AES ticket encryption, removing unnecessary legacy SPNs, and enabling Kerberos preauthentication wherever operationally possible. The password-length and encryption recommendations are practical hardening targets for an assessment, but the report should document the customer's compatibility constraints rather than treating legacy dependencies as an afterthought.
The following video provides a visual explanation of the two ticket-abuse paths:
Lateral Movement, Privilege Escalation, and Domain Compromise
A single workstation becomes dangerous when it holds privileged sessions, reusable hashes, or permissions that reach a critical group. Pass-the-Hash reuses an NT hash for NTLM authentication, while Over-Pass-the-Hash converts hash material into Kerberos-oriented access. In an authorized test, the objective isn't to collect credentials indiscriminately. It's to prove whether workstation placement and administrator logon habits create a path to higher privilege.
DCSync represents a more direct domain-level transition. With the necessary replication rights, an attacker can impersonate a Domain Controller and request password material through the directory replication process. The technique targets the legitimate replication pathway, so the attacker doesn't need interactive access to the underlying server to retrieve domain secrets. (Domain replication abuse study)
GPO and ADCS turn permissions into control
GPO abuse is powerful because write access can push policy changes to every user or computer affected by the object. A tester may validate permissions on the GPO ACL, its SYSVOL files, link targets, WMI filters, security filtering, scripts, scheduled tasks, preference items, or policy files. (GPO abuse detection guidance)
ADCS requires a separate workstream. Misconfigured templates covered by ESC1 through ESC16 can expose certificate-based impersonation and privilege escalation paths. The exact outcome depends on enrollment permissions, template settings, subject or alternative-name control, manager approval, and the certificate's authentication use. Certipy is valuable here because it turns an opaque certificate environment into an inspectable set of templates and principals.
| ESC ID | Misconfiguration | Escalation Outcome | Hardening Control |
|---|---|---|---|
| ESC1 | Enrollee controls subject identity on an authentication template | Request a certificate for another identity | Restrict enrollment and subject-name control |
| ESC2 | Broad use of a template with an overly permissive application policy | Obtain a certificate usable beyond its intended purpose | Limit application policies |
| ESC3 | Enrollment agent rights are broadly assigned | Request certificates on behalf of other users | Constrain enrollment-agent permissions |
| ESC4 | Write access permits template modification | Alter a template into an authentication path | Protect template ACLs and audit changes |
| ESC5 | Weak control over PKI-related objects | Modify certificate infrastructure relationships | Delegate PKI administration tightly |
| ESC6 | EDITF_ATTRIBUTESUBJECTALTNAME2 is enabled | Inject an alternate identity into a request | Remove the flag unless explicitly required |
| ESC7 | CA administrative rights are excessive | Approve or manipulate certificate issuance | Separate CA administration from enrollment |
| ESC8 | Web enrollment allows relay or weak transport protection | Relay authentication to request a certificate | Require secure transport and protect enrollment endpoints |
Testers should map evidence to event 4662 for replication activity, events 5136 and 5137 for directory and policy-object changes, and certificate enrollment auditing on the CA server. A focused internal network penetration testing methodology keeps those validations tied to scope, safety, and reproducibility.
Manual, Automated, and AI-Driven Pentest Workflows Compared
The right workflow depends on what the customer needs to learn. Manual testing produces the richest operator judgment, automated scanning provides consistent breadth, and AI-assisted testing can help chain and verify findings when the underlying collection is reliable.
Manual engagements use operator-driven BloodHound queries, CrackMapExec sweeps, and Impacket tooling. They're strongest when permissions interact in an unusual way, when business context changes the risk, or when a tester must adapt safely around fragile production systems. The trade-off is capacity. A manual assessment can consume 40–80 hours per domain, so MSSPs must price senior time around the highest-value questions rather than spend the engagement on repetitive collection.
Automated tools such as PingCastle, BloodHound, and PlumHound cover large portions of the environment quickly and create useful visualizations. Their weakness is triage. A broad scan can surface thousands of findings, many of which require validation before they belong in a customer report.
AI-assisted platforms place an agent over similar enumeration primitives. The differentiator isn't the label. It's whether the system can select a path, verify exploitability, preserve evidence, and explain why the path matters. A useful benchmark is a 95% verification rate and a sub-four-hour delivery target, but those figures should be treated as platform-specific benchmarks, not universal industry performance claims. The relevant AI penetration testing workflow is the one that makes verification auditable.
| Dimension | Manual | Automated | AI-Assisted |
|---|---|---|---|
| Time to first finding | Depends on operator and access | Usually fast for known checks | Fast when collection is available |
| Evidence quality | Deep and contextual | Consistent but often raw | Strong if verification is preserved |
| False-positive rate | Low after expert validation | Can be high without triage | Depends on verification logic |
| Compliance mapping depth | High but labor-intensive | Often shallow | Potentially repeatable and structured |
| Best use | Creative chains and sensitive validation | Baseline coverage | Chaining, verification, and reporting support |
AI doesn't replace an experienced operator when scope, safety, or business context is ambiguous. It earns its place when it reduces repetitive work without weakening the evidence standard.
Evidence Collection and Compliance-Mapped Reporting for MSSPs
A technically correct exploit can still produce a weak deliverable if the customer can't reproduce it or show an assessor what happened. For MSSPs, evidence quality is the commercial product. The report should prove the path, establish the timeline, explain the affected control, and give the customer a defensible remediation decision.
Each finding should carry a consistent evidence package:
- Command and output: Capture the relevant tool output and a screenshot that shows the action in context.
- Normalized artifact: Preserve a normalized hash of captured TGS material or DCSync output without exposing unnecessary secrets.
- Event timeline: Tie the action to Domain Controller event IDs such as 4769, 4624, 4662, and 4738.
- Reproduction record: List the operator account, source host, target object, tool version, timestamp, and authorization boundary.
- Impact statement: Explain what the identity could reach and what it could change, not merely which command ran.
Build the report for two audiences
The executive summary should state the dwell-time risk, the shortest path to privileged access, and the remediation priority. The technical narrative should then document assumptions, collection, exploitation, validation, and cleanup. An evidence appendix gives engineers the material they need, while a compliance crosswalk lets assessors connect findings to control families.
For teams improving centralized visibility before an engagement, Fluxtail's AI query guide for centralized log management offers useful context on making identity events easier to search and correlate.
| Finding | HIPAA | SOC 2 | PCI-DSS | CMMC | ISO 27001 | GLBA | GDPR |
|---|---|---|---|---|---|---|---|
| Weak service-account credentials | §164.308 | CC6.1 | 8.2 | AC.L2-3.1.5 | A.8.2 | Safeguards Rule | Article 32 |
| Excessive AD privileges | §164.308 | CC6.1, CC6.6 | 8.2 | AC.L2-3.1.5 | A.8.2 | Safeguards Rule | Article 32 |
| Unmonitored directory changes | §164.308 | CC6.6 | 10.5 | AC.L2-3.1.5 | A.8.2 | Safeguards Rule | Article 32 |
| DCSync-capable replication rights | §164.308 | CC6.1, CC6.6 | 8.2, 10.5 | AC.L2-3.1.5 | A.8.2 | Safeguards Rule | Article 32 |
| ADCS template abuse | §164.308 | CC6.1, CC6.6 | 8.2, 10.5 | AC.L2-3.1.5 | A.8.2 | Safeguards Rule | Article 32 |
The exact applicability depends on the customer's scope and obligations. The crosswalk should therefore support, not replace, a compliance professional's interpretation.
Defender Playbook for Detection and Mitigation
The most useful remediation plan pairs every demonstrated path with one signal and one control. A SOC should be able to answer whether the event occurred, which identity initiated it, what object changed, and whether the action was authorized.
Start with the ticket and replication signals. Monitor event 4769 for unusual service-ticket requests and RC4 encryption type 0x17. Review event 4624 type 3 followed by event 4662 activity on the Domain object for possible replication abuse. Track event 4738 for account changes and event 4742 for computer-account modifications. GPO and ADCS changes need object-level auditing, with certificate enrollment auditing enabled on the CA.
Prioritize the controls that break the path
- Kerberos hardening: Prefer AES ticket encryption, remove unnecessary legacy SPNs, and deploy a canary SPN that alerts on suspicious ticket requests.
- Service-account protection: Rotate passwords longer than 25 characters, eliminate stale accounts, and reduce service-account privileges.
- Replication control: Restrict replication-related rights to authorized Domain Controllers and administrative principals. Alert on unusual directory replication requests.
- Tier Zero isolation: Separate Domain Controllers and other critical identity assets from ordinary workstation administration. Use PAW workstations for privileged operations.
- ACL cleanup: Review BloodHound shortest paths to Domain Admin and remove unnecessary GenericAll, WriteDacl, WriteOwner, and group-membership rights.
- Protocol protection: Enable LDAP signing and channel binding where supported, and reduce unnecessary NTLM exposure.
- Policy and certificate governance: Protect GPO and SYSVOL write permissions, review certificate templates, and audit enrollment and template modification.
Turn the report into a 30/60/90-day plan
During the first 30 days, contain the shortest privileged paths, disable unsafe preauthentication exceptions, protect exposed accounts, and confirm that the required events reach the SIEM. By 60 days, complete service-account rotation, GPO and ADCS permission cleanup, PAW deployment for critical administrators, and replication-rights review. By 90 days, retest the original attack paths, validate alert fidelity, measure whether evidence is complete, and update the compliance crosswalk.
Operational test: A mitigation isn't complete because a setting changed. It's complete when a controlled retest fails safely and the SOC can explain why.
ThreatExploit AI helps MSSPs automate reconnaissance, exploitation, verification, evidence collection, and compliance-mapped reporting across internal networks, cloud infrastructure, and web applications. Use ThreatExploit AI to turn Active Directory testing into repeatable, evidence-backed risk reduction that your team can deliver at scale.