SDProp and adminSDHolder attack
Attackers use every possible trick and process they can to get into your Active Directory environment by moving laterally and gaining privileges. One such method is to leverage the SDProp process and gain privileges through the adminSDHolder object.
The brief history of this process, Security Descriptor Propagation (SDProp), goes back to the early 2000s. Administrators were breaking what privileged groups could do in Active Directory when the access control list of the privileged group was changed in error. Microsoft fixed this by introducing the SDProp process, which used the adminSDHolder objects’ ACL and the adminCount attribute of both users and groups.
The process works like this:
- Every 60 minutes, the SDProp process runs.
- The SDProp process copies the ACL from the adminSDHolder object, shown in Figure 1.
- The ACL from adminSDHolder is then pasted onto each and every user and group with an adminCount = 1, as you can see in Figure 2.
You can see this process in action by looking at the replication trail flow between domain controllers (Figure 3).
Attackers realized that if they add a rogue user or group to the adminSDHolder ACL, when the SDProp process ran, they would be added to every privileged user and group automatically. Even if the user or group was manually removed from the ACL of the privileged user or group, the SDProp process would add them back 60 minutes later.
Thus, it is necessary to constantly evaluate the adminSDHolder ACL and accounts that have an adminCount = 1 (but shouldn’t), as these are attack pathways into Active Directory.
Alsid is constantly looking at these attack pathways and will send an alert when one opens. You can see this in the Indicators of Exposure shown in Figure 4.
Being able to see all aspects of an attack in real time enables the security team to react swiftly to prevent any further damage in Active Directory or what the users from AD have access to.