Active Directory is the control plane of most enterprise networks. It decides who logs on to the file server, who pushes software to ten thousand endpoints, and who reads the backup share. That is why intrusions converge on it: an attacker who reaches Domain Admin needs no second exploit, and a ransomware operator deploys through your own management channels.
An Active Directory security assessment answers one question with evidence: how many routes exist from an ordinary domain account to control of the directory, and what has to change to close each. This is for the person buying that engagement, usually after a ransomware scare, an insurer's questionnaire, or a red team that ended on a screenshot of your domain controller.
Why Active Directory is the highest value target
Three properties make the directory decisive. It is a single trust root, so nearly every server, workstation and application defers authentication to it. Its permissions accumulate: every helpdesk delegation, every application granted write access to one OU in 2014, every migration that left a service account with replication rights, all surviving in ACLs nobody reviews. And most escalation paths are not vulnerabilities in the software sense, so they never reach a patch report and never trip a scanner.
This is how an organisation with clean vulnerability posture falls over in an hour: a standard user who can write one attribute on a service account, which belongs to a group with local admin on a server where a Tier 0 administrator logged in last Tuesday. No CVE anywhere in that sentence. Microsoft frames the defence as a layered enterprise access model in which the control plane must resist escalation from below.
What the assessment covers, and what it does not
It covers the directory as an identity system: domains, forests and trusts; user, computer, group and service accounts; object level permissions; Kerberos configuration and delegation; Group Policy; Active Directory Certificate Services; the hybrid seam into Entra ID; and the administrative practices that decide whether tier boundaries hold.
It does not cover every host on the internal network. Patch levels on a build server, a vulnerable internal application, a misconfigured storage array: those belong to an internal and external network penetration test. Scoping the two as one line item is how buyers pay for a network test and hear nothing about identity.
Dimension | Internal network penetration test | Active Directory security assessment |
|---|---|---|
Primary question | What can an attacker exploit internally? | How many ways does a standard user become Domain Admin? |
Unit of analysis | Hosts, ports, patches, segmentation | Identities, ACL edges, delegation, certificate templates, groups |
Typical start | Network drop or VPN, no credentials | Assumed breach: one standard account and workstation |
Core evidence | Exploited hosts and services | Proven paths from ordinary user to the control plane |
Findings look like | Missing patches, default credentials, exposed interfaces | Kerberoastable admins, ACL chains, delegation and template abuse |
Two decisions shape the rest. Starting position: assumed breach, where you hand over a standard account, or zero credentials, where testers earn the foothold. Assumed breach yields far more findings per day, which is why most AD assessments begin there (more on that trade). And impact depth: whether testers stop at "this path reaches Tier 0" or prove it under supervision.
The attack paths a real assessment proves
Enumeration is cheap. Proof is the product. A serious assessment walks each candidate path far enough to confirm it works, then names the object and attribute behind it.
Attack path | What it is | What the test proves |
|---|---|---|
Kerberos roasting (Kerberoasting and AS-REP roasting) | Service tickets for accounts carrying a Service Principal Name, and responses for accounts with pre-authentication disabled, both crack offline against weak passwords. | Which accounts have weak passwords, and whether any are privileged. |
Delegation abuse (unconstrained, constrained with protocol transition, RBCD) | Unconstrained hosts cache the tickets of everyone who authenticates to them; constrained delegation lets a service act for other users; resource based delegation puts that decision on the target object, so one writable attribute is enough. | Which hosts hold delegation, who can change it, and whether it reaches Tier 0. |
AD CS templates (ESC1 and the wider ESC family) | A template that lets a low privilege requester name their own subject and issues a client authentication certificate hands out credentials for other people. Over permissive template ACLs, risky CA flags and exposed enrollment endpoints sit here too. | Who can enroll in what, and whether CA endpoints are relay exposed. |
ACL edges (GenericAll, GenericWrite, WriteDacl, WriteOwner, ForceChangePassword, AddMember) | Object permissions left by years of delegation and application installs, each letting one principal control another. | The chains into privileged groups, named object by object. |
Shadow Credentials (msDS-KeyCredentialLink) | Write access to the key credential attribute authenticates as that object without touching its password. | Who can write it on privileged objects, and whether your PKI allows it. |
Replication rights (DCSync) | Extended rights that let a principal ask a domain controller for account secrets, including the key behind every Kerberos ticket. | Which non domain controller accounts hold them, usually migration leftovers. |
Golden and silver tickets | Tickets forged from the krbtgt or a service account key; an impact demonstration at the end of a proven path, not an entry technique. | That compromise is total, and recovery needs a double krbtgt rotation. |
Local admin reuse and LAPS gaps | One shared local administrator secret turns a single workstation compromise into fleet wide movement. | Which OUs sit outside LAPS, and who can read stored passwords. |
Stale and over privileged accounts | Dormant Domain Admins, Enterprise Admins, Account Operators, Backup Operators and DnsAdmins; non expiring service passwords; privileged accounts carrying an SPN. | The real size of your Tier 0 population. |
Two classes sit on the boundary with the network test, so say which engagement owns them: name resolution poisoning (LLMNR and NBT-NS) feeding NTLM relay against services that do not enforce signing or channel binding, and authentication coercion, which is what makes unconstrained delegation and exposed enrollment endpoints practically exploitable. Both usually belong here, because the fixes are directory and Group Policy work. Our walkthrough from one low privileged account to Domain Admin shows the sequence against a lab domain.
Tier boundaries and the clean source principle
Most AD findings are symptoms. The disease is a broken tier boundary. Tier 0, the control plane in Microsoft's language, is everything that can compromise identity: domain controllers, the certificate authority, federation and sync servers, the backups holding domain controller images, the platform that pushes code to those servers, and the workstations administrators use to touch them.
The clean source principle holds that anything an object depends on for its security must be at least as trusted as the object itself. A Domain Admin who logs on to a helpdesk workstation makes the domain dependent on that workstation and everyone who can push software to it. Good reports lead with tier dependencies, not six tickets about logon sessions.
Three boundaries belong in scope. Forest trusts, because the forest and not the domain is the security boundary, so trust direction and SID filtering need verifying rather than assuming. Administrative workstations, because privileged credentials should only be typed on hardened, dedicated devices. And the hybrid seam: if you synchronise to Entra ID, the sync server and its service accounts are Tier 0, which is why buyers pair this with an Entra ID engagement.
What the deliverable should contain
The report is what you actually buy, so specify it in the statement of work (how to judge one).
Component | What good looks like |
|---|---|
Executive summary | How many independent paths were proven, from what privilege, and how long the first took. |
Attack path graph | Proven paths with every node and edge labelled, plus the data behind them. |
Path narratives | The ordered hops, the object and attribute behind each, and where one fix breaks the chain. |
Tier boundary findings | Which Tier 0 assets depend on lower tiers, as systemic findings not scattered tickets. |
Object level register | Kerberoastable accounts, delegation, template permissions, replication rights and ACL edges, exportable for ticketing. |
Prioritised remediation | Ordered by how many proven paths each fix removes, split into this week and this quarter. |
Detection notes | Which stages produced telemetry you could alert on and which passed silently, the input to a purple team engagement. |
Retest record | Evidence the fixed chains are broken, not that tickets were closed. |
How long it takes and what drives the cost
Treat the windows below as planning guidance, not a price list. Effort scales with identities and trusts, not bandwidth.
Environment profile | Typical testing window |
|---|---|
Single forest, single domain, small user population, no certificate services | About one working week |
Single forest, two or three domains, mid sized population, AD CS in use | About two working weeks |
Multiple forests with acquisition trusts, large population, hybrid identity | Two to four weeks, phased by forest |
Cost driver | Why it moves the number |
|---|---|
Domains and forests | Every trust is another escalation surface, tested both directions. |
Identity population | Enumeration is fast; validating paths across thousands of objects is not, and every Tier 0 identity is a destination to trace. |
AD CS present | Adds a family of template and endpoint checks, often the shortest path in the domain. |
Hybrid identity | Sync and federation add a second control plane and extend the blast radius. |
Starting position | Zero credentials spends days earning the foothold assumed breach hands over on day one. |
Impact and evidence | Executing the final step under change control, insurer formats and formal retests are real effort. |
Because environments differ on every one of those axes, this is quoted per engagement, not from a rate card. Published Stingrai pricing covers web application testing; Active Directory, network, wireless, physical and social engineering work is quoted individually.
What to prepare before day one
The biggest cause of a slow engagement is waiting on access.
Item | Why it is needed |
|---|---|
Two deliberately unprivileged domain accounts | The assumed breach starting position. Elevated accounts invalidate the result. |
A domain joined workstation or VDI on your standard build | Your real image shows what your real controls block. |
Signed authorisation and rules of engagement | Scope, test hours, excluded actions, who can stop the test. |
Topology list: domains, forests, trusts, sites, domain controller ranges | Stops testers finding a second forest on day four. |
Lockout policy and agreed guessing thresholds | Guessing must stay under your threshold, so put the number in writing. |
A named technical contact during test hours | Fast validation when something looks like a live intrusion. |
Decisions on sensitive actions | Password resets, ticket forging, service restarts and production changes: pre approved or excluded. |
Backup and recovery owner on the distribution list | If a proven path reaches your backups, that owner hears it directly. |
Decide whether your security operations team is told. Informing them gives faster validation; withholding produces detection data, but that objective belongs in a red team engagement.
How to tell a real assessment from a graph
Anyone can run a collector, screenshot the shortest path to Domain Admin and paste it into a template. That is data collection, worth a fraction of its price.
Ask this | What a capable vendor says |
|---|---|
How many paths did you walk end to end? | A number, named paths with evidence, and which were assessed but not executed. |
How do you validate an ACL edge a collector reports? | They confirm effective permissions and practical exploitability, because collectors surface edges that inheritance or protected group processing make unusable. |
What do you do about certificate services? | Specifics on template permissions, requester supplied subjects, enrollment agents, CA flags and exposed endpoints. Vagueness is disqualifying. |
What would you fix first here? | Tier boundaries and the fixes that remove the most paths, not "apply the patches". |
Who performs the work, and how is collected data handled? | Named senior testers with verifiable certifications, plus documented retention and destruction of anything recovered. |
What will you not do? | A clear exclusion list. A vendor with no exclusions has not thought about your estate. |
How Stingrai runs Active Directory assessments
Stingrai has worked in offensive security since 2021 from Toronto and London, and is a CREST accredited penetration testing service provider at firm level, with testers holding CREST CRT alongside OSCE3, OSCP, OSWE, OSED, OSEP, CRTO and CISSP. The team has 18 published CVEs and 5.0 out of 5.0 across 19 Clutch reviews.
Active Directory work is delivered by senior human testers. Snipe, our autonomous agent, tests web applications only; it does not do directory, network, wireless, physical or social engineering work. What we bring instead is our own tooling: StingAD is an open source, Apache 2.0 licensed AD toolkit covering enumeration, delegation and LAPS auditing, certificate services checks, replication rights and graph export, with lockout aware pacing and restore on completion for anything that changes directory state. Read the code before you hire us.
Engagements start assumed breach, prove paths rather than listing edges, and end with remediation ordered by path removal plus a retest. If your trigger was an insurer questionnaire, our notes on cyber insurance underwriting questions map the usual asks to evidence. To scope the work, see the Active Directory service page or the wider network security practice, then get a quote.
Frequently Asked Questions
What is an Active Directory security assessment?
An Active Directory security assessment is an offensive engagement that maps and proves how an ordinary domain account can reach control of your directory. It examines identities, object permissions, Kerberos delegation, certificate templates, trusts and privileged group membership rather than host patch levels. The output is a set of proven attack paths and a remediation plan ordered by how many paths each fix removes.
How is an Active Directory security assessment different from an internal network penetration test?
An internal network penetration test asks what an attacker can reach and exploit across your internal hosts, services and segments. An Active Directory security assessment asks how many ways a standard user can become Domain Admin, examining identities, ACL edges, delegation and certificate templates instead of ports and patches. Scoping them as one engagement usually means the identity plane gets skipped.
How much does an Active Directory security assessment cost?
Active Directory assessments are quoted per engagement rather than sold at a fixed price, because effort scales with your domain and forest count, user and privileged account population, whether certificate services and hybrid identity are in play, and whether testing starts assumed breach or from zero credentials. Impact depth, evidence formats and retest requirements also move the number.
How long does an Active Directory security assessment take?
A single forest with one domain and a small user population is typically about one working week of testing. Two or three domains with certificate services in use is typically about two weeks. Multiple forests joined by acquisition trusts, with large populations and hybrid identity, generally run two to four weeks, phased by forest, with reporting and retest scheduled separately.
What do I need to provide before an Active Directory assessment starts?
Provide two deliberately unprivileged domain accounts, a domain joined workstation or VDI session on your standard build, signed authorisation and rules of engagement, and a topology list covering domains, forests, trusts, sites and domain controller ranges. Testers also need your lockout policy in writing, a named contact during test hours, and decisions on sensitive actions such as password resets and ticket forging.
Will an Active Directory assessment disrupt our domain controllers?
A well run assessment is read heavy and paced deliberately, and any operation that changes directory state should be pre approved, logged and reverted. The risks to manage are account lockouts from password guessing, which is why testers need your lockout threshold in writing, and any final impact demonstration such as ticket forging, which belongs in a change window.
Is running BloodHound the same as an Active Directory security assessment?
No. A graphing tool visualises relationships, but it reports candidate edges that inheritance, protected group processing or tooling limits can make unusable in practice. The assessment is the validation on top: confirming which edges are effective, walking paths end to end, and turning the result into a remediation order. A vendor who cannot say how many paths they walked sold you a collection exercise.
Does PCI DSS or SOC 2 require an Active Directory security assessment?
No framework names Active Directory assessments specifically. Among the common frameworks only PCI DSS v4.0.1 mandates penetration testing across a general population, and CMMC does so at Level 3 only, while ISO 27001, SOC 2 and NIST SP 800-171 do not mandate it and ISO 27001 and SOC 2 set no frequency. Where internal penetration testing is expected, an Active Directory assessment evidences that privileged access paths were tested, and the report supports your compliance programme.
