How To Not Overlook Important Windows Event IDs During Threat Analysis and Learning About Mimikatz DCsync (AD Replication)

Edit: 6/8/23 (Corrections regarding ID 4719)

Today I’d like to share with you all my experience of unfortunately overlooking some important windows event IDs during log analysis. Also during this process I ended up learning about Mimikatz DCSync instances and how to spot them!

I realized I had been overlooking some important Windows Event IDs when searching for abnormalities and malicious activity within the windows event logs. So typically, when I search for malicious activity I search for the following win event logs:

• event 4625 for failed logons, event 104 & 1102 (deleted event logs, event 4663 (attempt made to access object, events 4728, 4732, 4735, and 4756 (for account being added to security groups, security group modification)

After scanning for these with zero hits I assumed things were good. Wrong. During an incident today, a company server was getting hit with lateral movement alerts, we’ll call it DOMAINX , turns out a Service account was triggering the EDR software with very minimal detailed automated analysis from the EDR side, so I downloaded EVTX logs , ran some powershell commands (chainsaw) and found the following events which have event IDs which are lesser known (to me at least xD) however can be just as dangerous:

1. Mimikatz DC Sync (Event 4662):

As you can see, we are getting the following hit “Active Directory Replication from Non Machine Account + Mimikatz DC Sync” with corresponding event ID 4662 (4662: An operation was performed on an object). Here is a great writeup on this very attack that I’d like to share with you, this is from threat researcher John Dwyer, check out his article on this here. John states in his article ,

“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 “$”)”

So looking at the event Details we can see this adds up:

2. Active Directory Replication from Non Machine Account (Event 4662)

This is directly related to the DCsync attack and even shares the same Event ID 4662. Roberto Rodriguez has a great explanation for this inner workings of this concept on his website Threat Hunter Playbook,

“Active Directory replication is the process by which the changes that originate on one domain controller are automatically transferred to other domain controllers that store the same data.

Active Directory data takes the form of objects that have properties, or attributes. Each object is an instance of an object class, and object classes and their respective attributes are defined in the Active Directory schema. The values of the attributes define the object, and a change to a value of an attribute must be transferred from the domain controller on which it occurs to every other domain controller that stores a replica of that object.

An adversary can abuse this model and request information about a specific account via the replication request. This is done from an account with sufficient permissions (usually domain admin level) to perform that request. Usually the accounts performing replication operations in a domain are computer accounts (i.e dcaccount$). Therefore, it might be abnormal to see other non-dc-accounts doing it.”

Very cool, right? Let’s move on.

3. Network Login (Event 4624)

So for those of you who work in security you’ll know that the event ID 4625 “An account failed to log on” is key to recognizing , say — brute force attacks for example. However , this one threw me off as it said “4624: An account was successfully logged on”. You can see right away the time stamp , there are multiple successful logins many times per second. Simultaneous logons from the same user account on multiple systems, this could indicate compromised credentials being used on multiple machines.

After some research, here are some suspicious successful login indicators to look for :

• Event ID 4624 with Logon type 10 ( RemoteInteractive logins ) and source network address is loopback ( 127.*.*.* or ::1 ) , mostly RDP tunneling, also source network is not in your organization Subnet.
• Event ID 4624 and logon type ( 3, 10 ) and both source work station names and destination are end user machines.
• Event Id 4624 with logon types ( 10 ,2 ) , Type 2 ( A user logged on to this computer ) and account name has ends with $ , Example: ItSupport$ , Possible fake machine account.
• Event Id 4624 with more than 1 successful logon with logon type in 3, 10 from same account name and different source network address.
• Event ID 4624 and logon types ( 2,10,7 ) and account name like svc_* or internal service accounts , Possible interactive logon from a service account.

4. Disabling Windows Event Auditing (Event 4719):

The two main events I look for when detecting threat actors deleting event logs / clearing log entries to cover their tracks is Event 104, 1102 “ The audit log was cleared”. However today I saw this one, 4719 — “System audit policy was changed.”

— — — — — — — — — — — — — —

[Edit: 6/8/23 (Corrections regarding ID 4719)] After some further research into this Event ID it does appear that “4719(S): System audit policy was changed” can be generated by GPO refresh rate. It could be generating events due to a conflict of policies or the use of both advanced and basic audit policy settings. It’s also possible that someone changed the audit settings during office hours, but they were only applied later due to the GPO refresh rate. As found in this microsoft article the following can occur when the policies are misconfigured,

“Using both advanced and basic audit policy settings can cause unexpected results. If you use Advanced Audit Policy Configuration settings or use logon scripts (for computers running Windows Vista or Windows Server 2008) to apply advanced audit policy, be sure to enable the Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings policy setting under Local Policies\Security Options. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.”

— — — — — — — — — — — — — — — — — — —

This is a really interesting one, and I think I might write another article about how to actually go about doing this remotely , but after looking into it — it does appear that one could go into Group Policy Editor, go to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy. You can disable auditing or specific policy logging , such as “Audit account logon events,” “Audit object access,” or others here. I’m not sure if you can actually delete logs this way, but you definitely can stop them from generating, which could be useful to a threat actor.

Aaaaand that’s all for now — needless to say I will not be overlooking these additional Event IDs moving forward. Let me know in the comments if you have any additional event IDs you like to monitor for that were not covered in this article, I’d be interested in applying them as well.

Upcoming articles:

• pfSense Firewall GUI — Different Types of Logs / Firewall Rules How to
• Configuring pfSense with SIEM
• Sysmon (Deep Dive)