Quick Tutorial: Regex and EDR Detection Rules

Introduction: Why Regex in Wazuh Detection Rules?

Wazuh relies heavily on regex patterns to analyze log messages, detect threats, and correlate events.

• PCRE2 (Perl-Compatible Regular Expressions v2) is the one of the engines Wazuh uses for regex evaluation.

• SOC analysts often need to:

  • Write new detection rules.
  • Override existing ones (via custom rules).
  • Suppress false positives with custom regex.
  • Tighten loose patterns to reduce noise.

PCRE2 Regex Basics for Wazuh

Let's review key elements you'll use most often in Wazuh rules.

Tip: PCRE2 is anchored at the start and the end of the string by default in many rules, so ^ and $ is often implied/used).

Testing Your Regex

The website https://regex101.com/ is a great resource to test and verify regex expressions.
Let's say we'd like to test a regex to match C:\Windows\System32\backgroundTaskHost.exe, found as part of a Sysmon event.
We'd go to https://regex101.com:

Under “TEXT STRING” we paste the text we want to match, and under “REGULAR EXPRSESSION” our regex:

If everything goes as expected, the tool will highlight 1 match (green color, top right).

Note the following in this simple example:

• The regex used start of and end of (^ and $ respectively) because I want to match the exact expression.
• Backslashes need to be escaped (see table above).
• Same applies to the dot (.).

Defining EDR exclusion rules – examples and considerations.

All EDR solutions will generate “false positives”, events flagged as suspicious activity detected in the endpoint and classified with high severity / alert.

There are many well-known applications that, as part of their normal function will interact with the OS in ways that EDRs might classify as suspicious. This is the case particulary for tools like remote management and monitoring (RMM) solutions, anti-virus / anti-malware software, inventory tools, etc.

The challenge when defining exclison rules is being as specific as possible in the conditions used so we only “whitelist” what we know for sure is part of normal activity.

As part of our EDR for Windows, agent deployment, we always include Sysmon and the collection of PowerShell events, amongst all its settings. Due to the amount and variety of event types that Sysmon collects is common that some of them will be classisifed as alerts when, in reality, represents “normal” activity collected.

In the case of RMM tools, for example, is very common that the following event types will be registered as alerts by default:

• Process Injections (Sysmon Event 10).
• PowerShell Process Executions, where the RMM process is the parent process (Sysmon event 1).
• PowerShell Automation Library laoded (DLL Side Loading, Sysmon Event 7). This case often-times causes alarm since many automation libraries are not digitally signed, but legit.
• Activity on the Windows Registry (Sysmon Events 12 and 13).

As a general rule though, these events include enough telemetry allowing us to narrow down the conditions and ensuring that the exclusion rule can be safetly enabled.