Windows provides an event log collection tool which includes all generated events, and it is organized in channels. The main channels are System, Application and Security. In these channels, 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 the software installed in the system.

Wazuh collects the events of those channels and provides a new Windows ruleset that allows us to know the important events that happen in our Windows servers. Monitoring Sysmon could be an interesting application for this service. Sysmon is a Windows tool that records system activity and event detection anomalies in the event log, and is a subprogram of Winternals, a subdivision of Microsoft created by Mark Russinovich.

This article explains how to monitor threat activity with Sysmon step-by-step. Here, the Wazuh agent will be configured to monitor the Sysmon channel logs, but this configuration can be extended to the rest of the available channels.

In order to achieve this, we will see the log messages generated in the EventViewer, which allows the display of recorded events. Each log entry shows all the event information through a main message that describes the origin of the event and other specific parameters considered in the event. This post is an update of Using Wazuh to monitor Sysmon events, as Wazuh’s capabilities have been enhanced to collect EventChannel logs since version v3.8.0.

Prerequisites

  • Wazuh v3.8+
  • Windows Vista or higher

Sysmon event collection

We need to configure the agent to keep track of the processes to monitor the logs from Sysmon. 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 allows 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:

  1. Download Sysmon here.
  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. 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 here.

The process creation event will be the first matching event. Running the mimikatz.exe binary generates that event, and this can be seen in the EventViewer application in the Sysmon section (Applications and Services Logs/Microsoft/Windows/Sysmon/Operational):

Mimikatz process execution:

Mimikatz execution Windows event collection tutorial

The generated event is recorded in the Windows event log.

Mimikatz process creation event 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, which will be explained later.

Configuring Wazuh to collect Sysmon events

Once the Wazuh agent is installed and running in 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 will be 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 can involve 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 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 rule set 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 alerts that match the rules in the previous section. 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.

Mimikatz and lsadump execution Windows events

Events generated from the performed actions are recorded in the Sysmon section of the event log:

Sysmon event log

In the next screenshot from the EventViewer, we can see one of these events in detail. Specifically, the remote thread creation event:

Remote thread creation event Eventviewer

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 user interface side:

Remote Thread creation alert:

Remote thread creation alert at Kibana

Suspicious access alert:

Suspicious access alert at Kibana

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.

References

If you have any questions about this, join our Slack community channel! Our team and other contributors will help you. Wazuh is a free, open source and enterprise-ready security monitoring solution for threat detection, integrity monitoring, incident response and compliance. Check out our blog if you want to know more about Wazuh.