Inspired by this tweet from Renzo about his favourite Windows Event for Digital Forensics and Incident Response, we decided to create a top 5 of Windows Event IDs. We’d love to hear your favourite Event IDs please let us know in the comments.
The top 5 is based on what we see in the real world at our clients during incidents. Therefore, unfortunately no Sysmon events are out of scope as well as process creation events aka Event ID 4688, which are not enabled by default.
Note: If you’re responsible for Windows administration please install Sysmon and enable Command line process auditing, you’ll thank us later!
With that being said let’s dive in..
Number 5 — Event ID 1149
Description — User authentication succeeded (Source: Windows TerminalServices RemoteConnectionManager Operational log).
The Windows Remote Desktop Protocol (RDP) is often used by threat actors to move laterally, in order to find interesting systems, perform data exfiltration and sometimes even to manually run ransomware. As part of an RDP connection lots of events are generated in the Windows Event log. If you’re just starting out in the field or if you’re like me and need a refresher, please read the following blogs [1] and [2] on this topic to know exactly what logs are generated in which scenario. One of the more useful ones that we’ve used in the past to figure out suspicious RDP activity is using Event ID 1149. This event occurs early in an RDP connection and basically means that a successful RDP connection was established, but not a successful authentication. However, this event alone is very useful to hunt threat actors that are trying to connect to lots of systems using RDP. We’ve had cases where threat actors used RDP and created lots of nested connections. The below example from shows what’s typically recorded in an event:
This event can help you identify source IP and user of the connection, however this information is not always recorded. To get the full story of the RDP connection and to verify whether an actual successful RDP session occurred you have to combine it with Event ID 4624, which we will cover in this blog as well.
Number 4 — Event ID 4698
Description — A scheduled task was created (Source: Windows Security).
One of the most commonly used persistence mechanisms is the scheduled task. Sodinokibi/Revil used this method as well as IcedID. Once, you’ve found a scheduled task that you want to inspect or delete check the following locations:
Filesystem
C:\Windows\System32\Tasks
Windows registry
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Task HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tree Numbers
Number 3 — Event ID 4624
Description — An account was successfully logged on (Source: Windows Security).
This is a classic and you’ve probably seen this one before. If you want to know who authenticated, when and where you need this event. As part of an incident you’ll often need to determine the scope of the infection, filtering on this Event ID and searching for a username you can help you answer that questions. Additionally, you can detect pass-the-hash, interactive and RDP logons. Types of logons described by Ultimate Windows Security
Number 2 — Event ID 7045/4697
Description — A (new) service was installed in the system (Source: Windows System/Security).
This specific event was the inspiration for this blog and as observed in this thread this event is particularly useful for detecting Cobalt Strike. Please read up on our earlier articles on Cobalt Strike, but it’s safe to say that Ransomware groups ❤️️ Cobalt Strike for their operations. So this should be one of the first checks if you have a Windows Event log. Below an example of a service install because of Cobalt Strike. Picture is from the excellent Cobalt Strike Defender’s guide by the DFIR report.
Number 1 — Event ID 1102
Description — The audit log was cleared (Source: Windows Security).
The number one, if you see this event and no central log management was in place, this is the moment you start to cry. This event means that someone cleared the event log on purpose, which is rarely part of legitimate operations. Recently we saw this activity on an on-premise Windows Exchange environment, due to the enormous size of event logs. This was legitimate, however it’s not advised as you are destroying important evidence. During other recent engagements we noted that ransomware threat actors have started to cover their traces by clearing the event logs. There’s quite a long list of threat actors especially APT’s that employ this technique to hinder analysis, check out the full list by MITRE. If you see this event and you have the logs recorded in a central log management solution like Splunk or Elastic, this event also provides a great opportunity for further investigation. Because you can pivot further based on the user that performed the action or the time of the clear operation which is recorded in the event as shown below:
Further reading
If you like this post and want to know more about event logs and what you should be monitoring in a Windows environment, check out the following resources:
- If you want to set up auditing and all kinds of event log cheat sheets. https://www.malwarearchaeology.com/cheat-sheets
- Excellent blog about Ransomware TTPs and how to detect them in Windows event logs by IBM. https://securityintelligence.com/posts/detections-help-identify-ransomware/
Conclusion
We hope you liked this top 5, please let us know if we missed something and what your favorite Windows Event IDs are and why. Please follow us on LinkedIn & Twitter to stay updated on the latest.