# AD Trusts & Forest Attacks

> Forest is the real security boundary. Escalate from child-domain DA to Enterprise Admin via SID history, trust-key forgery, and cross-forest Kerberoasting.

- **URL:** https://hackindex.io/learn/pt2-penetration-tester-level-2-study-path/ad-trusts-and-forest-attacks
- **Certification:** [PT2 (Penetration Tester Level 2) Study Path](https://hackindex.io/learn/pt2-penetration-tester-level-2-study-path.md)
- **Estimated study hours:** 10
- **Published:** 2026-10-04
- **Updated:** 2026-10-04

A single domain is a management boundary, not a security boundary. The forest is. Compromise any domain in a forest and the rest are within reach, because intra-forest trusts do not filter SIDs by design. Cross-forest trusts do filter, but filtering fails in common misconfigurations. PT2 tests whether you can enumerate the trust topology, pick the right primitive for each trust type, and reach from child Domain Admin to Enterprise Admin across every domain the forest holds.

## Enumerate First

`Get-ADForest`, `Get-ADTrust`, `nltest`, and PowerView surface the full trust map. The `IntraForest` flag separates intra-forest (no SID filtering, exploitable without any misconfiguration) from cross-forest (SID filtered, requires a weaker primitive). The `trustAttributes` bitmask reveals SID-filtering state, selective authentication, and transitivity per trust.

## Child Domain To Enterprise Admin

Classic intra-forest escalation. From Domain Admin in a child domain, DCSync the child `krbtgt`, forge a golden ticket in the child, inject the forest root's Enterprise Admins SID (`<root-domain-SID>-519`) as an ExtraSid in the PAC. The root domain honours the SID because the trust does not filter it. Alternative path: dump the child-parent trust key with `lsadump::trust /patch`, forge an inter-realm referral ticket signed with the trust key, exchange with Rubeus for a service ticket in the root.

## Cross-Forest

SID filtering blocks the ExtraSid primitive at the forest boundary. The usual replacements are Kerberoasting SPNs across the trust (user hashes crack the same regardless of forest), ADCS misconfigurations on the trusted forest's CA (ESC templates that trust foreign principals), and compromise of forest trust accounts themselves (`domain$` accounts hold the trust key). SID history remains viable where SID filtering was deliberately disabled, usually left over from a legitimate migration.

## PAM Trust And Shadow Principals

Privileged Access Management forests introduce bastion-forest trusts with SID filtering explicitly disabled on the privileged-SID side, by design. Compromise of the PAM forest grants privileged SIDs into every joined forest it serves.

## Chaining

Trust abuse is almost always the final step. Reaching Domain Admin in any one domain of a forest is the preceding work; the trust walk from there is quick when the trust topology is already mapped.

## Study material

- [Domain Trust Abuse](https://hackindex.io/platforms/active-directory/post-exploitation/ad-domain-trust-abuse.md) (read, core)
- [Cross-Forest Trust Abuse](https://hackindex.io/platforms/active-directory/post-exploitation/ad-cross-forest-trust-abuse.md) (read, core)
