Photo by Laura College on Unsplash

Tracking Malware and Threat Actor Activity with Process Monitoring

Part 3: Centralising Process Creation Events with a SIEM

This is the third part of a three-part blog series discussing Windows process creation events. Part 1 introduced process creation events and discussed why they should be enabled. Part 2 showed how to enable process creation events and gave some examples showing why they are valuable for threat detection.

We will now briefly discuss how these events can be centralised 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 has been alluded to earlier in this article, which is to collect and centralise these events into a SIEM (Security Information Event Management) tool.

A SIEM will provide capabilities to read events from the Windows event log on an endpoint, and centralise the data for analysis and review. Using LogRhythm SIEM as an example, the screenshot below shows an example of a process creation event within the SIEM console. This is showing an example of a MITRE ATT&CK technique known as indirect command execution, which is a technique an attacker may use to bypass security restrictions on an endpoint:

Figure 1. A process creation event in LogRhythm

In this screenshot, 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.

Centralising process creation events will also allow defenders to perform threat hunting activities, such as analysing process parentage as described earlier in this article. Here is an example which shows the child and parent process relationships:

Figure 2. Parent and child processes displayed in LogRhythm

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

Figure 3. A trend graph of process execution within LogRhythm

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

Figure 4. A MITRE ATT&CK alarm within LogRhythm

5 Reasons for Enabling Process Monitoring Alongside Existing Endpoint Protection Platforms

A point thus far unaddressed is that of endpoint protection platforms such as EDR (Endpoint Detection and Response) tools. EDR tools will perform such functions as monitoring activity (including processes) on an endpoint for the purpose of detecting threats, assisting in incident response, and proactive threat hunting. Organisations that have deployed an EDR may view this as fulfilling the function of process monitoring.

However, for organisations who have made an investment in an endpoint protection platform, there is still value in enabling and centralising 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 centralising them in a SIEM, organisations 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 centralising process creation events, organisations 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. As mentioned at the beginning of the article, the types of attacks seen in 2020 (and likely in 2021) demonstrate that organisations should not rely on any single control but rather look to implement an 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:

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 organisations to perform detection in depth.

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

Considerations

Here are some final points that organisations should 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 WEF (Windows Event Forwarding) can be deployed. In VDI (Virtual Desktop) 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, and for the simple fact that attackers and malware are much more likely to make an initial infection or establish an initial foothold on a workstation, rather than a server.

Conclusion

It is hoped that this series has given the reader some illumination into what Windows process creation events are, and provided sufficient evidence to demonstrate the value that they can bring.

Read Part 1 here and Part 2 here.