A Windows security identifier, or SID, uniquely identifies a user or group. SIDs appear in security descriptors and in access tokens. T1134.005, SID-History Injection, abuses an Active Directory attribute that was designed to make migrations easier. It is an Access Token Manipulation sub-technique under stealth and privilege escalation, for Windows.
How attackers use it
An account can hold extra SIDs in its SID-History attribute. The point is interoperability during account migration between domains. Every value in SID-History is included in the account's access tokens.
MITRE's description of the abuse: with Domain Administrator rights or equivalent, harvested or well-known SID values can be inserted into SID-History. That lets an account impersonate arbitrary users or groups, such as Enterprise Administrators. The result can be elevated access to local resources, or access to domains that were previously out of reach through lateral movement over remote services, SMB and admin shares, or Windows Remote Management.
It needs high privilege to start, so it is mostly a persistence and reach technique rather than a first step. MITRE lists Mimikatz and Empire among tools that can do it.
How to detect it
MITRE's chain has four parts:
- Privileged operations or API calls such as
DsAddSidHistoryor related directory modification functions. - Observed attribute changes to SID-History, logged as Event ID 5136.
- New logon sessions where the token includes unexpected or privileged SID-History values.
- Follow-on resource access using the elevated privileges.
Event ID 5136 (a directory service object was modified) needs auditing of directory service changes on the domain controllers. Windows also has dedicated events for SID-History being added to an account, 4765 on success and 4766 on failure. In a healthy domain these are rare, so any occurrence outside a planned migration deserves review.
How to reduce the risk
MITRE lists Active Directory configuration:
- Clean up SID-History after migrations finish. Remove the old values once legitimate account migration is complete, so there is nothing for an attacker to blend into.
- Apply SID filtering on interforest trusts. Forest trusts and external trusts can be set to exclude SID-History from requests for domain resources, so that authentication across a trust carries only SIDs from the trusted domain.
Also guard the rights needed to make the change. Domain Administrator equivalence is the entry price, so tiering and monitoring of those accounts apply.
Check your own environment
With the Active Directory PowerShell module, read-only:
Get-ADUser -Filter 'SIDHistory -like "*"' -Properties SIDHistory | Select-Object SamAccountName, SIDHistory
Get-ADTrust -Filter * | Select-Object Name, SIDFilteringQuarantined, SIDFilteringForestAware
The first lists users with SID-History values. Each one should match a past migration you can name. The second shows how SID filtering is set on each trust.
Then confirm directory service change auditing is on for your domain controllers so event 5136 exists when you need it.
Quick check
Why is SID-History a useful target?
Every value in it is included in the account's access tokens, so a privileged SID placed there is honored as if the account were a member of that group.
What two cleanup steps does MITRE recommend?
Remove SID-History values after legitimate migrations finish, and apply SID filtering on interforest trusts.
Sources
- MITRE ATT&CK, T1134.005 SID-History Injection
