T1134.005: SID-History Injection

SID-History Injection matters because it can turn an Active Directory migration feature into a privilege-escalation and stealth problem. If an attacker already has Domain Administrator or equivalent rights, adding powerful or well-known SIDs to an account’s SID-History attribute can cause Windows access tokens to include privileges the account should not normally have. For leaders, this is less about a single endpoint alert and more about whether AD governance, privileged account monitoring, and incident response can prove that identity-based access has not been silently expanded.

Executive priority

Prioritize this as an Active Directory control and auditability issue for Windows environments. The behavior can affect privileged access decisions, cross-domain access, and lateral movement paths involving Remote Services, SMB/Windows Admin Shares, or Windows Remote Management. Executives should ask whether changes to sensitive AD attributes are monitored, whether privileged AD administration is tightly controlled, and whether incident responders can quickly validate SID-History values during a domain compromise investigation.

Technical view

This is a Windows sub-technique of Access Token Manipulation under stealth and privilege escalation. SOC and IR teams should validate visibility into Active Directory attribute changes, especially modifications to SID-History on user or group accounts, and correlate those changes with privileged administrative activity. Because the ATT&CK object provides no official detection text, use the related detection strategy DET0136 as a direction to build behavior-chain detection rather than relying on a single event. Relationship context also shows Mimikatz and Empire as software that can use this technique, so detections should account for both AD attribute manipulation and broader post-exploitation context without assuming a specific tool is always present.

Likely telemetry

Active Directory directory service change events for user and group objects
Audit records showing modifications to the SID-History attribute
Privileged account logon and administrative action logs
Domain controller security logs
Access token or authorization-context evidence where available

Detection direction

Baseline legitimate SID-History usage, especially where domain migrations have occurred, then alert on unexpected additions or changes.
Correlate SID-History modification with the actor account, source host, time of change, and whether the actor held Domain Administrator or equivalent rights.
Treat newly added privileged, well-known, or cross-domain SIDs as high-review events, while accounting for authorized migration activity as a likely false-positive source.
Use behavior-chain logic: suspicious SID-History changes followed by lateral movement over Remote Services, SMB admin shares, or WinRM should receive higher priority.
Do not depend solely on tool-name detections for Mimikatz or Empire; validate the underlying AD attribute and access-token behavior.

Mitigation priorities

Harden Active Directory configuration and privileged account governance consistent with mitigation M1015.
Restrict who can administer accounts and modify sensitive AD attributes, especially in domain administration paths.
Review and document legitimate SID-History use cases, such as migrations, so unexpected values can be identified quickly.
Maintain audit logging and retention on domain controllers sufficient for incident response and compliance evidence.
During IR, inspect SID-History values on privileged and recently modified accounts before declaring AD privilege integrity restored.

Analyst notes and limits

The key decision point is whether the organization can distinguish legitimate SID-History migration artifacts from malicious privilege expansion. This technique requires Domain Administrator or equivalent rights according to the supplied ATT&CK description, so it is often most relevant in suspected AD compromise, privilege misuse, or post-exploitation investigations.

The official ATT&CK detection field is not provided. Telemetry and detection guidance are inferred conservatively from the supplied description, platforms, tactics, mitigation relationship, and DET0136 relationship. Local AD architecture, migration history, audit policy, and log retention determine practical coverage.

Official MITRE ATT&CK definition

SID-History Injection

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).

With Domain Administrator (or equivalent) rights, harvested or well-known SID values [3] may be inserted into SID-History to enable impersonation of arbitrary users/groups such as Enterprise Administrators. This manipulation may result in elevated access to local resources and/or access to otherwise inaccessible domains via lateral movement techniques such as Remote Services, SMB/Windows Admin Shares, or Windows Remote Management.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

Filter related techniques 2 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1134	Access Token Manipulation	This object subtechnique of Access Token Manipulation.
Enterprise	T1178	SID-History Injection	SID-History Injection revoked by this object.

Associated objects

Groups, software, and campaigns

S0002: Mimikatz

Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many other features that make it useful for testing the security of networks. [1] [2]

Windows

S0363: Empire

Empire is an open-source, cross-platform remote administration and post-exploitation framework that is publicly available on GitHub. While the tool itself is primarily written in Python, the post-exploitation agents are written in pure PowerShell for Windows and Python for Linux/macOS. Empire was one of five tools singled out by a joint report on public hacking tools being widely used by adversaries.[1][2][3]

LinuxmacOSWindows

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1015: Active Directory Configuration Enterprise uses · Tool S0002: Mimikatz Enterprise uses · Tool S0363: Empire Enterprise subtechnique of · Technique T1134: Access Token Manipulation Enterprise revoked by · Technique T1178: SID-History Injection Enterprise detects · Detection Strategy DET0136: Behavior-chain detection for T1134.005 Access Token Manipulation: SID-History Injection (Windows) Enterprise

Mitigations

Mitigation direction

M1015: Active Directory Configuration

Implement robust Active Directory (AD) configurations using group policies to secure user accounts, control access, and minimize the attack surface. AD configurations enable centralized control over account settings, logon policies, and permissions, reducing the risk of unauthorized access and lateral movement within the network. This mitigation can be implemented through the following measures:

Account Configuration:

- Implementation: Use domain accounts instead of local accounts to leverage AD’s centralized management, including group policies, auditing, and access control. - Use Case: For IT staff managing shared resources, provision domain accounts that allow IT teams to log in centrally, reducing the risk of unmanaged, rogue local accounts on individual machines.

Interactive Logon Restrictions:

- Implementation: Configure group policies to restrict interactive logons (e.g., direct physical or RDP logons) for service accounts or privileged accounts that do not require such access. - Use Case: Prevent service accounts, such as SQL Server accounts, from having interactive logon privileges. This reduces the risk of these accounts being leveraged for lateral movement if compromised.

Remote Desktop Settings:

- Implementation: Limit Remote Desktop Protocol (RDP) access to specific, authorized accounts. Use group policies to enforce this, allowing only necessary users to establish RDP sessions. - Use Case: On sensitive servers (e.g., domain controllers or financial databases), restrict RDP access to administrative accounts only, while all other users are denied access.

Dedicated Administrative Accounts:

- Implementation: Create domain-wide administrative accounts that are restricted from interactive logons, designed solely for high-level tasks (e.g., software installation, patching). - Use Case: Create separate administrative accounts for different purposes, such as one set of accounts for installations and another for managing repository access. This limits exposure and helps reduce attack vectors.

Authentication Silos:

- Implementation: Configure Authentication Silos in AD, using group policies to create access zones with restrictions based on membership, such as the Protected Users security group. This restricts access to critical accounts and minimizes exposure to potential threats. - Use Case: Place high-risk or high-value accounts, such as executive or administrative accounts, in an Authentication Silo with extra controls, limiting their exposure to only necessary systems. This reduces the risk of credential misuse or abuse if these accounts are compromised.

**Tools for Implementation**:

- Active Directory Group Policies: Use Group Policy Management Console (GPMC) to configure, deploy, and enforce policies across AD environments. - PowerShell: Automate account configuration, logon restrictions, and policy application using PowerShell scripts. - AD Administrative Center: Manage Authentication Silos and configure high-level policies for critical user groups within AD.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release: 19.1
Object version: 2.0
Created: Feb 18, 2020, 18:34 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: 05275336badf2daa...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	2.0	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`05275336badf…`

Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
Microsoft SID

Microsoft. (n.d.). Security Identifiers. Retrieved November 30, 2017.
Open source URL
[2]
Microsoft SID-History Attribute

Microsoft. (n.d.). Active Directory Schema - SID-History attribute. Retrieved November 30, 2017.
Open source URL
[3]
Microsoft Well Known SIDs Jun 2017

Microsoft. (2017, June 23). Well-known security identifiers in Windows operating systems. Retrieved November 30, 2017.
Open source URL
[4]
mitre-attack T1134.005
Open source URL

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use

Analyst context for executives and security teams