This is the latest in a series of posts we’re calling “QOMPLX Knowledge.” These posts are intended to provide basic information and insights about the attack activity and trends that are driving malicious campaigns and that QOMPLX researchers encounter in our forensic work with customers.
These days, privileged access to a domain controller is one strategic aim of any sophisticated cyber adversary. For such adversaries, DCSync attacks are a popular choice. DCSync facilitates access without the need to drop any code or log on to the controller, frustrating most means of detection and auditing. This particular attack technique has some limitations, but nonetheless, it’s one of the most devastating tools at an attacker’s disposal as they attempt to elevate privileges and move laterally on a compromised network.
- DCSync attacks allow an attacker to impersonate a domain controller and request password hashes from other domain controllers
- Only accounts that have certain replication permissions with Active Directory can be targeted and used in a DCSync attack.
- DCSync attacks enable an attacker to target a domain controller without having to log on to or place code on the controller.
- Monitoring network traffic, and controlling replication permissions, are the best strategies to combat DCSync attacks.
How the DCSync Attack Works
Domain controllers are a pillar of Active Directory environments; these servers house the Active Directory Domain Services databases and manage user authentication requests to services elsewhere on the domain. Attackers who gain privileged access to the domain controller jeopardize the trustworthiness of entire Active Directory forests. They would have the ability to modify Active Directory databases; access and compromise other Active Directory user accounts; and carry out further post-exploitation attacks.
Savvy, experienced attackers can create real havoc with this type of network access, rapidly moving to other servers and services on the network, where they can: drop malware including ransomware; exploit software vulnerabilities in un-patched systems; and take advantage of vulnerable configurations on other servers. These long-lived compromises often result in theft of sensitive data or intellectual property. Using ransomware, cyber criminal groups may also extort organizations desperate to regain control of their network operations.
Compromising Domain Controllers, the Easy Way
Developed and released in 2015, the DCSync attack radically simplifies access to an Active Directory domain controller by removing the requirement to compromise one. Instead, DCSync allows an attacker to use a single domain administrator credential (or even a domain user with sufficient privileges) to totally compromise an entire forest. DCSync allows that attacker to mimic a domain controller. Using the GetNCChanges request, the attacker prompts the primary Domain Controller to replicate user credentials back to the attacker using the Directory Replication Service (DRS) Remote Protocol.
Tools such as Mimikatz and Empire make it easy to launch DCSync attacks. For example, built-in features for Mimikatz and other tools allow attackers to imitate a domain controller and initiate the request. This relieves the attacker from dumping a Windows NTDS.DIT database file, a “red flag” action that would almost certainly trigger alerts from a network detection system such as a SIEM or IPS. DCSync attacks can be a prelude to Golden and Silver Ticket attacks.
Elements of a DCSync Attack
Here’s how a DCSync attack works:
- The initial foothold must be against a domain account with domain replication privileges; the Directory Replication Service Remote Protocol (MS-DRSR); MS-DRSR is a legitimate Active Directory service that cannot be disabled.
- By default these privileges are limited to the: domain administrators, enterprise administrators, administrators, and domain controller groups. However, in certain cases, ordinary domain owners may have the needed permissions to launch a DCSync attack.Those roles have replication permissions that include the following rights that enable a DCSync attack: Replicating Directory Changes, Replicating Directory Changes All, and Replicating Directory Changes In Filtered Set
- The attacker who compromised an account with adequate permissions would load Mimikatz and run the DCSync command from the lsadump module, specifying the targeted domain and user account—one example would be the KRBTGT account which is used to encrypt and sign Kerberos tickets within a domain. A domain controller would use this account to decrypt and validate those tickets, authenticating accounts to access network resources.
- The DCSync command in Mimikatz allows an attacker to pretend to be a domain controller and retrieve password hashes from other domain controllers, without executing any code on the target. It does so over the MS-DRSR protocol via the DSGetNCChanges method that replicates updates from a naming context (NC) replica on the server.
- In addition to the crucial NTLM password hash, earlier password hashes are also returned. An attacker who can compromise those, as well, may deduce patterns a particular user employs to set passwords and may be able to crack those offline.
- Those passwords may also be returned in cleartext through the use of the Powersploit tool, Microsoft PowerShell scripts that enable reverse encryption and allows an attacker access to the plaintext version of the secret.
With the KRBTGT NTLM password hash in hand (AES256, AES128 hashes also), an attacker can launch a Golden Ticket attack that allows an attacker to forge valid Kerberos Ticket Granting Tickets and access any resource on an Active Directory Domain.
Prevention, Detection, Mitigation of DCSync Attacks
Given that the DCSync attacks piggyback on legitimate and vital Windows services such as MS-DRSR, options for mitigating these attacks are limited. There are, however, several countermeasures that are effective against DCSync attacks:
Audit Domain Administrator and User Permissions
Preventing DCSync attacks demands an understanding of which accounts have domain replication permissions. With that knowledge, security staff should determine whether those rights should be revoked or limited on any of those accounts. Given that these privileges are standard for domain administrators and domain controllers, consider strictly limiting access to these groups while also strengthening authentication requirements for all group members to make offline password cracking more difficult.
Tighten Patching and Configuration Management
Ensure basic security hygiene practices are followed including patch and configuration management, endpoint detection and response, and user awareness training. Basic security hygiene is the most reliable way to protect accounts from external attackers or malicious insiders.
Enable Network Monitoring
Network monitoring is the best detection method. First, as pointed out by expert Sean Metcalf, all domain controller IP addresses should be identified and then added to the Replication Allow List. Once that occurs, administrators should configure intrusion detection systems to alert when DSGetNCChange requests originate outside that list of IPs.
Here are the previous entries in our QOMPLX Knowledge series; look for more in our QOMPLX Knowledge series in the days and weeks ahead:
Some other links to consider: