Active Directory Tradecraft: Trust Abuse & Lateral Movement Trust misconfigurations // Cross-forest paths // ADCS ESC1–ESC8 // DCSync mechanics

Active Directory trusts exist to let security principals in one domain authenticate against resources in another. That single sentence is also the entire attack surface of this article — every technique below is a variation on convincing a trust boundary to honor an identity it shouldn't. Before touching exploitation, an operator needs the model straight: direction, transitivity, and authentication scope govern what a trust actually permits.

• Direction — a one-way trust from A to B means A trusts B's principals; users in B can authenticate to resources in A, not the reverse. Two-way trusts collapse that distinction.
• Transitivity — parent-child and tree-root trusts within a forest are transitive by default. External and forest trusts are non-transitive unless explicitly configured, which caps blast radius — in theory.
• Authentication scope — forest-level trusts can be restricted with selective authentication, requiring explicit ACE grants on target computer objects before a foreign principal can even attempt logon. Most environments never turn this on.

Every trust is backed by a Trusted Domain Object (TDO) holding the shared trust key and a set of security attributes — most importantly TRUST_ATTRIBUTE_QUARANTINED_DOMAIN (SID filtering) and TRUST_ATTRIBUTE_FOREST_TRANSITIVE. Operators should pull this from the target early: Get-DomainTrust, nltest /domain_trusts, or BloodHound's trust edges all surface it. The TDO's flags tell you which of the following techniques are even in scope before you burn time on them.

SID History Injection & Filtering Gaps

The sIDHistory attribute exists for domain migrations — it lets a principal retain access from a legacy domain SID after being moved. When SID filtering is not enforced on a trust (common on intra-forest parent-child trusts, which don't filter by default), an attacker with domain-level compromise on one side can inject a privileged foreign SID — commonly the target domain's Enterprise Admins or Domain Admins RID — into a principal's sIDHistory. Kerberos then honors that SID inside the PAC on the next ticket issued, and the resource domain grants access as if the principal were a native member of the privileged group.

Unconstrained Delegation as a Trust Pivot

A computer object flagged for unconstrained delegation caches the full TGT of any principal that authenticates to it. Domain controllers and shared services are the classic targets. If a DC on either side of a trust — or any box in the trust path — holds unconstrained delegation, coercing an authentication from a privileged account (via PrinterBug/PetitPotam-class coercion over MS-RPRN or MS-EFSR) hands you a cached, reusable TGT without ever touching credentials. Combined with a trust hop, this converts a foothold in a low-value domain into a ticket usable against a high-value one.

Foreign Security Principals & ACL Sprawl

When a trust is two-way and someone grants a foreign principal (from the trusting domain) an ACE on an object in the trusted domain, AD creates a ForeignSecurityPrincipal object to represent it. These accumulate silently over years of nested group membership and ad-hoc access grants, and they're rarely audited because they don't show up in a normal domain user/group review — you have to walk the trust explicitly. BloodHound's CrossForest edges are the fastest way to enumerate them; look specifically for FSPs sitting inside GenericAll, WriteDacl, or WriteOwner paths back to Tier-0 objects.

Kerberos Delegation Across Trust Boundaries

Constrained delegation with protocol transition (TrustedToAuthForDelegation) scoped to a service that itself has a trust path outward is a frequently missed escalation. Resource-based constrained delegation (RBCD) is worse from a defensive standpoint because it's configured on the target object's msDS-AllowedToActOnBehalfOfOtherIdentity attribute — meaning any principal with WriteProperty or ownership on a computer object can grant themselves delegation rights to it without needing Domain Admin, then S4U2Self/S4U2Proxy their way to a service ticket as any user, including one with rights across a trust.

# Enumerate trust flags and SID filtering state before assuming a path is viable
Get-DomainTrust -Domain corp.local
nltest /domain_trusts /all_trusts /v

# Confirm whether RBCD is writable on a target computer object
Get-DomainComputer -Identity SVC-APP01 -Properties msDS-AllowedToActOnBehalfOfOtherIdentity

Cross-forest movement is fundamentally about finding the one place an environment's segmentation model didn't get enforced. Forests are the hard security boundary Microsoft actually designs around — domains within a forest are not. Most orgs treat a forest trust the way they'd treat a domain trust, and that assumption gap is where the path lives.

Enumeration Before Movement

• Pull the trust topology from both sides if you can — Get-DomainTrustMapping or a full BloodHound collection run against each reachable domain — since trust attributes can differ per direction.
• Identify whether SID filtering is enforced (quarantined flag) and whether selective authentication is set. These two flags alone eliminate most theoretical paths before you spend cycles on them.
• Enumerate group memberships that span the trust — Enterprise Admins, nested groups pulled in via FSPs, and shares/GPOs that apply cross-forest.

Common Realistic Paths

Active Directory Certificate Services (ADCS) is, from an attacker's perspective, an alternate credential and authentication system layered on top of AD that most environments audit far less rigorously than Kerberos or NTLM. The ESC (Escalation) classification originates from SpecterOps' 2021 "Certified Pre-Owned" research and remains the standard taxonomy operators use to communicate findings. The table below is a reference map — full mechanics for each are broken out afterward.

DCSync doesn't exploit a vulnerability — it abuses a legitimate replication protocol. Domain controllers replicate directory data (including password hashes) between each other using the MS-DRSR (Directory Replication Service Remote Protocol) interface, specifically the IDL_DRSGetNCChanges RPC call. Any principal holding the extended rights DS-Replication-Get-Changes and DS-Replication-Get-Changes-All (and, for RODC-relevant secrets, DS-Replication-Get-Changes-In-Filtered-Set) on the domain object can call this RPC and ask a real DC to hand over the secrets for any object — impersonating a domain controller without ever touching one.

Why It Works

• The rights are stored as ACEs on the domain root object, not tied to actual DC membership — replication is authorization-based, not identity-based at the protocol layer.
• Domain Admins, Enterprise Admins, and Administrators hold these rights by default, which is expected — the problem is how often the rights get delegated further down to service accounts, backup tooling, or Azure AD Connect (MSOL_*) accounts without anyone tracking it.
• No event is logged on the requesting side beyond a standard authenticated RPC call; detection has to happen on the DC being asked to replicate, and it has to know what "normal" replication traffic looks like for that environment.

# Conceptual invocation pattern — requires DS-Replication-Get-Changes(-All)
# already granted on the domain object, either legitimately or via a prior
# ACL abuse chain (see Section 02).
lsadump::dcsync /domain:corp.local /user:krbtgt

# krbtgt is the highest-value target: its key signs every TGT in the domain,
# enabling offline Golden Ticket forgery independent of any single account's
# password state or lockout policy.

None of the techniques above are novel. What separates an effective operator from someone running tools blind is the same thing in every section of this writeup: understanding why the trust relationship, delegation setting, template ACL, or replication right exists in the first place — and recognizing the exact conditions under which that legitimate mechanism becomes an escalation primitive. Map the environment, understand the mechanism, then move. In that order.

This writeup is part of the ongoing BreachOperators research archive. Future entries in this series will cover Kerberoasting economics at scale, hybrid Azure AD/on-prem trust abuse, and tiered administration bypass patterns.

• 01 SpecterOps — "Certified Pre-Owned: Abusing Active Directory Certificate Services" (foundational ESC1–ESC8 taxonomy)
• 02 Microsoft — MS-DRSR Directory Replication Service Remote Protocol specification
• 03 Microsoft — MS-PKCA / Certificate mapping and StrongCertificateBindingEnforcement guidance (KB5014754)
• 04 BloodHound / SharpHound documentation — trust and ACL edge collection
• 05 Microsoft — Trusted Domain Object attributes and SID filtering reference