How to Defend against AdminSDHolder Attacks

In this blog post, we’ll be discussing the topic of the AdminSDHolder object in Active Directory and how it can be utilized in Active Directory attacks. Finally, we will discuss how to use StealthDEFEND to detect and respond to this type of attack.

Introduction to the “AdminSDHolder”

The AdminSDHolder is an Active Directory object that is basically a container to essentially act as a security descriptor template for protected accounts and groups in an Active Directory domain

A security descriptor includes information such as: (SID, A primary group SID, DACL, SACL, and more) that specifies an object’s security.

So, the AdminSDHolder has a lot of inherent control over what these level of privilege protected users and groups will have. To enforce this, a process named SDProp will execute once an hour that sets these descriptor permissions on the members of the AdminSDHolder group.

For more details on exactly how the AdminSDHolder object works, I’d suggest taking a look at some of the official documentation and blog posts from Microsoft on this topic. 

• Protected Accounts and Groups in Active Directory
• Security Descriptor Propagator

It can get a bit complicated to understand how the AdminSDHolder object and related processes all work but the basics as specified above are generally enough to understand how this object can be used by an attacker.

What is an AdminSDHolder Attack?

A typical attack that exploits the AdminSDHolder will use it to gain persistence in the environment. The goal is to apply changes to the AdminSDHolder – specifically the ACL applied to the object. An attack may choose to add accounts to this list to allow them to essentially give an account the same level of privileges normally associated with domain protected accounts and groups present in the AdminSDHolder object by default.

If an organization does happen to notice questionable activity for an account used by the attacker, the choice may be made to restrict access for the account. This is where the SDProp job comes into play as those changes would be reverted within one hour and the attacker account would have privileged access once again as the SDProp job would restore the ACLs specified on the AdminSDHolder group.

In this case, the account must have its ACL changes revoked from the AdminSDHolder object in order to truly remove those privileges.

Given the somewhat complicated nature of the AdminSDHolder object, it can easily be overlooked by system administrators, thus making it a valuable tool for attackers.

Step by Step Process of AdminSDHolder Attack

To further help illustrate the end to end steps an attacker may actually use in an AdminSDHolder attacker, here is a simple step by step example of an AdminSDHolder attack:

1. Attacker compromises privileged credentials (e.g. via phishing or social engineering, is already a privileged insider, by exploiting weak permissions, etc.)
2. The Attacker modifies AdminSDHolder by adding a new user to its Access Control List (ACL)
3. Via the SDProp process, the AdminSDHolder permissions are pushed down to all protected objects every 60 minutes (by default) including privileged groups such as Domain Admins, Administrators, Enterprise Admins, and Schema Admins
4. Even if an administrator sees inappropriate permission on a protected object and removes it, within an hour those permissions will be put back in place by the SDProp job.

AdminSDHolder Threat Detection with StealthDEFEND

Detection for this threat is actually relatively simple, as it can typically be detected by changes made to the AdminSDHolder object. In most Active Directory environments this is an object that is rarely (if ever) modified. The threat detection of StealthDEFEND will monitor for any changes specifically made to the NTSecurityDescriptor of the AdminSDHolder object. This allows StealthDEFEND to efficiently detect these types of attacks immediately when the change occurs.

Descriptions of the change that was made will also be displayed via the threat activity diagram and details of the event will be present in the threat event grid.

AdminSDHolder Threat Response with StealthDEFEND

Responding to an AdminSDHolder attack is quite interesting as this is an attack used to maintain persistence, so typically if an attacker has gotten this far they may have potentially already achieved part of their objectives or are planning to take action in the future.

Due to this fact, it is suggested that any AdminSDHolder holder attack should be coupled with an investigative response by the security team – this can typically be assisted by the ServiceNow Incident integration or the native alerting present in StealthDEFEND. That being said we also have a number of steps that can and should be taken immediately.

StealthDEFEND understands and is able to interpret ACL changes made to objects. Due to this capability, if we see changes being made to an object we can simply “undo” the permissions that were made. If an attacker user account is added to the AdminSDHolder ACL we can simply parse that change and remove the user from the ACL.

Get a free trial of StealthDEFEND, today!