It lets perpetrators compromise domain user accounts, domain computer accounts, security groups and other Active Directory content, including all privileged users and groups in Active Directory.
The compromise of a single Active Directory privileged user or group is sufficient to obtain complete command and control over the entire Active Directory and is tantamount to complete compromise.
Active Directory Privilege Escalation is made possible due to the presence of unauthorized
effective permissions that result from the security permissions provisioned on Active Directory objects.
The Keys to Correctly Identifying Privilege Escalation Paths in Active Directory
The keys to correctly (accurately) identifying privilege escalation paths in Active Directory lie in correctly assessing cumulative
access entitlements in Active Directory, and the keys to correctly assessing cumulative access entitlements in Active Directory lie in being able to accurately calculate
effective permissions in Active Directory.
Saliently, there are specific administrative tasks/operations that can be enacted on Active Directory objects, such as domain user accounts, domain computer accounts, domain security groups etc., wherein the enactment of such tasks gives the security principal that is able to enact such a task on a target, the ability to own (/compromise) that target, and any security principal that can perform these tasks on their various targets can in effect escalate their privilege to the specific target.
The following are examples of such administrative tasks/operations -
- Resetting the password of a domain user account
- Resetting the password of a domain computer account
- Changing the membership of a domain security group
- Adding or removing Self as a member to a domain security group
- Modifying the permissions of an Active Directory domain account, group or any object
- Changing the ownership of an Active Directory domain account, group or any object
Thus, any security principal that can enact the aforementioned tasks on an Active Directory object can in effect escalate their privilege on to that Active Directory object.
Consequently, to correctly identify privilege escalation paths in Active Directory, one needs to be able to accurately determine/identify exactly who can enact all such tasks in and across Active Directory, AND to be able to do that, one needs to be able to accurately determine effective permissions on objects in Active Directory.
It thus follows that the keys to being able correctly identify privilege escalation paths lie in being able to accurately assess cumulative access entitlements in Active Directory, which in turn involves accurately determining effective permissions in and across Active Directory.
You can learn more about what
Active Directory Effective Permissions are
here and
here. They are absolutely fundamental to Active Directory Security and in all native Microsoft tooling, there are referred to as
Effective Access.
A Real-World Example
This topic is perhaps best understood with a real-world example, so let us consider the following -
Objective - Identify all privilege escalation paths leading to the CEO's domain user account.
Setup - A real-world organization's Active Directory, comprised of multiple domains, with say twenty thousand domain user accounts, twenty thousand domain computer accounts, ten thousand domain security groups, and MILLIONS of security permissions in Active Directory, including hundreds of thousands (due to inheritance) of Deny permissions.
Side-Note for Amateurs - We are not talking about trying to find privilege escalation paths on an Active Directory object based on a mere three permissions in the ACL, of which none is a Deny permission, in some novice/junior sys-admin's home lab setup.
Possibilities - Technically, the possibilities here are wide ranging. At best, in a highly secure environment, there might at most be a handful of Domain Admin equivalent accounts that can enact ops that could take-over the CEO's account, and the same set of individuals who could also do the same on each other's accounts (due to AdminSDHolder.) At worst, you could have a situation wherein a single mis-configured permission could grant Authenticated Users or Everyone modify access on the CEO's account, and now you're looking at a situation wherein forty thousand (plus one) accounts have a direct privilege escalation path to the CEO's account alone, and scores of accounts with both unrestricted and restricted (delegated) admin access in Active Directory, have several privilege escalation paths on to each one of these forty thousand accounts. That's the spectrum of possibilities we're talking about here, to be predominantly viewed from the perspective of trying to automate this identification process.
Side-note 2 for Amateurs - This is a production environment, wherein organizational IT/cyber security personnel have actually put in the effort to lockdown access in their Active Directory, including by employing Deny permissions, so you don't have a setup where there are no Deny permissions. Also, in each ACL, there could be multiple Deny permissions, explicit and inherited, denying access for some of the very groups that have also been allowed access to the same object in the same ACL. In other words, there's considerable real-world complexity to deal with, unlike in a simple lab setup.
Specifics and Size - You can assume that over the years, a fair amount of administrative delegation has been done in this Active Directory. For instance, responsibilities for identity management, helpdesk functions and access for AD-integrated apps are all adequately provisioned via scores of inheritable permissions across the domain, in every domain. You can also assume that at least basic common-sense barriers have been put in place via Deny permissions, so you're looking at millions of security permissions in the Active Directory, including say 76 security permissions just in the ACL of the CEO's domain user account.
Innards
With the above setup in place, the process of identifying privilege escalation paths to the CEO's domain user account begins by examining the ACL of the CEO's domain user account.
As mentioned above, there are 76 security permissions in this ACL, of which 60 are of type Allow and 16 are of type Deny, and of which, 24 are explicit in nature and 52 have been inherited.
They include several conflicting permissions. For example, the Help Desk Team group has been granted the Reset Password extended right via an inheritable Allow permission. This Help Desk Team group contains two nested groups, one of which, the IT Help Desk (Contractors) group, represents contractors. This group IT Help Desk (Contractors) is a member of the IT All Contractors group, which in turn is a member of the All Contractors group, and there is an inheritable Deny permission in the CEO's account's ACL denying the All Contractors group All Extended Rights. This is merely one example. There are many such conflicting permissions in the CEO's account's ACL.
The reason this simple example is so pertinent and important to consider is that whilst virtually all other tools that claim to analyze Active Directory security, and/or identify privilege escalation paths, will take into account the Allow permissions granting the Help Desk Team the Reset Password extended right, none of them will evaluate or consider the impact of the Deny permission granted to the All Contractors group, which as seen above, due to an indirect (nested) group membership, will not actually permit any contractor who is a member of the IT Help Desk Team (via the nested IT Help Desk (Contractors) group) to actually be able to reset the CEO's account's password.
In essence, the very first step in this process is to take into account the collective impact of all the security permissions (i.e. both Allow and Deny permissions) specified in the ACL protecting the target object to identify which security principals do in fact have sufficient effective access to actually be able to enact technical/administrative operations on this account and escalate privilege.
This simple yet paramount determination is what is known as calculating
Active Directory Effective Permissions i.e. calculating the actual resultant access that is allowed on an Active Directory object.
Consequently, the very first step involves being able to accurately calculate effective permissions on the CEO's domain user account, and this in itself is no easy feat. In fact, it is one of the most difficult challenges in all of Active Directory security and organizational cyber security, even though it is absolutely fundamental and paramount to the security of every single object in Active Directory.
Thus, the very first step is to determine who actually has sufficient effective permissions on the CEO's domain user account to be able to enact admin tasks/ops that can be used to escalate privilege on to this account, and this being a domain user account, those tasks are as follows -
- Reset the domain user account's password
- Change the security permission on the domain user account
- Change the ownership of the domain user account
The first task is the primary avenue to escalating privilege on to a domain user account. The second task gives you the ability to grant oneself (or anyone) sufficient effective access to be able to enact the first task. The third task, gives you the ability to acquire ownership of the object, which in turn, gives you implicit Write DACL i.e. Modify Permissions on the object, which then can be used to grant oneself (or anyone) sufficient effective access to be able to enact the first task on the account.
Side-note - The list of admin tasks/operations that can be enacted to escalate privilege onto an Active Directory object are specific to the class of the object. For instance, on a domain security group, in lieu of #1 above, the two tasks would be 1) Change the membership of the group, and 2) Add/remove oneself as a member to the group. Similarly, akin to the above, tasks # 3 and #4 in the case of a security group would be Change the security permission on the domain security group and Change the ownership of the security group.
Thus,
the very first thing that
Gold Finger does in the process of determining privilege escalation paths is correctly calculate Active Directory Effective Permissions on the target of the determination, to determine who can enact tasks/operations that can be used to escalate privilege to the target.
Side-note - To reiterate, that is merely the very first step in this vital determination, and there is not a tool in the world that can accomplish even this very first step accurately, so as you can imagine, any tool that claims to be able to identify privilege escalation paths in Active Directory is in actuality simply not even able to complete the very first step accurately.
Now, let us assume that having accurately determined effective permissions on the target object, we have determined that a total of 56 security principals, including 30 domain user accounts, 4 domain computer accounts, 21 domain security groups and 1 foreign security principal (FSP, e.g. Anonymous Logon) are actually able to escalate privilege to the CEO's domain user account.
The next step in the process is to then proceed to accurately calculate effective permissions on each one of these 55 security principals and identify exactly who can escalate privilege on to each one of them, considering the privilege escalation tasks/operations that are specific to their class.
Side-note - Even though we have a total of 56 security principals that can escalate their privilege on to the CEO's domain user account, one of them is the FSP Anonymous Logon. We do not need to identify any escalation paths on to this FSP, because there are none to identify, in that one does not need any credentials to come across as Anonymous Logon.
To reiterate, having determined the identities of all security principals that have a direct privilege escalation path on to the target, the next step is to iteratively recurse this exact process on each* one of these security principals.
In essence, this elemental process, primarily involving the
fundamental accurate determination of effective permissions on numerous Active Directory objects to identify which enactable privilege escalation admin tasks/operations are entitled, to whom and how, needs to be recursed on each one of them
until such point that there are no more security principals that have a privilege escalation path to the target under consideration, i.e. other than those that have already been identified as having a path to the target, or on/to whom we have already identified privilege escalation paths. It is at that point that the intricate process of accurately identifying privilege escalation paths to a specific object in Active Directory is considered
complete.
At this point, what one has is an inverted privilege escalation path tree, wherein the root node is the target of the escalation, and every child node is a security principal that has one or more escalation paths to the parent node, and each edge in the tree represents one or more escalation paths representing the operations/tasks involved in the escalation(s), and there certainly can be more than one escalation path leading from one security principal to another.
Example - A user account, say John Smith, could have both sufficient Add/Remove Self as Member effective permissions as well as sufficient Modify Permissions effective permissions on a domain security group. In this case, there are two privilege escalation paths leading from John's account to this security group, so the edge would represent both these escalation paths, and be duly annotated as such.
Summary
In closing, based on what we have considered above, there could theoretically be anywhere from zero to thousands of privilege escalation paths leading to a specified target in Active Directory, and the only way to accurately identify them involves accurately determining access entitlements on possibly thousands of objects in Active Directory (, which involves accurately calculating effective permissions on thousands of Active Directory objects and mapping them to admin tasks/ops that can be used to escalate privilege,) and then taking this vast amount of accurately assessed access entitlement data and precisely generating a privilege escalation path tree.
Our unique Active Directory Privilege Escalation Path Identifier is the
only tooling the world that can
accurately identify such paths, based on the accurate determination of
effective permissions on as many Active Directory objects as may be involved, whether it be one or it be fifty thousand objects.
In Closing
That is what it takes to accurately determine privilege escalation paths in Active Directory.
To then attempt to build an automated solution that can completely automate this entire process, with 100% accuracy, and no room for error, one that can be used/deployed in any production Active Directory deployment in the world, no matter how simple or complex it may be, is then undoubtedly, an extremely difficult undertaking.
It requires the discipline of a United States Marine and the expertise and precision of a proficient and experienced heart surgeon to conquer such a massive, complexity-laden technical challenge.
We are pleased to have made it as easy as touching a button in any Active Directory in the world.
Consequently, today, any organization that wishes to do so, can instantly and accurately identify and eliminate all privilege escalation paths in their foundational Active Directory, and subsequently maintain a secure foundational Active Directory deployment, which is the bedrock of their business.
You can watch a demo of this unique tool
here. At the touch of a single button,
Gold Finger performs hundreds of thousands of operations under the hood to accurately determine exactly who has what privilege escalation paths to a specified target, and how, thereby finally empowering organizations to easily identify and eliminate all privilege escalation paths in Active Directory.
It is only a million miles ahead of any other tooling in the world that claims to be able to identify privilege escalation paths in Active Directory, and it is the only one that can do so accurately.
A simple litmus test that can prove how accurate any such tooling is, can be found
here.
I shouldn't have to say a word more, so I won't.
Thanks,
Sanjay
PS: Pardon the delay - We have been meaning to pen this post for several weeks now, but have been extremely busy, apart from our immense responsibilities to our customers across the world, completing the development of one more high-impact product, to be unveiled in just a few weeks.