In Cybersecurity, a new threat emerges every day, and it is essential to set up detections and logging to detect if any of these threats are attacking your organization. Furthermore, when an adversary compromises your organization, it is vital to stop them as soon as possible. Therefore, it is essential to have updated detection strategies and capabilities to identify these threats in real-time and stop them in their tracks. One of the best resources for detecting security-related events in Windows is the Windows Event Log.
Windows Event Log is a tool present in Windows which keeps a detailed record of System, Security and Application Logs. Administrators can use these logs to troubleshoot issues, find errors, and ensure correct security configurations are followed. In addition, each event in Windows Event Logs also matches a specific Event ID, which tools can use to notify and detect particular actions. Security Events in Windows Event Logs provide a wealth of data that can detect an adversary or be used during forensic analysis of the compromised system.
Detections using Event Logs
Security Events store information based on the system's audit policies. For example, the security log can be configured to log an entry when a user logs in. In addition, security event logs contain the date, time, user, computer, source, and type of event. These events can also be consumed or forwarded to various SIEM/logging solutions, which Security teams can then use to build detections and alert on specified events and threshold of events.
Windows Event IDs have around 85% coverage of Windows Specific techniques in MITRE ATT&CK. Therefore, a workflow can be established in the organization to cover these techniques and ensure that you have set up proper detection and alerting.
Choose: Select a necessary technique depending upon the latest threat intelligence or something essential in your organization.
Collect: Collect all the necessary data on the technique, such as log sources, event IDs, descriptions etc.
Generate: Generate logs for that event using tools or manually performing the action. Ensure that the records are being ingested.
Alert: Create an optimized query to detect the potential threat. Ensure low false positives.
Once this methodology is perfected, you can become proactive and start threat hunting in your environment. Threat hunting is becoming increasingly important if you need to stay ahead of the latest cyber threats.
When enabled, Windows will provide lots of logs for various events on the system. But, more than likely, they would add noise to your logging infrastructure. Therefore, it is crucial to disable the collection of logs which are highly likely to be false positives and identify other means or sources to collect more enriched data. Some examples of important logs which should be enabled for detection are given below. It is up to the organization to baseline its requirements and allow event logs while reducing false positives.
Event ID 4688 - A new process has been created: Event 4688 documents each program that is executed, who the program ran as and the process that started this process.
When you start a program you are creating a "process" that stays open until the program exits. This process is identified by the Process ID:. You can correlate this event to other events by Process ID to determine what the program did while it ran and when it exited
1A new process has been created.
4 Security ID: SYSTEM
5 Account Name: RFSH$
6 Account Domain: LAB
7 Logon ID: 0x3E7
10 Security ID: LAB\rsmith
11 Account Name: rsmith
12 Account Domain: LAB
13 Logon ID: 0x2C9D82
16 New Process ID: 0x2e0e4
17 New Process Name: C:\Windows\System32\RuntimeBroker.exe
18 Token Elevation Type: %%1938
19 Mandatory Label: Mandatory Label\Medium Mandatory Level
20 Creator Process ID: 0x268
21 Creator Process Name: C:\Windows\System32\svchost.exe
22 Process Command Line:
Event ID 4720 - A user account was created: When a new user account is made in a windows workstation, there would be an event log with ID 4720. Since a majority of accounts are created in Active Directory, this could be an indicator of an attempt of persistence.
1A user account was created.
45 Security ID: ACME-FR\administrator
6 Account Name: administrator
7 Account Domain: ACME-FR
8 Logon ID: 0x20f9d
1112 Security ID: ACME-FR\John.Locke
13 Account Name: John.Locke
14 Account Domain: ACME-FR
1718 SAM Account Name: John.Locke
19 Display Name: John Locke
20 User Principal Name: John.Locke@acme-fr.local
21 Home Directory: -
22 Home Drive: -
23 Script Path: -
24 Profile Path: -
25 User Workstations: -
26 Password Last Set: <never>
27 Account Expires: <never>
28 Primary Group ID: 513
29 Allowed To Delegate To: -
30 Old UAC Value: 0x0
31 New UAC Value: 0x15
32 User Account Control:
33 Account Disabled
34 'Password Not Required' - Enabled
35 'Normal Account' - Enabled
36 User Parameters: -
37 SID History: -
38 Logon Hours: <value not set>
4142 Privileges -
Event ID 1102 - The audit log was cleared: Event 1102 is logged whenever the Security log is cleared, REGARDLESS of the status of the Audit System Events audit policy. The Account Name and Domain Name fields identify the user who cleared the log.
The audit log was cleared.
Security ID: WIN-R9H529RIO4Y\Administrator
Account Name: Administrator
Domain Name: WIN-R9H529RIO4Y
Logon ID: 0x169e9
Event ID 4798 - A user's local group membership was enumerated: Windows logs this event when a process enumerates the local groups to which a the specified user belongs on that computer. This event is valuable for catching so-called APT actors who are scoping out the local accounts on a system they have compromised so that they extend their horizontal kill chain.
1A user's local group membership was enumerated.
4 Security ID: AzureAD\RandyFranklinSmith
5 Account Name: RandyFranklinSmith
6 Account Domain: AzureAD
7 Logon ID: 0x7A1EA
10 Security ID: DESKTOP-TMO9MI9\Administrator
11 Account Name: Administrator
12 Account Domain: DESKTOP-TMO9MI9
15 Process ID: 0x106c
16 Process Name: C:\Windows\System32\mmc.exe
Similarly, Windows keeps a log of many security events and can be turned on or off depending upon your needs and compliance policies. You can find a reference to these event IDs in the Windows Security Encyclopedia.
Detection Engineering with Sigma Rules
Collecting events from the Windows Event Log is not enough; it is essential to write correlation rules to detect these activities. Each security solution will have a different syntax to implement detection and alert rules. Writing new rules can become cumbersome when multiple detection systems are in use. Sigma by SigmaHQ is a generic and open YAML-based signature format that that enables a security operations team to describe relevant log events in a flexible and standardized format. Sigma rules can be converted to queries specific to your security solution. Sigma also provides an open-source list of rules you can use readily.
Taking an example from the CVE-2021-1675 Print Spooler Vulnerability, we can see how we can quickly search for an event based on EventID 5145 and filter on object type and access mask. Ability to quickly search for exploitation attempts or detect them while happening allows you to respond in a swift manner to contain a host and prevent breaches across the complete network.
Simulate a threat yourself
Let's take the example of Registry Run Key Persistence Technique.
MITRE ATT&CK mentions Registry Run Keys as "Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the "run keys" in the Registry or startup folder will cause the program referenced to be executed when a user logs in. These programs will be executed under the context of the user and will have the account's associated permissions level."
We can create events for this technique using the firedrill utility. You can find the source here and customize it to run more such techniques to improve your detection capabilities. This technique uses the Registry Key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run to execute a sample payload. Running this technique will add a value which would be captured in the Windows Event Logs with event ID 4657. An example Sigma Rule by Florian Roth to detect this attack. A huge thanks to Florian and Nextron Systems for maintaining and adding new rules to the Sigma repository.
1title: Reg Add RUN Key
3description: Detects suspicious command line reg.exe tool adding key to RUN key in Registry
6author: Florian Roth
13detection:14selection:15CommandLine|contains|all:16-"reg"17-" ADD "18-'Software\Microsoft\Windows\CurrentVersion\Run'19condition: selection
It is crucial to stay on top of emerging threats and contain or detect them in real-time. In a Security Operations Center, collecting Security Logs from Windows Event Logs and using them is essential. It is imperative to set up these detections and baseline the events in your organization to detect these threats swiftly. The baselines in your organization could be created manually or by using some automated tool to simplify the process.