Eleven attack paths to domain admin, closed by four changes

Twenty years of acquisitions had produced one forest, six domains and a delegation model nobody fully understood. External testing was clean. Internal testing had never been attempted at scale, because nobody could scope it.

• Privilege had accumulated with nobody removing any

  Service accounts from decommissioned systems still held delegated rights. Every acquisition added a trust and none had ever been retired.

• Findings without paths were not actionable

  Previous audits produced hundreds of individual misconfigurations with no indication of which ones chained. The list was accurate, unranked and consequently untouched for two years.

• Site networks were flat behind the perimeter

  A warehouse floor terminal and the domain controller sat in the same broadcast domain at several sites, so the blast radius of any single compromised endpoint was the entire site.

• No safe way to test internally

  Warehouse operations run continuously. Anything that risked locking accounts or disrupting a scanner terminal was politically impossible to schedule.

The engagement was framed around reachability rather than compliance: not which settings deviate from a baseline, but which sequences of them get an attacker from a warehouse laptop to a domain controller.

1. 1

   Graph the estate before testing it

   Read-only, 2 days

   Users, groups, machines, ACLs, delegations, trusts, GPO links and local admin membership were collected read-only across six domains and rendered as a single reachability graph.

2. 2

   Attack path enumeration

   11 paths found

   Every route from a standard user context to Tier 0 was enumerated, then each hop was validated in a controlled window: Kerberoastable service accounts, unconstrained delegation, ACL abuse and certificate template misconfiguration among them.

3. 3

   Choke point analysis

   4 changes

   Rather than ranking the misconfigurations, the graph was analysed for nodes that many paths depend on. Four changes sat on all eleven paths, which turned a two-year backlog into a two-sprint plan.

4. 4

   Lockout-safe credential testing

   0 lockouts

   Password attacks ran under the domain lockout policy with a deliberate margin, and account state was checked before every attempt. No production account was locked during the engagement.

5. 5

   Continuous re-verification of closed paths

   Monthly

   After remediation the paths were replayed monthly. Two reopened within a quarter (one from a new service account, one from a restored group membership) and both were caught before the next audit.

Measured from the first internal assessment through two quarters of remediation and re-verification.

11 → 0

Paths to domain adminVerified by replay after remediation

4

Changes that closed all of themChoke points shared across every path

0

Accounts locked during testingLockout-aware credential testing

340

Stale privileged rights removedService accounts from decommissioned systems

2

Paths that reopened, caught earlyBoth found by monthly replay, not by audit

6 weeks

From first graph to zero pathsAgainst a two-year-old untouched backlog

• Rank by reachability, not by severity

  The two-year backlog was not an engineering failure; it was an ordering failure. Nobody could tell which of 400 findings mattered. Eleven paths and four changes was a plan someone could actually commit to.

• Choke points beat severity every time

  None of the four blocking changes was individually the highest-severity finding in the report. They were the ones every path ran through.

• Closed is a state that decays

  Two paths reopened within a quarter through routine administration. Without monthly replay, both would have been discovered by the next annual audit, or by someone else.

• Operational safety is a testing requirement

  The engagement was only possible because credential testing respected the lockout policy. The constraint that had blocked internal testing for years was solvable in configuration.