Ladies and Gentlemen,
Two months ago, we announced the availability of Gold Finger 10.0 for Microsoft Active Directory, featuring the world's first and only accurate Active Directory Privilege Escalation Path Identifier -
 |
We developed this unique tool to empower organizations worldwide to be able to trustworthily (accurately) identify and eliminate privilege escalation paths in their foundational Active Directory environments, enabling them to eliminate the #1 threat to organizational cyber security.
Today, I will be sharing additional technical details on this paramount cyber security tool, which is the world's only tooling that can accurately identify privilege escalation paths in Active Directory.
(We trust the world understands the meaning of the English word - "only".)
Everest Beckons - Accurate Active Directory Privilege Escalation Path Identification
The cardinal tenet in the identification of privilege escalation paths in Active Directory is accuracy.
The only way to achieve accuracy in escalation path identification involves identifying privilege escalation paths based on an accurate assessment of access entitlements in Active Directory, which in turn involves and requires the determination of effective permissions in Active Directory.
Specifically, in order to be able to accurately identify privilege escalation paths in Active Directory, one first needs to accurately determine access entitlements on possibly thousands of objects in Active Directory, which involves accurately determining effective permissions on thousands of objects in Active Directory, and that is extremely difficult to accomplish, let alone automate.
As such, we are the only company in the world that actually has a solution that can accurately determine effective permissions in Active Directory. We are also the only company in the world that can accurately determine effective permissions on thousands of objects in Active Directory and determine exactly who has what privileged access, where and how in Active Directory. Even then, being further able to identify privilege escalation paths based on all assessed access entitlements in Active Directory is no easy feat.
For years now, even we had not attempted it because we knew just how difficult it is to accomplish, let alone automate it, considering how diverse Active Directory environments can actually be.
You see, when you build an automated solution, it needs to be able to work in every possible environment, ranging from a small business' 100 user account single-domain environment to an enterprise's 100,000 user account multi-domain environment spread across multiple continents.
Consequently, for years now, organizations had been using and relying on a particular amateur cyber security solution, that albeit substantially and dangerously inaccurate, seemed to have become the de-facto standard to identify privilege escalation paths in Active Directory.
In October of 2024, it came to our attention that even official guidance from the global intelligence community was recommending the use of this amateur cyber security solution, and we realized that something had to be urgently done, lest even government and intelligence agencies worldwide end up operating on dangerously inaccurate cyber security insights, reliance upon which could result in their swift and colossal compromise, a situation that could endanger U.S. national security as well as the national security of all countries that were relying on such (inaccurate) guidance.
Everest Conquered - Building an Accurate AD Privilege Escalation Path Identifier
With the above concern in mind, we decided to take on our biggest challenge yet, (and one may want to keep in mind that over the years, we have taken on and solved some of the biggest challenges in organizational cyber security,) and set out to architect and develop the world's first and only accurate privilege escalation path identification tooling for Microsoft Active Directory.
It took our entire development team, led by myself, almost a year to architect and develop this tool, and it undoubtedly has been the single biggest technical challenge that we have taken on to date.
To appreciate the magnitude of this problem, you have to understand that what is involved here is building an automated solution that can not only accurately calculate effective permissions on thousands of objects, but then also take an ocean of determined resultant access entitlements, and determine (potentially hundreds of thousands) of privilege escalation paths leading to one or more targets in Active Directory, and do so with complete accuracy, in any Active Directory environment.
We also gave ourselves a difficult stretch goal of not just being able to accurately identify privilege escalation paths in Active Directory, but also, for each and every single identified path, be able to pinpoint the exact security permission in the ACL of the target Active Directory object, that was entitling a subject to a specific privilege escalation path.
None of this was easy. In fact, it was the most difficult technical challenge we have conquered (, which is also why you'll see a picture of a mountain climber in the Mission Accomplished section on this technical page,) and it was the equivalent of trying to scale Mount Everest in the real-world.
All said and done, we knew that failure was not an option (, and as such that word doesn't exist in our dictionary at Paramount Defenses,) and the entire team worked tirelessly, laser-focused on the mission, in dark rooms, completely cut off from the Internet, and by the end of November 2025, we had successfully built the world's only cyber security solution that can accurately identify privilege escalation paths in Active Directory, and also includes source-identification (, our stretch-goal).
We then spent well over a hundred days, thoroughly testing every aspect of the tooling, as we always do, and after a hundred days of thorough testing, we signed-off on the final release version, with March 10, 2026 decided as our release date, almost coinciding with our twentieth anniversary.
On March 10, 2026, we released the world's first and only accurate privilege escalation path identification solution for Microsoft Active Directory, so that thousands of organizations worldwide, including thousands of $ Billion business organizations, and thousands of government and national security/intelligence agencies across a hundred countries, could finally trustworthily (i.e. accurately) identify and eliminate privilege escalation paths in their foundational Active Directory deployments.
If you can find a more important cyber security problem to solve than this one, do let me know.
A Glimpse into the Technicalities Involved
The remainder of this post is focused on the technicals of this tooling, which may be of interest to experts in this field, and ideally should be understood by all IT personnel and CISOs in the field.
The field of Active Directory security is vast, and consequently, describing as well as understanding the technical innards of such a tool requires a certain level of subject matter expertise. That said, I'll do my best to describe the technical innards such that everyone in the field can get a sense of what is actually involved, and how difficult it is to accurately accomplish.
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.
Side-note - There is also only one tool in the world that can accurately calculate effective permissions in Active Directory, i.e. our Active Directory Effective Permissions Calculator.
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 other words, this elemental process, primarily involving the fundamental accurate determination of effective permissions on numerous Active Directory objects, 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 we have 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.
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 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.
That is what it takes to accurately determine privilege escalation paths in Active Directory, and that is what our Active Directory Privilege Escalation Path Identifier can uniquely do today.
In Closing
This unique capability too embodies industry-wide recognized innovative patented technology and our unique effective permissions calculation, privileged access assessment as well as privilege escalation path identification cyber security solutions for Active Directory remain unrivaled.
That's all for now. Thank you.
Sincerely,
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 product, to be unveiled when the time is right.
