Windows
SID History
The sidHistory attribute facilitates user migration between domains by retaining the original user's security identifier (SID) in the new domain, ensuring continued access to resources in the original domain.
Mimikatz, a popular hacking tool, can exploit SID history injection by adding an administrator account's SID to the SID history attribute of an account controlled by the attacker.
When logging in with this manipulated account, all associated SIDs, including those of privileged accounts like Domain Admins, are added to the user's access token.
This grants the attacker elevated privileges, allowing them to perform actions like DCSync to retrieve password hashes and create powerful tickets like Golden Tickets or Ticket-Granting Tickets (TGTs).
With these privileges, the attacker can authenticate as any account in the chosen domain, potentially enabling further compromise and persistence within the target environment.
ExtraSids Attack using Mimikatz
This attack allows for the compromise of a parent domain once the child domain has been compromised. Within the same AD forest, the sidHistory property is respected due to a lack of SID Filtering protection. SID Filtering is a protection put in place to filter out authentication requests from a domain in another forest across a trust. Therefore, if a user in a child domain that has their sidHistory set to the Enterprise Admins group (which only exists in the parent domain), they are treated as a member of this group, which allows for administrative access to the entire forest. In other words, we are creating a Golden Ticket from the compromised child domain to compromise the parent domain. In this case, we will leverage the SIDHistory to grant an account (or non-existent account) Enterprise Admin rights by modifying this attribute to contain the SID for the Enterprise Admins group, which will give us full access to the parent domain without actually being part of the group.
To perform this attack after compromising a child domain, we need the following:
The KRBTGT hash for the child domain
The SID for the child domain
The name of a target user in the child domain (does not need to exist!)
The FQDN of the child domain.
The SID of the Enterprise Admins group of the root domain.
With this data collected, the attack can be performed with Mimikatz.
Obtaining the KRBTGT Account's NT Hash using Mimikatz
We can use the PowerView Get-DomainSID function to get the SID for the child domain, but this is also visible in the Mimikatz output above.
Using Get-DomainSID
Next, we can use Get-DomainGroup from PowerView to obtain the SID for the Enterprise Admins group in the parent domain. We could also do this with the Get-ADGroup cmdlet with a command such as Get-ADGroup -Identity "Enterprise Admins" -Server "INLANEFREIGHT.LOCAL".
Obtaining Enterprise Admins Group's SID using Get-DomainGroup
At this point, we have gathered the following data points:
The KRBTGT hash for the child domain:
9d765b482771505cbe97411065964d5fThe SID for the child domain:
S-1-5-21-2806153819-209893948-922872689The name of a target user in the child domain (does not need to exist to create our Golden Ticket!): We'll choose a fake user:
hackerThe FQDN of the child domain:
LOGISTICS.INLANEFREIGHT.LOCALThe SID of the Enterprise Admins group of the root domain:
S-1-5-21-3842939050-3880317879-2865463114-519
Before the attack, we can confirm no access to the file system of the DC in the parent domain.
Using ls to Confirm No Access
Using Mimikatz and the data listed above, we can create a Golden Ticket to access all resources within the parent domain.
Creating a Golden Ticket with Mimikatz
We can confirm that the Kerberos ticket for the non-existent hacker user is residing in memory.
Confirming a Kerberos Ticket is in Memory Using klist
From here, it is possible to access any resources within the parent domain, and we could compromise the parent domain in several ways.
Listing the Entire C: Drive of the Domain Controller
ExtraSids Attack using Rubeus
We can also perform this attack using Rubeus. First, again, we'll confirm that we cannot access the parent domain Domain Controller's file system.
Using ls to Confirm No Access Before Running Rubeus
Next, we will formulate our Rubeus command using the data we retrieved above. The /rc4 flag is the NT hash for the KRBTGT account. The /sids flag will tell Rubeus to create our Golden Ticket giving us the same rights as members of the Enterprise Admins group in the parent domain.
Creating a Golden Ticket using Rubeus
Once again, we can check that the ticket is in memory using the klist command.
Confirming the Ticket is in Memory Using klist
Finally, we can test this access by performing a DCSync attack against the parent domain, targeting the lab_adm Domain Admin user.
Performing a DCSync Attack
When dealing with multiple domains and our target domain is not the same as the user's domain, we will need to specify the exact domain to perform the DCSync operation on the particular domain controller. The command for this would look like the following:
Last updated