SID History
Group 1Sid history is a technique used to escalate privileges in a parent-child trust configuration.
This attack abuses a TGT attribute called SID History which is a legitimate attribute that was designed to handle the transition of a user from a domain to another: to make sure the moved user maintained access to the previous domain even after being moved to the second one, the user's old SID would be added to the SID History attribute of their account. We can find more information on it here and here.
Manipulating the SID History attribute of a ticket allows users from the child domain to inherit permissions or group memberships from the parent domain; this is possible because SID Filtering is not enabled when dealing with domains from the same forest.
I've documented the different exploitation methods here.
SID History Injection
SID History Injection (or SID Hijacking) refers an attack that consists in injecting the SID of a highly privileged group or user from the target domain into a low-privileged user account in the source domain.
If we're dealing with SID Hijacking in cross-forest configuration we have to be aware that SID Filtering will filter out all SIDs with a Relative Identifier (RID) of 1000. This security measure is usually circumvented by leveraging SIDs with identifiers equal to or higher than 1000 since they might still be associated with high-privilege users or groups.
To start off we can see whether SID History is enabled in the domain at all
If the output of this command includes the TREAT_AS_EXTERNAL attribute then SID History is enabled within the trust.
Now we can enumerate users with SID History enabled we can use the Get-ADUser cmdlet
If we find some interesting user we can reset their password and use a sacrificial PowerShell process to request a TGT for them.
Looking at the user's permissions, we can either decide to abuse existing permissions or execute an ExtraSIDs attack to request a ticket for the user with SID History enabled but with different (and possibly higher) privileges. In order to perform the attack we need:
The KRBTGT hash for the current domain
The SID for the current domain
The name of a target user in the current domain (Any domain user)
The FQDN of the current domain.
The SID of the high privileged group of the target domain
All these information can be retrieved with different methods: BloodHound, secretsdump, lookupsid, Mimikatz, ...
After we fetched all the data we need we can request a golden ticket with the extra SID
Last updated