The Active Directory Attack Surface Explained

You already have a rough idea of "attack surface" from anywhere else in security: the sum of all the ways in. For a web server it is the open ports and the exposed endpoints. The instinct is to picture the same thing for Active Directory, a list of services to firewall and patches to apply. That instinct is wrong for AD, and getting it right is the difference between defending the directory and defending the wrong thing entirely.

The Active Directory attack surface is made of identity and configuration, not network exposure. It is the accounts that exist, the permissions they hold, the protocols they authenticate with, and the trusts that connect them. The directory exposes all of this not by accident but by being useful: every one of those things exists because someone needed it. The surface is the cost of the directory doing its job.

The categories of the surface

It helps to break the surface into the categories an attacker actually works through. There are five worth holding in mind, and the rest of the course is a tour through them.

None of these categories is optional to the directory; each exists because the directory has to do real work. That is the theme to carry through all five: this is not surface you can eliminate, it is surface you have to understand, constrain, and watch. An attacker needs only one usable weakness in any one category. You have to account for all of them.

Accounts are the first category. Every user, service account, and computer account is a potential foothold or target. Service accounts matter most, because they often have a service principal name that makes them reachable for Kerberoasting and passwords that nobody rotates. Stale accounts, accounts that can be roasted without even authenticating, and accounts with weak passwords all widen the surface, and a typical domain has accumulated thousands of them.

It is worth being precise about why accounts are surface and not just inventory. Every account is a credential that can be stolen, and every account carries some access. Service accounts are the sharpest case: they frequently run with more rights than they need, their passwords are set once and forgotten, and the service principal name that makes them reachable is exactly what an attacker queries for.

Some accounts can even have their credentials attacked without the attacker authenticating at all, simply because a setting left pre-authentication disabled. Each of those is a different doorway, and they are everywhere.

Permissions are the second, and the deepest. Active Directory is a web of rights: who belongs to which group, what each group can do, who has been granted the ability to modify whom. Delegation rights, which let one account act for another, live here too. Permissions are where the most dangerous surface hides, because a single over-broad grant, made years ago for a reason no one remembers, can be the whole path to Domain Admin.

The permissions that matter are a specific, named set, and you will learn to recognize them: the right to take full control of an object, to rewrite its security settings, to reset its password, or to write one sensitive attribute.

Granted on the wrong object, any of these turns an ordinary account into what is sometimes called a shadow admin, an account in no privileged group that can still reach privilege through a permission. Because shadow admins are invisible to anyone who only checks group membership, they are among the most reliable paths attackers find.

Protocols are the third. Kerberos and the older NTLM are how the network authenticates, and both carry exposure: the encryption choices in a Kerberos ticket, the fallback to NTLM that attackers force, the way tickets can be requested and reused. You do not turn these off, so they are permanent surface you manage rather than remove.

Two protocol weaknesses recur enough to name now. Kerberos can be pushed to use the weak RC4 cipher, which is what makes a roasted ticket crackable, so the cipher in use is itself surface. And NTLM can often be relayed: an attacker who can make a machine authenticate to them can forward that authentication somewhere else and act as the machine. Neither is a bug to patch; both are behaviors to constrain and watch.

Trusts and structure are the fourth. Domains, forests, and the trust relationships between them extend reach by design, so a compromise in one place can travel to another. And the fifth category is everything bolted on or left on: Active Directory Certificate Services, ADFS, and legacy features like the print spooler, each of which adds its own well-documented abuses.

Trusts deserve a second look, because they quietly enlarge the surface beyond the domain you are thinking about. A trust says one domain will accept identities vouched for by another, so a foothold in a weakly defended domain can become reach into a strong one. The forest, not the domain, is the real security boundary, and a surprising number of organizations defend a single domain while leaving the wider forest exposed.

The bolted-on services compound this. Certificate Services in particular has become one of the richest escalation surfaces in modern AD, often because it was switched on for one application and never hardened.

The surface is really a graph

Listing categories is useful, but it misses the thing that makes AD security hard and interesting. The real attack surface is not a list, it is a graph: a web of relationships where the question is always who can act on whom.

This graph view is the single most useful mental model in AD security, and it is how attackers think. They do not look at your domain as a list of accounts and ask which is vulnerable. They look at it as a network of edges, each edge a right one object has over another, and they search for a path: a chain of edges leading from somewhere they already stand to somewhere they want to be, usually Domain Admins.

What they are walking toward has a name worth knowing now: tier zero, the small set of assets that effectively control the domain.

The domain controllers, the most privileged groups, the accounts that manage them, and the krbtgt account that signs every Kerberos ticket all sit at tier zero. Almost every path an attacker traces is, in the end, a route to a tier-zero asset, because reaching tier zero is reaching control of everything. Knowing which of your assets are tier zero tells you which edges of the graph matter most.

Each individual edge in that chain is legitimate. The helpdesk operator can reset passwords because that is their job. The service account is in a group because an application needed it. No single permission looks wrong. The danger is the path the permissions form together, which no one designed and no one is looking at. This is exactly why the free tools that map these paths, which you will meet later, are so powerful for attacker and defender alike: they turn the invisible graph into a picture.

That cuts both ways, and it is one of the more hopeful facts in AD security. The same map that helps an attacker find a path helps a defender find and cut it first. A great deal of defending Active Directory is simply seeing your own graph before an attacker does, then removing the edges that create the dangerous paths. You cannot defend a surface you cannot see, so the first real act of defense is making it visible.

Why the surface is so hard to see

The reason this surface grows unchecked is that it is nearly invisible in the tools used to run the directory day to day. The standard administrative views show you objects one at a time: here is a user, here are its group memberships, here are the permissions on this object. They do not show you the chains. To see that the helpdesk operator can, through three hops, reach Domain Admins, you have to assemble the relationships across many objects, which no human does by clicking through them.

And the few people who could reason about it, the senior administrators, are usually the busiest people in the organization, with no time to trace permission chains by hand. So the chains sit there, unexamined, for years. The attacker, by contrast, has all the time in the world and a tool that draws the graph in seconds. That asymmetry, defenders who cannot see the surface against attackers who can, is one this course sets out to close.

And it only ever grows. Every new service account, every delegation granted for a project, every trust added after a merger, every permission given and never taken back, adds an edge to the graph. Additions are easy and feel safe; removals are risky, because no one is certain what will break. So the surface accumulates, year after year, until the domain is a dense web of rights that no current employee fully understands. That accumulation is the attacker's opportunity and the defender's starting problem.

The causes are mundane and constant. A merger bolts two directories together with a broad trust. A project needs a service account in a hurry and it is given more rights than it strictly requires. An administrator leaves and their permissions are never revoked. A vendor's installer asks for delegation and gets it. None of these is negligence exactly; each is a reasonable decision under time pressure. The surface is the sediment those decisions leave behind.

The practical answer, which the course returns to, is that you have to look at your own directory the way an attacker does: map the graph, find the dangerous paths, and reduce them deliberately, because nothing else will. For now, hold the shift in mental model, because it is the one this whole sub exists to give you. The AD attack surface is not ports and patches. It is identities, permissions, and the paths between them.

You now know what the surface is made of and why it hides. The next sub puts it in motion: the most common paths attackers actually walk through this surface, the small set of routes that show up in breach after breach, and which become the modules of this course.