What is Active Directory penetration testing?
← All guidesActive Directory penetration testing examines whether weaknesses in a Windows domain’s identities, permissions, trusts and services can lead to unauthorized access. A common objective is Domain Admin; a specific file share or application can be a better target when that is what the business needs to protect.
Start with the identity and network position
A test without credentials asks how the first foothold can be obtained. An assumed-breach test starts with an account and asks how far its access extends. The same directory can yield different routes from different network segments or identities.
Include the intended domains and reachable systems in scope, and identify exclusions before the test begins. A trust relationship is relevant to the assessment; it is not permission to test an otherwise excluded domain.
The internal network assessment guide works through choosing the deployment segment and authorized ranges for a data-access objective.
What the test examines
- Exposed credentials. Passwords in shared files or directory attributes can provide access beyond the account that reads them.
- Weak account configuration. Some Kerberos settings allow password material to be collected for offline guessing.
- Delegated rights and certificate settings. Permissions intended for administration can sometimes let another identity obtain greater access.
- Credential reuse and trusts. Access gained on one system may extend elsewhere, depending on permissions and trust controls.
- Privileged access. Rights over a domain controller or directory replication can expose domain credentials.
These checks complement software and patch assessment. A fully patched host can still expose an administrative password, and a correct directory permission does not fix vulnerable software. Microsoft’s least-privilege guidance explains the risks of broad administrative access.
Choose a starting point that matches the question
| Starting access | Assessment question |
|---|---|
| Network access, no credentials | Can the test obtain a foothold from this segment and use it to reach the objective? |
| An ordinary employee account | What systems and privileges can this identity reach beyond its intended role? |
| An already privileged account | What can be assessed from this privileged position? This does not test how an attacker would obtain the starting privilege. |
Include authorized member servers as well as domain controllers. A password exposed on a file server or reused by a service account can be the link that makes domain control possible. Specify other domains and forests explicitly; discovering a trust does not expand the permitted scope.
Check the access behind the account
A useful report shows how the starting identity led to the resulting access. That lets you identify the credential exposure or permission that made a transition possible. It also separates a demonstrated route from a configuration that was observed but never used.
Collecting material for offline password guessing, recovering a password, using it successfully and obtaining domain control are separate results. Inspect the evidence for each transition. After remediation, a run that cannot obtain the first credential may never test permissions deeper in the route.
The report-reading guide explains how to interpret those gaps. AutoAttack records its route in a single campaign report. Read the AD takeover walkthrough, or inspect the published hardened-lab runs.