Goal

Detect artifacts related to DCSYNC operations in the network and how it's being used to credentials dumping

Categorization

These attempts are categorized as Credential Access using the DCSync Credential Dumping technique DCsync.

Strategy Abstract

The strategy will function as follows:

• Discovers Domain Controller in the specified domain name.
• Requests the Domain Controller replicate the user credentials via GetNCChanges (leveraging Directory Replication Service (DRS) Remote Protocol)

Technical Context

DCSYNC is a technique takes advantage of how domain controllers legitimately replicate domain objects. With the right permissions, it allows attackers to impersonate domain controllers and request the hashed credentials for any other users on the domain. It’s also a stealthy option; the attacker doesn’t need to run any malicious code on the domain controller and can selectively target the credentials of specific accounts.

When configured correctly, AD Domain Controllers will record Event IDs for group modifications. The following event IDs are of interest for this ADS:

Event ID	Event Name	Log Provider	Audit Category	Audit Subcategory	ATT&CK Data Source
4662	An operation was performed on an object	Microsoft-Windows-Security-Auditing	Directory Service Access	Audit Directory Service Access	Windows Event Logs

DCSync Permissions

The permissions needed vary based on domain functional level, explained in the DACL required on each directory partition:

Attribute Name	Attribute Value	Description
Access Mask	0x100	Control Access - “Access allowed only after extended rights checks supported by the object are performed. The right to perform an operation controlled by an extended access right.” - Microsoft Docs
Properties	1131f6aa-9c07-11d1-f79f-00c04fc2dcd2	DS-Replication-Get-Changes
Properties	1131f6ad-9c07-11d1-f79f-00c04fc2dcd2	Replicating Directory Changes All
Properties	89e95b76-444d-4c62-991a-0facbeda640c	Replicating Directory Changes In Filtered Set

By using HELK and Leveraging the Kibana query engine KQL using the above attributes, we used following Query to extract the informtion from the collected data:

(event_id:4662 AND NOT user_name.keyword:*$ AND object_operation_type:"Object Access" AND object_access_mask_requested:"0x100" AND object_properties:("*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*" OR "*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*" OR "*89e95b76-444d-4c62-991a-0facbeda640c*"))

The Kibana Results:

When expanding the kibana json log 1, inside of the Windows Event Security logs we found the Event ID 4662, showing this change.

We can tell by the Object Type, along with the Operation Type/Accesses and the user sql_svc:

Blind Spots and Assumptions

This strategy relies on the following assumptions:

• Group change event auditing is enabled by GPO.
• Group change events are written to the Windows Event Log.
• The DCs are correctly forwarding the group change events to WEF servers.
• WEF servers are correctly forwarding events to the SIEM.
• SIEM is successfully indexing group change events.

A blind spot will occur if any of the assumptions are violated. For instance, the following would not trip the alert:

• Windows event logging breaks.
• A group is modified in a manner which does not generate an event log.
• A legitimate account in a sensitive group is hijacked.
• A sensitive group is not correctly added to the monitoring list.

False Positives

There are several instances where false positives for this ADS could occur:

• Legitimate changes to the group are made as part of sanctioned systems administration activities.
• Automation scripts remove leavers from privileged groups.

Priority

The priority is set to high under the following conditions:

• A new user is added to a builtin Windows group.
• A new user is added to a Tier-0 administration group.

The priority is set to medium under the following conditions:

• A new user is added to a Tier-1 administration group.

The priority is set to low under the following conditions:

• The group modification event is a removal.

Validation

Enumerate members of the domain admins group

Validation can occur for this ADS by performing the following execution on a Windows host with RSAT installed:

powershell_execute 'Get-DomainGroupMember -Identity "svc_sql" |select  MemberName,MemberObjectClass'

Response

In the event that this alert fires, the following response procedures are recommended:

• Validate the group modified, user added and the user making the change.
  • If the user making the change is not an administrator at the appropriate permissions level, escalate to a security incident.
  • If the user added to the group is not a member of an administratively relevant team, escalate to a security incident.
  • If the user added to the group is a new account, escalate to a security incident.
• Validate there is a change management ticket or announcement for the change.
  • If there is no change management ticket or announcement, contact the user who made the change.
  • If the user is unaware of the activity, escalate to a security incident.

Additional Resources

• TBD