Module 19 of 22 — The domain is the kingdom
Active Directory (AD) is not just a directory — it's the nerve center of every enterprise Windows network. It stores who you are, what you can do, what computers exist, what groups matter, and what trust relationships bridge domains. Compromise AD, and you don't just own one computer — you own the entire organization. Every account, every server, every secret.
Why this matters: In a typical enterprise, 95% of the valuable data lives in AD-controlled systems. Email, file shares, databases, source code, customer records — all gated by AD authentication. One Domain Admin credential is the master key to the entire kingdom.
"Active Directory is the keys to the kingdom."
Translation: AD doesn't just store passwords — it decides who can log in, access files, run commands, and manage systems. If an attacker gets Domain Admin, every door in the organization unlocks. For defenders, this means AD must be treated as a crown jewel: hardened, monitored, segmented, and backed by privileged access management. For red teamers, AD is rarely the first step, but it is almost always the last.
🔴 Red: Your objective in most internal assessments is to reach Domain Admin or equivalent. Everything before that is reconnaissance and escalation.
🔵 Blue: Assume breach. Monitor privileged groups, DCSync attempts, anomalous LDAP queries, and krbtgt password rotation status.
AD is the personnel file cabinet, the building access control, and the communication network — all in one. If you get the master key (Domain Admin), you can open any door, read any file, and impersonate any employee. This module teaches you to map the castle before you storm it, pick the locks with Kerberos, and forge credentials that never expire.
The castle has multiple towers (domains), connected by bridges (trusts). Each tower has guards (ACLs) and secret handshakes (Kerberos). Learn the architecture, and you can walk anywhere.
This module assumes you understand these concepts from earlier modules:
DNS, LDAP ports, SMB, and RPC. AD is built on these protocols. You cannot attack what you cannot reach.
Local privilege escalation is often the entry point. You escalate from local SYSTEM to domain context.
Pass-the-hash, pass-the-ticket, and WMI/PSExec. Moving between machines is lateral movement; AD is the map.
Command and control infrastructure. Your beacon needs to communicate; AD credentials let you blend in.
The full attack lifecycle. AD compromise is often the "Actions on Objectives" phase — the endgame.
A Forest is the top-level container in Active Directory. It represents the complete security boundary for an organization. All domains in a forest share a common schema, global catalog, and transitive trust relationships.
The root. Contains one or more domains. Shares a common schema and global catalog. The ultimate security boundary.
The top-level security boundary within a forest. Contains all users, computers, and groups. Trusts other domains.
Child domain. Inherits forest-wide settings. Has a two-way transitive trust with the parent.
External trust between forests. May be one-way or two-way. Selective authentication is rare — usually domain-wide.
Container for organizing objects. Policies apply at OU level. Not a security boundary — just administration.
The actual object. Has a SID, password, group memberships, and ACLs. The target.
The forest is the only true security boundary in AD. Domain Admins in one domain can escalate to Enterprise Admins (forest-wide) through SID History abuse or trust exploitation. If you compromise any domain in a forest, you are one step from the entire forest. Never assume a child domain is "safe."
A hierarchy of domains sharing a contiguous DNS namespace:
All domains in a tree have automatic two-way transitive trusts.
| Type | Direction | Transitive |
|---|---|---|
| Parent-Child | Two-way | Yes |
| Tree-Root | Two-way | Yes |
| External | One or Two-way | No |
| Forest | One or Two-way | Yes |
| Shortcut | One or Two-way | Yes |
External trusts are often created for mergers, partnerships, or vendor access. They are rarely reviewed, frequently overprivileged, and commonly forgotten. An external trust from corp.example.com to acquired.com means: if you own acquired.com, you can attack corp.example.com. Trust is transitive by default. A chain of trusts is a chain of compromise.
"You don't attack AD, you abuse trust."
Translation: Active Directory is designed around trust relationships — between domains, forests, users, groups, computers, and services. The protocol isn't usually broken; the configuration is. Kerberos, delegation, and ACLs are all legitimate features that become weapons when misconfigured. A red teamer's job is to find the trust relationship that shouldn't exist and walk through the open door it creates.
🔴 Red: Stop looking for "AD exploits." Start mapping trust chains: parent-child, external, forest, delegation, and ACL trusts. Abuse is quieter and more reliable than exploitation.
🔵 Blue: Audit trust relationships quarterly. Remove stale external trusts, enforce selective authentication, and review who has delegation rights and ACL control over high-value objects.
Kerberos is the default authentication protocol in Active Directory. It uses symmetric key cryptography and a trusted third party (the Key Distribution Center, or KDC) to prove identity without sending passwords over the network.
User → KDC
"I am jsmith. Give me a TGT."
Encrypted with user's password hash
KDC → User
"Here's your TGT."
Encrypted with krbtgt hash
User → KDC
"I want to access SQL01."
Presents TGT + authenticator
KDC → User
"Here's your service ticket."
Encrypted with service hash
User → Service
"Let me in."
Presents service ticket
The TGT is your master ticket. Once you have it, you can request service tickets for any service in the domain without re-entering your password. The TGT is encrypted with the krbtgt account's password hash — a special account that exists only to encrypt TGTs. If you know the krbtgt hash, you can forge TGTs for anyone. This is the Golden Ticket.
The TGS is your entry pass to a specific service. It is encrypted with the service account's password hash. If you request a TGS for a service with an SPN, the ticket is encrypted with that service account's hash. You can take this ticket offline and crack it. This is Kerberoasting.
An SPN is a unique identifier for a service instance. It associates a service with a domain account. When Kerberos authenticates to a service, it uses the SPN to find the account and encrypt the ticket.
Delegation allows a service to impersonate a user to access another service. It's designed for multi-tier applications (web server → database server). For attackers, it's a privilege escalation path.
The service can impersonate the user to ANY service on ANY computer. If a Domain Admin authenticates to a server with unconstrained delegation, the server caches the user's TGT. Compromise the server, steal the TGT, become Domain Admin.
The service can only impersonate the user to specific services. More secure, but still exploitable. If you compromise the service account, you can request service tickets for the allowed SPNs — potentially as any user.
RBCD flips the model: the resource (target) decides who can delegate to it. If you have GenericAll or GenericWrite on a computer object, you can set its msDS-AllowedToActOnBehalfOfOtherIdentity attribute to a service account you control. Then request a ticket as any user to that computer. This is a common escalation path from computer account takeover to full domain compromise.
Every object in Active Directory has a Discretionary Access Control List (DACL) that defines who can do what to it. ACLs are the permission grid of the domain. Misconfigured ACLs create attack paths that BloodHound visualizes.
ACL modifications are logged in the Security event log (Event ID 5136), but in a typical enterprise, these logs are never reviewed. The attack doesn't involve malware, doesn't trigger AV, and doesn't create network anomalies. It's just LDAP queries and password resets — indistinguishable from legitimate administration. BloodHound exists because humans cannot manually trace these chains.
BloodHound ingests Active Directory data and builds a graph database (Neo4j) of all objects and their relationships. It then runs graph algorithms to find the shortest path from any starting point to high-value targets like Domain Admin.
| Color | Meaning |
|---|---|
| Red | High-value target (Domain Admin, etc.) |
| Green | Owned / compromised |
| Blue | Computer |
| Orange | User with path to target |
| Edge | Meaning |
|---|---|
| MemberOf | Group membership |
| AdminTo | Local administrator |
| HasSession | Active logon session |
| GenericAll | Full control |
| WriteDACL | Can modify permissions |
| AllowedToDelegate | Delegation rights |
SharpHound performs heavy LDAP queries and SMB enumeration. EDR tools may flag it. Stealth options:
--CollectionMethod DCOnly — only queries the DC, no network touch"BloodHound shows the path."
Translation: Active Directory attack paths are too complex for humans to trace by hand. BloodHound turns the domain into a graph and finds the shortest route from your current access to Domain Admin. It reveals chains of abuse that cross users, groups, computers, ACLs, sessions, and trusts — paths that would take hours or days to discover manually. Before you attack, you map. Before you map, you collect.
🔴 Red: Run SharpHound as soon as you have domain credentials. Let BloodHound tell you where to go instead of guessing. The path it finds is often shorter and quieter than you expect.
🔵 Blue: Run BloodHound against your own domain regularly. If you can find a path to Domain Admin in seconds, so can an attacker. Remove those paths before they are exploited.
Request TGS tickets for SPNs, crack offline. No special permissions needed. Service accounts often have weak passwords and high privileges.
Users with "Do not require Kerberos preauthentication" return encrypted AS-REPs. Crack offline to recover password.
Exploit misconfigured permissions (GenericAll, WriteDACL, ForceChangePassword) to move from user to user until Domain Admin.
Unconstrained delegation = TGT theft. Constrained/RBCD = service ticket forgery. Both lead to impersonation.
Imitate a Domain Controller and request password hashes via replication. Requires DCSync rights (usually Domain Admin, but sometimes misconfigured).
Forged TGT encrypted with krbtgt hash. Valid for any user, any group, any time. Persistent, undetectable by DC.
DCSync is an attack where you impersonate a Domain Controller and request password hash replication. A real DC uses the Directory Replication Service (DRS) to sync passwords. If your account has the right ACLs (Replicating Directory Changes), you can do the same.
DCSync generates Event ID 4662 (Directory Service Access) and 5136 (Directory Service Object Modification) on the DC. However, in most environments, these events are not monitored. A well-tuned SIEM should alert on non-DC accounts requesting replication. If you see DCSync alerts, the defenders are competent.
A Golden Ticket is a forged TGT encrypted with the krbtgt account's NTLM hash. Because the krbtgt hash is used to validate all TGTs in the domain, a forged TGT is indistinguishable from a real one. The DC never checks with anyone else — it just decrypts the ticket and trusts it.
The krbtgt password is automatically changed only when the domain functional level is raised or an admin manually resets it. Most organizations never do this. Even if they do, the attacker can DCSync again. The only true remediation is a double password reset (twice within 10 hours) to invalidate all existing TGTs — a disruptive operation that most admins avoid.
A Silver Ticket is a forged TGS (service ticket) encrypted with a service account's NTLM hash. Unlike a Golden Ticket, it only works for that specific service. But it's even stealthier — no DC contact at all.
| Feature | Golden Ticket | Silver Ticket |
|---|---|---|
| Hash needed | krbtgt | Service account |
| Scope | Entire domain | Single service |
| DC contact | TGT presented to DC | No DC contact |
| Detection | Possible (unusual TGT) | Extremely hard |
| Remediation | Double krbtgt reset | Change service password |
SID History is an attribute on user objects that stores additional SIDs. It was designed for migration scenarios: when a user moves from Domain A to Domain B, their old SID is added to SID History so they retain access to resources in Domain A.
SID History was built for migration, but it's a trust transitivity exploit. If Domain A trusts Domain B, and Domain B trusts Domain C, then Domain A trusts Domain C (transitive). SID History abuse lets you inject high-privilege SIDs from other domains into your token. In a forest, there is only one true security boundary: the forest itself. Domains are administrative boundaries, not security boundaries.
You have a low-privilege domain account: jsmith / Password1. Your objective: Domain Admin. You have BloodHound output showing the following relationships. Trace the attack path and document each step.
What is encrypted with the krbtgt account's hash?
Correct! The TGT is encrypted with the krbtgt hash. This is why knowing the krbtgt hash lets you forge Golden Tickets — the DC trusts any TGT it can decrypt with krbtgt.
You find that the user "helpdesk" has GenericAll on the computer "FILESERVER01". What is the MOST direct attack?
Correct! With GenericAll on a computer object, you can modify its msDS-AllowedToActOnBehalfOfOtherIdentity attribute (RBCD). This lets you impersonate any user to that computer — a direct path to privilege escalation. Resetting the password is noisy and doesn't immediately grant access. DCSync requires Replicating Directory Changes, not computer GenericAll.
Which statement about Golden and Silver Tickets is TRUE?
Correct! Silver Tickets are forged service tickets presented directly to the target service. No KDC is ever contacted, so there are no Kerberos service ticket request logs on the DC. Golden Tickets are presented to the DC (as TGTs), so there is a small detection surface. Silver Tickets require only the service account hash, not krbtgt.
Active Directory is the central hub that connects to nearly every other module in this course:
Local privilege escalation (Token Impersonation, SeDebugPrivilege) often provides the initial foothold to run SharpHound or Mimikatz in a domain context.
Pass-the-hash, pass-the-ticket, and WMI/PSExec are the transport mechanisms. AD tells you where to go and who to become.
Your beacon runs as a domain user. AD credentials let you move laterally, establish persistence, and blend into normal traffic.
AD compromise is typically the endgame. The full kill chain culminates in domain dominance — DCSync, Golden Tickets, and persistent access.
| AD Architecture (Forests, Domains, Trusts) | ✅ DEMONSTRATED |
| Kerberos Authentication (TGT/TGS/SPN) | ✅ DEMONSTRATED |
| Delegation (Unconstrained, Constrained, RBCD) | ✅ DEMONSTRATED |
| ACL Abuse (GenericAll, WriteDACL, ForceChangePassword) | ✅ DEMONSTRATED |
| BloodHound / SharpHound Reconnaissance | ✅ DEMONSTRATED |
| Kerberoasting / AS-REP Roasting | ✅ DEMONSTRATED |
| DCSync Attack | ✅ DEMONSTRATED |
| Golden Ticket Forgery | ✅ DEMONSTRATED |
| Silver Ticket Forgery | ✅ DEMONSTRATED |
| SID History Abuse | ✅ DEMONSTRATED |