AD Trust Exploitation

Trust Primer

A trust is used to establish forest-forest or domain-domain (intra-domain) authentication, which allows users to access resources in (or perform administrative tasks) another domain, outside of the main domain where their account resides. A trust creates a link between the authentication systems of two domains and may allow either one-way or two-way (bidirectional) communication. An organization can create various types of trusts:

Type	Description
Parent-child	Two or more domains within the same forest. The child domain has a two-way transitive trust with the parent domain, meaning that users in the child domain corp.inlanefreight.local could authenticate into the parent domain inlanefreight.local, and vice-versa.
Cross-link	A trust between child domains to speed up authentication.
External	A non-transitive trust between two separate domains in separate forests which are not already joined by a forest trust. This type of trust utilizes SID filtering or filters out authentication requests (by SID) not from the trusted domain.
Tree-root	A two-way transitive trust between a forest root domain and a new tree root domain. They are created by design when you set up a new tree root domain within a forest.
Forest	A transitive trust between two forest root domains.
ESAE	A bastion forest used to manage Active Directory.

Trusts can be transitive or non-transitive

• A transitive trust means that trust is extended to objects that the child domain trusts. For example, let's say we have three domains. In a transitive relationship, if Domain A has a trust with Domain B, and Domain B has a transitive trust with Domain C, then Domain A will automatically trust Domain C.

• In a non-transitive trust, the child domain itself is the only one trusted.

And finally, trusts can be set up in two directions: one-way or two-way (bidirectional):

• One-way trust: Users in a trusted domain can access resources in a trusting domain, not vice-versa.

• Bidirectional trust: Users from both trusting domains can access resources in the other domain.

sidHistory Primer

The sidHistory attribute is used in migration scenarios. If a user in one domain is migrated to another domain, a new account is created in the second domain. The original user's SID will be added to the new user's SID history attribute, ensuring that the user can still access resources in the original domain.

SID history is intended to work across domains, but can work in the same domain. Using Mimikatz, an attacker can perform SID history injection and add an administrator account to the SID History attribute of an account they control. When logging in with this account, all of the SIDs associated with the account are added to the user's token.

This token is used to determine what resources the account can access. If the SID of a Domain Admin account is added to the SID History attribute of this account, then this account will be able to perform DCSync and create a Golden Ticket or a Kerberos ticket-granting ticket (TGT), which will allow for us to authenticate as any account in the domain of our choosing for further persistence.

This will be used for ExtraSid Attack in the next section.

Enumerating Trusts

We can use the Get-ADTrust cmdlet to enumerate domain trust relationships. This is especially helpful if we are limited to just using built-in tools.

Import-Module activedirectory
Get-ADTrust -Filter *

We can also import PowerView and use the Get-DomainTrust function to enumerate what trusts exist:

Get-DomainTrust
Get-DomainTrustMapping

We can select any of the domains and check the users:

Get-DomainUser -Domain LOGISTICS.INLANEFREIGHT.LOCAL | select SamAccountName

Another tool we can use to get Domain Trust is netdom. The netdom query sub-command of the netdom command-line tool in Windows can retrieve information about the domain, including a list of workstations, servers, and domain trusts.

netdom query /domain:inlanefreight.local trust

We can use that to query Domain Controllers:

netdom query /domain:inlanefreight.local dc

We can also query workstations and servers:

netdom query /domain:inlanefreight.local workstation

We can also use BloodHound to visualize these trust relationships by using the Map Domain Trusts pre-built query.

Here we can see two bidirectional trusts exist