How to Easily Solve the Difficult Problem of Active Directory Botnets

Folks,

The year's almost coming to an end, and I just realized that one of the topics that I had not yet addressed as a part of my basic Active Directory Security School for Microsoft was this inane topic of Active Directory Botnets so today's post is on AD Botnets.

There's less than 100 hours left this year, and I value every minute, so this one's going to be short, yet sufficient.

Active Directory Botnets

Earlier this year, one of the two presentations on Active Directory Security at the famous Black Hat Conference USA 2017 was titled - The Active Directory Botnet. (The other one was An ACE Up the Sleeve - Designing Active Directory ACL Backdoors.)

Both of these presentations seem to have gotten a lot of attention, and as to the presentation on Active Directory Botnets, its authors said that this is (and I quote) "a nightmare of an implementation error with no easy fix!"

Well, today I'll show you just how easy it is to solve/fix this supposedly difficult problem :-)

In today's post, I am not going to go into the details of how attackers could set up these botnets because my focus is on helping organizations eliminate the very possibility of this issue, so if you're interested in the technical details, here are a few pointers -

1. The slides of the presentation titled The Active Directory Botnet that was made at the Black Hat Conference 2017
2. A video of the presentation titled The Active Directory Botnet that was made at the Black Hat Conference 2017
3. A short interview with the presenters of this presentation.

Since my purpose is on helping organizations mitigate this issue, I'm going to focus on the mitigation aspect.




What Makes This Possible

In order to find out how to easily mitigate this issue, it helps to first understand what makes this issue possible in the first place.

Here's the short of what makes this all possible  -

As you may know, Active Directory, being the very foundation of cyber security in a Microsoft Windows Server network, stores and protects the entirety of an organization's domain user accounts, security groups, computer accounts, security policies etc.

As you may also know, in Active Directory literally everything is an object, and an object is essentially a collection of numerous attributes, as defined in the Active Directory Schema. So for example, there exist attributes for elements such as a user's first name, last name, password, manager, contact details, address details, user profile, a picture etc. etc.

Further, Active Directory's powerful security/delegation model makes it very easy for IT personnel to provision access in Active Directory for various stakeholders, to fulfill business needs wherein these stakeholders may need to be able to modify any of these fields/attributes. For example, if an HR application may have a need to change the Manager field/attribute on user accounts, such access can be very easily and precisely delegated for that HR application's service account.

Now, it turns out that by default, Active Directory also lets all domain user account holders modify certain fields/attributes on their own domain user accounts. Examples of such fields/attributes include Address, Assistant, Personal-Title, Phone-Home-Other, Phone-Ip-Other, Picture, Street-Address, WWW-Home-Page  etc. to name a few.

These attributes could store values of various data-types, so for instance, while some could simply and solely store a text string, others could store a distinguished name, and still others could store binary data. An example of an attribute that can solely store a text value is Surname and an example of an attribute that can store binary data is Picture.

Finally, to simplify access control, numerous such related fields/attributes can be aggregated together into an Active Directory construct known simply as a Property-Set.

Examples of Active Directory Property Sets include Personal Information, Private Information, Web Information, etc.


Tying all of the above together, in the access control list (ACL) of every domain user account, by default there are explicit access control entries (ACEs) that grant the security principal Personal Self, the ability to modify the Personal Information, Phone and Mail Options and Web Information property sets. Since the Personal Self  security principal on an Active Directory user object maps to the domain user account itself, the presence of these security permissions provides sufficient effective access to the domain user account holder to be able to modify all the attributes that are members of these property sets!

Now, imagine a scenario wherein the computer onto which this domain user account usually logs on has been compromised. In that scenario, the attacker could now have malicious code run in the security context of this domain user account, and if so, then one of the things that malicious code could do is update these attributes on the user's domain user account! 

In such a scenario, how the attacker chooses to use this default ability to update these attributes in Active Directory is purely a function of his/her imagination, and it so happens that in this particular case, the presenters of that specific presentation at Black Hat came up with a scenario wherein attackers could choose to use this default access granted to domain user accounts to introduce and operate Botnets in Active Directory environments!






How to Easily Solve the Supposedly Difficult Problem of
Active Directory Botnets -

According to the authors of this presentation, this is (and I quote) "a nightmare of an implementation error with no east fix!" 

If you ask me, I'll tell you "this is an issue that can be mitigated in minutes, and here's how" -

All that organizational IT personnel need to do is write a simple script whose purpose is simply to remove those explicit ACEs in the ACLs of domain user accounts in an Active Directory that grant the Personal Self security principal Write-Property permissions to the involved property sets.

Specifically, here are the three explicit ACEs that you may want to remove -

1. { Allow   SELF   Read/write personal information }
2. { Allow   SELF   Read/write phone and mail options }
3. { Allow   SELF   Read/write web information }

Such a script can be written and be executed within minutes, and once it has been executed, there should no longer* be any ACEs in the ACLs of the organization's domain user accounts that would allow these domain user accounts the ability to modify these attributes on their own objects, and as a consequence, perpetrators will no longer be able to leverage this default modify access in Active Directory, resulting in a situation where this issue would no longer be an issue at all, since the underlying enabler of this issue would have been eliminated!

* Kindly see sections titled A Caveat and An Advanced Tip below

It really is as simple as this! That's it!


Now, some might ask - "But wouldn't this impact the ability to users to modify such attributes in Active Directory and/or cause potential application compatibility issues if certain apps were relying on this default access to properly function today?!"

The answer to that question is that realistically speaking, domain user accounts holders should not ideally possess any level of modify access in the Active Directory, and most likely no default applications should be relying on this default access granted to domain user accounts to function, so the application compatibility impact of making this change could be none to minimal.

Disclaimer: Organizations know their unique Active Directory environments best, so before acting on this advice, organizations will want to ensure that there in fact are no Active Directory integrated applications or business use-cases that leverage this default modify access granted to domain users on their accounts. This advice is provided on a best-efforts basis and your use of it is subject to our Terms of Use.

That's literally all there is to it, and that is literally how easy it is to solve this inane problem!

One Caveat

There is ONE caveat that could possibly still enable a perpetrator to still try and leverage the limited write-property access that might remain even after you remove each one of those explicit ACEs that grant SELF modify access to those property sets.

Here's the caveat - at the domain root, there is an inheritable permission specified that is inherited by all objects, including all user objects, and it grants SELF the ability to read and write the Private Information property set -  { Allow   SELF   Special }

Members of the Private Information property-set include* - 

1. ms-PKI-Credential-Roaming-Tokens
2. MS-PKI-RoamingTimeStamp
3. MS-PKI-DPAPIMasterKeys
4. MS-PKI-AccountCredentials

* This property-set has the above four members in Windows Server 2008 R2 and beyond.

As a result, theoretically speaking, a perpetrator could possibly try to use these attributes to achieve the same mal-effect.

However, in practice, should the system be using these attributes, then any values that the perpetrator might write into these attributes will likely get overwritten by whatever the system writes into them, thus in practice rendering that option infeasible.

Of course, if you know for a fact that these attributes are not being used in your environment, then you can simply remove this ACE from the domain root, which will then have the effect of it being removed from all domain user accounts as well.

Disclaimer: Organizations know their unique Active Directory environments best, so before acting on this advice, organizations will want to ensure that there in fact are no Active Directory integrated applications or business use-cases that leverage this default modify access granted to domain users on their accounts. This advice is provided on a best-efforts basis and your use of it is subject to our Terms of Use.

An Advanced Tip

Those who know the subject well know that even if each one of these ACEs no longer exist, a user could still possibly have sufficient effective permissions so as to be able to modify one or more attributes on the domain user account, should there be other permissions in the ACL of the account that might effectively grant the user sufficient effective access so as to be able to do so. The only way to correctly find out whether or not a user can in fact still modify attributes on his/her domain user account is by accurately determining Active Directory effective permissions on that domain user account.

Gold Finger Active Directory Effective Permissions Calculator

For instance, in the snapshot above, one can see that on the domain user account of a user, Jeff Bezos, the user Jeff Bezos still has write-property effective permissions to the Phone-Ip-Other attribute (which is a member of the Personal Information property-set), and he has this access on his own account not by virtue of those SELF ACEs but in fact by virtue of the fact that there exists an ACE that grants the IT Cloud DevOps Team domain security group, of which he is a member, Write-Property information to the Personal Information property set.

The likelihood of this is low, yet in the interest of completeness, since it is always a possibility, I felt the need to mention this, and security conscious organizations will want to take Active Directory Effective Permissions into account for completeness.





Summary

Today, I just wanted to take a few minutes to share with you just how easily organizations worldwide can solve this supposedly difficult problem of Active Directory Botnets! Of all the problems I've helped solve this year, this one was by far the easiest.

The short of it is that this inane issue can be mitigated within minutes by simply using basic scripting to remove the very ACEs that grant domain user accounts the ability to modify the attributes that this attack vector leverages. It really is as simple as that!

I apologize if this post was short and to the point. I usually spend a lot more time on my posts, but its almost the end of the year, and my time is very valuable, so I decided to keep it short. Besides this is so easy, that it only needed minutes to address.

Best wishes,
Sanjay