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

Folks,

Over the years, I've asked and answered some of the hardest questions in Active Directory Security, so today I'm only going to ask a question, with the hope that there is someone out there, and I mean anyone, who is the answer to this question!

Here's my Question -

Can Anyone in the World (i.e. any Cyber Security Company or Expert) Out There Help Thousands (1000s) of Microsoft's Organizational Customers Mitigate the Serious Cyber Security Risk Posed by Mimikatz DCSync?

Anyone?

There are 6,000,000,000+ people across 190+ countries worldwide, there are millions of IT personnel employed at 1000s of organizations, there are 1000s of cyber security experts and over a 1000 cyber security companies. I'm looking for just ONE.


By the way, by mitigate, I mean "render Mimikatz DCSync unusable in an AD environment" in that, say in an organization that had 10,000 employees and thus had 10,000 domain user accounts, and say 10 privileged users, even if every single one of these 10,000 accounts had been compromised by a perpetrator, he/she still couldn't use Mimikatz DCSync against their AD.

Also, I'm looking for an answer that's beyond the most obvious answer, which is to not grant anyone the required access. In other words, I'm looking for an answer that will work in every real, production Active Directory domain in the world, you know, wherein various default Active Directory security groups and users are already granted various permissions in Active Directory.


Here's what I've found thus far -

1. This brilliant, gentle, highly-accomplished cyber security expert developed Mimikatz DCSync
2. This AD security enthusiast educated the world about its usage, exploitation and detection (but not about its mitigation)
3. This famous cyber security expert showed an example in action (; Oh my! ;-))
4. This expert shared some guidance on how to detect it (; if you're detecting it, its likely too late)
5. These cyber security experts don't seem to know that much about it, or about Active Directory Security
6. These wonderful folks present an inaccurate script to help detect who can use Mimikatz DCSync

I could go on and on sharing the identities of so many who talk about it, but there isn't a single one who can help mitigate it :-(

Not to mention the 1000+ cyber security companies, including some big names such as (mentioned in no particular order) Palantir, Gemalto, Tanium, Tripwire, CheckPoint, Palo Alto Networks, Symantec, McAfee, Cisco, Kaspersky Labs, CrowdStrike, SentinelOne, BAE Systems, Qualys, Sophos, Gemalto, CyberArk, ZScaler, Preempt, BeyondTrust, Quest, HP, etc. etc.!

Oh, here's the amusing part - in all likelihood, most of these cyber security companies too very likely run on Active Directory, and if I had to guess, I don't think even one of them, know how to, or possess the means to mitigate Mimikatz DCSync!

Funny haan? ;-)


Why Does this Matter?

By now, I shouldn't have to tell anyone involved in Active Directory or cyber security why this matters, but I will nonetheless -

Most simply put, should a perpetrator be able to successfully run Mimikatz DCSync against your foundational Active Directory domain, you're DONE, as it would be tantamount to a massive, systemic cyber security breach. The entirety of your user populace's credentials would have been compromised, and the perpetrator would have obtained control over your entire Active Directory forever. It would be time for everyone, including all Domain Admins, the CISO, the CIO and the CEO to find another job (assuming you can find one, considering your resume would highlight your previous employment, and since your previous employer (i.e. the one that was breached) would likely have been all over the news for quite some time, it may perhaps end up being a little difficult to find suitable employment.)



How about an Illustrative Scenario?

Sure, if you'd like one, here you go -  A Massive Breach at a Company whilst it was Considering the Cloud.


A Request

We often come across Domain Admins, and every now and then CISOs, who have no idea what Mimikatz DCSync is, and that is scary. If you are such a Domain Admin / CISO, my earnest request to you would be to immediately learn about it, or, in the best interest of your employer's foundational cyber security, please let someone else take over your vital responsibilities.



Let Me Know

Very well then. If ANYONE in the world knows ANYONE who can help (and by that I mean  possesses the capability to be able to help) thousands of organizations worldwide (easily and correctly) MITIGATE the serious risk posed by Mimikatz DCSync, please let me know. I'm all ears, and I think, so are thousands of organizations worldwide, including perhaps Microsoft too ;-).

In short, I'm looking for someone/thing that could render the extremely powerful and dangerous Mimikatz DCSync, unusable. With 6 billion people, millions of IT and cyber security pros, and a 1000+ cyber security companies worldwide, I'm hopeful.

So if you know of someone (and I mean, anyone) who can do so, please let me know by leaving a comment below.

If I don't get an answer by July 02, perhaps I'll take a shot at the answer, over at - www.cyber-security-blog.com.

Best wishes,
Sanjay


PS: On an unrelated note, when you use Windows Update
       to update your Windows 10 PC every week, do you
       EVER check to see just what got downloaded?
       Perhaps you SHOULD, and here's why.



July 03 Update. Here's the answer > www.cyber-security-blog.com/2018/07/mimikatz-dcsync-mitigation.html

Some Interesting Figures from an Active Directory ACL Dump of Security Permissions from a default Windows Server 2016 Active Directory Domain

Folks,

I had only 2 minutes to blog today, so within the 2 minutes I had, I thought I'd generate, put together and share some interesting figures about the default Active Directory security permissions in a Windows Server 2016 based Active Directory domain.

It took a mere 3 seconds to do a domain-wide ACL dump of a Windows Server 2016 based Active Directory domain -

Active Directory Domain-wide ACL Dump

Domain-wide ACL Dump Download URL

You can download the entire actual domain-wide ACL dump from here.




Some Interesting Figures

Here are some interesting figures that took a minute to put together -

• Total number of object classes instantiated in domain partition: 40
• Total number of Active Directory objects in the domain: 242
• Total number of Active Directory ACLs (duh, obviously!): 242
• Total number of Active Directory security permissions (aka ACEs): 6677
• Total number of explicit Active Directory security permissions: 1323
• Total number of inherited Active Directory security permissions: 5354  
• Total number of inherit-only Active Directory security permissions: 3746
• Total number of unique security principals for whom permissions are specified: 27
• Total number of objects whose ACLs were marked "Protected" : 20


• Total number of Allow security permissions: 6677
• Total number of Deny security permissions: 0
• Total number of security permissions specified for Domain Admins: 246
• Total number of security permissions specified for Enterprise Admins: 230
• Total number of security permissions specified for Administrators: 231
• Total number of security permissions in the ACL of the AdminSDHolder object: 24
• Total number of security permissions in the ACL of the domain root objects: 53
• Total number of specific extended rights specified in these security permissions: 19
• Total number of attribute-specific write-property security permissions: 15

The exact security permissions can be viewed in the downloadable ACL dump (link provided above).



Unique Security Principals

Here's the list of the 27 unique security principals for whom security permissions are granted in the domain -

Pre-Windows 2000 Compatible Access Cloneable Domain Controllers Enterprise Read-only Domain Controllers Domain Controllers Key Admins Enterprise Key Admins Creator Owner Self Enterprise Domain Controllers Administrators Incoming Forest Trust Builders Authenticated Users Domain Admins Enterprise Admins

Everyone System Account Operators Print Operators Group Policy Creator Owners RAS and IAS Servers Domain Computers Network Service Cert Publishers Windows Authorization Access Group Terminal Server License Servers DnsAdmins DC1 (<domain computer account>)

The exact permissions granted to each one of these security principals can be viewed in the ACL dump (; link provided above).



Instantiated Object Classes

Here's the list of the 40 object classes, instances of which exist in the domain -

Domain-DNS Container Organizational-Unit Lost-And-Found Infrastructure-Update ms-DS-Quota-Container Rpc-Container File-Link-Tracking Link-Track-Volume-Table Link-Track-Object-Move-Table Domain-Policy Class-Store Group-Policy-Container NTFRS-Settings Dfs-Configuration Ipsec-Policy Ipsec-ISAKMP-Policy Ipsec-NFA Ipsec-Negotiation-Policy Ipsec-Filter

ms-DS-Password-Settings-Container ms-Imaging-PSPs TPM-InformationObjectsContainer User Builtin-Domain Group Foreign-Security-Principal Sam-Server Computer RID-Manager RID-Set ms-DFSR-GlobalSettings ms-DFSR-ReplicationGroup ms-DFSR-Content ms-DFSR-ContentSet ms-DFSR-Topology ms-DFSR-Member ms-DFSR-LocalSettings ms-DFSR-Subscriber ms-DFSR-Subscription

Each instance of these object classes, and their complete ACLs can also be viewed in the ACL dump (;link provided above).



Permission-Specific Breakdown

Finally, here's a breakdown of the number of security permissions of each Active Directory permission type -

• Number of security permissions (ACEs) granting Read Control (RC): 1977
• Number of security permissions (ACEs) granting List Child (LC): 2171
• Number of security permissions (ACEs) granting List Object (LO): 1968
• Number of security permissions (ACEs) granting Read Property (RP): 5704
• Number of security permissions (ACEs) granting Write Property (WP): 2072
• Number of security permissions (ACEs) granting Create Child (CC): 1001
• Number of security permissions (ACEs) granting Delete Child (DC): 779
• Number of security permissions (ACEs) granting Standard Delete (SD): 803
• Number of security permissions (ACEs) granting Delete Tree (DT): 586
• Number of security permissions (ACEs) granting Extended Right (CR): 1299
• Number of security permissions (ACEs) granting Validated Write (SW): 1389
• Number of security permissions (ACEs) granting Modify Permissions (WD): 978
• Number of security permissions (ACEs) granting Modify Owner (WD): 978

Finally, the exact ACEs that specify each one of these permissions can also be viewed in the ACL dump (;link provided above).



Detailed Security Permissions Analysis

Time permitting, you can analyze the entire ACL dump to perform detailed Active Directory security permissions analysis. Since the tooling splits the permissions field up into individual columns for permissions, it makes it very easy to analyze these ACLs.

For instance, you can easily find out exactly what security permissions are granted to a specific user or group, or find out exactly which users or groups are granted a specific Active Directory permission. You can also easily identify all inherit-only security permissions, as well as all Allow permissions, Deny permissions, Explicit permissions, Inherited permissions etc. etc.. I could go on with many more interesting facts/figures, but I'll stop here because my 2 minutes are up :-).

BTW, this is super easy and what we consider child's play (which is also why I didn't want to give this more than 2 minutes of my time.) Since it took just 3 seconds to dump these ACLs, I was happy to give it 2 minutes ; Oh, and we use our own tooling.

Alright then, my 2 minutes are up, so back to work.

Thanks,
Sanjay

Evidence Matters (, and We Have a Mountain of It)

Folks,

Earlier today, I had shared details of how we, by sheer chance, discovered that an untrusted (self-signed) purportedly Lenovo Kernel-mode device driver had been automatically downloaded and installed on a brand-new Microsoft Surface device.

The evidence is in, and lies on, that specific Microsoft Surface device itself, and we had quarantined that device the minute we made this discovery, to preserve the evidence, so that if needed, Microsoft's engineers could identify what caused this issue.

Speaking of evidence, as we know, in literally everything, evidence matters, because in it lies proof, and thus evidence prevails.

Thus and in fact, from day one, we've made sure that every single claim we have ever made, whether it be about an inaccuracy in a specific vendor's effective permissions tooling, or the lack of sufficient knowledge in the Domain Admin community, or the list of our marquee customers, or our global customer base, or our Microsoft testimonials, or the claims made in The Paramount Brief, or when we inform a specific organization's executive management team about deficiencies in their existing cyber security defenses, or our claim regarding our innovative products being unique in their ability to empower organizations worldwide to be able to audit effective privileged access in their Active Directory, is backed by concrete evidence, and a mountain of it at that.

You see, when you've spent 30,000 hours specializing on a single subject matter, you end up being the very best at what you do, and when you're the very best at what you do, unintended accomplishments come your way, and as they do, you not only end up standing tall upon a mountain of accomplishments, along the way, you also end up collecting, savoring and preserving every single trophy you've earned along the way, both small and big, which ultimately end up building a mountain of evidence.

So to anyone who wishes to take us on, please know that we stand tall and operate formidably, upon a mountain of evidence.

Best wishes,
Sanjay


PS: This message is certainly NOT directed at Microsoft.
       It is solely intended to convey the value of evidence.

Hello Again

Folks,

Hello again! I hope this finds you doing well. Wow, its been 6 months since I blogged, and I'm sorry for the unintended absence.

Perhaps I should introduce ourselves again ;-)

Hello World, We are ...

I should mention that I've been missing blogging, especially considering that I penned 60+ posts in 2017, so starting Monday, June 18, 2018, I'm going to get back to blogging, because its time to help safeguard Microsoft's global ecosystem.


Until then, perhaps I should share with you a bit of what's kept me away during the last 6 months -

• In January, one of the world's top technology companies, one that likely impacts hundreds of millions of computers worldwide, had requested our help in accurately identifying privileged access in their foundational Active Directory, and considering that they had 50,000+ objects in their domain, and the ACL of each object had a whopping 600+ ACEs, we had to enhance Gold Finger so it could efficiently take into account 30 million ACEs to determine effective permissions across their domain, so as Gold Finger's lead architect, I had to get involved to enhance it a bit.


• In February, one of the world's most important national defense forces had reached out to us with a rather unique requirement within which they wanted Gold Finger to operate, and since it potentially impacted that country's national security, as one of Gold Finger's lead programmers, I had to help lead the effort to help them out.


• During March and April, we finished work on Gold Finger Mini 6.0, the world's only cyber security tool that democratizes and delivers the power of real cyber intelligence by empowering 500 million+ people worldwide to find out for free exactly who can compromise their Active Directory credentials. It shipped on time, on May 01.


• In May, amongst others, one of the world's largest insurance companies joined our global family of customers by licensing Gold Finger 007, and I personally got involved to ensure that everything went off smoothly for them. In addition, one of America's top defense contractors had specially requested our assistance in helping them verify least-privileged access (LPA) in their foundational Active Directory, and I decided to get involved to help them out. 

I just realized that almost half the year's over, and I hadn't blogged anything yet, so I've decided to get back to blogging.

Very well then, onward to June 18, 2018.  Stay tuned!

Best wishes,
Sanjay