Cross-Forest Trust Abuse
Cross-Forest Trust Abuse - from Windows
Kerberoasting
Kerberoasting can be leverage to move laterally to another forest. For example, from Forest A cracking a Kerberos hash from a user that have administrative privileges in Forest B can lead to the compromise of that second forest.
The following image shows that we are currently in the INLANEFREIGHT.LOCAL domain.
With the Get-ADTrust PowerView command, we can observe that the INLANEFREIGHT.LOCAL has a bidirectional forest trust relationship with the FREIGHTLOGISTICS.LOCAL domain located in a second forest.
The first step to perform a Kerberos attack is to enumerate all domain users having a SPN set in the target domain. This can be done using PowerView.
Now, we can check the group membership of the users with SPN enumerated.
As the mssqlsvc user has administrative privileges over the target domain, then, we can use Rubeus to conduct a Kerberosting attack specifying the target domain.
If we can crack the Kerberos hash, this could give us administrative access to the target domain.
Admin Password Re-Use & Group Membership
Two administrative accounts can share the same password in two different domain across a forest trust. Pay attention to users having the same username pattern for example bob.userforestA and bob.userforestB. If those two users share the same password, a bidirectional trust exists between forests, and those two are members of high privilege group, password reuse can allow an attacker to move latterally from one forest to another.
We can also check if some domain groups have members that do not belong to the domain itself. The PowerView command below aim to identify users that are members of one or many FREIGHTLOGISTICS.LOCAL groups, but do not belong to that domain.
In the example above, we can observe that the INLANEFREIGHT\administrator users is a member of the FREIGHTLOGISITCS.LOCAL\Administrators group. A bidirectional forest trust connects the two domains. In this situation we have a direct access to the FREIGHTLOGISITICS.LOCAL domain via the INLANEFREIGHT\administrator user.
We can establish a remote session using EnterPS-Session.
SID History Abuse - Cross Forest
When migrating users from one forest to another. If the sidHistory attribute of a user is set for a group or a user with high privileges and that the sidFiltering is not enabled, this users could operate in both forests. The image below illustrates the case where a user migrates from INLANEFREIGHT.LOCAL to FREIGHTLOGISTICS.LOCAL where a bidirectional trust exists between the two forests. The domain user's sid from the INLANEFREIGHT.LOCAL is transposed to the sidHistory attribute of the new FREIGHTLOGISTICS.LOCAL domain user, which gives that user permissions across both domain.
Cross Forest Abuse - From Linux
Kerberoasting
Kerberoasting can also be operated remotely from a Linux host in order to gain access to another forest resources with whom we have a bidirectional trust relationship.
Domain users with the SPN set in the target domain can be identified using the script GetUsersSPNs.py. The following command will output all domain users with a Service Principal Name in the FREIGHTLOGISTICS.LOCAL domain with whom we have a bidirectional trust relationship with.
The second command is to request the Kerberos hash for the targeted user.
Once we obtained the hash, we can crack it using Hashcat.
It also worth to check if the cracked password from the Kerberos ticket is reused in our own domain or for any other services. This can help us extend our access or identify a password reuse security flaw.
Foreign group membership
It is possible to identify foreign group membership from a Linux host using the Python implementation of BloodHound, which allow an attacker to ingest data remotely.
To identify administrative members of a domain that are part of a group in another domain, we have to links information ingest from the two domains of interests.
The following command is to ingest data from the INLANEFREIGHT.LOCAL domain.
To collect data from the FREIGHTLOGISITCS.LOCAL domain perform the exact same command with modified parameters value.
Add the IP of the DCs in /etc/resolv.conf since bloodhound-python needs DNS resolution.
Once the data is imported into the BloodHound GUI, observe the results of the built-in query Users with Foreign Domain Group Membership.
Last updated
