In more than 78% of human-operated cyberattacks, threat actors successfully breach a domain controller, and in more than 35% of cases the domain controller is the primary spreader device that distributes ransomware at scale (Microsoft Security Blog, April 2025). Those two numbers are the whole argument for buying this engagement as its own line item. The directory is not one more internal system to sweep for missing patches. It is the control plane the intrusion is aiming at, and almost every path to it runs through configuration and permissions rather than a CVE.
An Active Directory penetration test is a scoped, authorised engagement in which testers start from the position of an ordinary domain user and attempt to reach control of the directory, then hand back every path they proved, the object and attribute behind each hop, and a remediation order that removes the most paths first. What you are buying is proof, not enumeration. A collector can list ten thousand permission edges in an afternoon; deciding which of those are actually usable, walking them end to end, and telling you which single change breaks the most chains is the work.
This guide covers buying that engagement: what should be in scope layer by layer, where the tester should start and why that choice changes the result, what the report and remediation roadmap must contain, the four delivery models on the market, published pricing and timelines, how to verify a provider before you sign, and how the output maps to your compliance programme.
Which guide you need
Stingrai publishes several resources on Active Directory and internal network security. They answer different questions, so start with the one that matches yours.
Your question | Read this |
|---|---|
How do I buy the engagement, compare providers, and budget for it? | This guide |
What does the assessment cover in scope terms, and what does it find? | |
How do testers reach the directory from inside the network in the first place? | Internal Network Penetration Testing: Scope, Cost and What It Actually Finds |
What does the perimeter half of the engagement look like? | External Network Penetration Testing: What Is In Scope and What It Finds |
What does a full attack chain look like end to end, with real output? | |
Why does Kerberos delegation keep coming up in findings? | |
How do I scope the wider network engagement around it? |
Active Directory pentest, internal network pentest, Active Directory security assessment: the definitions
The three terms are used interchangeably by a lot of vendors, and that ambiguity is a real buying hazard: it is how organisations pay for one thing and receive another. Here is the honest distinction. An internal network penetration test asks what an attacker can reach and exploit across your internal hosts and segments. An Active Directory penetration test asks how many routes exist from an ordinary domain account to control of the directory, and proves them. An Active Directory security assessment reviews the same identity plane but weights configuration review and coverage breadth more heavily than end-to-end exploitation.
Active Directory penetration test | Internal network penetration test | Active Directory security assessment | |
|---|---|---|---|
The question it answers | How many proven routes run from a standard user to control of the directory? | What can an attacker exploit across internal hosts, services and segments? | How far does the directory's configuration deviate from a hardened baseline? |
What gets enumerated | Identities, permission edges, delegation, certificate templates, Group Policy, trusts | Hosts, ports, patch levels, services, segmentation boundaries | The same identity objects, reviewed for configuration weakness across the estate |
Where the tester starts | Assumed breach, usually one deliberately unprivileged domain account | Network drop or VPN, often with no credentials | Usually a read-capable account, sometimes a read-only directory export |
What the deliverable leads with | Proven paths, named object by object, ordered by how many break per fix | Exploited hosts and services, plus segmentation results | Prioritised configuration deviations and hardening recommendations |
Buy it when | The directory itself is the risk you need evidence about | You need coverage of the whole internal estate | You want breadth of coverage and a hardening roadmap more than exploitation proof |
In practice the penetration test and the assessment overlap heavily, and many providers sell one under the other's name. The question that separates them on a proposal is simple: how many paths did you walk end to end, and what did you decline to execute? A provider who answers with a number and a named exclusion list is selling a penetration test. A provider who answers by describing tool coverage is selling an assessment. Both are legitimate purchases. Just know which one is on your statement of work.
What an Active Directory penetration testing service covers
A competent Active Directory penetration test names nine scope layers in the statement of work. If your proposal covers fewer, the gap is not theoretical: it is a family of paths nobody will look at. Each layer below is described in defender's terms, as what the test checks and what the finding says on your report.
Scope layer | What the test checks | What the finding looks like on your report | ATT&CK reference |
|---|---|---|---|
Kerberos ticketing | Whether accounts carrying a Service Principal Name, or accounts with pre-authentication disabled, hold passwords weak enough to be recovered offline, and whether any of those accounts are privileged | A named list of service accounts whose credentials are recoverable, flagged by privilege level and by how long recovery took | T1558.003, T1558.004 |
Object permissions and ACL chains | Which principals hold control permissions over which objects, and whether inheritance and protected group processing leave those permissions usable in practice | Named permission chains from an ordinary user into privileged groups, with the specific object and right at each hop | T1078.002 |
Delegation configuration | Which hosts and accounts are trusted to act on behalf of other users, who can modify those settings, and whether any of it reaches Tier 0 | The delegation inventory, which entries are reachable by a standard user, and which terminate at a control-plane asset | T1550 |
Active Directory Certificate Services | Certificate template permissions, whether requesters can supply their own subject, enrolment agent rights, certificate authority flags and the exposure of enrolment endpoints | Which templates issue authentication certificates to which populations, and which of those constitute a privilege escalation | T1649 |
Group Policy | Who can edit or link policy objects, which policies apply to Tier 0 assets, and whether any policy distributes credentials or grants local administrator rights broadly | The list of principals who can change policy affecting privileged systems, and any policy-delivered credential exposure | T1484.001 |
Domain and forest trusts | Trust direction, SID filtering status, and whether a compromise on one side of a trust reaches the other | Per-trust findings stating which direction is exploitable and what protection is missing | T1484.002 |
Credential exposure and local administrator reuse | Whether a single local administrator secret is shared across the fleet, which systems sit outside managed local password rotation, and who can read stored passwords | The organisational units outside password management, and who holds read access to the stored secrets | T1552 |
Tier 0 boundary and administrative practice | Whether control-plane assets depend on anything less trusted, including where privileged credentials are typed and which platforms can push code to domain controllers | Systemic findings naming each Tier 0 dependency on a lower tier, rather than scattered per-host tickets | T1078 |
Hybrid identity seam | The synchronisation server, its service accounts, federation infrastructure, and whether on-premises compromise extends into the cloud tenant or the reverse | Findings stating whether the two control planes are genuinely separated, and where a single compromise spans both | T1484, T1550 |
Two classes sit on the boundary between this engagement and a general internal network test, so name the owner explicitly in scope: name resolution poisoning feeding relay attacks against services that do not enforce signing or channel binding, and authentication coercion, which is what turns delegation and exposed enrolment endpoints from a configuration observation into a working path. Both are usually best owned here, because the remediation is directory and protocol configuration rather than host patching.
For the underlying technique catalogue, the September 2024 joint guidance Detecting and Mitigating Active Directory Compromises, published by ASD's ACSC with CISA, the NSA, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK, documents 17 techniques used to target Active Directory across AD DS, AD CS and AD FS. It is the most useful single reference to hand a provider when agreeing coverage, because it lets you ask which of the 17 they test for by name.
What is normally out of scope
Say these out loud during scoping rather than discovering them in the report. Host patch levels across the internal estate, internal web applications, storage and virtualisation platforms that are not Tier 0 dependencies, and workstation endpoint security testing all belong to an internal network penetration test. Detection and response performance belongs to a purple team or red team engagement, because measuring it requires your security operations team not to be told. Denial of service against domain controllers is excluded by default in every reputable statement of work.
Assumed breach: where the test starts, and why it changes the result
Start position is the single most consequential scoping decision, and it is worth more discussion than most proposals give it. Assumed breach means you hand the tester a deliberately unprivileged domain account on day one instead of making them earn it. This is not a shortcut. It is a decision about what you want to spend the budget proving, because days spent acquiring a foothold are days not spent mapping the identity plane behind it.
Starting position | What the tester is given | What it proves | Trade-off |
|---|---|---|---|
Zero credentials | Network access only, no accounts | That your foothold controls hold, and how long acquisition takes | Consumes one to several test days before identity work begins; a failed acquisition can end the engagement with no directory findings at all |
Standard domain account (most common) | One or two deliberately unprivileged accounts | The full escalation surface behind an ordinary user, which is what a phished employee actually has | Says nothing about how hard the initial foothold was to obtain |
Standard account plus managed workstation | An account and a domain-joined device on your standard build | The same, plus whether your real endpoint controls block the techniques | Requires build provisioning, which is the most common cause of a delayed kickoff |
Compromised service account | A non-human account of the kind attackers frequently obtain | Whether your service account population is a shorter route than your human one | Narrower scope; use it as an addition rather than a replacement |
Assumed Tier 1 administrator | A server or workstation administrator account | Whether the Tier 0 boundary genuinely holds under pressure | Skips the lower escalation surface entirely, so pair it with a standard-account phase |
The market default, and our recommendation for a first engagement, is one or two standard domain accounts. Ask for two, so that a lockout on one does not stall a day of testing. Put your lockout threshold in the rules of engagement in writing, because any password guessing has to stay underneath it.
If you also want to know how long foothold acquisition takes, buy it as a separate phase rather than as the opening of the directory test. That way an unsuccessful phishing simulation does not consume the budget you allocated to identity work.
Methodology and standards a provider should be able to name
Ask which framework governs the work, and expect specifics. Reputable Active Directory engagements map findings to MITRE ATT&CK technique IDs, so your detection engineering team can pick up the report and write rules directly from it. Coverage should be stated against the 17 techniques in the joint ASD and CISA guidance above. Remediation should be framed against Microsoft's enterprise access model, which defines the control plane and the tiering that protects it, because that is the model your platform team will actually implement against.
Firm-level accreditation is the other signal worth checking. CREST accreditation is assessed at the company level and covers methodology, data handling and quality assurance, which is different from an individual tester holding a CREST certification. Both are worth having. Verify which one a vendor is claiming, because the two get blurred in marketing copy routinely.
What the report contains, and the remediation roadmap
The report is the product. Everything else is process. Specify these components in the statement of work rather than hoping for them, because the difference between a good and a bad Active Directory report is not finding count, it is whether an engineer can act on it on Monday morning.
Report component | What good looks like |
|---|---|
Executive summary | How many independent paths were proven, from what starting privilege, and how long the fastest one took, in language a board member can read |
Proven path narratives | The ordered hops in each chain, the specific object and attribute behind every hop, and the point at which one change breaks the chain |
Attack path graph | Only proven paths, with every node and edge labelled, plus the underlying data as an export rather than a screenshot |
Tier 0 dependency findings | Control-plane dependencies on lower tiers written up as systemic issues, not decomposed into dozens of individual tickets |
Object-level register | Every roastable account, delegation entry, certificate template permission, replication right and permission edge, exported in a format your ticketing system can ingest |
Prioritised remediation roadmap | Ordered by how many proven paths each change removes, split by horizon, with owner and effort estimate per item |
Detection notes | Which stages generated telemetry you could have alerted on and which passed silently |
Retest record | Evidence that the fixed chains are broken, not merely that tickets were closed |
Sequencing the remediation roadmap
A list of findings sorted by CVSS severity is close to useless for Active Directory, because the severity of a permission edge depends entirely on where it leads. The roadmap should be sequenced by path removal instead. Ask the provider to structure it this way and to show their arithmetic.
Horizon | What belongs there |
|---|---|
This week | The single changes that break the largest number of proven paths, usually one or two permission removals, a certificate template correction, or rotating a credential that appeared in multiple chains |
This month | Delegation cleanup, certificate template permission review across the whole template set, removing replication rights from non-domain-controller accounts, and closing the local administrator reuse gaps |
This quarter | Tier 0 boundary work: dedicated administrative workstations, moving privileged authentication off general-purpose devices, and separating the hybrid identity seam |
Structural | Group Policy delegation review, trust hardening including SID filtering, and the joiner-mover-leaver process changes that stop the permission sprawl from returning |
Verification | A retest that re-walks each proven path and states whether it is now broken, plus a revised completion letter |
The structural row matters more than it looks. Nearly every Active Directory report describes permissions accumulated over a decade of delegations, migrations and application installs. If the process that created them does not change, the same report can be re-run in three years with different object names and the same conclusions.
The four delivery models, compared
Active Directory testing is human-led work in every delivery model, because the judgement being sold is which of thousands of enumerated permission edges are actually usable and where they lead. Where the models genuinely differ is who those humans are, whether they are on your network under a trusted access agreement, and how much of the deliverable is generated rather than written.
Delivery model | Who performs the testing | Strengths | Structural trade-offs | Published pricing |
|---|---|---|---|---|
Specialist offensive security firm | An in-house bench of senior testers, usually the same people across your retests | Deep directory specialisation, continuity between engagements, direct access to the tester who wrote your report | Bench capacity means lead times in busy quarters; smaller firms may not cover every adjacent service you need | Sometimes published, more often quoted per engagement |
Broad security consultancy | Consultants drawn from a large pool, often with rotating staffing across engagements | Breadth across compliance, cloud and advisory work; procurement-friendly for large enterprises | Directory specialisation varies by who is staffed; the tester who wrote your report may not exist by your retest | Rarely published |
IT partner or managed service provider add-on | Generalist engineers, occasionally subcontracted specialists | Convenient when the same partner runs your directory; low procurement friction | Independence problem: a provider assessing a directory it configured is reviewing its own work | Rarely published, often bundled |
Attack path software, self-run | Your own team, running a graphing or posture product | Continuous visibility, useful between engagements, strong for tracking whether remediation held | Reports candidate edges rather than proven paths; inheritance and protected group processing make some unusable, and the product cannot decide which matter to you | Licence-based, per-object or per-user |
Two honest observations about this category. First, crowdsourced and researcher-network models, which work well for external web application testing, are rare for internal Active Directory work, because the engagement requires trusted, authenticated access to your internal network under a named-tester agreement. If a platform offers it, ask specifically who receives the credentials and how that individual was vetted.
Second, attack path software is genuinely valuable and belongs in the conversation, but it solves a different problem. Products such as BloodHound, originally released by SpecterOps, and PingCastle, now part of Netwrix, are standard parts of a competent tester's toolkit, and running them yourself between engagements is a good idea. The distinction is that a graph shows you candidate relationships, while the engagement tells you which of them a person actually walked, which ones inheritance rendered unusable, and what to fix first. If a vendor's deliverable is a tool export with a cover page, you paid consultancy rates for a licence.
What an Active Directory penetration test costs in 2026
Active Directory engagements are quoted per engagement rather than sold from a rate card, because effort scales with the number of domains, forests and trusts, the size of the privileged population, whether certificate services and hybrid identity are in play, and how deep you want impact demonstrated. Very few providers publish figures at all, which makes the ones that do useful anchors.
Two published reference points, both current:
£750 to £1,800 per tester day. Agility Cyber Limited, a UK supplier, publishes this range for its "Active Directory Security Assessment (Penetration Test)" on the UK government's G-Cloud Digital Marketplace, delivered by UK-based, security-cleared CREST-certified testers (G-Cloud listing).
CAD$15,000 to CAD$40,000 per engagement. Cyber Security Pentesting Inc, based in Toronto, publishes this as its typical 2026 range for an Active Directory engagement, alongside published durations of two to three weeks for a single forest and three to five weeks for multi-forest or large hybrid estates.
Read those together and a picture emerges: a single-forest engagement of roughly eight to twelve tester days lands in the same band from both directions. That is the number to sanity-check a quote against. For wider context on how penetration testing is priced across service lines, see our penetration testing cost guide for 2026 and the average cost of a pentest in Canada.
Cost driver | Why it moves the number |
|---|---|
Domains and forests | Every trust is a separate escalation surface that has to be tested in both directions |
Privileged population size | Enumeration is fast; validating which of thousands of permission edges are usable is not, and every Tier 0 identity is another destination to trace |
Certificate services in use | Adds a whole family of template, enrolment and authority checks, and frequently produces the shortest path in the domain |
Hybrid identity | A second control plane, plus the seam between them, roughly doubles the surface that has to be reasoned about |
Starting position | A zero-credential start spends days acquiring what assumed breach hands over on day one |
Impact depth and evidence format | Executing final-stage actions under change control, and producing insurer or regulator evidence formats, is real additional effort |
Retest scope | A retest that re-walks every proven path costs meaningfully more than one that re-checks a list of tickets, and is worth the difference |
Where Stingrai's published pricing does and does not apply
Stingrai publishes fixed prices for web application testing: an Autonomous Pentest from US$3,000 as a one-time engagement or US$450 per month, and a Hybrid Pentest with certified experts at US$6,800 one-time or US$1,275 per month, both available as an annual one-time engagement or as a continuous programme. See our pricing page for what each tier includes.
Those tiers cover web application scope. Active Directory, network, wireless, physical and social engineering engagements are quoted individually, because the drivers in the table above vary too much between estates for a fixed price to be honest. If you want a number, send the domain and forest count, the approximate user and privileged account population, whether certificate services and hybrid identity are in play, and we will come back with tester days and a fixed price. Get a quote or see the Active Directory service page.
Timelines: what to plan for
Testing windows scale with identities and trusts, not with bandwidth or host count. The chart below reflects both our own engagement planning and published vendor durations. Iterasec, a provider based in Poland, publishes that "a typical active directory security assessment takes approximately two weeks, depending on domain size, trust relationships, and whether hybrid identity components are included", which sits squarely in the middle band.
Environment profile | Typical testing window | Typical elapsed time, kickoff to final report |
|---|---|---|
Single forest, one domain, small privileged population, no certificate services | 1–2 weeks | 3–4 weeks |
Single forest, two or three domains, mid-sized population, AD CS in use | 2–3 weeks | 4–5 weeks |
Multiple forests with acquisition trusts, large population, hybrid identity | 3–5 weeks, usually phased by forest | 6–9 weeks |
Add one to two weeks for scheduling before kickoff, and plan the retest for four to eight weeks after the report so your team has a realistic window to make the changes. The most common cause of a delayed start is not provider capacity: it is waiting on the test accounts and the domain-joined workstation. Provision both before the kickoff call.
How to choose an Active Directory pentesting company: an eight-step verification
Run every shortlisted provider through these eight steps. The questions are deliberately ones a generalist cannot answer well, and each has a right shape of answer.
Ask how many paths they walked end to end on a comparable engagement. A capable provider gives a number, describes the named paths, and distinguishes them from paths they assessed but declined to execute. Vagueness here is the single most reliable disqualifier.
Ask how they validate a permission edge that a collector reports. The right answer describes confirming effective permissions and practical exploitability, because collectors surface edges that inheritance, protected group processing or tooling limits make unusable. A provider who treats collector output as findings will hand you a report full of false paths.
Ask what they do about certificate services specifically. Expect specifics on template permissions, requester-supplied subjects, enrolment agent rights, authority flags and endpoint exposure. AD CS is frequently the shortest path in a domain, and it is the layer generalists skip most often.
Ask who performs the work and verify their certifications independently. Get named individuals, not a capability statement. CREST, OSCP and OSEP registries are checkable. Ask whether the named testers are the ones who will run your retest.
Ask whether the firm holds accreditation, or whether individuals do. Both are valid. Conflating them is not. Ask which entity holds what, and check it.
Ask what they will not do. A clear exclusion list demonstrates they have thought about your estate. A provider with no exclusions has not considered the operational risk of testing a production directory.
Ask how collected directory data is handled. Directory exports and any recovered credential material are among the most sensitive data you will ever hand a third party. Require documented retention periods, storage location, and destruction evidence at engagement close.
Ask what the retest includes and get it in the contract. The answer you want is that each proven path is re-walked and reported as broken or still open, with a revised completion letter. "We will re-scan" is a different and much cheaper product.
For a fuller set of procurement questions covering commercials, liability and evidence, use our pentest and red team RFP question bank.
Red flags in an Active Directory pentest proposal
The methodology section names tools but no techniques, standards or coverage claim.
The deliverable sample is a graph screenshot and a findings table with no path narratives.
Findings are sorted purely by CVSS severity, which tells you nothing about where a permission edge leads.
The provider will not name the testers, or names them but will not commit them to the retest.
Certificate services, Group Policy delegation or the hybrid identity seam are absent from scope and the provider does not raise them.
The quote is fixed and notably cheap without any questions about domain count, forest count or privileged population size. Nobody can price this work without those numbers.
The proposal offers to test the directory the same provider currently administers, without addressing the independence problem.
No exclusion list, no rules of engagement discussion, and no request for your lockout threshold.
Compliance mapping: what the frameworks actually require
No framework names Active Directory penetration testing as a specific requirement. What several of them require is internal penetration testing, and an Active Directory engagement is the strongest available evidence for that control when your estate is domain-joined.
Framework | What it requires on penetration testing | Practical implication for Active Directory |
|---|---|---|
PCI DSS v4.0.1 | Requirement 11.4 mandates internal and external penetration testing at least every 12 months and after significant change, correction of exploitable findings, and repeat testing to confirm remediation. v4.x has been mandatory since 31 March 2025 | Where the cardholder data environment is domain-joined, directory escalation paths that reach it are in scope for the internal test. Segmentation testing is a separate, additional requirement |
SOC 2 | Does not mandate penetration testing or set a frequency | Auditors and enterprise customers commonly expect annual internal testing. A directory report with a completion letter satisfies the evidence request cleanly |
ISO 27001 | Does not mandate penetration testing or set a frequency | Used as evidence for technical vulnerability management and access control objectives. Annual plus after significant change is the common settlement |
NIST SP 800-53 | CA-8 addresses penetration testing for applicable baselines | Directory testing evidences CA-8 alongside the access control and identification families |
CMMC | Requires penetration testing at Level 3 | Where the enclave holding controlled unclassified information is domain-joined, the directory is part of that boundary |
DORA and NIS2 | Threat-led penetration testing obligations for in-scope financial and essential entities | Directory compromise is a standard objective in threat-led testing, usually inside a broader red team engagement rather than as a standalone test |
Stingrai's penetration testing supports your SOC 2, ISO 27001, PCI DSS, NIST and CMMC compliance programmes, and our reporting is built around what auditors actually ask for. See SOC 2 penetration testing, PCI DSS penetration testing, and the pentest evidence auditors accept.
Where Stingrai fits
Signal | Detail |
|---|---|
Founded | 2021, headquartered in Toronto, Ontario, with a London, UK office |
Accreditation | CREST-accredited penetration testing service provider at firm level, with testers additionally holding CREST CRT |
Team certifications | OSCE3, OSCP, OSWE, OSED, OSEP, CREST CRT, CISSP, CRTO, GCPN, CRTE, eWPTX |
Published research | 18 published CVEs across the team, with research presented at DEF CON and BSides |
Client rating | 5.0 out of 5.0 across 19 Clutch reviews |
Who runs Active Directory work | Senior human penetration testers. Snipe, our autonomous agent, tests web applications only and is not used for directory, network, wireless, physical or social engineering work |
Proprietary tooling | StingAD, our open-source Apache 2.0 Active Directory toolkit, covering enumeration, delegation and local administrator password auditing, certificate services checks and replication rights review |
Starting position | Assumed breach by default, with two deliberately unprivileged accounts, and a zero-credential phase available as a separate addition |
Deliverable | Proven paths with per-hop object and attribute detail, a remediation roadmap ordered by path removal, detection notes and a retest that re-walks each path |
Engagement models | Available as a one-time annual engagement or on a recurring schedule, depending on how quickly your directory changes |
Compliance support | Reporting formats built for SOC 2, ISO 27001, PCI DSS, NIST and CMMC evidence requests |
Scoping | Send domain and forest count, approximate user and privileged population, and whether AD CS and hybrid identity are in play, for tester days and a fixed price |
Where web application scope is also in play, Snipe works alongside our certified pentesters throughout the engagement, with the testers directing where it focuses and extending the attack paths it surfaces. For directory work, the engagement is human-led from start to finish, supported by StingAD.
Frequently Asked Questions
What is an Active Directory penetration testing service?
An Active Directory penetration testing service is a scoped, authorised engagement in which qualified testers start from the position of an ordinary domain user and attempt to reach control of your directory, then report every path they proved along with the specific object and attribute behind each hop. It covers Kerberos ticketing, object permissions, delegation, Active Directory Certificate Services, Group Policy, trusts, credential exposure, the Tier 0 boundary and the hybrid identity seam. The output is a set of proven attack paths and a remediation roadmap ordered by how many paths each fix removes, rather than a list of configuration deviations.
How much does an Active Directory penetration test cost in 2026?
Active Directory engagements are quoted per engagement rather than sold from a rate card. Published market reference points include £750 to £1,800 per tester day from UK supplier Agility Cyber on the G-Cloud Digital Marketplace, and CAD$15,000 to CAD$40,000 per engagement from Toronto-based Cyber Security Pentesting Inc. A single-forest engagement of roughly eight to twelve tester days lands in the same band from both directions. Price is driven by domain and forest count, privileged population size, whether certificate services and hybrid identity are in play, the starting position, and how deep impact is demonstrated.
How long does an Active Directory penetration test take?
A single forest with one domain, a small privileged population and no certificate services is typically one to two weeks of testing, or three to four weeks from kickoff to final report. A single forest with two or three domains and certificate services in use is typically two to three weeks of testing. Multiple forests joined by acquisition trusts, with large populations and hybrid identity, generally run three to five weeks, phased by forest, with six to nine weeks elapsed. Add one to two weeks of scheduling before kickoff and plan the retest four to eight weeks after the report.
What is the difference between an Active Directory penetration test and an internal network penetration test?
An internal network penetration test asks what an attacker can reach and exploit across your internal hosts, services and network segments, and reports exploited hosts, missing patches and segmentation results. An Active Directory penetration test asks how many routes run from an ordinary domain account to control of the directory, and reports proven paths through identities, permission edges, delegation, certificate templates and trusts. Scoping the two as a single line item usually means the identity plane receives a fraction of the attention, because host coverage consumes the days.
How do I choose an Active Directory pentesting company?
Ask each provider how many paths they walked end to end on a comparable engagement, and expect a number rather than a description of tool coverage. Ask how they validate a permission edge a collector reports, because collectors surface edges that inheritance and protected group processing make unusable in practice. Require specifics on Active Directory Certificate Services, named testers with independently verifiable certifications, clarity on whether accreditation is held by the firm or by individuals, a written exclusion list, documented handling and destruction of collected directory data, and a retest that re-walks each proven path.
What does an Active Directory penetration test find?
The most common findings are service accounts whose credentials can be recovered offline, permission chains left by years of delegation and application installs that let an ordinary user control a privileged object, delegation settings that let a host or account act for other users, and certificate templates that issue authentication certificates to populations that should not have them. Underneath those, the systemic finding is almost always a broken tier boundary: a control-plane asset depending on something less trusted, such as privileged credentials typed on a general-purpose workstation.
Should an Active Directory penetration test start with a domain account or from zero credentials?
For a first engagement, start assumed breach with one or two deliberately unprivileged domain accounts. This is what a phished employee actually has, and it directs the entire budget at the escalation surface rather than at foothold acquisition. A zero-credential start consumes one to several test days before identity work begins, and if acquisition fails you can finish the engagement with no directory findings at all. If you also want to measure foothold difficulty, buy it as a separate phase so an unsuccessful result does not consume the identity budget.
Does PCI DSS, SOC 2 or ISO 27001 require Active Directory penetration testing?
No framework names Active Directory penetration testing specifically. PCI DSS v4.0.1 Requirement 11.4 mandates internal and external penetration testing at least every 12 months and after significant change, and v4.x has been mandatory since 31 March 2025, so where your cardholder data environment is domain-joined the directory escalation paths reaching it are in scope for the internal test. SOC 2 and ISO 27001 mandate neither penetration testing nor a frequency, so cadence is driven by auditors, enterprise customers and insurers, with annual plus after significant change being the common settlement. In all cases the useful output is the same: a scoped report, per-finding evidence, documented remediation status and a completion letter.
Related reading
Active Directory Security Assessment: What It Covers, What It Finds, What It Costs for the layer-by-layer assessment scope and cost-driver detail
Internal Network Penetration Testing: Scope, Cost and What It Actually Finds and External Network Penetration Testing
Network Penetration Testing Services 2026 for scoping the wider network engagement
StingAD: From One Low-Priv Account to Domain Admin for a full attack chain with real output
CREST-Accredited Penetration Testing Companies 2026 and Best Penetration Testing Companies 2026
Penetration Testing Cost 2026 and Average Cost of a Pentest in Canada
SOC 2 Penetration Testing 2026 and PCI DSS Penetration Testing 2026
Stingrai services: Active Directory, Internal and External Network Penetration Testing, Network Security, Red Teaming
Ready to scope your Active Directory penetration test?
Send us your domain and forest count, the approximate user and privileged account population, and whether certificate services and hybrid identity are in play. We will come back with tester days and a fixed price, not a discovery call. Active Directory engagements are delivered by our senior human testers, as a one-time annual engagement or on a recurring schedule.
