Preventing DCSync Attacks

DCSync attacks superficially sound simple and easy to defend against. What you will find, however, is that truly understanding and mitigating the root vulnerability of a DCSync attack is much more complicated. Most articles on this topic tell you to check for only three “ExtendedRights,” and you’re covered, but oh, how this is wrong. Maybe wrong is not the right word; it’s incomplete.

The reality is that an attacker can leverage many other weak ACEs on the domain’s ACL to perform a DCSync attack. If that sounds confusing, it’s because it is, and I want to demystify the root of DCSync attacks. At the same time, we will discuss how PowerShell and other tools can help discover where your own domain is vulnerable to DCSync and abuse of other access rights.

What is a DCSync Attack?

DCSync is a specific function performed by Microsoft’s Directory Replication Service (DRS) Remote Protocol within a domain. As the name implies, DCSync synchronizes Active Directory(AD) data between Domain Controllers. AD data includes anything within AD, such as usernames, groups, group membership, and, most importantly, NTLM password hashes. When more than one Domain Controller(DC) is in an environment, the DCs must sync changes to the AD data. DCSyncs are routine operations that happen many times per day.

In a DCSync attack, an attacker gains control over an AD Object(User account, computer, service account, etc.) with certain rights over the root Active Directory object, emulates being a DC, and asks the real DC for a copy of the AD data. This is possible only because the attacker has already compromised an AD object with certain AD rights.

So, then, what are AD Rights, and how do we audit for AD objects that pose a risk?
To find AD objects that may pose a risk, we first need to understand the Access Control List for the Active Directory Domain.

Section Key Terms
Active Directory Object - An AD Object can be a User, Computer, Service Account, Group, Organization Unit(OU), or one of many types. Each object contains a list of object attributes.  

AD Object Attributes - Object Attributes define what the object is and other data about the object. For example, the AD object attributes for the User account "Bob", has an "objectClass" of "User", "SamAccountName" of "Bob", "displayName" of "Bobby.M", etc..

Why Does This Matter?

You may wonder, “Why do I care if an attacker has my AD hashed passwords? The Attacker will still need to crack them, and we have a strong password policy.“

That is a real statement I have heard before btw…

If an Attacker can access hashed NTLM passwords from Active Directory, they can do the following attacks.

1. Pass-the-hash: In Windows environments, having the password hash is the same as having the password.
2. The Kerberos(KRBTGT) account password hash in AD is used to forge Kerberos tickets, which is a golden or silver ticket attack.

In short, due to the way Microsoft authentication works, you can own the whole domain if you can perform a DCSync attack. Having password hashes is as good as having plain text passwords!

Active Directory Access Control List(ACL)

The root vulnerability of a DCSync attack comes down to the Active Directory Access Control List(AD ACL). The AD ACL controls what objects in AD have access rights over another object in AD. For example, an ACL states that the Domain Admin has the right to edit a user object within the domain.

Explaining how the AD ACL works is a topic that requires its own post. I broke off the AD ACL explanation into its own post to keep this blog post from being excessively long. You can read The Active Directory Access Control List Explained here.

[Insert montage of you learning about AD ACLs]

After reading The Active Directory Access Control List Explained post, let’s discuss what ACEs lead to a DCSync attack.

Section Key Terms
Access Control List(ACL) - A collection of Access Control Entries(ACE) applied to an object. Also known as a Discretionary Access Control List(DACL).

Access Control Entries(ACE) - An ACE defines another object's rights on the object the ACE is applied to and how the object's descendants inherit those rights.

DS-Replication-Get-Changes* ExtendedRights for DCSync Attack

Most articles on DCSync attacks discuss three special permissions that enable an Attacker to perform the DCSync attack. Let’s discuss the well-known DCSync permissions before we move on to the lesser-known DCSync attack pathways. Those special permissions(ExtendedRights) are…

• DS-Replication-Get-Changes, GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
• DS-Replication-Get-Changes-All, GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
• DS-Replication-Get-Changes-In-Filtered-Set, GUID: 89e95b76-444d-4c62-991a-0facbeda640c

I wrote this blog post because all other sources are unclear about which of these ExtendedRights are needed to perform the DCSync attack. Do I need a user account with all three rights or just one of them? So, when enumerating a domain, what must I confirm before launching the attack?

To answer this, I built the GOADv2 lab to test and confirm my theory. I found that the only combo that allows for a successful DCSync attack is having DS-Replication-Get-Changes and DS-Replication-Get-Changes-All rights. The DS-Replication-Get-Changes-In-Filtered-Set right is not needed.

This means an attacker needs to control an AD user account or computer that has the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All extended rights on the Active Directory root domain object. The Attacker can then use a tool like Mimikatz or “secretsdump.py” to gather all the user’s NTLM/LM password hashes.

By default, all Domain Controllers AD group members have all three DS-Replication-Get-Changes* rights.

DS-Replication-Get-Changes-In-Filtered-Set

So DS-Replication-Get-Changes-In-Filtered-Set is useless as an attacker? Yes, as it relates to gathering AD credentials through a DCSync attack, but it may not be completely useless.

If an Attacker has access to an AD account with DS-Replication-Get-Changes-In-Filtered-Set and DS-Replication-Get-Changes, they can perform a DirSync attack. A DirSync attack leverages these two ExtendedRights to read some sensitive AD account attributes, like a computer’s LAPS(ms-Mcs-AdmPwd) or the Unix password hash(unixUserPassword).

An Attacker can use a tool like Sharphound/Bloodhound to extract these AD attributes without much additional work. So we still need to audit for this extended right.

DCSync Attack with Other ExtendedRights

Many other rights provide an Attacker with enough access to perform a DCSync attack; not only DS-Replication-Get-Changes rights. We must also check for generic rights, like GenericAll and others. An attacker has many paths to obtain enough rights to perform a DCSync attack.

Let’s review some of the more common paths to DCSync attacks.

GenericAll

GenericAll is also known as complete control. An Attacker can use this right to manipulate or read anything in Active Directory. So, all those DS-Replication-Get-Changes* rights are included in the GenericAll right.

By default, members of the Enterprise Admins group have GenericAll rights over the domain.

AllExtendedRights

As the name implies, this right gives an AD object all ExtendedRights. The three DS-Replication-Get-Changes* rights are also ExtendedRights. Thus, an attacker will have all the necessary rights for a DCSync attack.

By default, members of the Domain Admins group or a member of the Domain Controller’s local Administrators group have AllExtendedRights over the domain.

WriteOwner

Object owners can modify object security descriptors regardless of the object’s Discretionary Access Control List(DACL) permissions. To abuse the WriteOwner right, an attacker can make themselves the owner of a highly privileged group like BUILTIN\Administrators, Domain Admins, or Enterprise Admins and add an account they control to one of these groups.

As discussed above, once an attacker has the rights inherited from a highly privileged group, they can perform a DCSync attack. While the WriteOwner right does not allow a DCSync attack directly, it is a stepping stone to one.

WriteDacl

The WriteDACL right allows users or groups to alter the AD Objects ACL. So, an entity with this right over the AD Object can modify or add permissions to the object. An attacker can abuse this right the same way as the WriteOwner permission.

Section Key Terms
Object Security Descriptors - Rights in Active Directory are defined by a security descriptors, which stores properties directly in the AD objects. 

Discretionary Access Control List - An Active Directory object's Discretionary Access Control List (DACL) is a security feature that specifies the access rights users or groups have to the object, using a list of Access Control Entries (ACEs) to grant or deny permissions.

Putting the Attack Together

Let’s put together what we have learned and apply it to an example. Below is an attack path taken from the GOADv2 lab that starts with a weak WriteOwner right and ends in a DCSync attack.

Let me explain how this attack path works.

1. An attacker gains control of the user account named Raider, which is a member of the DragonStone group.
2. The DragonStone group has WriteOwner permissions on the KingsGuard group. So, the Attacker sets the user Raider as the new owner of the KingsGuard group.
3. Now that Raider owns the KingsGuard group, he will add himself to the group.
4. Raider is now a member of the KingsGuard group, and as a member, Raider gains GenericAll rights over the user account Stannis.Baratheon. With the GenericAll rights, Raider will reset the password on the Stannis.Baratheon account to one he knows.
5. Raider now logs in as Stannis.Baratheon to gain all his rights.
6. As Stannis.Baratheon, the Attacker, will leverage his GenericAll rights on the computer KingsLanding and perform a Kerberos Resource-based Constrained Delegation attack. The Attacker will gain remote code execution on the computer KingsLanding.
7. The attacker is logged into the KingsLanding computer, which has DCSync rights on the SevenKingdoms.local domain.
8. The Attacker will now launch Mimikatz, running as the “SYSTEM” user of the KingsLanding computer, and then request a DCSync from the SevenKingdoms.local domain.
9. Boom! The Attacker has all your AD domain password hashes.

This attack path will work to take over the domain. However, I am simplifying a few steps to make them more digestible. For example, the Kerberos Resource-based Constrained Delegation attack step is complicated and not 100% guaranteed to work. The point is that weak ACL permissions in the right places will create a path for an attack to take over your domain.

Preventing DCSync Attacks: Audit High-Risk AD Groups

Preventing DCSync Attacks all comes down to auditing. No simple checkbox or GPO can fix this. As you may have inferred from this blog post, AD ACLs are complicated, and weak points are not obvious. However, a few audits will cover the most common pathways to a DCSync attack.

Preventing DCSync Attacks: Audit for Over-provisioned AD Accounts

Over-provisioned user AD accounts are one of the most common ways an Attacker gains enough rights to perform a DCSync attack; accounts with more rights than are required to perform their role. A basic user account can become a highly privileged AD group member through nested group membership. So, we should audit high-privileged AD groups for user accounts that should not be included.

The following groups are considered highly privileged and at high risk of abuse.

Not all of the above groups directly lead to a DCSync, but all should be treated as groups that are prone to abuse by attackers.

We will use PowerShell to recursively audit Active Directory group members of the high-risk groups to find all users that directly or indirectly have membership.

# Define the list of high-risk group names
$groupNames = @(
    "Domain Admins",
    "Enterprise Admins",
    "Administrators",
    "Schema Admins",
    "Backup Operators",
    "Account Operators",
    "Server Operators",
    "Domain Controllers",
    "Print Operators",
    "Replicator",
    "Enterprise Key Admins",
    "Key Admins"
)

# Initialize the ADAdmins array
$ADAdmins = @()

# Loop through each group and append its members to ADAdmins
# NOTE: The "-Recursive" flag. This is key to finding hidden accounts through nested groupings.
foreach ($groupName in $groupNames) {
    $ADAdmins += Get-ADGroupMember -Identity $groupName -Recursive -ErrorAction SilentlyContinue
}

# Output the list of user accounts with high-risk group membership.
$ADAdmins

You should have an output similar to the one below.

Preventing DCSync Attacks: Audit for DS-Replication-Get-Changes* Rights

You can use the PowerShell one-liner command below to audit the specific extended DS-Replication-Get-Changes* rights.

(Get-Acl "ad:\$((Get-ADDomain).DistinguishedName)").Access `
| ? {($_.ObjectType -eq "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" `
-or $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" `
-or $_.ObjectType -eq "89e95b76-444d-4c62-991a-0facbeda640c" ) }

This will give you a raw ACE output on the root domain object with one of the three DS-Replication-Get-Changes* extended rights. The “IdentityReference” is the user or group assigned the right. See the example below.

Don’t be alarmed if you have these rights on your domain. These rights are needed for legitimate purposes. We only need to ensure that the users and computers we expect are given these rights and no others.

Preventing DCSync Attacks: In-Depth Audit with Tools

We will need a tool to investigate and find weak AD ACL permission attack paths. I can recommend two tools for auditing the ACL of an Active Directory root domain object. Those tools are…

Bloodhound & SharpHound

Bloodhound analyzes and visualizes potential attack paths within AD, using graph theory to uncover complex relationships and vulnerabilities. SharpHound is the data collector that feeds Bloodhound with the necessary information from the AD environment, using methods like LDAP queries to gather data. Together, they help identify and mitigate security risks in AD setups, aiding both attackers in finding vulnerabilities and defenders in securing their networks.

The example attack path I showed above was created with the Bloodhound tool. Bloodhound is the best option for thoroughly auditing your domain for many different weak ACL attack paths. However, setting up and using Bloodhound and SharpHound can be difficult and time-consuming. For that reason, I also recommend…

AD-PowerAdmin: AD Access Rights Module

There are many scenarios in which BloodHound cannot be run in an environment. So, I built a PowerShell tool to audit for various Active Directory security vulnerabilities, including weak or high-risk ACEs on the root domain.

Below are some images of some of the weak ACE(single permission set from the ACL) that the AD-PowerAdmin AD Access Rights Module found in the GOADv2 lab.

You can download and install AD-PowerAdmin or import and use the AD Access Right audit module to find vulnerabilities. AD-PowerAdmin is 100% pure PowerShell, so you do not need to install anything else.

Wrapping-Up: Preventing DCSync Attacks TLDR

DCSync attacks are powerful and difficult to defend against. The key to defense is auditing for over-provisioned accounts or AD objects. With PowerShell, you can do some quick checks, but a thorough audit requires the assistance of a tool.

• Quick Audit with PowerShell
• In-Depth Audit with Tools

Do not just audit for the three obvious DS-Replication-Get-Changes* rights. Also, audit for the devilish defaults of built-in high-privilege groups, such as AllExtendedRights, GenericAll, and more.

Sources: Preventing DCSync Attacks

• GOADv2 lab – Huge help testing the attack methodology.
• MS-Wiki – DS-Replication-Get-Changes extended right
• Pentester’s Promiscuous Notebook: ACL Abuse
• HackTricks: Abusing Active Directory ACLs/ACEs
• Other sources listed in my other blog post: The Active Directory Access Control List Explained

Related posts:

AD Hardening Against Kerberos Golden Ticket Attack Client System Hardening Best Practices & Testing NIST Server Hardening Best Practices Operating System Hardening 101 Windows Client Hardening Linux Web Server Hardening: MAC with AppArmor Secure Windows Remote Management from 2FA Bypass Password Policy Best Practices in 2023 Building Custom Company-Specific Wordlists Defend KeePass Against CVE-2023-32784