Windows security identifier (SID) is a unique value that identifies a user, computer account or group. When creating an account, the domain controller (DC) issues a unique SID to each account, which is stored in the database.
When a user logs in, the system retrieves the SID for the respective user, and stores it in an access token. The SID in the access token is used to identify the user in all subsequent interactions with the system. It is also used to track the security principal and access level the account has when a user connects to resources.
If a user moves to another domain, they would lose access to the resources located in their former domain. SID-History is an attribute that supports such migration scenarios; it is instrumental in retaining access when the user migrates from one domain to another. This means that an account can hold multiple SIDs, and all values in SID-History are included in the access token.
The threat with SID-History lies in whether the attributes are secure or not. If attributes are not secure, an account containing Enterprise Administrator SID in its SID-History during migration from one domain to another can elevate access and privilege for the user account to an effective Domain Admin in all domains within the forest.
If the adversary has domain administrator rights (or an equivalent), they can inject harvested or well-known SIDs from another forest in the SID-History. This injected SID will be added to the access tokens and enables impersonation of arbitrary users/groups, such as Enterprise Administrators.
This form of access token manipulation allows for elevated access to resources. The adversary can also use lateral movement techniques such as Remote Services, SMB/Windows Admin Shares, or Windows Remote Management to gain access to otherwise inaccessible domains.
1. Empire: It can add SID-History to a user if on a DC.
2. Mimikatz: The MISC::AddSid can add any SID or user or group account to a user's SID-History.
This technique of privilege escalation is stealthy, but it can still be detected. Here's what to look for to uncover this type of attack.
Organizations that fail to secure their account attributes can fall victim to this type of attack. Once legitimate account migration is complete, ensure cleanup of the SID-History attributes to mitigate risk of such threats.
Ensure that SID filters are applied to interforest trusts (such as forest and external trusts). A forest is a logical boundary in Active Directory that contains the domains, users, assets, and the group policies. A trust is a method of connecting two different domains or forests in order to access the other's resources. The SID filters ensure that any authentication requests over a trust only contain SIDs of security principals from the trusted domain.
The filters can be applied by:
Employing an integrated SIEM tool, such as ManageEngine's Log360, can aid in detecting and mitigating these threats effortlessly. The solution audits Active Directory changes and network device logs to protect organizations from external and internal threats. Click here to learn more about all the features Log360 can offer.
Downloaded the FBI Checklist Ebook
You will receive regular updates on the latest news on cybersecurity.
© 2025 Zoho Corporation Pvt. Ltd. All rights reserved.