How to Lockdown Active Directory to Thwart the Use of Mimikatz DCSync

Folks,

I'm going to keep this post short, because some brilliant folks feel that my blog posts are longer than their source code.


This is Very Important

On a (very) serious note, today, thanks to the DCSync feature of Mimikatz, the creation of the brilliant Mr. Benjamin Delpy, we have a situation wherein organizational security worldwide boils down to this - if you assume a breached network, then your foundational Active Directory is only as secure as the number of individuals that have the Get Replication Changes All extended right effectively granted in the access control list (ACL) that protects the domain's root object.

A perpetrator using Mimikatz DCSync feature to obtain the credentials of all domain accounts in Active Directory
 

Here's why - if the perpetrator can compromise the account of even a single user who has the Get Replication Changes All extended right effectively granted on the domain root, he/she could login as using that account, request and obtain secrets from Active Directory, and use Mimikatz to in effect determine the credentials of the entirety of your user populace, within minutes!




This is Preventable -  Deny them the Access they Need

As serious as this is, it is easily preventable. You can deny perpetrators the access they need to leverage the DCSync feature.

Thus, in your own best interest, you'll want to immediately minimize (i.e. reduce down to a bare absolute minimum) the number of users who effectively have this right granted, and from that point on not only afford those accounts the highest protection, but also verify and ensure that at all times (365-24-7), not a single individual more than is absolutely required to have this extended right, has this extended right effectively granted to him/her.

The only ability you need to deny perpetrators the access they need to use the DCSync feature of Mimikatz is the ability to accurately determine effective permissions in Active Directory, so that you can accurately assess, audit and verify exactly who has the Get Replication Changes All extended right effectively granted on the domain root object at all times.

Here's how you can lockdown Active Directory in 5 simple steps, to deny perpetrators the opportunity they need to leverage the DCSync feature of Mimikatz -

1. Identify all users who currently have the Get Replication Changes All extended right granted today on the domain root by determining effective permissions on the domain root. 

2. Analyze this list of users to identify all users who should not be on this list.

3. For every user that should not be on this list, identify how he/she is being entitled to this effective permission.

4. For each such user, based on the above identification, proceed to lockdown the identified security permissions, such as by restricting access or modifying a group membership etc.

5. Finally, determine effective permissions on the domain root object again to verify the lockdown, and ensure that only authorized individuals effectively possess this right.

Using these steps, organizations worldwide can quickly lockdown Active Directory to deny perpetrators the opportunity required to leverage the DCSync Feature of Mimikatz to engage in domain-wide credential theft, thus thwarting its use.




Required Tooling

In order to enact the 5 steps outlined above, you can use any Active Directory effective permissions tool that can help you -

1. Accurately determine effective permissions in Active Directory

2. Identify all users that have a specific effective permission granted on an Active Directory object

3. Identify how a specific user has a specific effective permission granted on that Active Directory object

Here's why - Accuracy is essential. We need to identify all such users, and we need to know the how to lockdown their access.

One tool that I know of that meets these criteria is this one. I know so because I architected it. In fact, so many of the world's top business and government organizations worldwide use it to audit privileged access in Active Directory. However, I do NOT want my advice to sound biased so you do NOT have to take my word. Please feel free to do your own research. I will only say this much, and you can validate it yourself - stay away from this tool and scripts on TechNet, as they are dangerously inaccurate.

In the interest of fairness and objectivity, I will repeat this again - you can use any Active Directory effective permissions tool you want that can help you fulfill the above 3 essential needs. I've also provided the reasons as to why these 3 needs are essential.




One

It is critical to ensure that only the absolutely minimum possible number (0/1) of users have this 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 grant is not fully locked down at all times, it could be Game Over very quickly.

Finally, 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 (i.e. via the free Try Now option.)




Complete Details

I wanted to keep this post short but perhaps you want more details. Complete details, including an example/illustration of the above 5 steps provided above, as well as the deficiencies in Microsoft's Effective Permissions Tab, and other relevant details can be found on my second blog at - http://www.active-directory-security.com. Here's the url to the post that has the details -
How to Prevent a Perpetrator from Using Mimikatz DCSync feature to perform Credential Theft from Active Directory


In your own organization's best interest, it is imperative to understand just how important this is to Active Directory security.

Best wishes,
Sanjay


PS: Ideally, I could have conveyed this in one sentence - "Simply minimize the number of individuals who effectively possess the Get Replication Changes All on the domain root. Done!"   The keyword here is "effectively" i.e. "effective permissions"

PS2: By the way, detection (see PS3 of this post) isn't sufficient, because by the time you detect and respond to an intruder replicating secrets out, it will have been too late because they will already have been replicated out. As such, when you can easily prevent something bad from happening, why merely rely on being able to detect it, especially when this is so critical?

PS3: By the way, where is Microsoft when it comes to providing some thought-leadership, as well as real-world advice and help on such critical cyber security issues? Also, what if solutions to such fundamental cyber security challenges didn't exist today?

A Simple $100B Active Directory Security Question for Alex Simons at Microsoft

Dear Mr. Simons,

I believe you are the Active Directory Czar at Microsoft these days, so I have a simple but very important question for you.

Incidentally, do you know who came up with that ludicrous title, Czar? (By the way, that's not the question I wanted to ask.)


The Question -

With the introduction of the DCSync feature in Mimikatz, the security of an entire Active Directory deployment boils down to this:

Anyone who effectively has the Get Replication Changes All extended right granted to them in the access control list (ACL) protecting the domain root object can now easily compromise the credentials of all Active Directory domain accounts, including those of all Active Directory privileged user accounts!

Although by default, only administrative personnel have this right effectively granted, since most Active Directory deployments have been around for many years, in almost all of them, the ACL protecting the domain root may have been modified several times, and as a consequence the default access may have changed substantially, resulting in a situation wherein no one may really know exactly who effectively has the Get Replication Changes All extended right granted to whom today.

Thus today it is imperative and in fact paramount for every organization in the world to know exactly who effectively has the Get Replication Changes All extended right granted in the ACL of their domain root object, and how they have it. (The need to know how is essential for being able to lock-down access for all those who currently have this critical access, but should not have it.)

So the simple $100B question is -

"Precisely what does Microsoft recommend that customers do to make this paramount determination in their foundational Active Directory deployments?"  i.e. how do they find out exactly who effectively has the Get Replication Changes All extended right granted in the ACL of their domain root object, and how they have it?

Microsoft may or may not realize this but thanks to the technical brilliance of a certain Mr. Benjamin Delpy, this is the 2nd most important Active Directory Security question facing organizations worldwide today. (In a few days, I'll let you know the 1st one.)

I (and the world) look forward to your answer.  (We hope you have one.)

Most respectfully,
Sanjay



PS 1: I imagine it shouldn't be too hard for the $450 Billion Microsoft to answer this simple question.

PS 2: Here's some Q&A that I can envisage happening, between Microsoft and its customers -

Answer: We recommend that organizations use the Effective Permissions Tab provided in our native Active Directory management tools, or our acldiag tool, to find out exactly who effectively has this right granted.

Follow-up Question (from customers): Thank you. We tried that recommendation. These tools don't seem to be very accurate and it appears can only determine effective permissions one user at a time. We have 1000s of users in our Active Directory. Do you expect our IT personnel to enter 1000s of names one-by-one manually?!

Answer: <Silence>

Follow-up Question 2 (from customers) a few weeks later: We (somehow) were able to figure out the identities of everyone who has this right effectively granted in the ACL of the domain root object. Its a long list i.e. much longer than it should be. We need to lock-down it down. Can you recommend how we could go about locking it down?

Answer: We recommend that organizations determine how these individuals have this right effectively granted to them, then use that information to tweak the underlying security permissions or modify involved security groups.

Follow-up Question 2 (from customers): Okay, but how do we determine how these individuals have this right effectively granted to them?

Answer: <Silence>

PS 3:  I sincerely hope your answer isn't one of the following, including why (because there is an easy answer to this question) -

Poor Answer 1: "We recommend that our customers use Microsoft ATA to monitor such activity." 

Reason: Microsoft ATA is basically a detection measure. In the list of protection measures, detection comes third. The first is prevention, the second is avoidance. By suggesting detection, you're conceding that you don't have the ability to provide the first two measures. And the world expects better than that from a $450 Billion company. 

Poor Answer 2: "We encourage our customers to transition to Microsoft Azure." 

Reason: It seems like Microsoft will do almost anything (including conceding defeat) to get their customers on its Cloud. I hope you realize that the degree to which you can help protect customers that are not in the Cloud, and the thought leadership (or lack thereof) Microsoft may have displayed thus far in cyber security, are a few factors that organizations consider when deciding on whether or not to bet (the security of) their business on your Cloud.  

(Besides, thousands of organizations still run Active Directory on-premises and may not want to get on the Cloud. As such, billions have been spent worldwide integrating so many applications with Active Directory and its ACLs.)

PS 4:  If you're wondering who I am, just ask Microsoft's top cyber security brass. (I'm a former blue-badger who cares deeply about the foundational cyber security of Microsoft's ecosystem.) If you're wondering why I am asking this question publicly, its because its 2016, not 2006, and we the world simply cannot afford to not have adequate solutions to address such fundamental cyber security challenges. Today foundational cyber security is a matter of paramount defenses. Before you respond, kindly also do consider a what-if scenario wherein such critical cyber security challenges, and the threats they pose, would still exist, but adequate solutions to address them did not. (Fortunately, they do exist today, and they are paramount to global security.)


PS 5:  August 01, 2016 update: Here's the answer to this question, and here's some valuable security guidance for Microsoft.