Press "Enter" to skip to content

Active Directory: Exploiting Trust Relationships I

Let’s continue with the posts on Red Teaming.  After the post on how to exploit misconfigured Certificate Templates, today we will talk about the forests, the trust relationships that are established between the different domains, and how to abuse them to pivot and gain access to other domains.

Basic Concepts

Let me first define some concepts.

Domain Trusts

A trust relationship allows users in one domain to authenticate and access resources in another domain.

Cross Domain Authentication Process

  • The two domains (A and B) use a shared trust key (an inter-domain TGT).
  • When a user in domain A tries to access a resource in domain B, the KDC (Key Distribution Center) A generates a referral ticket (TGT, Ticket Granting Ticket) that points to KDC B.
  • This TGT is encrypted using the shared key.
  • Domain B receives the TGT, decrypts it using that shared key and checks whether the user is worthy of access or not.
Types of Trust Relationships
 
There are three types of domain trusts:
  • Dual: Domain A trusts B and vice versa. Users from both domains can authenticate to each other.
  • Inbound:The other domain trusts us. So users from our domain can authenticate and access each other’s resources.
  • Outbound: We trust the other domain. So the users of the other domain can authenticate and access the resources of our domain.

We can also distinguish between trust relationships according to their transitivity: transitive (if A trusts B and B trusts C, then A trusts C) and nontransitive (if A trusts B and B trusts C, it does not imply that A trusts C).

Forests
 
Forests are sets of Active Directory domains that have trust relationships with each other. If the domain google.com trusts hackinglethani.com, we would have a forest consisting of those two domains’ trees, which would contain the domain and its subdomains:
 

An interesting thing to note is that when a child is added to the forest, it automatically creates a dual, transitive trust relationship with its parent.

This means that if we have Domain Admin privileges on dev.hackinglethani.com, we can also get Domain Admin privileges on hackinglethani.com through a special TGT ticket with an attribute called “SID History”.

To do this, we need to create a Golden Ticket in which we indicate the SID of the parent domain. Let’s see how to do it.

Golden Ticket to Parent Domain - How to exploit dual trust relationships.

The Silver, Golden and Diamond tickets would require a whole post just to talk about them, but let’s summarise it so it’s easy to understand and we can do the attack.

Golden Ticket

A Golden ticket is a Ticket Granting Ticket (TGT) signed by the kerberos domain account. With this ticket we can impersonate any user, and request any service, on any machine in the realm. For this we need the kerberos key, which we can obtain through a DCSync attack.

DCSync

A DCSync attack would be worthy of another post. But in a nutshell, it is an attack in which the MS-DRSR protocol is replicated to replicate Active Directory information, including password hashes. In theory, this can only be done by Domain Admins, but in this scenario, we are Domain Admin of the child domain so we can do it.

First I will use PowerSploit, specifically PowerView’s Get-DomainGroup command, to get the SID of the Domain Admins group of my current domain. We can also get the SID of the parent domain by specifying that domain in -Domain (we will need it later).

Next we need the Kerberos password, which we can get by doing a dcsync, which we can do since we are assuming we have Domain Admin privileges in our current domain. In Cobalt Strike, we can do this by using the command:

dcsync dev.domain.com DEV\krbtgt

Once we get the aes256 key from kerberos, we can use it with mimikatz to generate our own TGT ticket signed by kerberos: a golden ticket. This is something we can do offline, from our attacking windows computer.

Let me explain the parameters:
  • /sid is the security identifier of our current domain.
  • /sids is the security identifier of the parent domain.
  • /startoffset sets the ticket start time to 10 minutes before the current time.
  • /endin gives the ticket a validity time of 600 minutes.
  • /renewmax indicates the maximum time the ticket can last if it is renewed.
Now that we have the ticket, we can use it to authenticate ourselves and access the resources of the parent domain. To do this we can create a sacrifice session and then use the ticket we created with mimikatz.
In Cobalt Strike we can do this using the commands make_token y kerberos_ticket_use.

So much for the attack. I could directly explain the attacks that exist on inbound and outbound trust relationships, but I’m going to leave it for next week’s post, so that this kind of dense posts are not too long and can be better understood.

If you liked it, don’t forget to subscribe to my telegram channel to get a notification every time I publish a new post.

Lethani.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Mission News Theme by Compete Themes.