Hunting for malicious DCSync operations

Assuming you have acquired domain admin credentials and now you are trying to either

1. Get hold of the NTLM hashes of the rest of the users in the AD or 

2. To specifically acquire NTLM hash of krbtgt user in order to create a golden ticket

There are several ways to do that:

1. You can get hold of ntds.dit file and the SYSTEM reg hive under system32 folder and then use these to extract the hashes from the ntds.dit file. There are several ways to do this as well. 

2. OR find out which AD objects have been granted the DS-Get-Replication-Changes and DS-Get-Replication-Changes-All ExtendedRights on the Domain-DNS, Configuration, and Schema (Schema) objects. This can be done by the following script and then use DCSync method in mimikatz or Empire and other tools to get hold of the NTLM hashes of the AD users. 

https://gallery.technet.microsoft.com/scriptcenter/Get-DCSyncRights-0e2ebbfe

Let us run the script to find out which objects have this right:

Seems like only Builtin Administrators group has the right:

Let us add the compromised domain admin user “Faisal” to “qureshi.com\builtin administrators” group:

Hunt Artifact: By the way you can hunt for EventID 4732 or EventID 4728 for users added to security groups:

Now let us invoke dcsync from mimikatz and get the NTLM hashes:

Do a gpupdate /force on the pivot machine in order to get the group membership updated:

Running cmd.exe as the qureshi\faisal user who has the rights to perform dc replication:

Using dcsync module of mimikatz to get hashes

Pivot System (Compromised System) Side:

No hunting artifacts found

On the Domain Controller:

We can see event ID 4662 (an operation was performed on an object) generated. We can also see the Security ID of the account QURESHI\faisal, which is performing the sync operation and the object on which the operation was performed can also be seen under Object Name (DC=Qureshi, DC=com). 

Hunting Artifact: It is possible to hunt for DCsyc by searching for this event 4662 on Domain Controllers whereby the account, which is performing the sync operation, is unexpected and not the computer account of other domain controller(s).

On the network:

Another way to discover DCsync is by hunting for IDS alerts using following rules (Ref: https://blog.didierstevens.com/2017/10/08/quickpost-mimikatz-dcsync-detection/) , which simply looks for workstations other than domain controllers from where dc sync request is originating:

Hunting Artifacts:

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;)