Access token manipulation: SID-History Injection

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.

What is SID-History?

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.

What is SID-History Injection?

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.

SID-History Injection procedure examples

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.

SID-History Injection detection

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.

• Examine data in user's SID-History attributes using the Powershell Get-AdUser cmdlet. Look for users who have SID-History values from the same domain.
• Monitor account management events for any changes made to SID-History, both failed and successful.
• Look for API calls to the DsAddSidHistory function.

SID-History Injection mitigation

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:

• Disabling SID-History on forest trusts. This can be done using the netdom tool (netdom trust /domain: /EnableSIDHistory:no on the domain controller)
• Applying SID Filter Quarantining to external trusts. This can also be done using the netdom tool (netdom trust /domain: /quarantine:yes on the domain controller)
• Splitting the trusted and untrusted domains into separate forests where SID Filtering can be applied to an interforest trust.

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.

What's next?