Blog Post July 20, 2023

Unraveling Cyber Defense Model Secrets: DCSync Attacks

By: Joshua Beach, Detection Engineer and Andrew Chapin, Threat Researcher

Welcome to the Unraveling Cyber Defense Model Secrets series where we shine a light on Adlumin’s Data Science team and explore the team’s latest detections and learn how to navigate the cyberattack landscape.

DCSync Attacks are hard to protect and used often by cybercriminals who aim to takeover your network. In this blog, we’ll walk you through the methodology, detection and more, let’s begin:

Domain control is a common intermediate goal in many cyber attack scenarios including Advanced Persistent Threat (APT), Inside Threat, and Ransomware. Executing a Domain Controller Sync (DCSync) attack is a popular method for achieving domain control. Often reliant on the exploit tool Mimikatz, DCSync can also be performed with manual methods.

Methodology

A DCSync attack targets Windows Active Directory (AD).

In this type of attack, a threat actor targets a feature in AD called the domain controller (DC) which allows different parts of the network to share and synchronize data.

The domain controller is a high value target because it stores a secured database that contains sensitive information, such as user account records with usernames and password hashes.

During a DCSync attack, the threat actor attempts to trick the domain controller into sharing the user account information by utilizing the Directory Replication Service Remote (DRSR) protocol. This allows the threat actor to pretend to be another trusted domain controller that is part of the network.

A successful DCSync attack, allows an attacker to steal sensitive account records in the database. The attacker will then try to crack the password hashes and gain unauthorized access to user accounts (including to network admin or super-admin accounts) and gain more control over the network.

Detection

Adlumin has created a detection for DCSync Attacks that can recognize and alert on the methodology used by threat actors described above. This allows for quick mitigation and remediation for clients.

The starting point is to review Directory Replication Service Remote (DRSR) related logs found in the Windows security log. Specifically, events with ID 4662.

Then, logs are filtered to focus on entries where the requesting user possesses the necessary credentials to make domain requests. The logs are examined to identify any suspicious or unauthorized domain requests that may indicate a DCSync attack.

The challenge is to sift through benign activity in this subset of DRSR logs.

The DRSR protocol is primarily used within networks to provide redundancy for multiple domain controllers. Thus, DC to DC replication is considered normal, while DC to host replication is not.

Adlumin will flag any DCSync requests from non-DC hosts as potential malicious activity. A security team can then quickly identify and respond to any potential threats against the domain controllers running on the network.

Remediation View:

The Problem

The DCSync attack methodology takes advantage of the Directory Replication Service Remote (DRSR) protocol to obtain sensitive information from a domain controller. This functionality is not a bug, but rather is intended activity to provide user friendly redundancy in a multi-DC network.

This technique involves an adversary masquerading as a domain controller (DC) and convincing the authentic DC to synchronize its database to the new rogue DC by issuing a replication request. The results of a successful DCSync attack will provide the adversary with password hashes of the targeted users. In most cases, this will include all users.

The Algorithm

By using the associated logs resulting from actual DCSync attacks, Adlumin is able to filter on their defining characteristics to build detections. A few of these factors include user replication rights, if the requesting machine is a DC or not, and access rights. This rule-based detection scans every 6 hours for any new cases of this occurrence and will alert you for further investigation.

User Actions

When encountering an alert indicating a domain user attempting DCSync requests, the objective is to determine if the alert is an active threat or a false positive. But how?

Let’s remember that attackers rarely perform actions in isolation. Threat actors tend to chain together several steps. Therefore, we can check for other actions in tandem with the DCSync request.

Below is a list of items to check:

Verify User Account and Behavior

Verify authorized creation of the user account and if the DCSync behavior is normal for your network. This detection alerts on DCSync related behavior, but some organizations have been found to back up their domain controller data to non domain controllers. If this behavior is normal and accepted within your network, disregard this alert.

Domain Controller Syncing
Ensure that the host machine of the suspected DCSync attack is NOT a domain controller. Failure to identify it as such may result in a false positive. DCSync activity between Domain controllers is generally benign.

Enumeration of Permissions
The attacker will often check which accounts have the required permissions to perform the DCSync attack before performing the attack. Here is an example command:

Exploit Command
To perform the attack a program must be executed to make the request to the other domain controller. We can check process execution on the machine that was the origin of the attack and search for any suspicious process execution that occurred at the time of the DCSync attack.

Text BoxHere are some example commands:

Persistence
If the attacker has compromised a domain admin account, they may get the permissions required to perform the DCSync attack to another account.
Text BoxHere is an example command:

Network Traffic
The most effective way to discover and identify a DCSync attack is through network monitoring. Confirming whether the attack originated from a DC IP address on your network is much faster and less prone to false positives.

Here are some example Suricata signatures: