I recently covered the topic of Active Directory permissions by giving an overview on how to apply them and view what already exists in your organization. In this blog, I’ll be taking a deeper dive into Active Directory permissions, outlining potential risks that exist when certain permissions are applied to certain objects.
So how do Active Directory permissions actually create risk in your environment? The first thing to understand, which can’t be understated, is that AD permissions can be very complex. Effective access based on group membership and nested group membership isn’t always super easy to untangle at face value. In large, complex environments, untangling all these permissions is no small task. Beyond understanding exactly who has access to what in your AD infrastructure, you have to understand what those permissions are actually granting someone access to do.
Being able to modify an object’s description is a potentially harmless act that may have little to no impact on your environment, but on the other hand, something like replicating the domain is a much more privileged action to take. Understanding everywhere administrative type permissions are applied can help in understanding and mitigating risk, and I’ll have a list of some permissions to keep an eye on below. However, understanding who those administrative permissions are granted to isn’t necessarily all you need to pay attention to. You also need to know what those permissions are applied to and what level of access those objects have. This is where the term shadow access comes into play, for example, a help desk should have access to reset everyone’s password that they service, but should it have the capability to reset the password of an Azure Active Directory service account that can replicate the domain? If a user who works at the help desk, who is only responsible for resetting passwords and helping end-users get into their accounts, has access to reset the password of the Azure AD service account that can replicate the domain, that poses a significant risk to the organization. At least two things can happen:
So how is replicating the domain a potentially malicious activity and why should you be concerned with it? Well, it is actually the main permission required to perform a DCSync attack with a tool like mimikatz. That is why it is so important to not only understand what permissions a user has applied to them directly but what unintended permissions they may have access to by leveraging their own permissions to move laterally or escalate. From a penetration testing standpoint both the blue team and red team should be attempting to unravel and abuse these permissions to see how they can gain unintended access to further the security of their organization’s Active Directory.
Below is a list of some Active Directory permissions that are easy to take note of and understand where and who they are applied to in an organization. This is not an all-encompassing list and there are always new ways that could become prevalent in a malicious actor’s arsenal to abuse. I’ll quickly touch upon why each of the permissions below can be considered a risk.
The example I provided above hopefully outlined why being able to reset passwords is a risk, but the idea is that if a user has the capability to reset another user’s password, they can compromise that account. Once they compromise that account, they can further their access to include the resources and objects that the account they can reset the password of has. This is an important way that an attacker or malicious actor can escalate their privileges or move laterally throughout an organization.
Very similar to resetting a password, if a user can modify the membership of a group, they can add themselves or an account they also have access to, to the group. Once they’re added to the group, they then will have access to all of the permissions and resources that the group has access to. Imagine a user can add themselves to a group that has access to a share that contains sensitive customer content. If you’re looking at and reporting on access to sensitive resources, are you also determining who could gain access by leveraging Active Directory permissions?
I covered this one briefly above, but being able to replicate the domain is the precursor to a DCSync attack. A DCSync attack will allow an attacker to gain access to password hashes from the environment that will allow them to leverage a Pass-the-Hash attack and escalate or move laterally however they see fit. Beyond that, it also can enable an attacker to pull all of the password hashes offline to attempt to crack them and get their cleartext counterparts.
The AdminSDHolder container is an important container in Active Directory, it is used in a process called SDProp which controls the ACLs of sensitive objects in Active Directory (ones that have the admincount attribute set to 1). Every 60 minutes SDProp will force the ACL on protected objects to be identical to the ACL on AdminSDHolder. So, what does this mean and why is it a risk? Well, if a malicious actor is able to apply a change to the AdminSDHolder container ACL, such as granting a specific user full control, every 60 minutes that permissions will get put on your protected groups such as Domain Admins. This creates persistence in your environment for the attacker, even if you were to identify the misconfigured permission on the Domain Admin group and remove it, it would reappear in 60 minutes unless you identified that it was applied to the AdminSDHolder container.
The last Active Directory permission I want to cover is access to the Servers container. A DCShadow attack requires promoting a computer to a domain controller, which involves adding them to the Servers container. If a user can perform a DCShadow attack in your environment, they can push any change to your domain via a rogue domain controller.
Some other things to consider, that aren’t directly related to Active Directory permissions, are some of the permissions and rights that exist throughout your environment that can be leveraged after one of these Active Directory permissions are abused. A few of those permissions and rights are Local Administrators on Windows servers, database access, and share and file server resource access. If a user is a local administrator on a machine, they’re a target for lateral movement and privilege escalation because they’re capable of scraping a hash out of memory on a Windows server. That hash can then be used to attempt to move laterally or escalate even further. Similarly, having access to databases or shared resources, sometimes being sensitive, can make for an appetizing target for compromise.
So how can you manage these risks and what can you be doing to limit the attack surface that a malicious actor could leverage to gain access to your environment? The biggest thing would be to first understand your own environment. You’ll want to get a grasp on what permissions exist and begin to unravel if those permissions are necessary. Beyond actually understanding what’s already at play, looking to monitor and alert on high-risk changes in your environment can aid in you getting ahead of an unintended change. Lastly, you can look to implement a model like Zero Standing Privilege (ZSP), limiting the potential attack surface of an attacker exponentially.
Something that you can do almost immediately as I mentioned above, is to understand what is already at play in your environment. Unravel the permissions that already are applied and start to digest that data. StealthAUDIT Active Directory Permissions Analyzer allows you to easily identify who has been granted the permissions I mentioned above. Below is an example report that helps you identify all users that been granted reset password permissions in the environment.
Beyond just showing what is applied to users directly or through group membership, the tool also allows you to easily identify shadow administrators, which are accounts that can leverage their Active Directory permissions to quickly gain access to other objects allowing them to laterally move or escalate their privileges. Check out this quick video on shadow access to learn more!
Kevin Joyce is a Senior Technical Product Manager at Stealthbits – now part of Netwrix. He is responsible for building and delivering on the roadmap of Stealthbits products and solutions.
Kevin is passionate about cyber-security and holds a Bachelor of Science degree in Digital Forensics from Bloomsburg University of Pennsylvania.
Learn why Active Directory security should be a priority for your organization and ways to mitigate against a data breach with this free white paper!Read more
Start a Free Stealthbits Trial!
No risk. No obligation.