Active Directory DACL Backdoors
In my last blog post, we examined Active Directory (AD) backdoors and how to defend against them. The botnets’ primary communication mechanism relied on abusing AD attributes. Once established, these botnets allow attackers to communicate across internal security controls, exfiltrate data—and most importantly—gain a foothold that is very difficult to detect and remove. All accomplished without one line of malicious code. Now that’s a real life advanced persistent threat…only it isn’t as advanced as nation-state style attacks and does not require nation-state levels of expertise to carry out.
Today, I want to examine another “malware-less” persistence technique—AD Discretionary Access Control Lists (DACL) Backdoors. Said another way, the authors of the research define it as “maliciously crafted Access Control Entries (ACEs) that allow for later domain or object compromise.” Much like the botnet attack that I profiled, this technique also abuses native Active Directory functionality to achieve its goal, only this time instead of abusing User Attributes, it is AD DACLs that are abused for controlling objects. Again, this requires no exploit to perform. However, an attacker would either need the correct privileges or have gained those privileges via any of the methods that Jeff Warren, STEALTHbits SVP of Technical Product Management, covers in his Active Directory attack series.
DACLs are the Perfect Place to Create AD Backdoors
The stealth primitives outlined in this attack hide the existence of security principals or deny an admin the ability to read a DACL on an object. Why does this make for a good “backdoor”?
Maliciously modified Discretionary Access Control List (DACL) are:
- Difficult to locate
- Often overlooked by defenders
- Difficult to determine whether a specific DACL misconfiguration was set intentionally or implemented by accident
- Minimal forensic footprint (Malware-less); traditional security tools simply will not find it
- For insider threats, it provides plausible deniability (easily could have been a misconfiguration, my bad ¯\_(ツ)_/¯ )
- Attackers know this!
Access Control Lists (ACLs) in Active Directory
As I often like to do, let’s lay a little ground work first and get an understanding of Access Control Lists (ACLs) within Active Directory.
Access Control Lists are part of Active Directory security descriptors, which contain the security information associated with securable objects. Within those descriptors are the discretionary access control list (DACL) that controls access to the object, along with the system access control list (SACL) that controls the logging of attempts to access the object. An object’s Discretionary Access Control List (DACL) and System Access Control List (SACL) are ordered collections of Access Control Entries (ACEs).
All ACEs have an access mask, which is a 32-bit value whose bits correspond to the access rights supported by an object. All Windows securable objects use an access mask format that includes bits for generic access rights, standard access rights, SACL access rights, and directory services access rights.
The complete details regarding how access control works within Active Directory is slightly out of scope for today’s post. However, you may want to check out the MSDN article ‘How Access Control Works in Active Directory Domain Services’ as well the full paper of this attack, published by Andy Robbins and Will Schroeder. For this attack, the focus will be on the Owner, DACL, and the access control mask shown below via AD User and Computers (ADUC), which is simply a graphical display of the 32-bit access mask.
There are a number of access masks. However, our focus will be on the DS_CONTROL_ACCESS mask, which when flipped, grants read access to a confidential attribute, such as ms-Mcs-AdmPwd, or an extended right, such as User-Force-Change-Password that allows a password to be changed without knowing the current password.
So ms-Mcs-AdmPwd actually stores the plaintext of the randomized local administrator password for the machine represented by the computer object. This is why it is marked as a confidential attribute. If you were to flip the DS_CONTROL_ACCESS mask bit on the property, it would allow read access to the plaintext of the randomized local administrator password!
Additionally, if you wanted to enumerate users who have read access to this attribute, you would search for ACE entries with DS_CONTROL_ACCESS flipped and the ObjectType GUID referring to the randomized GUID pointing to ms-Mcs-AdmPwd that is specific to the environment. Both intriguing ideas that I may expand on in future posts. However, we are focused on backdoors right now.
Taking over Active Directory
Setting up the backdoor relies on one of two primary take over primitives:
- Forcing a password reset (Powerview abuse function: Set-DomainUserPassword)or….
- A targeted Kerberoasting attack (Powerview abuse function: Set-DomainObjectOwner)
For the targeted Kerberoasting attack, we rely on our ill-gotten write access to the SPN property of a user object. With that, we can write whatever fake value we want to that property and then request a Kerberos ticket for that user account. With ticket in hand, we can then crack it offline and recover the user’s current clear text password. If you are following along at home, the two PowerView abuse functions referenced above are part of the PowerSpolit collection of Microsoft PowerShell modules used for penetration testing. These are also covered by Jeff Warren in his Active Directory attack series.
Now that we have some ground work laid, in my next post I will describe how the backdoor is designed, along with the mechanics of a DCSync backdoor, which allows non-administrative users to perform a DCSync and an AdminSDHolder backdoor, which allows attackers to grant themselves the right to force a password reset on any account. The key to all of these is the fact that these rights will be hidden from legitimate administrators–hence the backdoor.
To register for the webinar on Active Directory Botnets & DACL Backdoors: How Attackers Exploit Native AD Capabilities to Achieve Domain Persistence, please click here.
Don’t miss a post! Subscribe to The Insider Threat Security Blog here: