Child Domain Admin and the Parent SID History Ticket
You are a Domain Admin in the child domain eu.corp.local. The forest root is corp.local; parent and child are in the same forest, so SID filtering is not enabled between them. You have the child krbtgt hash and can forge Kerberos tickets. A firewall between the child and parent permits TCP 88 and 445 from the child to parent domain controllers and member servers, but blocks LDAP 389/636. You do not have parent credentials. The client authorizes proof of Tier 0 access but forbids modifying parent domain controller configuration. You have two hours for the proof and a 30-day retest window afterward. Parent monitoring includes Microsoft Defender for Identity and advanced audit; a previous tester was detected after using a SID-history ticket with the built-in Administrator RID 500. You need a defensible path to a parent Tier 0 resource and a persistence recommendation.
1. What is the minimum reliable proof of parent Tier 0 access from the child DA, and what would you verify before forging a ticket?
Read the worked answer
First verify the trust and SID-filtering state, even though same-forest parent/child normally has SID filtering disabled. Then obtain the parent domain SID, not just the child SID. The minimum proof is not a parent DC login; it is a service ticket for a parent member server using a forged child TGT that carries the parent Enterprise Admins SID in SID history. I would use a non-RID-500 child identity and target one low-profile parent member server over CIFS/445, not a DC, to show Tier 0-equivalent access with minimal blast radius. Before forging, I would confirm time sync, because Kerberos tolerates only about five minutes of skew, and confirm that 88/445 are actually open to the chosen target. I would avoid the built-in Administrator name because the previous tester was detected that way. The proof should be a single authenticated access with a timestamp, not a broad sweep. This is a judgement call: the child DA already controls the child, so the real question is whether parent monitoring detects the cross-domain SID-history use.
2. How would you move from proof to parent domain compromise without modifying parent DC configuration, and what are the detection tradeoffs?
Read the worked answer
Once the SID-history ticket reaches a parent member server with Enterprise Admins-equivalent rights, I would use that access to perform DCSync against a parent DC over 445. DCSync reads replication data and does not require changing DC configuration, which fits the client constraint. It would give the parent krbtgt hash and allow a parent golden ticket, but it is also one of the highest-fidelity MDI alerts. The tradeoff is speed versus stealth: DCSync is fast and reliable but likely to be caught; a certificate-based path through parent AD CS might be stealthier, but only if 443 to the CA is available and the template is misconfigured. I would not use the RID 500 account or a broad SID-history spray. If the goal is a defensible proof, one DCSync of a single parent account or krbtgt with a narrow filter is enough; pulling the entire domain is unnecessary and noisy. I would document the exact replication rights used so the client can audit 4662 events.
3. Recommend persistence and remediation. Why not rely on SID history alone?
Read the worked answer
I would not rely on SID history as persistence. It depends on the child krbtgt and on parent acceptance of cross-domain SIDs, and it is exactly the behavior MDI flags. A better persistence option, if authorized and if the parent CA is reachable, is a certificate issued to a controlled parent identity, because certificate authentication can survive password and krbtgt resets. A parent golden ticket after DCSync also works but is high-detection and should be treated as a last resort for proof, not a durable implant. Remediation order: reset the child krbtgt twice; if DCSync occurred, reset the parent krbtgt twice; rotate Enterprise Admins and any account whose hash was replicated; review SID history and 4765/4766 events; audit DCSync rights and 4662; and restrict child-domain administrators from parent Tier 0 resources. Long term, separate Tier 0 into its own forest or enforce an administrative tier model, because a child DA is effectively a forest-level risk when SID filtering is absent.