Security Blogs

Uncategorized

Letting the Secrets “Sync” In – DCSync Attack

In this blog, we’ll be focusing on abusing the Replication of Directory Services feature of an Active Directory environment. As always, we’ll first discuss the Directory Services Replication feature of Active Directory and then we’ll walkthrough both the theoretical and practical aspects of the abuse.

The DCSync Attack is listed as an Enterprise Credential Dumping technique on the MITRE ATT&CK Framework, bearing the ID 1003.006.

What is AD Replication?

In most of the cases, organizations need multiple Domain Controllers to manage AD Objects in the environment. To keep these multiple Domain Controllers in sync with each other Microsoft introduced the Directory Replication Service in Active Directory, which can be abused by attackers to get the password hashes of the users in the Active Directory.

Any Domain User with the following permissions set can request for replication of objects in the AD, including the NTLM hashes of the users, and eventually dump the NTDS.dit file from the DC:

CN: DS-Replication-Get-Changes (GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)

CN: DS-Replication-Get-Changes-All (GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)

CN: DS-Replication-Get-Changes-In-Filtered-Set (GUID: 89e95b76-444d-4c62-991a-0facbeda640c)

By default members of the Administrators, Domain Admins, Enterprise Admins groups and Computer Objects on the DC have AD Replication rights.

How the DCSync Attack Works?

The attacker first compromises a user and gets a foothold on a windows machine in the network, and discovers a Domain Controller in the specified domain name. He then discovers that the compromised user has replication rights. He requests the DC to replicate user credentials via GetNCChanges (leveraging the Directory Replication Service Remote Protocol). The attacker sends an IDL_DRSGetNCChanges request to the DC to replicate AD objects from the server NC (Naming Context) Replica to the client NC Replica. The response from the server contains the set of updates that the attacker has requested.

Attack Anatomy

Practical Demonstration of the Attack:

As usual following the Assumed Breach methodology, we have access to a user’s windows machine in an Active Directory environment. Enumerating the group memberships we find that our user is just another Domain User.

whoami /all

Just a regular Domain User

Using PowerView, we check if our user has permissions to replicate directory services or not

Get-ObjectACL -Identity "dc=dcell,dc=local"

Enumerating User Permissions

Since our user has Directory Services Replication privileges, we once again use Mimikatz to request and dump NTLM hashes from the Domain Controller.

lsadump::dcsync /domain:DCELL.local /user:krbtgt

Kerberos Service Account’s Hash Dumped

lsadump::dcsync /domain:DCELL.local /user:administrator

Administrator’s Hash Dumped

Alternatively, this can also be done using the Impacket-Toolkit’s secretsdump.py script.

python secretsdump.py dcell.local/dcell1:'U$er1123'@192.168.138.130

Impacket secretsdump.py dumping NTDS.dit

If an attacker has Domain Admin privileges, Directory Services Replication permissions can also be set with PowerView.ps1 with the following command:

Add-ObjectACL -PrincipalIdentity Attacker -Rights DCSync

Detection of the Attack:

Monitor Domain Controller logs for replication requests (Windows log event ID 4662), and network protocols for unknown IPs requesting AD replication.

Event Log 4662 Generated as a result of AD Object Replication

Defense against the Attack:

  • Ensure strong and complex password policies.
  • Apply ACLs for Replicating Directory Changes and other properties associated with AD Replication.
  • Ensure that user or admin domain accounts are not in the local administrator groups.
References:

Leave a Reply

Your email address will not be published. Required fields are marked *