Michuu1337Follow
20 min read
·
Oct 8, 2025
Prepared By: Michal Bednarczyk
INTRODUCTION
In this article, I will show you how to easily and effectively integrate Sysmon software on both Windows and Linux with the Wazuh SIEM system.
What is Sysmon software?
Sysmon (System Monitor) is a Windows system service and device driver that, once installed, stays active across system reboots to monitor and log detailed system activity to the Windows event log. It captures information such as process creations, network connections, and file creation time changes, including details like command lines, process hashes, and parent-child process relationships.
By installing and configuring Sysmon software, you will gain much broader insight into various activities on end hosts (laptops, servers, PCs, etc.).
Unfortunately, Sysmon software will not be useful to us immediately after installation without any configuration. After installing Sysmon, you need to upload the appropriate config to it, while in Wazuh you need to prepare the appropriate detection rules that will be responsible for triggering alerts/security events. I will tell you more about this and show you how to configure it all later in this article. I won’t bore you with theory anymore, so let’s move on. to practice!
Installing and configuring Sysmon software — Windows 11
In this chapter, I will show you how to install and configure Sysmon software on Windows 11. Please note that you must have the Wazuh agent installed. You can download the Wazuh agent installer from the following source: https://documentation.wazuh.com/current/installation-guide/wazuh-agent/wazuh-agent-package-windows.html
Important note: Before downloading the Wazuh agent installer (msi file), make sure you know which version of the agent you are downloading. At the time of writing, the latest version of Wazuh is 4.13.1.1. If you are using Wazuh version 4.12, for example, the latest Wazuh agent will not be compatible with your instance.
In this article, I will not show you step by step how to install the Wazuh agent. I assume that you already know how to do this. It is really quick and easy, don’t worry.
Sysmon software is part of the Microsoft SysInternals Suite. This suite includes a variety of diagnostic tools and tools that support the analysis of malware, logs, etc. It really is a great set of tools, and I recommend that you take some time to familiarize yourself with it!
To install Sysmon software, you must first download it from this source: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
Click on Download Sysmon.
After downloading the Sysmon archive, unzip it. For the purposes of this demo, I unzipped it in the Downloads folder. After unzipping Sysmon, you will see its executable files and EULA regulations, but something is missing here. Can you guess what it is? It is the file containing the Sysmon configuration.
A Sysmon configuration file is an XML file that defines which system events Sysmon should monitor and log, as well as how to filter or exclude certain events. It allows precise control over what activities like process creations, network connections, or file changes get recorded, helping to reduce noise and focus on relevant security events.
I have good news for you. You don’t have to write the configuration for Sysmon yourself. Of course, you can do it if you want, but first you need to learn the syntax of writing XML files and configurations for Sysmon. Fortunately, there are ready-made configuration files that have been created by professionals.
In my subjective opinion, the two best sources for downloading configurations for Sysmon are:
Sysmon-modular by Olaf Hartong: https://raw.githubusercontent.com/olafhartong/sysmon-modular/refs/heads/master/sysmonconfig.xml
Swift On Security:
In this case, I will download the Sysmon configuration file — “Sysmon-Modular by Olaf Hartong.” As I mentioned, both sources are great, so which one you choose depends entirely on your individual preferences. You can always change or edit an existing config, but you should do so with caution.
In order to create a configuration file, you must first download the content containing the appropriate parameters, settings, rules, etc.
Go to the link provided above and copy all the content to Notepad. Save the file as config.xml and, importantly, select “All Files” in Windows. Place the saved file in the Sysmona directory.
You should get the following result:
Okay, now it’s time to finally install Sysmon. To do this, run the command prompt (cmd) with administrator privileges. Go to the directory where Sysmon is located and then list the directory to view its contents.
In the next step, use the following command to install the Sysmon software:
Sysmon64.exe -accepteula -i config.xml.
Finally, you should get the following result:
To verify and confirm that Sysmon has been installed correctly and is generating events, launch the Event Viewer application and navigate to the following path:
Application and Service Logs → Microsoft → Windows → Sysmon → Operational
If you have followed all the steps correctly and Sysmon has been installed correctly, you should see events generated by the Sysmon software in the Operational file. See the screenshot below for an example.
By clicking on each event, you will see its details in the window below.
You have already verified that Sysmon has been installed correctly. Now, the Wazuh agent software needs to “know” that it should monitor the path where Sysmon logs are stored and then redirect them to the Wazuh server.
To do this, log in to the Wazuh Dashboard.
Create a new configuration group called Sysmon. I’ll show you how to do this in a moment, but first, a little theory. I’ll explain what configuration groups are in Wazuh.
Wazuh agent groups are collections of agents that share a specific, unique configuration. They are created to simplify and centralize the management of multiple agents by allowing the Wazuh manager to push tailored configuration settings to groups of agents rather than managing each one individually. This helps ensure consistent security policies and easier updates across endpoints with similar roles or operating systems, improving efficiency in large environments.
Okay, now you know what configuration groups for agents are in Wazuh. Now I will move on to creating such a group. In the Wazuh Dashboard, go to Agent management → Groups.
Then click on “Add New Group” and name it “Sysmon.”
In the next step, edit the configuration group by clicking on the pen icon.
In the next step, edit the configuration group by clicking on the pen icon. Paste the configuration section below. It is responsible for indicating to the Wazuh agent the path I showed you earlier, which is where the events generated by the Sysmon software are stored. This allows the Wazuh agent to collect this data and redirect it to the Wazuh server. The server and Indexer process this data, and it will ultimately be displayed in Wazuh Dashboard.
<agent_config>
<localfile>
<location>Microsoft-Windows-Sysmon/Operational</location>
<log_format>eventchannel</log_format>
</localfile>
</agent_config>
Save the configuration by clicking the Save button.
In the next step, you need to add an agent or agents to this configuration group. Of course, you add the endpoints on which you want to monitor events generated by Sysmon.
To do this, click the “eye” icon and then go to the “Manage Agents” section.
You will see two sections. The section on the left contains a list of agents. Double-click on an agent name to add it to this configuration group. In my case, I am adding one agent named “SOC_Analyst.” After confirming the changes, click “Apply Changes.”
Now, when you click the back arrow, you will see that the agent has been successfully added to this configuration group. See the example in the screenshot below.
We are halfway there. Namely, we have added an agent to the Sysmon configuration group.
However, at this point, we have not yet implemented the appropriate detection rules that are responsible for generating individual events.
One of the best sources of detection rules for Sysmon and other software is SocFortress github. There you will find a large repository of various configurations and a variety of rules that may be useful to you.
Remember that these are ready-made configurations. You can always edit existing detection rules, delete them, or add new ones according to your preferences. Also, keep in mind that some detection rules can be “very noisy” and generate a large number of “False Positive” alerts, so you need to test them in your environment.
· Link to the repository with rules for Wazuh: https://github.com/socfortress/Wazuh-Rules
· Repo with Sysmon rules for Wazuh: https://github.com/socfortress/Wazuh-Rules/tree/main/Windows_Sysmon
In my case, for the purposes of this article, I am using the rules for Sysmon created by SOC Fortress. You can manually copy the rules from GitHub and implement them into Wazuh, or if you want to have all the rule files uploaded to Wazuh right away, you can use the following command, which you will execute on the Wazuh server. However, before you run this script, make sure that you do not already have certain detection rules created. In Wazuh, each rule should have a unique ID. If there is a conflict between rule IDs and you have duplicate values, the Wazuh server will stop working. In summary, if you want to use this script directly on the Wazuh server, make sure you don’t have any previously created rules.
curl -so ~/wazuh_socfortress_rules.sh https://raw.githubusercontent.com/socfortress/Wazuh-Rules/main/wazuh_socfortress_rules.sh && bash ~/wazuh_socfortress_rules.sh
In the next step, make sure that the rules have been correctly uploaded to the Wazuh server. To do this, go to Server Management → Rules → Custom Rules → Manage Rules in the Wazuh Dashboard. You should see output similar to the screenshot below:
You can also verify this directly on the Wazuh server by running the following command: ll /var/ossec/etc/rules:
Once you have finished adding rules, verify that they are visible in the Wazuh Dashboard, in the Threat Hunting section. Go to this section by clicking on “Threat Intelligence” → “Threat Hunting.”
Then select the appropriate agent by clicking on “Explore Agent” in the upper right corner and select the appropriate one from the list.
In the next step, go to the Events section and use the following filtering method to display only Sysmon logs:
data.win.system.providerName: Microsoft-Windows-Sysmon
If you have followed all the steps correctly, you should be able to see the events generated by the Sysmon software. In this article, I show you how to properly integrate the Sysmon tool with Wazuh. I will not show you how to analyze these events, as this will be covered in a separate article to be published in the future.
INSTALLING AND CONFIGURING SYSMON — UBUNTU SERVER 24.04 LTS
You already know how to install Sysmon on Windows and integrate it with Wazuh. In this chapter, you will learn how to install Sysmon on Linux, specifically on Ubuntu Server 24.04 LTS. Of course, if you want, you can install Sysmon software on various Linux distributions such as Debian, Fedora, etc., but in this case, I will use Ubuntu Server for this purpose because I have tested Sysmon on it and know that it worked stably.
First, you need to install the Wazuh agent software on Ubuntu Server. I will not show this process in this article, but I am providing a link where you will find step-by-step instructions on how to install the Wazuh agent software.
Link to download the Wazuh agent and installation instructions: https://documentation.wazuh.com/current/installation-guide/wazuh-agent/wazuh-agent-package-linux.html
If you have already installed the Wazuh agent correctly, let’s move on to installing Sysmon.
Below is a set of commands that you should paste into your Ubuntu Server terminal one by one. These commands are responsible for installing the necessary dependencies (which are needed to install Sysmon), and one of the commands simply installs Sysmon.
1. apt-key adv — keyserver hkp://keyserver.ubuntu.com:80 — recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
2. echo “deb https://download.mono-project.com/repo/ubuntu vs-bionic main” | sudo tee /etc/apt/sources.list.d/mono-official-vs.list
3. apt update
4. apt -y install build-essential gcc g++ make cmake libelf-dev llvm clang libxml2 libxml2-dev libzstd1 git libgtest-dev apt-transport-https dirmngr monodevelop googletest google-mock libgmock-dev libjson-glib-dev
5. wget -q https://packages.microsoft.com/config/ubuntu/$(lsb_release -rs)/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
6. dpkg -i packages-microsoft-prod.deb
7. apt-get update
8. apt-get install sysmonforlinux
Once you have completed all of the above steps, Sysmon will be installed, but it will not yet have a configuration file. As you already know, as was the case with installing Sysmon on Windows, it needs a configuration file to work properly. Below are the steps for configuring this file for Sysmon for Linux.
In the first step, create a Sysmon configuration file using the following command: Of course, you can use a different editor if you want — for example, vi. However, legend has it that once you enter vi, you will never leave it.
nano /opt/config.xml
In the next step, paste the following content into the previously created file:
<Sysmon schemaversion=”4.70″>
<EventFiltering>
<! — Event ID 1 == ProcessCreate. Log all newly created processes →
<RuleGroup name=”” groupRelation=”or”>
<ProcessCreate onmatch=”exclude”/>
</RuleGroup>
<! — Event ID 3 == NetworkConnect Detected. Log all network connections →
<RuleGroup name=”” groupRelation=”or”>
<NetworkConnect onmatch=”exclude”/>
</RuleGroup>
<! — Event ID 5 == ProcessTerminate. Log all processes terminated →
<RuleGroup name=”” groupRelation=”or”>
<ProcessTerminate onmatch=”exclude”/>
</RuleGroup>
<! — Event ID 9 == RawAccessRead. Log all raw access read →
<RuleGroup name=”” groupRelation=”or”>
<RawAccessRead onmatch=”exclude”/>
</RuleGroup>
<! — Event ID 10 == ProcessAccess. Log all open process operations →
<RuleGroup name=”” groupRelation=”or”>
<ProcessAccess onmatch=”exclude”/>
</RuleGroup>
<! — Event ID 11 == FileCreate. Log every file creation →
<RuleGroup name=”” groupRelation=”or”>
<FileCreate onmatch=”exclude”/>
</RuleGroup>
<! — Event ID 23 == FileDelete. Log all files being deleted →
<RuleGroup name=”” groupRelation=”or”>
<FileDelete onmatch=”exclude”/>
</RuleGroup>
</EventFiltering>
</Sysmon>
Apply the configuration using the following command:
sysmon -accepteula -i /opt/config.xml
Finally, after completing all of the above commands, you should verify that the Sysmon service is working correctly and that event logs are being generated in real time. To do this, run the following commands to verify this.
1. Verification that Sysmon is working correctly.
systemctl status Sysmon
2. events are stored in the directory: /var/log/syslog. Use the following command to verify that events are being generated:
tail -f /var/log/syslog
If you see output like the one in the screenshot above, it means that Sysmon is working correctly and events are being generated.
Now perform a simple use case to confirm that Sysmon is working correctly.
Namely, create a file and edit it by writing some content in it. Then display the contents of the /var/log/syslog directory, filtering by the name of the previously created file. You should see events related to the creation of this file (Event ID 11).
Below is an example illustrating the methodology described above:
1. Creating a file and editing it
touch payload.txt
nano payload.txt
2. Display events generated by Sysmon with filtering of events related to the created payload.txt file.
cat /var/log/syslog | grep payload
Following the above steps has allowed you to confirm and ensure that Sysmon is working properly. In the next step, you need to implement detection rules for Sysmon in the Wazuh SIEM system and create a configuration group for agents so that Sysmon events are sent to the Wazuh server and finally displayed on the Dashboard.
In addition, it is very important to create appropriate decoders, or so-called parsers for Sysmon events. Simply put, decoders are specially crafted regular expressions designed to make log/event data “understandable” to the Wazuh server.
In the first step, I will start by creating a file with decoders and show you step by step how to do it. First, as proof that Sysmon events generated on Linux are not understandable to Wazuh, I will show you how to verify this.
First, go to Server Management → Decoders in the Wazuh Dashboard.
Then click on “Manage decoders files” and then on “Custom Decoders.”
Next, edit the “local_decoder.xml” file by clicking on the pencil icon and then clicking on “Decoders test.”
In the next step, paste the content of one of the events generated by Sysmon into the empty field in the Decoders Test section and click Test. You will not see any information in the window below. This means that at this point, Wazuh does not understand this syntax, specifically this event, so appropriate decoders must be written for these Sysmon events (parsers) must be written for these Sysmon events.
In the next step, I will show you how to create such a file with decoders. First, go to “Manage decoders files” → “Custom decoders.” Click on “Add new decoders file.”
Paste the following content into the file, give it a name with the .xml extension, and click on “Save.”
<decoder name=”sysmon-linux”>
<program_name>sysmon</program_name>
</decoder>
<! — system →
<! — EventID →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pEventID\p(\d+)\p/EventID\p</regex>
<order>system.eventId</order>
</decoder>
<! — keywords →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pKeywords\p(\.+)\p/Keywords\p</regex>
<order>system.keywords</order>
</decoder>
<! — level →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pLevel\p(\d+)\p/Level\p</regex>
<order>system.level</order>
</decoder>
<! — channel →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pChannel\p(\.+)\p/Channel\p</regex>
<order>system.channel</order>
</decoder>
<! — opcode →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pOpcode\p(\d+)\p/Opcode\p</regex>
<order>system.opcode</order>
</decoder>
<! — version →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pVersion\p(\d+)\p/Version\p</regex>
<order>system.version</order>
</decoder>
<! — systemTime →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pTimeCreated SystemTime=”(\d+-\d+-\d+T\d+:\d+:\d+.\d+\w)”</regex>
<order>system.systemTime</order>
</decoder>
<! — eventRecordID →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pEventRecordID\p(\d+)\p/EventRecordID\p</regex>
<order>system.eventRecordID</order>
</decoder>
<! — threadID →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>”\sThreadID=”(\d+)”/\p</regex>
<order>system.threadID</order>
</decoder>
<! — computer →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pComputer\p(\.+)\p/Computer\p</regex>
<order>system.computer</order>
</decoder>
<! — task →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pTask\p(\d+)\p/Task\p</regex>
<order>system.task</order>
</decoder>
<! — processID →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pExecution\sProcessID=”(\d+)”</regex>
<order>system.processID</order>
</decoder>
<! — eventdata →
<! — originalFileName →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”OriginalFileName”\p(\.+)\p/Data\p</regex>
<order>eventdata.originalFileName</order>
</decoder>
<! — image →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”Image”\p(\.+)\p/Data\p</regex>
<order>eventdata.image</order>
</decoder>
<! — product →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”Product”\p(\.+)\p/Data\p</regex>
<order>eventdata.product</order>
</decoder>
<! — parentProcessGuid →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”ParentProcessGuid”\p(\.+)\p/Data\p</regex>
<order>eventdata.parentProcessGuid</order>
</decoder>
<! — description →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”Description”\p(\.+)\p/Data\p</regex>
<order>eventdata.description</order>
</decoder>
<! — logonGuid →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”LogonGuid”\p(\.+)\p/Data\p</regex>
<order>eventdata.logonGuid</order>
</decoder>
<! — parentCommandLine →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”ParentCommandLine”\p(\.+)\p/Data\p</regex>
<order>eventdata.parentCommandLine</order>
</decoder>
<! — processGuid →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”ProcessGuid”\p(\.+)\p/Data\p</regex>
<order>eventdata.processGuid</order>
</decoder>
<! — logonId →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”LogonId”\p(\d+)\p/Data\p</regex>
<order>eventdata.logonId</order>
</decoder>
<! — parentProcessId →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”ParentProcessId”\p(\d+)\p/Data\p</regex>
<order>eventdata.parentProcessId</order>
</decoder>
<! — processId →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”ProcessId”\p(\d+)\p/Data\p</regex>
<order>eventdata.processId</order>
</decoder>
<! — currentDirectory →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”CurrentDirectory”\p(\.+)\p/Data\p</regex>
<order>eventdata.currentDirectory</order>
</decoder>
<! — utcTime →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”UtcTime”\p(\d+-\d+-\d+T\d+:\d+:\d+.\d+\w)\p/Data\p</regex>
<order>eventdata.utcTime</order>
</decoder>
<! — hashes →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”Hashes”\p(\.+)\p/Data\p</regex>
<order>eventdata.hashes</order>
</decoder>
<! — parentImage →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”ParentImage”\p(\.+)\p/Data\p</regex>
<order>eventdata.parentImage</order>
</decoder>
<! — ruleName →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”RuleName”\p(\.+)\p/Data\p</regex>
<order>eventdata.ruleName</order>
</decoder>
<! — company →
Get Michuu1337’s stories in your inbox
Join Medium for free to get updates from this writer.Subscribe
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”Company”\p(\.+)\p/Data\p</regex>
<order>eventdata.company</order>
</decoder>
<! — commandLine →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”CommandLine”\p(\.+)\p/Data\p</regex>
<order>eventdata.commandLine</order>
</decoder>
<! — integrityLevel →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”IntegrityLevel”\p(\.+)\p/Data\p</regex>
<order>eventdata.integrityLevel</order>
</decoder>
<! — fileVersion →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”FileVersion”\p(\.+)\p/Data\p</regex>
<order>eventdata.fileVersion</order>
</decoder>
<! — user →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”User”\p(\.+)\p/Data\p</regex>
<order>eventdata.user</order>
</decoder>
<! — terminalSessionId →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”TerminalSessionId”\p(\.+)\p/Data\p</regex>
<order>eventdata.terminalSessionId</order>
</decoder>
<! — parentUser →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”ParentUser”\p(\.+)\p/Data\p</regex>
<order>eventdata.parentUser</order>
</decoder>
<! — event 3 specials →
<! — protocol →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”Protocol”\p(\.+)\p/Data\p</regex>
<order>eventdata.protocol</order>
</decoder>
<! — initiated →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”Initiated”\p(\.+)\p/Data\p</regex>
<order>eventdata.initiated</order>
</decoder>
<! — sourceIsIpv6 →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”SourceIsIpv6″\p(\.+)\p/Data\p</regex>
<order>eventdata.sourceIsIpv6</order>
</decoder>
<! — sourceIp →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”SourceIp”\p(\.+)\p/Data\p</regex>
<order>eventdata.sourceIp</order>
</decoder>
<! — sourceHostname →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”SourceHostname”\p(\.+)\p/Data\p</regex>
<order>eventdata.sourceHostname</order>
</decoder>
<! — sourcePort →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”SourcePort”\p(\.+)\p/Data\p</regex>
<order>eventdata.sourcePort</order>
</decoder>
<! — sourcePortName →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”SourcePortName”\p(\.+)\p/Data\p</regex>
<order>eventdata.sourcePortName</order>
</decoder>
<! — destinationIsIpv6 →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”DestinationIsIpv6″\p(\.+)\p/Data\p</regex>
<order>eventdata.destinationIsIpv6</order>
</decoder>
<! — destinationIp →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”DestinationIp”\p(\.+)\p/Data\p</regex>
<order>eventdata.DestinationIp</order>
</decoder>
<! — DestinationHostname →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”DestinationHostname”\p(\.+)\p/Data\p</regex>
<order>eventdata.destinationHostname</order>
</decoder>
<! — destinationPort →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”DestinationPort”\p(\.+)\p/Data\p</regex>
<order>eventdata.destinationPort</order>
</decoder>
<! — destinationPortName →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”DestinationPortName”\p(\.+)\p/Data\p</regex>
<order>eventdata.destinationPortName</order>
</decoder>
<! — event 4 specials →
<! — state →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”State”\p(\.+)\p/Data\p</regex>
<order>eventdata.state</order>
</decoder>
<! — version →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”Version”\p(\.+)\p/Data\p</regex>
<order>eventdata.version</order>
</decoder>
<! — schemaVersion →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”SchemaVersion”\p(\.+)\p/Data\p</regex>
<order>eventdata.schemaVersion</order>
</decoder>
<! — event 9 specials →
<! — device →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”Device”\p(\.+)\p/Data\p</regex>
<order>eventdata.device</order>
</decoder>
<! — event 11 specials →
<! — targetFilename →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”TargetFilename”\p(\.+)\p/Data\p</regex>
<order>eventdata.targetFilename</order>
</decoder>
<! — creationUtcTime →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”CreationUtcTime”\p(\d+-\d+-\d+T\d+:\d+:\d+.\d+\w)\p/Data\p</regex>
<order>eventdata.creationUtcTime</order>
</decoder>
<! — event 16 specials →
<! — configuration →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”Configuration”\p(\.+)\p/Data\p</regex>
<order>eventdata.configuration</order>
</decoder>
<! — configurationFileHash →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”ConfigurationFileHash”\p(\.+)\p/Data\p</regex>
<order>eventdata.configurationFileHash</order>
</decoder>
<! — event 23 specials →
<! — isExecutable →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”IsExecutable”\p(\.+)\p/Data\p</regex>
<order>eventdata.isExecutable</order>
</decoder>
<! — archived →
<decoder name=”sysmon-linux-child”>
<parent>sysmon-linux</parent>
<regex offset=”after_parent”>\pData Name=”Archived”\p(\.+)\p/Data\p</regex>
<order>eventdata.archived</order>
</decoder>
The above configuration was taken from this source: https://raw.githubusercontent.com/OpenSecureCo/Demos/main/linux-sysmon.xml
After completing these steps, run the decoder test again. Open the previously created file with decoders for Sysmon Linux events, paste a sample Sysmon event into the field, and click “Test.”
You should see output similar to the following:
If you have seen that the event has been correctly decoded by the decoders, you are halfway there! You still need to add a file with detection rules that will apply to Sysmon events for Linux. Now I will show you how to do it.
Go to “Server Management” → “Rules.”
Then, go to “Manage rules files” → “Custom rules” à “Add new rules file”.
Paste the following content into the rules file. Then name the file and click “Save.” (Remember to include the .xml extension in the name of the rules file.)
<group name=”linux,sysmon,”>
<rule id=”200150″ level=”3″>
<decoded_as>sysmon-linux</decoded_as>
<field name=”system.eventId”>\.+</field>
<group>sysmon_event1</group>
<description>Sysmon For Linux Event</description>
<mitre>
<id>T1204</id>
</mitre>
<options>no_full_log</options>
</rule>
<! — EventID = 1 →
<rule id=”200151″ level=”3″>
<if_sid>200150</if_sid>
<field name=”system.eventId”>¹$</field>
<description>Sysmon — Event 1: Process creation $(eventdata.image)</description>
<group>sysmon_event1</group>
<mitre>
<id>T1204</id>
</mitre>
<options>no_full_log</options>
</rule>
<! — EventID = 3 →
<rule id=”200152″ level=”3″>
<if_sid>200150</if_sid>
<field name=”system.eventId”>³$</field>
<description>Sysmon — Event 3: Network connection by $(eventdata.image)</description>
<group>sysmon_event3</group>
<mitre>
<id>T1043</id>
</mitre>
<options>no_full_log</options>
</rule>
<! — EventID = 5 →
<rule id=”200153″ level=”3″>
<if_sid>200150</if_sid>
<field name=”system.eventId”>⁵$</field>
<description>Sysmon — Event 5: Process terminated $(eventdata.image)</description>
<group>sysmon_event5</group>
<mitre>
<id>T1204</id>
</mitre>
<options>no_full_log</options>
</rule>
<! — EventID = 9 →
<rule id=”200154″ level=”3″>
<if_sid>200150</if_sid>
<field name=”system.eventId”>⁹$</field>
<description>Sysmon — Event 9: Raw Access Read by $(eventdata.image)</description>
<group>sysmon_event9</group>
<mitre>
<id>T1204</id>
</mitre>
<options>no_full_log</options>
</rule>
<! — EventID = 11 →
<rule id=”200155″ level=”3″>
<if_sid>200150</if_sid>
<field name=”system.eventId”>¹¹$</field>
<description>Sysmon — Event 11: FileCreate by $(eventdata.image)</description>
<group>sysmon_event_11</group>
<mitre>
<id>T1044</id>
</mitre>
<options>no_full_log</options>
</rule>
<! — EventID = 16 →
<rule id=”200156″ level=”3″>
<if_sid>200150</if_sid>
<field name=”system.eventId”>¹⁶$</field>
<description>Sysmon — Event 16: Sysmon config state changed $(Event.EventData.Data.Configuration)</description>
<group>sysmon_event_16</group>
<mitre>
<id>T1562</id>
</mitre>
<options>no_full_log</options>
</rule>
<! — EventID = 23 →
<rule id=”200157″ level=”3″>
<if_sid>200150</if_sid>
<field name=”system.eventId”>²³$</field>
<description>Sysmon — Event 23: FileDelete (A file delete was detected) by $(eventdata.image)</description>
<group>sysmon_event_23</group>
<mitre>
<id>T1107</id>
<id>T1485</id>
</mitre>
<options>no_full_log</options>
</rule>
<! — Overrides →
<! — EventID = 3. Discrad events if Image = /var/ossec/bin/wazuh-agentd or Image = /usr/sbin/zabbix_agentd →
<rule id=”200200″ level=”1″>
<if_sid>200152</if_sid>
<field name=”eventdata.image”>wazuh-agentd$</field>
<description>Sysmon — Event 3: Network connection by $(eventdata.image)</description>
<group>sysmon_event3</group>
<mitre>
<id>T1107</id>
<id>T1485</id>
</mitre>
<options>no_full_log</options>
</rule>
<! — EventID = 11. Discrad events if Image = /var/ossec/bin/wazuh-agentd →
<rule id=”200201″ level=”1″>
<if_sid>200155</if_sid>
<field name=”eventdata.image”>wazuh-agentd$</field>
<description>Sysmon — Event 11: FileCreate by $(eventdata.image)</description>
<group>sysmon_event_11</group>
<mitre>
<id>T1107</id>
<id>T1485</id>
</mitre>
<options>no_full_log</options>
</rule>
<! — EventID = 23. Discrad events if Image = /var/ossec/bin/wazuh-agentd →
<rule id=”200202″ level=”1″>
<if_sid>200157</if_sid>
<field name=”eventdata.image”>wazuh-agentd$</field>
<description>Sysmon — Event 23: FileDelete (A file delete was detected) by $(eventdata.image)</description>
<group>sysmon_event_23</group>
<mitre>
<id>T1107</id>
<id>T1485</id>
</mitre>
<options>no_full_log</options>
</rule>
</group>
After completing these steps, click on “Ruleset Test” inside the rules file. Paste the same event there that you previously pasted into “Decoders Test.” You should see output related to the alert being generated. This means that you have correctly written decoders and detection rules.
Almost done. The last step will be to add a configuration group for agents so that the Wazuh agent knows where to collect these events and redirect them to the Wazuh server. You already know how to do this for Windows. Here, the methodology will be very similar.
Go to the “Agents management” → “Groups” section.
Click on “Add new group”.
Give the group a name, for example “linux_sysmon” and save the group.
Edit the newly created group by clicking on the pencil icon and add the following configuration section to it. It tells the Wazuh agent which path to monitor and collect events from. As you may recall, Sysmon saves events to /var/log/syslog by default.
<localfile>
<log_format>syslog</log_format>
<location>/var/log/syslog</location>
</localfile>
Then save the group. In the next step, display the group details by clicking on the eye icon in the “Actions” section, then go to “Manage agents.”
From the section of available agents, select the agent (by double-clicking on it) that you want to add to this group, i.e., specifically the one from which you want to display Sysmon events, and click on “Apply changes.”
In the final step, go to the “Threat Hunting” section and select the agent you just added to the “linux_sysmon” group.
If you have followed all the steps correctly, you should see the events generated by the Sysmon software. Well done!!
SUMMARY
Installing, configuring, and integrating the Sysmon solution on both Windows and Linux operating systems will give you a much broader and more detailed insight into various activities on end hosts. Thanks to this integration, you can now monitor running processes, network connections, commands entered in the terminal, etc., which will contribute to a better monitoring process for your infrastructure.
Wazuh Ambassadors Program: https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program
Wazuh Webpage: https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program
Contact me
If you have any questions, please contact me on LinkedIn.
My Linkedln Profile: https://www.linkedin.com/in/%F0%9F%9B%A1%EF%B8%8Fmicha%C5%82-bednarczyk-2580a6228/
Leave a Reply