HasTrustKeys
The relationship’s source node is a domain which has the trust keys for the end node trust account. The trust account exists because the source domain has an outbound trust to the domain of the trust account.
The trust keys can be leveraged to authenticate as the trust account and gain access to the trust account’s domain.
Abuse Info
Step 1: Obtain Trust Keys
Trust keys can be dumped with administrative access to a domain controller of the source domain.
On Windows, use Mimikatz to dump the trust keys:
The trust keys for the target trust account appear under ”[ Out ]” for the target domain.
Step 2: Authenticate as the Trust Account
The RC4 version of the trust keys serves as the RC4 Kerberos secret key for the trust account. This can be used directly to request a Kerberos Ticket-Granting Ticket (TGT).
The AES trust keys are not identical to the AES Kerberos secret keys of the trust account due to different salt values. However, you can derive the AES Kerberos secret keys using the cleartext trust key and tools like krbrelayx.py. (See reference: A Note on Calculating Kerberos Keys for AD Accounts).
When authenticating as a trust account, there are two key limitations:
-
Only Kerberos authentication is supported (NTLM authentication is not possible).
-
Only network logins work (interactive logins such as RUNAS, console login, and RDP are not possible).
On Windows, use Rubeus to obtain a TGT:
On Linux, use Impacket’s getTGT.py to obtain a TGT:
Opsec Considerations
Authentication via a trust account is unusual and can be detected by Windows security events with the account name of a trust account. Specifically, monitor for:
- Event ID 4768 – A Kerberos authentication ticket (TGT) was requested
- Event ID 4624 – A successful account login