This guest blog was contributed by Justin Kohler, Director of BloodHound Enterprise at SpecterOps.
Microsoft Active Directory (AD) is by far the most widely used directory service product. Retailers, banks, military and government agencies, small businesses, and the vast majority of the Fortune 500 use AD as the identity backbone facilitating user access to data throughout the organization. Unfortunately, these same chains of permissions linking users and computers can also be abused by attackers who use them to form Attack Paths to move laterally, steal sensitive data, or launch malware attacks. They’re present in virtually all business networks and have frustrated defenders for decades (whether they’ve known it or not).
We’ve studied Attack Paths in detail over the last several years (our team created BloodHound, a free and open-source tool for mapping Attack Paths). When consulting with organizations to help them manage their Attack Paths, we often run into some form of the same question: "Is it this bad for everyone?"
The answer is always the same: “Yes, it’s this bad for everyone.”
By "this bad," folks are typically referring to the number or severity of the Attack Paths that we're able to uncover. A “small” organization with around 1,000 endpoints will typically have millions, if not billions of Attack Paths.
Why? First, auditing privilege in AD is nearly impossible. Second, a lack of visibility from native and third-party tooling has contributed to more than two decades of misconfiguration debt.
Mission (Nearly) Impossible: Auditing Privilege in AD
If you ask any Active Directory administrator how easy they think it is to see where privileges are applied in the environment, they’ll say it’s nearly impossible. An easy example of this is attempting to determine which users have local administrator rights on a workstation or server. The built-in tooling only shows which principals are direct members of the local administrators group. This tooling may indicate that “Helpdesk” has local administrator rights but it doesn’t show that the “Helpdesk” group has five other groups nested within it, all containing hundreds of users. An administrator would need to navigate to each of these groups individually within a separate tool (Active Directory Users and Computers or “ADUC”) to fully understand the true count and identity of those with local administrator rights on this example system. This simple example of lack of visibility and extreme tedium repeats itself through AD and makes it almost impossible for teams to get an accurate picture of who has abusable access to crucial systems.
In one extreme case, a colleague of mine discovered an environment where AD showed 31 security principals added to its local admins group, but thanks to nested security groups, the total number of users that had admin rights was actually 733,415.
AD admins aren’t at fault here – the fact that they are able to keep such a fundamental system running with the limitations they’re working under is honestly pretty incredible! The opaque nature of how privileges are granted in AD makes managing Attack Paths too difficult for even the most talented administrators. All the AD admins I’ve spoken to care about keeping their system secure, but the deck is just too stacked against them for them to make meaningful progress. Therefore, these flaws and security risks in AD build up unnoticed over time.
A Tale of (More Than) Two Decades: Misconfiguration Debt
Active Directory and system administrators can easily make mistakes or misconfigurations that create Attack Paths. As we’ve established, AD itself gives admins very little visibility into user permissions, making it nearly impossible to spot these misconfigurations once they’ve been created. Inevitably, misconfiguration debt will accumulate over time. Given the fact that Microsoft released AD in 1999, it’s staggering to think about how much time these issues have had to fester.
Tribal knowledge is also an issue. On average, AD administrators serve in their roles for two to five years before either changing roles, transitioning into management, or moving on to other companies. This means that if an AD environment is 10 years old, which is relatively young, it’s very possible that there have been four or five different admin teams over that time. Does the current team understand all those past admins’ decisions? Is a certain problematic configuration an intentional decision or a mistake, and if we change it, will anything break? These questions make it very hard to do anything about misconfiguration debt.
Although updates have been made over the past two decades and change, AD is still essentially built on the same underlying functionality. While this does speak to the incredible resilience of these systems, the fact that AD still has immense room for improvement (more specifically, visibility) simply isn’t a debate at present.
Finally, Some Good News
So, do we just throw up our hands in the face of this overwhelming problem that’s bad for everyone? Of course not. There are many things AD admins can do to help make their environments more secure. Shining a light on a problem that’s been hiding in the dark for more than two decades has enabled us to recognize that security teams need capabilities to map and prioritize attack paths in order to even attempt to take corrective action. Understanding nested security groups and getting better visibility into AD are a couple of the most important steps.
Using third-party tools or scripts (like FOSS BloodHound and others) to get more insight into which users have which permissions and tracking nested security groups is a great starting point to better AD security. While it may be this bad today, we now have the capability to understand and remove AD as the adversary’s favorite target.
###