From Domain Admin to Enterprise Admin
Explore Parent-Child Domain Trust Relationships and abuse it for Privilege Escalation
Last updated
Explore Parent-Child Domain Trust Relationships and abuse it for Privilege Escalation
Last updated
This lab is based on an Empire Case Study and its goal is to get more familiar with some of the concepts of Powershell Empire and its modules as well as Active Directory concepts such as Forests, Parent/Child domains and Trust Relationships and how they can be abused to escalate privileges.
The end goal of this lab is a privilege escalation from DA on a child domain to EA on a root domain.
Firstly, some LAB setup - we need to create a child domain controller as well as a new forest with a new domain controller.
After installing a child domain red.offense.local of a parent domain offense.local, Active Directory Domains and Trusts show the parent-child relationship between the domains as well as their default trusts:
Trusts between the two domains could be checked from powershell by issuing:
The first console shows the domain trust relationship from offense.local perspective and the second one from red.offense.local. Note the the direction is BiDirectional which means that members can authenticate from one domain to another when they want to access shared resources:
Similar, but very simplified information could be gleaned from a native Windows binary:
Powershell way of checking trust relationships:
After installing a new DC dc-blue in a new forest, let's setup a one way trust between offense.local and defense.local domains using controllers dc-mantvydas.offense.local and dc-blue.defense.blue.
First of, setting up conditional DNS forwarders on both DCs:
Adding a new trust by making dc-mantvydas a trusted domain:
Setting the trust type to Forest:
Incoming trust for dc-mantvydas.offense.local is now created:
Testing nltest output:
Now that the trust relationship is set, it is easy to check if it was done correctly. What should happen now is that resources on defense.local (trusting domain) should be available to members of offense.local (trusted domain).
Note how the user on dc-mantvydas.offense.local is not able to share a folder to defense\administrator (because offense.local does not trust defense.local):
However, dc-blue.defense.local, trusts offense.local, hence is able to share a resource to one of the members of offense.local - forest trust relationships work as intended:
Assume we got our first agent back from the computer PC-MANTVYDAS$:
Since the agent is running within a high integrity process, let's dump credentials - some interesting credentials can be observed for a user in red.offense.local domain:
Listing the processes with ps, we can see a number of process running under the red\spotless account. Here is one:
The domain user is of interest, so we would use a usemodule situational_awareness/network/powerview/get_user command to enumerate the red\spotless user and see if it is a member of any interesting groups, however my empire instance did not seem to return any results for this command. For this lab, assume it showed that the user red\spotless is a member of Administrators group on the red.offense.local domain.
Let's steal the token of a process with PID 4900 that runs with red\spotless credentials:
After assuming privileges of the member red\spotless, let's get the Domain Controller computer name for that user. Again, my Empire instance is buggy, so I used a custom command to get it:
Check if we have admin access to the DC-RED:
We are lucky, the user is a domain admin as can be seen from the above screenshot.
Let's get an agent from DC-RED - note that the credentials are coming from the previous dump with mimikatz:
We now have the agent back, let's just confirm it:
Once in DC-RED, let's check any domain trust relationships:
We see that the red.offense.local is a child domain of offense.local domain, which is automatically trusting and trusted (two way trust/bidirectional) with offense.local - read on.
We will now try to escalate from DA in red.offense.local to EA in offense.local. We need to create a golden ticket for red.offense.local and forge it to make us an EA in offense.local.
First of, getting a SID of a krbtgt user account in offense.local:
After getting a SID of the offense.local\krbtgt, we need to get a password hash of the krbtgt account in the compromised DC DC-RED (we can extract it since we are a domain admin in red.offense.local):
We can now generate a golden ticket for offense.local\Domain Adminssince we have the SID of the offense.local\krbtgt and the hash of red.offense.local\krbtgt:
Note how during sids specification, we replaced the last three digits from 502 (krbtgt) to 519 (enterprise admins) - this part of the process is called a SID History Attack:
The CredID property in the dcsync module comes from the Empire's credential store which previously got populated by our mimikatz'ing:
We now should be Enterprise Admin in offense.localand we can test it by listing the admin share c$ of the dc-mantvydas.offense.local:
For the sake of fun and wrapping this lab up, let's get an agent from the dc-mantvydas:
The Configuration NC is the primary repository for configuration information for a forest and is replicated to every DC in the forest. Every writable DC (not read-only DCs) in the forest holds a writable copy of the Configuration NC. Exploiting this require running as SYSTEM on a (child) DC.
It is possible to compromise the root domain in various ways. Examples:
Exploit ADCS - Create/modify certificate template to allow authentication as any user (e.g. Enterprise Admins)
SID filtering prevents the SID history attack, but not this one.
