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