Detecting DCSync
Understanding and Detecting MITRE T1003.006 - OS Credential Dumping: DCSync
Introduction
A common favorite “domain domination” technique for Black Lantern Security (BLS) operators during engagements is to perform a DCSync attack to obtain all the juicy credentials they can acquire. Because this technique generally flies under the radar of detection and logging capabilities at most organizations, the first question from the client during outbrief always seems to be, “How did you do it?” In an effort to aggregate many of the community resources, research, and shared experience and to demystify some of this technique’s nitty gritty technical details in a digestible manner for our clients, we have put together a brief write up.
Overview
The DCSync attack methodology takes advantage of the Directory Replication Service Remote (DRSR) protocol to obtain sensitive information from a domain controller.1 This technique involves an adversary masquerading their host as a domain controller (DC) and convincing the authentic DC to synchronize its database to the new rogue DC by issuing a replication request. This functionality is not a bug, but rather is intended activity to provide user friendly redundancy in a multi-DC network. The attack does require elevated privileges to complete. The user account used to perform the data replication request must have the ”replicating directory changes” privilege, which is commonly found associated with administrator and domain administrator credentials. 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.
Detection on the Wire
The security community’s current recommendation for detecting a DCSync attack is to implement a detection signature at the network layer (typically through an IDS/IPS application) to identify RPC/DCE traffic, which includes calls to the DRSUAPI RPC interface.2 Network layer detection has proven to be the most consistent and easiest way to detect this type of attack. The detection criteria can be further customized to have more granularity by specifically targeting traffic which includes the bit map that indicates calls to “IDL_DRSGetNCChanges”.
For this detection technique to be effective, it requires the network to be logically segmented so that the domain controllers are grouped on a common VLAN and separated from the rest of the network. It is important to note that replication activity, as mentioned above, is normal behavior in a Windows Active Directory environment. The recommended deployment configuration from Microsoft suggests including more than one DC for redundancy and load balancing purposes.3 As this is the advice given directly from the vendor, it is likely to be encountered in many corporate networks and all but guarantees ongoing replication activity. The fact that replication behavior is expected makes detection of “malicious” activity very challenging on a flat network. The sheer volume of alerts from a flat network will eventually cause alert fatigue and many times the results of an investigation will end up being legitimate activity. By implementing proper network segmentation, DRSR protocol activity is limited to the DC VLAN and detective measures can be put in place so that the IDS/IPS signatures only alert on attempts to replicate the DC database outside of the controlled DC segment. In this configuration, preventative controls may also be put in place as well to block DRSR traffic that is routed outside of the DC network segment.
Example Suricata signatures created by Didier Stevens research can be seen below.4
alert tcp !$DC_SERVERS any -> $DC_SERVERS any (msg:"Mimikatz DRSUAPI"; flow:established,to_server; content:"|05 00 0b|"; depth:3; content:"|35 42 51 e3 06 4b d1 11 ab 04 00 c0 4f c2 dc d2|"; depth:100; flowbits:set,drsuapi; flowbits:noalert; reference:url,blog.didierstevens.com; classtype:policy-violation; sid:1000001; rev:1;)
alert tcp !$DC_SERVERS any -> $DC_SERVERS any (msg:"Mimikatz DRSUAPI DsGetNCChanges Request"; flow:established,to_server; flowbits:isset,drsuapi; content:"|05 00 00|"; depth:3; content:"|00 03|"; offset:22 depth:2; reference:url,blog.didierstevens.com; classtype:policy-violation; sid:1000002; rev:1;)Note that both signatures are inspecting for traffic originating from any network segment that is NOT the DC segment and that includes calls to drsuapi through RPC/DCE traffic. The first signature is looking for a bind event, which is a required prerequisite to call individual functions from the DRSUAPI. The second alert is specifically targeting the flag associated with DsGetNCChanges requests. Both signatures have been tested and validated in a lab environment. Each will fire and alert when a DCSync attack is executed.
Detection Through Event Logs
Even though network detection is preferred, there will be environments that may not have the capability to detect this attack at the network layer. Fortunately, there is a means to detect this attack technique using standard Windows Event logs, which should accommodate those organizations that may have this technical limitation. The event log ID required to detect this attack is Event ID 4662, which is activated by enabling “Audit Directory Services Access” through Group Policy (Computer configurations > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit Directory Service Access > Enable Success).5 By configuring this setting, two new event IDs will be generated in the logs: 4661 and 4662. Each of these event IDs can be viewed in the Security log using the standard Event Viewer application. Both of these events are extremely generic and track access attempts to directory service objects. The 4662 event ID generated by DCSync activity is specifically targeting actions where, “An operation was performed on an object”. It is important to note that this event ID is not enabled by default and must be explicitly configured. Based on the Microsoft documentation, the decision to omit these events from default logging was based on the high volume of logs that can be generated. For example, event ID 4662 will be created for any access attempts to a directory service object in which a security access control list (SACL) has been assigned. 4662 events are also generated when access to the WMI namespace, MicrosoftVolumeEncryption, is referenced.6 When Bitlocker is enabled in the environment, this generates substantial log volumes and has been cause for many organizations to eventually disable the event after initial configuration. One final recommendation is to NOT enable failure auditing as these event logs are infamous for flooding log collectors in the 10+ million range when a single error occurs.
This event log correlation method, like the network detection method, also requires some prerequisite planning steps. For this method of detection to be efficient and to facilitate effective rule tuning, a strong baseline of legitimate replication activity should be identified.
Investigating Using a SIEM
From a SIEM alerting perspective, if the host names of the DCs are known and documented, their machine account names can be explicitly omitted from security event generation as that is expected behavior. Another way to limit the volume of logs from these events (at least from the SIEM perspective) is to implement a blocklist on the event forwarder so that only 4662 events of interest are captured and transferred to the centralized logging platform. This process and implementation will vary depending on both the log forwarder and the SIEM, and will require tailored research.
An example where the forwarder was tuned within the BLS Detection Lab is detailed below (Note: this is not specific to DCSync detection):7
The blacklist feature of the Splunk Universal Forwarder v6.1+ can be utilized to filter events. An additional line would need to be placed in Splunk_TA_windows\local\inputs.conf and pushed to the DCs.
[WinEventLog://Security] blacklist1=EventCode="4662" Message="Properties: [regex]”
There are three data fields of interest that should be correlated from the 4662 logs to identify possible DCSync activity.
SubjectUserName
AccessMask
Properties
For authentic replication activity the “SubjectUserName” should contain the name of the machine account of a domain controller or a variation of NT AUTHORITY/SYSTEM. This data field will need to be evaluated within the target environment that is being monitored. What is shown here is only an example. For this detection method, any logs that match the additional criteria listed below and include a regular user account in the “SubjectUserName” field, should be investigated further.
The “AccessMask” captured in the event log should be 0x100.8 This value represents “control access” and is specifically registered when access is allowed following extended rights verification (typically associated with the use of high level and explicit permissions that are required to initiate the DCSync attack).
The “Properties” field will include 2 pieces of relevant information to search for. The first is the starting string in the log example above, “%%7688”.9 This is another flag that is assigned and is associated with “Control access”. The second is the long string of characters at the end of that field, which are registered GUIDs that represent each of the RPC functions associated with the replication attempt. Through testing, the GUIDs of interest have been identified as one of three options when tracking DCSync activity.10 The 4th one listed below may also be associated, however, this has not yet been validated*.
{1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} - DS-Replication-Get-Changes
{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} - DS-Replication-Get-Changes-All
{9923a32a-3607-11d2-b9be-0000f87a36b2} - DS-Install-Replica 4.*{89e95b76-444d-4c62-991a-0facbeda640c} - DS-Replication-Get-Changes-In-Filtered-Set
It is important to note that within the community there is some disagreement with regard to the presence of the GUID versus the more generalized statement (“Replicating Directory Changes all”) that’s captured in these logs. At this time, it is recommended to enrich the detection criteria to search for either the GUIDs or the replication statement to capture all possible scenarios. While hunting client environments for this type of activity, BLS has found this string instead of the GUIDs above.
Benjamin Delpy (@gentilkiwi), the researcher who discovered and pioneered the DCSync attack technique, has also provided a few recommended Splunk queries to hunt for this activity.11 Some of his searches have been found to be a bit generic when utilized in larger corporate environments and may produce overwhelming results. However, one of the suggestions he makes that could prove useful in tuning efforts is to exclude events where the SubjectUserSID includes “AUTHORITE NT”. This may be something to consider should the other criteria above overwhelm the Logs/SIEM with large numbers of events.
Note: For those curious about the other GUID seen in the log example above, “{19195a5b-6da0-11d0-afd3-00c04fd930c9}”, this is associated with the RPC function: WRITE_DAC. Though this will be present in each of these event logs, it is not very helpful in detecting DCSync activity specifically. This is a standard access permission to modify discretionary access control lists in an object’s security descriptor.
After testing using the BLSOPS lab environment, we were able to efficiently detect this activity successfully using the explained log criteria.
Lab Sample Splunk Query:
index=main EventCode=4662 Access_Mask=0x100 AND (“Replicating Directory Changes all” OR “1131f6ad-9c07-11d1-f79f-00c04fc2dcd2” OR “1131f6aa-9c07-11d1-f79f-00c04fc2dcd2” OR “9923a32a-3607-11d2-b9be-0000f87a36b2”) | regex Account_Name!=”\w+$”
Note: The Splunk instance used during test, the “SubjectUserName” data from the log was parsed and indexed into “Account_Name.”.
gist.github.com/gentilkiwi/dcc132457408cf11ad2061340dcb53c2#file-dcsync-dcshadow-splunk
Notable References
https://www.siliconshecky.com/dcsync-where-the-heck-did-that-come-from/
http://themawofeternity.blogspot.com/2018/04/secretsdump-dcsync.html
https://www.praetorian.com/blog/active-directory-visualization-for-blue-teams-and-threat-hunters
http://pjhartlieb.blogspot.com/2011/10/one-mans-take-on-active-directory.html
https://blog.stealthbits.com/extracting-user-password-data-with-mimikatz-dcsync/