Can add a SID-History to a user if on a domain controller.1
SID-History Injection T1134.005
- Tactics
- Privilege Escalation, Stealth
- Platform
- Windows
- Version
- 2.0
- Created
- 18 February 2020
- Last modified
- 12 May 2026
- Contributors
- Alain Homewood, Insomnia Security; Vincent Le Toux
Adversaries may use SID-History Injection to escalate privileges and bypass access controls. The Windows security identifier (SID) is a unique value that identifies a user or group account. SIDs are used by Windows security in both security descriptors and access tokens. [1] An account can hold additional SIDs in the SID-History Active Directory attribute [2], allowing inter-operable account migration between domains (e.g., all values in SID-History are included in access tokens).
SID-History Injection MITRE reference T1134.005
2 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
Mimikatz's MISC::AddSid module can append any SID or user/group account to a user's SID-History. Mimikatz also utilizes SID-History Injection to expand the scope of other components such as generated Kerberos Golden Tickets and DCSync beyond a single domain.12
All 2 software entries for this technique
Offense vs defense T1134.005
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
SID-History Injection detection strategy DET0136
MITRE names one behaviour worth catching for this technique and breaks it into 1 analytic, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Behavior-chain detection for T1134.005 Access Token Manipulation: SID-History Injection (Windows)
AN0383 · Windows
Detection of unauthorized modification of Active Directory SID-History attributes to escalate privileges. This chain involves: (1) privileged operations or API calls to DsAddSidHistory or related AD modification functions, (2) observed attribute changes in SID-History (Event ID 5136), (3) new logon sessions where the token includes unexpected or privileged SID-History values, and (4) follow-on resource access using elevated privileges derived from SID-History injection.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| User Account MetadataDC0013 | WinEventLog:Security | EventCode=4720, 4738 |
| OS API ExecutionDC0021 | etw:Microsoft-Windows-Directory-Services-SAM | api_call: Calls to DsAddSidHistory or related RPC operations |
| Active Directory Object ModificationDC0066 | WinEventLog:Security | EventCode=5136 |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| AllowedSIDHistoryChanges | Approved migration windows or known SID-History population events. |
| TimeWindow | Correlation window between attribute change and suspicious logon activity (default 15–30 minutes). |
| PrivilegedSIDList | List of sensitive SIDs (e.g., Enterprise Admins, Domain Admins) that should never appear in SID-History. |
| UserContextFilter | Exclude trusted migration service accounts or pre-approved administrative tasks. |
| AnomalousSIDCountThreshold | Raise alerts when a token contains more than X SID-History entries (default X=2). |
Clean up SID-History attributes after legitimate account migration is complete.
Consider applying SID Filtering to interforest trusts, such as forest trusts and external trusts, to exclude SID-History from requests to access domain resources. SID Filtering ensures that any authentication requests over a trust only contain SIDs of security principals from the trusted domain (i.e preventing the trusted domain from claiming a user has membership in groups outside of the domain).
SID Filtering of forest trusts is enabled by default, but may have been disabled in some cases to allow a child domain to transitively access forest trusts. SID Filtering of external trusts is automatically enabled on all created external trusts using Server 2003 or later domain controllers. However note that SID Filtering is not automatically applied to legacy trusts or may have been deliberately disabled to allow inter-domain access to resources.
SID Filtering can be applied by:
* Disabling SIDHistory on forest trusts using the netdom tool (netdom trust /domain: /EnableSIDHistory:no on the domain controller)
* Applying SID Filter Quarantining to external trusts using the netdom tool (<code>netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:yes</code> on the domain controller)
* Applying SID Filtering to domain trusts within a single forest is not recommended as it is an unsupported configuration and can cause breaking changes. If a domain within a forest is untrustworthy then it should not be a member of the forest. In this situation it is necessary to first split the trusted and untrusted domains into separate forests where SID Filtering can be applied to an interforest trust
Tests from Atomic Red Team (MIT licence) · technique definition