Domain Trusts
Introduction
In Active Directory, a domain trust is a relationship between two domains that allows users in one domain to access resources in the other domain.
There are two types of domain trusts in Active Directory: one-way trusts and two-way trusts.
A one-way trust allows users in one domain (the trusted domain) to access resources in another domain (the trusting domain), but not the other way around. For example, if Domain A trusts Domain B, users in Domain B can access resources in Domain A, but users in Domain A cannot access resources in Domain B.
A two-way trust allows users in both domains to access resources in the other domain. For example, if Domain A trusts Domain B and Domain B trusts Domain A, users in both domains can access resources in the other domain.
To establish a domain trust, an administrator in the trusting domain must create a trust relationship with the trusted domain. The administrator in the trusted domain must then approve the trust relationship. Once the trust relationship is established, users in the trusted domain can access resources in the trusting domain, subject to any permissions and access controls that are in place.
Enumeration
You can find the enumeration commands in this link.
Bidirectional (Extra SID)
In a valid scenario, a user originating from Domain A, equipped with ExtraSids assigned from Domain B, can gain access to content within the trusted domain based on the group memberships to which the ExtraSids are mapped.
The implementation of Kerberos authentication across domains relies on the utilization of the trust key. Since Domain B lacks knowledge of the password hash in Domain A, decrypting a Ticket Granting Ticket (TGT) transmitted from Domain A to Domain B becomes impossible. This challenge is addressed through a shared secret, established during the trust configuration process.
Upon the establishment of domain trust, a new computer account is generated, bearing the name of the trusted domain. In the case of prod.corp1.com, this computer account is denoted as corp1$, also known as the trust account. The shared secret is essentially the password hash of corp1$.
In the context of a bi-directional trust, such as that between parent and child domains, both prod.corp1.com and corp1.com create their respective trust accounts. The account within corp1.com is named prod$, aligning with the trusted domain, but both prod$ and corp1$ share the same password hash.
1. Obtain the shared secret between domains to encrypt the TGT
2. Obtain the SID of each domain. You can use PowerView.
3. Obtain the RID of the Enterprise Admins group (Static value: DOMAIN SID + 519)
4. Create the golden ticket. You can use Mimikatz.
We’ll supply the username inside prod.corp1.com (which does not have to be valid), the origin domain (/domain), the origin domain SID (/sid), the krbtgt password hash (/krbtgt), and finally, the ExtraSid value (Enterprise Admins SID) through the /sids: option.
ℹ️ The
/sids
attribute is a combination of foreign domain SID and the foreign identity in our case "Enterprise Admins" (519).
5. Check access to the target computer.
Bidirectional (Parent-Child)
When a child domain is added to a forest, it automatically creates a transitive, two-way trust with its parent.
In order to gain Domain Admin Privileges in the parent domain, you need to create a TGT with a particular attribute called SID History. SID History was designed to support migration scenarios, where a user would be moved from one domain to another. To preserve access to resources in the "old" domain, the user's previous SID would be added to the SID History of their new account. When creating such a ticket, the SID of a privileged group (EAs, DAs, etc) in the parent domain can be added so it will grant access to all resources in the parent.
The only difference between creating a normal and a transitive one is that you need to add the SID of a target group in the parent domain.
1. Obtain the SID of a group with admin privileges in the parent domain.
2. Obtain a Domain Administrator in the parent to impersonate.
3. Create a Golden Ticket
4. Import the ticket to a new process
5. Check that you can access the parent DC.
One-Way Inbound
If the trust is inbound from your perspective, it means that principals in your domain can be granted with access to other resources in the foreign domain.
1. Enumerate groups with foreign domain principals (it can be groups or users)
2. If it is a group, search for its members.
3. Create a TGT for the target user.
4. Request a referral ticket from the current domain to the target domain
5. Use this inter-realm ticket to request TGS's in the foreign domain
One-Way Outbound
Remember that if Domain A trusts Domain B, users in Domain B can access resources in Domain A; but users in Domain A should not be able to access resources in Domain B.
Nonetheless, sometimes there is a possibility to become a domain user. To do so, you need to obtain the shared password between domains in a Trusted Domain Object (TDO).
1. Read the system container through LDAP.
2. Perform a DCSync of TDO's GUID.
3. Enumerate the domain accounts looking for the trusted account of the foreign domain.
4. Create a TGT with the trusted account to impersonate it.
Forest trust - Extra SID
The implementation of SID filtering is a key element introduced by forest trust. In the context of forest trust, the ExtraSids field are filtered so group memberships are not blindly trusted. Thus, the attack show on Bidirection (Extra SID) will not work.
Microsoft dictated that any SID with a RID less than 1000 will always be filtered regardless of the SID history setting. Nevertheless, a SID with a Relative Identifier (RID) equal to or exceeding 1000 remains unfiltered in the case of an external trust. Any non-default group invariably possesses a RID surpassing 1000. Identifying a custom group with membership that could potentially compromise a user or computer provides a viable entry point.
To exploit this configuration, follow these steps.
1 . Check if ISD history is enabled on your target domain.
2. Enumerate members of the target domain built-in Administrators group.
3. Craft a golden ticket as in but Bidirection (Extra SID) using the SID of the foreign group as /sids
.
Last updated