Active Directory is still the most travelled road to full control of a domain. Not because it is inherently insecure, but because years of delegations, inherited permissions, certificate templates left open and forgotten service accounts create paths that lead from any ordinary user all the way to Domain Admin, the account that has complete control of the domain. An attacker who gains an internal foothold rarely exploits a software vulnerability: they climb identity.

The market has answered with dedicated tools — PingCastle, Purple Knight and the like — that photograph AD posture. They are capable tools, but they live in isolation: they run once, produce a separate report, and know nothing about the external exposure or the internal surface the customer has already mapped elsewhere. For anyone delivering security as a service, the result is one more silo to manage.

RECON approaches the problem from a different angle. The Active Directory assessment is not a separate product: it is an additional capability of the same platform — and the same probe — that already runs the customer's external and internal scanning. One probe, one correlated view, a single contract.

RECON's answer is designed precisely to get past that conversation. No agent is installed: not on the domain controllers, not on the endpoints. The collector performs a single authenticated read of the directory, with only the rights of an ordinary domain user, exactly as a posture tool would — it reads, it never writes.

The administrator credential, when it is needed at all, is used exactly once to mint a dedicated read-only collector account, then destroyed (crypto-shredded): it never lands on disk, in a log or in a permanent field. Alternatively, the organisation can supply a read-only account directly, without ever handing over a privileged credential. All the dangerous analysis — Tier-0, attack paths, certificate abuse, score computation — then happens server-side, on the collected data, without ever touching the live domain again. The invariant is explicit and non-negotiable: detect, never exploit.

For a partner this translates into a concrete commercial fact: the technical obstacle that usually slows the signature — "I don't want privileged software on my DCs" — simply never comes up.

The first level is an identity inventory: every user, group, computer, organisational unit and GPO the directory exposes, collected into a filterable list. In a mid-sized organisation this easily runs to over a thousand objects. What makes them legible are the markers: privileged and Tier-0 objects are highlighted. Tier-0 is the set of the most powerful accounts and systems in the domain — the Domain Admins, the domain controllers and anything that can control them; whoever owns Tier-0 effectively owns the whole domain, which is why it is the first perimeter to defend. Alongside the objects sit the risk flags — a misplaced adminCount=1 (the trace that an account is, or once was, privileged), a last logon that is too old, a sensitive group exposed more than it should be.

And all of this condenses into a single number: a domain posture grade, from A to F (from 100 downward). The security team can open it and see the findings weighted behind the number; the board can read it with no technical mediation. It is the difference between handing the customer a wall of findings and handing them a sentence: here is how exposed your domain is, and here is what to fix first.

An example helps convey the shape of the result. It is not unusual for a single element — a computer account, a service account, a badly delegated group — to turn out to be the passage point of a dozen different paths, each with a confidence score and an estimated effort. In a case like that the console does not merely say "you have a problem": it points to the single node to guard in order to shut down the largest number of routes in one move. And every finding carries its own remediation: for a dangerous ACL on a domain controller object, for instance, the precise instruction is to remove the Write/AllExtendedRights/AddKeyCredentialLink rights held by non-Tier-0 principals.

The same principle applies to Certificate Services, the internal PKI, among the most abused routes to Domain Admin: RECON reads templates and certification authorities and classifies the known misconfigurations of the public-key infrastructure. "ESC" stands for Escalation: it is the label under which the security community catalogues AD CS abuse techniques, a family numbered from ESC1 to ESC16 in which each entry describes a different way a misconfigured PKI grants an ordinary user privileges they should not have. ESC1, for example, is the case where a certificate template lets the requester specify the identity to write into the certificate themselves and allows its use for authentication: in practice any ordinary user can have a certificate issued that makes them pass for a far more powerful account.

RECON classifies each of these entries with a rare honesty — confirmed, candidate or detect-only. A confirmed ESC1 means a non-privileged user can already obtain that certificate; a candidate stays marked as such until the abuse is proven. The customer never reads an inflated "critical" that no one demonstrated — and this honesty, counter-intuitively, is one of the most solid sales arguments you can bring.

For the partner it is not "another tool to sell": it is one more capability on infrastructure that is already installed, opening a recurring service, shortening the sale and making the value measurable at every scan.

The next steps are concrete: a guided walkthrough of the assessment on the customer's own domain; deploying the probe in a single network to see internal scanning, OT/ICS and Active Directory in one pass; and a review of the live paths to Domain Admin, with the chokepoint to break called out first.

Learn more: [email protected] · orizon.one/services/recon