Folks,
Hello. Today, we'll share with you what the CORRECT procedure is for finding out who can successfully execute Mimikatz DCSync against your Active Directory, particularly because so many IT professionals errantly believe that they know how to accurately make this determination.
As many know, Mimikatz DCSync is a hacking tool written by Benjamin Delpy that is often used by perpetrators to swiftly and substantially compromise organizations by letting them determine the passwords of all organizational AD accounts.
This is extremely important because DCSync is possibly the single biggest threat to all organizations operating on Active Directory, considering that even just a single successful enactment of DCSync instantly results in the compromise of the credentials of ALL domain user accounts, and thus, is in effect, tantamount to a colossal breach.
In fact, as recently shared by Microsoft Security, and I quote below, even LAPSUS$ i.e. DEV-0537 have been observed to use DCSync to substantially compromise several organizations, including most notably, Okta -
"The group compromised the servers running these applications to get the credentials of a privileged account or run in the context of the said account and dump credentials from there. The group used DCSync attacks and Mimikatz to perform privilege escalation routines. Once domain administrator access or its equivalent has been obtained, the group used the built-in ntdsutil utility to extract the AD database."
Now, it is very important to understand that LAPSUS$ were only able to successfully use DCSync because they were able to compromise an account that had sufficient ACCESS in their Active Directory domain so to be able to run DCSync.
In other words, if an account compromised by perpetrators does NOT have sufficient ACCESS to be able to successfully run DCSync, then the perpetrators will NOT actually be able to successfully run DCSync against Active Directory, so if we can correctly find out who has sufficient ACCESS to run DCSync against our Active Directory, we can lockdown all such exploitable access, minimizing the possibility of perpetrators being able to use DCSync against our Active Directory.
The ACCESS required to DCSync
From a technical standpoint, any user that has (i.e. is granted) sufficient privileged access in Active Directory to be able to replicate secrets from Active Directory can request Active Directory to provide it a copy of the entire domain contents, including all secrets i.e. password hashes of all domain accounts.
It logically follows that a perpetrator can only successfully use Mimikatz DCSync against an Active Directory domain if the compromised domain account that he/she is using has sufficient privileged access in Active Directory to be able to request and obtain secrets (i.e. password hashes) from Active Directory.
Speaking of which, the exact privileged access required to obtain (replicate) secrets from Active Directory involves two Active Directory extended rights, and an attacker requires BOTH of these permissions to be effectively granted -
- Replicating Directory Changes
- Replicating Directory Changes All
To be specific, to be able to successfully execute DCSync, an account needs to have both of these Active Directory extended rights be effectively granted in the ACL of the domain root object of an organization's Active Directory.
The Mistake 99% of IT Pros Make
Now, it is at this point that we must take a moment's pause and understand something extremely important.
The operative word in the previous sentence is "effectively" granted, and therein lies the answer to this question.
You see, most IT professionals errantly assume that all they need to do is find out "Who has these permissions in Active Directory" and to do so all they need to do is use any Active Directory ACL/Permissions Analysis tool, or write a few lines of PowerShell script to find out which users and groups are granted these permissions, and that's it!
Unfortunately, any IT professional that makes the above assumption is very likely going to end up with an inaccurate list of accounts that can run DCSync because what needs to be determined here is not "Who has these permissions in Active Directory" but in fact "Who has these effective permissions in Active Directory?"
In short, it is not "who has what permissions in Active Directory" but in fact "who has what effective permissions in Active Directory" that determines who actually has sufficient privileged access so as to be able to run Mimikatz DCSync!
Further, and as such, "effective permissions" not only determines who can actually run DCSync against Active Directory, it actually determines exactly who has what privileged access to do just about anything and everything in Active Directory.
This subtle yet profound difference can be very easy to get wrong, and yet is extremely important to understand, because it determines whether or not the results of one's analysis are accurate or not, and as you know, when it comes to privileged access, there is absolutely no room for error and accuracy is paramount.
Consequently, while it is relatively easy to find out "Who has these permissions in Active Directory" using PowerShell or any ACL/Permissions Analysis tool, it is extremely and far more difficult, if not almost impossible, to accurately find out "Who has these effective permissions in Active Directory" using PowerShell or such tools.
Effective Permissions
In this section, we will understand why it is not "Who has what permissions in Active Directory" that we need to determine, but in fact "Who has what effective permissions in Active Directory" that we need to determine if we care about accuracy.
In this section, we will understand why it is not "Who has what permissions in Active Directory" that we need to determine, but in fact "Who has what effective permissions in Active Directory" that we need to determine if we care about accuracy.
Once you have understood this, you will also understand why no AD ACL/Permissions Analysis tooling and/or any PowerShell script that one may have written, no matter how complicated, can actually provide accurate results.
Let us consider what we need to determine to make this paramount determination.
In essence, what we need to determine is in light of ALL the security permissions specified in the ACL protecting the domain root object, exactly who has BOTH the "Get Replication Changes" and "Get Replication Changes All" extended right effectively allowed.
By "effectively" what we mean is the following - consider that a user John Doe is a member of two groups, Group X and Group Y. Further consider that in the ACL of the domain root, the following permissions exist for Group X and Group Y -
Deny Group X All Extended Rights
Allow Group Y Full Control
Note - As you may know, each of the above is an ACE (access control entry) in an ACL (access control list), and each ACE either allows or denies either a generic or a a specific type of permission to a specific security principal.
Consequently, one might rightly assume that for starters we need to consider ALL ACEs in the ACL that specify either one of the following permissions - "Get Replication Changes" extended right, "Get Replication Changes All" extended right, All Extended Rights and Full Control.
Note: Some pros like to include the impact of being able to modify permissions on the ACL at this stage, but that is strictly speaking, an entirely separate entitlement/administrative task, which is why, strictly speaking, it need not be taken into account at this stage.
Now, based on the above, most PowerShell scripts would be programmed to find all permissions that grant either of the above four rights, and that is indeed the correct way to BEGIN to approach this analysis.
However, it is at this point that not only most PowerShell scripts, but also all AD ACL/Permissions analysis tools, and even tools like Bloodhound, meet their match and start falling substantially short.
Let me explain -
Based solely on an ACL that has the above two permissions, virtually all PowerShell scripts and tools like Bloodhound, will enumerate both permissions but make either of the two following errors -
- Error 1 - They will errantly assume that since there is an ACE specifying the specified access for two groups, members of both these groups have the required access, at which point they will proceed to expand these group memberships and report that all the members of both these groups can in fact replicate secrets, whereas nothing could be further from the truth!
- Error 2 - A more refined script looking merely for Allow permissions will partially rightly determine that only members of Group Y have the required access, at which point it will proceed to expand this group's membership and report that all its members can in fact replicate secrets, which too would unfortunately be inaccurate.
Here's why both of the above will lead to inaccurate results - you see, what such PowerShell scripts and tools like Bloodhound ACTUALLY need to be doing is determining that Group Y is allowed the required access -AND- Group X is denied the required access so they need to be identifying members of both these groups, then performing conflict resolution, which involves correctly identifying any and all individuals that may be members of both these groups, and eliminating those individuals that are on both lists, from the final list, since the deny permission will have precedence over the allow permission!
NOW, in theory, and especially when you are considering merely two ACEs, as we have above, being able to perform this conflict resolution may seem simple, BUT in practice and reality, the ACL of the domain root could easily have hundreds of ACEs/permissions, any theoretically each one of them could be in play, i.e. could influence such access, and be either allow or deny, so for any PowerShell script or a tool like Bloodhound to be able to deliver accurate results, it would have to have the automated ability to be able to accurately perform conflict resolution involving hundreds of ACEs (/permissions.)
Further, in the illustrative example shared above, John Doe was directly a member of these two groups.
In the real world, thousands of accounts could also indirectly, i.e. via nested group memberships, some of which may be deeply nested, and others may possibly also be circularly nested, be members of hundreds of domain security groups for which permissions may be specified in the domain root's ACL, and the PowerShell script or a tool like Bloodhound will need to have the ability to be able to process even such substantial complexity with 100% accuracy.
In addition, theoretically speaking, Active Directory security permissions could also be specified for one or more well-known RIDs as well as well-known security principals, such as Domain Users, Authenticated Users, Everyone, etc. and so PowerShell scripts and tools like Bloodhound will also need to be able to accurately evaluate the impact of all such permissions on the resulting access.
Also, there are several other factors that influence the accurate determination of "who has what privileged access in Active Directory" and I'm not going to list them all out there.
Finally, the ACL on the domain root object is an exception in that it is possibly the only object (, other than those that have protected ACLs,) wherein there are no inherited permissions to deal with. In reality, 99% of objects in Active Directory also inherit hundreds of security permissions, and it is exponentially difficult to be able to accurately do conflict resolution when inherited permissions are also in play, because one has to be able to accurately determine resulting access in light of the precedence order involving both explicit and inherited allow and deny permissions.
For anyone who wants to learn more, a more detailed explanation and example of just how difficult and complicated it is to accurately determine Active Directory Effective Permissions can be found here.
In short, it is extremely difficult, if not almost impossible, to write any amount of PowerShell that can take all of the above complexity into account and yet determine with 100% accuracy, exactly who has sufficient effective access so as to be able to enact a critical operation such as DCSync against Active Directory, or perform any one of over one hundred possible administrative tasks in Active Directory.
This is why it is almost impossible for any PowerShell script or a tool like Bloodhound to be able to accurately determine who can successfully execute DCSync against an organization's Active Directory.
An Actual, Step-by-Step Example
The best way to understand what I have shared above is for you to try it yourself in an Active Directory, and to facilitate exactly that, we have made available a real-world like lab AD of a fictional company in a free VM.
You can follow an entire step-by-step example of how to correctly identify who can run DCSync against Active Directory right here.
Your PowerShell Script is Woefully Inadequate
Once you've had an opportunity to understand the technical nuances I've shared above and follow the step-by-step example I've provided above, you'll know for yourself that it is extremely difficult, if not impossible, to find out exactly who can do what in Active Directory using PowerShell.
Once you've had an opportunity to understand the technical nuances I've shared above and follow the step-by-step example I've provided above, you'll know for yourself that it is extremely difficult, if not impossible, to find out exactly who can do what in Active Directory using PowerShell.
Specifically, there are over a dozen factors one needs to take into account, with 100% precision, and zero room for error, and no amount of PowerShell, even written by the world's best Active Directory Security practioners can make this paramount determination accurately.
The same is true of all well-intentioned but woefully deficient amateur tools like Bloodhound, which self-admittedly do not even take deny permissions into account. The sheer fact that they do not take one of the most important factors in the entire process into account renders them virtually useless from a professional standpoint.
Of course, if you don't care about accuracy, then by all means, even basic tools like acldiag can help you get "a list." Of course, since you don't care about accuracy, you likely won't care about whether or not that list is accurate.
Click, Done
There is one and only way to accurately make these paramount determinations in Active Directory, and that is by accurately determining Active Directory Effective Permissions.
There is also one and only on solution in the whole world that can accurately determine effective permissions in Active Directory and that is our Microsoft-endorsed Gold Finger solution. Fortunately, to help everyone make this paramount determination for FREE, a subset of its unique capabilities are now also available in Gold Finger Mini.
The most important report in Gold Finger Mini is - "Who can replicate secrets (i.e. password hashes)) from the domain?" and that one report can instantly and accurately determine "Active Directory Effective Permissions" on the domain root and reveal exactly how many accounts possess sufficient access to be able to run DCSync against your Active Directory, and who they are.
The basic version of Gold Finger Mini is free, and it can help every organization instantly find out exactly how many accounts can successfully run DCSync against their Active Directory today.
Gold Finger Mini can be instantly download, and installed in under two-minutes, and at the click of a button, reveal this information, for free, using any domain user account. It is a 100% read-only tool and does not require any admin access.
In light of what Microsoft shared about LAPSUS$, if I were the CISO, an IT Manager, a Domain Admin, or an IT Auditor at an organization, I would not want to sleep without having determined how many accounts possess sufficient privileged access so as to be able to run DCSync against our Active Directory today. After all, what else could be more important?
Conclusion
The objective of today's post was to help everyone realize that trying to accurately find out can successfully execute DCSync against your Active Directory is not as easy as it may seem, and neither amateur tools like Bloodhound nor PowerShell scripting can accurately take all the factors involved in this determination.
As the breaches at Okta and Microsot by LAPSUS$ have shown the entire world, a single occurrence of this threat could result in a massive cyber security breach, that could cost the organization not just millions of dollars to recover from, but serious reputational damage as well, not to mention potentially substantial liability arising from the potential loss of all kinds of organizational data, such as customer PII, financials, trade secrets etc.
Consequently, all organizations that operate on Microsoft Active Directory today, must know at all times, exactly which accounts possess sufficient ACCESS to be able to run DCSync against their Active Directory, because having this paramount insight can help them ensure that ALL such accounts are on their radar and sufficiently protected.
In contrast, it takes almost nothing at all to mitigate this serious threat and minimize the possibility of its occurrence, and today from the CEO to the CISO to the Domain Admin, all stakeholders must know what Mimikatz DCSync is, and exactly who can run DCSync against their foundational Active Directory -
👉 Gold Finger Mini - Advanced Level - Report #1 - "Who can replicate secrets from the domain?"
That's all for now.
Best wishes,
Sanjay.
No comments:
Post a Comment