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:
Process create:
RuleName:
UtcTime: 2022-08-16 18:54:34.972
ProcessGuid: {0bd59c11-e7ea-62fb-c001-000000001b00}
ProcessId: 9512
Image: C:\AtomicRedTeam\atomics\T1003.001\bin\procdump64.exe
FileVersion: 10.11
Description: Sysinternals process dump utility
Product: ProcDump
Company: Sysinternals - www.sysinternals.com
OriginalFileName: procdump
CommandLine: C:\AtomicRedTeam\atomics\T1003.001\bin\procdump.exe -accepteula -ma lsass.exe C:\Windows\Temp\lsass_dump.dmp
CurrentDirectory: C:\Users\User\AppData\Local\Temp\
User: [REDACTED]
LogonGuid: {0bd59c11-e097-62fb-43d1-040000000000}
LogonId: 0x4d143
TerminalSessionId: 1
IntegrityLevel: High
Hashes: MD5=8CC9C90598900CECB00192DA74163250,SHA256=1A107C3ECE1880CBBDC0A6C0817624B0DD033B02EBAF7FA366306AACA22C103D,IMPHASH=92A5EE874B322C50D634CA587ECBBE66
ParentProcessGuid: {0bd59c11-e7ea-62fb-bf01-000000001b00}
ParentProcessId: 11172
ParentImage: C:\AtomicRedTeam\atomics\T1003.001\bin\procdump.exe
ParentCommandLine: C:\AtomicRedTeam\atomics\T1003.001\bin\procdump.exe -accepteula -ma lsass.exe C:\Windows\Temp\lsass_dump.dmp
ParentUser: [REDACTED]Note: We ran this test to populate event ID.
Windows Event Logs
Windows Event Logs offer defenders an entirely native option for collecting all variety of security telemetry. There’s at least one Windows Security Event Log that collects process creation data:
Windows Security Event ID 4688: A new process has been created
As the name implies, and in Microsoft’s own words, Event ID 4688 populates with relevant telemetry every time a new process starts. The following is an example of a 4688 event that populated after we used procdump.exe to dump the memory space of lsass.exe:
A new process has been created
Creator Subject:
Security ID: [REDACTED]
Account Name: [REDACTED]
Account Domain: [REDACTED]
Logon ID: 0x48A46
Target Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Process Information:
New Process ID: 0x1b4
New Process Name: C:\AtomicRedTeam\atomics\T1003.001\bin\procdump64.exe
Token Elevation Type: TokenElevationTypeFull (2)
Mandatory Label: Mandatory Label\High Mandatory Level
Creator Process ID: 0x1348
Creator Process Name: C:\AtomicRedTeam\atomics\T1003.001\bin\procdump.exe
Process Command Line:
Note: We ran this test to populate this Windows Event ID 4688.
Generating telemetry
Now that you understand the virtues of monitoring process creation events, it might be helpful to see how this works in practice. The above examples leveraged procdump.exe to generate telemetry, but here we’ll use a simpler test that doesn’t rely on any external prerequisites. Whether you’re using a commercial EDR tool, Sysmon, native logging capabilities, or another technology we didn’t cover in this blog, the following atomic test should create at least one process and a corresponding record of that process creation event.
Run this in command prompt:
rundll32 vbscript:"\..\mshtml,RunHTMLApplication "+String(CreateObject("WScript.Shell").Run("calc.exe"),0)
Simply put, this atomic test uses a combination of rundll32.exe and VBscript to launch the calculator application. Running it should generate process creation events for the following processes: rundll32.exe and calc.exe.
The following table shows relevant process telemetry captured by Sysmon.
Process Create:
RuleName: technique_id=T1218.002,technique_name=rundll32.exe
UtcTime: 2022-09-09 17:55:38.684
ProcessGuid: {0bd59c11-7e1a-631b-eb00-000000002c00}
ProcessId: 4064
Image: C:\Windows\System32\rundll32.exe
FileVersion: 10.0.22000.653 (WinBuild.160101.0800)
Description: Windows host process (Rundll32)
Product: Microsoft® Windows® Operating System
Company: Microsoft Corporation
OriginalFileName: RUNDLL32.EXE
CommandLine: rundll32 vbscript:"\..\mshtml,RunHTMLApplication "+String(CreateObject("WScript.Shell").Run("calc.exe"),0)
CurrentDirectory: C:\Users\User\
User: [REDACTED]
LogonGuid: {0bd59c11-7caf-631b-d68d-040000000000}
LogonId: 0x48DD6
TerminalSessionId: 1
IntegrityLevel: Medium
Hashes: SHA1=282B937EC6F6DEE3FEE38E9BF660EEDC664426D0,MD5=5B6074C9C7461198561B7B68A0A46FFE,SHA256=2984B4AD9F5CE7A8828934832FA7D7932FA53E432ED14D0B5636FBADAF536131,IMPHASH=5C68DE198B5D2DD5C1129782AD19676C
ParentProcessGuid: {0bd59c11-7ce5-631b-a200-000000002c00}
ParentProcessId: 7812
ParentImage: C:\Windows\System32\cmd.exe
ParentCommandLine: "C:\Windows\system32\cmd.exe"
ParentUser: [REDACTED]Conclusion
While you can’t rely on it exclusively to detect threats, process creation is a critical data source component that should be collected by nearly every security team. While it’s not entirely resistant to evasion, it’s readily available in native logs as well as free and paid tools.
In combination with command execution, process creation is an extremely powerful tool for performing behavioral endpoint detection.
Related Articles
The Trainman’s Guide to overlooked entry points in Microsoft Azure