Windows provides an event log collection tool, organized into channels, which includes every event generated. The main channels are System, Application and Security, where events will be stored depending on whether they were created by a system action, an active audit policy or if they have information related to software installed in the system.
Wazuh collects events from those channels and provides a new Windows ruleset which makes us aware of important events happening in our Windows servers. Monitoring Sysmon could be an interesting application for this service. It consists of a Windows tool that records system activity and anomaly detection events in the event log, and it is a sub program from Winternals, a subdivision of Microsoft created by Mark Russinovich.
This article will describe the steps to monitor a threat’s activity with Sysmon. In this case, the Wazuh agent will be set up to monitor the logs from the Sysmon channel, but this configuration can be extended to the rest of the available channels.
To accomplish this goal, we will view the log messages generated on the EventViewer, which permits the visualization of recorded events. Each log entry shows all the event information through a main message which describes the origin of the event and other specific parameters considered in the event. In addition, this post is an update to Using Wazuh to monitor Sysmon events, as the capabilities of Wazuh have been improved to collect EventChannel logs since v3.8.0.
- Wazuh v3.8+
- Windows Vista or higher
Sysmon event collection
In order to monitor the logs from Sysmon, it is necessary to configure the agent to keep track of the desired processes. Our purpose in this post is 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 permits the execution of different operations which may appear suspicious to Sysmon, and therefore, they will be registered in the Sysmon section in the Windows event log. These are the installation and configuration steps:
- Download Sysmon at this link.
- 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>
- Launch CMD with administrator privileges in the Sysmon folder and install the file with the following command:
Sysmon64.exe -accepteula -i sysconfig.xml
Now that the configuration file for Sysmon has been loaded, download Mimikatz from this link.
The first event to be matched will be the process creation event. Executing the mimikatz.exe binary generates that event, and it can be seen in the EventViewer 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, two main structures are differentiated, System and EventData. The first one is composed of generic metadata, while the second one includes particular fields for each kind of event. All of those fields are gathered and processed by Wazuh, as will be explained below.
Configuring Wazuh to collect Sysmon events
Once the Wazuh agent is installed and running in the computer being monitored, it is necessary 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>
It is necessary to restart the agent to apply the changes.
With this configuration, Sysmon events will be checked and retrieved by Wazuh. Once the Wazuh manager has gathered the events, it uses an internal decoder for translating them into JSON format. Going further, the creation of rules can imply a higher level of monitoring, because it involves alert triggering, which is a more visual form of keeping track of what is happening in the system.
As configured in the XML file, the events that will be monitored in this case will be events 1 (process creation), 8 (remote thread creation) and 10 (process access). We can use the generic Sysmon rules included in the Wazuh ruleset as parents for the custom ones created for this use case.
Taking that into account, 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 restarting the manager to apply the new rules.
To generate alerts that match the rules from the previous section, two operations with Mimikatz can be executed. One of them consists of running mimikatz.exe, which will create a process creation event as can be seen in the image above, and the second one is based on retrieving credentials from the SamSs service, which is the Local Security Authentication Server.
This last event will create a remote thread, connect to the SAM API and access the domain. The following images show the execution of these two operations and the events that were caused by them.
Events generated from the performed actions are recorded in the Sysmon section of the event log:
In the next screenshot from the EventViewer, 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 rule engine. Here we can see alerts generated from the Wazuh App 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 huge, and monitoring the Windows event log with Wazuh is as simple as configuring the agent to monitor the desired channels, as this post demonstrates for the Sysmon use case.