TryHackMe: Custom Alert Rules in Wazuh

Author: Mario Martinez Jr. (ku5e / Gary7) | TryHackMe USA Top 1%

Difficulty: Medium

Topics: XDR/SIEM, Rule Syntax, Regex, Threat Detection


Answers are redacted within the narrative to allow you to complete the tasks on your own, but a full table of answers is available at the end of this walkthrough.

In this lab, we step into the role of a Security Operations Center (SOC) analyst responsible for fine-tuning a Wazuh deployment. The default rule set captures many common threats, but specialized environments require custom detection logic to identify sophisticated adversary behavior. We will focus on modifying the local rules configuration to trigger alerts based on specific log patterns and nested logic.


Task 2: Decoders and Sysmon Analysis

Wazuh uses decoders to transform raw logs into structured data fields. When a Windows machine with Sysmon installed sends an event, the decoder identifies specific fields such as the process image, parent process, and command line.

In the provided Sysmon log, we are examining a Process Creation event. We specifically look at the sysmon.commandLine field to see exactly what was executed on the host. This field provides the full context of the command, including the binary path and the specific script being called with its associated flags.

  • Looking at the Sysmon Log, what will the value of sysmon.commandLine be? ANSWER: [REDACTED]

Next, we look at how Wazuh extracts data using Regex. If we encounter a log entry that contains a user identity, we can use a non-whitespace selector to grab just the name. The pattern User: \S* tells the engine to find the literal string "User: " and capture every character until it hits a space.

  • *What would the extracted value be if the regex is set to "User: \S"?** ANSWER: [REDACTED]

Task 3: Understanding Ruleset Logic

Rules use the fields extracted by decoders to determine if an alert should be fired. We often pivot off of specific MITRE ATT&CK techniques or rule IDs to broaden our detection coverage. For instance, rule ID 184666 is part of the default Sysmon ruleset and is tied to a specific adversary technique (T1055).

  • From the Ruleset Test results, what is the <mitre> ID of rule id 184666? ANSWER: [REDACTED]

We also use the Wazuh Dashboard's "Ruleset Test" feature to simulate how the manager would react to a log if certain fields were changed. By manually altering the sysmon.image value to a common system process like taskhost.exe, we can observe which rule hierarchy takes over and how the manager assigns a Rule ID to that specific execution.


Task 5: Implementing Custom Rules

When default rules are too broad, we modify local_rules.xml to add environment-specific logic. A common requirement is to monitor activity within temporary or sensitive directories. We use the <regex> tag within our rule blocks to look for keywords or paths within the log data to escalate the alert level. In the provided example, we are looking specifically at the current working directory.

  • What is the regex field name used in the local_rules.xml? ANSWER: [REDACTED]

Final Flag Summary Table

TaskCategory/QuestionFlag/Answer
2sysmon.commandLine value“C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” “-file” “C:\Users\Alberto\Desktop\test.ps1”
2Regex extracted valueWIN-P57C9KN929H\Alberto
2sysmon.parentImage valueC:\Windows\Explorer.EXE
3MITRE ID for rule 184666T1055
3Rule 12 descriptionHigh importance event
3Rule ID for taskhost.exe184736
4Parent Rule ID of 184717184716
5Regex field name in local_rulesaudit.cwd
5Current working directory (cwd)/var/log/audit
6Rule ID for test.php100003
6malware-checker.sh level12

Walkthrough by Mario Martinez Jr. (ku5e / Gary7) | TryHackMe Profile | blog.ku5e.com