search
active-directoryCAPECRTP

Inter-Forest

In a cross-forest AD environment, the mechanics of trust relationships mirror those of cross-domain trusts. However, while cross-domain trust relationships are implicit within a forest, cross-forest trusts must be explicitly configured by administrators. This deliberate configuration allows two separate forest roots to authenticate users and resources across organizational boundaries.

Trust tickets operate in the same way in forest trusts (transitive trust between two forest root domains) as they do between domains. If DA or EA access is obtained on one forest root, it becomes possible to impersonate similarly privileged users in the trusted forest, assuming the trust relationship permits it and the conditions are met.

A critical difference is that unlike domain trust keys, which rotate automatically (typically every 30 days), the key used in a forest trust remains static unless manually changed. This makes it an attractive target for long-term persistence, especially when combined with ticket forging techniques.

To defend against privilege escalation across forest boundaries, AD implements SID filteringarrow-up-right. This mechanism strips certain well-known SIDs from tickets issued across a forest trust. Specifically, SIDs in the range typically associated with built-in privileged groups (e.g., DAs starting at RID 500 and DCs at 1000) are filtered out.

As a result, attempts to embed these SIDs into a forged ticket from a foreign forest will be blocked by default.

However, this filtering can be bypassed if misconfigurations exist, especially when high-privileged groups are custom-created and assigned SIDs outside the filtered range.

This scenario often arises in environments where administrators create new groups with elevated permissions but do not consider how SID filtering might interact with these roles. If a forest trust exists, there is usually a reason for it, and that reason often introduces risk if not properly managed.

While enumeration of external forests via service tickets is noisy and easily detected, it remains the only practical method for mapping trust paths in a red team engagement without direct access to forest-wide enumeration tools.

hashtag
Trust Account

When a one-way outbound trust is established between two forests, e.g. from mollysec.local to rigassec.local, a trust account (e.g. mollysec$) is automatically created in the latter. This trust account possesses standard domain user privileges within Forest B and represents a potential attack vector for gaining unauthorized access to the trusted forest.

The credentials of rigassec$ can be extracted from a DC in either of the domains. The following example demonstrates an outbound trust from mollysec.local to rigassec.local:

Due to the one-way trust configuration, rigassec.local cannot be enumerated directly from mollysec.local.

However, compromising the trust account (mollysec$) enables enumeration and establishes a foothold in the target domain.

Mimikatz outputs both NewPassword and OldPassword attributes from the Trusted Domain Object (TDO). Trust keys rotate automatically every 30 days, so both values may be valid during the rotation period.

hashtag
Uncostrained Delegation

DCs have unconstrained delegation (UD) enabled by default. When UD is configured on a service account in one forest (mollysec.local) that trusts another (rigassec.local), the service can impersonate users from the trusted forest by capturing their TGTs.

circle-info

Microsoft implemented significant security changes to mitigate this attack vector:

  • July 9, 2019 Updatearrow-up-right: TGT delegation is now disabled by default for both new and existing forest and external trusts.

  • Current State: This attack is only feasible if the EnableTGTDelegation flag is explicitly set to Yes, reverting to a less secure configuration

Users are susceptible to TGT theft unless they meet one of the following criteria:

  • The Account is sensitive and cannot be delegated flag is enabled on their account

  • They are members of the Protected Users security group

For this attack to succeed, the following conditions must be met:

  1. TGT Delegation Enabled: The EnableTGTDelegation flag must be explicitly set to Yes on the trust (default: disabled post-July 2019)

  2. Selective Authenticationarrow-up-right Disabled: The trust must not use selective authentication

  3. Two-Way Trust: A bidirectional trust relationship must be configured between the forests

The authentication level of a trust is determined by the trustAttributes flags of the Trusted Domain Object (TDO):

Authentication Level
Description

Forest-wide

Allows unrestricted authentication from all principals in the trusted forest to resources in the trusting forest. This is the least secure level and completely opens one forest to another (authentication-wise, not access-wise).

Domain-wide

Allows unrestricted authentication from principals in the trusted domain to resources in the trusting domain. More secure than forest-wide authentication as it restricts access to a specific domain.

Selective

Allows only specific users in the trusted domain to access resources in the trusting domain. Most secure option requiring explicit "Allowed-To-Authenticate" extended right in the resource's DACL.

Important Notes:

  • Trusts within a forest always use Forest-Wide Authentication and this cannot be disabled

  • Authentication level depends on the trust relationship type and configuration flags

If a DC in one forest (mollysec.local) is compromised, it can be used to extract TGTs from accounts in a trusted forest (rigassec.local).

PreviousGPO AbuseNextIntra-Forest

Last updated