Anyone who has looked at the number of event IDs assigned to Windows events has probably felt overwhelmed. In the last blog, we looked at some best practices events that are a great start to providing contextual data in the event of a security breach. For example, repeated login failures, attempted privilege escalations, and attempts to manipulate registry entries are all going to provide useful forensic data during incident response. In this blog, let’s broaden our horizons. The fact that event IDs exist in several sources beyond Microsoft-Windows-Security-Audit allows us to be more proactive and have a better understanding of how our users and systems interact. It’s all about building a baseline of what is normal and recognizing potential threats and IoC’s as sequences of event IDs.
Here are some additional event sources and useful IDs that will help increase visibility through a better understanding of network assets and how they are used:
Event Log was Cleared
Audit Log was Cleared
Attempt to hide malicious activities
Attempt by malware to interact with an application
Attempt to violate usage policy on the system
Windows Service Fails/Crashes
7022, 7023, 7024, 7026, 7031, 7032, 7034
Service Control Manager
Repeated failures on the same systems, particularly high value assets could indicate a compromise
Detected an invalid image hash of an image file
Detected an invalid page hash of an image file
Code Integrity Check
Failed Kernel Driver Loading
3001, 3002, 3003, 3004, 3010, 3023
Insertion of malicious code or drivers into the kernel
New Kernel Filter Driver
New Windows Service
Service Control Manager
Changes to software on critical assets outside of scheduled maintenance windows
Action on Malware Failed
Between these events and the list of account, process and firewall events from the previous blog, you know have a well-rounded security policy.
Note that this is by no means an exhaustive list. The idea is to get started with a set of events to build a threat detection policy. There are several other types of events such as those that report on wireless usage, mobile device activities, and print services. These events can be tracked for audit, billing, and resource utilization purposes and periodically archived.
The next step is to define how to apply our security policy and to be prepared to tune it over time. To facilitate this process, create a checklist for your environment:
- Identify which events should be monitored for critical assets versus all endpoints
- Identify those events that should be tracked at various times of the day
- Identify events that should trigger an immediate action, such as send an email to an admin; these may be tied to a task directly from the Windows Event Viewer or a series of events can be configured as triggers for alerts via the Task Scheduler.
- If I don’t use features such as AppLocker or Defender, should I investigate their applicability?
- Understand which events should be prioritized in terms of reaction and remediation.
- What events or combinations of events are considered alerts, and which are providing contextual information?
- What events need to be tied to thresholds that make a clear distinction between normal versus threat?
- Do I need to have a policy for threat detection and a process for collecting audit information?
Having a clear plan for your security policy will help overcome what is and the biggest issue with all logging and alerting; large numbers of false positives that waste time and resources and possibly detract from a real threat.
Spotting the Adversary Through Windows Event Log Monitoring