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

Some Love For Microsoft + Time to Help Microsoft (and the Entire World)

Folks,

This is a Trillion $ post. I wanted to show some love for Microsoft and help them out, as it appears they could use some help.

BTW, for those wondering who I am to make such a statement, I'm a nobody who knows a thing about a thing that impacts WD.




Trillion $ Background

From the White House to the Fortune 1000, Microsoft Active Directory is the very foundation of cyber security at over 85% of organizations worldwide. In fact, it is also the foundation of cyber security of almost every cyber security company worldwide.

Active Directory is the Foundation of Cyber Security Worldwide

The compromise of an organization's foundational Active Directory deployment could have disastrous consequences for the organization and its stakeholders, and the real extent of damage would be a function of the perpetrators' proficiency and intent.

If you understand the inner workings of Active Directory based networks, then you know that the amount of damage that we've seen in recent breaches such as the Equifax breach, is nothing, compared to the amount of damage that can actually be done.



Thus far, perpetrators have been focused on simple attack vectors such as credential-theft attacks aimed at the compromise of an organization's privileged users (e.g. Domain Admins), and over time Microsoft has made their enactment much harder.

As these attack vectors become harder to enact, perpetrators have started focusing on increasing their knowledge about Active Directory, and exploring ways to try and target and compromise Active Directory itself, as evidenced by the fact that in the last year alone, we've seen the introduction of Mimikatz DCSync, BloodHound and recently the advent of Active Directory Botnets.

Today Active Directory security, and in particular Active Directory access control lists (ACLs) impact organizational security and national security, worldwide. Speaking of which, and just so the world knows, here is Microsoft's take on them, and here is ours.

Perpetrators seem to be learning fast, and building rapidly, so the next big wave of cyber breaches could involve compromise of Active Directory deployments, unless organizations act swiftly to lock-down their foundational Active Directory deployments.

To do so, organizations worldwide need the right insight, guidance and tooling to adequately lock-down their Active Directory deployments. Unfortunately, Microsoft doesn't seem to know much about it (proof: 1, 2, 3, 4), and thus may be unable to help.




Some Love for Microsoft

Today I may be the CEO of Paramount Defenses, but I'm also former Microsoft Program Manager for Active Directory Security, and I for one deeply love Microsoft, and deeply care about the foundational cyber security of all organizations worldwide, so I'm going to help Microsoft and the entire world adequately secure and defend their foundational Active Directory deployments.

To Satya (Nadella) and my former colleagues at Microsoft I say - "Microsoft is one of the greatest companies in the world today, and we care deeply and passionately about not only the role we play in society and the impact we have on billions of people, but also the responsibility that goes along, so we're* going to help the world address this colossal cyber security challenge."

* I may no longer be a Microsoft employee, but I still do care deeply and equally, so I'm happy to help you.
  If I were you, I'd most respectfully embrace this opportunity, be thankful for it, and not squander it.

To my friends at Microsoft, if I may have recently been a tad critical of you, its only because I care deeply about our customers, and I know that Microsoft can do much better at educating its global customer base about a matter of paramount importance.





Er, What Cyber Security Challenge?

Now, there might be billions of people and thousands of organizations worldwide who may have absolutely no idea about what I'm talking about, so perhaps I should succinctly and unequivocally spell it out not just for the entire world, but also for Microsoft.

Stated simply, and as described in The Paramount Brief, here's the #1 cyber security challenge that impacts the world today -

"From Silicon Valley to New York and London to Sydney, at the very foundation of cyber security and IT of 85+% of all business and government organizations across 190+ countries worldwide lies Microsoft's Active Directory.

Within the foundational Active Directory domains of these organization lie the entirety of their building blocks of their cyber security i.e. their user accounts, computer accounts, security groups, security policies etc. each one of which is represented by an Active Directory object & protected by an Active Directory Access Control List (ACL).

Today, in most of these organizations, there exist millions of ACLs in their Active Directory, and within these ACLs exists an ocean of excessive/unauthorized access, that today paves thousands of privilege escalation paths to literally the entirety of all objects in these Active Directory deployments, including to all their privileged users.

This ocean of unauthorized access exists worldwide today because Active Directory lacks and has always lacked the essential ability to help organizations correctly and adequately audit effective access in Active Directory, and consequently even though organizations have been delegating/provisioning all kinds of access in Active Directory to fulfill various business needs, they've never had the opportunity to correctly audit this ocean of access, resulting in a situation caused over time (i.e. over the years) wherein today unauthorized access pervades Active Directory.

In short, today, at most organizations, no one knows exactly who has what access on any of their building blocks of security, and possibly an excessive number of users, computers and service accounts may have substantial unauthorized access on them, and thus be in a position to easily and instantly compromise their security.

• A Trillion $ Note: Most organizations (and perpetrators, as well as the Bloodhound Tool) audit "Who has what permissions in Active Directory?" Unfortunately, that does not provide the accurate picture. What they need to audit is "Who has what effective permissions/access in Active Directory?" Sadly, Microsoft has NEVER provided this guidance in an entire decade, so no one even seems to know this.

Anyone who possesses the tooling to correctly analyze effective access in Active Directory could instantly identify, and either eliminate or exploit, all such unauthorized access grants and the 1000s of privilege escalation paths they pave, and thus be in a position to either formidably defend or completely compromise these organizations.

The potential impact of this huge cyber security challenge is best illustrated by these 7 examples. Its that simple."

As simple as it is, not a single one* of the 1000+ cyber security companies that exist today has a solution for this challenge.


Let there be no mistake about this - a proficient intruder who possesses tooling that lets him/her correctly analyze effective permissions/access in Active Directory, could easily find, hundreds if not thousands, of unauthorized access grants in most Active Directory domains, and exploit them to compromise and obtain complete command and control over the organization.

If you find this hard to believe, you don't have to take my word for it, as here is Microsoft finally acknowledging it, and doing their best to downplay it. By the way, if they truly understood the depth of this problem, what they should've actually said is here.

Unfortunately, perpetrators can develop their own tooling and they don't even have to be 100% accurate (e.g. Bloodhound.)

Fortunately, organizations that possess the right tooling (e.g. 1, 2) can reliably mitigate all such security risks to Active Directory, from Mimikatz DCSync to Active Directory Privilege Escalation and from Sneaky Persistence to Active Directory Botnets, before perpetrators have the opportunity to exploit them, leaving no unauthorized access in Active Directory for perpetrators to exploit.





Time to Help Microsoft (and the Entire World)

Over the next few days, not only am I going to help reduce the almost total lack of awareness, education and understanding that exists at organizations today concerning Active Directory Security, I am also going to help organizations worldwide learn just how they can adequately and swiftly address this massive cyber security challenge before it becomes a huge problem.

Of course, today we can also uniquely empower organizations worldwide to adequately secure and defend their foundational Active Directory deployments, and we are happy to help organizations that request our help, but we are not going to go to anyone explicitly offering our help, because we're not your ordinary company.


So, in days to come, we'll begin by educating the world about the following -

1. What Constitutes a Privileged User in Active Directory


2. How to Correctly Audit Privileged Users/Access in Active Directory


3. How to Render Mimikatz DCSync Useless in an Active Directory Environment


4. How to Easily Identify and Thwart Sneaky Persistence in Active Directory


5. How to Easily Solve The Difficult Problem of Active Directory Botnets


6. Why the World's Top Active Directory Permissions Analysis Tools Are Mostly Useless


7. Why is the Need to Lockdown Access Privileges in Active Directory Paramount to its Defense?


8. How to Attain (Lockdown) and Maintain Least Privileged Access (LPA) in Active Directory


9. How to Securely Delegate and Correctly Audit Administrative Access in Active Directory


10. How to Easily Secure Active Directory and Operate a Bulletproof Active Directory Deployment

You see, each one of these Active Directory security focused objectives can actually be easily accomplished today, but and in order to do so, what is required is the ability to be able to accurately and adequately audit effective access in Active Directory.

Each one of these topics is absolutely essential for organizational cyber security worldwide, and if you know of even one other entity (e.g. individual/company) on the planet that can help the world address each one of these objectives today, let me know.

So, within the next 7 days, as a part of this, I'll start penning the above, and you'll be able to read them right here.

In Summary

If you truly understand Active Directory Security, then you know that literally the entire world's wealth is being protected by it, so and thus we just cannot afford for organizations to start having their foundational Active Directory deployments being breached.

Together, we can help adequately secure and defend organizations worldwide and deny perpetrators the opportunities and avenues they seek to compromise our foundational Active Directory deployments, because we must and because we can.


Best wishes,
Sanjay

CEO, Paramount Defenses

Formerly, Program Manager,
Active Directory Security,
Microsoft Corporation


PS: To anyone who believes they know more about Active Directory Security than us, or can help the world more than we can, go ahead and demonstrate that you can - this is your opportunity. If you can, let's see it. If you can't, you'll want to listen to us.

PS2: If you liked this post, you may also like the 20+ posts that are a part of - Helping Microsoft with Active Directory Security.