Windows Security Identifier (SID) History Injection Exposure

Attackers often look for the easiest way to escalate privileges and bypass security controls. The Windows Security Identifier (SID) injection technique allows attackers to take advantage of the SID History attribute, escalate privileges, and move laterally within the organization’s Active Directory (AD) environment.

What is the Windows Security Identifier (SID), and what is its role?

The SID is a unique value used to identify a user, computer account, or group. Each account has a unique SID the domain controller (DC) issues when it creates the account, stored in a database. The SID contains a domain (an account authority portion) and Relative Identifier (RID), a smaller integer representing an identity relative to the account authority. RIDs are unique for each security principal SID created in a domain and allocated from a RID pool controlled by the master function called RID Master FSMO. The RID Master FSMO role owner is the single DC responsible for processing RID pool requests from all DCs within a given domain. It is also responsible for moving an object from one domain to another during an inter-domain object move.

The following are Windows security elements that use SIDs to identify users, computers, Managed Service Accounts, groups, and access controls.

  • Security Descriptors – To identify the owner of an object and primary group. It can also contain a DACL that controls access to the object and a SACL that controls the logging of attempts to access the object.
  • Access Control Entries – To identify the trustee for whom access is allowed, denied, or audited.
  • Access Tokens – To identify the user and the groups to which the user belongs.

A standard user account can hold additional SIDs in the SID History attribute, used during the account migration between domains. For example, suppose a standard user in domain A migrates to domain B. In that case, the user cannot access resources that were accessible previously because migrated users from domain B can’t access resources located at domain A. Here, SID History plays a vital role in ensuring users retain access when moved (migrated) from one domain.

What is the problem with SID History Injection Exposure?

The problem with SID History is that it allows the injection of any SID values. Knowing this, an attacker can exploit the SID History attribute by injecting higher privileged SID values such as Domain Administrator (or equivalent) rights and hiding in a low privileged account. This injection results in elevated access to the local resources or unrestricted access to remote systems via lateral movement techniques such as Remote ServicesSMB/Windows Admin Shares, or Windows Remote Management.

How do attackers exploit SID History Injection Exposure?

An attacker can compromise a standard user account with higher privileged rights and add the Administrator’s SID to the SID History attribute of that compromised user. For example, the PowerShell cmdlet “Get-ADUser <user> -Properties SIDHistory” is used to verify the SID History attribute of the user “pocuser”, the value of the SID History attribute is currently empty, as shown in the figure below.

Attackers can use tools like DSInternals or Mimikatz modules which enable SID History injection as a method to achieve persistence. They can add the SID History attribute to any user account using the “privilege::debug” and “sid::add /sam:pocuser /new:administrator” Mimikatz commands.

Rerunning the PowerShell cmdlet confirms the SID History and Relative IDentifier (RID) value. The RID value set to 500 indicates a user account for the system administrator. By default, it is the only user account that can give attackers full control over the system. Here is the list of well-known SID structures documented by Microsoft.

Attackers can now abuse the “pocuser”, who already has administrator rights to log in to the system. They can leverage the same user account and rights granted through SID History and get unrestricted network access to the entire AD domain. Attackers can further expand to a DCSync attack or pull the KRBTGT account password data from a Domain Controller.

Detection and Defensive Strategy

The Attivo Networks ADAssessor continuously monitors AD exposures. The solution detects and reports on accounts set with well-known privileged SID values in the SID History attribute. The following defensive steps also help organizations to evaluate and prevent privilege escalations.

  • Examine objects in the user’s SID History attributes using the PowerShell “Get-ADUser” cmdlet, especially users with SID History values from the same domain.
  • Examine user accounts with any well-known privileged SID values.
  • Check users with the same SID History attribute right after migrating between domains.
  • Delete the SID History attribute of the suspicious user using the following command.
    • Get-ADUser USERNAME -properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}

Conclusion

SID History Injection is one of the stealthier techniques for an attacker to maintain Domain persistence. Organizations can monitor for and remediate the presence of privileged SID values in the SID History attributes. These oversights may lead to escalation of privileges bypassing existing access controls. For more information, please visit https://www.sentinelone.com/wp-content/uploads/product/adassessor/.

References

Attivo's Identity Suite
Ready to experience Attivo Networks, the market’s leading identity security suite?