Warmup Guide — Active Directory as the Enterprise Identity Perimeter

Zero-to-principal primer for Phase 05. It builds Active Directory's identity model from first principles so you can reason about why an unprivileged account so often reaches Domain Admins, and exactly what telemetry each step emits. We cover the AD object model and ACLs; NTLM vs Kerberos; the Kerberos ticket dance under the hood; Kerberoasting and AS-REP roasting; the three delegations; golden, silver, and diamond tickets; NTLM relay and authentication coercion; DACL attack edges; ADCS ESC1; and the BloodHound graph model. Every chapter ends in the telemetry, the detection, and the misconceptions. By the end you can walk a foothold-to-Domain-Admins path, name the Kerberos/Windows event for each abuse, and prescribe the mechanism-level fix.

Safety. Everything here is explained at the level of mechanism and detection. The labs reason over synthetic directory metadata only — no live AD, no collection, no ticket requests, no cracking, no weaponization. Practice the operator workflow only on an owned, purpose-built forest (see HITCHHIKERS-GUIDE.md), never a production domain.

Table of Contents

• Chapter 1: Why Active Directory Is the Real Perimeter
• Chapter 2: The AD Object Model, Security Descriptors, and ACLs
• Chapter 3: Authentication — NTLM vs Kerberos
• Chapter 4: The Kerberos Ticket Dance Under the Hood
• Chapter 5: Kerberoasting (T1558.003)
• Chapter 6: AS-REP Roasting (T1558.004)
• Chapter 7: The Three Delegations and How Each Is Abused
• Chapter 8: Golden, Silver, and Diamond Tickets
• Chapter 9: NTLM Relay, Coercion, Pass-the-Hash, and Pass-the-Ticket
• Chapter 10: DACL Attack Edges and ADCS ESC1
• Chapter 11: The BloodHound Graph Model
• Lab Walkthrough
• Success Criteria
• Common Mistakes / OPSEC Failures
• Interview Q&A
• References

Chapter 1: Why Active Directory Is the Real Perimeter

Zero background. When a company has more than a handful of Windows computers, it stops managing each one separately and joins them to a domain: a central directory that knows every user, every computer, every group, and what each is allowed to do. That directory is Active Directory (AD), and the servers that host it are Domain Controllers (DCs). Logging in, accessing a file share, running a service — all of it is mediated by AD. AD is, in one phrase, the enterprise's identity system.

What it is. AD is a database (the NTDS.dit file on each DC) plus the protocols that let machines query and authenticate against it: LDAP for reading and writing the directory, Kerberos and NTLM for authentication, DNS for locating DCs, and SMB/RPC for the management calls. A collection of domains that trust each other is a forest; the forest is the real security boundary in AD.

Why it exists. Without a central directory, every server keeps its own account list and you manage N machines by hand. AD centralizes identity so a user has one account, one password, and one set of group memberships that grant access everywhere. That centralization is exactly what makes it the prize: compromise AD and you compromise every identity and every machine that trusts it. Most published enterprise breaches — and the bulk of every Mandiant M-Trends report — run through AD, because the attacker's goal (move laterally, escalate, persist) is precisely what AD is built to facilitate for legitimate admins.

Under the hood — the trust model. AD trusts by default, by design. A normal domain user can:

• Read most of the directory over LDAP — every user, group, computer, their attributes, group memberships, and the Service Principal Names (SPNs) and delegation settings that turn into attack edges. (This single fact powers reconnaissance: an unprivileged account can map the whole forest. It is what SharpHound collects.)
• Request Kerberos tickets for any service — which is what makes Kerberoasting (Chapter 5) possible from any account.

So the attacker's job is rarely "break a cryptographic protocol." It is "read the graph of who-can-do- what-to-whom, and find a chain of legitimate-looking abuses from where I am to Domain Admins."

Telemetry. AD is one of the most observable systems in the enterprise — if auditing is on. Each DC can log authentication (4768/4769/4776), logons on every host (4624/4625/4672), object access and changes (4662/5136/4670/4720-4738), and group changes (4728/4732/4756). The catch: by default much of this is not logged at the granularity needed (object auditing and PowerShell logging in particular must be turned on), so the absence of a detection is often a configuration gap, not the absence of the attack.

Significance. "Getting Domain Admin" is table stakes in this profession; the value is the narrative of the path, mapped to ATT&CK, with the detection the SOC missed at each step, and the identity-hardening that closes it. That is what the rest of this phase trains.

Misconceptions.

• "AD security is about patching." Mostly it is not. The dominant AD attacks abuse configuration and relationships (SPNs, delegation, ACLs), not memory-corruption bugs.
• "A normal user can't see much." A normal user can read almost the entire directory. Reconnaissance is nearly free; that is the design.
• "The domain is the boundary." The forest is the boundary. A DC compromise in any domain of a forest is a forest compromise.

Chapter 2: The AD Object Model, Security Descriptors, and ACLs

Zero background. Everything in AD is an object with a type (user, group, computer, organizational unit, GPO, certificate template, …) and a set of attributes (a user has sAMAccountName, memberOf, servicePrincipalName, userAccountControl, pwdLastSet, …). Objects live in a tree of Organizational Units (OUs). The set of allowed object types and attributes is the schema.

What a security principal is. Some objects can authenticate and be granted rights — users, computers (every domain-joined machine has a computer account, named with a trailing $), and security groups. These are security principals, each identified by a SID (a Security Identifier, e.g. S-1-5-21-…-1106). Group membership is transitive: a user in Help Desk, which is in IT Staff, which is in Server Operators, inherits all three groups' rights. That transitivity is the first kind of attack edge (MemberOf).

What governs access — the security descriptor. Every object carries a security descriptor with four parts that matter here:

Security descriptor of an AD object
├── Owner SID            — the owner can always rewrite the DACL (this is why WriteOwner is dangerous)
├── DACL (Discretionary Access Control List)
│   └── ACEs (Access Control Entries): "principal P is Allowed/Denied right R on this object"
│       e.g.  Allow  Help Desk  ->  Reset Password          (becomes the ForceChangePassword edge)
│             Allow  Support    ->  GenericAll              (full control over the object)
│             Allow  SvcGrp     ->  WriteProperty:SPN       (lets you add an SPN -> targeted roast)
├── SACL                 — the *audit* list: which accesses generate 4662/5136 events
└── (rights are object-specific: extended rights like "Reset Password", "DS-Replication-Get-Changes")

Why this is the attack surface. Over decades, admins grant ACEs to make day-to-day work convenient — "let the help desk reset passwords," "give this app team full control of these objects" — and almost no one ever audits or removes them. The result is a dense web of GenericAll, WriteDacl, WriteOwner, ForceChangePassword, and AddMember rights that are perfectly legitimate individually but, chained, form a path from an unprivileged account to a privileged one. BloodHound (Chapter 11) exists to surface exactly these chains.

Under the hood — how a right becomes an attack. Take ForceChangePassword: if your account has the "Reset Password" extended right over svc_admin, you can set svc_admin's password to something you know — without knowing the old one — and then authenticate as svc_admin. Or GenericWrite over a user lets you add an SPN to it and then Kerberoast it (a targeted roast), or write its msDS-KeyCredentialLink for shadow credentials (Chapter 10). The right is the door; the technique is what you do once through it.

Telemetry. Object access and modification are logged by Directory Service auditing, if the object's SACL and the DC's audit policy are configured:

• 4662 — an operation was performed on an object (the workhorse for DACL-abuse and DCSync; the specific GUIDs in the event name the right used).
• 5136 — a directory object was modified (attribute writes: SPN added, msDS-KeyCredentialLink written, RBCD attribute set, owner changed).
• 4670 — permissions on an object were changed (WriteDacl/WriteOwner follow-through).
• 4724/4738 — a password was reset by another account / an account was changed (ForceChangePassword).
• 4728/4732/4756 — a member was added to a global/local/universal security group (AddMember).

Detection. Set SACLs on high-value objects (privileged groups, the AdminSDHolder, service accounts, the domain object) to generate 4662/5136; alert on writes to sensitive attributes (servicePrincipalName, msDS-KeyCredentialLink, msDS-AllowedToActOnBehalfOfOtherIdentity, nTSecurityDescriptor) from non-administrative principals; baseline group membership and alert on new members of Tier-0 groups.

Significance. ACL hygiene is one of the highest-leverage defensive investments in AD and one of the least done. The choke-edge analysis in Lab 01 exists because removing one over-broad ACE often severs many attack paths at once.

Misconceptions.

• "Only admins can change directory objects." No — a misconfigured ACE can let any principal write a privileged object. The DACL, not the user's title, decides.
• "WriteOwner isn't a big deal, it's not GenericAll." The owner can always rewrite the DACL, so WriteOwner → WriteDacl → GenericAll. They collapse into the same outcome.

Chapter 3: Authentication — NTLM vs Kerberos

Zero background. Before AD can decide what you may do, it must decide who you are. Windows has two domain authentication protocols: the old NTLM (challenge-response) and the modern Kerberos (ticket-based). Understanding both — and why Kerberos replaced NTLM but never fully removed it — is the foundation for every attack in this phase.

NTLM — what it is. NTLM proves you know a password without sending it, via a challenge-response:

NTLM challenge-response (simplified)
Client ----- NEGOTIATE ----->  Server
Client <---- CHALLENGE (nonce) Server
Client ----- RESPONSE = f(NT_hash, nonce) -----> Server
Server ----- (if domain account) passes to a DC for verification (NETLOGON) -----> DC

The crucial fact: the response is computed from the NT hash of the password (MD4(UTF-16(password))), not the plaintext. So if you steal the NT hash from memory (LSASS) or the SAM/NTDS database, you can authenticate without ever knowing the password — this is pass-the-hash (Chapter 9). NTLM also has no server authentication and no channel binding by default, which is why it can be relayed (Chapter 9).

Kerberos — what it is and why it exists. Kerberos (RFC 4120) was designed to fix NTLM's structural problems: it provides mutual authentication, uses time-limited tickets instead of replaying a password-equivalent on every connection, and centralizes trust in the DC acting as a Key Distribution Center (KDC). Instead of proving your password to every server, you prove it once to the KDC, get a Ticket-Granting Ticket (TGT), and then exchange the TGT for per-service tickets. Chapter 4 walks the full dance.

Why NTLM still exists. Kerberos requires the client to locate the service by name (it needs an SPN to ask the KDC for a ticket) and needs DNS, time sync, and reachability to a DC. When any of that fails — accessing a server by IP address, a local account, a non-domain-joined host, certain legacy apps — Windows falls back to NTLM. Attackers love this fallback: it is how relay and coercion stay relevant in 2020s networks.

The attacker's view — which protocol enables which attack.

Telemetry.

• NTLM authentication is logged as 4776 (the DC validated the credentials) and 4624 logon type 3 on the target with Authentication Package: NTLM.
• Kerberos shows up as 4768 (a TGT was requested — AS), 4769 (a service ticket was requested — TGS), and 4624 with Authentication Package: Kerberos.
• A telltale: NTLM where Kerberos was expected (e.g., admin tools hitting a server by IP) is worth alerting on; so is a sudden rise in NTLM in an otherwise Kerberos-first environment.

Detection / hardening. Reduce NTLM usage (audit with the "Restrict NTLM" policies, then block where possible); enforce SMB signing and LDAP channel binding / signing to stop relay; require Kerberos for management. The long-term direction is NTLM-disabled domains, which Microsoft is moving toward.

Significance. Almost every AD attack maps cleanly onto "which protocol, which stolen material." If you can place a technique on this axis, you can predict its telemetry and its control.

Misconceptions.

• "Kerberos is encrypted so it's safe." Kerberos has multiple offline-crackable artifacts (the TGS reply, the AS-REP) and forgeable keys (krbtgt). It is attackable by design choices, not broken.
• "We turned off NTLM." Most environments cannot, because of fallback cases; assume NTLM is reachable until proven otherwise.

Chapter 4: The Kerberos Ticket Dance Under the Hood

Zero background. Kerberos is a ticket system. You authenticate once to get a master ticket (the TGT), then trade it for service tickets without re-entering your password. The DC plays two roles inside the KDC: the Authentication Service (AS) issues TGTs, and the Ticket-Granting Service (TGS) issues service tickets. Two keys you must hold in your head: the user's key (derived from the user's password) and the krbtgt key (derived from the password of the special krbtgt account, known only to the KDC).

The four messages.

            AS-REQ  ──────────────►   ┌──────────────┐
  Client                              │  KDC on DC   │
            AS-REP  ◄──────────────   │  (AS + TGS)  │
   (1,2) get a TGT                    └──────────────┘

            TGS-REQ ──────────────►
  Client
            TGS-REP ◄──────────────
   (3,4) get a service ticket for a named SPN

            AP-REQ  ──────────────►   ┌──────────────┐
  Client    (present the service       │   Service    │
             ticket to the service)    └──────────────┘

(1) AS-REQ. The client asks the AS for a TGT. To prove identity before the KDC does any work, the client includes pre-authentication: a timestamp encrypted with the user's key. The KDC can decrypt it only with the user's key (which it derives from the stored password), so a valid pre-auth proves the client knows the password. (Disabling pre-auth is what makes AS-REP roasting possible — Chapter 6.)

(2) AS-REP. The KDC returns the TGT plus a session key. Crucially, the TGT is encrypted with the krbtgt key (so only the KDC can later read it), and the session-key blob the client needs is encrypted with the user's key. The TGT contains the user's identity and a PAC (Privilege Attribute Certificate) listing the user's SIDs and group memberships — this is how the rest of the system learns the user's privileges without re-querying AD.

(3) TGS-REQ. When the client wants to reach a service (say MSSQLSvc/db01), it sends the TGT back to the TGS along with the SPN of the target service. The TGS validates the TGT (it can decrypt it — it holds the krbtgt key) and issues a service ticket.

(4) TGS-REP. The KDC returns a service ticket (TGS) encrypted with the target service account's key (so the service can decrypt and trust it), plus a service session key for the client. (This is the artifact Kerberoasting cracks — Chapter 5: the TGS is encrypted with the service account's password-derived key, and the requester receives it.)

(AP-REQ). The client presents the service ticket to the service. The service decrypts it with its own key, reads the PAC, and grants access accordingly.

The keys, summarized.

Why RC4 vs AES lives here. Each ticket is encrypted with an encryption type (etype). RC4 (etype 0x17) derives its key straight from the NT hash (MD4 of the password) — fast to brute-force. AES (etype 0x12/0x11) derives the key with PBKDF2 (4096 iterations + salt) — far slower. Whether a ticket comes back RC4 or AES is decided by the account's msDS-SupportedEncryptionTypes and the client's request; an attacker will ask for RC4 to make any offline crack cheap.

The PAC is the privilege bundle inside the TGT/TGS. It is signed by the KDC. Forged tickets (golden) must forge a valid PAC; the PAC validation improvements and the 2021–2022 PAC-signature hardening (KB5008380 and the November 2021/2022 changes) exist precisely to make forged or mismatched PACs detectable — relevant when you reason about why old golden-ticket forgeries now fail or get flagged.

Telemetry. 4768 = AS-REQ (a TGT was requested — note the Ticket Encryption Type and Pre-Authentication Type); 4769 = TGS-REQ (a service ticket was requested — note the Service Name (the SPN) and the Ticket Encryption Type, where 0x17 = RC4). These two events are the backbone of nearly every Kerberos detection in this phase.

Detection / hardening. Set accounts and the domain to AES-only where possible (so RC4 in a 4768/ 4769 becomes anomalous and alertable); rotate the krbtgt password (twice) on a schedule and after any suspected DC compromise; keep DCs patched for PAC-validation hardening.

Significance. Every attack in Chapters 5–8 is a manipulation of one specific message or key in this dance. Hold the dance in your head and the attacks become obvious rather than memorized.

Misconceptions.

• "The TGT proves who you are to the service." No — the service ticket does; the TGT only proves you to the KDC. The service never sees your TGT.
• "Kerberos tickets can't be cracked because they're encrypted." The TGS and AS-REP are encrypted with password-derived keys, which is exactly what makes them offline-crackable when the password is weak and the etype is RC4.

Chapter 5: Kerberoasting (T1558.003)

Zero background. Some accounts run services (a SQL server, a web app pool). To let Kerberos locate them, those accounts are tagged with one or more Service Principal Names (SPNs) — e.g. MSSQLSvc/db01.meridian.local:1433. The presence of an SPN on a user account is the precondition for Kerberoasting.

What it is. Kerberoasting is requesting a service ticket (TGS) for an SPN and then cracking it offline to recover the service account's password. ATT&CK: T1558.003.

Why it works — the mechanism. Recall from Chapter 4 that the TGS-REP is encrypted with the service account's key (derived from its password) and is handed to the requester. And recall from Chapter 1 that any domain user can request a service ticket for any SPN. Put those together:

1. Any authenticated user asks the KDC for a TGS for MSSQLSvc/db01 (a normal, legitimate request).
2. The KDC returns a TGS encrypted with svc_sql's password-derived key.
3. The attacker takes that ticket offline and brute-forces/dictionaries the password: for each guess, derive the key, try to decrypt, check for a valid structure. No further interaction with AD is needed — and therefore no lockout and no further telemetry during cracking.

Why RC4 is the red flag. If the ticket comes back RC4 (etype 0x17), the key is just the NT hash and the crack runs billions of guesses per second on a GPU. AES makes each guess far more expensive. Attackers therefore request RC4 when the account supports it. A weak or old password makes the crack fast regardless; a long random password makes even RC4 infeasible.

Kerberoast in one line of logic:
  any user  --TGS-REQ(SPN)-->  KDC  --TGS-REP(enc with svc account key)-->  attacker  --crack offline-->  password
                                                                                         (RC4 + weak pw = trivial)

Telemetry. 4769 (a Kerberos service ticket was requested) for the SPN — and the discriminators are the Ticket Encryption Type = 0x17 (RC4) and a single account requesting tickets for many different SPNs in a short window (mass roasting). The request itself looks legitimate, which is why the pattern and the etype — not the bare event — are the signal.

Detection. Alert on 4769 with encryption type 0x17 for accounts/SPNs that should be AES; alert on one principal requesting TGS for an anomalous number or diversity of SPNs; deploy honey SPN accounts (a fake service account with an SPN and a strong password) whose any 4769 is malicious.

Hardening (mechanism-level).

• gMSA (group Managed Service Account): the password is 128 random characters, auto-rotated by AD — uncrackable in practice. This is the real fix.
• If a human-managed account is unavoidable: long random password (25+ chars) and AES-only (msDS-SupportedEncryptionTypes), and remove SPNs that aren't needed.
• Never put an SPN on a privileged account (a Domain Admin running a service) — the crack yields domain power directly (Lab 02's privileged_with_spn).

Significance. Kerberoasting is often the first move after a foothold because it needs only a normal user, leaves cracking entirely offline, and frequently yields a service account that is over-privileged. It is the textbook example of "the protocol isn't broken; the configuration is."

Misconceptions.

• "You need admin to Kerberoast." No — any authenticated user can request the ticket.
• "Setting a strong password fixes it." It raises the cost; it does not stop the request. AES-only + gMSA is what actually neutralizes it, because a human-set password is rotated rarely and can leak.
• "AES means we're safe." AES makes the crack expensive but the request still happens; if the password is genuinely weak even AES can fall. gMSA's randomness is what truly closes it.

Chapter 6: AS-REP Roasting (T1558.004)

Zero background. Recall the pre-authentication step in Chapter 4: normally the client must prove it knows the password (an encrypted timestamp) before the KDC issues anything. Some accounts have a flag — DONT_REQ_PREAUTH in userAccountControl — that turns pre-auth off, usually to support a legacy application that can't do it.

What it is. AS-REP roasting is requesting an AS-REP for a pre-auth-disabled account and cracking it offline. ATT&CK: T1558.004. It is Kerberoasting's cousin, one message earlier in the dance.

Why it works — the mechanism. With pre-auth disabled, the KDC will send the AS-REP — which contains a blob encrypted with the user's password-derived key — to anyone who asks, with no proof of identity. So the attacker:

1. Requests a TGT (AS-REQ) for the pre-auth-disabled account, supplying no pre-auth.
2. Receives the AS-REP, part of which is encrypted with the account's key.
3. Cracks it offline, exactly like a Kerberoast.

The difference from Kerberoasting: AS-REP roasting needs no authenticated foothold at all (you can ask the KDC as an outsider if you can reach it) and targets the user's own key rather than a service account's. The shared root cause is the same: an offline-crackable, password-derived ciphertext is handed out, and RC4 (etype 0x17) makes it cheap.

Telemetry. 4768 (a TGT was requested) with Pre-Authentication Type = 0 (none) — the signature of an AS-REP-roastable account being asked for. RC4 in the reply (etype 0x17) again marks the cheap-crack case.

Detection. Audit which accounts have DONT_REQ_PREAUTH set (there should be very few, and you should know each one's reason); alert on 4768 with pre-auth type 0; treat any pre-auth-disabled privileged account as a critical finding.

Hardening (mechanism-level). Re-enable Kerberos pre-authentication (clear the DONT_REQ_PREAUTH flag) — the direct fix. If a legacy app genuinely requires it off, give the account a long random password, set it AES-only, scope its privileges to nothing, and monitor its 4768 events.

Significance. AS-REP-roastable accounts are pure misconfiguration debt — almost always a flag set years ago for a now-forgotten app — and they hand an attacker an offline-crackable hash for free. Lab 02 flags them and ranks privileged ones highest.

Misconceptions.

• "It's the same as Kerberoasting." Same crack, different message and precondition: Kerberoasting needs an SPN (and a foothold); AS-REP roasting needs pre-auth disabled (and not even a foothold).
• "Disabling pre-auth is harmless if the password is strong." It removes a control and emits an offline-crackable artifact to anyone; the only good number of pre-auth-disabled accounts is as close to zero as the apps allow.

Chapter 7: The Three Delegations and How Each Is Abused

Zero background. Delegation is a Kerberos feature that lets a service act on behalf of a user to a back-end service — e.g. a web front-end (web01) needs to reach a database (db01) as the logged-in user, not as itself, so file permissions apply correctly. Useful and legitimate; also one of the most dangerous misconfigurations in AD when set too broadly. There are three kinds.

1) Unconstrained delegation (the worst). A computer flagged TRUSTED_FOR_DELEGATION is allowed to impersonate users to any service. To make that possible, when a user authenticates to such a host, the KDC includes the user's TGT in the service ticket, and the host caches that TGT in memory.

• Abuse: compromise the unconstrained host and you can extract the cached TGTs of every user who has authenticated to it — including, if you can make one authenticate, a Domain Admin or a DC's computer account. Combined with coercion (Chapter 9 — force a DC to authenticate to your host, PetitPotam-style), this is a direct path to domain compromise.
• Why it's catastrophic: it caches a reusable TGT, the most powerful Kerberos artifact, for everyone who touches the host.

2) Constrained delegation (S4U). A service is allowed to impersonate users only to a named list of SPNs (msDS-AllowedToDelegateTo). It uses two extensions: S4U2Self (the service requests a ticket to itself on behalf of a user, even without the user's TGT) and S4U2Proxy (it then requests a ticket to the allowed back-end service on the user's behalf).

• Abuse: if you control the delegating account, S4U2Self lets you mint a ticket as any user (including a DA) to yourself, and S4U2Proxy forwards it to the allowed service — and with protocol transition you don't even need the user's password. The constraint limits which services, but if one of them is sensitive (e.g. CIFS/dc01), it's game over.

3) Resource-based constrained delegation (RBCD). The newest model inverts the configuration: the back-end resource decides who may delegate to it, via its own attribute msDS-AllowedToActOnBehalfOfOtherIdentity.

• Abuse: if you can write that attribute on a target computer (you have GenericWrite/WriteDacl over it, or you can create a computer account and configure it), you point it at an account you control, then use S4U2Self/S4U2Proxy to impersonate any user to that target. RBCD is a favorite because the precondition — a write to one attribute — is a common DACL-abuse outcome (Chapter 10).

Under the hood — the abuse pattern, in one diagram:

Unconstrained:  user --auths--> [TRUSTED_FOR_DELEGATION host]   (host caches the user's TGT)
                attacker owns host  =>  steal cached TGT  =>  be that user (incl. DA)

Constrained:    attacker controls delegating account
                S4U2Self(as: DA, to: self)  then  S4U2Proxy(to: allowed SPN)  => act as DA to that SPN

RBCD:           attacker writes  msDS-AllowedToActOnBehalfOfOtherIdentity  on TARGET, pointing at OWNED
                S4U2Self/S4U2Proxy  => impersonate ANY user to TARGET

Telemetry. 4769 service-ticket requests showing the S4U pattern (a service requesting tickets on behalf of other users); 5136 writes to msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD being configured) and to msDS-AllowedToDelegateTo (constrained delegation being changed); anomalous outbound authentication from a DC (a sign of coercion feeding unconstrained delegation).

Detection. Enumerate and alert on the existence of TRUSTED_FOR_DELEGATION on any non-DC; alert on 5136 writes to the delegation attributes; watch for the S4U2Self → S4U2Proxy pattern in 4769 from unexpected principals.

Hardening (mechanism-level). Remove unconstrained delegation everywhere it isn't strictly required (replace with constrained/RBCD); mark sensitive accounts "account is sensitive and cannot be delegated" and add them to Protected Users (their TGTs won't be cached/forwarded); tightly control who can write the delegation attributes; prefer gMSA identities for delegating services.

Significance. Delegation abuse is one of the cleanest paths to Domain Admin and is heavily configuration-driven — exactly the kind of thing Lab 02 surfaces and Lab 01 walks. The AllowedToDelegate/AllowedToAct edges in the path solver are these three delegations.

Misconceptions.

• "Constrained is safe because it's constrained." It's constrained to services, not to users; with protocol transition you impersonate any user to the allowed service.
• "RBCD needs domain admin to set up." It needs a write to one attribute on the target — frequently achievable from a DACL edge, which is why it pairs with Chapter 10 so often.

Chapter 8: Golden, Silver, and Diamond Tickets

Zero background. Once an attacker steals the right key, they can stop asking the KDC for tickets and start forging them. The three forgeries differ by which key they need and what they let you do.

Golden ticket. Forge a TGT using the krbtgt key (the NT hash or AES key of the krbtgt account, obtained via DCSync or a DC compromise). Because the TGT is the master ticket and is encrypted with the krbtgt key (Chapter 4), a forged TGT lets you be any user, in any group, for as long as you like — without the AS exchange at all. ATT&CK: T1558.001.

• Why it's so powerful: it skips authentication entirely; you mint your own identity and the KDC's own krbtgt key validates it.
• Why it's persistent: the only way to invalidate every golden ticket is to rotate the krbtgt password twice (twice, because the previous password is kept for one rotation).

Silver ticket. Forge a service ticket (TGS) using a service account's key (Chapter 4). It grants access to that one service as any user — but never touches the KDC, so there's even less telemetry than a golden ticket. ATT&CK: T1558.002.

• Why it's quiet: the service decrypts the forged TGS with its own key and trusts it; no 4768/4769 is generated because you never asked the KDC. It's scoped but stealthy.

Diamond ticket. A refinement: instead of forging a TGT from scratch (which can produce a PAC that doesn't match what a real KDC would issue and thus trips PAC-validation detections), the attacker requests a legitimate TGT and then modifies its decrypted contents (using the krbtgt key) before re-encrypting — yielding a ticket whose fields/PAC look like the KDC's own. It is harder to detect than a classic golden ticket precisely because it starts from a real ticket.

Under the hood — why detection is hard. These are valid tickets by construction: they decrypt correctly with the right key, so the cryptography accepts them. Detection therefore shifts from "is this ticket valid?" to behavioral and consistency signals: tickets with anomalous lifetimes, a logon (4624) with no preceding 4768, a username in a ticket that doesn't exist in the directory, PAC fields that don't match the account, or use of an account from an impossible location.

Telemetry / detection.

• Golden: 4624/4672 (privileged logon) without a corresponding 4768; tickets with non-default lifetimes; PAC-validation failures after the 2021–2022 hardening; nonexistent or mismatched usernames.
• Silver: essentially invisible to the DC — you must detect at the service (e.g., the service granting access with no matching 4769 on the DC) and via host EDR.
• The durable control: rotate krbtgt twice (kills golden/diamond), rotate service account keys / use gMSA (kills silver), and patch DCs for PAC validation.

Hardening (mechanism-level). Protect the krbtgt key like the crown jewel it is (it is the crown jewel); rotate it on a schedule and after any DC-compromise suspicion; minimize service-account key exposure with gMSA; enforce PAC-validation patches; constrain ticket lifetimes.

Significance. These are persistence and impersonation techniques, not initial access — they are how an attacker who already reached the DC stays and moves as anyone. They are why "we reset the admin passwords" after an incident is insufficient: until krbtgt is rotated (twice), golden tickets survive.

Misconceptions.

• "Resetting admin passwords removes a golden ticket." No — only krbtgt rotation (twice) does.
• "Silver tickets are louder than golden." The opposite — silver tickets never touch the KDC, so they generate less central telemetry; they're just narrower in scope.

Chapter 9: NTLM Relay, Coercion, Pass-the-Hash, and Pass-the-Ticket

Zero background. Two themes here: reusing stolen authentication material (you have a hash or a ticket, use it without the password) and relaying/coercing authentication (you make a victim authenticate and forward that authentication somewhere useful). Both lean on NTLM's structural weaknesses (Chapter 3).

Pass-the-hash (PtH, T1550.002). Because NTLM proves knowledge of the NT hash, not the plaintext (Chapter 3), an attacker who steals the NT hash from LSASS or the SAM/NTDS can authenticate as that user without cracking anything. The hash is the credential for NTLM.

Pass-the-ticket (PtT, T1550.003). The Kerberos analogue: steal a TGT or service ticket from a host's memory and inject it into your own session to act as that user, again without the password. (A golden/silver ticket is a forged ticket; PtT reuses a real stolen one.)

NTLM relay. NTLM has no server authentication and (by default) no channel binding, so a man-in-the-middle can take a victim's NTLM authentication aimed at server A and relay it to server B, authenticating to B as the victim. If B is a domain controller's LDAP, an MSSQL server, or ADCS web enrollment, the relayed auth can do real damage (e.g., grant the attacker rights, or — relaying to ADCS — obtain a certificate as the victim, Chapter 10).

Coercion (the PetitPotam idea). Relay needs a victim's authentication to relay. Coercion is making a privileged machine authenticate to you on demand by calling a Windows RPC method that triggers an outbound authentication — the family includes PetitPotam (MS-EFSRPC) and PrinterBug (MS-RPRN). The high-impact chain is: coerce a Domain Controller to authenticate to an attacker host, then relay that DC's NTLM authentication to ADCS to obtain a certificate for the DC's computer account, then use that certificate to act as the DC → domain compromise. (This is the conceptual chain; the lab never performs it — it reasons about the exposure and the detection.)

Coercion + relay (conceptual):
  attacker --RPC trigger--> DC          (PetitPotam/PrinterBug: "authenticate to me")
  DC       --NTLM auth----> attacker     (the coerced authentication)
  attacker --relay NTLM---> ADCS/LDAP    (act AS the DC)  => certificate / rights => domain compromise

Telemetry.

• PtH/PtT: 4624 logon type 3 with NTLM where it doesn't belong; logons with mismatched workstation/host fields; EDR detection of LSASS access (Sysmon 10) feeding the theft; a ticket in use with no preceding 4768 (PtT).
• Relay/coercion: a DC authenticating outbound to a non-DC (very abnormal); NTLM where Kerberos was expected; ADCS issuance (4886/4887) for a machine account via web enrollment; EFSRPC/MS-RPRN RPC calls to a DC.

Detection / hardening.

• Stop relay: enforce SMB signing (everywhere), LDAP signing + channel binding, and Extended Protection for Authentication (EPA) on ADCS web enrollment and other HTTP auth endpoints; disable NTLM where feasible.
• Stop coercion: patch (PetitPotam mitigations), restrict the vulnerable RPC interfaces, and remove web enrollment / require EPA on ADCS.
• Stop PtH/PtT: Protected Users group (no NTLM, no RC4, no delegation, shorter ticket life), Credential Guard (isolates secrets from LSASS), tiered admin and LAPS (so a stolen local-admin hash isn't reusable across machines).

Significance. This chapter is the bridge between "I have some credential material" and "I am the domain": relay+coercion turns a coerced machine authentication into privilege, and PtH/PtT turn stolen material into lateral movement. The controls here (signing, EPA, Protected Users, Credential Guard, LAPS, tiered admin) are the backbone of an AD-hardening roadmap.

Misconceptions.

• "We have strong passwords, so PtH doesn't matter." PtH never touches the password — only the hash. Password strength is irrelevant to it; tiered admin + LAPS + Credential Guard are the answer.
• "Relay is a legacy problem." Coercion (PetitPotam/PrinterBug) keeps it current; unsigned SMB/LDAP and ADCS web enrollment without EPA are common in 2020s networks.

Chapter 10: DACL Attack Edges and ADCS ESC1

Zero background. Chapter 2 introduced the security descriptor and ACEs. This chapter turns specific rights over objects into attack edges — the quiet, no-malware, no-CVE abuses that BloodHound exists to find — and then covers ADCS ESC1, a certificate-template misconfiguration that is a fast lane to Domain Admin.

The DACL attack edges (the GenericAll family).

Shadow credentials (under the hood). Modern Windows supports Key Trust logon: you can attach a public key to an account's msDS-KeyCredentialLink and then authenticate with the matching private key via PKINIT (certificate-based Kerberos). If you have GenericWrite/AddKeyCredentialLink over a victim, you write your own key, then request a TGT as the victim with no password reset (quieter and more reversible than ForceChangePassword). ATT&CK: T1556.

ADCS ESC1 (under the hood). AD Certificate Services (ADCS) issues certificates. Certificates can be used to authenticate (a cert maps to an account, and PKINIT logs you in as that account). ESC1 is a template that combines three misconfigurations:

1. The template allows client authentication (the cert can be used to log on), and
2. The template lets the enrollee supply the Subject Alternative Name (SAN) — i.e., you choose which account the cert is for, and
3. Low-privileged users may enroll.

Put together: a normal user enrolls a certificate, sets the SAN to a Domain Admin, and then authenticates with that certificate as the Domain Admin. No password, no cracking — a direct, fast path to DA. (SpecterOps's Certified Pre-Owned catalogs ESC1–ESC8; ESC1 is the canonical one.) ATT&CK: T1649 (Forge/Steal Authentication Certificates).

ESC1 in one line:
  low-priv user --enroll(template: clientAuth + enrollee-supplies-SAN, SAN = "Domain Admin")-->  CA
  CA --issues cert for "Domain Admin"-->  user  --PKINIT(cert)-->  TGT as Domain Admin

Telemetry.

• DACL abuse: 4662 / 5136 on the target object (attribute writes, SPN added, msDS-KeyCredentialLink written, owner/DACL change); 4724 for a forced password reset; 4728/ 4732/4756 for group additions.
• ADCS: 4886 (certificate requested) and 4887 (certificate issued) on the CA — the discriminator is a request whose SAN doesn't match the requester (an enrollee asking for a cert as someone else), and a follow-on 4768 PKINIT logon for that other account.

Detection. Audit object SACLs to generate 4662/5136 and alert on writes to sensitive attributes by non-admins; alert on 4886/4887 where the SAN ≠ the requester; enumerate certificate templates for the ESC1 combination (enrollee-supplied SAN + client auth + broad enrollment) and fix the template.

Hardening (mechanism-level).

• Templates: disable enrollee-supplied SAN, require manager approval for sensitive templates, restrict enrollment to the principals that actually need it, and remove client-auth EKU where not needed.
• DACLs: remove over-broad GenericAll/WriteDacl/WriteOwner/AddKeyCredentialLink from non-administrative principals on privileged objects; protect Tier-0 objects with AdminSDHolder and tight SACLs.
• PKINIT: enforce strong certificate mapping (the 2022 KB5014754 changes) so a cert can't be silently re-mapped to a privileged account.

Significance. DACL edges and ESC1 are the quietest, fastest AD escalation paths — no exploit, no malware, just misused rights — which is exactly why they dominate BloodHound paths and why Lab 01 includes them as first-class edges and Lab 02 (extension) checks for them.

Misconceptions.

• "Certificates are a defensive technology, not an attack surface." ADCS, misconfigured, is one of the fastest paths to DA in modern AD; certs authenticate, so a cert for the wrong account is a logon as that account.
• "AddKeyCredentialLink is obscure." Shadow credentials are a mainstream technique; the edge is a routine BloodHound finding.

Chapter 11: The BloodHound Graph Model

Zero background. Every prior chapter described one kind of relationship — group membership, an ACL right, a session, a delegation, a cert path. BloodHound is the tool that collects all of them and treats AD as what it really is: a directed graph. SharpHound is the collector (it queries LDAP and host sessions and writes JSON); BloodHound ingests that JSON into a graph database and lets you ask graph questions — chiefly, "what is the shortest path from this owned principal to Domain Admins?"

The model. Nodes are principals and objects: User, Computer, Group, OU, GPO, Domain, CertTemplate. Edges are directed, typed relationships that represent abusable control:

Nodes:  User · Computer · Group · OU · GPO · Domain · CertTemplate
Edges (a slice — each is an attack technique with a detection):
  MemberOf            group membership (transitive rights)             — no event alone
  AdminTo             local admin on a host (→ creds there)            — 4624/4672 on the host
  HasSession          a user is logged on (→ harvest their creds)      — 4624; LSASS access (Sysmon 10)
  CanRDP / CanPSRemote remote interactive / WinRM                      — 4624 type 10 / 5985-5986
  GenericAll/Write     full / attribute control of an object           — 4662 / 5136
  WriteDacl/WriteOwner rewrite the object's ACL/owner                  — 4670 / 5136
  ForceChangePassword  reset the victim's password                     — 4724
  AddKeyCredentialLink shadow credentials (PKINIT)                     — 5136; 4768 PKINIT
  AllowedToDelegate    constrained delegation                          — 4769 S4U
  AllowedToAct         resource-based delegation (RBCD)                — 5136; 4769 S4U
  ADCSESC1             enroll a cert as anyone                         — 4886/4887 (SAN ≠ requester)
  DCSync               replicate secrets from the DC                   — 4662 (replication GUIDs)

The core question — shortest path to Domain Admins. Once AD is a graph, "how does an attacker get from a foothold to domain dominance?" is literally a graph path query (BloodHound runs Cypher; e.g., shortestPath from an owned node to the Domain Admins node). And because some abuses are louder or costlier than others (cracking a ticket vs. reusing a live session vs. walking group membership), the right question is the weighted shortest path — the path of least resistance, not fewest hops. This is exactly Lab 01: edges carry a cost (attacker effort / detectability) and Dijkstra finds the quietest path.

The defender's dual — choke edges (dominators). The same graph answers the defender's question: which edges lie on every path from the foothold to the crown jewels? Remove one of those and you sever all those paths at once. These are the dominators / choke edges, and they are the highest-leverage remediations — far better than fixing dead-end leaf findings. This is the other half of Lab 01 (choke_edges), and the exposures Lab 02 finds are the edges you'd cut.

Under the hood — why weighting and choke analysis matter. A real forest has thousands of nodes and tens of thousands of edges; there are usually many paths to DA. Two insights make the analysis actionable: (1) attackers take the cheapest path, so weighting tells you which path to expect and detect first; (2) defenders can't fix everything, so choke-edge analysis tells you the few edges whose removal collapses the most paths. The combination — predict the quiet path, cut the dominators — is the entire defensive payoff of graphing AD.

Telemetry / detection. BloodHound itself is attacker reconnaissance and has a footprint: SharpHound generates a burst of LDAP queries (and session enumeration via SMB/RPC), so a sudden high-volume LDAP query pattern from a single host — especially queries for all users, groups, computers, ACLs, and SPNs — is a collection signal worth alerting on (some environments deploy a honey account/object whose enumeration is always malicious). Each edge in a found path has its own detection (the table above); the path is only as undetected as its quietest step.

Hardening. The graph is the roadmap: cut choke edges (remove dangerous ACEs, enforce tiered admin so HasSession/AdminTo edges from Tier-0 to Tier-2 vanish, convert service accounts to gMSA so the roastable edges disappear), then build the detection (the per-edge events) for every path you can't cut.

Significance. The graph model is the lingua franca of modern AD attack and defense. A red teamer who can collect, walk, weight, and explain the path — and hand the client the choke edges to cut and the detections to keep — is doing the staff-level job, not just "getting DA."

Misconceptions.

• "BloodHound finds vulnerabilities." It finds relationships. Every edge is, individually, a legitimate configuration; the attack is the chain. That's why remediation is graph surgery, not patching.
• "More paths = more secure if they're long." Length is hops, not cost. A single cheap GenericAll edge can be shorter in effort than a long chain — weight, don't count.

Lab Walkthrough

The two labs are the graph and the facts views of one directory. Do Lab 02 first if you want the exposures before the paths, or Lab 01 first if you want the algorithm spine; they are independent.

Lab 01 — AD attack-path solver (lab-01-ad-attack-path-solver/). Implement in this order:

1. nodes(edges) — every principal that appears as a src or dst. Trivial, but it underpins reachable_high_value.
2. shortest_path(edges, start, target) — Dijkstra over Edge.effective_cost(). Return the node path, the edge path (so you can label techniques), and the total cost. Handle start == target (((start,), (), 0.0)) and unreachable ((None, (), inf)). Use a heap and sorted adjacency for determinism — ties must break the same way every run.
3. path_cost — the cost component of shortest_path.
4. reachable_high_value(edges, start, high_value) — for each high-value node, path_cost and keep the reachable ones; sort by (cost, name). Compare names case-insensitively against the HV set.
5. choke_edges(edges, start, target) — BFS reachability with one edge removed; the edges whose removal disconnects the target are the choke points. Return sorted (src, dst, kind) keys.
6. path_techniques(edge_path) — map each edge kind through EDGE_CATALOG to its technique + detection; don't crash on an unknown kind — degrade to an UNKNOWN label.

Why this order: the path functions are the spine; reachable_high_value reuses path_cost; choke_edges is the defender's dual and needs only unweighted reachability; path_techniques is the detection-pairing layer that makes the output a report, not just a path.

Lab 02 — Kerberos exposure analyzer (lab-02-kerberos-exposure-analyzer/). Implement each check, then analyze:

1. kerberoastable — SPN on a user, skip gMSA; risk up for RC4, old password, and privilege. (Chapter 5.)
2. asrep_roastable — preauth_disabled accounts. (Chapter 6.)
3. delegation_risks — unconstrained_delegation (top risk) and rbcd_writable_by objects. (Chapter 7.)
4. privileged_with_spn — privileged user accounts carrying an SPN, flagged at the top tier. (Chapter 5.)
5. analyze — run all checks, sort by (risk desc, technique, account, title) — highest-impact, easiest-crack first, and deterministic.

Every finding must carry a detection (the right event id) and a hardening string — that pairing is the point. Run LAB_MODULE=solution pytest -q to see the reference pass (12 and 11 tests), fill in lab.py, then pytest -q until green.

Success Criteria

You understand this phase when you can, without notes:

• Draw the Kerberos ticket dance (AS-REQ → AS-REP → TGS-REQ → TGS-REP) and name every key and what the PAC carries — and place each attack on the specific message/key it abuses.
• Explain why a Kerberoast (TGS) and an AS-REP roast are offline-crackable, why RC4 makes the crack cheap, and why gMSA / AES-only / pre-auth are the real fixes — not "a strong password."
• Distinguish the three delegations and state how each is abused and detected, and why unconstrained on a non-DC is catastrophic.
• Explain golden vs silver vs diamond tickets by key and telemetry, and why krbtgt rotation (twice) is the only cure for golden/diamond.
• Trace coercion + relay to ADCS as a path to DA, and name the controls (SMB/LDAP signing, EPA, Protected Users, Credential Guard, LAPS, tiered admin) that break each step.
• Read a DACL edge (GenericAll, ForceChangePassword, AddKeyCredentialLink) and ESC1 and name the 4662/5136/4724/4886-4887 event that detects the abuse.
• Model AD as a weighted directed graph, find the quietest path to Domain Admins, rank the reachable high-value targets, and name the choke edges to cut — and pair every surviving edge with its detection.

If you can only run the tools but cannot explain the mechanism and name the event id and the fix for each step, you are not done.

Common Mistakes / OPSEC Failures

• Mapping a technique but not its telemetry. A Kerberoast you can't tie to 4769/etype-0x17, a DCSync you can't tie to 4662/replication-GUIDs, or an ESC1 you can't tie to 4886/4887 SAN ≠ requester fails this track's detection-pairing bar.
• "Strong password" as the Kerberoast fix. It raises cost; it doesn't stop the request and doesn't rotate. gMSA + AES-only + no SPN on privileged accounts is the mechanism-level answer.
• Confusing the three delegations or thinking "constrained = safe." Constrained limits services, not users.
• Thinking golden tickets are loud. They skip the AS exchange — no 4768 — which is why behavioral detection and krbtgt rotation matter more than any single event. And silver tickets are quieter still (no KDC contact).
• Chasing leaf findings over choke edges. Cut the dominators; don't grind dead-ends.
• OPSEC: mass SharpHound/LDAP bursts. Collection is loud — a single host enumerating all users, groups, computers, ACLs, and SPNs is a detection signal. On a real engagement you pace and scope it; in these labs there is no collection at all — synthetic data only.
• Forgetting RC4 is the tell. AES-only doesn't block the request but makes the crack expensive and the 4769-etype-0x17 detection meaningful.
• Treating AD as patchable. The dominant attacks are configuration and relationships — SPNs, delegation, ACLs, templates — not memory-corruption CVEs.

Interview Q&A

Q1. Walk me through the Kerberos ticket dance and name every key. Where does the krbtgt key sit? The client sends an AS-REQ to the KDC's Authentication Service, including pre-authentication — a timestamp encrypted with the user's key (derived from the password) — to prove identity. The KDC returns an AS-REP containing a TGT encrypted with the krbtgt key (so only the KDC can read it later) plus a session key blob encrypted with the user's key; the TGT carries a PAC of the user's SIDs and groups. To reach a service, the client sends the TGT plus the target SPN in a TGS-REQ; the TGS validates the TGT (it holds the krbtgt key) and returns a TGS-REP containing a service ticket encrypted with the target service account's key. The client presents that ticket to the service (AP-REQ), which decrypts it with its own key and reads the PAC. The krbtgt key sits at the root: it encrypts every TGT, so whoever holds it can forge a TGT for anyone — that's the golden ticket, and why krbtgt is the keys to the kingdom.

Q2. Explain Kerberoasting from first principles — why crackable, why any user, why RC4? The TGS-REP is encrypted with the service account's password-derived key and is handed to the requester, and any authenticated user may request a TGS for any SPN. So any user asks for a service ticket for, say, MSSQLSvc/db01, receives a blob encrypted with svc_sql's key, and cracks it offline — no lockout, no further AD interaction. RC4 (etype 0x17) derives the key straight from the NT hash (MD4 of the password), so a GPU brute-forces billions/sec; AES uses PBKDF2 with 4096 iterations + salt, making each guess far costlier. Detect via 4769 with etype 0x17 and one principal requesting many SPNs; harden with gMSA (128-char auto-rotated key), or AES-only + long random password + remove unused SPNs, and never an SPN on a privileged account.

Q3. AS-REP roasting vs Kerberoasting? Same offline crack, different message and precondition. Kerberoasting needs an SPN on a user (and a foothold) and cracks the TGS (a service account's key). AS-REP roasting needs pre-auth disabled (DONT_REQ_PREAUTH) — and not even a foothold — and cracks the AS-REP (the user's own key), because with pre-auth off the KDC hands the AS-REP to anyone. Detect AS-REP roasting via 4768 with pre-auth type 0; fix by re-enabling pre-authentication (and AES-only + strong password if a legacy app forces it off).

Q4. Compare unconstrained, constrained, and RBCD delegation. Why is unconstrained on a non-DC so bad? Unconstrained lets a host impersonate users to any service; to enable that the KDC puts each authenticating user's TGT in the service ticket and the host caches it — so compromising the host yields reusable TGTs for everyone who authenticated, and coercing a DC to authenticate there yields a DC's TGT → domain compromise. Constrained limits impersonation to a named SPN list via S4U2Self/ S4U2Proxy (with protocol transition you can impersonate any user to those services). RBCD inverts it: the target lists who may delegate to it via msDS-AllowedToActOnBehalfOfOtherIdentity, so a write to that attribute (a common DACL outcome) lets you impersonate any user to the target. Unconstrained on a non-DC is worst because it caches the most powerful artifact (a TGT) for everyone. Detect via 4769 S4U patterns and 5136 writes to the delegation attributes; harden with constrained/RBCD only, Protected Users, "sensitive — cannot be delegated," and tight write-control on those attributes.

Q5. Golden vs silver vs diamond tickets — keys, scope, telemetry? Golden forges a TGT using the krbtgt key → be any user, any group, domain-wide, with no AS exchange (no 4768). Silver forges a service ticket using a service account's key → access to that one service, and it never touches the KDC (no 4768/4769) so it's even quieter but narrower. Diamond uses the krbtgt key to modify a real TGT's contents, so its PAC/fields mirror a genuine KDC issuance and it's harder to detect than a from-scratch golden. They're valid by construction, so detection is behavioral/consistency: logon (4624) with no preceding 4768, anomalous ticket lifetimes, nonexistent usernames, PAC mismatches. The cure: rotate krbtgt twice (golden/diamond), rotate service keys / gMSA (silver), and PAC-validation patches.

Q6. What is NTLM relay, and how does coercion turn it into domain compromise? NTLM has no server authentication and no channel binding by default, so an attacker can relay a victim's NTLM authentication intended for server A to server B, acting as the victim on B. Coercion (PetitPotam/MS-EFSRPC, PrinterBug/MS-RPRN) forces a privileged machine to authenticate to the attacker on demand. The classic chain: coerce a DC to authenticate to the attacker, relay that to ADCS web enrollment, obtain a certificate as the DC's machine account, then use it to act as the DC → domain compromise. Break it with SMB signing, LDAP signing + channel binding, EPA on ADCS, removing web enrollment, patching the coercion vectors, and disabling NTLM where feasible.

Q7. Explain a DACL edge like GenericAll or ForceChangePassword. What does BloodHound show, and what detects the abuse? A DACL edge is a right one principal has over an object that can be abused without malware or a CVE. ForceChangePassword (the "Reset Password" extended right) lets you set a victim's password without the old one and log in as them; GenericAll is full control (reset password, add an SPN to roast, write msDS-KeyCredentialLink for shadow credentials/PKINIT, etc.); WriteOwner → owner → WriteDacl → GenericAll. BloodHound shows these as directed edges from your principal to the victim, with abuse info per edge. Detection is object auditing: 4662/5136 on the target (attribute/SPN/keyCredentialLink/ DACL writes), 4724 for a forced reset, 4728/4732/4756 for group additions. Fix by removing over-broad ACEs from non-admin principals on privileged objects and alerting on writes to sensitive attributes.

Q8. You have a foothold user and a SharpHound graph. How do you find the path to DA, choose the quietest, and tell the client which edge to cut first? Treat AD as a weighted directed graph: nodes are principals, edges are the abuses, each edge weighted by attacker effort/detectability. Run Dijkstra from the owned user to the Domain Admins node for the path of least resistance (not fewest hops — a cheap GenericAll may beat a long chain). Then compute choke edges (dominators) — edges on every path to DA — and tell the client to cut the highest-leverage one first (often a stale GenericAll, a help-desk ForceChangePassword, or a Tier-0 HasSession on a workstation), because removing it severs the most paths at once. Pair every surviving edge with its detection (4769/RC4, 4662/5136, 4724, 4886/4887) so the SOC keeps a durable control. That weighted-path + choke-edge + per-edge-detection package — exactly what Lab 01 produces — is the staff-level deliverable, not "we got DA."

References

• RFC 4120 — The Kerberos Network Authentication Service (V5) — the AS/TGS exchange, tickets, pre-authentication, and encryption types.
• Microsoft [MS-KILE] (Kerberos extensions) and [MS-PAC] (the Privilege Attribute Certificate) open specifications; the KB5008380 / KB5014754 PAC-validation and certificate-mapping hardening notes.
• SpecterOps research: the original Kerberoasting and AS-REP roasting writeups; An ACE Up the Sleeve (Robbins & Schroeder — DACL/ACE attacks); Certified Pre-Owned (Schroeder & Christensen — ADCS ESC1–ESC8).
• BloodHound documentation — node/edge taxonomy, abuse info, Cypher path queries (shortestPath).
• Microsoft Docs — Kerberos authentication, constrained/resource-based delegation, Protected Users security group, group Managed Service Accounts (gMSA), Windows security audit events (4624, 4662, 4670, 4724, 4728/4732/4756, 4768, 4769, 4776, 4886/4887, 5136).
• PetitPotam (MS-EFSRPC) and PrinterBug (MS-RPRN) coercion research and Microsoft's relay mitigations (SMB signing, LDAP channel binding, EPA).
• MITRE ATT&CK — T1558 (Steal or Forge Kerberos Tickets: .001 golden, .002 silver, .003 Kerberoasting, .004 AS-REP roasting), T1550 (Use Alternate Authentication Material: .002 PtH, .003 PtT), T1207 (Rogue DC / DCShadow), T1649 (Forge/Steal Authentication Certificates), T1098 (Account Manipulation), T1556 (Modify Authentication Process — shadow credentials), T1003.006 (DCSync).
• Windows Internals (Russinovich, Solomon, Ionescu) — tokens, SIDs, and the authentication stack.