A directory finding is almost never a vulnerability. It is a sequence of memberships, permissions and delegations that nobody designed, joining an ordinary account to a privileged one. Collecting the relationships tells you the sequence might exist. B-52 starts from an account you nominate and establishes which of those edges actually holds.
Where this sits
No vendor and no tool is named here — these are categories of work. Most organisations large enough to need this class already run the first two, and should.
| Configuration audit | Attack path mapping | A scheduled directory engagement | B-52 | |
|---|---|---|---|---|
| What it produces | A list of settings that differ from a baseline. | A graph of who could reach what, if every edge in it holds. | A route, walked by an assessor, for the days that were bought. | A route, walked, with the edges that held and the ones that did not. |
| Says which edges are real | Not what it is for. | No. Every edge stays a possibility until something attempts it. | For the ones there was time to attempt. | For every one inside the boundary you authorised, and the drops are reported too. |
| Runs without somebody driving it | Yes. | Collection does. Deciding which paths matter does not. | No — that is what you are paying for. | Yes, after scope sign-off. |
| What a finding costs you to confirm | Nothing. The setting either differs from the baseline or it does not. | Judgement, about which of many paths is worth anybody’s week. | Usually nothing; it was walked. | Nothing. The steps that proved it arrive with it. |
| Cadence | Continuous. | Whenever collection is run again. | When it is scheduled and staffed. | The interval you set. |
| Whose signature it carries | None. | None. | The firm that ran it. | Security Brigade’s, in the two models with an empanelled auditor in them. |
What it produces
Says which edges are real
Runs without somebody driving it
What a finding costs you to confirm
Cadence
Whose signature it carries
On the map
Attack path mapping is genuinely useful, and any directory large enough to need this class should already have it: collect the relationships, draw the graph, and the shortest route from an ordinary account to a privileged one falls out of the picture. What a graph cannot say is which of those edges survives contact. A delegation that looks exploitable may be blocked by something the collector never saw. A membership that looks inert may be the one that works. Separating the two means attempting them, and attempting them is precisely what a collection tool is not permitted to do. That is the boundary this class sits on: the map is an input, and the assessment is the walk.
Class and boundary
The directory as a set of relationships rather than as a list of servers. Active Directory penetration testing and an Active Directory security assessment are the same work here; the second phrase is what buyers type.
Accounts, groups and computers and the memberships between them; delegation and trust configuration; the permissions set on the directory objects themselves; and the privileged tier — who is in it, what put them there, and what can reach it from outside.
Authentication protocol configuration and what the directory will accept or fall back to; service accounts and what they are registered for; and the credential material that ends up on machines as a consequence of both.
Reaching the hosts and services around it is the internal network class. This one starts from a position that can already talk to the directory, and the two are commonly bought as one engagement.
Out of scope for the platform entirely, in every class. It is the only exclusion, and it is stated the same way everywhere on this site.
Who this page is for
Both are answered here. Where they should start is not the same.
By phase
The phase names are the platform’s. On this class the drops matter as much as the findings, and phase four is where both are produced.
| Phase | What enters | What leaves |
|---|---|---|
| Discovery | A position that can talk to the directory, and an account at the privilege level you nominated. | The objects, memberships, delegations and trusts as they actually are — which is regularly not as the documentation has them. |
| Planning | The collected relationships. | The paths worth attempting, and a boundary: which of them may be walked and how far. Signed in writing before anything is attempted. |
| Scanning | The directory configuration. | Candidates — permissions, delegation and protocol configuration measured against the model. Nothing leaves this phase as a finding. |
| Exploitation | A candidate path, and the account it starts from. | A path that held, or an edge that did not. The drops are written down too: an edge that failed is the closest thing a directory has to evidence that a control works. |
| Reporting | Confirmed paths. | Each step with the object it used and the permission that allowed it, landing in your dashboard as each is confirmed. |
| QA | The finished report. | A gate that can send it back to reporting. It is where a path that was theoretically reachable is separated from one that was actually walked. |
Discovery
Planning
Scanning
Exploitation
Reporting
QA
On the starting account
An assessment starting from a fresh domain user answers what a phished employee reaches. One starting from a workstation administrator answers what a compromised support account reaches. One starting from a service account answers what happens when an application is taken. Those are three different assessments with three different answers, and none of them on its own is the assessment. So the starting position is agreed at scoping beside the movement boundary, and every finding records which of them it was — because a privilege path without its starting privilege is a claim nobody can check and nobody can prioritise.
The boundary
The same three actions need written approval as on every coverage class. On this one the first is the work itself and the second is stricter than usual, for a reason the block below explains.
| State | What it means | What follows |
|---|---|---|
| Persistence and movement past the entry host | Walking a privilege path is movement by definition. On this class the authorisation and its limit are part of the scope agreement rather than a question raised while a run is going. | Agreed at scoping, with its boundary written down. |
| Changing anything in the directory | Creating, altering or removing an object, a membership or a permission. Establishing that a path would permit a change is the finding; making the change is not part of producing it. | Stops and waits, in writing. |
| Live credentials or real customer data | Recovering credential material belonging to a real account once a path to it has been proved, and using it afterwards. | Stops and waits, in writing. |
| Everything else inside the authorised scope Terminal | Collection, relationship analysis, configuration measurement, attempting the edges inside the agreed boundary, chaining and reporting. | Runs without asking. |
Why the second row is stricter here
Most systems can be tested and left where they were found. A directory is not most systems: a membership added, a permission granted or an object created is a change to the thing everything else authenticates against, and some of it has replicated before anybody notices. So the destructive gate here is not really about damage in the usual sense — it is about not leaving an estate in a state somebody has to reconstruct afterwards. Establishing that a path would permit a change is the finding. Where you want the change itself demonstrated, it is authorised specifically, performed at an agreed time, and reversed deliberately rather than assumed to have been harmless.
What the assessment reaches
The first two rows are what the other six turn into. None of them is a vulnerability in the usual sense, which is exactly why a patch cycle never finds them.
| Class | What it looks like in a real directory |
|---|---|
| Paths into the privileged tier | The chain of memberships, permissions and delegations connecting an ordinary account to a privileged one. Almost never a single defect, and almost always a sequence nobody designed or reviewed as a whole. |
| Permissions set on directory objects | What one account is permitted to do to another — reset it, add itself to something, rewrite an attribute that something else trusts. These are the edges the whole graph is made of. |
| Delegation configuration | Which accounts may act on behalf of others, for which services, and whether that permission is narrower than the account holding it. |
| Service accounts and their registrations | Accounts that authenticate software rather than people: where their credentials end up, what they are members of, and what still depends on how they were configured years ago. |
| Authentication protocol configuration | What the directory will accept, what it will fall back to, and which fallback is still enabled for a reason nobody currently in the building can name. |
| The privileged tier itself | Who is in it, what put them there, whether membership is still explained by a job somebody does today, and what outside the tier can reach into it. |
| Trusts between domains and forests | What each side is permitted to assert about the other, and whether the boundary between them is the boundary the architecture diagram draws. |
| Credential material left on machines | What is recoverable from a host once it has been reached, and which accounts that turns into. This is where the directory class meets the internal network one. |
Paths into the privileged tier
Permissions set on directory objects
Delegation configuration
Service accounts and their registrations
Authentication protocol configuration
The privileged tier itself
Trusts between domains and forests
Credential material left on machines
Three of them, worked
Each of these looks settled on a map and turns out otherwise, in one direction or the other.
Methodology
Each cited at the version current on the date beside it. The technique vocabulary matters more here than on most classes, because the team that receives the report is usually the team that owns the detections.
| Standard | Version | What it carries here |
|---|---|---|
| MITRE ATT&CK | v19.2, released 6 August 2026. Read 2026-09-13 | The technique each step of a path maps to — credential access, privilege escalation, lateral movement — so a finding can be taken straight to the rule that should have caught it. |
| NIST SP 800-115 | Final, September 2008. Read 2026-09-13 | The structure of a technical assessment, and the handling rules for what the attack phase turns up. |
| Still the current edition: it has been neither withdrawn nor superseded. | ||
| CWE | Current | The weakness identifier where a step maps to one. Several do not, because a permission granted deliberately in 2011 is not a weakness class — and the report says so rather than forcing an identifier onto it. |
| CVSS | v4.0, November 2023. Read 2026-09-13 | The severity vector on the path as a whole rather than on each step, because the steps are individually unremarkable and that is the point of them. |
MITRE ATT&CK
NIST SP 800-115
Still the current edition: it has been neither withdrawn nor superseded.
CWE
CVSS
Before a run starts
Deliberately excluded
Per finding
Each step with the object it used, the permission that allowed it, and the account it was performed as. A privilege path summarised as a severity is not something anybody can act on.
Which account the run began from, and at what level. A path from a domain user and a path from a workstation administrator read identically without it and mean entirely different things.
Which single step in the chain, removed, ends the path — so remediation starts somewhere smaller than the whole route and somebody can actually schedule it.
Severity with its CVSS v4.0 vector on the path as a whole, the CWE where a step maps to one, and the ATT&CK technique for each step.
In the model with no auditor in it, findings pass a second automated gate before they are reported. It is a check on top of the walk, not a substitute for it.
Filing
Coverage is identical across the three delivery models. What differs is whose signature the report carries.
| Obligation | What it asks for, and which model produces it |
|---|---|
| A privileged access programme with a tier boundary | Where a programme asserts that a boundary holds, the evidence is an attempt to cross it from below — recorded whether or not it succeeded, and repeated on the cadence you set. |
| SEBI CSCRF | Annexure L of the circular dated 20 August 2024 names infrastructure and operating systems in the scope of a VAPT. Where the filing names an empanelled auditor, take the expert-verified or the human-led model. |
| Read 2026-09-08. | |
| A periodic internal or infrastructure assessment | Any of the three delivery models covers the testing itself. What differs between them is whose signature the report carries. |
| Evidence of remediation | Each finding carries through open, fixed, retested and closed, and on this class it closes when the path can no longer be walked from the same starting account. |
A privileged access programme with a tier boundary
SEBI CSCRF
Read 2026-09-08.
A periodic internal or infrastructure assessment
Evidence of remediation
On empanelment
Security Brigade holds the CERT-In empanelment. Under the framework it attaches to the testing rather than to the firm alone, so the expert-verified and the human-led models produce a report that can be filed under it, and the fully autonomous model does not. Which paths were walked, and from which starting privilege, is identical in all three.
Worked example
Every step below is a permission that was granted deliberately by somebody with a good reason at the time.
| Link | Alone | In sequence |
|---|---|---|
| 1 An ordinary account | A domain user with nothing remarkable about it. | It is a member of a group created for a project that finished years ago. |
| 2 A permission on an object | One account permitted to reset another. | The old group holds that permission, so the ordinary account does. |
| 3 An account that is not ordinary | A second user. | It administers workstations, which is what it was created to do. |
| 4 What was left on one of those workstations | Credential material in memory. | It belongs to an account in the privileged tier — and the whole path contains no defect to patch. |
Measured
B-52 and Security Brigade’s expert assessment team were put on the same targets at the same time and everything either produced went into one pooled set, each item counted once. B-52 reached 90–95% of it. Some of what it reached was absent from the team’s own output, which is why the pool is larger than either side alone — and on a class where a single overlooked edge is the whole finding, that is the argument for the expert-verified model rather than against it.
One scan is one application or target and the entry tier is $500. A directory assessment is scoped around a starting privilege and a movement boundary instead, which is a conversation rather than a form.