Has SID History
Description
The Source security principal has the SID of the Target security principal in its SIDHistory attribute, which means that the Source has the same rights as the Target.
SID History is a legitimate mechanism used when migrating security principals between domains to keep all authorizations referencing their previous SID functional.
However, this is also a persistence mechanism that attackers use, as it allows a discreet backdoor account to have the same rights as the desired target such as an Administrator account.
Exploitation
Attackers who compromise the Source security principal can directly authenticate as the Target security principal since the Target's SID is transparently added into the token that Active Directory authentication mechanisms generate (NTLM & Kerberos).
Remediation
If the Source and Target security principals are related to an approved domain migration, you can consider the relation to be legitimate and not perform any action. This relation remains visible as a reminder of a potential attack path.
If the domain of origin was deleted after the migration or is not configured in Tenable Identity Exposure, the Target security principal is marked as unresolved. Since the risk lies with the Target and that Target does not exist, there is no risk and hence no remediation required.
On the contrary, SID History relations to natively privileged users or groups are very likely malicious since Active Directory prevents their creation. This means that they were probably created using hacker techniques such as a "DCShadow" attack. You can also find these cases in the IoE related to "SID History".
If this is the case, Tenable Identity Exposure recommends a forensic examination of the entire Active Directory forest. The reason is that attackers must have obtained high privileges — domain administrator or equivalent — to edit maliciously the Source's SID history. The forensic examination helps you analyze the attack with corresponding remediation guidance, and identifies potential backdoors to remove.
Finally, Microsoft recommends that you modify all access rights in all services (SMB shares, Exchange, etc.) to use the new SIDs and remove unnecessary SIDHistory values after this migration is complete. This is a housekeeping best practice, although identifying exhaustively and fixing all ACLs is very difficult.
A user who has the right to edit the SIDHistory attribute on the Source object itself can remove SIDHistory values. Contrary to creation, this operation does not require domain administrator rights.
To do this, you can only use PowerShell because graphical tools such as Active Directory Users and Computers will fail. Example:
Set-ADUser -Identity <user> -Remove @{sidhistory="S-1-..."}Caution: While removing a SIDHistory value is easy, reverting this operation is very complicated. This is because you must recreate the SIDHistory value which requires the presence of the other domain that may be decommissioned. For this reason, Microsoft also recommends that you prepare snapshots or backups.
See also