Hitchhiker's Guide — Walking an AD Attack Path on an Owned Forest

The operator's range walkthrough for Phase 05. The WARMUP explained the mechanism of every AD identity attack; the labs reason over synthetic directory metadata. This guide is how you safely practice the real workflow on an owned, purpose-built forest — collect with SharpHound, find the path to Domain Admins in BloodHound, demonstrate a single Kerberoast against a lab SPN, then harden (gMSA, AES-only, tiered admin, dangerous-ACL removal) and write the detection — and prove the path is closed.

The boundary, stated once and meant absolutely. Everything here happens on a forest you built, own, and can destroy — a GOAD-style range or your own lab DC — that is network-isolated from home, corporate, and the internet. Never a production domain. Never a domain you do not own. If you cannot name the owner, the scope, the stop conditions, and the deconfliction contact, you do not run the step. This is the same rule as Phase 00.

Table of Contents

• 1. What You Are Building and Why
• 2. The Range — An Owned, Isolated Forest
• 3. Turn On the Telemetry First
• 4. Collect — SharpHound on the Owned Forest
• 5. Find the Path — BloodHound to Domain Admins
• 6. Demonstrate One Kerberoast Against a Lab SPN
• 7. Harden — gMSA, AES-Only, Tiered Admin, Remove Dangerous ACLs
• 8. Write the Detection — 4769 RC4 and Friends
• 9. Verify Effective State, Not Intended Config
• 10. The Evidence Packet
• 11. Teardown and Cost/Safety Controls
• 12. Common False Claims
• 13. Map Back to the Labs

1. What You Are Building and Why

A red team consultant's AD deliverable is not "we got Domain Admin." It is a reproducible package: the path from a foothold to domain dominance, every edge mapped to ATT&CK and to the exact event that detects it, the choke edge to cut first, the hardening that closes the path, and the proof — by re-collection — that the path is gone. This guide produces that package on an owned forest so you can do it for a client (under contract) without ever touching their production domain to learn it.

The loop you will run — and the one the labs encode — is:

  authorize → turn on telemetry → collect → graph the path → demonstrate ONE technique safely →
  observe the telemetry it emits → harden the mechanism → re-collect → prove the path is closed →
  write the durable detection → tear down

2. The Range — An Owned, Isolated Forest

Use a purpose-built vulnerable forest designed for exactly this — GOAD (Game of Active Directory) is the common choice — or build your own minimal forest. Either way:

                 [ isolated host-only / internal vSwitch — NO route to home/corp/internet ]
                   |                      |                         |
            DC01 (forest root)     SRV02 (member server)     WS01 (Win10/11 client)
            AD DS, DNS, KDC        a service w/ an SPN        the "foothold" workstation
            ADCS (optional)        unconstrained deleg.       SharpHound runs here
                   |                      |                         |
                   +----------- detection host (Sysmon + WEF/SIEM: Wazuh/Elastic) ----------+

Hard rules (same spirit as the README's range section):

• The forest is owned and isolated. Snapshot every VM before you start so you can roll back.
• No real credentials, no real user data, no production anything — the accounts, SPNs, and ACLs are deliberately seeded weaknesses you put there.
• Decide stop conditions up front (e.g., "stop at one demonstrated Kerberoast and one path to DA; do not pivot to the host OS; do not exfiltrate"). On a client engagement these come from the ROE.
• Keep a deconfliction note: if this were a client, who do you call when an alert fires? Practice writing it even on the range.

3. Turn On the Telemetry First

You cannot claim a detection you never had the logging to see. Before any attack step, enable on the DCs and hosts:

• Kerberos auditing: Audit Kerberos Authentication Service (→ 4768) and Audit Kerberos Service Ticket Operations (→ 4769) — Success and Failure.
• Logon auditing: Audit Logon (→ 4624/4625) and Audit Special Logon (→ 4672).
• Directory Service auditing: Audit Directory Service Access and Changes (→ 4662/5136) and set SACLs on the high-value objects (privileged groups, service accounts, the domain object) so those events actually fire.
• ADCS auditing (if you deployed ADCS): CA auditing for 4886/4887 (request/issue).
• Sysmon on every host (LSASS access = event 10, process create = 1), forwarded via WEF to your SIEM (Wazuh/Elastic) on the detection host.

Expected baseline observation: with the forest idle, you should see routine 4768/4769 from normal logons. Capture this baseline — your detections must distinguish attack from this noise.

4. Collect — SharpHound on the Owned Forest

From the foothold workstation (WS01), running as a normal domain user (this is the point — recon needs no privilege), run SharpHound to collect the directory graph:

SharpHound  →  queries LDAP for users, groups, computers, ACLs, SPNs, delegation flags,
               and enumerates sessions/local-admin via SMB/RPC  →  writes a ZIP of JSON

Expected observations (this is itself a detection lesson):

• A burst of LDAP queries from one host asking for everything — all users, groups, computers, ACLs, SPNs. In a real environment this volume/pattern is anomalous and alertable.
• Session/local-admin enumeration generates SMB/RPC traffic to many hosts.
• On the range you will tune a "collection" detection (high-volume LDAP from a single non-admin host; or any touch of a honey object you planted) so you carry a real detection back, not just an attack.

You now have the JSON the labs simulate. (Lab 01's extension ingests exactly this kind of export.)

5. Find the Path — BloodHound to Domain Admins

Ingest the SharpHound JSON into BloodHound and ask the graph the operator question:

• Shortest path from your owned principal to the Domain Admins node (BloodHound's built-in query, or Cypher shortestPath). Expect a chain like WS01-user → (MemberOf) → Help Desk → (ForceChangePassword) → svc_admin → (MemberOf) → Domain Admins, or a delegation/ADCS path you seeded.
• Pre-built queries: "Find all Domain Admins," "Shortest paths to Domain Admins," "Find principals with DCSync rights," "Kerberoastable accounts," "Accounts with unconstrained delegation."

Map what BloodHound shows to the labs: each edge BloodHound draws is one of Lab 01's Edge kinds (MemberOf, ForceChangePassword, AllowedToDelegate, ADCSESC1, DCSync, …). The path of least resistance and the choke edge are what Lab 01's shortest_path and choke_edges compute over the synthetic version. Record the path and the choke edge — you'll prove you closed it in step 9.

Expected observation: the graph almost always reveals a path you did not design — that's the lesson of dense, unaudited ACLs.

6. Demonstrate One Kerberoast Against a Lab SPN

Pick one seeded service account on the range (e.g., svc_sql with MSSQLSvc/srv02 and a deliberately weak password) and demonstrate a single Kerberoast — on the owned forest only, at minimum proof:

1. As a normal user, request a TGS for that SPN (a legitimate Kerberos request).
2. Observe the 4769 the DC logs — note Service Name = the SPN and Ticket Encryption Type = 0x17 (RC4).
3. Crack the ticket offline against a wordlist that contains the lab password you set — the point is to see the mechanism and the telemetry, not to break strong crypto. Stop the moment you've recovered the lab password.

Expected observations:

• A 4769 with etype 0x17 for the SPN appears in the DC log / SIEM.
• If you roast several SPNs at once, one principal requests many 4769s in a short window — the mass-roast pattern.
• Cracking produces no further AD telemetry (it's offline) — which is exactly why the request (4769/RC4) is the only chance to detect it.

Stop conditions honored: one account, minimum proof, no pivot into the host OS, no lateral movement beyond demonstrating the path. (On a client engagement, this is where the ROE's "demonstrate, don't exploit further" clause lives.)

7. Harden — gMSA, AES-Only, Tiered Admin, Remove Dangerous ACLs

Now do the part that makes you a consultant and not a CTF player — fix the mechanism for each thing you demonstrated, then prove it:

• Kerberoast → gMSA / AES-only. Convert the service account to a group Managed Service Account (128-char auto-rotated key — uncrackable) or, if a human-managed account is unavoidable, set a long random password and AES-only (msDS-SupportedEncryptionTypes = AES) and remove unused SPNs. Never leave an SPN on a privileged account.
• The choke edge → remove the dangerous ACL. Delete the over-broad GenericAll/WriteDacl/ForceChangePassword/AddKeyCredentialLink ACE that the BloodHound path ran through. This is the highest-leverage single change — it should sever the path.
• Tiered admin. Enforce that Domain Admins never log on to Tier-2 hosts (workstations/member servers), so the HasSession/AdminTo edges from Tier-0 to lower tiers disappear; deploy LAPS so a stolen local-admin hash isn't reusable across machines.
• Delegation hygiene. Remove unconstrained delegation from any non-DC; put sensitive accounts in Protected Users and mark them "sensitive — cannot be delegated"; tightly control who can write the delegation attributes.
• (If ADCS) ESC1. Disable enrollee-supplied SAN, require manager approval, and restrict enrollment on any client-auth template.

8. Write the Detection — 4769 RC4 and Friends

For the technique you demonstrated, write the durable detection the client keeps. The flagship is the Kerberoast detection:

Detection: Kerberoasting via RC4 service tickets (ATT&CK T1558.003)
  Source:   Security 4769 (a Kerberos service ticket was requested)
  Fire when: Ticket Encryption Type == 0x17 (RC4)
             AND the target SPN's account should be AES-only (or is a honey-SPN account)
  Escalate:  one Account Name requests 4769 for many distinct Service Names in a short window
  Tune out:  known legacy RC4 services (and migrate them); normal AES (etype 0x12/0x11) traffic

Add the companions for whatever else you demonstrated:

• AS-REP roast: 4768 with Pre-Authentication Type = 0.
• DCSync: 4662 containing the DS-Replication-Get-Changes GUIDs from a non-DC principal.
• DACL abuse / shadow creds: 5136 writes to servicePrincipalName, msDS-KeyCredentialLink, or msDS-AllowedToActOnBehalfOfOtherIdentity; 4724 for a forced password reset.
• ESC1: 4886/4887 where the SAN ≠ the requester.
• Collection (SharpHound): anomalous high-volume LDAP from a single non-admin host, or any touch of a honey object.

Express each as a Sigma-style rule in your SIEM and confirm it fires on the captured evidence — a detection you haven't seen fire is a hypothesis, not a control.

9. Verify Effective State, Not Intended Config

The discipline that separates a real consultant from a checkbox: prove the effective state, not the intended config. "I converted it to a gMSA" is a claim; re-collect and re-graph is proof.

• Re-run SharpHound and re-open BloodHound. The path you recorded in step 5 should be gone — the Kerberoastable edge no longer exists (gMSA), the choke ACL edge is removed, the delegation flag is cleared.
• Re-attempt the Kerberoast on the now-gMSA account: the 4769 still appears (the request is always allowed), but the etype should be AES and the offline crack should fail — that's the mechanism working, not just a setting changed.
• Confirm legitimate behavior still works: the service still authenticates and runs as the gMSA; normal users still log on. A fix that breaks production is not a fix.
• Confirm the detection fires on the captured attack evidence and does not fire on the baseline from step 3.

Only now can you write "path closed, verified by re-collection; detection fires on evidence; service unaffected."

10. The Evidence Packet

Assemble a sanitized, reproducible packet — the same shape a client report uses:

• The before BloodHound path (foothold → Domain Admins) with each edge's ATT&CK technique.
• The demonstrated technique (one Kerberoast): the 4769/RC4 event, the minimum-proof crack result (lab password only), stop conditions honored.
• The choke edge identified and the hardening applied (gMSA, ACL removal, tiered admin, delegation/ADCS fixes).
• The after BloodHound re-collection showing the path is gone and the re-attempt failing.
• The detection (Sigma-style) with proof it fires on the evidence and not on the baseline.
• A hash of each artifact, with source/time/collector/timezone. No real credentials, no production data, no weaponized artifacts — synthetic/owned only.

This packet is the per-host instance of the Operation Cedar Lattice Phase 05 portfolio artifact.

11. Teardown and Cost/Safety Controls

• Roll back to the pre-engagement snapshots (or destroy and rebuild the forest) when done — never leave a deliberately weakened forest running.
• If any range component is cloud-hosted, set budgets, quotas, alerts, and teardown automation before building, and confirm everything is destroyed after.
• Scrub evidence of anything that shouldn't persist; keep only what's needed to explain and remediate.
• Confirm the range never had a route off the isolated segment.

12. Common False Claims

• "We got Domain Admin, so the forest is owned." Getting DA on a deliberately vulnerable owned range proves you can run the workflow — it is not a finding about a client and not evidence of skill until you also produced the path, the detection, the fix, and the verified closure.
• "gMSA conversion done." Not until you re-collected and the Kerberoastable edge is gone and the re-attempt's crack fails — verify effective state.
• "We have a Kerberoast detection." Not until it fired on the captured 4769/RC4 evidence and stayed quiet on the baseline. A rule that never fired is untested.
• "Silver/golden tickets would show in 4768/4769." Silver tickets never touch the KDC (no central event); golden tickets skip the AS exchange (no 4768). Don't claim a Kerberos-event detection for forgeries that bypass those events — detect them behaviorally and rotate krbtgt twice.
• "Strong passwords fixed Kerberoasting." They raise crack cost; the request still happens and a human password rotates rarely. gMSA + AES-only is the mechanism fix.
• "This is just like a real engagement." It is the workflow, on an owned forest. The boundary that makes a real engagement legal is the contract, scope, and authorization — never reachability.

13. Map Back to the Labs

The labs let you build, test, and reason about all of this offline over synthetic data — no forest, no risk. This guide is how you turn that understanding into a verified, reproducible package on a forest you own. The two together are the Phase 05 skill: walk the path, write the detection, cut the choke edge, and prove it.