Microsoft

Microsoft Defender for Identity Recommended Actions: Remove unsecure SID history attributes from entities

by thalpius

Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with fourteen recommended actions. In a series of blog posts, I will go through all fourteen recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The tenth one in the series is the “Remove unsecure SID history attributes from entities” recommended action.

Introduction

You have fourteen recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

Some recommended actions are easy to configure, but others take time, proper planning, auditing, and expertise. This blog post will review the “Remove unsecure SID history attributes from entities” recommended action.

Update: Microsoft updated the recommended actions with six additional recommendations, which makes it a total of twenty. I will describe the six updated ones after this series.

Update: Microsoft removed the “Stop legacy protocol communication” from the Secure Score Recommended Actions.

Introduction

Every object in Active Directory holds a unique Security Identifier or abbreviated SID. When an object migrates from one forest to another, the object gets a new SID. Any permissions set using the object in the source forest do not work anymore because of the new SID. When using SID history, the permissions set still works.

After migrating the object and setting new permissions, you can remove the SIDs. If not, you need to check the SID set on the source forest and set the permissions for the new object. Depending on the organization, this takes time.

SID History

As mentioned in the introduction, every object in Active Directory holds a unique Security Identifier. Although most objects have a friendly name, Windows uses the SID under the hood to identify an object. Here is an example of a SID.

S-1-5-21-1004336348-1177238915-682003330-512

The S indicates the SID is a string, the one after the S is the revision level, and the five after the 1 is the identifier authority. The following four parts of the SID are the domain identifier, which differs per domain. The last part in this example is the relative identifier. In the example above, 512 is the Domain Administrators group. In every domain, the SID for the Domain Administrators will always be 512.

Luckily, Microsoft has well-documented the Security Identifier.

The part we will focus on is the domain identifier. In most domains, the Domain Administrators group will start with S-1-5-21 and end with 512, but the domain identifier will never be the same. If a migration takes place where an object, let us say a user account, is migrated to another domain, the domain identifier will change. Migrating an object from domain to domain is only an issue if you want the object to keep having access to resources in the original domain.

Although the name does not change, the SID does. Since Windows uses the SID to identify an object, access to the original domain no longer works. Using SID history, the object keeps its access to the resources in the original domain.

Image 1: SID changed after migration of the object

In the image above, you see a user migrated to another forest. The objectSID is different than the original objectSID since it is a new object in a new forest. When the user accesses a resource in the “old” forest due to SID history, the user still has access as Windows validates the access using the SID. Without an SID history, the new SID cannot access the resources in the “old” forest.

SID Filtering

Imagine if a malicious actor compromises Forest B, adds the SID for the Domain Admins group for Forest A, and authenticates to a resource in Forest A. Since the malicious actor has complete control over Forest B, creating their ticket and adding SIDs is possible. Luckily, Microsoft prevents high-privilege groups from adding to a ticket when you authenticate cross-forest due to SID filtering.

When you present a ticket from Forest B to Forest A and request a service ticket, specific high-privilege SIDs like Domain, Schema, and Enterprise Administrators are filtered out. Without the filter, once a malicious actor compromises a forest and there is a forest trust, all trusted forests are instantly compromised.

Unfortunately, only high-privileged groups are filtered out. A malicious actor can still add SIDs from groups, which makes the malicious actor authenticate to resources in the other forest.

Migration

Remove all SID history from your objects within Active Directory to prevent a malicious actor from using it to compromise resources in another forest. After a complete migration of the objects from Forest A to Forest B, there is no need for SID history.

Unfortunately, not all SID history gets deleted from all objects in the new forest after migration. Microsoft Defender for Identity identifies objects within Active Directory with SID history. Use the PowerShell command to search for users with SID history enabled.

Get-ADUser -Filter {SIDHistory -like $SID} -Properties SIDHistory | Select Name, Enabled, SIDHistory

Suppose no resource in a trusted forest uses SID history. In that case, deleting all SID history on the objects within Active Directory mitigates the risks of malicious actors accessing resources in another forest.

Conclusion

Not all administrators consider SID history a risk. Luckily, Microsoft Defender for Identity identifies objects with SID history, and removing it mitigates the risk of a successful attack from forest to forest. There is no need for SID history in a single-forest, single-domain environment. If any SID history is left in a single-forest, single-domain environment, removing SID history for all objects in Active Directory is a must. Then again, if no migration is running or objects from one forest need to access resources in another, removing SID history is also a must.