This Idiom describes the process of capturing the process tree of execution that was observed and reported for a malware instance by a dynamic analysis or similar tool. As with all analysis-derived results, those that come from dynamic analysis can be captured through the use of a MAEC Bundle. However, results pertaining to the process tree of execution for a malware instance will be captured exclusively through the use of the Process Tree entity.
In this scenario, a malicious PE binary has been analyzed through the freely available Anubis sandbox service, which provides information about the low-level actions that the PE binary performs when executed and also the process tree of execution that was seen. Note that in this example, we’ll be covering only the capture of the process tree - for information on the capture of API calls and actions, please see the Capturing Dynamic Analysis Results Idiom. Also, for the sake of brevity, we will assume that the observed process tree involves only two different processes - the process first spawned when the malicious binary was executed (“first_process.exe”), and a child process spawned by this process (“malproc.exe”). Accordingly, let’s assume that the first (root) process performs a single Action of creating a file.
The following are the important MAEC data model constructs used in this idiom:
Process Tree: the Process Tree entity is used to characterize an observed process tree of execution for a malware instance, and is captured in a MAEC Bundle.
Process Tree Node: the Process Tree Node is used to capture a single node in the Process Tree, or in other words the details around a single process.
Let’s discuss the Process Tree Node in more detail. Firstly, it’s important to note that this entity derives from the CybOX Process Object, so that it encompasses all of the Process Object fields, including the following that are commonly utilized:
PID. The PID field specifies the Process ID, or PID, of the process.
Name. The Name field specifies the name of the process.
Image_Info. The Image_Info field specifies information about the image associated with the process, such as its file name and path.
Additionally, the following fields are extensions added in the Process Tree Node:
Initiated_Actions. The Initiated_Actions field captures, via references, the actions (found inside the top-level Actions element, or an Action Collection inside the top-level Collections element) initiated by the Process.
Spawned_Process. The Spawned_Process field captures a single child process spawned by this process.
Injected_Process. The Injected_Process field captures a single process that was injected by this process.
As with many of the other Idioms, the first step is to create a MAEC Package with a Malware Subject for capturing the information about the malware instance being analyzed. We should also add an Analysis entity to the Malware Subject to capture some details relating the particular analysis that we’re performing. The information on this process is not covered in this idiom, but can be found in the corresponding Creating a MAEC Package and Capturing Analysis Metadata idioms.
Next, a MAEC Bundle is created. Once created, we must set the “content_type” attribute on the Bundle to define the type of content that it is characterizing. In this case, since we’re capturing output related to dynamic analysis, we should set it to a value of “dynamic analysis tool output”. This is one of the values contained in the BundleContentTypeEnum enumeration used by this field. Finally, we should set the defined_subject attribute on the Bundle to a value of “false”, since this Bundle will be contained in a Malware Subject, which has already defined the particular malware instance being characterized.
Now that we’ve set up the Bundle that will capture the process tree results, we can begin to populate it with these results. As mentioned in the introduction, we’ll be using the Process Tree entity to capture the output of the observed process tree. Accordingly, since the Process Tree is intended to serve simply as the root of the process tree, we’ll be using the Process Tree Node entity to capture the information about the actual processes in the tree.
Thus, the general process of building a Process Tree instance involves the following basic steps:
Create the Process Tree instance by populating its corresponding “Process_Tree” field at the top-level of the Bundle that was previously created.
Set the root process in the “Root_Process” field of the process tree by using the Process Tree Node.
Set any defined properties on the root process, such as its process ID (“PID” field) or process name (“Name” field). For our example, we’ll set the “Name” field to a value of “first_process.exe”.
Define any processes that were spawned or injected by the root process using their respective “Spawned_Process” and “Injected_Process” fields and the Process Tree Node. For our example, we’ll add a single “Spawned_Process” that corresponds to the one spawned by “first_process.exe”.
Define any Actions that were initiated by the root process using the Initated_Actions field and the corresponding Action Reference entity. The Action Reference is simply a reference, via its “action_id” field, to an Action that is defined elsewhere in the same MAEC Bundle that the Process Tree resides in. For our example, we’ll add a single Action Reference instance to the Initated_Actions field in order to refer to the “create file” Action that was initiated by the root process.
Repeat steps 3-5 for any spawned or injected processes, as well as their children, defined in the respective “Spawned_Process” and “Injected_Process” fields of the root process. For our example, we’ll set the “Name” field of the spawned process that we added to a value of “malproc.exe”, for representing the identity of the process spawned by “first_process.exe”.
With the Bundle populated with the process tree information, the final step is to add it to the Malware Subject. To do, we’ll use the Findings_Bundles field, and specifically will populate its child “Bundle” field with the Bundle that we’ve constructed.
1
2
3
4
5
6
7
8
9
10
11
<maecBundle:Process_Tree>
<maecBundle:Root_Process id="example:process-b61b6bd3-3489-4db9-8558-a148526e96be">
<ProcessObj:Name>first_process.exe</ProcessObj:Name>
<maecBundle:Initiated_Actions>
<maecBundle:Action_Reference action_id="example:action-68f87759-45f4-4e2e-b3a1-1edf15282db5"/>
</maecBundle:Initiated_Actions>
<maecBundle:Spawned_Process id="example:process-d3b74b23-01e4-408e-a29f-fdb45c40bed4">
<ProcessObj:Name>malproc.exe</ProcessObj:Name>
</maecBundle:Spawned_Process>
</maecBundle:Root_Process>
</maecBundle:Process_Tree>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Create the first, create file action
# Create the Process Tree
p_tree = ProcessTree()
# Create the root process
root_p = ProcessTreeNode()
root_p.name = "first_process.exe"
root_p.add_initiated_action(act1.id_)
# Create the spawned process
spawned_p = ProcessTreeNode()
spawned_p.name = "malproc.exe"
# Add the spawned process to the root process
root_p.add_spawned_process(spawned_p)
# Set the root process in the process_tree
p_tree.set_root_process(root_p)