📦 Active Directory

What is it?

  • Concept: Active Directory (AD) is Microsoft’s directory service for Windows domains — a central database (NTDS.dit, replicated between Domain Controllers) of every user, computer, group, and policy in the environment, exposed over LDAP for queries and Kerberos for authentication. Almost nothing about AD is a “vulnerability” in the software-bug sense; it’s a permissions system, and every technique note under this tag is really about a permission that was granted a little too broadly.
  • Impact: Nearly every AD compromise chain documented in this vault (see the Exploitation section below) is a chain of legitimate rights used the wrong way — a password reset right, an object-write right, a replication right — strung together until it reaches Domain Admin. Understanding the naming conventions, group structure, and permission model below is the prerequisite for reading any of those chains, not an exploit in itself.

How it works

  1. A Domain Controller (DC) hosts the directory database, the Kerberos Key Distribution Center (KDC), and an LDAP server on top of it — SMB/RPC endpoints exist mostly to let clients push/pull data to those.
  2. Every object (user, computer, group, GPO, OU) has a Distinguished Name (its path in the directory tree), a Security Identifier (SID), and a security descriptor — an owner plus a Discretionary ACL (DACL) that lists exactly which principals can read/write which of its attributes.
  3. At logon, the KDC bakes the user’s full (transitive) group membership into the ticket’s PAC (Privilege Attribute Certificate). Everything downstream — file shares, RPC calls, other tickets — trusts that PAC instead of re-checking group membership live, which is why permission changes only take effect once a new ticket is requested.

Naming Conventions (glossary)

TermExampleNotes
sAMAccountNamejdoeLegacy short logon name (pre-Windows 2000 style), still the identifier most tools (nxc, net rpc) expect.
User Principal Name (UPN)jdoe@corp.localModern, email-shaped logon format — not always identical to <sAMAccountName>@<domain>.
NetBIOS formCORP\jdoedomain\username, the format Windows dialogs and LDAP simple binds often expect.
Distinguished Name (DN)CN=John Doe,OU=IT,DC=corp,DC=localFull path in the LDAP tree, read right-to-left from the root domain component down.
Security Identifier (SID)S-1-5-21-<domain>-<RID>Unique, never reused — the domain portion is shared by every object in that domain, the RID (Relative ID) is unique per-object.
FQDNDC01.corp.localFull hostname — needed for anything Kerberos-based once NTLM is disabled, since Kerberos SPNs are hostname-based.

Well-known RIDs worth recognizing on sight: 500 Administrator, 501 Guest, 502 krbtgt, 512 Domain Admins, 518 Schema Admins, 519 Enterprise Admins, 520 Group Policy Creator Owners. Built-in local groups (not domain-wide) use a separate, fixed SID prefix S-1-5-32-<RID> instead of the domain SID — 544 Administrators, 548 Account Operators, 549 Server Operators, 550 Print Operators, 551 Backup Operators — because they exist identically on every DC rather than being a single replicated object.

Groups

  • Built-in high-value groups: Domain Admins, Enterprise Admins, Schema Admins, Administrators (BUILTIN), Account Operators, Server Operators (see Active Directory - Server Operators Group Abuse), Backup Operators (see Active Directory - SeBackupPrivilege Abuse), Print Operators, DnsAdmins, Group Policy Creator Owners.
  • Nesting is transitive: a group can be a member of another group, and effective rights come from the full transitive closure of that membership — a permission granted to a group two levels removed from a user still applies to them. Tracing that by hand doesn’t scale past a handful of objects, which is the entire reason BloodHound exists.
  • Custom delegation groups are the recurring theme in this vault’s write-ups: admins routinely create bespoke groups for a narrow operational reason — Shared Support Accounts in HTB - Support, Share Moderators in HTB - Administrator — and then over-grant them broad rights (GenericAll on a Domain Controller, FTP share access) without treating “who gets added to this group later” as a standing security decision.

Permissions / ACEs — what BloodHound actually shows

BloodHound’s graph edges are AD ACEs (Access Control Entries), just renamed to be readable. This is the list worth recognizing immediately when it shows up on an edge:

BloodHound Edge / ACEGrantsRelated Technique
GenericAllFull control of the object — reset password, add to group, edit any attributeActive Directory - ACL Abuse (GenericAll & ForceChangePassword)
GenericWriteWrite any non-protected attribute — e.g. servicePrincipalName, msDS-AllowedToActOnBehalfOfOtherIdentity, scriptPathActive Directory - Targeted Kerberoasting, Active Directory - Resource-Based Constrained Delegation (RBCD) Attack
WriteOwnerTake ownership of the object, then write a fresh DACL granting yourself anything—
WriteDaclDirectly write a new ACE onto the object’s DACL — typically self-granting GenericAll—
ForceChangePasswordReset the target’s password with no knowledge of the current one (narrower than GenericAll)Active Directory - ACL Abuse (GenericAll & ForceChangePassword)
AddMemberAdd arbitrary principals — including yourself — to a group—
OwnsObject owner — implicitly carries WriteDacl-equivalent rights regardless of what the DACL itself says—
GetChanges + GetChangesAllTogether, DS-Replication-Get-Changes[-All] — full directory replication rights over the whole domainActive Directory - DCSync Attack
AllExtendedRightsEvery extended right on the object at once — on a user this includes password reset; on the domain object it includes replication rightsActive Directory - DCSync Attack
ReadLAPSPassword / ReadGMSAPasswordRead a computer’s current LAPS local-admin password / a gMSA’s current password blob—

Security Quirks & Niche Facts

  • Cached tickets ignore live permission changes: since group membership is baked into the PAC at issuance, revoking a right doesn’t take effect until the victim’s ticket is renewed — and symmetrically, a right an attacker just granted themselves doesn’t apply until they request a fresh TGT/TGS either. Every technique note above that changes an ACE or group membership implicitly assumes a new ticket gets requested afterward.
  • “Effective permissions” is not the same question as “explicit ACEs on this object”: nested group membership, object ownership, and ACEs inherited from a parent OU/container all contribute to what a principal can actually do. Reading a single object’s ACL by hand (Get-Acl, dsacls) answers a much narrower question than BloodHound’s graph does — treat manual ACL reads as a spot-check, not a substitute for a full collection.
  • Built-in groups aren’t domain objects the way custom groups are: S-1-5-32-* groups are local to every DC individually, which is part of why they show up granted rights “automatically” in ways that can look surprising in BloodHound compared to a normal domain-scoped group.

Exploitation

Start here: Active Directory - Enumeration — the systematic checklist for what to enumerate and which of the notes below each finding feeds into.

Mitigation

  • Fix 1: Audit ACLs with BloodHound (or an equivalent) starting from every realistic “assume breach” position, not just from Domain Admin’s perspective — over-permissioning accumulates silently through years of helpdesk-style delegation, and nobody notices from the top down.
  • Fix 2: Default to least privilege for any custom delegation group — GenericAll/WriteDacl should never be handed out when a narrower right (ForceChangePassword, a single attribute write) satisfies the actual operational need.
  • Fix 3: Treat any account holding DS-Replication-Get-Changes[-All] outside the built-in Domain Controllers/Domain Admins groups as equivalent to Domain Admin, because it functionally is one.
FileCreated
HTB - AuthorityJuly 23, 2026
HTB - CertifiedJuly 23, 2026
HTB - SupportJuly 22, 2026

References: