Active Directory as an Attack Surface

You already know the parts of Active Directory. A domain, a few controllers, service accounts, groups, and the trust that lets a machine accept who the directory says you are. What this sub asks you to do is look at those familiar parts from the attacker's side of the table, because the same design that makes the directory work is the thing that lets one foothold spread.

Trust is what travels

Start with what a domain actually is. Every account, computer, and group lives in one directory, and every joined machine trusts the controllers to vouch for who someone is.

Joined to the domain means more than reachable on the network. It means the machine has agreed to accept the controllers' word about identity, to honor the tickets they sign, and to apply the policy they push. That agreement is the convenience and the risk at once, because anything that can speak as the directory inherits all of it.

When you log on, the controller hands you a ticket that other machines accept without rechecking your password. That is the whole point of single sign-on. It also means a ticket stolen on one machine is honored across the domain.

The trust does not stop where it was issued. It travels, by design, to every service that trusts the same directory.

That ticket is worth understanding, because two kinds of it drive most of the attacks in this course. The ticket-granting ticket is what you get when you first log on. A service ticket is what you get to reach one specific service, and it is encrypted with that service account's key.

That second detail is the one attackers love. Ask the directory for a service ticket and you receive something encrypted with the service account's password hash. Take it away, crack it offline, and nothing on the controller records the cracking. The request looked routine. The attack happened on the attacker's own hardware, in their own time.

The rights that reach the center

A domain has a handful of accounts that can change anything: Domain Admins, the accounts that can replicate the directory, the controllers themselves. Those are watched.

Around that center sits a much larger ring of accounts that are not labeled "admin" but hold one right that reaches inward. An account that can reset a privileged user's password. A service whose host can be coerced. An operator who can write a single attribute on a sensitive object.

Attackers do not go for the obvious admin. They go for the unglamorous account with one delegated right that nobody reviewed, because that right is a quiet step toward the center.

Picture the accounts that actually carry that risk. A help-desk operator group whose members can write attributes on user objects. A service account with an old password and a service principal name still attached. A legacy account left without Kerberos pre-authentication because something broke years ago and turning it off made the error go away.

None of those looks dangerous in the admin console. Each is a documented step in a real attack chain, and you almost certainly have one of them in your domain right now.

Here is the reframe if you administer AD day to day. Everything you configured for convenience is reachable by an attacker too, and each feature has a hostile twin.

You do not need new knowledge to defend. You need to look at the configuration you already understand and ask, of each feature, who else can reach this and what it would look like if they did.

Read that list again as a defender. You are not being asked to rip out single sign-on or delegation. You are being asked to know which accounts can use each one, and to notice when the use does not match the account. That is a detection and a review, not a redesign.

Why a domain is not just another server

It is worth saying plainly why a domain escalates the way no single server does. Compromise a standalone server and you own that server. Compromise the directory that authenticates a thousand servers and you own all of them at once, because they all defer to it.

That is the multiplier. The directory is not one more system on the network. It is the system the others trust to decide who is who.

An attacker who controls it does not need to break into anything else. The directory will let them in, correctly, as whoever they choose to be.

This is also why detection has to live close to the directory. The controllers see every authentication and every change, while a sensor on one file server sees only that file server. The evidence that matters is concentrated where the trust is, and that is where this course points you.

The chain, not the breach

The reason one workstation reaches Domain Admin is that the steps chain. Each one is small, and each looks in isolation like something that happens legitimately a hundred times a day.

It is the sequence that is hostile, and it sits on every defender's whiteboard in the same four stages.

Recon comes first because the attacker lands blind. They ask the directory to describe itself, and it answers, because answering queries is its job and any authenticated user may ask.

This is the honest gap in the course. Native Windows does not log the directory queries an attacker runs to map the domain, so recon is the one stage you harden against rather than detect. You will see why, and what to do instead, in the recon module.

Credential access turns that map into keys. A service account with a weak password and a registered service principal name can have its ticket requested by anyone and cracked offline, with nothing logged on the cracking side.

The attacker is not breaking cryptography here. They are collecting credentials the environment handed out and then failed to protect, which is why a strong service-account password and a modern cipher do more for you than any single detection rule.

Escalation uses the keys to gain rights the foothold never had: abusing a delegation, writing a service principal name onto a target, or on Server 2025 abusing the new managed service account migration to inherit a privileged identity.

What unites these is that each is a small, authorized-looking write or request. The attacker is not exploiting a flaw so much as using a permission they should never have held, which is why the fix is usually a permission to remove, not a patch to apply.

Dominance is the end state. The attacker replicates the directory to pull every hash, forges a ticket that never expires, or has the certificate authority issue them a certificate in an admin's name. There is nothing left to escalate to.

Drawn as a line, the stages look orderly, and the simplest intrusions are. Real ones branch. An attacker roasts one account to reach a second, uses the second to write a delegation right, uses that to replicate.

The value of the four stages is not that attacks march through them in order. It is that every action belongs to one of them, and each stage has a small set of techniques with a small set of telemetry signatures you can learn.

There is one more reason the end state matters. Once an attacker reaches dominance, eviction is not a password reset. A forged ticket survives a password change, and a stolen krbtgt key means every ticket in the domain is suspect.

Recovery becomes rebuilding trust, measured in days and outages rather than minutes. Catching the chain early is the difference between an incident and a rebuild.

Patching is not defending

Here is the trap that catches well-run teams. The controllers are patched, the scanner is green, and the conclusion is that AD is handled. Then a Kerberoast against a service account with a 2019 password walks straight past all of it.

Nothing in that chain was a vulnerability in the patch sense. The service account was configured as intended. The delegation was assigned on purpose. Replication is how the directory is meant to work.

It helps to hold two words apart. A vulnerability is a flaw in code that a patch repairs. A misconfiguration is a setting working exactly as written, used by someone it was never meant to serve. Almost everything in this course is the second kind, and scanners are built to find the first.

Two recent additions make the point. CVE-2026-25177 is a real patchable bug, but the technique it helps, writing a service principal name onto an account you have rights over, is mostly a configuration problem. BadSuccessor, the Server 2025 managed service account abuse, is not a memory bug at all, it is a permissions design that lets a low-privileged write inherit a high-privileged identity. You detect both. You do not patch your way out of either.

So the question is, would you see it

The good news is that the trust fabric is noisy. The directory cannot grant a ticket, modify an object, add a member to a privileged group, or replicate to a peer without writing it down, provided the auditing is on.

That last clause carries weight. Several of the most important records are off by default, and a domain can look quiet simply because nobody turned the auditing on. Confirming it is one of the first things you do, and part of the next sub.

Every step that makes AD dangerous also makes it detectable, because every step has to touch the directory, and the directory logs. So the question this course keeps asking is not "is my domain patched" but "would I see it."

Each step has a specific record. The roast is a service-ticket request carrying a weak cipher. The replication is an object-access event that should only ever come from a controller. The certificate abuse is an issuance where the requester and the subject do not match. You will learn to read each of these directly off the Windows event, before any SIEM is involved.

Would you see the service ticket requested with the weak cipher. Would you see the replication that should only ever come from a controller. Would you see the certificate issued with someone else's name in the subject. By the end you will, in the events every domain already produces. The next sub lays out exactly where those events live.