Better know a data source: Process creation

Process-related data sources often provide necessary (but insufficient) telemetry to security teams who want to develop endpoint-based behavioral analytics. Accordingly, some 97 percent of Red Canary detection analytics for Windows contain a process component. While less dramatic, process creation (a component of ATT&CK’s Process data source) is the second most common data source across ATT&CK techniques, trailing only command execution.

Given its preeminence at Red Canary, in MITRE ATT&CK, and elsewhere, process creation certainly deserves attention in our ongoing Better know a data source series.

Read on to learn why it’s important to monitor process creation events, where you can collect relevant logs, and how you might use them.

What’s a process anyway?

The ATT&CK framework defines a process as, “Instances of computer programs that are being executed by at least one thread” and continues to say that they “have memory space for process executables, loaded modules (DLLs or shared libraries), and allocated memory regions containing everything from user input to application-specific data structures.” Microsoft very simply defines a process as “an executing program.” A safe, middle ground definition is that a process is a collection of resources that perform or facilitate the performance of an action or actions on a computer or server.

A process is a collection of resources that perform or facilitate the performance of an action or actions on a computer or server.

Why focus on process creation?

However you define it, anything you do on a computer involves a process in some way, shape, or form. Similarly, anything an adversary does on a computer also involves a process, which is why process creation and other process-related telemetry are among the most important data sources that any security team should collect from. All actions that occur in an operating system (module loads, network connections, registry modifications, file modifications. etc.) are tied to a process.

Further, process records are widely and readily available to security teams of all sizes and at all budget levels. You can pay top dollar for a tool that records them or you can get them for free from native logging capabilities and free system monitoring tools like Sysmon (we’ll explore collection in depth later).

How much control does an adversary have over process creation?

There’s a lot of dynamics involved in determining the extent to which an adversary does or doesn’t control process creation. In almost every circumstance, depending on what they are trying to accomplish, adversaries have multiple processes to choose from. Further, for any given process that an adversary chooses to abuse, they may be able to manipulate defenders’ ability to accurately identify and record that process.

To that last point, an adversary can easily rename a process, thereby evading superficial detection logic that simply tracks presented process names. However, even a renamed version of PowerShell, for example, will still contain process metadata that identifies the true identity of the executable. Things like binary internal name, original filename, and cryptographic hashes will ultimately reveal the true identity of the process, although these data source components are distinct from process creation.

An adversary could go so far as to change the hashes and binary metadata for a process, but at that point, they’re not living off the land so much as introducing a new external binary with no local or global reputation to the system. In either case, defenders should be able to collect a record of process execution, regardless of the information associated with the process.

Short of disabling security tools and hindering a defender’s ability to log process execution, which is a pretty common adversary technique, defenders should be able to record process-related information regardless of what an adversary does, assuming they’ve configured their security controls correctly.

There’s admittedly a lot more we could write about an adversary’s ability to subvert this data source, and we could expound on the topic for all the various collection sources we’re about to cover. However, we’d be retreading ground that’s already been covered to a large extent. If you want to learn more, our director of threat research, Matt Graeber, wrote an extensive report for SpecterOps in 2018 along with Lee Christensen about the extent to which an adversary can subvert Sysmon, including process creation events. This research remains relevant today, and is representative of the broader ways that an adversary might try to evade other collection sources as well.

Collecting process creation events

There are a wide array of event logs and tools that collect process starts, stops, relationships, and other metadata. Some are free, others cost money, and others still are default or configurable log sources. We’ll start generically.

Commercial endpoint detection and response (EDR) tools

Nearly every EDR tool will collect process-related information, including but certainly not limited to process creation events. Some leading EDR providers include VMware Carbon Black, CrowdStrike, Microsoft, and SentinelOne to name a few, and we published a detailed EDR buyer’s guide a few years ago to help anyone who might be in the market for one. Despite their utility, EDR platforms can be prohibitively expensive for teams who are doing security on a budget. Luckily, there are free alternatives.

Sysmon

Sysmon Event ID 1 collects a wealth of information about newly created processes, including the unique processGUID, the hash value of the process, and its corresponding command line. We ran an Atomic Red Team test that downloads procdump.exe and uses it to empty the memory space of lsass.exe into a DMP file, to populate Event ID 1 with the following telemetry: