2 November 2026 · 10 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
Active Directory penetration testing: scope, the control gaps we find and the remediation order that matters
Nearly every serious intrusion in a Windows-based enterprise ends up in Active Directory, because whoever controls the directory controls every account, server and policy that depends on it. This guide explains what an Active Directory penetration test covers, from on-premises domains to Entra ID and hybrid identity, which control gaps recur, how an assumed-breach engagement runs, and which fixes to make first.
What Active Directory penetration testing is, and why identity is the target
Active Directory penetration testing is a manual, authorized assessment of the identity infrastructure most enterprises still run on: on-premises Active Directory domains and forests, the trusts between them, Group Policy, Active Directory Certificate Services (AD CS), the privileged accounts and groups that administer it all, and, in nearly every organization today, the Entra ID tenant and the synchronization layer that joins cloud and on-premises identity into one hybrid system. The test starts from the position of an attacker who already has a foothold (a standard user account or a workstation) and establishes how far that position can be expanded, which privileged paths exist, and which controls would have stopped the progression.
Identity is the target because it is the control plane. Ransomware operators, espionage groups and insiders spend most of an intrusion not on breaking software but on collecting and abusing credentials and permissions until they hold domain or tenant administrator rights, at which point backups, endpoint protection, email and every business application are theirs to disable. In September 2024 the Australian Signals Directorate, with CISA, the NSA and the cyber security centres of Canada, the United Kingdom and New Zealand, published Detecting and Mitigating Active Directory Compromises, a guide to the 17 techniques seen most often in real incidents. Its central message: these are not exotic exploits but abuses of configuration and privilege that the directory owner can remove.
What is in scope: the nine areas of an Active Directory penetration test
A complete engagement covers the on-premises directory, the cloud tenant and the bridge between them. Name each area in your scope statement, including the ones you exclude.
Forest, domain and trust design
How many forests and domains exist, how trusts connect them, and whether a lower-assurance domain (an acquisition, a lab, a legacy subsidiary) can reach a higher-assurance one.
Privileged accounts, groups and tiering
Who is in Domain Admins, Enterprise Admins and the other built-in privileged groups, who can modify them indirectly, and whether administrative accounts are separated by tier so a workstation compromise cannot yield domain-level credentials.
Authentication protocols and password policy
Which authentication protocols remain enabled, whether legacy protocols are still accepted, how password policy is set, whether multi-factor authentication covers privileged and remote access, and how service account credentials are managed and rotated.
Group Policy and configuration
Group Policy objects are the directory's configuration engine. The test reviews who can edit them, whether credentials or scripts in policies expose secrets, whether hardening baselines are actually applied, and whether a policy change could push settings to privileged systems.
Active Directory Certificate Services
Enterprise certificate authorities issue the certificates that authenticate users, computers and services. Misconfigured templates and permissive enrollment are among the most common privilege paths of recent years. The test reviews templates, enrollment rights and CA permissions.
Entra ID and hybrid identity
The synchronization service between on-premises Active Directory and Entra ID, the accounts it runs under, Entra roles and application permissions, conditional access coverage, and whether a compromise on one side converts into control of the other.
Service accounts and delegation
Service accounts with high privilege, interactive logon rights or passwords that never change, delegation settings that let one service act on behalf of users, and the applications that depend on them.
Domain controllers, backups and recovery
Where domain controllers run, who can log on to them, how they are patched, whether their backups are protected against the credentials an attacker would hold, and whether the directory could be rebuilt after a destructive incident.
Monitoring and detection
Whether directory security events reach a SIEM or managed detection service, whether changes to privileged groups, policies and certificate templates generate alerts, and which of the testers' agreed actions were noticed.
The control gaps we report most often
Described as control gaps rather than techniques. In a report each is scored by how directly it leads from a standard user to domain or tenant control; the remediation order follows below.
1. Weak or absent administrative tiering
Domain administrators who log on to ordinary workstations, help-desk staff with rights over privileged accounts, and the same credentials used for daily work and administration. One compromised workstation then holds the keys to the directory.
2. Legacy authentication protocols still enabled
Older protocols kept alive for a printer, a file share or an application nobody owns any more, accepted by every domain controller because disabling them was never scheduled. They weaken the entire domain, not just the device that needs them.
3. Excessive privileged group membership and indirect paths
Privileged groups that have grown for years, nested groups that grant domain-level rights to people who do not know they have them, and object permissions that let a non-administrator reset or modify privileged accounts.
4. Certificate template and enrollment misconfiguration
Templates that let requesters specify the identity in the certificate, enrollment rights granted to broad groups, and certificate authorities whose own permissions were never reviewed. Because certificates authenticate users and computers, these settings become a direct path to privileged identities.
5. Password policy and credential exposure
Short minimum lengths, no screening against known-compromised passwords, no monitoring for broad login attempts across many accounts, service accounts with passwords set years ago, and credentials stored in scripts, shares and Group Policy.
6. Stale accounts, stale systems and unmanaged service identities
Accounts of departed employees still enabled, computer accounts for systems that no longer exist, unsupported operating systems joined to the domain, and service identities nobody can trace to an owner. Each is an unmonitored entry point.
Active Directory security assessment versus penetration test versus red team
Buyers often receive three proposals with similar titles. They differ in method, realism and output, and the right choice depends on what you need to prove.
| Aspect | AD security assessment (configuration review) | Active Directory penetration test | Red team engagement |
|---|---|---|---|
| Question answered | Which settings and permissions deviate from good practice? | From a realistic foothold, which paths lead to domain or tenant control, and what stops them? | Can a motivated adversary reach a business objective undetected? |
| Method | Automated collection of directory data plus expert review | Assumed-breach testing from a standard user and workstation, manual privilege-path analysis, controlled validation | Covert, objective-driven, full attack chain over weeks |
| Starting position | Read access to the directory | Standard user account, domain-joined workstation | Nothing, or whatever the scenario defines |
| Coverage | Broad, every object and setting | Deep on privilege paths and the controls around them | Narrow, the paths the team actually used |
| Output | Findings list against a benchmark | Attack narrative, CVSS-scored findings, prioritized remediation, retest | Objectives reached, detection timeline, strategic recommendations |
| Best for | Baseline and continuous hygiene | Annual assurance, post-migration validation, compliance evidence | Mature programs validating detection and response |
How an Active Directory penetration test runs
The engagement is positioned as assumed breach: we start from a realistic foothold and measure how far it can be expanded.
1. Scoping and rules of engagement
We agree the forests, domains, tenant and trusts in scope, the starting position (a standard user and workstation by default), whether the security operations team is informed, excluded systems, the testing window and the escalation path for critical findings.
2. Directory and identity mapping
From the starting position testers build a model of the directory: accounts, groups, nested memberships, object permissions, Group Policy links, certificate templates, trusts, synchronization accounts and Entra roles.
3. Privilege-path analysis
Testers identify the chains that lead from the starting position to privileged accounts, domain controllers, the certificate authority, the synchronization service and Entra administrative roles, and document each with the control gap that enables it and the control that should have blocked it.
4. Controlled validation
Selected paths are validated under agreed conditions to prove they are real rather than theoretical, with evidence for the report.
5. Hybrid and cloud extension
Where Entra ID is in scope, testers assess whether on-premises control converts to tenant control and the reverse: the synchronization service and its accounts, application and service principal permissions, conditional access gaps and privileged role assignments.
6. Reporting, remediation workshop and retest
Executive summary, privilege-path narrative, CVSS-scored findings with evidence, a remediation plan sequenced by risk reduction per effort, and a mapping to the frameworks you report against. Medium or higher findings are retested within 90 days.
Remediation priorities: what to fix first
Directory remediation can consume a year if approached as a list. Sequenced by risk reduction, the first three remove most of the paths we find.
1. Enforce tiering for privileged access
Separate accounts and dedicated hardened workstations for directory administration, no privileged logons to ordinary workstations or servers, and privileged credentials that never leave their tier. Microsoft's enterprise access model describes the target state.
2. Shrink and govern privileged membership
Reduce built-in privileged groups to a small set of named administrators, remove nested paths, fix object permissions that allow indirect control, and move everyone else to just-in-time elevation with approval and logging. Review quarterly.
3. Harden certificate services
Review every certificate template, remove enrollment rights from broad groups, disable templates that let requesters define identity unless a documented need exists, require approval for sensitive templates and audit the certificate authority's own permissions. Treat the CA as a tier-zero asset.
4. Retire legacy protocols and strengthen credentials
Inventory and remove dependencies on legacy authentication, enforce modern authentication at the domain controllers, apply NIST SP 800-63B password guidance with compromised-password screening, extend multi-factor authentication to all privileged and remote access, and move service accounts to managed account types.
5. Close the hybrid bridge and detect
Treat the synchronization server and its accounts as tier zero, limit which on-premises accounts hold Entra privileged roles, apply conditional access to administrators without exception, and alert on changes to privileged groups, Group Policy and certificate templates.
Frameworks and compliance mapping
The public reference for this work is Detecting and Mitigating Active Directory Compromises (ASD ACSC with CISA, NSA, CCCS, NCSC-UK and NCSC-NZ, September 2024), which describes 17 common compromise techniques with mitigations and detections for each. Microsoft's enterprise access model defines the privileged access architecture the priorities above aim for and extends tier zero to the whole control plane including cloud identity. The CIS Benchmarks for Windows Server and Microsoft 365 provide configuration baselines, and NIST SP 800-63B sets the authentication and password requirements US regulators increasingly cite.
For US compliance programs, an Active Directory penetration test evidences the NIST SP 800-53 Rev. 5 Access Control (AC) and Identification and Authentication (IA) families, which flow into FedRAMP and into CMMC 2.0 Level 2 through NIST SP 800-171 Rev. 3 (the AC.L2 and IA.L2 practices and the CA.L2-3.12.1 assessment requirement). PCI DSS v4.0.1 Requirements 7, 8 and 11.4 touch the directory wherever it governs access to the cardholder data environment, the HIPAA Security Rule requires access and audit controls at 45 CFR 164.312(a) and (b), and SOC 2 examinations map directory findings to CC6.1 through CC6.3. In the EU, NIS2 Article 21(2) names access control and multi-factor authentication among required measures, DORA Articles 9 and 25 cover access management and penetration testing for financial entities, and ISO 27001:2022 controls A.5.15, A.5.18, A.8.2 and A.8.5 are the ones an auditor will ask you to evidence for the directory.
What to prepare before the test
A short preparation list that saves testing days and prevents surprises during the engagement.
- A high-level diagram of forests, domains, trusts and the Entra tenant, including recent acquisitions and legacy environments
- The starting position agreed in writing: a standard user account and a domain-joined workstation with the same build and policies as a normal employee
- A list of excluded systems and fragile legacy applications, with the business owner who can approve or deny checks against them
- Documentation of current administrative practice: who administers the directory, from where, with which accounts, and how privileged access is granted and revoked
- Confirmation that the organization owns or is authorized to test every domain, tenant and system in scope, including those operated by a managed service provider
How HackersHub tests Active Directory
Active Directory testing at HackersHub is delivered within our network penetration testing practice, positioned as assumed breach and covering on-premises directories, Entra ID and the hybrid bridge between them. Our testers hold at least OSCP, with OSWE and CREST-certified testers on the team, and the methodology aligns with PTES and NIST SP 800-115.
Every report names the lead tester and contains an executive summary, the privilege-path narrative, CVSS-scored findings with evidence, a remediation plan sequenced by risk reduction, and a mapping to the frameworks you report against. A verification retest of medium and higher findings within 90 days is included. We deliver remotely from Amsterdam, Netherlands, for US and EU clients, with on-site work where an engagement requires it. Every engagement is scoped individually.
Frequently asked questions
Related guides and services
- Network penetration testing by HackersHub
- Kubernetes penetration testing: scope, findings and preparation
- Red team vs penetration testing: which one you need
- Black box vs grey box vs white box penetration testing
- Penetration testing methodology: standards, phases and evidence
- External vs internal penetration testing
- CMMC penetration testing: Level 2 assessment requirements
- Penetration testing services by HackersHub
Is your directory the weakest link?
We map the privilege paths from a standard user to domain and tenant control, and hand you a remediation order that removes most of the risk in the first three changes. Talk to an expert.