Understanding Sysmon Events using SysmonSimulator

Introduction

I wanted to understand how Sysmon detects various activities on the Windows endpoints and generates the event logs, so I created a tool SysmonSimulator which is written in C and uses Win32 APIs for simulating attack techniques and provides instructions to generate the Sysmon event logs. It can be used by threat detection teams to test the EDR detections and correlation rules. The source code is available on Github and anyone can modify to test it as per their requirements.

Also, a lot of times, I needed raw events for SIEM rule correlation to test the use-cases. I used to search the required tools for generating log data for good, suspicious and malicious events for different attack scenarios to build unit tests for false positives, true positives and false negatives. These type of attack techniques can be simulated using SysmonSimulator to generate event logs by calling the relevant Windows APIs. I’ll use Sysmon for reference in this post, but you can simulate attacks using SysmonSimulator to test other EDR products as well. I will explain all the event IDs logged by Sysmon to show what kind of logs are generated, and why it is important from the monitoring perspective.

Sysmon

Sysmon is a host-level monitoring and tracing tool developed by Mark Russinovich and few other contributers from Microsoft. It is a part of the Sysinternals suite, which is now owned by Microsoft. Sysmon fetches a lot of information about the operations performed on the system and logs them into the Windows Event Viewer. It’s really helpful for threat detection teams because it provides a lot more information in addition to the existing Windows events which helps to better understand detections for different attack scenarios.

Sysmon uses a driver called SysmonDrv.sys and a service that runs in the background. To capture the additional information, the Sysmon driver registers multiple callback routines to gather activities performed by different Windows APIs. Windows kernel notifies the specified actions to the sysmon driver using callback routines. Sysmon also looks into Event Tracing for Windows (ETW). We’ll discuss this further in the event logs section. To filter the noise in the event logs, Sysmon’s event logging can be customized and fine-tuned by defining XML rules in its config file.

Sysmon can be downloaded from here. You can read more about capabilities of Sysmon here.

To install Sysmon service and driver, open a command prompt as an administrator and enter below command:

sysmon64.exe -i –accepteula 

or if you want to install with your custom XML config file, it can be installed as follows:

The installation can be verified as follows:

Below is an example of Sysmon XML config file which can be modified:

The best thing about Sysmon is that it also provides an option to have a more fine-tuned and specific event logging by a set of XML rules, that can be modified in its XML config file as per the detection engineer’s requirements.

SwiftOnSecurity XML config for Sysmon can be referred for more information-

https://github.com/SwiftOnSecurity/sysmon-config/blob/master/sysmonconfig-export.xml

When Sysmon is installed, there are two files that are dropped on the disk :

• C:\Windows\SysmonDrv.sys
• C:\Windows\Sysmon64.exe

The first one SysmonDrv.sys is the driver loaded by Sysmon which registers the kernel notification callbacks. Sysmon sets multiple callbacks on kernel objects in addition to using telemetry APIs and ETW and sets up as a Minifilter driver on all volumes on a system which allows it to see all the file system operations and actions taken by APIs before they are processed by the file system. The driver is loaded by a service at system startup which runs Sysmon64.exe on system boot and keeps requesting the driver to get state of events generated. Below diagram shows the architecture of Sysmon:

Sysmon Events are available in Event Viewer as follows:

Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> Sysmon -> Operational

Sysmon Simulator

Once we have sysmon installed and configured on the system, we’ll use the SysmonSimulator tool to simulate the logs and see how it works. I’ve compiled the code in Visual Studio and opened the help section as follows:

SysmonSimulator requires an event ID from the above parameters list (for example: -eid 1) and the related Windows API function will be called to simulate the attack and Sysmon event log will be generated which can be viewed in the Windows Event Viewer.

Note: Sysmon must be installed on the system where SysmonSimulator needs to run for testing, so that the required events are generated in the Event Viewer.

Event ID 1: Process creation

Process creation events in Sysmon provide extended information about a newly created process including full command line which can help us to understand more about the process execution. To help in the event correlation across all the logs, there is a field called as ProcessGUID which is a unique value for the process. It is linked in other event logs as well. It turns out to be useful to discover suspicious patterns based on parent-child process relationships and the other activities performed by that process and it’s child processes. The bonus feature of event ID 1 is that it also logs the full hash of the file which is helpful for analysts to corelate or do a replutation check for known bad hashes.

For this demonstration, I’ve kept the sysmon configuration file to look only for the child processes created by SysmonSimulator.exe

<!-- -eid 1: Process Creation -->
<ProcessCreate onmatch="include">
    <ParentImage name="SysmonSimulator ProcessCreate Simulation for WMIC.exe" condition="end with">SysmonSimulator.exe</ParentImage>
    <Image condition="end with">wmic.exe</Image>
</ProcessCreate>

When the event ID 1 from SysmonSimulator is executed, it’ll create child process of SysmonSimulator.exe as WMIC.exe using the CreateProcessA WINAPI which can be seen in the below screenshot:

To detect process creation events, Sysmon uses PsSetCreateProcessNotifyRoutine callback routine to monitor the process creation activities performed by APIs like CreateProcess(), CreateProcessAsUser(), CreateProcessWithToken(), CreateProcessWithLogon() and so on.

Event ID 1 - Process Creation - Event data fields and description

Event ID 2: A process changed a file creation time

In Event ID 2, Sysmon detects a technique known as “Timestomping”, in which the file creation times are manipulated to make it look like it is not a recently created file and was installed with the operating system. Manipulating the file times on the Windows is a common anti-forensics technique.

For the PoC, I’ve changed the sysmon configuration file to look only for the file creation time events from SysmonSimulator.exe

<!-- -eid 2: A process changed a file creation time -->
    <FileCreateTime onmatch="include">
        <Image name="SysmonSimulator FileCreateTime modification Simulation for SysmonCreateFileTime.txt" condition="end with">SysmonSimulator.exe</Image>
        <TargetFilename condition="end with">SysmonCreateFileTime.txt
        </TargetFilename>
    </FileCreateTime>

When the event ID 2 from SysmonSimulator is executed, it’ll create a new file as SysmonCreateFileTime.txt using the CreateFileW WINAPI. Then it’ll change it’s creation time to a past date, using the SetFileTime function.

Note: File creation time change does not necessarily indicate malicious activity since many processes legitimately change the creation time of a file.

To detect file creation time change events, Sysmon uses the FltRegisterFilter which is used to register a minifilter to detect the activities when any process tries to change the creation time of a file using the windows API function SetFileTime.

Event ID 2 - File creation time changed - Event data fields and description

Event ID 3: Network connection

In the Sysmon EventID 3, all the TCP and UDP network connections are logged and each network connection is linked to a process through the ProcessId and ProcessGUID fields which is really useful for the correlation. Some important fields are included like the source and destination host names, IP addresses and port numbers.

For the PoC, I’ve changed the sysmon configuration file to look only for the network connection events initiated by SysmonSimulator.exe by specifying the port number:

<!-- -eid 3 is NetworkConnect-->
    <NetworkConnect onmatch="include">
        <DestinationPort name="SysmonSimulator Network connect Simulation for NMAP" condition="is">31337</DestinationPort>
    </NetworkConnect>

When the event ID 3 from SysmonSimulator is executed, it’ll use the Winsock functions to create a new TCP socket, connect to scan.nmap.org on TCP port 31337 and then close the socket.

Note: Usually, event ID 3 generates a large volume of logs, so the sysmon XML configuration file should be properly tuned by creating necessary filters for specific processes and ports.

To detect network connection events, Sysmon takes advantage of Event Tracing for Windows (ETW). ETW is kernel-level tracing that helps to trace and log events that are raised by user-mode applications and kernel-mode drivers to monitor applications and their behavior. Sysmon leverages the ETW callbacks “NT Kernel Logger” specified in the EVENT_TRACE_FLAG_NETWORK_TCPIP under the “SYSMON_TRACE” trace session to capture TCP /UDP which can be seen running in the background as follows:

Event ID 3 - Network connection - Event data fields and description

Event ID 5: Process terminated

In Event ID 5, Sysmon logs the process termination event when a process terminates. It provides the UtcTime, ProcessGuid and ProcessId of the process. For threat detection teams, this event ID is useful to co-relate with process start and shutdown events, if a process may have been terminated by an adversary and also to measure the lifespan of a process by comparing the process termination time with the process creation time to test SIEM behavioural rules.

Below XML config looks for all process termination events:

<!-- -eid 5 is ProcessTerminate-->
    <ProcessTerminate onmatch="exclude">
    </ProcessTerminate>
    

When the event ID 5 from SysmonSimulator is executed, it performs below steps:

1. Asks for a process ID that you want to kill
2. Using that Process ID, it gets the handle to the target process by using OpenProcess function
3. Passes the handle of the target process to TerminateProcess function and terminates the process

The POC can be seen as follows:

To detect process termination events, Sysmon uses the same PsSetCreateProcessNotifyRoutine event registration mechanism and looks for any process termination API like ExitThread(), ExitProcess(), TerminateProcess() and their relevant NTAPIs. To verify which NT API is called when a particular Win32 API to exit the process is called, I tried these different API functions to terminate the process and in the end, ZwTerminateProcess() gets called and kernel terminates the process and all of its threads, and a process termination event gets logged in Event Viewer.

Event ID 5 - Process terminated - Event data fields and description

Event ID 6: Driver loaded

In the Sysmon EventID 6 (driver loaded), the information about a driver being loaded on the system is provided. This event would be helpful in identifying driver based threats such installation of malicious or vulnerable drivers, more importantly the signed ones because they provide a stealthy way to conduct malicious activity. There are various incidents of such activity where a driver is loaded on a system to perform malicious activities, for example- XMRIG coinminer driver (WinRing0x64.sys) which comes in an open source project that is commonly abused by adversaries to infect and mine bitcoin. Threat actors often use kernel drivers to install rootkits or to run the tools that require to run at Kernel level. So as defenders, we should always keep an eye on the drivers in our environment.

This is the tag for logging the DriverLoaded events in the Sysmon config file:

<DriverLoad onmatch="exclude"></DriverLoad>

To just generate the DriverLoaded event log for testing SIEM tools, there is a known way to load a driver WdNisDrv.sys which is signed by Microsoft. It gets loaded when the Windows Defender’s real-time protection is enabled, as shown in the screenshot below:

Let us try to load Non-Microsoft driver for example Mimidrv.sys, which is used with the Mimikatz executable.

Mimikatz is a great tool that also uses a driver to perform a lot of tasks. Some of them are as follows:

• Play with Tokens & Privileges
• Perform BSOD on the system
• Set all privilege on process
• Display SSDT x86 & x64
• List MiniFilters
• List the notify callbacks for process/thread/image/registry
• System Environment Variable Set
• System Environment Variable Delete

Reference: https://blog.gentilkiwi.com/downloads/mimikatz-rmll.pdf

When I load mimidrv.sys into the system which is a non-Microsoft driver, this is how the DriverLoaded event looks like:

To detect driver loading events, Sysmon uses the PsSetLoadImageNotifyRoutine event registration mechanism, which registers a callback for this activity.

Event ID 6 Driver loaded - Event data fields and description

Event ID 7: Image loaded

In the Sysmon Event ID 7, the information is logged when a module is loaded in a specific process. This is useful to monitor the suspicious libraries or combinations used by threat actors.

This is the tag for logging the ImageLoaded events in the Sysmon config file. For the PoC, I am just looking for crypt32.dll module loaded by SysmonSimulator.exe.

<!-- -eid 7 is ImageLoad-->
    <ImageLoad onmatch="include">
        <Image condition="end with">SysmonSimulator.exe</Image>	
        <ImageLoaded condition="end with">crypt32.dll</ImageLoaded>
    </ImageLoad>

When the event ID 7 from SysmonSimulator is executed, it calls the LoadLibraryA function to Load the crypt32.dll module into the address space of the SysmonSimulator.exe. This is how the event looks like:

You can create custom filters to search for specific modules to be loaded by the processes. For example- looking for a custom process loading the PowerShell engine System.Management.Automation.dll.

<ImageLoaded condition="end with">System.Management.Automation.dll</ImageLoaded>

To detect image loading events, Sysmon uses the same PsSetLoadImageNotifyRoutine event registration mechanism, which registers a callback for this all image loading activities performed by different API functions such as ImageLoad(), NtMapViewOfSection(), LoadLibrary() and so on.

Event ID 7 Image loaded - Event data fields and description

Event ID 8: CreateRemoteThread

In the Sysmon event ID 8 (CreateRemoteThread), a log is generated when a process creates a thread in another process by using the CreateRemoteThread function. This technique is used by malware to inject code and hide in other processes. The event indicates the source and target process. It gives information on the code that will be run in the new thread: StartAddress, StartModule and StartFunction.

This is the tag for logging the CreateRemoteThread events in the Sysmon config file. For the PoC, I am just looking for remote threads created by SysmonSimulator.exe.

<!-- -eid 8 is CreateRemoteThread-->
    <CreateRemoteThread onmatch="include">
        <SourceImage condition="end with">SysmonSimulator.exe</SourceImage>		
    </CreateRemoteThread>
    

When the event ID 8 from SysmonSimulator is executed, it performs below steps:

1. Creates a new suspended process PING.exe using the CreateProcessA function and gets its Process ID.
2. Open a target process using OpenProcess function by passing it the process ID acquired from created process.
3. Allocate memory in the remote process by passing the handle of the process PING.exe to the VirtualAllocEx function.
4. Write the code to print message box which is stored in the variable shellcode to the allocated section using the WriteProcessMemory function.
5. Create a new thread in the remote process by using the CreateRemoteThread function to execute the shellcode.

The POC can be seen as follows:

In these type of events, the StartAddress field shows the address of the target process where the new thread starts. We can use Process Hacker to see what is there in that address. It can be seen that a new thread is created into the remote process starting at the address of our MessageBox shellcode that was loaded by SysmonSimulator into the allocated virtual memory space of the target process.

To detect CreateRemoteThreat events, Sysmon uses the PsSetCreateThreadNotifyRoutine event registration mechanism, which registers a callback when a new thread is created and when such a thread is deleted.

Event ID 8 - CreateRemoteThread - Event data fields and description

Event ID 9: RawAccessRead

Sysmon Event ID 9 (RawAccessRead) is logged when a process performs read operations on the drive using the \.\ syntax. This technique is often used by malware for data exfiltration of files that are locked for reading, as well as to avoid file access auditing tools. Threat actors use this technique to copy important files such as NTDS.dit and SAM Registry hives from the host to do credential harvesting.

This is the tag for logging the RawAccessRead events in the Sysmon config file. For the PoC, I am just looking for RawAccessRead by SysmonSimulator.exe.

<!-- -eid 9 is RawAccessRead-->
    <RawAccessRead onmatch="include">
        <Image condition="end with">SysmonSimulator.exe</Image>
    </RawAccessRead>

When eid 9 is executed from SysmonSimulator, it calls the CreateFile() function to search C drive using the \.\ denotation:

In this event. the important fields that are present are source process and the target device it is trying to read.

Note: Normally, no legitimate process should be performing this kind of activity. It is mostly performed by softwares like the backup tools or drive imaging tools in a normal environment.

To detect RawAccessRead events, Sysmon uses the FltRegisterFilter which is used to register a minifilter to detect the activities when any process tries to read a drive using the \.\ denotation using APIs such as NtCreateFile(), CreateFile(), ObpLookupObjectName() and so on.

Event ID 9 - Raw access read - Event data fields and description

Event ID 10: ProcessAccess

Sysmon Event ID 10 (ProcessAccess) is logged when a process tries to open another local process object by using OpenProcess function. This is a type of operation that is often performed to read and write in the address space of the target process. This event can help in enabling the detection of malicious tools that read the memory contents of processes like lsass.exe (Local Security Authority) in order to steal credentials.

If a target process is opened with higher permissions, it is possible to perform operation like reading the data from target process memory, patching its memory, process hollowing, creations of threads in the target process like we did in Event ID 8 (CreateRemoteThread) that are commonly performed by adversaries.

This is the tag for logging the ProcessAccess events in the Sysmon config file. For the PoC, I am just looking for Processes accessed by SysmonSimulator.exe.

<!-- -eid 10 is ProcessAccess-->
    <ProcessAccess onmatch="include">
        <SourceImage condition="end with">SysmonSimulator.exe</SourceImage>
    </ProcessAccess>

When the event ID 10 from SysmonSimulator is executed, it performs below steps:

1. Asks the user for a process ID of the target process to be accessed
2. Accesses the process handle by calling OpenProcess function
3. Closes the handle and exits

Open a target process OpenProcess function by passing it the process ID acquired from created process.

Note: I tried to open process using the NtOpenProcess NTAPI function instead of WINAPI function OpenProcess and sysmon detected that as well.

In this event, the most important field is CallTrace which can be used by threat detection teams to create different use cases. The calltrace provides the DLL and the relative virtual address of the functions in the call stack right before the OpenProcess call which would be really helpful to find which functions are called to performed specific actions.

I will demonstrate how we can use the Calltrace field to detect Credential dumping performed using MiniDumpWriteDump().

MiniDumpWriteDump() is an exported function from the DLL dbgcore.dll

It is located at offset 6cfb in dbgcore.dll, so I will add this condition in the Sysmon config as follows:

		<!-- -eid 10 Process accessed (Credential dumping)-->
    <ProcessAccess onmatch="include">
        <SourceImage condition="end with">dumplsass.exe</SourceImage>
        <CallTrace condition="contains" name="Credential dumping performed by using function MiniDumpWriteDump from dbgcore.dll">C:\Windows\SYSTEM32\dbgcore.DLL+6cfb</CallTrace>
    </ProcessAccess>

Now, I will dump the LSASS memory by calling MiniDumpWriteDump() from a custom program dumplsass.exe. Once the function is called, an event log is generated which matches the above condition as seen in the below screenshot:

That was an example of using the Calltrace field to detect Credential dumping performed using MiniDumpWriteDump(). Similarly, other use cases can be created by leveraging information from the calltrace.

To detect ProcessAccess events, Sysmon uses the ObRegisterCallbacks which is used to register a list of callback routines for thread, process, and desktop handle operations to detect the activities when any process tries to open handle of other processes using APIs such as [OpenProcess()](https://docs.microsoft.com/en-us/windows https://exatrack.com/public/SysmonInternals.pdf

Event ID 10 - Process Access- Event data fields and description

Event ID 11: FileCreate

In Sysmon Event ID 11 (FileCreate), creation of files and information of the process creating the file is logged when a file is created or overwritten. This event is important to monitor the locations like startup folder, as well as temporary and download directories, which are common places malware drops during initial infection.

This is the tag for logging the FileCreate events in the Sysmon config file. For the PoC, I am just looking for files created by SysmonSimulator.exe.

<!-- -eid 11 is FileCreate-->
    <FileCreate onmatch="include">
        <Image condition="end with">SysmonSimulator.exe</Image>
    </FileCreate>
    

When the event ID 11 from SysmonSimulator is executed, it’ll create a new file as NewFile.bat using the CreateFileW WINAPI.

Note: If there’s another AntiVirus or EDR minifilter driver on the system having lower altitude number range than sysmon and it detects a malicious file and blocks it writing to disk, Sysmon will not log the event because that minifilter driver will load before Sysmon due to its lower altitude number range.

Sysmon has a predefined altitude of 385201. We can check the altitute range of the filter drivers using fltmc.exe

To detect FileCreate events, Sysmon uses the FltRegisterFilter which is used to register a minifilter to detect the activities when any process tries to create a file using APIs such as NtCreateFile(), CreateFile() and so on.

Event ID 11 - File create- Event data fields and description

Event ID 12: RegistryEvent- Object create and delete

In Sysmon Event ID 12, Registry key and value create and delete operations are detected, which are useful for monitoring the changes to Registry autostart locations, or to look for suspicious additions to registry keys such as Run, RunOnce and several other keys, by analyzing all values in the specified registry keys and find anomalous ones based on commonality in the environment.

Sysmon uses abbreviated versions of Registry root key names, with the following mappings:

This is the tag for logging the Registry Events in the Sysmon config file. For the PoC, I am just looking for Registry Events created by SysmonSimulator.exe.

<!-- -eid 12,13,14 are RegistryEvent-->
    <RegistryEvent onmatch="include">
        <Image condition="end with">SysmonSimulator.exe</Image>
    </RegistryEvent>
    

When the event ID 11 from SysmonSimulator is executed, it’ll create a new registry key as TestSysmon using the RegCreateKeyA function.

To detect these Registry events, Sysmon driver registers a registry callback routine using the CmRegisterCallback to detect the activities when any process tries to create or delete registry object using APIs such as RegCreateKey(), NtCreateKey(), NtDeleteKey(), RegDeleteTree(), RegDeleteValue(), RegDeleteKey(), and so on.

Tip: Look for processes that are involved in malicious registry activity (for example- MS office macro creating the registry key)

Event ID 12 - Registry event (Object create and delete)- Event data fields and description

Event ID 13: RegistryEvent- Value Set

Sysmon Event ID 13 identifies the Registry value modifications on a system. This event records the value written for Registry values of type DWORD and QWORD.

When the event ID 13 from SysmonSimulator is executed, it’ll perform below steps:

1. Try to open TestSysmon registry key by using RegOpenKeyExA. If doesn’t exist, it’ll create it using RegCreateKeyA function.
2. Sets the data and type of the test value under the registry key using RegSetValueExA function.

To detect these Registry events, Sysmon driver registers a registry callback routine using the CmRegisterCallback to detect the activities when any process tries to set value of registry object using APIs such as NtSetValueKey(), RegSetValue(), and so on.

Event ID 13 - Registry event (Value set)- Event data fields and description

Event ID 14: RegistryEvent- Key and Value Rename

Sysmon Event ID 14 detects the Registry key and value rename operations and include the new name of the key or value that was renamed.

When the event ID 14 from SysmonSimulator is executed, it’ll perform below steps:

1. Creates a new registry key NewRegistrySysmonTesting using RegCreateKeyA function.
2. Renames it to RegistrySysmonTestingRenamed using RegRenameKey function

You can see the three TargetObject and NewName for the changes made to the registry object.

To detect these Registry events, Sysmon driver registers a registry callback routine using the CmRegisterCallback to detect the activities when any process tries to rename registry key or its value using APIs such as NtRenameKey().

Event ID 14 - Registry event (Key and value rename)- Event data fields and description

Event ID 15: FileCreateStreamHash

Sysmon Event ID 15 logs the creation of Alternate Data Streams (ADS). Malware variants can drop their executables or configuration settings via browser downloads, and this event is aimed at capturing that based on the browser attaching a Zone.Identifier “mark of the web” stream. This is an technique used by malware variants to create the ADS on files where the alternate stream is a PE executable to hide information.

This is the tag for logging the FileCreateStreamHash events in the Sysmon config file. For the PoC, I am just looking for FileCreateStreamHash events created by SysmonSimulator.exe.

<!-- -eid 15 is FileCreateStreamHash-->
    <FileCreateStreamHash onmatch="include">
        <Image condition="end with">SysmonSimulator.exe</Image>
    </FileCreateStreamHash>

When the event ID 15 from SysmonSimulator is executed, it’ll perform below steps:

1. Create a new file as Streamfile.txt:SysmonStream using the CreateFileW WINAPI.
2. Get the handle to the file
3. Pass the file handle to the WriteFile function
4. Writes data to the specified file stream

To detect FileCreateStreamHash events, Sysmon uses the FltRegisterFilter which is used to register a minifilter to detect the activities when any process tries to create a file stream using APIs such as NtCreateFile(), CreateFile() and so on.

Event ID 15 - File create stream hash- Event data fields and description

Event ID 17: PipeEvent- Pipe Created

In Sysmon event ID 17, an event is generated when a named pipe is created. Named Pipes are a method of inter-process communication in Windows operating systems which are primarily used for local processes to communicate with eachother but can also support the communication between two processes on separate machines by using the Microsoft SMB Protocol.

Malware often uses named pipes for interprocess communication. Command and Control frameworks like Cobalt Strike use named pipes in its SMB Beacon feature and for most of its post-exploitation jobs.

This is the tag for logging the Pipe events in the Sysmon config file. For the PoC, I am just looking for Pipe events created by SysmonSimulator.exe.

<!-- -eid 17 and 18 are PipeEvent-->
    <PipeEvent onmatch="include">
        <Image condition="end with">SysmonSimulator.exe</Image>
    </PipeEvent>

When the event ID 17 from SysmonSimulator is executed, it’ll create a named pipe \\.\pipe\sysmontestnamedpipe using CreateNamedPipeA function as shown in the below screenshot:

To detect Pipe creation events, Sysmon uses the IoSetCompletionRoutineEx which registers an IoCompletion routine. API calls for pipe creation activity are CreateNamedPipeFile() and CreateNamedPipe().

Event ID 17 - Pipe event (Pipe created) - Event data fields and description

Event ID 18: PipeEvent- Pipe Connected

In Sysmon event ID 18, an event log is generated when a named pipe connection is made between a client and a server. It is important to monitor these pipe events because named pipes are commonly used for pivoting and to communicate to the injected code in the other processes.

When the event ID 18 from SysmonSimulator is executed, it’ll perform below steps:

1. Create a named pipe \\.\pipe\sysmontestconnectpipe using CreateNamedPipeA function
2. Connect to the named pipe using CreateFileA function

To detect Pipe connection events, Sysmon uses the IoSetCompletionRoutineEx which registers an IoCompletion routine. API calls for pipe connection activity are ConnectNamedPipe(), CreateFileA, NtCreateFile() and CallNamedPipe().

Event ID 18 - Pipe event (Pipe Connected) - Event data fields and description

Event ID 19: WmiEvent - WmiEventFilter activity detected

Windows Management Instrumentation Event Subscription is a documented technique in MITRE ATT&CK framework. Threat actors use the capabilities of WMI to install event filters, providers, consumers, and bindings that execute code when a defined event occurs to establish persistence on a system. The reason to look into WMI Event Subscription events is that WMI provides ways to achieve persistence for threat actors, so it is important for defenders to understand how WMI is abused and how to catch this activity.

WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for accessing management information in an enterprise environment. WMI uses the Common Information Model (CIM) industry standard to represent systems, applications, networks, devices, and other managed components.

In Sysmon Event ID 19, we’ll look for WMI Event Filter activity. An event filter is a WMI class that describes which events WMI delivers to an event consumer. An event filter also describes the conditions under which WMI delivers the events. When a WMI event filter is registered, which is a method used by malware to execute, this event logs the WMI namespace, filter name and filter expression.

This is the tag for logging the WMI events in the Sysmon config file to detect WMI abuse. It is recommended to log all instances of this event type.

<WmiEvent onmatch="exclude">
    </WmiEvent>

For this PoC, we’ll create a permanent event that will track service state changes into a text file Log.log. This means if I stop a service, it’ll be logged in the log file. This will generate all three sysmon event IDs WmiEventFilter(19), WmiEventConsumer(20) and WmiEventConsumerToFilter(21). Steps to perform this are as follows:

1. Register a WMI event filter named as “ServiceFilter”
2. Register a WMI event consumer named as “ServiceConsumer”
3. Bind the event consumer to the event filter

Let’s start with WMI event filter. Event ID 19 from SysmonSimulator will show the instructions on how to create a __EventFilter that will check for a modification of the Win32_Service class every 5 seconds:

Event ID 19 - WMI event (WmiEventFilter activity detected) - Event data fields and description

Now that the event filter has been registered. We’ll create a WMI Event consumer in the next step.

Event ID 20: WmiEvent - WmiEventConsumer activity detected

In Sysmon event ID 20, registration of WMI consumers is logged. This event records the consumer name, log, and destination. In this event, the Destination field is important from monitoring perspective, because it shows the command or script being executed which can contain stager code or any interesting encoded strings.

Event ID 20 from SysmonSimulator will show the instructions on how to create a Event Consumer that will create a log file Log.log in C drive

Event ID 20 - WMI event (WmiEventConsumer activity detected) - Event data fields and description

Now the event consumer has been created as well. We’ll bind the WMI Event consumer to the Event filter in the next step.

Event ID 21: WmiEvent- WmiEventConsumerToFilter activity detected

Sysmon event ID 21 is generated when a consumer binds to a filter. This event logs the consumer name and filter path which is important from monitoring perspective.

Event ID 20 from SysmonSimulator will show the instructions on how to create a Event Consumer that will create a log file Log.log in C drive

This will create a __FilterToConsumerBinding class instance using the __EventFilter and the LogFileEventConsumer class instance we created earlier. Now, this PoC code will monitor for any change of state change in the Windows services and log them in the C:\Log.log file when the service state changes. Similarly a threat actor can abuse this WMI capability by monitoring for specific events by using subscriptions and take certain actions when these events occur.

Make sure to perform cleaning after testing WMI events, so that the WMI objects will be removed.

Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding -Filter "__Path LIKE '%ServiceFilter%'" | Remove-WmiObject -Verbose
Get-WMIObject -Namespace root\Subscription -Class LogFileEventConsumer -Filter "Name='ServiceConsumer'" | Remove-WmiObject -Verbose
Get-WMIObject -Namespace root\Subscription -Class __EventFilter -Filter "Name='ServiceFilter'" | Remove-WmiObject -Verbose

To detect WMI activity, Sysmon uses ExecNotificationQueryAsyn() OR ExecNotificationQuery WMI callbacks to monitor operations performed by COM APIs. This callback filters three WMI classes __EventFilter, __EventConsumer, and __FilterToConsumerBinding

Event ID 21 - WMI event (WmiEventConsumerToFilter activity detected) - Event data fields and description

Event ID 22: DNSEvent - DNS query

Sysmon Event ID 22 is generated when a process executes a DNS query using the DnsQuery_A API call, whether the result is successful or failed, cached or not. The telemetry for this event was added for Windows 8.1, so it is not available on Windows 7 and earlier because it leverages new ETW functionality in newer versions of Windows. Programs that do their own DNS resolution and do not use the Windows API calls will not be logged.

This is the tag for logging the DNS events in the Sysmon config file. For the PoC, I am just looking for DNS events created by SysmonSimulator.exe.

<!-- -eid 22 is DnsQuery-->
    <DnsQuery onmatch="include">
        <Image condition="end with">SysmonSimulator.exe</Image>
    </DnsQuery>
    

When the event ID 22 from SysmonSimulator is executed, it’ll perform a lookup for domain google.com using the DnsQuery_A API call

Note: It is recommended to exclude known domains in the sysmon config for this event such as Microsoft domains, Windows update, browser update domains etc. This event is useful to detect processes looking up for malicious/phishing domains.

To detect DNS query events, Sysmon uses ETW as it can be seen as follows

The “SysmonDnsEtwSession” is the one that provides the DNS data to Sysmon

As it can be seen from the screenshot, Sysmon gets this information from this ETW Provider Microsoft-Windows-DNS-Client

Event ID 22 - DNS - Event data fields and description

Event ID 23: FileDelete (File Delete archived)

Sysmon will log Event ID 23 when a file gets deleted. Additionally to logging the event, the deleted file is also saved in the ArchiveDirectory (which is C:\Sysmon by default) and it can be changed to a different directory. Under normal operating conditions, this directory might grow to an unreasonable size. To make sure not all files gets archived, there is a separate event ID 26: FileDeleteDetected for similar behavior but without saving the deleted files.

This is the tag for logging the File Delete archived events in the Sysmon config file. For the PoC, I am just looking for File Delete archived events created by SysmonSimulator.exe.

<!-- -eid 23 is FileDelete-->
    <FileDelete onmatch="include">
        <Image condition="end with">SysmonSimulator.exe</Image>
    </FileDelete>

When the event ID 23 from SysmonSimulator is executed, it’ll create a file NewFile.bat and delete it by using the DeleteFile function.

As it can be seen in the above screenshot that the Archived attribute is True for this batch file. So, even if the file is deleted, it is still automatically archived by Sysmon in its Archive Directory. This allows forensic investigators to grab the sample to learn more about how an attack took place, because threat actors commonly clean their executables or initial access payloads from the system.

To detect file deletion events, Sysmon uses the FltRegisterFilter which is used to register a minifilter to detect the activities when any process tries to delete a file using the windows API function DeleteFile and NtDeleteFile()

Event ID 23 - File Delete event- Event data fields and description

Event ID 24: ClipboardChange - New content in the clipboard

Sysmon Event ID 24 is generated when the system clipboard content gets changed i.e. when an application stores text in the clipboard. The data in clipboard may be sensitive because it may contain usernames, passwords, personal information as well. So this is a reason that the data is not stored in the event log but in a folder whose location is controlled by the <ArchiveDirectory> element in the configuration XML file and its permissions are controlled using ACLs. This type of event logging should not be enabled on all end-user machines because of the risk of unencrypted sensitive data being stored, but it can be configured on sensitive machines such as servers that have RDP enabled and exposed to untrusted networks by making sure that the sys admins are aware that this is enabled. But we’ll understand how it is done programmatically.

This is the tag for logging the ClipboardChange events in the Sysmon config file. For the PoC, I am just looking for ClipboardChange events created by SysmonSimulator.exe.

<!-- -eid 24 is ClipboardChange-->
    <ClipboardChange onmatch="include">
        <Image condition="end with">SysmonSimulator.exe</Image>
    </ClipboardChange>

When the event ID 24 from SysmonSimulator is executed, it’ll perform below steps:

1. Allocate a global block of memory using GlobalAlloc() function
2. Copy the Data into the Global Memory using memcpy() function
3. Unlock the Global Memory using GlobalUnlock() function
4. Open the Clipboard using OpenClipboard() function
5. Empty the Clipboard using EmptyClipboard() function
6. Call SetClipboardData() function to set the Clipboard Data in standard text format ("New Sysmon Test data in clipboard")
7. Close the Clipboard using CloseClipboard() function
8. Free the specified global memory object using GlobalFree() function

Few points to understand:

• Clipboard is created and maintained by the application that is making this data available for other applications. Since the data in the clipboard must be accessible from all processes, the Windows API functions, GlobalAlloc and GlobalLock, are used. GlobalAlloc() function is used to allocate that will hold the data being made available via the Clipboard. We’ll specify how the memory is to be allocated and how large a buffer we want to allocate.

• Another requirement is that the window must be the current clipboard owner. To do this, we open the clipboard using OpenClipboard() function and call the EmptyClipboard() function that empties the clipboard and assigns ownership of the clipboard to the window that currently has the clipboard open.

Below is an example of the event that gets created when clipboard gets changed. It will not, though, show the actual data that was copied.

• When SetClipboardData() sets the text in clipboard, the event is generated and the text that was copied in to clipboard is stored as a file referenced by the hash in the location specified for deleted files

Sysmon could not capture the process and user information when I performed this programatically. Normally, it should display the information of the process that stored the data in the clipboard, the user who copied it, and when it was done. It will not, though, show the actual data that was copied because it gets stored in the Archive Directory.

Note: Before creating filters for this event type, an element of <CaptureClipboard/> needs to be added under the Sysmon element in the Sysmon config xml.

Event ID 24 - Clipboard event- Event data fields and description

Event ID 25: ProcessTampering - Process image change

Sysmon event ID 25 is generated when process hiding techniques such as “process hollowing” or “process herpaderping” are detected in which the original image of a process is replaced in memory or on disk. In this attack, a process is launched in suspended state. Then the memory for the image is unmapped and realigned to another image injected in to memory. It is then resumed to execute the injected image. MITRE has covered it in Process Hollowing technique. The other technique is Process Herpaderping in which the content on disk is modified after the image has been mapped. This capability was added later in Sysmon.

This is the tag for logging the ProcessTampering events in the Sysmon config file. For the PoC, I am just looking for ProcessTampering events created by SysmonSimulator.exe.

<!-- -eid 25 is ProcessTampering-->
    <ProcessTampering onmatch="include">
        <Image name="SysmonSimulator ProcessTampering Simulation" condition="end with">cmd.exe</Image>
    </ProcessTampering>

For this PoC, we’ll perform process hollowing attack and see what event is generated in Sysmon.

When the event ID 25 from SysmonSimulator is executed, it’ll perform below steps:

1. Start the target application using CreateProcessW (c:\windows\system32\cmd.exe) in suspended state
2. Open the replacement executable using CreateFileW (c:\Windows\System32\svchost.exe)
3. Get the size of the replacement executable using GetFileSize
4. Allocate memory for the executable file using VirtualAlloc
5. Read the executable file from disk using ReadFile
6. Unmap the executable image using NtUnmapViewOfSection function
7. Write the replacement executable into target application using NtWriteVirtualMemory NATIVE API
8. Write the new address of the executable into the PEB and set the eax register of primary thread to the entry point of replacement executable
9. Resume the thread using the NtResumeThread

The replacement executable then runs in the address space of the target process i.e cmd.exe, and waits for the target process to terminate. After the target process terminates, the injector exits.

Sysmon will log the Event ID 25 mentioning that the Image is replaced

Event ID 25 - Process Tampering- Event data fields and description

Event ID 26: FileDeleteDetected - File Delete logged

Sysmon Event ID 26 is generated when a file gets deleted without archiving the deleted file. This event is identical to Event ID 23 (File Delete) but the difference is that file is not archived in the configured archived directory. This was created to make sure specific files/folders are not archived, whether the archiving is on or not. This event ID is recommended for those cases where there is a large number of false positive for a given rule but still it is of value to log the action. This is also applicable for files that could be of great size like archive file or image files like ISO, IMG and others.

This is the tag for logging the File Delete logged events in the Sysmon config file. For the PoC, I am just looking for File Delete logged events created by SysmonSimulator.exe.

<!-- -eid 26 is FileDeleteDetected-->
    <FileDeleteDetected onmatch="include">			
        <Image condition="end with">SysmonSimulator.exe</Image>
    </FileDeleteDetected>

When the event ID 26 from SysmonSimulator is executed, it’ll perform below steps:

Event ID 26 - File Delete Detected- Event data fields and description

References

• https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
• https://www.cobaltstrike.com/help-smb-beacon
• https://blog.cobaltstrike.com/2015/10/07/named-pipe-pivoting
• https://www.darkoperator.com/blog/2017/10/15/sysinternals-sysmon-610-tracking-of-permanent-wmi-events
• https://blog.palantir.com/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63
• https://github.com/trustedsec/SysmonCommunityGuide
• http://undocumented.ntinternals.net/
• https://posts.specterops.io/uncovering-the-unknowns-a47c93bb6971