How to Easily Mitigate the Security Risk Posed by Mimiktaz DCSync

Folks,

Hello. I hope this finds you all doing well. This post is Day-7 of Active Directory Security for Cyber Security Experts.

Today, I will share with you how to easily mitigate the serious cyber security risk posed by Mimikatz DCSync hacking tool to Active Directory deployments, as well as walk through a real-world example in our Active Directory Security lab VM.




Overview

Mimikatz DCSync is a hacking tool written by Benjamin Delpy that is often used by perpetrators to swiftly and substantially compromise Active Directory deployments by letting them determine the passwords of all organizational domain accounts.

In short, if a perpetrator could successfully run Mimikatz DCSync against your domain, he/she/they could instantly find out everyone's passwords, from that of all Domain Admin accounts to that of the CEO's account to that of the krbtgt account.

In short, it would be Game Over in minutes, and the organization would have suffered a massive cyber security breach.





Root Cause

The simple reason that Mimikatz DCSync is able to determine the passwords of all domain accounts is that the account being used by the perpetrator has sufficient access so as to be able to request and obtain from Active Directory, the password hashes of all domain accounts, which it can then easily determine the clear-text version of.

To be specific, any user that has (i.e. is granted) sufficient privileged access in Active Directory to be able to replicate secrets from Active Directory can simply 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 that is required to be able 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 -

1. Replicating Directory Changes
2. Replicating Directory Changes All

That's literally all that a perpetrator needs to be able to run Mimikatz DCSync against an organization's Active Directory.




Prevention

Organizations can in fact prevent perpetrators from being able to run Mimikatz DCSync against their Active Directory.

To do so, they need to first accurately identify, and then review and lockdown the list of all personnel who are currently authorized to, i.e. have sufficient privileged access to, be able to replicate secrets from their Active Directory domains.

Specifically, if organizations can accurately determine exactly which domain accounts have these two Active Directory extended rights effectively granted in the ACL protecting the domain root object, then they can easily determine exactly who all can run Mimikatz DCSync agains their Active Directory today.

Once they have done so, a review of this list will instantly identify and reveal all accounts that currently do but that should not have this level of privileged access, and if they can additionally determine the underlying security permissions in the ACL of the domain root object that entitle these accounts to the required privileged access, they can instantly and reliably lockdown those permissions to minimize this number down to virtually zero.

Subsequently, to maintain locked-down access, security conscious organizations will want to periodically (daily, weekly or biweekly) monitor (audit) any changes in privileged access (i.e. Active Directory effective permissions) on the domain root.


In short, a simple three-step process is all it takes to prevent the use of Mimikatz DCSync -

1. Accurately identify who has sufficient effective permissions to replicate secrets from the domain
2. Review list and lockdown access, by identifying and then tweaking the underlying entitling permissions
3. Subsequently, monitor (audit) effective permissions on domain root to identify any changes in privileged access

By following this simple three-step process, organizations can easily prevent the use of Mimikatz DCSync against their foundational Active Directory, and prevent the credentials of the entirety of their user populace from being compromised.





A Classic Mistake

A classic mistake that many organizations often make when trying to determine who has the required privileged access to be able to replicate secrets from Active Directory is that they often only focus on identifying "Who has what permissions?" on the domain root object whereas in fact what they need to be doing is identifying "Who has what effective permissions?"

A simple analysis of "Who has what permissions" may not always include the impact of any deny permissions that may have been specific (directly or indirectly), or the impact of arcane nested group memberships, or the impact of any permissions granted to (dynamically evaluated) well-known security principals, or the impact of Special permissions etc.

Further, in most Active Directory deployments, there are almost always well over a hundred security permissions the ACL of the domain root object, so it is difficult, cumbersome and error-prone to make this determination with 100% accuracy.

Consequently, even organizations that know exactly what privileged access enables perpetrators to use Mimikatz DCSync may not always have the correct picture when it comes to who can actually run this tool in their environment.





The Correct Procedure

The simple and correct procedure to make this paramount cyber security determination involves accurately determining effective permissions on the domain root object to identify all individuals who are effectively granted both, the Replicating Directory Changes and the Replicating Directory Changes All extended rights.

Individuals who are on both the lists are the only ones who can successfully run Mimikatz DCSync against Active Directory.





A Step-by-Step Example

With this in mind, let us proceed to enact the three steps outlined above in our corp.local lab Active Directory domain.

• Prerequisite: To follow along this example, you will need to download and use the completely free and ready-to-use accompanying lab Active Directory VM, which can be instantly downloaded from here.

Step 1

Let us begin by examining the ACL protecting the domain root object. To do so, simply launch Active Directory Users and Computers snap-in, select and right-click the domain-root object, click the Security tab and then click the Advanced button.

Active Directory security permissions in the ACL of the domain root object

As one can see, there are many Active Directory security permissions specified in the ACL for many security principals, some allowing and some denying access, and it does not seem easy to even just view these permissions in their entirety.


As an alternative, let us try using Microsoft's dsacls command-line utility to get a better picture of this ACL -

Unfortunately, even with dsacls it seems difficult to even just get a simple listing of all the security permissions in this ACL, perhaps because dsacls is more suited to perform Active Directory ACL modifications than it is to perform ACL analysis.



Today there are several solutions available to help make Active Directory ACL/security permissions analysis easier for everyone, and you are welcome to use any tool/solution of your choice to obtain a better picture and follow along.



I am going to proceed with the Microsoft-endorsed Active Directory ACL Analyzer, because it is the simplest, most capable and most trustworthy Active Directory ACL Analyzer that I know of (, and because I architected it) -

I was able to retrieve the object's ACL at a button's touch; status bar indicates that there are 59 permissions in the ACL.


Next, I click the View Details button and the tool now shows me a detailed view of the ACL, with the security permissions field/column broken down into individual, sortable columns, one for each of the 13 Active Directory security permission types, making it easy for me to sort the ACL and hone-in on just those permissions that impact Extended Rights (CR) -

The rich, detailed view (also available in the exportable CSV format) helped me make the following determinations -

1. Of the 59 permissions in the ACL, there are 33 permissions that specify (allow/deny) extended right permissions
2. Of these 33 permissions, 19 permissions directly or indirectly specify the two permissions we are interested in
3. Of these 19 permissions, 13 permissions indirectly specify both the permissions we are interested in 
4. Of these 19 permissions, 3 permissions directly specify the Replicating Directory Changes extended right
5. Of these 19 permissions, 3 permissions directly specify the Replication Directory Changes All extended right
6. Of these 19 permissions, 2 permissions deny access, and the remaining allow access
7. Finally, altogether, these 19 permissions allow/deny access to 17 unique security principals

As one can see, this information in itself is already helpful because it has helped us determine which of the 59 security permissions in the ACL of the domain root object we need to take into account to make this determination.

In case it helps, here's a snapshot of the output of this tool, exported to CSV and opened in Excel -

Saliently, there are 17 security principals that we need to focus on, almost all of which are security groups that we will need to expand, and perhaps some of them may contain nested groups (of which some could be circularly nested) etc.

This also indicates that we will also have to perform conflict resolution because there are at least 2 security permissions that deny extended rights to 2 different security groups, either of which could be nested (, possibly even circularly nested).

•  Side-note: Question - Does Bloodhound negate denies? If not, how can it be accurate?

Incidentally, I could also have just used the Active Directory Permissions Analyzer to make this very determination, without having to perform any kind of visual analysis i.e. I could have just specified that I am looking for exactly these permissions, and it would have instantly found them for me, making the task even easier -

However, this still leaves us with 16 security groups to completely expand (the 17th security principal being System itself,) and while we could proceed to do so, it would still involve some work, not to mention meticulously taking into account which permissions grant blanket access and which one grant specific access, negating allows with denies etc. etc.

Let us also keep in mind that in this case, we are looking at a small domain of a fictional organization so there are only 16 security groups to expand. In most real-world production Active Directory domain, there are over 100 security permissions and there could easily be many, many more security groups one may have to manually and meticulously expand!


This may make you wonder that there must be an easier way to do this. After all, can you imagine how much effort it might take us each time we needed to make this determination, and all such determinations in Active Directory.

Indeed, there IS actually an easier way, and in fact it is the only correct way to make this determination, and all such determinations, and that ONE simple, easy and correct way is called "Active Directory Effective Permissions"


In fact, its right there in Microsoft's native ADUC tooling's Advanced Security tab, and its called the Effective Access tab.

The importance of this tab is conveyed by the simple fact that it is one of the three tabs that exist in ADUC's Advanced Security tab, along with Permissions and Auditing, and it has existed since day one, i.e. since Windows 2000.

For years it was called the Effective Permissions tab, until Microsoft recently changed its name to Effective Access tab.


Well, if this tab exists in ADUC, let's just proceed to use it to make this determination, and IF IT CAN FULFILL OUR NEED, then there's no point in wasting our precious time on all that ACL/permissions analysis etc., so lets see if it can help us -

The first thing you'll notice is that you need to enter a user's name. As seen above, I entered the name of a specific user, Peter Jackson, and it showed me an approximation of the effective permissions that Peter Jackson has on the domain root. One can scroll down to see the full list of effective access that Peter Jackson is entitled to on this object.

Therein lies the problem. It can at most determine (approximate) effective permissions ONE USER at a time. :-( In other words, you can specify a particular user, and it will determine and show you the effective permissions for that ONE user.

In this demo Active Directory domain itself, there are over a thousand users and computers, and in most organizations there could be tens of thousands of users and computers, and I don't know about you, but most people do NOT have the time to enter ONE USER AT A TIME and then make a note of his/her effective permissions etc. as this would take weeks!

In short, Microsoft's Effective Permissions/Access Tab is hardly useful i.e. practically useless, and that's so unfortunate.

It is only useful to the point wherein you may want to find out what effective permissions a specific user may have. Further it cannot accurately calculate the complete set of effective permissions, and it cannot pinpoint which underlying security permission in the ACL entitles a user to a specific effective permission, which one needs to know to lockdown access.


Hmm. It seems like after all, even after twenty years, we'll just have to go right back to doing boring, complicated and laborious Active Directory permissions analysis, group membership evaluations, conflict resolutions etc. MANUALLY :-(


As I have said earlier, you can use any tool from any vendor you like to help you ultimately do ALL that is involved (i.e. ACL analysis, group membership expansions, allow vs. deny conflict resolution etc.) to make this determination accurately.


As for myself, I'm going to use this Microsoft-endorsed tool, and I'll be completely done in less than one minute -

This unique tool is the world's only accurate fully-automated effective permissions calculator for Microsoft Active Directory.

It can do, what no other tool or entity (i.e. person or company) in the world can - instantly and accurately determine the complete set of effective permissions entitled on any Active Directory object, identify exactly which accounts have these effective permissions, and pinpoint the underlying permissions that entitle these accounts to these effective permissions, all at the touch of a button.

As you can see above, all I had to do was point the tool to the domain root object, and click a button, and in less than a minute, it accurately determined and revealed the complete set of effective permissions entitled on this object, exactly who has these effective permissions, and which underlying permissions entitle a user to a specific effective permission.


I simply used the What drop-down to locate and select Extended Right - Replicating Directory Changes and it instantly showed me that a total of 40 accounts have this effective permissions on the domain root object -

Next, I used the What drop-down to locate and select Extended Right - Replicating Directory Changes All and it instantly showed me that a total of 40 accounts have this effective permissions on the domain root object -


Then, all I had to do was intersect these two lists, which I easily did by exporting the results to CSV and opening it in Excel.


Here is the list of 40 accounts that can run Mimikatz DCSync in the lab corp.local domain

Administrator, Alexander White, Andrew Cushman, Around Trust, Brandon King, Certify Suite, Control Engine, Darren Baker, David Edwards, DC, Donald Parker, Felix Defense, Frank Collins, George Carter, Greg Baker, Harper Anderson, Henry Moore, Isabelle Woods, James Cushman, Jane Moore, Jason Goodman, Kevin Johnson, Larry Phillips, Lauren Cruise, Lucas Allison, Mary Gates, Michael Young, Nancy Clark, Net Tricks, Nicholas White, Passive Server, Peter Brown, Peter Jackson, Ryan Clark, Simon Baker, Solar Breeze, Susan Douglas, Suzanne Goodman, Tim Young, Victor Branson

•  Note - The accounts in red are unmanaged service accounts !

Thus, as seen above, it took me just a few minutes to complete step 1, which was to accurately identfy all accounts that possess sufficient privileged access to be able to replicate secrets from Active Directory.



Step 2

Now that we have accurately identified the list of all individuals/users/accounts who possess sufficient privileged access to be able to replicate secrets from Active Directory, its time to review and lockdown this list.

We have identified 40 accounts that possess this level of access. That is about 39 accounts too many if you ask me, and at least 30 accounts to many by most standards, so we need to review and reduce this list.

Perhaps a good place to begin is by reviewing the 7 unmanaged service accounts (from various vendors), on the list.

As seen above, there are 7 unmanaged service accounts that possess this high level of privilege. During an internal meeting this was discussed and it was determined that none of these 7 service accounts actually require the ability to replicate secrets, so we agreed to take away this privileged access from these service accounts.

The only question was how do we find out which one of those 59 security permissions in the ACL of the domain root is the one that entitles these 7 service accounts to this alarmingly high level of privileged access.

Fortunately, with the tool above, all I had to do was click on the names of these service accounts, and it pinpointed the exact security permission in the domain root object's ACL that was responsible for these service accounts having such a high level of privileged access -

Here's the underlying (culprit) permission:  Allow  corp\Administrators  Extended Right - Replicating Directory Changes All


A quick review of the membership of the corp\Administrators security group confirms the finding -

As we can see in the snapshot above, the Domain Admins security group is a member of the Administrators security group, and the Privileged Service Accounts group is a member of the Domain Admins security group.

Thus, it was this nested group membership that was entitling these 7 service accounts to this privileged access.


Incidentally, I actually used the following tool to view the complete nested membership of any Active Directory Security group, because it automatically shows me the complete nested group membership of any domain security group -

But I digress.

Now, to lockdown the privileged access granted to these 7 unmanaged service accounts, I have many options -

1. I can remove these service accounts from the Privileged Service Accounts group
2. I can remove the Privileged Service Accounts group from the Domain Admins group
3. I can remove the Domain Admins group from the Administrators group
4. I can modify or remove the security permission that grants this extended right to Administrators
5. I can add an explicit deny permission denying the Privileged Service Accounts group one of these extended rights

In short, once I have enacted the above, these service accounts will no longer possess this privileged access on the domain root, and I will have reduced the number of accounts that can replicate secrets from Active Directory by 7!

Further, to verify that I correctly locked it down, I can simply run the tool again, and it will instantly show me the results.

In this manner, I can proceed to evaluate every account on this list, then make a determination as to whether or not that account requires the privilege to replicate secrets from the domain, and if not, I can lockdown access for each of these accounts, thereby substantially reducing the number of accounts with such a high level of privilege.

Most importantly, I now have complete control, because I have complete and accurate insight into exactly who has this level of privilege, and how i.e. I also know which underlying permission is entitling each such account to this privilege.

In this manner, I can eventually reduce this number down to just 2 - the System and the DC itself!



Step 3

It is important to note that it is not sufficient to merely identify these accounts and then lock the access down just once, but in fact to periodically audit who has this level of privileged access in your Active Directory.

The reason is simple - invariably, at least a few Active Directory admins and service accounts may still possess the ability to modify permissions on the domain root, and thus any action taken by them, whether intentional, accidental or coerced could change the state of access provisioned on the domain root.

In addition, any delegated admin who may be in control of a group membership that is currently granted this level of privilege on the domain root could also easily and indirectly cause the resulting effective access to change.

Thus, it is important to periodically review exactly who possesses this level of privileged access on the domain root, and as seen above, with the right tooling, it only takes a few minutes to make this determination.

We recommend that organizations review this at least on a fortnightly basis, if not on a weekly basis.




Something to Try

The accompanying lab AD Security VM is free to download and follow along this example, and others that I will be sharing.

In addition to what I have shared above, (which you can attempt with any tool of your choice), here's something you can easily try to see how the state of effective access changes, impacting who can run Mimikatz DCSync right away!

Select any existing user account from amongst the 1000+ domain user accounts in the VM and simply add this account to the IT Security Incident Response Team. 

When you do so, you'll find that this account will be able to instantly use Mimikatz DCsync against this domain!

Next, take the same account and this time around, also add it to the Contractors team.

When you do so, you'll find that the account will no longer be able to use Mimikatz DCSync against this domain!

When you add the account to the IT Security Incident Response Team, it ends up effectively getting both the extended rights needed to replicate secrets from Active Directory. Next, when you add the account to the Contractors team, it ends up being denied this very access, because the Contractors team is denied this access, so the explicit deny will override the explicit allow.

•  Note - After you are done trying, please undo both changes, because otherwise the overall state of access in your copy of the demo AD lab VM will have changed, and the results of all examples that I will be sharing in days to come will differ in your AD, making it difficult to follow future examples.

This simple experiment shows how effective permissions and actually determine privileged access in Active Directory.





Conclusion

The objective of today's post was to show you how to easily mitigate the serious security posed by Mimikatz DCSync.

We began by identifying exactly what privileged access is needed to successfully run this tool against Active Directory, and then by learning how to correctly determine exactly who has this level of privileged access in Active Directory, because once we know that, we can lock it down and be in control, knowing at all times, exactly who could do so, and how.

We also touched upon the fact that it is important to make this determination periodically, because the state of underlying access can change, either directly or indirectly, impacting this in subtle ways that may not be apparent to the naked eye.

It is also very important to understand just how dangerous a threat the use of Mimikatz DCSync poses to Active Directory and to every organization that operates on it. A perpetrator only needs to run the tool ONCE and he/she would have instantly compromised the credentials of ALL your domain accounts, from the CEO to the CISO to the Domain Admin to every employee and every service account, as well as the krbtgt account.

In short, 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.

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.

Towards that end, possibly the single most important thing you could do for your organization today is to bring this to the attention of all stakeholders, and ensure that they understand this threat and how to protect your organization from it.

Here's a post you could share internally - A Massive Cyber Breach at a Company Whilst it was Considering the 'Cloud'

That's all for now.

Best wishes,
Sanjay.