Learn to detect threats on Windows by monitoring Sysmon events
Windows provides an event log collection tool that includes all generated events and is organized in channels. The main channels are System, Application, and Security. In these channels, events are stored depending on whether they were created by a system action, an active audit policy, or if they have information related to the software installed on the system.
Wazuh collects the events from those channels and is equipped with a Windows ruleset that allows it to inform about important events that happen in our Windows servers. Monitoring Sysmon logs is an interesting application for this service. Sysmon is a Windows tool that records system activity and detected anomalies in the event log.
This article details how it is possible to monitor threat activity using Sysmon. Although here the Wazuh agent will be configured to monitor logs in the Sysmon channel, this configuration could be extended to any of the available channels.
The log messages generated can be checked out using Windows Event Viewer. This tool allows us independent inspection of these recorded events. Each log entry shows all the event information through a message that describes the origin of the event as well as other specific parameters considered in the event. This post is an enhancement of Using Wazuh to monitor Sysmon events, as Wazuh capabilities have been improved to collect EventChannel logs since version 3.8.0.
Prerequisites
- Wazuh 3.8 or later
- Windows Vista or later
Sysmon event collection
We need to configure the agent to keep track of the processes and monitor the logs from Sysmon. In this post, we learn to monitor the Inter-process access, the Process creation, and the Remote thread creation of Mimikatz. This experimental threat is a command-line tool that allows the execution of different operations which may appear suspicious to Sysmon, and therefore, will be registered in the Sysmon section in the Windows event log.
To install and configure Sysmon, follow these steps:
1. Download Sysmon.
2. Create an XML configuration file named sysconfig.xml with the information below. Then, move it to the folder where the Sysmon binaries are contained.
<Sysmon schemaversion="4.10">
<HashAlgorithms>md5</HashAlgorithms>
<EventFiltering>
<!--SYSMON EVENT ID 1 : PROCESS CREATION-->
<ProcessCreate onmatch="include">
<Image condition="contains">mimikatz.exe</Image>
</ProcessCreate>
<!--SYSMON EVENT ID 2 : FILE CREATION TIME RETROACTIVELY CHANGED IN THE FILESYSTEM-->
<FileCreateTime onmatch="include" />
<!--SYSMON EVENT ID 3 : NETWORK CONNECTION INITIATED-->
<NetworkConnect onmatch="include" />
<!--SYSMON EVENT ID 4 : RESERVED FOR SYSMON STATUS MESSAGES, THIS LINE IS INCLUDED FOR DOCUMENTATION PURPOSES ONLY-->
<!--SYSMON EVENT ID 5 : PROCESS ENDED-->
<ProcessTerminate onmatch="include" />
<!--SYSMON EVENT ID 6 : DRIVER LOADED INTO KERNEL-->
<DriverLoad onmatch="include" />
<!--SYSMON EVENT ID 7 : DLL (IMAGE) LOADED BY PROCESS-->
<ImageLoad onmatch="include" />
<!--SYSMON EVENT ID 8 : REMOTE THREAD CREATED-->
<CreateRemoteThread onmatch="include">
<SourceImage condition="contains">mimikatz.exe</SourceImage>
</CreateRemoteThread>
<!--SYSMON EVENT ID 9 : RAW DISK ACCESS-->
<RawAccessRead onmatch="include" />
<!--SYSMON EVENT ID 10 : INTER-PROCESS ACCESS-->
<ProcessAccess onmatch="include">
<SourceImage condition="contains">mimikatz.exe</SourceImage>
</ProcessAccess>
<!--SYSMON EVENT ID 11 : FILE CREATED-->
<FileCreate onmatch="include" />
<!--SYSMON EVENT ID 12 & 13 & 14 : REGISTRY MODIFICATION-->
<RegistryEvent onmatch="include" />
<!--SYSMON EVENT ID 15 : ALTERNATE DATA STREAM CREATED-->
<FileCreateStreamHash onmatch="include" />
<PipeEvent onmatch="include" />
</EventFiltering>
</Sysmon>
3. In the Sysmon folder, launch the CMD with administrator privileges and install the file with the following command:
Sysmon64.exe -accepteula -i sysconfig.xml
For testing purposes, we install Mimikatz, a leading post-exploitation tool that dumps passwords from memory, as well as hashes, PINs, and Kerberos tickets. Mimikatz is considered dangerous as it can be associated with malware or unwanted software, do not install it on production environments.
To test this use case and now that the configuration file for Sysmon has been loaded, download Mimikatz.
The Process creation event is the first matching event. Running the mimikatz.exe binary generates this event, and it can be seen in the Event Viewer application in the Sysmon section (Applications and Services Logs/Microsoft/Windows/Sysmon/Operational).
Mimikatz process execution:
The generated event is recorded in the Windows event log.
In this event, there are two major structures: System and EventData. The first one is formed by generic metadata, while the second one includes specific fields for each type of event. All these fields are collected and processed by Wazuh.
Configuring Wazuh to collect Sysmon events
Once the Wazuh agent is installed and running on the computer being monitored, we need to set up the agent to monitor Sysmon events. To do that, this code must be included in the agent’s configuration file:
<localfile> <location>Microsoft-Windows-Sysmon/Operational</location> <log_format>eventchannel</log_format> </localfile>
Restart the agent to apply the changes.
Using this configuration, Sysmon events are checked and retrieved by Wazuh. After the Wazuh manager has collected the events, it uses an internal decoder to translate them into JSON format. Going further, creating rules provides a higher level of control because it involves triggering alerts, a more visual way to keep track of what is happening in the system.
As configured in the XML file, the events to be monitored in this case are events ID 1 (Process creation), ID 8 (Remote thread creation), and ID 10 (Process access). We can use the generic Sysmon rules included in the Wazuh ruleset as the parents of the custom rules created for this use case.
To monitor these events, the following rules are added to the rules/local_rules.xml file
<group name="windows, sysmon, sysmon_process-anomalies,">
<rule id="100000" level="12">
<if_group>sysmon_event1</if_group>
<field name="win.eventdata.image">mimikatz.exe</field>
<description>Sysmon - Suspicious Process - mimikatz.exe</description>
</rule>
<rule id="100001" level="12">
<if_group>sysmon_event8</if_group>
<field name="win.eventdata.sourceImage">mimikatz.exe</field>
<description>Sysmon - Suspicious Process mimikatz.exe created a remote thread</description>
</rule>
<rule id="100002" level="12">
<if_group>sysmon_event_10</if_group>
<field name="win.eventdata.sourceImage">mimikatz.exe</field>
<description>Sysmon - Suspicious Process mimikatz.exe accessed $(win.eventdata.targetImage)</description>
</rule>
</group>
The next step is to restart the manager to apply the new rules.
Evaluating results
Two operations can be executed with Mimikatz in order to generate the alerts that would match the rules in the previous section. One of them consists of simply running mimikatz.exe, which creates a Process creation event as can be seen in the Windows event log image above. The second one is based on retrieving credentials from the SamSs service, which is the Local Security Authentication Server. This last operation creates a Remote thread, connects to the SAM API, and accesses the domain.
The following images show the execution of these two operations and the events produced by them.
Events generated from the performed actions are recorded in the Sysmon section of the event log:
In the next screenshot from the Event Viewer, we can see one of these events in detail, specifically, the Remote thread creation event:
The events collected by the Wazuh agent are forwarded to the manager where they are processed by the Windows decoder and evaluated against the rules engine. Here we can see alerts generated from the Wazuh user interface side.
Remote Thread creation alert:
Suspicious access alert:
To sum up, we have used the Mimikatz threat tool to experiment with Windows security. This example can serve as a reference to monitor and report each event of interest in the EventChannel log format. For example, audit policies can be enabled at the Group Policy Editor so that events, like terminating a process or changing the privileges of an archive, can be monitored.
The possibilities are many, and monitoring the Windows event log with Wazuh is as simple as configuring the agent to monitor any desired channel such as the Sysmon channel as explained in this use case.
References
If you have any questions about this, join our Slack community channel! Our team and other contributors will help you.