80% of the Active Directories We Tested Had a Live Path to Domain Admin
I have spent years getting into the Active Directory of regulated Spanish companies: banking, insurance, healthcare, energy, public administration. Serious environments, with a SOC, with EDR, with signed policies, with their annual pentest done by a Big Four. And aggregating what I have seen while running the tool, the number that comes out is uncomfortable:
In close to 80% of those environments there was, at the moment of looking, at least one live path from any domain user to full control of the directory: Domain Admin.
Not "a theoretical vulnerability". A path. A sequence of chainable steps that an attacker with a single compromised user (the help desk one, an intern's, a forgotten service account) can walk all the way to owning the entire domain. And it had almost always been there for months or years, without any scanner flagging it and without any pentest catching it.
About the figure. The 80% is aggregate and anonymized, from my professional experience running this kind of analysis in real environments. I do not publish the total number of environments nor identify any organization. The point is not the exact figure: it is that most mature directories have a live path, and almost no one knows it.
What is interesting is not that these paths exist. It is why nobody sees them. And the answer has to do with four patterns that repeat, with a tool that measures the wrong problem, and with the difference between a photo and a film.
Why doesn't the vulnerability scanner see the path to Domain Admin?
Because none of the four patterns that lead to Domain Admin is a CVE. They are legitimate configurations and valid permissions badly combined, not unpatched software, so the scanner, which looks for vulnerable versions, walks right past them without flagging anything.
This is the mental trap you have to break before going further. When a CISO thinks "Active Directory exposure", they think of patches: the latest Microsoft bulletin, the Netlogon CVE of the moment, the domain controller version. And patching is good. But the real path to the domain almost never goes through a CVE.
It goes through permissions. Through a service account with a password from 2014. Through a certificate template that someone marked "to make it more convenient". Through a delegation option that was turned on so an application would work and nobody touched again. All of that is legitimate configuration from the system's point of view. There is nothing to patch. The vulnerability scanner, designed to find outdated software, looks at this and sees absolutely nothing.
That is why the problem is one of relationships, not versions. Active Directory is a graph: users, groups, computers, GPOs, certificate templates, all connected by permissions and memberships. The path to Domain Admin is a route in that graph. To see it you have to model the entire graph and compute the shortest route, not scan hosts one by one.
When I run the tool against a directory, the first thing I do is exactly that: rebuild the graph and ask "which routes reach Tier 0?". And almost always, underneath an apparently clean environment, one of these four patterns shows up.
Pattern 1. ACL abuse: the permission nobody reviews
An ACL (access control list) defines who can do what over each object in the directory. The problem appears when a poorly watched object holds, over an object that touches Tier 0, a permission that is too powerful: GenericAll (full control) or WriteDACL (the power to rewrite the permission list itself).
If the help desk account has GenericAll over a group that is, in turn, a member of a group with domain administration privileges, the attacker who controls that account needs no exploit. They just use the permission for what the permission allows: they add themselves to the group, or reset the password of a privileged account, or rewrite the ACL to grant themselves more. It is legitimate administration, executed by the wrong person.
These permissions accumulate by sedimentation. A migration from six years ago that granted "temporary" control. A group nested inside another group inside another, until nobody knows the chain ends up touching the domain. A help desk delegation that is too broad. None of these decisions was malicious. Added together, they open the door.
MITRE ATT&CK: T1222: File and Directory Permissions Modification and T1098: Account Manipulation
What I see when I run it: the graph connects a low-privilege account to Tier 0 through two or three ACL edges that no human would relate by reviewing objects separately. The chain is only visible when you see the full graph.
Pattern 2. Kerberoasting: the service password that never expired
Kerberos, the authentication protocol of Active Directory, has a property by design: any authenticated user can request a service ticket (TGS) for any account that has an associated SPN (Service Principal Name), typically service accounts. That ticket is encrypted with the service account's password. The attacker takes it away and tries to crack it offline, on their own machine, without touching the network again.
Here is the detail that makes it so effective: service accounts tend to have old passwords, long in years but not in entropy, that never expire because changing them would break the application that uses them. And many of those accounts are, on top of that, members of privileged groups. A service account with an SPN, a weak password, and high privileges is the perfect combination: roastable, crackable, and powerful.
The attack does not generate suspicious noise. Requesting a TGS is a perfectly normal protocol operation: millions of them happen every day in a healthy domain. The cracking happens elsewhere, where no EDR is looking.
MITRE ATT&CK: T1558.003: Steal or Forge Kerberos Tickets, Kerberoasting
What I see when I run it: the tool lists the accounts with an SPN, marks which ones have privileges that touch Tier 0 and which ones have password policies that make them viable. It is not about cracking everything: it is about knowing which of those accounts, if it falls, hands you the domain.
(If you want the full technical detail of how it works and how it is mitigated, I have a separate Kerberoasting guide.)
Pattern 3. Misconfigured ADCS: anyone forges a Domain Admin certificate
Active Directory Certificate Services (ADCS) is the internal certificate authority. It issues certificates from templates. And a misconfigured template is one of the cleanest and quietest paths to the domain that exists.
The family of flaws is known as ESC (the first one, ESC1, is the canonical one). The idea: if a template lets an unprivileged user request a certificate and lets them specify themselves on whose behalf it is issued (the SAN, Subject Alternative Name), then that user can request a certificate in the name of a domain administrator. With that certificate they authenticate as the administrator. Game over.
There is no malware. There is no exploit. It is the PKI doing exactly what its configuration tells it to do: issue a certificate to whoever asks, with the name they ask for. The flag that enables it is usually turned on for operational convenience ("so users can self-enroll") without understanding that this convenience is equivalent to handing over the keys to the domain.
ADCS is especially dangerous because almost nobody audits it. The security team looks at the directory; the PKI lives in a corner, managed by other people, taken for granted since it was installed.
MITRE ATT&CK: T1649: Steal or Forge Authentication Certificates
What I see when I run it: I enumerate the published templates and review the combination of flags that turns "certificate issuance" into "escalation to Domain Admin". When a dangerous template is published, the path to the domain is a single hop.
Pattern 4. Delegation abuse: the ordinary machine that becomes a bridge to the DC
Kerberos delegation exists for a legitimate use case: that a service acts on behalf of a user against another service (the web application that, on your behalf, queries the database). The problem is how powerful it is when it is poorly scoped. There are three flavors, from worst to "best":
- Unconstrained delegation: the machine can impersonate any user who authenticates against it, including a domain administrator. If an attacker controls that machine and gets a DA to authenticate (sometimes it can be forced), they walk away with their credentials.
- Constrained delegation: scoped to specific services, but if those services are sensitive, the bridge still exists.
- RBCD (Resource-Based Constrained Delegation): the modern variant, where the permission to delegate is configured on the target object. If an attacker can write to the right attribute of a computer, they can grant themselves delegation over it and turn an ordinary computer into a springboard toward the domain controller.
The common pattern: a seemingly irrelevant computer or account acquires the ability to speak on behalf of others, and that ability ends up reaching Tier 0. Again, it is not a CVE. It is a configuration attribute that someone set, or that an attacker can set if they find the right write permission.
MITRE ATT&CK: T1558.003 and the general delegation technique under T1134: Access Token Manipulation
What I see when I run it: the graph marks which computers have delegation, of what type, and whether that delegation, combined with a reachable write permission, opens a path to a DC. Unconstrained delegation on an exposed host is one of the edges that most makes me raise an eyebrow.
The thesis: photo versus film
Put the four patterns together and the real problem emerges. None of them is a CVE → the vulnerability scanner does not see them. And here comes the second piece: the annual pentest does not solve this either, for a structural reason.
A pentest is a photo. It captures the state of the directory the day the auditor looked. An excellent photo, taken by good professionals. But the next day someone creates a service account with a weak password. Within a week, an administrator publishes a certificate template "to speed things up". Within a month, a migration leaves a GenericAll dangling. Three of the four patterns I just described are born from normal operational changes that happen every day, after the auditor has left.
The real risk is not whether you have a path to Domain Admin today. It is how long a path has been live without anyone knowing. And that time, in most environments, is measured in months or years: the window between two annual photos.
What you need is a film: continuous validation of the directory's exposure, recomputing the routes to Tier 0 every time the environment changes. Not to replace the pentest, but to cover the 364 days the pentest does not look at.
The contrast, in one line: an annual pentest covers 1 day out of 365. Continuous validation covers all 365.
Why this is now a compliance problem, not just a technical one
The technical argument was always valid. What is new is that now the regulator backs it, and that changes the conversation in the boardroom.
- DORA, the Regulation (EU) 2022/2554, has applied since 17 January 2025 (source: EIOPA). It requires financial entities to manage ICT risk and run resilience testing based on real threats, which includes technically verifying the compromise paths of the identity directory, not just documenting policies.
- NIS2 broadens the cybersecurity risk-management obligations and accountability to essential sectors, with material penalties for serious non-compliance.
- ENS Alto (Royal Decree 311/2022) requires periodic verification of the security status of systems, and the CCN-CERT increasingly asks for real technical evidence, not just signed policies.
The three rules point to the same thing: it is not enough to have documented controls; you have to demonstrate technically, and in a sustained way, that your directory does not have a live path to full control. An annual photo does not demonstrate "sustained". A film does.
The context that should worry any CISO
These patterns are not academic. They are exactly where modern ransomware comes in.
According to Microsoft, in more than 78% of human-operated cyberattacks the attackers manage to compromise a domain controller, and in more than 35% of cases the device that distributes the ransomware at scale is a domain controller (Microsoft Security Blog, April 2025). The average cost of a ransomware attack reached 9.36 million dollars in 2024, according to the same source.
The domain controller is not just another target. It is the target. And the path to it is, almost always, one of the four patterns above: live, silent, there for months.
How I do it (and the tool is open source)
When I get into an environment, the flow is always the same: I rebuild the directory graph, compute all the routes that end in Tier 0, and classify them by these four patterns. I do not look for CVEs. I look for paths. The question is not "what software is unpatched?" but "what sequence of permissions, tickets, certificates, and delegations turns any user into the owner of the domain?".
The tool I use for this is ADscan, and it is open source: the link is in the comments of the LinkedIn post that brought you here, and also on GitHub. You can download it, point it at your own lab environment, and see for yourself which paths show up. That is the point of publishing this: the pattern is impossible to fake because it is real; the tool that measures it is in your hands.
What ADscan does, in one sentence: it continuously and automatically detects all the paths through which an attacker could take full control of the directory, and leaves that finding mapped to DORA, NIS2, and ENS for the supervisor.
Photo versus film. That is all that changes. But it changes everything.
Methodological note. This article describes patterns, not step-by-step exploitation procedures. The goal is for a CISO to understand why their scanner does not see the problem and why the annual pentest does not close it, not to provide an offensive recipe. The MITRE ATT&CK references link the public documentation of each technique for anyone who wants to go deeper.