Cross-Domain
In Active Directory environments, trust relationships govern access across domain or forest boundaries. Within a single forest, domains are linked by default through implicit two-way trust.
A key attribute in these trust-based escalations is sIDHistory, which stores the old Security Identifier (SID) when a user account is migrated between domains. While its intended use is to preserve access to legacy resources, it creates an opportunity for privilege escalation under specific conditions, particularly through Trust Tickets and ExtraSID injection.
Trust Tickets
Trust Tickets exploit the Kerberos trust mechanism between domains. When a user from a child domain requests access to services in a parent domain, a cross-realm TGT is issued by the child’s DC. This TGT is encrypted with a shared trust key and presented to the parent’s DC, which validates it using the same key. By default, this key—functionally similar to a machine account password—is the NTLM hash of the trust object and rotates every 30 days.
If this NTLM hash is obtained (typically RC4-based), it becomes possible to forge a cross-realm TGT. The forged ticket can then include privileged SIDs such as Enterprise Admins (-519) in the sIDHistory field, effectively tricking the parent DC into recognizing the ticket as one issued to a highly privileged user. This enables unauthorized access to services and systems in the parent domain.
Extract the trust key as a DA:
Get the parent domain SID:
Forge the inter-realm TGT:
Request and inject the TGS:
Access the parent's domain resource:
From Linux hosts:
Execute the Golden Ticket attack including the target SIDs using ticketer:
Leverage the forged TGT to request a ST and perform a DCSync attack:
ExtraSID Injection
An attacker with control over a child domain can abuse the krbtgt secret to forge Kerberos tickets that impersonate privileged users in a trusted parent domain. This approach builds upon the logic of cross-domain trust abuse but targets a different step in the Kerberos authentication flow, offering a more straightforward execution path with a bigger impact as the attack can access any resource on the parent domain's DC.
This method uses the RC4 hash of the child domain's krbtgt account to forge a standard Golden Ticket. The critical twist is in preloading the ticket with high-privilege SIDs from the parent domain—typically by setting the sIDHistory to include the SID of the Enterprise Admins group (-519). When this forged TGT is presented to the child DC to request access to a parent domain service, the resulting inter-realm TGT is generated with the maliciously inserted sIDHistory intact. The parent domain then validates and honors the ticket, effectively granting EA privileges to an attacker-controlled principal.
This approach is particularly advantageous because it targets the step before the inter-realm TGT is created. It avoids the need to compromise the trust account itself, relying only on the child domain’s krbtgt secret—often easier to obtain. The result is elevated access to the parent domain, including the ability to authenticate to its DCs, which normally disallows logons from users in child domains.
OPSEC: The Diamond ticket is the most OPSEC-friendly option.
Execute the Golden Ticket attack including the target SIDs using Rubeus or SafetyKatz:
Access the parent domain's DC:
However, when an Administrator from the child domain logs in interactively to the forest root DC, it generates alerts (event ID 4672), alerting on high-privilege logons from unexpected accounts. Instead of impersonating an administrator directly, the forged ticket can represent the machine account of the child domain’s DC, combined with SIDs for DCs (-516) and Enterprise DCs (S-1-5-9). This simulates legitimate replication behavior between domains and bypasses interactive logon restrictions. Because it mimics legitimate DC-to-DC replication, this variant often evades detections—even those from advanced defenders like MDI.
For improved OPSEC, Diamond Tickets can be used in place of traditional Golden Tickets. Diamond Tickets resemble legitimate Kerberos requests and include a corresponding TGT request, making them less suspicious.
From Linux hosts:
Execute the Golden Ticket attack including the target SIDs using ticketer:
Leverage the forged TGT to request a ST and perform a DCSync attack:
Last updated
Was this helpful?