The Admins You Didn't Count

Ask most Active Directory (AD) teams how they control privileged access and you will hear a good answer: “We keep Domain Admins small.” On a recent internal penetration test at a global manufacturer, Domain Admins had ten members. Tight, on paper.

It did not matter. We reached full domain control through an account that was not in Domain Admins at all, and we were far from the only path. If your privileged-access story starts and ends with the Domain Admins group, this article is about everything that story leaves out.

The short version: Tier-0 is a set of rights, not a group you can list. Auditing membership tells you who holds one crown. It says nothing about everyone else who can pick the lock.

Domain Admins is not the boundary you think it is

Tier-0 is the label for the accounts and systems that can control the identity platform itself: domain controllers, the directory, the accounts that administer them. Compromise anything at Tier-0 and you own the domain. The goal of a tiering model is to keep that set small, known, and heavily defended.

The trap is treating Tier-0 and Domain Admins as the same list. They are not. The built-in Administrators group in a domain quietly holds directory-replication rights and ownership over the domain, and it is local administrator on every domain controller. By any honest definition it is Tier-0. Yet it is a different group from Domain Admins, so an audit that only asks “who is in Domain Admins?” never sees it.

That gap is not theoretical. It is where the real privileged access tends to hide, because it is the access nobody is looking at.

The group named after its own loophole

On this engagement, the account we rode to domain control was not in Domain Admins. It reached built-in Administrators through nesting.

Active Directory lets groups contain other groups. Rights flow down the chain, so an account can end up with power it was never directly granted, inherited through a stack of memberships several layers deep. This account inherited rights from more than sixty groups. One of them, a nested group whose name effectively announced the loophole (it described itself as the admins who were not Domain Admins), landed the account inside built-in Administrators.

From there the math was ugly. Through that inherited membership, the account held write or ownership rights over roughly nineteen thousand directory objects, full control over several thousand more, and directory-replication rights over the domain. It could perform a DCSync: ask a domain controller to hand over every account’s password hash, using a supported replication feature that was never meant to sit with an account like this one. (MITRE tracks it as T1003.006.)

None of that showed up in a Domain Admins membership check. The account looked like a mid-tier administrator. It was Tier-0 in everything but the label.

Service accounts wearing crowns

Membership auditing failed a second way, and this one was hiding in plain sight inside Domain Admins.

Of those ten Domain Admins, five were not people. They were service accounts: automation identities for a vulnerability scanner, a backup product, a systems-management platform, and an integration tool. Each had a password set never to expire.

A service account in Domain Admins is a domain-takeover path with a long fuse. Its password sits in a configuration file, a scheduled task, or a product’s database, often readable by more people than anyone tracks, and it does not rotate. Compromise the product and you have a Domain Admin. Five of them multiply the odds.

The pattern ran deeper than the top group. A single SQL service account was registered across roughly twenty-eight database servers, so cracking it once would have exposed all of them. A human user’s account was carrying a service identity (a service principal name, or SPN), which makes the account Kerberoastable: an attacker can request a ticket for it and crack the account’s password offline. Human accounts should not carry service identities, and one service account should not be the master key to an entire class of servers.

DCSync handed out more widely than anyone meant

Directory replication is the right that makes DCSync possible, and it is supposed to belong to domain controllers and to a small number of justified, monitored sync accounts. On this engagement it had been delegated more broadly than that: to several identity-sync accounts and to a custom group, each of which represented another way to dump every hash in the domain.

Replication rights are easy to grant and easy to forget. A vendor’s setup guide asks for them. An integration needs them temporarily. They get added and never reviewed. Every one of those grants is a Tier-0 capability, whether or not the account holding it is anywhere near the Domain Admins group.

Why this stays hidden

Every one of these gaps survives for the same reason: the audit that is easy to run is the wrong audit.

“Who is in Domain Admins?” is a question anyone can answer in ten seconds from a single group. It produces a short, clean list and a feeling of control. “Who can reach Tier-0 rights by any path?” is a question you cannot answer by looking at one group, or ten. It means resolving nested memberships, access-control entries, and delegated rights across the whole directory into an actual reachability graph. That takes tooling and expertise, so it rarely gets done, and the easy metric stands in for the hard one.

The organizational pressures push the same way. A vendor’s install guide asks for replication rights or a spot in a privileged group, the integration will not work without it, and the request is granted under deadline. The access is never revisited, because nothing breaks and nobody owns the review. Group nesting grows the way a filing cabinet grows: one reasonable addition at a time, until no single person can tell you what is inside.

The result is an environment that passes the audit it runs and fails the audit an attacker runs. The only way to close that gap is to run the attacker’s audit yourself, on purpose, before someone else runs it for free.

Running it on purpose is the part worth being careful about. Resolving effective rights across a production directory means touching the systems your business runs on, and mapping a path to Domain Admin is not the same as walking it. On this engagement we proved the privilege existed and stopped well short of the places where proving it further would have cost the client something, which is a judgment call we write about separately. Ask anyone testing your directory where their stop conditions are before they start.

How to actually audit Tier-0

The fix is to stop auditing membership and start auditing effective rights. The question is not “who is in the privileged groups?” It is “who can, by any path, control a domain controller or replicate the directory?” Those are different lists, and the second one is the one that matters.

• Map effective access, not group rosters. Attack-path tooling built for AD, such as BloodHound, resolves nested groups and access-control entries into the real reachability graph. It will show you the account that is Tier-0 through six layers of nesting that no eyeball audit would catch. Run it as your own red team would.
• Collapse the group sprawl. Remove standing membership of built-in Administrators, and of custom admin groups like the one described here, from any account that is not deliberately Tier-0. Nesting that grants privilege by accident is the root cause; prune it.
• Get automation out of Domain Admins. Run service and automation accounts as Group Managed Service Accounts (gMSAs), which rotate their own passwords and are scoped to specific hosts. Give each one the least privilege its job needs instead of the most privilege that was easy.
• Fix the account hygiene underneath. Replace shared service accounts with per-instance identities. Remove service principal names from human accounts. Put genuine Tier-0 accounts into the Protected Users group and mark them sensitive so their credentials cannot be delegated.
• Watch replication. Minimize who holds directory-replication rights, and alert on DCSync-style replication from anything that is not a domain controller. Microsoft’s privileged access model is the design to build toward, and the CIS Controls give a framework for the account-management practices around it.

There is a satisfying irony in this client’s numbers worth ending on. When we later audited their passwords, not one of the ten Domain Admin accounts could be cracked. Their most-guarded credentials were genuinely strong. The compromise did not come through the front door they were watching. It came through the doors they never counted as doors.

That is the lesson. A small Domain Admins group is necessary and not sufficient. If you have never mapped who holds Tier-0 rights by every path, not just by membership, you do not actually know how large your privileged tier is. This engagement started from a single exposed credential and turned into total control of the forest precisely because the privilege underneath was wider than anyone had counted.

If you want that map of your own environment, drawn the way an attacker would draw it, that is what an internal penetration test gives you. Get in touch and we will show you who your real admins are.