In today’s post we are going to exploit one-way trust relationships, from an inbound point of view.
If you haven’t seen it yet, take a look at this post first, in which I explain the basics of trust relationships in an active directory, the different relationships that forests have and how to exploit a two-way trust relationship.
Remember that in a one-way trust relationship, all users of the trusted domain have access to the resources of the trusting domain, but not the other way around.
Depending on the perspective, the trust relationship can be inbound (the other domain trusts my domain, so the users of my domain have access to the resources of the other domain) or outbound (my domain trusts the other domain, so the users of the other domain have access to the resources of my domain).
Inbound Relationships
In this example we can see that our domain, dev.*****.io, has an inbound trust relationship with the domain subsidiary.external. Therefore, the users of our domain can access the resources of subsidiary.external:
We can therefore enumerate the opposite domain through this trust relationship. I am using PowerSploit commands to enumerate it.
Let’s see which computers are associated to this domain:
Another interesting thing to list is whether there are groups in the other domain that contain users who do not belong to that domain.
We see that there is a member that belongs to the administrator group and does not belong to that domain. To see what that member is, use the PowerShell ConvertFrom-SID command and enter the SSID.
The “Subsidiary Admins” group of our domain belongs to the administrators group of the external domain. If we have access to any of the users in this group, then we will be able to access the external domain with administration permissions.
Case 1: We know the username and password of a trusted group member.
We just have to use the command Get-DomainGroupMember to find the group “Subsidiary Admins” in our domain. In this case we get that the user jadams belongs to this group. Assuming we know his credentials, we can use the make_token function of Cobalt Strike (or the homonym in the C&C you are using) to be able to access the resources of ad.subsidiary.external.
Case 2: We know user and RC4/AES keys of a trust group member
In case we don’t know the password but we have the user’s RC4 or AES keys (we have obtained them with mimikatz for example), then we can use Rubeus to request a ticket from Kerberos. However, we will need a couple of extra steps, because since we are requesting a ticket for an external realm, we need an inter-realm key that Rubeus does not generate automatically.
First, we need a TGT ticket for our user on our domain. We request it with the Rubeus asktgt command:
