To access material, start machines and answer questions login.
Press 'Start' to begin
A large Active Directory environment is rarely a single domain. As an organisation grows, it often splits into a root domain and one or more child domains, maybe one per region, business unit, or environment. A common assumption is that this split is also a security boundary, that owning a child domain keeps you contained inside it and away from the .
It doesn't. The real boundary is the forest, not the domain. Every domain in a forest automatically trusts every other, and that trust does not filter the privileged SIDs an attacker cares about. So Domain Admin in a small child domain is not the end of the line, it's a stepping stone to Enterprise Admin over the entire forest.
In this room, you start as Domain Admin in a child domain. By the end, you'll be Enterprise Admin over the forest root, using two different techniques, without cracking a single password in the root domain.
This builds directly on the last room. In PAM Trust Exploitation, you injected a privileged across a trust where SID filtering had been switched off. In this room, you'll use the same idea, but you won't need any misconfiguration to do it. Inside a forest, that filtering was never applied in the first place.
One thing to note is that we're assuming an attacker already holds Domain Admin in the child domain. How they got there, whether through a relay, a weak service account, or a misconfigured host, is outside the scope of this room and will not be covered. What matters here is what the foothold lets you do next, which is take over the entire forest.
Learning Objectives
- Understand forest structure and why the forest, not the domain, is the real security boundary.
- Understand why intra-forest trusts do not filter SIDs, unlike a forest trust.
- Enumerate the forest to find the root domain, the SIDs, and the keys you need to forge tickets.
- Escalate from a child Domain Admin to an Enterprise Admin in the root domain with a golden ticket carrying an injected ExtraSid.
- Reach the same access a second way using the trust key between the child and root domains.
Prerequisites
This room requires familiarity with Active Directory, , DCSync, and tools for forging tickets. If any of that is new, we recommend finishing the following rooms first:
Starting the Network
Use the information below to access the child domain controller via .
| Setting | Value |
|---|---|
| Child account | DEV\Administrator |
| Password | DevAdm1n123!@# |
| Hostname | CHILD-DC (10.0.0.20) |
Before moving to the next task, click the green Start button under the network diagram. Give the network enough time to launch. You can connect to the network in two ways:
Option 1: Using the AttackBox
- Click the Start AttackBox button at the top of this room. Once ready, your AttackBox will be available on a split-screen.
- Launch a terminal window and run the following command to connect to the child domain controller:
user@tryhackme:~$ xfreerdp /v:10.0.0.20 /u:Administrator /d:dev.corp.thm /p:'DevAdm1n123!@#' /dynamic-resolution +clipboard
Option 2: Over a VPN Connection
Alternatively, you can connect to the network via the VPN. To establish a VPN connection to this network follow the steps below.
- Click the Download VPN Profile button below the network diagram.
- In a Linux terminal, run the following command to connect to the VPN:
sudo openvpn [your_configuration_file_name.ovpn] - Connect to the child domain controller using the same xfreerdp command above.
Note: If using Windows operating system, connect to the using OpenVPN , then simply connect to the child domain controller using the Windows Remote Desktop client.
I have started the network and connected to the child domain controller!
Ready to learn Cyber Security?
The Child Domain Exploitation room is only available for Premium or Max subscribers. Signup now to access more than 500 free rooms and learn cyber security through a fun, interactive learning environment.
Already have an account? Log in

