SID history injection abuses the sIDHistory attribute, which lets a migrated account retain the access of its old identity. An attacker writes a privileged SID (Domain Admins, Enterprise Admins, or a target domain's admin) into an account's sIDHistory, so the account inherits those rights while looking ordinary. It is used for stealthy persistence and for escalation across domain and forest trusts. Defend by monitoring sIDHistory changes, enabling SID filtering on trusts, and treating it as tier-0.
What SID history injection is
During migrations, sIDHistory lets an account carry the SIDs of its former identity so it keeps access without re-permissioning everything. That flexibility is the weakness: a SID placed in sIDHistory grants that identity's access. An attacker who can write the attribute injects a privileged SID, and the account is treated as a member of that privileged group without ever being added to it.
How the attack works
With sufficient rights (Domain Admin, or via DCShadow / a directory-level write) the attacker adds a privileged SID to a target account's sIDHistory, using tools such as mimikatz sid::add or DSInternals Add-ADDBSidHistory. Injecting the Enterprise Admins SID, or an admin SID from another domain in the forest, escalates the account across the boundary, since SID filtering often does not apply within a forest. Shown for defensive testing.
How to defend against it
Monitor for changes to sIDHistory and alert on any account that gains a privileged or foreign-domain SID, since legitimate injections only happen during migrations. Enforce SID filtering (quarantine) on external and forest trusts so injected foreign SIDs are dropped, treat the forest as the security boundary, and clean up leftover sIDHistory values after migrations.
References
- [1]MITRE ATT&CK Enterprise Matrix(MITRE ATT&CK)
- [2]Microsoft: Security identifiers and SID history(Microsoft)
An injected SID can hand an account your whole forest, invisibly. Talk to a security expert about auditing sIDHistory across your domains.