« Red Team Engineer

Phase 05 — Active Directory & Identity Attacks

Operation Cedar Lattice, Phase 05. Phases 03–04 landed a foothold on Meridian Freight International's internal network and escalated locally on the first Windows and Linux hosts. Now the campaign turns to the part of an enterprise breach that decides everything: Active Directory. AD is the identity perimeter — the single system that decides who every user, computer, and service is and what they may touch. Once an attacker stands inside it with even an unprivileged account, the fight is no longer about exploiting software bugs; it is about abusing the identity relationships the domain was built on. This phase takes you from a foothold user to Meridian's Domain Admins along an attack path you can draw, weigh, and — as a defender — cut.

The deliverable a real engagement produces here is not "we got DA." It is the attack-path graph from foothold to domain dominance, every Kerberos and DACL abuse on it mapped to ATT&CK and to the exact Windows event that detects it, and the prioritized identity-hardening roadmap — the artifact the purple team replays and the client keeps.

Safety. Authorized-lab only. Every lab in this phase is a graph-solver / exposure-analyzer / detection-mapper over synthetic directory metadata — a directory graph of users, groups, computers, ACLs, SPN lists, and delegation flags. There are no live AD attacks, no collection, no ticket requests, no cracking, and no weaponization. Every attack ends in its detection (Kerberos/Windows event ids) and its hardening. This is the same boundary as the security track's offensive-methodology-mastery/ labs.

Why this phase exists

Almost every published enterprise intrusion — and every Mandiant M-Trends year — runs through Active Directory. The reason is structural: AD is old, central, and trusting by default. It speaks Kerberos and NTLM, protocols designed when the network was the trust boundary; it stores access-control lists on every object that almost no one audits; and it supports delegation features that, misconfigured, let one machine act as anyone. An attacker who understands AD does not need a single CVE to go from a help-desk account to the entire forest — they need to read the graph of relationships and walk it.

This is also where the offensive and defensive jobs fuse. Every AD attack technique has a precise telemetry signature — a 4769 with RC4 encryption for a Kerberoast, a 4768 without pre-auth for an AS-REP roast, a 4662 with replication GUIDs for DCSync, a 5136 write for an RBCD takeover. A red teamer who cannot name the event the SOC should have alerted on has done half the job. The skill this phase trains is to walk the path and write the detection for every step of it.

Learning Objectives

By the end of this phase you can, without notes:

1. Explain the AD object model — users, groups, computers, OUs, the schema, security descriptors (owner + DACL + ACEs), SIDs, and how a security principal's effective rights are computed.
2. Contrast NTLM and Kerberos authentication and state precisely why Kerberos exists, what each protects, and where each still leaks.
3. Walk the Kerberos ticket dance end to end — AS-REQ → AS-REP → TGS-REQ → TGS-REP — naming every key involved (the user's key, the krbtgt key, each service's key) and what the PAC carries.
4. Explain Kerberoasting (T1558.003) and AS-REP roasting (T1558.004) from first principles — why an SPN or disabled pre-auth makes a reply crackable offline, and why RC4 vs AES decides the crack — and the detection and hardening for each.
5. Distinguish the three delegations — unconstrained, constrained (S4U2Self/S4U2Proxy), and resource-based (RBCD) — and how each is abused and detected.
6. Explain golden, silver, and diamond tickets — what key forges each, what privilege each grants, and the limited telemetry that catches them.
7. Explain NTLM relay and authentication coercion (the PetitPotam idea) and pass-the-hash / pass-the-ticket — and the controls (SMB signing, EPA, Protected Users) that stop them.
8. Read DACL attack edges — GenericAll, WriteDacl, WriteOwner, ForceChangePassword, AddKeyCredentialLink — and the object-auditing events that detect their abuse.
9. Explain ADCS ESC1 (a certificate template that lets a low-priv user enroll a cert authenticating as anyone) and its issuance telemetry.
10. Model AD as a BloodHound-style graph and compute the shortest/quietest attack path to Domain Admins, the reachable high-value targets, and the choke edges a defender must cut.

The two questions this phase answers

ATTACKER:  from this owned, unprivileged account, what is the cheapest, quietest chain of
           identity abuses that reaches Domain Admins?                         → Lab 01 (the graph)

DEFENDER:  which accounts and objects are exposed (Kerberoastable, AS-REP-roastable, dangerously
           delegated, dangerously ACL'd), how do I rank them, and what is the detection + fix?
                                                                                → Lab 02 (the facts)

The graph (Lab 01) and the facts (Lab 02) are two views of one directory: the exposures Lab 02 finds are the edges Lab 01 walks, and fixing an exposure removes an edge.

Concepts

Labs

Each lab follows LAB-STANDARD.md: lab.py (TODOs), a complete solution.py, adversarial test_lab.py, README.md, requirements.txt — pure Python 3 (stdlib + pytest), offline, deterministic, with the detection pairing built in.

cd lab-01-ad-attack-path-solver
LAB_MODULE=solution pytest -q   # reference passes (12 tests)
pytest -q                        # your implementation after the TODOs

cd ../lab-02-kerberos-exposure-analyzer
LAB_MODULE=solution pytest -q   # reference passes (11 tests)

Deliverables

• An AD attack-path solver that models the directory as a typed, weighted graph, finds the cheapest/quietest path from an owned principal to Domain Admins, enumerates the reachable high-value targets, identifies the choke edges a defender cuts to break the most paths, and labels every step with its ATT&CK technique and the Windows/Kerberos event that detects it.
• A Kerberos/identity exposure analyzer that reads synthetic directory facts and produces a risk-ranked findings report — Kerberoastable (RC4 + old password ranked highest), AS-REP-roastable, unconstrained-delegation, RBCD-writable, and privileged-SPN accounts — each paired with its detection and mechanism-level hardening.
• The Operation Cedar Lattice Phase 05 artifact: the path graph from Meridian's foothold user to its Domain Admins, the exposure report behind it, and the identity-hardening roadmap (gMSA, AES-only, tiered admin, Protected Users, dangerous-ACL removal) with the detection for every surviving edge.
• The fluency to walk the Kerberos dance, the three delegations, the ticket forgeries, and the BloodHound model in an interview, and to name the detection and the fix for each.

Readings (primary sources)

• RFC 4120 — The Kerberos Network Authentication Service (V5) (the ticket dance, the keys, the PAC concept); Microsoft's [MS-PAC] and [MS-KILE] specifications.
• SpecterOps research: the original Kerberoasting/AS-REP roasting writeups, An ACE Up the Sleeve (DACL attacks), and Certified Pre-Owned (ADCS ESC1–ESC8).
• BloodHound documentation — the node/edge model, the abuse info per edge, and Cypher.
• Microsoft docs on Kerberos, delegation (unconstrained/constrained/RBCD), Protected Users, gMSA, and the security audit events (4768, 4769, 4624, 4672, 4662, 4724, 4728, 5136, 4886/4887).
• MITRE ATT&CK: T1558 (Steal or Forge Kerberos Tickets) and sub-techniques, T1550 (Use Alternate Authentication Material — PtH/PtT), T1207 (Rogue Domain Controller / DCShadow), T1649 (Forge Authentication Certificates), T1098 (Account Manipulation).
• Windows Internals (Russinovich, Solomon, Ionescu) on tokens, SIDs, and the authentication stack.

Common Mistakes

• Treating AD as a list of permissions instead of a graph. The attack is the chain of edges, not any single right. If you cannot draw the path, you cannot cut it.
• Demonstrating a technique without its telemetry. A Kerberoast you cannot tie to 4769/RC4, or a DCSync you cannot tie to 4662/replication GUIDs, fails this track's detection-pairing bar.
• Confusing the three delegations. Unconstrained caches every TGT; constrained limits to named SPNs via S4U; RBCD is configured on the target — they are abused and detected differently.
• Calling UAC, group membership, or "we set a strong password" a fix for Kerberoasting. The fix is gMSA / AES-only / no SPN on privileged accounts, because the crack is offline and the only real defenses are key strength and key rotation you don't control with a human password.
• Thinking a golden ticket is loud. A forged TGT skips the AS exchange entirely — there is no 4768 — which is exactly why krbtgt rotation and behavioral detection matter more than a single event.
• Chasing leaf findings over choke edges. Removing one stale GenericAll that every path runs through beats remediating ten dead-end exposures. Prioritize the dominators.
• Forgetting that RC4 is the tell. AES-only doesn't stop a request, but it makes the crack expensive and makes the 4769-etype-0x17 detection meaningful.

Interview Questions

1. Walk me through the Kerberos ticket dance — AS-REQ to TGS-REP — and name every key involved. Where does the krbtgt key sit, and why is it the keys to the kingdom?
2. Explain Kerberoasting from first principles. Why is the TGS reply crackable offline, why does any domain user get to ask for it, and why does RC4 vs AES matter? How do you detect and harden it?
3. What is AS-REP roasting, and how is it different from Kerberoasting? What single account flag enables it, and what is the fix?
4. Compare unconstrained, constrained, and resource-based delegation. How is each abused, and what makes unconstrained delegation on a non-DC so dangerous?
5. What is a golden ticket vs a silver ticket vs a diamond ticket? What key forges each, what does each let you do, and why are they hard to detect?
6. What is NTLM relay, and how does authentication coercion (PetitPotam-style) turn it into domain compromise? Which controls break it?
7. Explain a DACL attack edge such as GenericAll or ForceChangePassword. What does BloodHound show, how would you abuse it, and which audit event detects the abuse?
8. You have a foothold user and a SharpHound graph. How do you find the path to Domain Admins, decide which is the quietest, and tell the client which single edge to cut first?

(Full principal-level answers are in WARMUP.md.)

Portfolio artifact

The Operation Cedar Lattice Phase 05 identity package: the attack-path graph from Meridian's foothold user to its Domain Admins (Lab 01 output) with every edge labeled by ATT&CK technique and detection; the risk-ranked exposure report behind it (Lab 02 output); and a one-page identity- hardening roadmap — gMSA migration, AES-only, tiered admin, Protected Users, dangerous-ACL removal, krbtgt rotation — with the detection for every surviving edge. All over synthetic directory metadata: no live AD, no collection, no weaponization. This is part of 04-05-windows-ad/ in the capstone portfolio.

Guides

• WARMUP.md — the from-zero, chapter-by-chapter deep dive: the AD object model and ACLs; NTLM vs Kerberos; the ticket dance under the hood; Kerberoasting and AS-REP roasting; the three delegations; golden/silver/diamond tickets; NTLM relay and coercion; DACL attack edges; ADCS ESC1; and the BloodHound graph model — each with its telemetry, detection, and misconceptions.
• HITCHHIKERS-GUIDE.md — how to run this safely on an owned, purpose-built GOAD-style forest: collect with SharpHound, find the path to DA in BloodHound, demonstrate a Kerberoast against a lab SPN, then harden (gMSA, AES-only, tiered admin, dangerous-ACL removal) and write the 4769-RC4 detection. Never a production domain.