Active Directory: Notes from Someone Who Just Got Schooled

I came into Active Directory thinking I understood it.

I had the conceptual picture. Domains, domain controllers, forests, trusts, Kerberos, LDAP. I’d read enough to feel oriented. I’d taken notes. I had a rough map.

Then I started actually attacking AD environments — HTB machines, practice labs, the ProLab machines — and the map turned out to be much less useful than I thought.

Understanding something conceptually and being able to move through it quickly under pressure are different skills. I’m still building the second one.

Why AD Is Still Everywhere

There’s a version of this post that begins “despite decades of alternatives…” and talks about why enterprise environments haven’t migrated to more modern identity systems.

I’ll skip it.

Active Directory is everywhere because it works, because it’s deeply integrated with every piece of enterprise software built in the last twenty years, because migration costs are enormous, and because “if it ain’t broke” is a complete sentence to most IT leaders. The security problems are well-documented and the environment persists anyway. This is not puzzling if you’ve worked in large organizations. It’s completely predictable.

From an offensive perspective: there will be AD to attack for the foreseeable future.

What I Actually Spent Time On

Kerberoasting first, because it was the first thing I kept seeing in writeups and I wanted to understand it mechanically, not just “run this tool.”

The short version: in AD, service accounts are given a service principal name, an SPN. Any authenticated domain user can request a Kerberos ticket for any service — this is how Kerberos is supposed to work. That ticket is encrypted with the service account’s password hash. You request the ticket, take it offline, crack it with hashcat.

The attack works because: service account passwords are frequently old, set once and never rotated because “it would break things”; the ticket request is a legitimate operation so it doesn’t trip alerts by default; and many service accounts have more privileges than they need, provisioned in a hurry years ago and never revisited.

Running Rubeus for the first time and watching it enumerate SPNs across a domain was a kind of revelation. Read operation. Completely legitimate. The number of service accounts with crackable tickets in a typical AD environment is more than you’d expect.

BloodHound Changed How I Think About Graphs

BloodHound is not a new tool. It’s been around since 2016. I knew what it did before I used it. Graphs the AD environment, shows attack paths from any node to Domain Admin.

Using it is different from knowing what it does.

The first time I ran SharpHound against a practice environment and fed the data into BloodHound, I sat there for a while just zooming in and out of the graph. The shortest path to DA from a compromised user account I had. The number of hops. The intermediate nodes — a group membership here, a constrained delegation there, a local admin right on a machine that had sessions from a privileged account.

The thing that hit me: each one of those relationships looked reasonable in isolation. User A is in Group B because that’s the group IT uses for this software. Group B has local admin on Server C because that server needs to be managed. Server C has a session from a privileged account because someone logged in this week and didn’t disconnect. None of those individual decisions were bad decisions.

The attack path is the combination.

DCSync and Why Domain Admin Is Not the End

I’ll be honest: when I first got to Domain Admin on a lab box, I felt done. Like the game was over.

Then I kept reading and realized I was thinking about it wrong.

DCSync illustrates this. An account with certain AD rights — Replicating Directory Changes, specifically — can mimic a domain controller and request replication of password hashes from the DC. Without logging in to the DC. Without touching LSASS. Just using legitimate replication protocol.

The interesting part isn’t that you can dump hashes once you’re DA. It’s that the rights to replicate directory changes don’t require DA. There are accounts with those rights that aren’t DA, sometimes because someone delegated replication rights for a specific purpose and didn’t think about the implications.

The goal isn’t always “get DA.” Sometimes getting DA is noisier and harder than finding an account with the specific rights you actually need.

What I’m Still Working On

Kerberos delegation. Constrained, unconstrained, resource-based constrained. I understand the concepts. I’m not fast with them yet. Under time pressure, in a machine I haven’t mapped completely, I still have to stop and think through the logic more carefully than I’d like.

Certificate services. AD CS is a deep rabbit hole — ESC1 through ESC12 and counting, Certipy making it more accessible but the underlying protocol still being something I want to understand more thoroughly.

Trusts. Forest trusts, domain trusts, external trusts. I’ve read about trust abuse but haven’t had enough practice with it to be comfortable.

The honest answer is that AD is big enough that I expect to keep finding new things to learn in it for years. Which is part of why it’s still relevant. Both to defenders who have to manage it and to me.

One Thing I Keep Saying to Myself

The tool tells you what’s there. The knowledge tells you what it means.

BloodHound shows me the path. I have to understand why it’s a path. Rubeus gets me the ticket. I have to know what to do with it. Impacket runs the attack. I have to know when to use it and when not to.

The tools are not the skill. I spent time confusing those two things. I’m trying not to anymore.