The old identity that still opens every door (SID History)
SID History was built so users keep access after a migration. Inject a privileged SID into an account and it inherits that access invisibly, across domains. Here is the abuse, and the fix.
The most dangerous privilege is the one that does not show up in any group membership.
What it is
The SID History attribute lets a migrated account retain access tied to its old SID. An attacker with sufficient rights injects the SID of a privileged group (for example, Domain Admins, or a SID from a parent domain across a trust) into an account’s SID History. The account then inherits that access transparently, with no group membership to spot, including across domain trusts. This is T1134.005 (SID-History injection) with T1098.
Why it works
Access checks honor SID History, the privilege is hidden because the account is not visibly in the group, and it survives most cleanup that looks only at group memberships.
How to detect it
Look for accounts whose SID History contains privileged or cross-domain SIDs, and changes to the attribute; audit SID History across the forest.
The fix that holds
Audit and clear unexpected SID History, enable SID filtering on trusts, restrict who can write the attribute, and include SID History in privileged-access reviews. Treat an injected privileged SID as a compromise indicator.
Practice it
We built a SID History injection scenario in GraphLattice Range so teams learn to find the hidden privilege and clean it up.