Folks,
Today, I'd like to take a few minutes to show you 5 simple steps that you can enact in 5 minutes to prevent a perpetrator from using the DCSync feature of Mimikatz to perform credential theft from Active Directory.
This is very important, so please read it.
I'm not going to go into too many details regarding the specific threats posed by this feature of Mimikatz, or its details, use and exploitation. For that kind of stuff, you can check
this out. What I will do is provide a quick overview, cover some pertinent aspects, including why its so important to do this, and most importantly
show you exactly how to easily do this.
A succinct version of this blog post can be found at -
How to Lockdown Active Directory to Thwart the Use of Mimikatz DCSync
I. Quick Overview
As you may know,
Mimikatz, is a hacking tool developed by a certain Mr.
Benjamin Delpy that can, to put it mildly, gather credential data from Windows systems. It can do a lot more, and you can read all about it's numerous capabilities
here.
 |
| An Intruder using Mimikatz |
The short of it is that any perpetrator who has administrative control over an owned machine can use Mimikatz to easily obtain and reuse the credentials of anyone who may have logged on that machine.
When run on non-domain controllers, the impact is limited to being able to obtain/access/reuse the credentials of only those individuals that may have logged on that machine. In a typical Active Directory environment, you may at most have a few individuals that may have logged on to a specific machine. By few, I mean a very small number compared to the total number of domain user accounts in Active Directory. So, at most, the damage would be restricted to the credential compromise/theft of those individuals that logged on the owned machine. Of course, this could be used to target other domain-joined hosts on the network etc. but in general, one likely couldn't obtain access to the credentials of the entire user population.
In contrast, if a perpetrator could successfully run mimikatz on a Domain Controller, then he/she could easily dump LSASS on the Domain Controller to obtain access to the password hashes of all domain accounts and thus
easily obtain access / effectively compromise the credentials of your entire user population!
II. But wait, its Already Game Over
Please note that it is IMPERATIVE to understand that in order to "successfully" run Mimikatz on a Domain Controller, the perpetrator would have to be logged on as an Admin on the Domain Controller, and here's the Trillion $ point -
IF THE PERPETRATOR CAN LOGON AS AN ADMIN ON A DOMAIN CONTROLLER, it is already GAME OVER right at that point!
 |
| Perpetrator having Admin Creds on on a Domain Controller |
He/she need not do anything else to play God! At that point, he/show already effectively owns your entire Kingdom. Incidentally, only those perpetrators who do not know this trivial fact will need to enact many more steps to play God.
In essence, if an unauthorized individual can logon to even one DC as an Admin, please consider your entire Active Directory forest compromised. It's that simple. You're done. Its over. There's nothing more left to defend. (A little more on that
here.)
Thus, it is of paramount importance to ensure that only the most trustworthy and authorized individuals are allowed access to and ability to logon to Domain Controllers!
III. A Seemingly Simple Mitigation?
Consequently it follows that if you can ensure that the perpetrator can never logon to your Domain Controller as Admin, (
it used to be that) you don't have to worry about his/her ability to essentially access/steal the credentials of your entire user populace (i.e. all domain users in your Active Directory, which could be 1000s or for some companies, a 100,000+ users.)
 |
| Logon to Domain Controllers Locked Down |
I say
used to be, because Mimikatz recently got a new feature called
DCSync, as a result of which, if the perpetrator has sufficient privileged access delegated/provisioned to him/her in the Active Directory, then he/she no longer need logon to a Domain Controller as admin to be able to in effect compromise/steal the credentials of your entire user populace, because via the tool, he/she could request that Active Directory replicate out to him/her all Active Directory data including secrets (i.e. password hashes), and once the tool has these secrets, the rest is easy and automated by the tool.
As a result, today denying a perpetrator the ability to logon as Admin on to a Domain Controller is no longer a sufficient mitigating measure for this risk. To reliably mitigate this risk, an additional essential measure, described below, is required.
IV. But First, A Quick Background of the New Vector
Before I can share information on the additional essential measure, I should share some background information on the new vector, so you can understand why this additional step is essential and required.
As a result of this new
DCSync feature, Mimikatz can now leverage a capability in Active Directory wherein a user who effectively has sufficient rights to do so, can basically request that Active Directory replicate out to it, the entire Active Directory partition contents, including secrets, which are essentially the password hashes stored in Active Directory.
In effect,
instead of having to logon to a Domain Controller, the perpetrator can simply
request that Active Directory send over all the password hashes to the perpetrator, thus obviating the need to be able to logon to a Domain Controller, and thus bypassing the protections put in place that would prevent him/her from logging on as an Admin on Domain Controllers!
The ability to enact the administrative task of
Replicating all Active Directory data, or more simply put the ability to replicate secrets out from an Active Directory domain is governed by a single system-level access grant, i.e. an Active Directory security permission (strictly speaking, an Extended Right) called
Replicating Directory Changes All. Anyone who effectively has this extended right granted to him/her on the domain NC head, i.e. in the access control list (ACL) of the domain root object can replicate secrets out from Active Directory. This ability has existed in Active Directory since 2000. (More on this extended right below.)
V. The Replicating Directory Changes All Extended Right
As mentioned above, the ability to replicate data, including secrets (i.e. password hashes) from an Active Directory domain is controlled by the
Replicating Directory Changes All extended right. Its CN is called
DS-Replication-Get-Changes-All -
 |
| The Replicating Directory Changes All extended right in the ACL on the Domain Root object |
For those who are technically inclined, you can checkout
Appendix D of Microsoft's
whitepaper on Administrative Delegation in Active Directory which I wrote for Microsoft way back in 2003. Its Rights GUID is
1131f6ad-9c07-11d1-f79f-00c04fc2dcd2.
Only those individuals who effectively have this extended right granted to them in the ACL of the domain root object (also known as the NC head) can replicate all data (including secrets i.e. password hashes) from the Active Directory.
VI. The Second Essential Measure - Lockdown Replicating Directory Changes All Extended Right
If it is this extended right that controls who can replicate all data, including secrets (password hashes) out of Active Directory, then it logically follows that simply locking down who effectively has this right granted to them would be a second essential measure towards mitigating the risk posed by a perpetrator's ability to steal/compromise the credentials of your entire user populace!
Now, the act of locking down this right is fairly simple and straight-forward. However,
before you can do so, you'll need to be able to precisely determine/assess exactly who all have this extended right
effectively granted to them in the first place,
and after you have taken the steps to lock it down, you'll need to verify that the steps you have taken to lock it down have actually achieved the desired lockdown.
It turns out that in order to do both, i.e. precisely determine/assess exactly who all currently have this extended right effectively granted to them, as well as to verify that post lockdown, only the intended individuals have this right effectively granted to them, you require the ability to be able to accurately determine (something known as)
effective permissions in Active Directory.
In other words, one can neither accurately figure out who currently has this right effectively granted, nor accurately verify the lockdown measure without being able to (accurately) determine effective permissions in Active Directory.
VII. The Need to Determine Effective Permissions
By default, only the most powerful administrative groups in Active Directory as well the domain's Domain Controllers have this extended right granted to them.
So in environments wherein the security permissions on the domain root have NEVER been changed, it may be safe to assume that only members of the most powerful administrative groups can replicate secrets out of the Active Directory.
However, as you'll agree, most Active Directory deployments have been around for years, and over the years, many IT personnel may have changed permissions all across Active Directory, including on the domain root for various reasons, such as to delegate administration, provision access for/to line-of-business applications or to lockdown access in Active Directory.
As a result, in 99.9% of all Active Directory deployments, the ACL on the domain root objects is no longer the same as the original default ACL when the domain was created. Consequently, it would be unwise and dangerous to assume that this permission grant would not have changed.
 |
| Numerous IT personnel may have the Get Replication Changes All right effectively granted to them Active Directory |
In fact, for reasons outlined below,
it can almost be guaranteed that many more individuals that should ideally have the ability to replicate secrets out of Active Directory, have the ability to do so
today -
1. An administrator may have deliberately made access provisioning changes on the domain root object, either to grant or deny additional individuals or groups this specific access i.e. Get Replication Changes All
2. An administrator may have accidentally ended up granting or denying this specific access, such as by granting or denying a specific user or group All Extended Rights or Full Control instead of this specific extended right
3. A malicious administrator may have deliberately granted an obscure group, containing other nested groups or specific user accounts, this extended right as a backdoor, so that, in the future, were he/she to be terminated, he/she could use that obscure account to replicate secrets out and in effect own the entire domain.
Point 2 in particular is worth reiterating. Any blanket permissions such as
All Extended Rights, or
Full Control, specified in the ACL of the domain root that may have been deliberately or accidentally specified will undoubtedly cover this extended right, and thus could unknowingly end up granting tremendous power to some individual who is not ideally authorized to possess it.
Finally, as you may know, there are many permission entries, each one of which directly/indirectly allows or denies some access for some security principal. Ultimately what matters is that the system takes into account the appropriate precedence orders and resolves any conflicting rights to arrive at the determination of whether or not to grant a specific security principal the requested access. In other words, what determines the actual access a user has on an Active Directory object are his/her
effective permissions.
It is for the above reasons that when trying to audit access in Active Directory, it is grossly insufficient to merely analyze "who has what permissions" and in fact absolutely essential and paramount to analyze "who has what effective permissions".
Thus, to answer the simple yet paramount cyber security question "
Who effectively has the Replicating Directory Changes All extended right on the domain root", what is needed is the ability to determine effective permissions on the domain root object.
The concept of effective permissions is very important to understand, yet hardly understood, and as a result, most individuals, including many IT professionals as well as proficient hackers, tend to mistake "
who has what permissions" for "
who has what effective permissions."
To reiterate, considering all the permissions specified in the ACL of an Active Directory object, the difference between the various
permissions specified for a user and the actual
effective permissions that a user ends up with, could be NIGHT and DAY, and could be the difference between SECURITY and COMPROMISE.
VIII. Determining Effective Permissions on Active Directory Objects
Given the vital importance of effective permissions, Microsoft provides an Effective Permissions Tab in Active Directory to help organizations determine effective permissions on Active Directory objects.
 |
| The Effective Permissions Tab in Active Directory |
Unfortunately, Microsoft's Effective Permissions Tab is virtually useless, because of two main reasons, the first one being that it is not always accurate, but/and more importantly, the second one being that it can at best determine effective permissions
for one user at one time.
 |
| Security Principal Selector |
This (second reason) might not readily appear limiting, but if you consider an environment with thousands (or even hundreds) of users,
you'll realize that the only way to accurately determine a specific effective permission on an Active Directory object is to enter the identity of each one of these thousands of users one by one to arrive at an accurate picture of who really has what effective permissions on that object, and as you can see, doing so could be very arduous, time-consuming and painstaking.
The same is true of the effective permissions capability of Microsoft's
acldiag command-line tool.
Security Warning: In regards to Active Directory Effective Permissions tools, please note that this specific tool is exremely inaccurate, and thus any reliance on it could potentially result in the introduction of dangerously inaccurate changes. The same is true of any script(s) etc. available on Microsoft TechNet.
Ideally, what is required is the ability to be able to
quickly (i.e. within minutes, not days) and
accurately determine effective permissions on the domain root, such that one could easily determine the list of
all individuals to whom this critical extended right is effectively granted, as well as
how they have it effectively granted.
For instance, something like this -
 |
| Gold Finger Active Directory Effective Permissions Tool |
The snapshot above (click to enlarge) is that of the world's only accurate
Active Directory Effective Permissions Tool.
Armed with a tool such as the above, IT personnel can now instantly identify exactly who effectively has this (and in fact any) right granted on the domain root (and in fact on any object in any Active Directory partition) within seconds, at a button's touch.
IX. How to Correctly Lockdown the Replicating Directory Changes All Extended Right on the Domain Root
With the background information gained above, your are now in a position to easily lockdown the
Replicating Directory Changes All extended right on the domain root in 5 simple steps -
Note: The following steps utilize the following Active Directory Effective Permissions Tool - http://www.paramountdefenses.com/active-directory-effective-permissions-tool.html
1. The first step is to determine effective permissions on the domain root. The really hard way to do so is to use the Effective Permissions Tab in Active Directory, and enter the identity of every user in your domain and make a note of whether or not they have the
Replicating Directory Changes All extended right effectively granted to them. As mentioned above, the easy way to do this is to use
this Active Directory Effective Permissions Tool. Simply click a button and you're done.
For instance, in the following domain, using such a tool we have identified that a total of
15 users are effectively granted the
Replicating Directory Changes All extended right in the domain root object -
Specifically, we can see that the following 15 users currently have this right effectively granted to them -
- Administrator
- Alex Simons, Cloud Active Directory Administrator
- Chris Betz, Cloud Engineer Architect
- DC1
- Gene Farrell, DevOps Cloud Engineer
- Hayden Hainsworth, Cyber Security Cloud Engineer
- Jeff Bezos, Cloud DevOps Operator
- Ken Malcolmson, DevOps Cloud Engineer
- Marc Benioff, Cloud DevOps Admin
- Michael Brown, Cloud Product Manager
- Mike Neil, Cloud Software Engineer
- Satya Nadella, Cloud DevOps Engineer
- Stephen Schmidt, Cloud Security Engineer
- Steve Ballmer, IT Analyst
- Terry Hanold, Cloud Operations Engineer
2. The second step is to analyze the results of the effective permissions analyze and identify all users who currently have this critical right assigned to them, and identify how many of these users should NOT have this critical right assigned to them.
For instance, here we have identified that the following individuals should not actually have this critical access right granted to them, but happen to have it granted nonetheless -
Specifically, based on our corporate security policies, we have identified 12 users who should
not ideally have this right effectively granted to them -
- Alex Simons, Cloud Active Directory Administrator
- Chris Betz, Cloud Engineer Architect
- Gene Farrell, DevOps Cloud Engineer
- Hayden Hainsworth, Cyber Security Cloud Engineer
- Jeff Bezos, Cloud DevOps Operator
- Ken Malcolmson, DevOps Cloud Engineer
- Marc Benioff, Cloud DevOps Admin
- Michael Brown, Cloud Product Manager
- Mike Neil, Cloud Software Engineer
- Satya Nadella, Cloud DevOps Engineer
- Stephen Schmidt, Cloud Security Engineer
- Terry Hanold, Cloud Operations Engineer
In case it helps, the complete CSV file for this effective permissions audit (pre-hardening) generated using the above tool can be found
here.
3. Once you have done so,
the third step involves determining HOW these users are currently ending up with these effective permissions, because in order to lockdown access, we will need to know HOW they are ending up with these permissions. Once we know the HOW, we can proceed to make the appropriate changes.
For instance, below, to find out how a user has this extended right effectively granted to them, we simply click on the user's name, and the underlying ACE (/ security permission) is displayed -
Specifically, in the snapshot above, we have been able to determine that
Alex Simons, a Cloud Active Directory Administrator effectively has this right granted to him due to the following access control entry in the ACL of the domain root:
Allow root\IT Cloud DevOps Team (All) Extended Right(s).
(It turns out that in this example, the 12 users who should not effectively have this right granted, but do nonetheless, all have this access by virtue of membership in the IT Cloud DevOps Team group.)
We now know which ACE to tweak and/or which security group membership to change to take away this effective right from Alex Simons -
4. The fourth step is to actually make the changes required to lockdown access i.e. to make any necessary ACLing / permissioning changes, and/or changes to any group memberships as required to in effect take away these unintentionally granted (and thus in effect unauthorized) permissions, ultimately resulting in a situation wherein only those who should have this critical right effectively granted, have it granted.
For instance, to lockdown Alex Simon's access, we remove the ACE that was granting this access to the
IT Cloud DevOps Team group, and as a result members of that group should no longer have this right granted to them -
5. The last step is to
verify that after you have taken the lockdown steps, the resulting effective access is indeed such that only those who should have this critical right granted have it granted, and that no other individuals have this critical right effectively granted to them.
For instance, we simply run the Effective Permissions tool again, and we can see that NOW only those (a very small set of highly trustworthy and authorized) individuals who should be the only ones to have this right effectively granted to them, have it effective granted to them -
In the snapshot above, we can now see and
verify/confirm that indeed, only 3 users have this critical right effectively granted to them -
- Administrator
- DC1
- Steve Ballmer, IT Analyst
In case it helps, the complete CSV file for this effective permissions audit (post-hardening) generated using the above tool can be found
here.
In this manner, having enacted these 5 simple steps in just a few minutes, we can easily and reliably lockdown the effective grant of the
Replicating Directory Changes All extended right on the domain root, and consequently enact the second essential and necessary measure required to prevent the unauthorized replication of secrets from Active Directory, and to mitigate the risk of the mass credential theft of all domain user accounts in Active Directory.
X. This is VERY Important!
As explained above, it is VERY important that only the absolutely minimum possible number (
0/1) of users have this critical right effectively granted to them.
If even one additional user is effectively granted this critical right, and the perpetrators can identify them and compromise their account(s) (credentials), then they will simply be minutes away from being able to steal the credentials of every user in the Active Directory domain, including all privileged users such as all Domain Admins, Enterprise Admins, Built-in Admins etc.
So,
in a way, today, the security of an entire Active Directory domain (and thus forest) depends on exactly who effectively has sufficient enough rights to be able to replicate secrets out of Active Directory!
In other words, to put it simply, if this security right grant is not fully locked down, it could be
Game Over very quickly.
Summary
To summarize, in this blog post, I wanted to and have shared the following information with you -
- How a perpetrator can use the DCSync feature of Mimikatz to steal the credentials of your entire user populace
- What makes it possible for the DCSync feature of Mimikatz to work
- What mitigation measures we can take to lockdown who can replicate secrets from Active Directory
- What are the reasons due to which more people than those allowed by default may effectively have this right granted
- Why we need to be able to determine effective permissions precisely to assess and verify who effectively has this right
- How to mitigate the risk posed by the DCSync feature of Mimikatz in 5 simple steps (i.e. how to render it useless.)
Organizations worldwide can now use this information to quickly and easily prevent a perpetrator from using Mimikatz' DCSync feature to perform mass credential theft from Active Directory.
Alright, my time's up. I hope you have found this information to be useful and valuable.
Best wishes,
Sanjay
PS: To demonstrate just how deeply we care about cyber security globally, any* organization that wishes to find out exactly
how many individuals effectively have this right granted today, can now do so completely
free (; via the free
Try Now option.)
