Better know a data source: Process command line

EDITOR’S NOTE: We initially published this article before MITRE significantly updated ATT&CK data sources and components. As a result, we use the term “process command line” in this article to refer to the data source component that MITRE would later categorize as “command execution.” 

Command line refers to the arguments that are passed to an executable process in Windows. It is useful information for defenders as it can reveal contextual clues about the execution of a suspicious process. For example, adversaries regularly supply malicious PowerShell code as command-line arguments via the -Command and -EncodedCommand parameters. For executables that support arguments, command-line context is incredibly valuable to defenders looking to identify malicious behavior and/or aid incident response.

Any user-mode process, even if it isn’t a dedicated console application (for example, a GUI application) can have associated command-line arguments. And while it is generally the case that if an application implements command-line parameters that they will be documented accordingly, this is not always the case. Many applications have undocumented command-line parameters.

Why focus on process command line?

Defenders and vendors rely on process command line to discern benign from suspicious or malicious activity because it is among the most omnipresent data sources on an endpoint. Process command line can tell us how an application was intended to be used and in some cases can supply us directly with adversary payloads. For example, adversaries often supply malicious encoded PowerShell commands directly at the command line using any of the -EncodedCommand parameter variations. The way in which PowerShell eases post-exploitation abuse for adversaries also creates a unique and straightforward means of detecting malicious behavior based on process command line alone.

But this begs the question: what does legitimate PowerShell command-line activity look like?, which begs the follow-on question an adversary may pose: to what extent can I blend in with seemingly legitimate looking PowerShell command-line activity? So while you can be generally confident that known malicious evidence in the command line is malicious, you can’t always trust that non-malicious looking command line is not malicious activity in hiding.

What data sources are available to retrieve process command line?

The following data sources are either built into the operating system or are freely available to collect process command line. Note: This is a non-exhaustive list of data sources.

Windows Management Instrumentation (WMI)

Data source: Win32_Process Class
Relevant field[s]: CommandLine

Example retrieval: 

Sysmon

Data source: Event ID 1: Process creation
Relevant field[s]: CommandLine, ParentCommandLine

Example data:

Where is process command line stored and how do adversaries retrieve it?

Process command-line information is stored within the ProcessParameters field of the process environment block (PEB), a user-mode data structure present in all processes. Because it is a user-mode data structure, it is readily susceptible to adversary modification. Even kernel drivers responsible for populating security events have to retrieve the command line from the PEB in user mode.

There are no APIs for directly retrieving process command line from another process. The following APIs are often used to access the PEB directly:

• NtQueryInformationProcess: This function can be used to obtain the PEB address for a process. For example, the WMI Win32_Process class uses this function for command-line retrieval. There are also other available methods of obtaining the PEB address, including RtlGetCurrentPeb and inline assembly code.
• ReadProcessMemory: This function can be used to read memory from a process. Using this API would require knowledge of the offsets to the CommandLine field within the ProcessParameters structure or by linking against winternl.h.

Under what conditions does an adversary have control over the process command line?

If an adversary has already achieved arbitrary code execution, they have the ability to spawn a new process with the command-line arguments of their choosing. An adversary may supply custom command-line arguments with the following intentions:

• to supply legitimate command-line arguments to an executable that expects and will process the arguments
• to evade naive detection logic that might look for specific command-line strings

So in the scenario where an adversary already has arbitrary code execution, they have a large amount of control over the command line of the processes they spawn. You should never assume that an adversary is not tampering with command-line logging.

Under what conditions does an adversary not have control over process command line?

An adversary will not have direct control over process command line under the following conditions, among many others:

• A file is executed using its default file handler. For example, getting a victim to download and double click on a MSHTA .hta file would invoke the default file handler for that extension: mshta.exe <path to HTA file>
• An executable starts as a side effect of certain actions. For example, when the Add-Type cmdlet is called in PowerShell, assuming it is C# code being compiled, the C# compiler csc.exe is spawned as a child process with a predictable command line.

How can I simulate generation of process command line in order to perform sensor and detection validation?

Influencing process command line at process start

There are multiple APIs available to start a process with a custom command line, CreateProcess being one of the more common functions available. In order to test starting an executable with a command line, we developed a simple PowerShell wrapper to make testing easy.