Mimikatz DCSync Mitigation

Folks,

A few days ago I asked a (seemingly) very simple question ; no I'm not referring to this one, I'm referring to this one here  -

Can Anyone (i.e. any Cyber Security Company or Expert) Help Thousands of Microsoft's Customers MITIGATE the Risk Posed by Mimikatz DCSync?

Here's why I did so - While there's a lot of info out there on the WWW about how to use Mimikatz DCSync, and/or how to detect its use, there isn't one other* single correct piece of guidance out there on how to mitigate the risk posed by Mimkatz DCSync.

So, as promised, today I am (literally) going to show you exactly how thousands of organizations worldwide can now easily and demonstrably actually mitigate the very serious cyber security risk posed to their foundational security by Mimikatz DCSync.

In light of what I've shared below, organizations worldwide can now easily mitigate the serious risk posed by Mimikatz DCSync.




First, A Quick Overview

For those who may not know, and there are millions who don't, there are three quick things to know about Mimikatz DCSync.

Mimikatz DCSync, a Windows security tool, is the creation of the brilliant technical expertise of Mr. Benjamin Delpy, whose work over the years has very likely (caused Microsoft a lot of pain ;-) but/and) helped substantially enhance Windows Security.

Mimikatz DCSync targets an organization's foundational Active Directory domains, and instantly gives any attacker who has sufficient privileges to be able to replicate sensitive content from Active Directory, access to literally everyone's credentials!

Thus far, the only guidance out there is on how to DETECT its use, but this is one of those situations wherein if you're having to rely on detection as a security measure, then its unfortunately already TOO late, because the damage has already been done.



Detection Is Hardly Sufficient

They say a picture's worth a thousand words, so perhaps I'll paint a picture for you. Relying on detection as a security measure against Mimikatz DCSync is akin to this -

Lets say a nuclear weapon just detonated in a city, and the moment it did, detection sensors alerted the city officials about the detonation. Well, within the few seconds in which they received the alert, the whole city would've already been obliterated i.e. by the time you get the alert, literally everyone's credentials (including of all privileged users) would've already been compromised!

Make not mistake about it - a single successful use of Mimikatz DCSync against an organization's foundational Active Directory domain is tantamount to a complete forest-wide compromise, and should be considered a massive organizational cyber security breach, the only way to recover from which is to completely rebuild the entire Active Directory forest from the ground up!

This is why detection is grossly insufficient as a security measure, and what organizations need is the ability to prevent the use of Mimikatz DCSync's against their foundational Active Directory domains & thus the ability to mitigate this risk is paramount.



How to Mitigate Mimikatz DCSync

The key to mitigating this risk lies in identifying what it technically takes to be able to successfully use Mimikatz DCSync.

Specifically, if you know exactly what privileges an attacker needs to be able to successfully use Mimikatz DCSync against your Active Directory domain, then by ensuring that only highly-trustworthy, authorized individuals (and not a single other individual) actually currently possess those required privileges in your IT infrastructure, you can easily mitigate this risk.

Technically speaking, all that an attacker needs to successfully use Mimikatz DCSync is sufficient Get Replication Changes All effective permissions on the domain root object of an Active Directory domain, so all that organizations need to do is accurately identify exactly who has these effective permissions on the domain root object of each of their Active Directory domains.

While by default only the default administrative Active Directory security groups are granted this permission, since most Active Directory deployments have been around for years, and have likely gone through a substantial amount of access provisioning, in most Active Directory, a lot many more individuals than merely the members of the default AD admin groups may likely have this highly sensitive effective permission granted to them, either directly or via group membership, some of which may be direct, whilst others may be via nested group memberships, resulting in a potentially large and unknown attack surface today.

Now, it is paramount to understand ONE subtle but profound difference here - it is NOT who has what permissions on the domain root that matters, but who has what effective permissions on the domain root that matters, and this difference could be the difference between a $100 B organization being completely compromised or being completely protected from compromise.



The Key - Active Directory Effective Permissions

If you've followed what I've shared above, then you'll agree and understand that the key to being able to successfully mitigate the serious risk posed by Mimikatz DCSync lies in being able to accurately determine effective permissions in Active Directory.

In fact Effective Permissions are so important, essential and fundamental to Windows and Active Directory Security, that of the four tabs in all of Microsoft's Active Directory Management Tooling, one entire tab is dedicated to Effective Permissions.

Unfortunately, it turns out that not only is Microsoft's native Effective Permissions Tab not always accurate, it is substantially inadequate, and while I could elaborate on that, I'd rather let you come to the same conclusion yourself, and this ONE glaring inadequacy will be self-evident the moment you attempt to use it to try and find out exactly whom amongst the thousands of domain user account holders in your Active Directory domain(s), actually has the required effective permissions. In fact, the same is true of all tools/scripts that involve the use of Microsoft's APIs to do so, such as this dangerously inaccurate free tool.

Fortunately, in a world whose population is 7,000,000,000+ today, thanks to one (1) inconsequential individual, there's hope...



Finally, How to Easily and Reliably Mitigate the Risk Posed by Mimikatz DCSync

Here's a very short (and perhaps boring but insightful) video on how organizations worldwide can reliably mitigate this risk -

Note: This is NOT intended to demonstrate our unique tooling. It is solely intended to show what it takes to mitigate this serious risk. We have no particular interest in licensing our unique tooling to anyone. As such, over the years, we have NEVER, not once pitched our tooling to anyone; we've had almost 10,000 organizations worldwide knock at our doors completely unsolicited, so I hope that makes this point unequivocally.

Thus, as seen in the short video above, with the right guidance (knowledge) and capability (tooling), organizations worldwide can now easily and reliably mitigate the serious cyber security risk posed by Mimikatz DCSync to their foundational security.

Complete, illustrated, step-by-step details on how to easily and correctly mitigate Mimikatz DCSync can now be found here.


I'll say this one last time - a single successful use of Mimikatz DCSync against an organization's foundational Active Directory is tantamount to a forest-wide compromise and constitutes a massive cyber security breach, which is why mitigation is paramount.

Best wishes,
Sanjay


PS: *Here are 4 posts I've previously penned on Mimikatz DCSync - a summary, technical details, a scenario and the question.

PS2: In days to come, I'll answer this question too.

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.

A Letter to Benjamin Delpy regarding Mimikatz & Active Directory Security

Dear Mr. Delpy,

Hello. I hope this finds you doing well. Although we don't personally know each other, I've heard about your work, and the impact it's had on improvements in Windows Security, so thank you for your contributions to the field of Windows Security.

To begin with, I'd like to apologize for not having been able to tune sooner into the incredible circus caused by your interesting hobbies over these past few years :-), as I was away, silently working on the world's most powerful cyber security weapon ...

Gold Finger 007G

... you know, one that can be used to go from breach to 0wned (AD) in about 5 minutes in any Active Directory deployment in the world, even and particularly in environments (such as the one described below) wherein an intruder couldn't accomplish much with Mimikatz. We've built it for the good guys though, so that they can prevent such scenarios from occurring.


By the way, like you, I too am a programmer. I personally wrote about 10% of the code for all of Gold Finger and 007G.
(The rest of it was written and tested by a team of < ~ 50 software dev and QA engineers, all of whom are ex-Microsoft.)

However, given its sheer power, I'm not too big a fan of releasing our work in the wild, because I believe in an old saying - "Along with great power, comes great responsibility." (As for this, it is merely temporary and controlled.)


(Oh I digress. I have a bad habit of digressing often, so my apologies. End of digression.)


I did however briefly hear about Microsoft scrambling to try and save its face by buying a little start-up whose founder (, and you too might find this funny,) not too long ago, one day, sat thinking for two hours (as to) how to build an attack path, and then realized that everyone has access to Active Directory! (Hilarious! - that video's here (2:10 onwards.))

Oh, by the way, I forgot to introduce myself. I'm the one who did a risk assessment of Microsoft Corporation's global Active Directory more than a decade ago and showed them...

 ...well, I'm not about to reveal what I showed them. They know it, and that's all that matters.

Oh, I'm also the one who amongst other things, wrote Microsoft's 400-page whitepaper on how to delegate privileged access in Active Directory, only about 10 years before the world had heard of Mimikatz or an Aorato.


Speaking of privileged access in Active Directory, as you probably know, that cool little recent DCSync feature of yours, would be rendered completely USELESS if the perpetrator didn't have sufficient rights to replicate secrets out of Active Directory.

Replicating Directory Changes All Extended Right on Domain root in Active Directory

And while that feature may wow some, to us it very simply boils down to this - if you already possess sufficient privilege to be able to replicate secrets out of Active Directory, you're already virtually God in that environment any way. But thank you nonetheless for showing the world just how easy it can be. (Actually its not that super easy too, so I respect your work.)

Interesting side note question - Do you think anyone in the world knows exactly who has the Get Replication Changes All extended right effectively granted to whom in any production Active Directory environment, wherein the domain root ACL has been changed even once? (I don't think so.)

Oh, and by the way, as you may well know, you can't generate a Kerberos Golden Ticket without having the NTLM hash for the krbtgt account, and if you don't have the Get-Replication-Changes-All extended right to request secrets from a DC, you can't have that hash until you can log on as an Admin on a Domain Controller, BUT, if you can log in as an Admin on a Domain Controller, buddy, its ALREADY GAME OVER RIGHT THERE!


So, why bother going a step or five forward (LSASS dump, hash extraction etc.), when its already game over! Just use the task scheduler to launch a cmd prompt as System, and you're playing God in no time ;-)


I mean, seriously, if you're telling me that its that easy for a perpetrator to be able to logon as Admin on a Domain Controller at hundreds or thousands of organizations worldwide, then I must say, the $400+ Billion Microsoft hasn't done enough to educate its customers about the importance of protecting its Domain Controllers, and probably ought to spend a petty $100 million to do so right away (because if that's that easy, forget ATA, nothing's going to be able to protect these organizations from getting 0wned in minutes.)


[Again, a (not so) small digression...


Active Directory / Cyber Security 101 for the World

If your Domain Controller has been compromised, you're DONE. Period.

Domain Controllers in a Data Center

From the AD Admin to the CEO, it's time to pack up, go home, and find another job, because believe you me, until you completely re-build the forest from scratch, he who knows what to do will have you for ETERNITY without needing any ticket, let alone a Golden Ticket, at all! (To whose who would like to see a demo of this, please let us know.)

Let me repeat that. If an unauthorized individual can login to a Domain Controller as Admin, you are done! D-O-N-E! 

Only ignorant organizations will continue to operate that Active Directory forest, because you'd be operating on a compromised foundation, and if you do, those who truly understand Active Directory security, will know (and could divulge) everything there is to know about you, tamper with anything, destroy anything at will etc. etc. And yes, even Microsoft's latest toy won't be able to stop them.

... end of digression.]



Mr. Delpy, if you'll allow me, I'd like to most respectfully paint a very simple picture for you, one wherein, one could possibly grow old and maybe even have grand-children, and yet not succeed with Mimikatz. For brevity, I'll keep it simple.

Consider a forest with one or more domains wherein -

1. Domain Controllers: All physically secured in data-centers, requiring triple-factor authentication to physically access. Interactive logon denied to everyone except an empty AD security group. Of course, fully patched (so no low-hanging fruit etc.), plus all default User Rights and Privilege assignments severely locked-down. Soldered USB drives and keyboards i.e. no chance of applying a keystroke logger or USB-anything. No 3rd party software of any kind on these machines. Etc. etc.

2. Get Replication Changes All Extended Right: Only granted to Domain Controllers.

3. Domain Admins: None. All responsibilities for Active Directory service and data management (i.e. account and group management) natively delegated in Active Directory. In fact, the Domain Admins group SID has been removed from across Active Directory by a simple execution of a baby of a tool called dsrevoke.

4. Active Directory Admins and Designated Workstations: Less than 5 AD admins, each one with alt accounts, and separate workstations for every day use and admin use. Admin use workstations are as secure as the DCs, and interactive and network logons only allowed to the designated admin. Soldered USB drives and keyboards i.e. no chance of applying a keystroke logger or USB-anything. No 3rd party software of any kind on these machines. Minimum 25-character passwords, changed frequently, never written or stored anywhere.

5. Active Directory Backups: Stored encrypted in a physical bank vault, physical access to which requires the CISO to escort you to them. Only the CISO can get into bank vault.

6. An Educated Active Directory Admin Team: These aren't you ordinary admins. They know NEVER to logon to any system they do not OWN and CONTROL. They're also bound by a simple policy - you logon to any other system and you will be instantly terminated. Besides, Group Policy prevents them from logging on anywhere else.

7. Zero Services Using Domain Admin Creds: Not a single service in the enterprise uses Domain Admin creds, because if you know how to do security, you know that nothing strictly requires running as Domain Admin.

8. No DCs in the Cloud: Yes, you heard it right. I don't care how iron-clad the SLA is, we're not putting a single DC in the cloud with any provider yet. Not just yet. (More on that in days to come.)

9. Microsoft ATA:  Microsoft ATA is NOT deployed just yet, because if you think about it, its still just some rudimentary technology acquired from a start-up, and rolled out in just months. Not sure how robust and reliable it is in code and its art to protect multi-$ Billion companies.

I could go on and on, but you get the drift. (BTW, if you want to make it harder, throw in 2-factor authentication, at least for all admin accounts at a minimum, and a bunch of other latest Band-aids, none of which can stop a knowledgeable perpetrator.)

In such an environment, you might be able to compromise a domain-joined machine, but you're likely not going to get anywhere close to getting Domain Admin type credentials, because a Domain Admin type account will NEVER logon to a system 0wned by an intruder, and the intruder will almost NEVER be able to logon to an admin workstation or on to a DC as admin. Period.

In such a situation, I doubt an intruder's going to have a field day harvesting or reusing credentials to gain administrative access to Active Directory. In all likelihood, he/she'd sit and wait, and wait and wait, and wait, and grow old, and still not get anywhere.

Disgruntled intruder not getting any success with Mimikatz :-(

Hmm. Not a fun day with Mimikatz anymore, is it :-( 

NOW, I'll be the first to admit that the environment described above is a rarity, but not an impossibility by any stretch. In fact, in time, the world will get there, and we already are there. For instance, our Active Directory environment is only about 50 times tighter than I have described above, so at least one such environment exists, and we operate it most easily. But in reality (, and 8,000+ organizations from 160+ countries have knocked at our doors, completely unsolicited of course, so) we know just how bad the situation is out there.

End of digression. Back on track...

Hmm. I wonder if there might be a way for an intruder to compromise a relatively more secure Active Directory environment, specifically, such as the one described above? Well, it doesn't seem very likely, at least not using credential theft based attack vectors, since no Active Directory admins seem to want to give the bad guys even a chance at getting them.




Duh!

But wait, if this is all about Active Directory Security, then it doesn't take a brilliant mind to figure out the following - hey let me actually look INTO Active Directory, and I mean it literally! Look INTO it! -

Inside Active Directory

Wow, now that I'm looking in, it is an ocean in there!

And since we're talking about security here, perhaps its worth looking at something called an Access Control List (ACL), you know, that little thing that protects each object in Active Directory, including every administrative account, administrative group, domain user account, domain computer account (and of course the domain controller's domain computer account), the domain root, AdminSDHolder, the System Container, the entire Configuration container, the Schema container, every GPO, etc. etc.-

Active Directory ACL on some random user, say an Alex Simon's domain user account.

Hmm. I wonder why nobody has looked INTO the Active Directory that much? And by that, I don't mean looking at basic kid-stuff enumeration of accounts, groups, GPOs, DCs etc. I mean looking a little deeper, and a little more intelligently.


You know, like trying to figure out who can actually reset a Domain Admin account's password, or who can change the Domain Admins group membership, or perhaps who can change the ACL on the AdminSDHolder object, etc. such as and/or ...

... speaking of say, Mimikatz, you know who can modify the ACL protecting the Domain root to grant someone or themselves the Get Replication Changes All extended right so they could replicate secrets (password hashes) out from Active Directory, or say, grant themselves Full Control over the entire Active Directory domain. (You see, intelligent and (very) powerful stuff.)

[Quick Digression -  

Now, a novice might say - "You don't need an effective permissions tool to assess REPL perms on NC." Well, if no one has ever changed the ACL on the NC head, and you're just dealing with default permissions, then its his lucky day and a simple group enumeration should do it, BUT, if the permissions on the NC head have changed even once, and there's even ONE deny permission there (e.g. Deny All extended rights to Group X), well, then tough luck, because if you really want an accurate picture, you're going to have to determine effective permissions on the NC head ;-)"

End of Digression]

Hmm. I wonder. Let me see. Well, to begin with, what could I figure out by looking into these ACLs?

Not much, other than exactly who has the keys to every door in the kingdom, and the Keys to the Kingdom of course!

Hmm. Wonder how I do it? Yes, I know! I could use a tool like dsacls from Microsoft or I could pick up several amateur scripts from TechNet which claim to help find out who has what permissions -

dsacls

But wait, I see all kinds of permissions :-( > Allow permissions, Deny permissions, Explicit permissions, Inherited permissions, over a dozen basic permissions, five dozen plus special permissions (Extended rights), Validated writes, permissions with IO flags, etc. etc.

Whoa! Where do I even begin?

And does "who has what permissions" even equal "who actually has what permissions"?

Well, maybe I should read Microsoft's bible on all this Active Directory permissions stuff, and perhaps in a year or so, get my head around all this, and could possibly get somewhere. Perhaps, that's when I'll realize that what matters is who has what effective permissions, not who has what permissions!

Oh wait, yes, I've seen an Effective Permissions Tab in Active Directory Users and Computers, but I never did give it much thought! Hmm, its one out of four tabs in there, so it must be important -

Why don't I just use that to figure out who can do what within the Active Directory?

Sure, go ahead ... ...consider an environment consisting of thousands of users and you'll know why it is almost virtually useless.

Oh, and if you come across this, RUN, because its dangerously inaccurate. Same is true for the advice on TechNet forums.

Well, perhaps, if I had something like this, I could actually answer that question accurately and quickly -

Then ask yourself a simple question - what if I wanted to find out who can create a user account in Active Directory? Hmm - would I even know where to begin? Hey, this Active Directory has 100s of OUs, 100s of containers, etc. etc. - how many objects am I going to have to analyze effective access on to answer this one simple question. It'll be 100s if not 1000s.

Again, you could try for a year, or be done in seconds ...

An Effective Privileged Access Audit in Active Directory

But, you should absolutely try it yourself first, so you can get a sense of just how monumentally difficult it is do so. I insist!

Years may go by, but you'll eventually gain the knowledge to comprehend the profoundness of this, this, this and this.

When you're there, please let me know, because then you too will have learnt how the (really) smart guys find ways to the Keys to the Kingdom, or to any door they want in to, in minutes, without having to wait for someone to logon to a machine you 0wn!


When you get there, please let me know...

 

... I'm already there.


Until then, I wish you well, and hope you continue to enjoy hashes and tickets! Oh, and if the intriguing world of Active Directory Security (which literally lies within every Active Directory) has piqued your curiosity, here's some recommended 101 reading.

Personally though, as a fellow programmer who too has spent 1000s of hours on an ocean of technical detail that most would never get into, my humble unsolicited advice to you would be to also enjoy life because there's a lot more to it than just work. You've already proven how incredibly smart you are, and made a big (enough) difference, so thank you also for helping make Windows more secure for the world.

Sir, for your valued contributions to the field of cyber security, you have my respect, and that of the world.

I most sincerely wish you well.

Thank you.

Best wishes,
ST aka TS.

PS: Some RESPECK for you in a simple ($100B) question posed to Alex Simons at Microsoft - here

PS 2: For those who may be new to the subject, and wish to share your thoughts on Twitter- here + Closure and Clarity - here

PS 3: For those who may not yet understand the depth of what I just shared above, you may want to take a shot at answering any 1 of the 10 simple questions concerning Active Directory Security that I've posed to Sean Metcalf and Microsoft - here

PS 4: October 21, 2016 Update - Defending Active Directory Against Cyber Attacks - here

PS 5: May 22 2017: Taking Microsoft to Active Directory Security School - here

PS 6: June 01, 2017: How Well Does Microsoft Really Understand Cyber Security - here

PS 7: July 25, 2017 Update: You'll want to read this because its paramount to security - Active Directory Effective Permissions