Secretsdump: DcSync

Been awhile since I wrote a post. But on forward. The following write up will be around trying to come up with a method for detecting dcsync.

My previous post was somewhat sporadic. In an attempt to introduce some structure to the writing, I wanted to loosely answer the questions outlined in Sergio Caltagirone's awesome article, Building Threat Hunting Strategies with the Diamond Model (source). 

What am I looking for?

I am looking for a user account performing dcsync operations

in the network. Typically you will see servers, particularly domain controllers, performing this

function thus observing a user account should raise some suspicion.

Why am I looking for it?

Dcsync , as explained by Sean Metcalf, “effectively “impersonates”

a Domain Controller and requests account password data from the

targeted Domain Controller.” (source) The combination of rights required to perform
this operation is replicating directory changes, replicating directory changes all, and replicating directory changes in a
filtered set (source). Simply put, if an attacker has compromised an account with the rights to dcsync, they could possibly gather
all NTLM hashes for your domain or just dcsync the KRBTGT hash, create a golden ticket and plunder.

How do I find it?

There are two methods in my experience, to identify this behavior.

Through network monitoring, if  your organization has internal Bro network sensors logging traffic to and from Domain Controllers, this Bro script can trigger an event whenever an IP not associated with a Domain Controller attempts the DRSGetNCChanges DCE-RPC operation. :

#loading smb is necessary at times

@load policy/protocols/smb

@load base/frameworks/notice

export {

       redef enum Notice::Type += {

               ## Indicates that a host was attempting a replication of the domain_controller.

               DCSync_attempt::Found

       };

#this is where you would place your domain controllers

const domain_controllers: set[addr] = {  

} &redef;

}

event dce_rpc_request(c: connection, fid: count, opnum: count, stub_len: count)

{ if ( c$id$orig_h in domain_controllers ) { return; } if ( c$dce_rpc?$operation && c$dce_rpc$operation == "DRSGetNCChanges" ) { NOTICE([$note=DCSync_attempt::Found, $msg=fmt("---- Replication from an unauthorized address ---"), $conn=c]); } }

Since I have not been able to test this script in a large enterprise environment :(, I cannot honestly relay
the signal to noise ratio.

With the help of the pentesting team I work with, we were able to identify that event code 4662, an operation was performed on an object, is triggered when a user attempts the DCSync operation. We will focus on the following key events to hopefully generate an accurate alert:

index=wineventlog sourcetype="WinEventLog:Security" EventCode=4662 Account_Name!="*\$" Access_Mask=0x100 Object_Type=domainDNS AND ("Replicating Directory Changes all"  OR “1131f6ad-9c07-11d1-f79f-00c04fc2dcd2” OR "{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}" ) | table _time Account_Name ComputerName Object_Server Object_Type Object_Name Accesses Access_Mask




You will first need to change the auditing policy in the Audit Directory Service Access subcategory in order to begin seeing logs forward to splunk. This event code generates a good amount of noise so before it is forwarded, you could specify that you only want any account name that does not end with a $, eg Account_Name!="*\$". This will ensure that you filter out hosts that perform this function, typically Active Directory servers that need to replicate this information. However as a warning, if an attacker performs this action with a computer account, the signature will not trigger on the event.

The properties field for this event code is where you will find some crucial information. As explained in microsoft documentation, “first part is the type of access that was used. This Typically has the same value as Accesses field.

Highlighted is the value "for which operation was performed." 

Second part is a tree of GUID values of Active Directory classes or property sets, for which operation was performed.”(source) In our case, the operation that was performed that we want to focus on is the replicating directory changes all. However I have seen at times that the GUID is not converted to its display name, so that’s why in our signature we specify both the display name and GUID. 

What do I do when the alert triggers?
The unfortunate thing for either detection method, is that it does not identify which credentials were transfered
from domain controller to host. However once someone has the rights to conduct this attack, you may need to
assume that the attacker is capable of acquiring the KRBTGT hash which should raise an alert. An analyst also must
determine whether this is a false positive or not. Has this account performed this operation in the past? What actions
are associated with this account prior to triggering this alert? Do you have a cloud-based Azure Active Directory
instance that synchronizes user passwords from an on-premise Active Directory instance via a service account?(source) Are there any other instances where an account would need to synchronize user passwords from one Active Directory server to another?
How often is this performed? Does this request from the account always originate from the same IP? Do you have a relationship with your sysadmins where you could ask about account activity and rights delegated? Hopefully these questions are a few you ask yourself when filtering
out false positives.  As a caveat, the Windows detection signature is fairly experimental. Though it has worked for me, I would highly recommend, as with any new detection, testing before deploying. 


References: http://www.activeresponse.org/building-threat-hunting-strategy-with-the-diamond-model/
https://adsecurity.org/?page_id=1821#LSADUMPDCSync
https://adsecurity.org/?p=1729
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662