SYSMON Playbook – Event ID 1

Windows by default records most of the activity happening on OS in the Windows logs and can be viewed in Windows Event Viewer. However the Sysmon is much better when it comes to providing visibility into the activities related to executions.

Sysmon is a great tool which is used to monitor the system and log activities in the windows events logs. There are different actions that Sysmon can log which I will explain in a separate post. However, today we will talk about the activity that is required by pretty much any malware to achieve what it was designed for. Now a malware can show different behaviors, it can be a dropper, it can be the actual binary that will be executed or it could be just used for connecting to command and control server. In any case, malware will have to execute on the system to perform the activities it was designed for.

Execution is the key for malware to be active and do what it is required to do. A malware sitting on the system doing nothing isn’t much of an asset for an adversary unless attacker has a backdoor access to it and it can trigger anytime. In any case, system will be affected when it will execute and once it does we will get a process creation event in Sysmon logs.

What is Process?

To discuss what exactly is a process, I’ll borrow this definition from Microsoft’s website.

process, in the simplest terms, is an executing program. 

So moving further, lets dive into the reasons of why exactly a process will be executing. Four basic principles of process creations would be:

  1. System Initialization
  2. A running process creates another process.
  3. Process created by user (For example: double click an .exe)
  4. Batch job gets initialized.

Why Process Creation is Important?

What is more important from security analyst’s perspective is that when a process is created, what are the actions that a process is taking, is it creating other child processes? is it trying to connect to network? or is it creating another binaries. Who is actually creating a process? These are very relevant questions that should be answered and we will find those answers and much more using the pivoting technique to gather additional contextual information. For this we will be using the Sysmon Event ID 1 which is logged by Sysmon when a process gets created.

Sysmon Event ID 1 provides a treasure trove of information about the environment’s situation at a certain point in time when a process was created. It may not seem enough but using the information available we can move around this event and gather additional contextual information. The attributes available in the Sysmon event id 1 become the key attributes in itself to identify the additional information.

Relationships of Process Creation:

A process creation is an event where another being is created. Just like humans have reproduction cycle and they have children, similarly processes reproduce also. However, in case of humans parents (Mother and Father) have to be involved but for the processes there is no such limitation. A single process can have multiple children and the association is known as parent-child relationship. A single parent process can create other processes or another single process which will be known as child process. When a process is created there are many details associated with it which include details about it’s executable, time of creation, actions associated with it and hashes of the executables.

Process Creation Attributes:

Sysmon captures many details about the process creation event and documents them under the event id 1. We will briefly discuss all the fields captured under the event id 1.

  • RuleName: 
  •     UtcTime: Time at which the process was created.
  •     ProcessGuid: A unique value for the process across a domain to make event correlation easier. (Can be used incase ProcessId is reused by system.)
  •     ProcessId: A unique identifier assigned to the process during it’s life time. (Same ProcessId can be assigned to other process once this process terminates).
  •     Image: Path to the executable file which actually is being used for running the process.
  •     FileVersion: Version number of the child process executable.
  •     Description:
  •     Product:
  •     Company:
  •     CommandLine: What is the command that was executed by the process.
  •     CurrentDirectory: The image location from where it is being executed.
  •     User: The user under whose role the process is being executed.
  •     LogonGuid:
  •     LogonId: Unique logos id specific to the user session created after user login.
  •     TerminalSessionId:
  •     IntegrityLevel:
  •     Hashes:
  •     ParentProcessGuid:
  •     ParentProcessId: Unique Id for the parent process.
  •     ParentImage: What is the executable that ran the child process.
  •     ParentCommandLine: What command did the parent process run to execute a child process.

Investigation Steps:

This strategy has a lot of information that can be used in many ways depending on the type of incident and artifacts that you observe. In this event id we know that it occurs when a new process is created, this happens when we either double click on any exe or run an executable using any other way. There are many fields in this event id which can be a very good candidates for pivot points. Pivot points means to further obtain the contextual information any of the event properties can be used.

  1. Check the Parent Image field and Image field, if you find any discrepancy that the parent of the process shouldn’t be executing such child processes, we will proceed further. (For example: if outlook.exe is the parent process of the cmd.exe this would be worth investigation)
  2. Check the commandLine and parent command line parameters. Check what are the action parameters being mentioned in the command line since it will define what the attacker wants to execute. (For example: whoami, net users kind of commands should raise red flag.)
  3. Hashes can be checked also if the Parent Image and Image field show unknown processes executables.
  4. Current directory should be checked if it is a known legitimate windows path or temp folder.
  5. Current Direcory should be matches with the Image name to verify that the known Image is executing from the correct path.
  6. Next it also provides LogonId which can be used to pivot into the user activities performed based on this logon id.
  7. Similar to step 6, can be done for User field which will provide further activities performed by the user even in different logon times.
  8. Process Id and ParentProcessId can be used to see what are other commands run by the same process.
  9. ParentProcessId can be used to see what are other child processes created at that time using this parent process.
  10. Check all the logs coming from that machine for some time period around this alert.

Leave a Reply

Your email address will not be published. Required fields are marked *