Persistence through SID History
SIDs are used to track the security principal and the account's access when connecting to resources. There is, however, an interesting attribute on accounts called the SID history.
The legitimate use case of SID history is to enable access for an account to effectively be cloned to another. This becomes useful when an organisation is busy performing an AD migration as it allows users to retain access to the original domain while they are being migrated to the new one.
History Can Be Whatever We Want It To Be
With the right permissions, we can just add a SID of our current domain to the SID history of an account we control. Some interesting notes about this persistence technique:
Domain Admin privileges (or equivalent) are usually required for this attack.
When a user logs in, their SIDs are added to their token, defining their permissions.
Injecting the Enterprise Admin SID grants Domain Admin rights across all domains in the forest.
To stay even more hidden, the attacker can modify the SID history of another account.
Forging History
Before we forge SID history, let's just SSH to the Administrator in the DC and get some information regarding the SIDs.
Get-ADUser <your ad username> -properties sidhistory,memberof
We can confirm that our user does not currently have any SID History set. Let's get the SID of the Domain Admins group since this is the group we want to add to our SID History:
Now we add the SID history to our user but first we need to stop the stop the NTDS service and restart it back after done adding the SID history.
Then, we SSH to our low privileged user in THMWRK1 and check his SID history
Nice, we successfully added the SID of Domain Admins group to our low privileged user. We should be able to list directories and files of the DC
Last updated