Skip to main content

SID History

Security Identifiers (SID) are used to track the Security Principal and the Account's Access when connecting to Resources. There is, however, an 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 Organization 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.

In the new Domain, the User would have a new SID, but we can add the User's existing SID in the SID History, which will still allow them to access Resources in the previous Domain using their new Account.


SID History is not restricted to only including SID's from other Domains. With the right Permissions, we can just add a SID of our current Domain to the SID History of an Account we control.

  • We normally require Domain Admin Privileges or the equivalent to perform this Attack.
  • When the Account creates a Logon Event, the SID's associated with the Account are added to the User's Token, which then determines the Privileges associated with the Account. This includes Group SID's.
  • We can take this Attack a step further if we Inject the Enterprise Admin SID since this would Elevate the Account's Privileges to effective be Domain Admin in all Domains in the Forest.
  • Since the SID's are added to the User's Token, Privileges would be respected even if the Account is not a Member of the actual Group. Making this a very sneaky method of Persistence. We have all the Permissions we need to compromise the entire Domain, but our Account can simply be a normal User Account with Membership only to the Domain Users Group. We can hide from the Blue Team by always using this account to alter the SID History of another Account, so the initial Persistence vector is not as easily Discovered and remedied.