Elastic Security Rules with Custom Windows Logs: Using xml2evtx and Winlogbeat

src: https://github.com/austinsonger/Elastic-Security

After describing the basic components, such as the SIEM solution (in my case, the Elastic Stack), we can move on to creating and testing SIEM rules to trigger alerts. The audit policies for the Windows environment were covered in a previous article, where they were configured based on best practices and recommendations. Building dashboards will come later in the process.

Additionally, you can implement Sysmon using the Sysmon Modular configuration provided by Olaf Hartong (https://github.com/olafhartong/sysmon-modular). However, the primary focus of this project is to create rules that are based primarily on the built-in Windows logs, rather than relying solely on Sysmon.

This project is time-consuming, so the first 15–20 rules are provided as a starting point, representing an ideal setup. Think of it like a wiki: each rule includes a description, the corresponding XML code, and a compiled .evtx log file. Additionally, a script and clear instructions are provided on how to test the rules, ingest the logs into Elasticsearch and run the appropriate queries. You can also import the rules in ndjson format to streamline the process.

Building dashboards for this project requires a logical organization of the rules into categories and subcategories, allowing not only alerts to be displayed but also logs related to each category/subcategory. This is just an idea for future implementation, as creating these dashboards for the demo will also be time-consuming. While the project is still a work in progress, certain elements may be (or will be) implemented without full descriptions or fully tested concepts at this stage.

In this project, I use the xml2evtx tool provided by JPCERTCC (https://github.com/JPCERTCC/xml2evtx). It’s an excellent tool for creating custom Windows log files. As you may know, .evtx is a binary file format, so using this tool allows us to manipulate certain fields in XML format to generate custom .evtx files.

However, you cannot insert random text into the XML to build an .evtx file, as this will result in errors when attempting to open the generated log file. It’s important to follow the XML syntax and the logical structure of Windows log files.

In some cases, I intentionally add unnecessary information to specific fields in the XML log file, mainly to demonstrate that it doesn’t match the data typically generated when the event is triggered. For example, when a new user is created (Event ID 4720), certain fields are expected to be empty. However, I might insert text into those fields to illustrate the discrepancy.

The next tool is Winlogbeat-Bulk-Read.ps1 (https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES/blob/master/Winlogbeat-Bulk-Read.ps1). This PowerShell script allows you to ingest .evtx logs into Elasticsearch using Winlogbeat.

While this may overlap with existing Sigma rules (https://github.com/SigmaHQ/sigma), I have created a custom set of rules with generated logs for testing. Additionally, there are some great projects that provide pre-generated .evtx logs for further analysis:

• https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES
• https://github.com/Yamato-Security/hayabusa-sample-evtx
• https://github.com/mdecrevoisier/EVTX-to-MITRE-Attack

As mentioned in a previous article, you can also use the https://github.com/Yamato-Security/hayabusa tool to analyze these logs with Sigma or built-in Hayabusa rules.

Let’s Test It

First, you need to clone the repository: https://github.com/celeroon/win-sec-elastic-rules. Inside this repository, download Winlogbeat https://www.elastic.co/downloads/beats/winlogbeat — make sure to download the version that matches your Elasticsearch version. Once downloaded, unzip the file and rename the folder to winlogbeat (removing the version number from the folder name).

Next, download and place the Winlogbeat-Bulk-Read.ps1 script in the same directory. Rename the winlogbeat-evtx.yml.example file to winlogbeat-evtx.yml, and modify the following fields:

• hosts
• username
• password

Finally, inside the winlogbeat/winlogbeat.yml file, ensure that you update the following fields:

setup.kibana:
  host: "https://192.168.0.1:5601"
  ssl.verification_mode: none
output.elasticsearch:
  hosts: ["192.168.0.1:9200"]
  protocol: "https"
  ssl.verification_mode: none
  username: "elastic"
  password: "PASSWORD"

Created rules can be exported into a single file by using the prepared script extract_ndjson.sh. This script will generate a POC_RULES.ndjson file, which needs to be imported into Kibana. By default, these rules will be in a disabled state. Next, you need to set up Winlogbeat. Change your directory to the Winlogbeat folder: cd .\winlogbeat\ then, run the following command to set it up: .\winlogbeat.exe setup

To ingest logs into Elasticsearch for each log example, I’ve provided instruction in the markdown file on how to use the PowerShell script to send logs. Here’s an example:

.\Winlogbeat-Bulk-Read.ps1 -Exe .\winlogbeat\winlogbeat.exe -Source "./logs/Account-Logon/User-Account-Logon-Success/Subject-is-not-SYSTEM/evtx/*.evtx" -Config ".\winlogbeat-evtx.yml"

Logs will be ingested into the winlogbeat-* index, and the rules are based on this index. This is why I refer to them as PoC (Proof of Concept) rules. For a production environment, the logs should ideally be ingested into a logs-* index to align with best practices.