How to CORRECTLY identify WHO can run DCSync against Active Directory

Folks,

Hello. Today, we'll share with you what the CORRECT procedure is for finding out who can successfully execute Mimikatz DCSync against your Active Directory, particularly because so many IT professionals errantly believe that they know how to accurately make this determination. 

As many know, Mimikatz DCSync is a hacking tool written by Benjamin Delpy that is often used by perpetrators to swiftly and substantially compromise organizations by letting them determine the passwords of all organizational AD accounts.

This is extremely important because DCSync is possibly the single biggest threat to all organizations operating on Active Directory, considering that even just a single successful enactment of DCSync instantly results in the compromise of the credentials of ALL domain user accounts, and thus, is in effect, tantamount to a colossal breach.

In fact, as recently shared by Microsoft Security, and I quote below, even LAPSUS$ i.e. DEV-0537 have been observed to use DCSync to substantially compromise several organizations, including most notably, Okta -

"The group compromised the servers running these applications to get the credentials of a privileged account or run in the context of the said account and dump credentials from there. The group used DCSync attacks and Mimikatz to perform privilege escalation routines. Once domain administrator access or its equivalent has been obtained, the group used the built-in ntdsutil utility to extract the AD database."

Now, it is very important to understand that LAPSUS$ were only able to successfully use DCSync because they were able to compromise an account that had sufficient ACCESS in their Active Directory domain so to be able to run DCSync.

In other words, if an account compromised by perpetrators does NOT have sufficient ACCESS to be able to successfully run DCSync, then the perpetrators will NOT actually be able to successfully run DCSync against Active Directory, so if we can correctly find out who has sufficient ACCESS to run DCSync against our Active Directory, we can lockdown all such exploitable access, minimizing the possibility of perpetrators being able to use DCSync against our Active Directory. 

The ACCESS required to DCSync

In order for organizations to be able to identity ALL accounts that possess sufficient ACCESS to be able to run DCSync, they first need to know exactly what ACCESS an account needs to to be able to run DCSync against Active Directory.

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

To be specific, to be able to successfully execute DCSync, an account needs to have both of these Active Directory extended rights be effectively granted in the ACL of the domain root object of an organization's Active Directory.

The Mistake 99% of IT Pros Make 

Now, it is at this point that we must take a moment's pause and understand something extremely important.

The operative word in the previous sentence is "effectively" granted, and therein lies the answer to this question.

You see, most IT professionals errantly assume that all they need to do is find out "Who has these permissions in Active Directory" and to do so all they need to do is use any Active Directory ACL/Permissions Analysis tool, or write a few lines of PowerShell script to find out which users and groups are granted these permissions, and that's it!

Unfortunately, any IT professional that makes the above assumption is very likely going to end up with an inaccurate list of accounts that can run DCSync because what needs to be determined here is not "Who has these permissions in Active Directory" but in fact "Who has these effective permissions in Active Directory?"

In short, it is not "who has what permissions in Active Directory" but in fact "who has what effective permissions in Active Directory" that determines who actually has sufficient privileged access so as to be able to run Mimikatz DCSync!

Further, and as such, "effective permissions" not only determines who can actually run DCSync against Active Directory, it actually determines exactly who has what privileged access to do just about anything and everything in Active Directory.

This subtle yet profound difference can be very easy to get wrong, and yet is extremely important to understand, because it determines whether or not the results of one's analysis are accurate or not, and as you know, when it comes to privileged access, there is absolutely no room for error and accuracy is paramount.

Consequently, while it is relatively easy to find out "Who has these permissions in Active Directory" using PowerShell or any ACL/Permissions Analysis tool, it is extremely and far more difficult, if not almost impossible, to accurately find out "Who has these effective permissions in Active Directory" using PowerShell or such tools.

   

Effective Permissions

In this section, we will understand why it is not "Who has what permissions in Active Directory" that we need to determine, but in fact "Who has what effective permissions in Active Directory" that we need to determine if we care about accuracy.

Once you have understood this, you will also understand why no AD ACL/Permissions Analysis tooling and/or any PowerShell script that one may have written, no matter how complicated, can actually provide accurate results.

Let us consider what we need to determine to make this paramount determination. 

In essence, what we need to determine is in light of ALL the security permissions specified in the ACL protecting the domain root object, exactly who has BOTH the "Get Replication Changes" and "Get Replication Changes All" extended right effectively allowed.

By "effectively" what we mean is the following - consider that a user John Doe is a member of two groups, Group X and Group Y. Further consider that in the ACL of the domain root, the following permissions exist for Group X and Group Y -

Deny   Group X   All Extended Rights

Allow   Group Y    Full Control 

Note - As you may know, each of the above is an ACE (access control entry) in an ACL (access control list), and each ACE either allows or denies either a generic or a a specific type of permission to a specific security principal.

Consequently, one might rightly assume that for starters we need to consider ALL ACEs in the ACL that specify either one of the following permissions - "Get Replication Changes" extended right, "Get Replication Changes All" extended right, All Extended Rights and Full Control.

Note: Some pros like to include the impact of being able to modify permissions on the ACL at this stage, but that is strictly speaking, an entirely separate entitlement/administrative task, which is why, strictly speaking, it need not be taken into account at this stage. 

Now, based on the above, most PowerShell scripts would be programmed to find all permissions that grant either of the above four rights, and that is indeed the correct way to BEGIN to approach this analysis.

However, it is at this point that not only most PowerShell scripts, but also all AD ACL/Permissions analysis tools, and even tools like Bloodhound, meet their match and start falling substantially short.

Let me explain -

Based solely on an ACL that has the above two permissions, virtually all PowerShell scripts and tools like Bloodhound, will enumerate both permissions but make either of the two following errors - 

1. Error 1 - They will errantly assume that since there is an ACE specifying the specified access for two groups, members of both these groups have the required access, at which point they will proceed to expand these group memberships and report that all the members of both these groups can in fact replicate secrets, whereas nothing could be further from the truth!


2.  Error 2 - A more refined script looking merely for Allow permissions will partially rightly determine that only members of Group Y have the required access, at which point it will proceed to expand this group's membership and report that all its members can in fact replicate secrets, which too would unfortunately be inaccurate.

Here's why both of the above will lead to inaccurate results - you see, what such PowerShell scripts and tools like Bloodhound ACTUALLY need to be doing is determining that Group Y is allowed the required access -AND- Group X is denied the required access so they need to be identifying members of both these groups, then performing conflict resolution, which involves correctly identifying any and all individuals that may be members of both these groups, and eliminating those individuals that are on both lists, from the final list, since the deny permission will have precedence over the allow permission!

NOW, in theory, and especially when you are considering merely two ACEs, as we have above, being able to perform this conflict resolution may seem simple, BUT in practice and reality, the ACL of the domain root could easily have hundreds of ACEs/permissions, any theoretically each one of them could be in play, i.e. could influence such access, and be either allow or deny, so for any PowerShell script or a tool like Bloodhound to be able to deliver accurate results, it would have to have the automated ability to be able to accurately perform conflict resolution involving hundreds of ACEs (/permissions.)

Further, in the illustrative example shared above, John Doe was directly a member of these two groups. 

In the real world, thousands of accounts could also indirectly, i.e. via nested group memberships, some of which may be deeply nested, and others may possibly also be circularly nested, be members of hundreds of domain security groups for which permissions may be specified in the domain root's ACL, and the PowerShell script or a tool like Bloodhound will need to have the ability to be able to process even such substantial complexity with 100% accuracy.

In addition, theoretically speaking, Active Directory security permissions could also be specified for one or more well-known RIDs as well as well-known security principals, such as Domain Users, Authenticated Users, Everyone, etc. and so PowerShell scripts and tools like Bloodhound will also need to be able to accurately evaluate the impact of all such permissions on the resulting access.

Also, there are several other factors that influence the accurate determination of "who has what privileged access in Active Directory" and I'm not going to list them all out there.

Finally, the ACL on the domain root object is an exception in that it is possibly the only object (, other than those that have protected ACLs,) wherein there are no inherited permissions to deal with. In reality, 99% of objects in Active Directory also inherit hundreds of security permissions, and it is exponentially difficult to be able to accurately do conflict resolution when inherited permissions are also in play, because one has to be able to accurately determine resulting access in light of the precedence order involving both explicit and inherited allow and deny permissions.    

For anyone who wants to learn more, a more detailed explanation and example of just how difficult and complicated it is to accurately determine Active Directory Effective Permissions can be found here.

In short, it is extremely difficult, if not almost impossible, to write any amount of PowerShell that can take all of the above complexity into account and yet determine with 100% accuracy, exactly who has sufficient effective access so as to be able to enact a critical operation such as DCSync against Active Directory, or perform any one of over one hundred possible administrative tasks in Active Directory.

This is why it is almost impossible for any PowerShell script or a tool like Bloodhound to be able to accurately determine who can successfully execute DCSync against an organization's Active Directory.

An Actual, Step-by-Step Example

The best way to understand what I have shared above is for you to try it yourself in an Active Directory, and to facilitate exactly that, we have made available a real-world like lab AD of a fictional company in a free VM.

You can follow an entire step-by-step example of how to correctly identify who can run DCSync against Active Directory right here.

Your PowerShell Script is Woefully Inadequate

Once you've had an opportunity to understand the technical nuances I've shared above and follow the step-by-step example I've provided above, you'll know for yourself that it is extremely difficult, if not impossible, to find out exactly who can do what in Active Directory using PowerShell.

Specifically, there are over a dozen factors one needs to take into account, with 100% precision, and zero room for error, and no amount of PowerShell, even written by the world's best Active Directory Security practioners can make this paramount determination accurately.

The same is true of all well-intentioned but woefully deficient amateur tools like Bloodhound, which self-admittedly do not even take deny permissions into account. The sheer fact that they do not take one of the most important factors in the entire process into account renders them virtually useless from a professional standpoint.

Of course, if you don't care about accuracy, then by all means, even basic tools like acldiag can help you get "a list."  Of course, since you don't care about accuracy, you likely won't care about whether or not that list is accurate.

Click, Done

There is one and only way to accurately make these paramount determinations in Active Directory, and that is by accurately determining Active Directory Effective Permissions.

There is also one and only on solution in the whole world that can accurately determine effective permissions in Active Directory and that is our Microsoft-endorsed Gold Finger solution. Fortunately, to help everyone make this paramount determination for FREE, a subset of its unique capabilities are now also available in Gold Finger Mini.

Gold Finger Mini

The most important report in Gold Finger Mini is - "Who can replicate secrets (i.e. password hashes)) from the domain?" and that one report can instantly and accurately determine "Active Directory Effective Permissions" on the domain root and reveal exactly how many accounts possess sufficient access to be able to run DCSync against your Active Directory, and who they are.

The basic version of Gold Finger Mini is free, and it can help every organization instantly find out exactly how many accounts can successfully run DCSync against their Active Directory today.

Gold Finger Mini can be instantly download, and installed in under two-minutes, and at the click of a button, reveal this information, for free, using any domain user account. It is a 100% read-only tool and does not require any admin access.

In light of what Microsoft shared about LAPSUS$, if I were the CISO, an IT Manager, a Domain Admin, or an IT Auditor at an organization, I would not want to sleep without having determined how many accounts possess sufficient privileged access so as to be able to run DCSync against our Active Directory today. After all, what else could be more important?

 

 

Conclusion

The objective of today's post was to help everyone realize that trying to accurately find out can successfully execute DCSync against your Active Directory is not as easy as it may seem, and neither amateur tools like Bloodhound nor PowerShell scripting can accurately take all the factors involved in this determination.

As the breaches at Okta and Microsot by LAPSUS$ have shown the entire world, 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.

Consequently, all organizations that operate on Microsoft Active Directory today, must know at all times, exactly which accounts possess sufficient ACCESS to be able to run DCSync against their Active Directory, because having this paramount insight can help them ensure that ALL such accounts are on their radar and sufficiently protected.

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, and exactly who can run DCSync against their foundational Active Directory -

👉   Gold Finger Mini - Advanced Level - Report #1 - "Who can replicate secrets from the domain?"

I'll leave you with this thought - if your organization doesn't even know exactly which accounts can execute DCSync against your Active Directory, how can it be safe from a cyber security perspective, and what does it really know?


That's all for now.

Best wishes,
Sanjay.

The $ 25,000 Gold Finger Mini Challenge

Folks,

I hope this finds you doing well. Today, we are announcing our second global Gold Finger Mini Challenge for US $ 25,000.

The $ 25,000 Gold Finger Mini Challenge

We are excited to announce an award of US $ 25,000/- to the first individual who can identify any solution in the world, other than Gold Finger, that can demonstrably do what the Advanced level of Gold Finger Mini can. Details below -

Here are the Top 7 Active Directory Privileged Access Audit that the Advanced level of Gold Finger Mini can provide -   

1. Who can replicate secrets (password hashes) from an Active Directory domain? 
2. Who can reset the password of an Active Directory domain user's account?
3. Who can disable the use of Smartcards on an Active Directory account?
4. Who can change an Active Directory security group's membership?
5. Who can change security permissions on an Active Directory OU?
6. Who can link a group policy (GPO) to an Active Directory OU?
7. Who can create an Active Directory user account in an OU? 

The need to know exactly who can enact these privileged tasks is absolutely paramount.

Paramount Privileged Access Insights

The unauthorized, accidental or coerced enactment of virtually all administrative tasks listed above could instantly result in a colossal breach far greater (damaging) in impact than even the recent SolarWinds Hack.

Consider this -

1. Anyone who could replicate secrets from Active Directory, effortlessly enactable via the use of Mimikatz DCSync, could instantly compromise the credentials of all (thousands) of organizational domain user accounts resulting in a colossal breach bigger than the Solar Winds Hack.


2. Anyone who could reset the password of a domain user account would in effect have instantly compromised the identity of that account, such as that of a C-Level Executive, a Software Developer etc. He/she could then login as that account and instantly obtain access to everything that account has access to. If the target were an Active Directory privileged user account, it would be tantamount to a colossal, system-wide breach.


3. Anyone who could disable the use of Smartcards for interactive logon, would in effect have downgraded security on that account, forcing authentication to being password based, and a simple password reset of that domain user account could be used to instantly compromise it.


4. Anyone who could change the membership of a domain security group could instantly obtain domain-wide access to all IT resources that the compromised group has access to, such as All Employees, Source-Code Access, Accounting, Cloud Global Admins etc. If the target were an Active Directory privileged group, such as Domain Admins, it would be tantamount to a colossal, system-wide breach.


5. Anyone who could modify the security permissions on an Active Directory OU could easily gain privileged access on all Active Directory objects e.g. user accounts, computers, security groups, service connection points etc. that reside in that OU. In numerous ways, this could easily be used to elevate/escalate privilege and gain Domain Admin equivalent access, resulting in a colossal breach.


6. Anyone who could link a GPO to an Active Directory OU could instantly control the security of all computers whose domain computer accounts reside in that OU. This could be used to easily circumvent all endpoint-protection controls, deliver malicious payloads or instantly unleash malware on thousands of domain-joined computers.


7. Anyone who could create a domain user account in Active Directory could then use that account to engage in nefarious activities that couldn't be traced back to a uniquely identifiable individual, thereby enabling the perpetrator to evade accountability while engaging in nefarious recon or attack activities.  

Consequently, the need to know exactly who can enact these administrative tasks in an organization's foundational Active Directory deployment is absolutely paramount to organizational cyber security today. 

The $ 25,000 Challenge

Our challenge is simple. All you need to do is -

1. Try the Advanced level of Gold Finger Mini, downloadable from here, to experience its unique capabilities.
   
   
2. Identify any solution in the world, other than Gold Finger, that you believe can do what Gold Finger Mini can.
   
   Specifically - Identify any solution in the world that can accurately deliver the 7 paramount insights listed above.
   
   
3. Compare and verify the results of the identified solution with Gold Finger Mini's results in the same AD domain. For your convenience, a ready to use lab AD domain with Gold Finger Mini pre-installed, can be downloaded from here.

If you believe you have found a solution, email its name to us at challenge[@]paramountdefenses.com. If you don't find a solution, but wish to be eligible for our next challenge (see below), email us and let us know that you didn't find a solution.  

List of Popular Active Directory Security Solutions

To help make it easy for you to find other solutions that you could compare Gold Finger Mini with, here is a list of various Active Directory Security Solutions available today, listed in alphabetical order -

1. Acldiag (Microsoft)
2. Aclight (CyberArk)
3. Active Directory ACL Analyzer* (Paramount Defenses)
4. Active Directory ACL Exporter* (Paramount Defenses)
5. Active Directory Effective Permissions Calculator* (Paramount Defenses)
6. Active Directory Effective Access Auditor* (Paramount Defenses)
7. Active Directory Membership Auditor* (Paramount Defenses)
8. Active Directory Permissions Analyzer* (Paramount Defenses)
9. Active Directory Permissions Reporting Tool (ManageEngine)
10. Active Directory Privileged Access Auditor* (Paramount Defenses)


11. Active Directory Security Auditor* (Paramount Defenses)
12. AD ACL Scanner (Robin Granberg ?)
13. AD Permissions Reporter (CJWDev)
14. AD Secure (Attivo Networks)
15. AD Assessor (Attivo Networks)
16. Alsid for AD (Alsid)
17. BeyondTrust Auditor (BeyondTrust)
18. Bloodhound (SpectreOps)
19. CrowdStrike Falcon Identity Protection (CrowdStrike)
20. Dsacls (Microsoft)


21. Directory Service Protector (Semperis)
22. Effective Permissions Reporting Tool (Netwrix)
23. Enterprise Reporter for Active Directory (Quest)
24. Hyena (Systemtools)
25. LepideAuditor (Lepide)
26. Permissions Analyzer for Active Directory (SolarWinds)
27. Ping Castle (Ping Castle)
28. PowerShell for Active Directory (Microsoft)
29. Purple Knight (Semperis)
30. StealthAUDIT Active Directory Permissions Analyzer (Stealthbits)

• * These tools are a part of the Gold Finger Suite and are thus not eligible for consideration

If there are any tools that are not on this list but should be, simply leave a comment below, and we will add them to the list.

Submission Deadline

The deadline for submitting an entry for our second challenge is May 16, 2021 i.e. all entries received by 23:59:59 U.S. PST on May 16, 2021 will be eligible for participation. The winner will be announced on May 20, 2021 on this blog.

The timestamp at which your email is received will determine the order of submissions. The first submission that identifies a solution other than Gold Finger, that can accurately do what Gold Finger Mini can i.e. deliver the 7 paramount insights listed above, will be the winner. If no submission is able to demonstrably identify such a solution, there will be no winner.

The Next Challenge

We will be issue our next challenge on May 21, 2021. The reward for the next challenge will be US $ 50,000/-.

However, only those individuals who participate in this challenge will be eligible to participate in the next challenge.  

Summary

Almost all major breaches in the last decade, including the SolarWinds Hack, involved the compromise and misuse of just one Active Directory privileged user account. Of note, the SolarWinds hackers only targeted Active Directory environments.

The objective of this challenge is to help organizations as well as IT and cyber security personnel worldwide become aware of the paramount importance of knowing exactly who has what privileged access in Active Directory, and to help organizations realize just how substantially inadequate their existing Active Directory audit toolsets are today.

We hope that this will be an educational challenge for all IT and cyber security professionals worldwide, and we look forward to hearing from everyone who understands the paramount importance of Active Directory Security.

Thank you.

Kindest regards,

Sanjay Tandon.

Chairman and CEO,

Paramount Defenses

Your participation is subject to the Terms of Use of our website and our Privacy Policy.

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.