search
CAPECRTPactive-directoryunconstrained-delegation

Intra-Forest

In Active Directory (AD) environments, trust relationships govern access across domain or forest boundaries. Within a single forest, domains are linked by default through implicit two-way trust.

hashtag
sIDHistory

A key attribute in these trust-based escalations is sIDHistoryarrow-up-right, 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.

hashtag
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.

Simirarly, from Linux:

hashtag
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, which is 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.

circle-exclamation

OPSEC: The Diamond ticket is the most OPSEC-friendly option.

We need the following pre-requisites:

  • krbtgt hash of the child domain

  • SID of the child domain

  • Any domain user in the child domain

  • FQDN of the child domain

  • SID of the target group (e.g. EA) of the root domain

Similarly, from Linux:

Or, more efficiently:

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:

hashtag
Unconstrained Delegation

DCs have unconstrained delegation enabled by default. As a result, if the child domain's DC is compromised, it can be leveraged for compromising the parent domain's DC.

hashtag
Configuration NC Abuse

The Configuration Naming Contextarrow-up-right (NC) (CN=Configuration,DC=mollysec,DC=local) is the primary repository for configuration information for a forest and is replicated to every DC in the forest.

Every change made to an object within the Configuration NC will be replicated downwards to all domains within the forest. More importantly, the reverse is also true: every change made to an object of a child domain, will be replicated upwards to the root domain.

On each DC, the SYSTEM account can modify the Configuration NC:

hashtag
AD CS

The Configuration NC stores information about the AD CS within various containers:

  • Certificate Templates stores templates as pKICertificateTemplate objects.

  • Enrollment Services stores one pKIEnrollmentService object per CA and its certificate Templates attributes list the published certificates.

This attack leverages the fact that SYSTEM has FullControl over the Public Key Services container. This allows us to create and publish a malicious template, which will then be replicated across the forest and becomes available to the CA.

  1. Launch MMC as SYSTEM and add the Certificate Templates snap-in:

  1. Duplicate the User template and create a new vulnerable one within and assign to the Administrator of the child domain FullControl over the template. In this instance, we created the UserNew template and made it vulnerable to ESC1:

  1. The next step if publishing the UserNew template via the pKIEnrollmentService attribute. However, SYSTEM does not have any kind of access over the target object:

  1. The SYSTEM account has FullControl over the Public Key Services container, so we can leverage permissions inheritance. We will modify the security descriptor for the Public Key Services container and gain the same rights over pKIEnrollmentService:

  1. Confirm that SYSTEM has FullControl over the Enrollment Services and publish the UserNew template via modifying the certificate Templates attribute of the pKIEnrollmentService object:

  1. Perform the ESC1 attack chain:

hashtag
GPO On Site

A malicious GPO can be created and then linked (as SYSTEM) from a child domain to a root domain.

Create a malicious task within the target GPO using pygpoabusearrow-up-right. In this case, we will create a new user and add them to local Administrators group:

Confirm that the task was created via the GUI:

Modify the task's settings to ensure that it will run multiple times:

Enumerate the DN of the root's domain replication site, link the GPO from a SYSTEM shell, and then request a TGT (Invoke-Rubeus.ps1arrow-up-right):

Validate the credentials remotely:

hashtag
GoldenGMSA

Group Managed Service Accounts (gMSAs)arrow-up-right let Windows handle service account password management automatically, removing that burden from administrators. They’re commonly used for services that run on multiple machines, such as IIS applications, SQL Server, backup software, scheduled tasks, and directory‑sync services, where the same domain credential must be shared and rotated without manual intervention.

The KDS (Key Distribution Service) Root Key enables AD to deterministically generate gMSA passwords. AD stores a KDS Root Key object in the directory; when a machine requests a gMSA password, a DC derives the password on demand using a mathematical function that combines:

  • the KDS Root Key

  • the gMSA’s SID

  • time‑based values tied to the password rotation interval

Because the password is generated rather than stored, possession of the KDS Root Key (or read access to the msDS-ManagedPassword attribute / ReadGMSAPassword on the key object) would allow an attacker to reconstruct the current password for any gMSA.

Popular tools can typically dump only the gMSA password of the same domain. However, GoldenGMSAarrow-up-right or pyGoldenGMSAarrow-up-right can help us when we have compromised a child domain and we want to get access to the root domain's gMSA account(s).

To use it we need access to various attributes of the KDS Root Key object which can be obtained by the msKds-ProvRootKey class under the following container of the parent domain:

This class can be accessed only by EAs, root domain DAs, and SYSTEM-level access on a DC.

As shown below, a normal DA on a child domain cannot enumerate the msKds-ProvRootKey class, but the same DA can when adsiedit.msc is launched from a SYSTEM shell:

hashtag
Online Attack

The gMSA account SID can be also enumerated locally:

Convert the encrypted gMSA password to an NT hash (gMSA2NT.pyarrow-up-right):

hashtag
Offline

The password retrieval can be also performed locally after enumerating all the details:

hashtag
DNS Trust

hashtag
DNS Wildcard Injection

A DNS wildcard record is a catch‑all that matches any unresolved name under a zone. By injecting a wildcard entry, for example:

and pointing it at an attacker‑controlled IP, all non‑existent hostnames under the parent domain (e.g., *.mollysec.local) will resolve to the attacker’s address.

SYSTEM-level access to a child DC has FullControl over the DNS records of the parent domain:

We can inject a wildcard record using Powermadarrow-up-right:

  • The -Tombstone flag puts the created node into a state that allows any authenticated user to modify or completely tombstone it. By tombstoning it, we mean that we mark it as deleted, while keeping it temporarily so the deletion can be synchronized with other servers before it’s permanently removed.

  • In addition, the -Data <IP-address> is omitted as it defaults to the source IP address

The attack could be then intercept traffic and capture or relay users credentials.

hashtag
Arbitrary DNS Record Modification

SYSTEM-level access on a child DC gives us the ability to enumerate all parent‑domain DNS records.

If an existing DNS record is altered, e.g., changing the IP for test.mollysec.local, clients attempting to access \\test.mollysec.local\test-share can be redirected to an attacker‑controlled host. The TTL value below is set to a low value to allow for fast propagation of the update record:

This enables interception of SMB traffic, NTLM credential capture, and facilitates MitM or DoS attacks against the service:

hashtag
Foreign Groups & Principals

hashtag
Foreign Groups

Foreign users or groups are accounts that belong to a child domain but have permissions or group memberships in the parent domain. This means users from one domain can access resources in another domain within the same forest.

AD security groups have different scopesarrow-up-right, which define where members can come from and where the group can be used:

Scope
Can Include

Global

User accounts or other global groups from the same domain.

Universal

User accounts, global groups, or other universal groups from any domain in the same forest.

Domain Local

User accounts, global groups, universal groups, other domain local groups from any domain, trusted domain, external forests or external domains.

Built-in Local

Prefedined groups in the Built-in container.

The parent domain can add users from a child domain to Universal or Domain Local groups in the parent domain. This allows child domain users to access resources located in the parent domain.

hashtag
Foreign Principals

Child domain objects can have ACLs on parent domain objects.

We can also enumerate all foreign ACLs for all principals:

PreviousInter-ForestNextKerberoasting

Last updated