DCSync Attack & Defense
What is a DCSync Attack?
Imagine you have a big filing cabinet at home with all your secrets (like passwords). Normally, only trusted people (like yourself) can open it. In a company network using Active Directory (AD), this "filing cabinet" is the Domain Controller (DC), a special computer that stores all user passwords and account info. The DCs talk to each other to keep their info the same—this is called replication.
A DCSync attack tricks one DC into thinking the attacker is another DC asking for a copy of the secrets (password hashes). The attacker doesn’t break in with a crowbar; they use a key that’s already part of the system—special permissions meant for replication. They use a tool called Mimikatz to pretend they’re a DC and ask for the data. Once they have it, they can use those secrets to unlock more doors—like pretending to be any user or even the “master key” (krbtgt) to make fake logins (Golden Tickets).
How Does the Attack Happen?
The Attacker Needs a Special Key:
They need an account with permissions to ask for replication data. These permissions are called
DS-Replication-Get-ChangesandDS-Replication-Get-Changes-All.By default, only big bosses like Domain Admins, Enterprise Admins, Administrators, and the DCs themselves have these keys.
An attacker might steal one of these accounts (e.g., by guessing a weak password) or trick the system into giving their account these permissions.
They Use Mimikatz:
Mimikatz is like a hacker’s Swiss Army knife. The attacker runs a command like:
This tells the DC, “Hey, I’m a friend, send me the Administrator’s password hash.”
The DC Falls for It:
The DC checks if the account has the right permissions. If yes, it sends the password data over the network using a normal process (RPC, or Remote Procedure Call).
This looks like regular DC-to-DC chatter, so it’s sneaky.
What They Get:
Password hashes (NTLM hashes) they can crack to get the actual password.
The krbtgt hash, which is like a master key to make fake login tickets.
Prerequisites
Before we begin, ensure your home lab meets these requirements:
Domain Controller (DC): A Windows Server configured as an AD domain controller (e.g., lab.local).
Client Machine: A Windows client joined to the domain.
Kali Linux Machine
Ubuntu Machine (Elasticsearch & Kibana)
We need to create two user accounts: one as an administrator account, which will serve as the target for extracting its NTLM hash, and another with the necessary privileges to carry out the attack on the administrator account.
We will create an account named testadmin and assign it to the Domain Admins group.
Let's assign the password "P@ssw0rd!" to this account.
Next, we will add it to the Domain Admins group.
Let's verify whether this account has been added to the Domain Admins group.
Next, we need to create a custom user with replication privileges.
We will assign the password "P@ssw0rd2!" to this account.
We need to give it the required privilege also so we can complete the attack:
Next, right-click on the domain name, select Properties, and navigate to the Security tab.
We need to assign the necessary privileges to the previously created syncuser to ensure proper access.
We also need to enable auditing for Directory Service Access.
The Attack - DCSync
Log in to the Windows machine using any regular account and initiate a new session for the SyncUser account. This attack can be executed from either a Kali Linux system or the Windows machine. In this post, we will explore both approaches.
We have initiated a new session for the user SyncUser. Now, let's execute Mimikatz to determine if we can extract any valuable information.
We can observe that the user syncuser extracted the NTLM hash of the Administrator account due to the privileges assigned to them.
Let's attempt the same attack again, this time using a Kali Linux machine.
We have successfully retrieved all account hashes from the domain by leveraging the credentials of the SyncUser account.
Defending Against DCSync Attacks
Detecting DCSync activity is straightforward, as each domain controller replication triggers an event with ID 4662. By monitoring this event and verifying whether the initiating account belongs to a domain controller, abnormal replication requests can be identified promptly.
Let's filter for Event ID 4662 in Event Viewer to analyze the details of the activity.
Active Directory replication is a standard process between Domain Controllers (DCs). Certain legitimate services, such as Azure AD Connect, continuously synchronize password hashes with Azure. Generating alerts for every replication request would result in an excessive number of false positives.
To ensure we're only detecting malicious DCSync activity, we apply some filtering techniques.
There are two important GUID properties that appear in Event ID 4662 when a DCSync attack happens:
1131f6aa-9c07-11d1-f79f-00c04fc2dcd2→ DS-Replication-Get-Changes1131f6ad-9c07-11d1-f79f-00c04fc2dcd2→ DS-Replication-Get-Changes-All
These GUIDs indicate that someone is requesting sensitive directory replication data.
Now, we need to create a detection rule for this attack while minimizing false positives. To achieve this, the alert should only trigger when replication requests originate from non-domain controller (non-DC) systems.
Let's conduct our investigation by filtering for Event ID 4662.
We need to create a rule based on the username, access mask, and data properties.
Access Mask: 0x100 → This is a hexadecimal value that translates to a specific type of access right—in this case, Control Access.
In AD, “Control Access” is a special permission that lets someone do advanced things—like replication. The DCSync attack uses replication permissions (Replicating Directory Changes and Replicating Directory Changes All), and these permissions are tied to “Control Access.” When someone runs DCSync (e.g., SyncUser), it triggers an Event ID 4662 with AccessMask set to 0x100.
I have two domain controller accounts, so we need to exclude them from the rule.
This rule means:
At each execution (every 1 minute), the rule analyzes data collected over the last 5 minutes (the look-back time).
For example, if the rule runs at 5:21 PM, it will check data from 5:16 PM to 5:21 PM. Then, at 5:22 PM, it will check data from 5:17 PM to 5:22 PM, and so forth.
Now, let's replicate the attack and verify whether any alerts have been triggered.
These rules are not the final production-ready versions. When deploying them in real-world environments, they need to be continuously tuned to minimize false positives as much as possible.
To remove permissions from non-admin users (SyncUser), we need to execute the following command:
Let's replicate the attack once more to determine whether the user SyncUser can still perform a DCSync attack.
Thank you for taking the time to read this write-up. I truly appreciate your time and attention.
Last updated
