Centralizing Process Creation Events with a SIEM

Employee Centralizing Process Creation Events with a SIEM

How Process Creation Events Can Be Centralized for Ease of Analysis

Process creation events are written to the Windows Event Log on the local endpoint where they are generated. This raises an obvious issue for defenders looking to proactively review these logs, because it is simply infeasible to review large amounts of data with the Windows Event Viewer (not least because the Windows Event Viewer remains largely the same as when it was first released with Windows 95).

One possible solution to this dilemma is to collect and centralize these events into a security information and event management (SIEM) tool. A SIEM will provide capabilities to read events from the Windows event log on an endpoint and centralize the data for analysis and review.

Using LogRhythm’s NextGen SIEM Platform, the screenshot below shows an example of a process creation event within a SIEM console.

A process creation event in LogRhythm NextGen SIEM Platform
Figure 1: A process creation event in LogRhythm

This is visualizing a MITRE ATT&CK technique known as indirect command execution, which is a tactic an attacker may use to bypass security restrictions on an endpoint. We can see that the command which was executed was:

pcalua.exe -a C:\Windows\System32\calc.exe

We can also clearly see the process name and parent process name. From this output, a defender can identify this as a suspicious execution of a LOLBIN (pcalua.exe is a built-in Windows program called Program Compatibility Assistant) and subsequently conduct an investigation.

Centralizing process creation events will also allow defenders to perform threat hunting activities, such as analyzing process parentage. Here is an example which shows the child and parent process relationships:

Parent and child processes displayed in LogRhythm NextGen SIEM Platform
Figure 2: Parent and child processes displayed in LogRhythm

In addition, a SIEM solution may provide a trend visualization, which allows defenders to track the execution of processes over time. This type of visualization is useful to help establish a normal baseline of LOLBIN execution as described above.

A trend graph of process execution within LogRhythm's SIEM solution
Figure 3: A trend graph of process execution within LogRhythm

Lastly, certain SIEM technology may provide inbuilt analytics and content to detect MITRE ATT&CK techniques leveraged within an environment, which require process monitoring as a data source:

A MITRE ATT&CK alarm within LogRhythm's SIEM
Figure 4: A MITRE ATT&CK alarm within LogRhythm

5 Reasons for Enabling Process Monitoring Alongside Existing Endpoint Protection Platforms

Endpoint protection platforms such as endpoint detection and response tools (EDR) tools will perform functions such as monitoring activity (including processes) on an endpoint for the purpose of detecting threats, assisting in incident response, and proactive threat hunting. Organizations that have deployed an EDR may view this as fulfilling the function of process monitoring; however, for organizations who have made an investment in an endpoint protection platform, there is still value in enabling and centralizing process creation events in a SIEM for the following five reasons:

1. While an EDR tool will monitor processes on an endpoint, it may not retain the log data for any process activity which did not trigger an alert on the EDR. By enabling Windows process creation events and collecting and centralizing them in a SIEM, organizations will have a longer-term retention of all events to aid in historical analysis.

2. Advanced attackers will attempt to bypass or disable endpoint protection platforms such as EDR in order to stay undetected in their campaigns. By enabling and centralizing process creation events, organizations can mitigate this risk. Process creation events will continue to provide visibility into activity on the endpoint.

3. Process creation events alongside an EDR, provide a “detection in depth” strategy for endpoint monitoring. The types of attacks seen in 2020 (and likely in 2021) demonstrate that organizations should not rely on any single control, but rather look to implement a security architecture which provides overlapping fields of visibility.

4. Endpoint protection platforms (such as EDR that provides malware prevention capabilities) may not detect targeted malware. For example, at the time of writing, only 20/60 vendors on VirusTotal made a detection on a sample of Sunburst malware, see screenshot below. This highlights the need for detection in depth:

VirusTotal detections for Sunburst malware in January 2021
Figure 5: VirusTotal detections for Sunburst malware in January 2021

5. Lastly, when examining the MITRE ATT&CK Evaluations test results for a simulated test of APT29 activity, all vendors missed one or more detections of the various MITRE techniques tested. This is to be expected, but further highlights the need for organizations to perform detection in depth.

In summary, organizations should not rely on a single mechanism for threat detection on the endpoint, and so should consider enabling and centralizing Windows process creation events to compliment the capabilities of any existing endpoint protection platform.

What to Consider When Enabling Windows Process Creation Events

When enabling process creation events, additional data will be written to the Windows Event Log (and therefore the SIEM if they are being centrally collected). It is highly recommended to perform some testing, with a corporate image if possible, to understand the additional event volume generated and the potential impact that this may have in a production environment.

If collecting these events centrally, the delivery mechanism needs to be considered. In some scenarios, collection via a SIEM can be leveraged, however tools such as Windows Event Forwarding (WEF) can be deployed. In Virtual Desktop (VDI) environments, this may be more feasible.

Finally, there is the question of what endpoints (workstations or servers) to enable process creation events. It is highly recommended that they are enabled on both workstations and servers, which will provide complete visibility of the environment. Plus, attackers and malware are much more likely to make an initial infection or establish an initial foothold on a workstation, rather than a server.

Read More About Process Creation Events

This is the final post to a three-part blog series discussing Windows process creation events, the value they can bring, and best practices while using them in threat hunting.

To read the full series, visit these blogs today!

  • Part one: Introduces process creation events and discusses why you should enable them.
  • Part two: Shows readers how to enable process creation events and provides examples of why they are valuable for threat detection.