Radioactive Directory

Forest: The security boundary. The top of the hierarchy. Contains one or more domains. All domains in a forest trust each other by default with transitive trusts.

Domain: A partition of the directory. Has its own DCs, its own KRBTGT account, its own policies. NOT a security boundary. Child domains do NOT provide isolation from the forest root.

Trust: A relationship allowing authentication across boundaries. The trust arrow points FROM the trusting domain TO the trusted domain. Access flows the opposite direction. See diagram below.

Organizational Units (OUs): Containers for organizing objects. Used for Group Policy application and delegation. GPOs can be linked to Sites, Domains, or OUs—with OUs providing the most granular scope for targeting specific groups of users or computers. OUs are NOT security boundaries and are NOT used for access control.

Security Groups: Used for access control. Grant permissions to resources. Come in three scopes:

AGDLP/AGUDLP: A common mnemonic for group nesting best practice. Accounts go in Global groups, Global groups go in Domain Local groups, Domain Local groups get Permissions. The "U" variant adds Universal groups to bridge domains in multi-domain forests. (See Microsoft's group scope documentation for the underlying concepts.)

Group nesting creates hidden attack paths. User is in Group A, which is in Group B, which is in Group C, which is in Domain Admins. BloodHound exists because this is impossible to track manually.

DCs hold the keys to the kingdom. They store the AD database (NTDS.dit), authenticate users, issue Kerberos tickets, and replicate with each other.

Every DC has a full copy of all credential material for its domain. Compromise one DC, you have everyone's hashes. DCSync doesn't even require DC access, just replication rights.

GPOs push configuration to domain members. Security settings, software deployment, scripts, preferences. Applied based on OU structure.

GPOs are stored in SYSVOL (\\domain\SYSVOL). Writable GPOs = code execution on every machine that processes them. GPO abuse is a common privilege escalation path.

Most AD operations are multi-master (any DC can process them). Five operations require a single authoritative DC. These are the Flexible Single Master Operations roles:

PDC Emulator: Most critical for operations. Receives urgent password changes, is the authoritative time source, processes account lockouts. Often targeted first in attacks.

Forests and domains are logical structures. Sites represent physical network topology. AD uses sites to optimize replication and client authentication.

DC Locator: When a client needs a DC, it queries DNS for SRV records. Site-aware clients prefer DCs in their own site. This affects which DC receives your authentication.

Replication latency: Inter-site replication is scheduled (not instant). Password changes and other updates may take time to propagate. This creates windows where credentials work on some DCs but not others.

The AD database is divided into partitions, each replicated differently:

This explains why schema changes affect the entire forest (Schema Admins are forest-wide dangerous), while user changes only affect one domain.

The Global Catalog (GC) is a partial replica of all objects in the forest, stored on designated DCs.

Why it exists: Without GC, cross-domain queries would require contacting every domain. GC enables forest-wide searches from a single server.

Universal group membership: GCs resolve universal group membership during logon. If no GC is available, logons can fail (unless universal group caching is enabled).

Every securable object in Windows (files, registry keys, AD objects, services) has a Security Descriptor containing:

Owner: Can always modify the DACL, even if explicitly denied. Ownership is a backdoor to full control.

DACL: Discretionary Access Control List. Contains Access Control Entries (ACEs)—each ACE is a rule specifying a security principal (by SID) and what access they're allowed or denied. If DACL is null, everyone has full access. If DACL is empty (zero ACEs), no one has access.

SACL: System Access Control List. Controls auditing, not access. Requires SeSecurityPrivilege to read/write.

When you try to access an object, the Security Reference Monitor (SRM) walks the DACL, comparing each ACE against your access token's SIDs and requested access mask.

Important: This ordering assumes the DACL is in canonical order, which is the default when using standard Windows APIs. However, canonical order is NOT enforced by the kernel—it's the responsibility of the API or caller that creates/modifies the DACL. Low-level manipulation can create non-canonical DACLs where Allow ACEs appear before Deny ACEs.

There is no "default deny ACE." Unlike a firewall with an implicit deny rule, DACLs simply have no match = no access. The SRM walks the list; if it doesn't find an Allow ACE granting the requested access, the request is denied. This is why an empty DACL means no access, while a null DACL means full access to Everyone. (Thanks to Jim Sykora for the correction.)

Not all permissions are equal. Some are effectively ownership:

WriteDACL: Modify the DACL itself. Grant yourself any other permission. Game over.

WriteOwner: Change the owner. Owners can modify DACLs. Game over.

GenericAll: Full control over the object. Includes WriteDACL. Game over.

These are what BloodHound looks for. If you have WriteDACL on a user, you own that user. If you have it on a group, you can add yourself to that group.

AD objects have extended rights and property-specific permissions beyond standard file ACLs:

Property-level ACEs: Can grant write to specific attributes (e.g., msDS-AllowedToActOnBehalfOfOtherIdentity for RBCD, msDS-KeyCredentialLink for Shadow Credentials).

Validated writes: Self-membership lets you add yourself to a group if granted.

When you authenticate, Windows creates an access token. This token is attached to every process you run and determines what you can access.

When you access a resource, Windows compares your token's SIDs against the resource's DACL. The token is the bridge between authentication (who you are) and authorization (what you can do).

Token theft is different from credential theft. Steal a token, impersonate that session. Steal credentials, create new sessions anywhere.

Permissions are on objects (DACLs). Privileges are in tokens. They're different security mechanisms.

SeDebugPrivilege: Debug any process. Read memory from LSASS. Dump credentials.

SeImpersonatePrivilege: Impersonate tokens. If you can get SYSTEM to connect to you, become SYSTEM.

SeBackupPrivilege: Read any file regardless of DACL. Extract NTDS.dit.

How you authenticate determines what credentials get cached on the target system:

This is why RDP with DA credentials to a compromised workstation is catastrophic, but network logon is safer. Interactive logons cache credentials. Network logons (mostly) don't.

runas /netonly creates a Type 9 logon session. This is confusing because it creates a split identity:

Use case: You're on a non-domain workstation but need to access domain resources. Run runas /netonly /user:DOMAIN\admin cmd.exe. That cmd window can access domain shares as DOMAIN\admin, but locally it's still you.

LSASS (Local Security Authority Subsystem Service) is the process that handles Windows authentication. It caches credentials to enable single sign-on.

What's cached depends on logon type, credential delegation settings, and OS configuration. Interactive logons expose the most. This is why:

Privileged accounts should only log on interactively to hardened systems. Every interactive logon leaves credentials in LSASS. Every system you log into is a system where your creds can be dumped.

The file sharing protocol. Every \\server\share connection uses SMB. But it's not just files. SMB carries named pipes, which are how services communicate remotely.

SMB is the transport for PsExec, remote registry, and dozens of lateral movement techniques. When you see "ADMIN$" or "C$" shares, that's SMB.

RPC lets you call functions on remote systems as if they were local. It's how Windows services expose functionality over the network.

Every coercion attack (PrinterBug, PetitPotam, DFSCoerce) abuses legitimate RPC interfaces. They call real functions, just with malicious intent.

LDAP is the primary and most commonly used interface to query and modify Active Directory. User lookups, group membership checks, GPO fetches. Not the only way (ADSI, WMI, PowerShell cmdlets wrap various interfaces), but the most direct.

BloodHound's collection? LDAP queries. Finding Kerberoastable accounts? LDAP. Enumerating trust relationships? LDAP. It's the primary read/write interface to AD.

DNS translates names to IP addresses. More importantly for AD, it's how clients find services: domain controllers, Kerberos KDCs, LDAP servers, Global Catalogs.

Domain controllers are typically (but not always) DNS servers. AD-integrated DNS stores zone data in AD itself and replicates it with AD replication. This is convenient but means DNS data is as sensitive as AD data.

Compromise DNS, and you gain powerful primitives for compromising AD. DNS poisoning can redirect authentication. Dynamic DNS updates (often open by default) allow record injection.

When DNS fails, Windows doesn't give up. It checks local files first, then falls back to broadcast protocols that anyone on the network can respond to.

The hosts file (C:\Windows\System32\drivers\etc\hosts) is checked before DNS. Malware often modifies it for persistence or redirection.

LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) are broadcast protocols. Responder and similar tools answer these broadcasts, capturing authentication attempts.

WPAD allows browsers and applications to automatically discover proxy settings by looking for a wpad.dat file. The lookup uses DNS first, then falls back to LLMNR/NBT-NS.

If an attacker can respond to WPAD requests (via DNS poisoning, LLMNR/NBT-NS spoofing, or rogue DHCP), they can inject a malicious proxy configuration. All HTTP traffic then flows through the attacker.

Windows' management infrastructure for querying system info and executing operations. Administrators use it for inventory and remote management. Attackers use it for the same reasons—plus lateral movement.

Why attackers love WMI: Built-in (no tools to upload), fileless execution via Win32_Process Create, blends with legitimate admin activity, and remote WMI = Type 3 logon = minimal credential caching.

Challenge-response protocol from 1993. Client proves it knows the password by encrypting a server challenge with a hash derived from the password. Simple but with significant security considerations.

Pass-the-Hash: Use stolen hash directly for authentication.
NTLM Relay: Forward authentication to another server.
Cracking: NTLMv1 responses are trivially crackable. NTLMv2 is significantly stronger but still susceptible to offline cracking with weak passwords or captured challenge/response pairs.

NTLM can be hardened (require NTLMv2, enable Extended Protection for Authentication, require signing), but these mitigations are rarely fully deployed. Most environments have NTLM enabled everywhere for backward compatibility.

Ticket-based authentication. You authenticate once to the KDC (Key Distribution Center, running on DCs), get a TGT (Ticket Granting Ticket), then exchange TGT for service tickets.

Kerberoasting: Request service tickets, crack them offline to get service account passwords.
AS-REP Roasting: Request encrypted data for accounts without pre-auth, crack offline.
Golden Ticket: Forge TGTs with the KRBTGT hash. Become anyone.
Silver Ticket: Forge service tickets with service account hash.

Kerberos proves WHO you are. The PAC says WHAT you can do. It's Microsoft's extension to Kerberos for carrying authorization data inside tickets.

Golden Ticket: You forge the PAC. Put Domain Admins SID in there. Sign with stolen krbtgt hash. KDC trusts it completely.

Silver Ticket: You forge a service ticket PAC. Most services don't validate PAC signatures with the DC—they just trust whatever's in the ticket.

In Windows authentication, you don't need to know someone's password to become them. You need their credentials, and credentials take many forms.

An NT hash can be used directly to authenticate via NTLM (pass-the-hash). A TGT can be used to request service tickets (pass-the-ticket). A certificate can be used to request a TGT (PKINIT). Neither requires knowing the original password.

This is why Mimikatz exists. This is why credential dumping is step one of every AD attack. This is why "just change the password" doesn't help if the attacker already has a Golden Ticket (which remains valid until KRBTGT is rotated twice) or a certificate (valid until it expires or is revoked).

The computer account (WORKSTATION$) is a security principal just like a user account. It has:

When a computer boots and joins the domain, it authenticates with its machine account password. It gets a TGT. It can then access network resources as itself.

Many admins think "computers authenticate, users do things." Reality: computers ARE users. They can query LDAP, access shares, be granted permissions, be delegated to.

Compromise a machine, get its machine account. This gives you:

DC machine accounts: Domain Controllers are computers. Their machine accounts (DC01$) are effectively Tier 0. Compromise a DC's machine account = domain compromise.

Relay attacks: Coerce a machine to authenticate to you, relay that authentication. You're now acting as that machine account.

Resource-Based Constrained Delegation (RBCD) abuse relies entirely on machine accounts:

Step 1 is why ms-DS-MachineAccountQuota matters. Any authenticated user can create machine accounts by default. You create one, you control its password, you have a principal for RBCD.

Step 2 requires write access to the target. But if you have it (via ACL misconfiguration, relay, etc.), you can configure the target to trust your controlled machine account for delegation.

Machine account passwords are managed automatically by Windows:

The machine stores its own password in the SECURITY registry hive. Extract it (SYSTEM access required), and you can authenticate as that machine anywhere.

Silver ticket implication: A machine account password hash lets you forge service tickets for any service that machine hosts, without touching the DC.

An SPN is an attribute on an account that says "this account runs this service." When you request a Kerberos service ticket, the KDC looks up the SPN to find which account to encrypt the ticket for.

Machine accounts have SPNs automatically (HOST/computername). User accounts only have SPNs if manually configured, usually for services running under user accounts.

The SPN-to-account mapping is how Kerberos knows which key to use. This is also why Kerberoasting works.

Any authenticated user can request a service ticket for any SPN. The ticket is encrypted with the service account's password hash.

Machine accounts have 120-character random passwords. They're not crackable. But user accounts? Often have weak, human-chosen passwords. If a service runs under a user account with an SPN, that password is crackable.

Kerberoasting was introduced by Tim Medin at DerbyCon 2014.

Not all service accounts are equal:

gMSAs solve Kerberoasting for services that can use them. Many legacy applications can't. Those still need user-based service accounts with all their problems.

Service accounts accumulate privileges over time:

One compromised service account often leads to lateral movement across every system where it's used. If it's DA, game over. If it has interactive logon rights, its credentials are cached everywhere it logged in.

Domain Controllers replicate the AD database to stay in sync. This includes all objects and all attributes, including password hashes.

When a DC replicates, it requests changes from another DC. The responding DC sends objects, attributes, and secrets. This is how all DCs have all credentials for their domain.

DCSync isn't an exploit. It's using the replication protocol as intended, just from a non-DC. The DC doesn't care if the requestor is a DC or an attacker with the right permissions.

Two extended rights control replication:

Both rights together = DCSync = dump every credential in the domain. By default, Domain Admins, Enterprise Admins, Administrators, and Domain Controllers have these rights.

Replication happens within domains and across certain trust boundaries:

The Global Catalog contains a partial replica of all objects in the forest. GC replication doesn't include password hashes, but it does include enough for enumeration.

This is another reason why the forest is the security boundary, not the domain. Replication topology follows forest trust, not domain isolation.

Read-Only Domain Controllers exist specifically to limit replication risk:

RODCs were designed for branch offices where physical security is weak. Compromise an RODC, and you only get the credentials it was allowed to cache, not the entire domain.

But if the Password Replication Policy is misconfigured (e.g., "allow all"), the RODC becomes a full credential store. Configuration matters.

In AD, permissions flow downward through inheritance. If someone grants "HelpDesk → Reset Passwords" on the Users OU, that permission propagates to every user object below it. This is convenient for delegation—but catastrophic if it applies to Domain Admins.

To prevent inherited permissions from accidentally (or maliciously) granting control over privileged accounts, AD has a protection mechanism: the AdminSDHolder object and the ProtectAdminGroups background task.