Building My First Custom Wazuh Detection Rule: A Complete Detection Engineering Case Study

How I Built, Troubleshot, and Validated Custom PowerShell & Command Prompt Detection Rules Using Wazuh 4.14.7 and Sysmon

Author: Syed Ahamed Wasik

Introduction

As I continue my journey toward becoming a SOC Analyst, I wanted to move beyond simply viewing alerts in a SIEM and start understanding how those alerts are actually created.

One of the core responsibilities of a Blue Team or Detection Engineer is developing and improving detection logic that helps identify suspicious activities within an organization’s environment. Rather than relying only on the built-in detection rules provided by a SIEM, security teams often create custom rules to monitor behaviors that are relevant to their infrastructure or threat model.

To gain practical experience, I decided to build a home lab using Wazuh 4.14.7, Windows 11, and Sysmon. The objective was straightforward: create custom Wazuh detection rules capable of identifying PowerShell and Command Prompt execution based on Sysmon Event ID 1 (Process Creation).

Although the goal appeared simple at first, the implementation quickly turned into a valuable learning experience. During the project, I encountered several technical issues, including XML syntax errors, duplicate rule IDs, incorrect field mappings, rule dependency problems, and alerts that failed to trigger despite the events being collected successfully.

Rather than searching for ready-made solutions, I approached each issue as a troubleshooting exercise. I verified every stage of the detection pipeline, analyzed log files, reviewed Wazuh’s built-in rules, corrected my custom rules, and repeatedly tested the environment until the detections worked as expected.

This article documents that journey from start to finish. It explains not only the final working solution but also the investigation process, the mistakes I made, and the lessons I learned while building my first custom Wazuh detection rules.

Why I Started This Project

Many cybersecurity learners can install Wazuh and view alerts in the dashboard. However, understanding how those alerts are generated is a different skill entirely.

My goal was not just to create another lab. I wanted to understand the complete lifecycle of a security event — from the moment a process starts on a Windows endpoint to the point where it becomes an alert in the SIEM.

By building and troubleshooting custom detection rules, I aimed to answer questions such as:

• How does Sysmon record process creation events?
• How does the Wazuh agent collect Windows Event Logs?
• How are events decoded by the Wazuh Manager?
• How do built-in and custom rules interact?
• What causes a custom rule to fail?
• How can those issues be identified and resolved systematically?

Answering these questions provided hands-on experience with detection engineering concepts that are directly relevant to SOC operations.

Project Objectives

The primary objective of this project was to develop and validate custom Wazuh detection rules for Windows process creation events.

Specifically, I wanted to:

• Build a functioning Wazuh home lab.
• Configure Windows 11 with Sysmon.
• Forward Sysmon events to the Wazuh Manager.
• Create custom detection rules for:
• PowerShell execution
• Command Prompt execution
• Validate the detections using live events.
• Troubleshoot and resolve any issues encountered during development.
• Understand how Wazuh processes and evaluates custom rules.

The ultimate goal was not only to generate alerts but also to understand the reasoning behind each stage of the detection process.

What You’ll Learn

By the end of this article, you will understand:

• How Windows process creation events are generated by Sysmon.
• How Wazuh collects and processes Windows Event Logs.
• The structure of Wazuh custom XML rules.
• Common mistakes when writing custom rules.
• A systematic approach to troubleshooting Wazuh detection issues.
• How to validate custom detections using real endpoint activity.
• Practical lessons that can be applied in SOC Analyst and Detection Engineering roles.

Lab Architecture & Environment

Before writing a single custom detection rule, I needed to understand how Wazuh processes Windows events. This turned out to be one of the most important lessons from the project.

Initially, I assumed that if Sysmon generated an event, Wazuh would automatically detect it. After several failed attempts and many hours of troubleshooting, I realized that a detection rule is only one component of a much larger pipeline. If any stage in that pipeline fails, the alert will never be generated, regardless of how well the rule is written.

Understanding this data flow became the foundation for every troubleshooting step that followed.

Lab Environment

To simulate a small Security Operations Center (SOC) environment, I built a home lab consisting of a Windows endpoint, a Wazuh Manager running on Ubuntu, and the Wazuh Dashboard for investigation.

ComponentTechnologySIEM PlatformWazuh 4.14.7Operating SystemUbuntu Server 24.04 LTSEndpointWindows 11Endpoint MonitoringSysmonLog CollectionWazuh AgentSearch EngineWazuh Indexer (OpenSearch)DashboardWazuh Dashboard

This setup closely resembles how endpoint telemetry is collected and analyzed in many enterprise environments.

Understanding the Detection Pipeline

Every alert displayed in the Wazuh Dashboard follows a series of processing stages before it reaches the analyst.

Each component has a specific responsibility, and understanding those responsibilities helped me troubleshoot issues much more effectively.

Component Overview

Windows 11 Endpoint

The Windows machine acts as the monitored endpoint where user activity takes place.

Whenever a user launches an application such as PowerShell or Command Prompt, Windows generates an event. By itself, however, Windows Security Logs do not always provide enough detail for advanced detection.

Sysmon

Sysmon (System Monitor) extends Windows logging by recording detailed system activity.

For this project, the most important event was:

Event ID 1 — Process Creation

This event includes valuable information such as:

• Process Name
• Command Line
• Parent Process
• User
• Process GUID
• File Hashes
• Integrity Level
• Timestamp

This additional telemetry provides the context required for effective detection engineering.

Wazuh Agent

The Wazuh Agent runs on the Windows endpoint and is responsible for collecting Windows Event Logs, including Sysmon events.

Its role is to:

• Monitor Windows Event Channels
• Collect Sysmon logs
• Forward events securely to the Wazuh Manager

Without the agent, no endpoint telemetry would reach the SIEM.

Wazuh Manager

The Wazuh Manager is the core of the platform.

It performs several important functions:

• Receives logs from endpoints
• Decodes Windows events
• Applies built-in detection rules
• Evaluates custom rules
• Generates security alerts

During this project, every custom XML rule was processed by the Wazuh Manager before an alert could be generated.

Wazuh Indexer

After an event matches a rule, the alert is stored inside the Wazuh Indexer.

The Indexer enables fast searching and efficient storage of security events.

Wazuh Dashboard

The Wazuh Dashboard is the interface used by analysts to investigate alerts.

It provides features such as:

• Alert investigation
• Event search
• Rule validation
• Threat hunting
• Security dashboards

Throughout this project, I used the Discover page to confirm whether my custom detection rules were working correctly.

Detection Workflow

The following workflow summarizes how a process execution eventually becomes a security alert.

User Executes PowerShell
           │
           ▼
Sysmon Generates Event ID 1
           │
           ▼
Wazuh Agent Collects Event
           │
           ▼
Wazuh Manager Decodes Event
           │
           ▼
Custom Rule Evaluation
           │
           ▼
Rule Match
           │
           ▼
Alert Generated
           │
           ▼
Indexed in OpenSearch
           │
           ▼
Displayed in Wazuh Dashboard

This workflow became my reference throughout the project whenever something failed.

Why Understanding the Pipeline Was Important

One of the biggest lessons I learned was that writing a correct detection rule does not guarantee an alert.

A rule can fail for many reasons, including:

• Sysmon not generating the event
• The Wazuh Agent failing to forward logs
• The Wazuh Manager not decoding the event correctly
• Incorrect field names in the custom rule
• XML syntax errors preventing the rule from loading
• Incorrect rule hierarchy (if_sid or if_group)
• Search queries that do not match the indexed data

By understanding the entire pipeline, I was able to troubleshoot each stage individually instead of making random changes to my XML rules.

This systematic approach ultimately led to a successful implementation and is a valuable skill for any SOC analyst or detection engineer.

Installing Sysmon and Verifying Endpoint Telemetry

Before creating any custom detection rules, I needed to answer one critical question:

Is my Windows endpoint actually generating the events that I want to detect?

If Sysmon wasn’t producing the required logs, then no amount of troubleshooting inside Wazuh would solve the problem.

For this reason, I decided to validate the endpoint first before writing a single custom rule.

Why Sysmon?

Windows already records security events through the built-in Event Viewer. However, these default logs often lack the detailed telemetry required for advanced threat detection.

Microsoft Sysinternals Sysmon (System Monitor) extends Windows logging by providing significantly richer event data. Instead of recording only that a process started, Sysmon also captures additional context that is extremely valuable during investigations.

Some of the information provided by Sysmon includes:

• Process Name
• Process ID
• Parent Process
• Parent Command Line
• Full Command Line
• Username
• Process GUID
• File Hashes (MD5, SHA1, SHA256)
• Integrity Level
• Timestamp

This additional telemetry enables analysts to detect attacker behavior with much greater accuracy.

Why Event ID 1?

For this project, I focused on Sysmon Event ID 1 — Process Creation.

Whenever a new process starts on Windows, Sysmon records an event containing detailed information about that process.

Examples include:

• PowerShell.exe
• cmd.exe
• notepad.exe
• explorer.exe
• chrome.exe

Since PowerShell and Command Prompt are commonly used by attackers during execution, Event ID 1 serves as an excellent starting point for building detection rules.

Installing Sysmon

I installed Sysmon on my Windows 11 endpoint using the official Sysinternals package from Microsoft.

The installation included a configuration file that enabled process creation logging and other useful telemetry.

Once installation was complete, Sysmon created a dedicated Windows Event Log:

Applications and Services Logs
        │
        ▼
Microsoft
        │
        ▼
Windows
        │
        ▼
Sysmon
        │
        ▼
Operational

This log became the primary telemetry source for the project.

(Insert Screenshot: Windows Event Viewer showing Microsoft-Windows-Sysmon/Operational)

Verifying Event Generation

After installing Sysmon, I needed to confirm that it was actively generating Process Creation events.

Using PowerShell, I queried the latest entries from the Sysmon Operational log.

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5

The output showed several Process Creation events, confirming that Sysmon was working correctly.

Example output:

ProviderName : Microsoft-Windows-Sysmon

Id           : 1

Level        : Information

Message      : Process Create

(Insert Screenshot: PowerShell output showing Event ID 1)

Examining a Sysmon Event

To understand what information was available for detection, I displayed the full details of a single Process Creation event.

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 1 | Format-List *

The event contained valuable fields such as:

• Image
• CommandLine
• ParentImage
• ParentCommandLine
• ProcessGuid
• ProcessId
• User
• IntegrityLevel
• Hashes

Example:

Image:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

CommandLine:
powershell.exe

ParentImage:
C:\Windows\explorer.exe

User:
WASIK\User

IntegrityLevel:
Medium

This information would later become the basis for my custom detection rules.

(Insert Screenshot: Full Sysmon Event Details)

Understanding the Available Fields

One of the biggest lessons during this stage was realizing that custom rules can only match fields that actually exist in the event data.

For example, the following fields are available within Sysmon Event ID 1:

FieldDescriptionImageExecutable that startedCommandLineFull command used to launch the processParentImageParent process that created itParentCommandLineParent process command lineUserAccount that executed the processHashesFile hashesIntegrityLevelProcess privilege level

Later in the project, these fields became essential when writing custom Wazuh XML rules.

Why This Validation Was Important

At this stage, I had not yet configured any custom Wazuh rules.

My objective was simply to answer one question:

“Is the endpoint generating the telemetry I need?”

The answer was yes.

Sysmon was successfully recording Event ID 1, which meant the endpoint was ready for the next phase of the project.

By validating telemetry first, I eliminated one of the most common troubleshooting variables. If a detection later failed inside Wazuh, I could confidently rule out the endpoint and focus on the Wazuh configuration instead.

This simple validation step saved a significant amount of debugging time later in the project.

Key Takeaways

Before creating detection rules, always verify that the endpoint is producing the required telemetry.

During this phase, I learned that:

• Sysmon provides much richer process telemetry than standard Windows logs.
• Event ID 1 is the foundation for many Windows detection use cases.
• Understanding available event fields is critical before writing detection logic.
• Validating telemetry early helps isolate future troubleshooting efforts.

Connecting Windows 11 to Wazuh and Verifying Log Ingestion

After confirming that Sysmon was successfully generating Process Creation events, the next step was ensuring those events reached the Wazuh Manager.

Installing Sysmon alone is not enough. If the Wazuh Agent cannot collect or forward the logs, the SIEM will never receive the telemetry, and no detection rule will ever trigger.

Before developing any custom rules, I needed to verify that the communication between the Windows endpoint and the Wazuh Manager was working correctly.

Project Goal

At this stage, my objective was to validate the entire log collection pipeline.

Specifically, I wanted to confirm that:

• The Windows endpoint was connected to the Wazuh Manager.
• The Wazuh Agent was online.
• Sysmon Event ID 1 logs were being collected.
• The Wazuh Manager was receiving the events.
• The events were indexed and searchable in the Wazuh Dashboard.

Only after confirming these steps would I begin writing custom detection rules.

Installing the Wazuh Agent

The Windows endpoint was configured with the Wazuh Agent.

During installation, I configured:

• Wazuh Manager IP Address
• Agent Name
• Agent Registration

Once the installation completed, I started the Wazuh Agent service.

(Insert Screenshot: Wazuh Agent Installation Wizard)

Verifying Agent Connectivity

The first validation step was checking whether the Windows endpoint had successfully established communication with the Wazuh Manager.

I reviewed the Wazuh Agent log located at:

C:\Program Files (x86)\ossec-agent\ossec.log

The log confirmed that the agent had successfully connected.

Example:

Connected to the server (192.168.xxx.xxx:1514/tcp)

Agent is now online.

These messages confirmed that communication between the endpoint and the manager was functioning correctly.

(Insert Screenshot: ossec.log showing successful connection)

Monitoring Connection Stability

While testing the environment, I also observed occasional connection interruptions.

The agent log contained messages similar to:

Lost connection with manager.

Trying to reconnect...

Connected to the server.

Agent is now online.

Rather than assuming the custom rules were responsible for missing alerts, I first confirmed that these temporary network interruptions were resolved and that the agent eventually re-established communication.

This reinforced an important troubleshooting principle:

Always verify the health of the data source before debugging the detection logic.

Verifying the Agent in Wazuh Dashboard

After confirming the connection on the endpoint, I verified that the Wazuh Manager recognized the Windows machine.

Inside the Wazuh Dashboard:

Endpoints → Agents

The Windows 11 endpoint appeared with:

• Agent Name
• Agent ID
• IP Address
• Status: Active

This confirmed that the endpoint was successfully registered with the Wazuh Manager.

(Insert Screenshot: Wazuh Dashboard showing Active Agent)

Confirming Sysmon Event Collection

The next step was verifying that Sysmon events were actually reaching the Wazuh Manager.

Instead of assuming the events were being collected, I searched for Sysmon logs inside the Wazuh Dashboard.

One of the first searches I performed was:

data.win.system.providerName:
Microsoft-Windows-Sysmon

The search returned multiple Sysmon events.

This confirmed that:

• The endpoint was generating events.
• The Wazuh Agent was forwarding those events.
• The Wazuh Manager was decoding them.
• The events were successfully indexed.

(Insert Screenshot: Discover showing Sysmon events)

Inspecting the Event Structure

Finding the events in the dashboard was only the beginning.

Before writing any custom detection rules, I needed to understand how Wazuh stored the event data.

Opening one of the Sysmon Process Creation events revealed a detailed JSON document containing fields such as:

data.win.system.eventID

data.win.eventdata.image

data.win.eventdata.commandLine

data.win.eventdata.parentImage

data.win.eventdata.user

These fields would later become the foundation of my custom detection rules.

At this point, I made an important observation:

The JSON displayed in Discover is not always identical to the field names used internally by the Wazuh rule engine.

This difference became one of the biggest troubleshooting challenges later in the project.

(Insert Screenshot: Expanded JSON event in Discover)

Initial Validation Complete

By the end of this phase, I had successfully verified the complete data collection pipeline.

Windows 11
        │
        ▼
Sysmon
        │
        ▼
Windows Event Log
        │
        ▼
Wazuh Agent
        │
        ▼
Wazuh Manager
        │
        ▼
Indexer
        │
        ▼
Dashboard

Every component was functioning correctly, giving me confidence that the environment was ready for custom rule development.

Lessons Learned

This phase reinforced several important concepts:

• An active agent does not automatically guarantee that the correct logs are being collected.
• Always verify endpoint connectivity before troubleshooting detection rules.
• Inspect the actual event structure before writing custom rule conditions.
• Confirm that events are searchable in the SIEM before assuming a rule is faulty.
• A structured validation process significantly reduces troubleshooting time later.

Transition to Detection Engineering

At this point, the environment was fully operational.

• Sysmon was generating Process Creation events.
• The Wazuh Agent was forwarding logs successfully.
• The Wazuh Manager was receiving and indexing the events.
• The Wazuh Dashboard displayed the telemetry correctly.

With the data pipeline validated, I was ready to begin the most challenging part of the project — developing my first custom Wazuh detection rules.

Building My First Custom Wazuh Detection Rule (And Why It Failed)

At this stage, my lab environment was fully operational.

• ✅ Sysmon was generating Process Creation events.
• ✅ The Windows Agent was connected to the Wazuh Manager.
• ✅ Sysmon events were visible in the Wazuh Dashboard.
• ✅ The entire telemetry pipeline had been verified.

With the environment ready, I could finally begin writing my first custom detection rule.

What I expected to be the easiest part of the project quickly became the most challenging.

This phase marked the beginning of my detection engineering journey.

Understanding How Wazuh Detects Events

Before writing any XML, I wanted to understand how Wazuh processes Windows events.

Whenever an event reaches the Wazuh Manager, it follows a sequence:

Windows Event
      │
      ▼
Decoder
      │
      ▼
Built-in Rules
      │
      ▼
Custom Rules
      │
      ▼
Alert Generated

A custom rule is not responsible for collecting logs.

Its job is only to inspect already decoded events and determine whether they match specific conditions.

This distinction became very important later in the troubleshooting process.

Project Objective

For my first detection rule, I chose one of the simplest and most common use cases.

I wanted Wazuh to generate an alert whenever a user executed:

• PowerShell
• Command Prompt

These applications are frequently used by attackers during post-exploitation activities and therefore serve as an excellent introduction to detection engineering.

Writing My First Rule

I created my custom rule inside:

/var/ossec/etc/rules/local_rules.xml

The idea was straightforward:

If Sysmon Event ID 1 indicated that powershell.exe or cmd.exe had started, Wazuh should generate a custom alert.

Initially, my rule looked correct.

It contained:

• Rule ID
• Rule Level
• Event ID
• Image field
• Description

Everything appeared to be properly configured.

I restarted the Wazuh Manager, generated fresh PowerShell events, and searched the dashboard.

Expected Result

PowerShell.exe
        │
        ▼
Sysmon Event ID 1
        │
        ▼
Custom Rule
        │
        ▼
Alert Generated

Actual Result

Nothing happened.

Searching the dashboard returned:

No Results Found

Despite executing PowerShell multiple times, my custom rule never triggered.

Initial Assumption

My first thought was that the XML rule itself contained an error.

However, instead of rewriting the rule immediately, I decided to verify each stage of the detection pipeline again.

This decision ultimately saved a significant amount of time.

First Verification

I confirmed that Sysmon was still generating Process Creation events.

Using PowerShell:

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5

The output clearly showed:

Event ID : 1

Process Create

This meant the endpoint was functioning correctly.

Second Verification

Next, I confirmed that the Wazuh Agent was forwarding the logs.

I reviewed the Windows Agent log:

C:\Program Files (x86)\ossec-agent\ossec.log

The agent remained online and connected to the manager.

No communication errors were preventing log delivery.

Third Verification

I searched for Sysmon events inside the Wazuh Dashboard.

The events were present.

This confirmed:

• Windows generated the event.
• Sysmon recorded the event.
• Wazuh Agent forwarded the event.
• Wazuh Manager received the event.
• OpenSearch indexed the event.

Everything worked perfectly.

Except…

My custom rule still refused to trigger.

The Real Investigation Begins

At this point, I realized something important.

The problem was not in the logging pipeline.

The issue had to exist inside the rule itself.

This changed my troubleshooting strategy completely.

Instead of checking Windows or the Wazuh Agent again, I shifted my focus to the Wazuh rule engine.

I began asking questions such as:

• Is the XML valid?
• Did the rule actually load?
• Is the Rule ID duplicated?
• Are the field names correct?
• Am I referencing the correct parent rule?
• Is Wazuh evaluating my rule at all?

These questions became the roadmap for the next phase of the investigation.

Why This Was an Important Lesson

One of the biggest mistakes beginners make is assuming that if a detection rule doesn’t work, the problem must be the rule itself.

In reality, detection failures can occur anywhere in the telemetry pipeline.

By systematically validating each component before modifying the rule, I eliminated unnecessary guesswork and narrowed the problem down to the rule engine.

This approach closely reflects how experienced SOC analysts troubleshoot detection issues in production environments.

Key Takeaways

This stage taught me several valuable lessons:

• Always validate the telemetry pipeline before modifying detection logic.
• A missing alert does not necessarily indicate a logging problem.
• Custom rules depend on correctly decoded events.
• Systematic troubleshooting is more effective than repeatedly editing XML files.

Most importantly, I learned that successful detection engineering requires understanding the entire event processing workflow — not just writing XML rules.

Troubleshooting the Detection Rules: From Failure to Success

At this point, I had verified that my environment was working correctly.

• Sysmon was generating Process Creation events.
• The Wazuh Agent was online.
• The Wazuh Manager was receiving the events.
• Sysmon logs were visible in the Wazuh Dashboard.

Despite all of this, my custom detection rules still failed to generate alerts.

Rather than continuing to modify the XML file randomly, I decided to approach the problem systematically. I treated each issue as an investigation and validated one component at a time until I found the root cause.

This troubleshooting process ultimately became the most valuable part of the project.

Problem 1 — XML Syntax Errors

The first issue appeared immediately after restarting the Wazuh Manager.

The manager refused to load my custom rules and recorded the following error in ossec.log:

ERROR: Error reading XML file 'etc/rules/local_rules.xml'
XMLERR: Element '<group' not closed.

On another attempt, the error changed to:

ERROR: End of file and some elements were not closed.

Investigation

These messages indicated that Wazuh could not parse the XML file.

To verify the issue, I reviewed the structure of local_rules.xml and checked:

• Opening and closing <group> tags
• Opening and closing <rule> tags
• Proper nesting of XML elements

Root Cause

Some XML elements were either missing closing tags or were incorrectly nested, causing the entire rule file to fail during parsing.

Resolution

I corrected the XML structure and restarted the Wazuh Manager.

Once the syntax errors were fixed, the XML loaded successfully and the parsing errors disappeared from ossec.log.

Problem 2 — Duplicate Rule IDs

After resolving the XML issues, another error appeared:

Rule ID '100100' is duplicated.
Only the first occurrence will be considered.

Investigation

Using grep, I searched for duplicate Rule IDs throughout the Wazuh configuration.

grep -R '100100' /var/ossec

Initially, I suspected that the duplicate existed in the built-in ruleset. However, after reviewing the results, I discovered that the duplicate was caused by my own custom rule definitions.

Root Cause

I had accidentally created multiple rules using the same Rule ID.

Since Wazuh requires every Rule ID to be unique, the manager ignored the later definitions.

Resolution

I removed the duplicate entries and assigned unique Rule IDs to each custom rule.

Problem 3 — Invalid Rule Dependency

The next issue appeared during rule validation.

ERROR:
No such description at rule '100101'

Investigation

This error indicated that my rule depended on another rule that Wazuh could not resolve.

At first, I believed the problem was related to the Rule ID itself. After examining the XML structure more closely, I realized the issue was with the rule dependency.

Root Cause

The child rule referenced a parent rule that either failed to load or was not available during rule evaluation.

As a result, Wazuh ignored the dependent rule.

Resolution

I corrected the rule hierarchy and ensured that every dependent rule referenced a valid parent.

Problem 4 — “No Results” in the Dashboard

This was the most confusing issue of the project.

Even after fixing the XML and restarting the manager, searching for my custom Rule IDs returned:

No Results Found

At first, I assumed that my detection logic was incorrect.

Instead of modifying the rule again, I decided to validate the entire logging pipeline from the beginning.

Step 1 — Verify Sysmon

I confirmed that Sysmon was still generating Event ID 1.

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5

Result:

✅ Sysmon was working correctly.

Step 2 — Verify the Wazuh Agent

I checked the agent log:

C:\Program Files (x86)\ossec-agent\ossec.log

Result:

• Agent connected
• Agent online
• No communication errors

Step 3 — Verify Event Collection

Inside the Wazuh Dashboard, I searched for Sysmon events.

The events appeared immediately.

This confirmed:

• Sysmon generated the events.
• The Wazuh Agent forwarded the logs.
• The Wazuh Manager received the data.
• The Indexer stored the events successfully.

The telemetry pipeline was functioning correctly.

The issue had to be inside my custom rule.

Problem 5 — Incorrect Field Names

This turned out to be one of the most important discoveries during the project.

While reviewing the JSON events inside Discover, I noticed fields such as:

data.win.system.eventID

data.win.eventdata.image

Naturally, I used these field names inside my XML rules.

However, the rules still failed.

After investigating Wazuh’s built-in Sysmon rules, I discovered that the rule engine actually references decoded fields differently.

For example:

win.eventdata.image

win.eventdata.commandLine

instead of

data.win.eventdata.image

Root Cause

I was writing rules based on the indexed JSON structure shown in the dashboard rather than the decoded fields used internally by the Wazuh rule engine.

Resolution

I modified the rules to use the correct decoded field names, matching the structure used by the official Wazuh Sysmon rules.

Problem 6 — Understanding if_sid vs if_group

Another challenge was deciding how to chain my custom rules.

Initially, I attempted to build my own base rule and reference it using:

<if_sid>100100</if_sid>

Although this seemed logical, it introduced unnecessary complexity and caused additional dependency issues.

While studying the official Wazuh Sysmon rules, I noticed that they already classify Process Creation events into a predefined group:

<if_group>sysmon_event1</if_group>

This meant I didn’t need to create another base rule. Instead, I could extend the existing rule group maintained by Wazuh.

This approach was cleaner, more reliable, and aligned with the platform’s native rule hierarchy.

Final Result

After correcting:

• XML syntax
• Duplicate Rule IDs
• Rule dependencies
• Field names
• Rule hierarchy

I restarted the Wazuh Manager one final time.

This time, no errors appeared in ossec.log.

I generated new PowerShell and Command Prompt events, searched the dashboard, and finally observed my custom alerts.

For the first time, the custom detection rules were working exactly as intended.

Lessons Learned

This troubleshooting process fundamentally changed how I approach detection engineering.

Rather than assuming the XML was always the problem, I learned to validate every stage of the detection pipeline, isolate the failing component, and resolve issues based on evidence rather than guesswork.

The experience reinforced that successful detection engineering is built on structured investigation, careful validation, and a solid understanding of how telemetry flows through the SIEM.

Final Working Detection Rules and Validation

After several rounds of troubleshooting, I finally identified the issues preventing my custom detection rules from working. By correcting the XML structure, removing duplicate rule IDs, using the correct decoded field names, and referencing the appropriate built-in Sysmon group, the Wazuh Manager successfully loaded my rules.

The next step was to validate that the rules worked as expected by generating live Windows events and confirming that Wazuh detected them.

The Final Custom Rules

The final version of my custom rules was stored in:

/var/ossec/etc/rules/local_rules.xml

Below is the working configuration.

<!-- Local rules -->

<group name="local,sysmon_custom">

    <!-- Detect PowerShell Execution -->
    <rule id="100101" level="12">
        <if_group>sysmon_event1</if_group>

        <field name="win.eventdata.image" type="pcre2">
            (?i)\\powershell\.exe$
        </field>

        <description>
            PowerShell Execution Detected
        </description>

        <mitre>
            <id>T1059.001</id>
        </mitre>

        <group>
            attack,powershell,execution
        </group>
    </rule>

    <!-- Detect CMD Execution -->

    <rule id="100102" level="10">

        <if_group>sysmon_event1</if_group>

        <field name="win.eventdata.image" type="pcre2">
            (?i)\\cmd\.exe$
        </field>

        <description>
            Command Prompt Execution Detected
        </description>

        <mitre>
            <id>T1059.003</id>
        </mitre>

        <group>
            attack,cmd,execution
        </group>

    </rule>

</group>

Understanding the XML

Rather than copying the rule, I wanted to understand every element used in the configuration.

Rule ID

<rule id="100101" level="12">

Every Wazuh rule requires a unique Rule ID.

The Rule ID uniquely identifies the detection whenever an alert is generated.

Example:

Rule ID : 100101

This allows analysts to search directly for that detection inside the Wazuh Dashboard.

Alert Level

level="12"

The alert level determines the severity of the detection.

Higher levels indicate events that require greater attention.

For this project:

RuleLevelPowerShell12CMD10

Rule Group

<if_group>sysmon_event1</if_group>

This line became the most important discovery of the project.

Initially, I attempted to create my own base rule.

After studying Wazuh’s built-in Sysmon rules, I realized that every Sysmon Event ID 1 already belongs to the built-in group:

sysmon_event1

Instead of rebuilding the detection chain, I simply extended the existing group.

This approach made the rules much cleaner and more reliable.

Field Matching

<field name="win.eventdata.image">

This tells Wazuh which field should be inspected.

For PowerShell:

Image

↓

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

For CMD:

Image

↓

C:\Windows\System32\cmd.exe

Regular Expression

(?i)\\powershell\.exe$

This uses a PCRE2 regular expression.

Meaning:

(?i)

Case-insensitive matching

\\

Matches the Windows path separator

powershell.exe

Executable name

$

End of string

Therefore the rule matches:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

but ignores unrelated filenames.

MITRE ATT&CK Mapping

<mitre>
<id>T1059.001</id>
</mitre>

The rule is mapped to:

Execution

↓

Command and Scripting Interpreter

↓

PowerShell

Likewise,

cmd.exe

is mapped to:

T1059.003

Mapping detections to MITRE ATT&CK helps analysts understand the attacker technique associated with each alert and supports consistent reporting.

Restarting the Manager

After saving the custom rules, I restarted the Wazuh Manager.

sudo systemctl restart wazuh-manager

To confirm that the rules loaded successfully, I checked the manager log.

sudo tail -30 /var/ossec/logs/ossec.log

The absence of XML parsing or rule loading errors confirmed that the configuration was valid.

Generating Test Events

To validate the PowerShell rule, I generated a new PowerShell process.

Start-Process powershell.exe

Next, I generated a Command Prompt process.

Start-Process cmd.exe

These actions caused Sysmon to generate new Process Creation (Event ID 1) logs.

Validating the Detection

Inside the Wazuh Dashboard, I opened the Discover page and searched for my custom Rule IDs.

PowerShell detection:

rule.id:100101

Result:

(Insert Screenshot: PowerShell alert in Wazuh Discover)

The search returned the expected alert, confirming that the custom rule had successfully matched the Sysmon event.

For Command Prompt, I searched:

rule.id:100102

Result:

(Insert Screenshot: CMD alert in Wazuh Discover)

The dashboard displayed the expected detection, confirming that the second custom rule was also functioning correctly.

Detection Pipeline Validation

At this point, I had successfully validated the complete detection pipeline.

User Launches PowerShell
           │
           ▼
Windows Creates Process
           │
           ▼
Sysmon Records Event ID 1
           │
           ▼
Wazuh Agent Collects Event
           │
           ▼
Wazuh Manager Decodes Event
           │
           ▼
Custom XML Rule Matches
           │
           ▼
Alert Generated
           │
           ▼
Stored in OpenSearch
           │
           ▼
Displayed in Wazuh Dashboard

Every stage of the pipeline operated as expected, confirming that the environment was correctly configured.

What This Project Demonstrated

By completing this project, I was able to demonstrate practical skills in several areas:

• Building and configuring a Wazuh home lab
• Working with Windows Sysmon telemetry
• Creating custom Wazuh XML detection rules
• Understanding Wazuh rule hierarchy
• Debugging XML syntax and rule logic
• Using PCRE2 regular expressions
• Validating detections with live endpoint activity
• Mapping detections to MITRE ATT&CK techniques
• Investigating and troubleshooting SIEM pipelines

This project was more than simply creating two detection rules. It provided a structured introduction to detection engineering and reinforced the importance of understanding the complete flow of security telemetry from endpoint to SIEM.

Conclusion, Lessons Learned, and Future Work

This project started with what seemed like a simple objective: create custom Wazuh detection rules for PowerShell and Command Prompt execution using Sysmon Event ID 1.

However, as I progressed through the implementation, I realized that writing XML rules represented only a small portion of the overall process.

The real challenge was understanding how endpoint telemetry flows through the SIEM, how Wazuh evaluates detection logic, and how to troubleshoot issues systematically when expected alerts fail to appear.

By the end of the project, I had successfully built a working detection pipeline and gained practical experience that extends well beyond writing custom rules.

Project Summary

During this project, I successfully:

• Built a Wazuh 4.14.7 home lab.
• Connected a Windows 11 endpoint to the Wazuh Manager.
• Installed and configured Sysmon.
• Verified Sysmon Process Creation (Event ID 1) telemetry.
• Created custom Wazuh XML detection rules.
• Generated alerts for:
• PowerShell execution
• Command Prompt execution
• Mapped detections to the MITRE ATT&CK framework.
• Validated alerts inside the Wazuh Dashboard.

More importantly, I developed a structured troubleshooting methodology that helped me identify and resolve multiple issues throughout the project.

Technical Skills Developed

This project allowed me to strengthen several practical cybersecurity skills, including:

SIEM & Detection Engineering

• Wazuh architecture
• Rule development
• Alert validation
• Detection testing

Windows Security Monitoring

• Sysmon configuration
• Windows Event Logs
• Process Creation events
• Endpoint telemetry analysis

XML Rule Development

• Custom rule creation
• Rule hierarchy
• Rule dependencies
• Field matching
• Regular expressions (PCRE2)

Troubleshooting

• XML syntax validation
• Duplicate Rule IDs
• Rule loading issues
• Log analysis
• Wazuh Manager diagnostics
• Event verification

Threat Detection

• PowerShell execution
• Command Prompt execution
• Process monitoring
• MITRE ATT&CK mapping

Biggest Lessons Learned

One of the biggest lessons from this project was that detection engineering is not simply about creating XML rules.

A detection rule depends on an entire pipeline functioning correctly.

Windows Process
      │
      ▼
Sysmon
      │
      ▼
Windows Event Logs
      │
      ▼
Wazuh Agent
      │
      ▼
Wazuh Manager
      │
      ▼
Rule Engine
      │
      ▼
Indexer
      │
      ▼
Dashboard

If any component fails, the alert will never be generated.

Understanding this pipeline fundamentally changed how I approach troubleshooting.

Instead of modifying XML repeatedly, I learned to validate every stage independently before drawing conclusions.

My Troubleshooting Mindset

One of the most valuable outcomes of this project was developing a repeatable troubleshooting methodology.

Instead of guessing, I followed a structured process:

Detection Failed
        │
        ▼
Verify Endpoint
        │
        ▼
Verify Sysmon
        │
        ▼
Verify Wazuh Agent
        │
        ▼
Verify Manager
        │
        ▼
Review Logs
        │
        ▼
Validate Rule
        │
        ▼
Generate New Event
        │
        ▼
Confirm Detection

This systematic approach significantly reduced unnecessary changes and made it easier to identify the actual root cause of each issue.

I believe this way of thinking is just as important as writing the detection rules themselves.

Real-World Relevance

Although this project was completed in a home lab, the concepts directly reflect real-world Security Operations Center (SOC) responsibilities.

SOC analysts routinely need to:

• Verify endpoint telemetry.
• Investigate missing alerts.
• Validate detection logic.
• Troubleshoot data collection issues.
• Analyze Windows events.
• Understand attacker techniques.
• Improve detection coverage.

Working through this project provided hands-on experience with each of these activities in a controlled environment.

Future Work

This project marks the beginning of my Detection Engineering learning journey.

My next objective is to build additional custom detections focused on attacker behavior rather than simply identifying application execution.

Planned projects include:

PowerShell

• EncodedCommand detection
• ExecutionPolicy Bypass
• DownloadString
• Invoke-WebRequest

Living-off-the-Land Binaries (LOLBins)

• Rundll32
• Regsvr32
• MSHTA
• Certutil
• WMIC
• BITSAdmin

Persistence Techniques

• Scheduled Tasks
• Registry Run Keys
• Startup Folder
• Services

Lateral Movement

• PsExec
• Remote PowerShell
• SMB Execution

Credential Access

• Mimikatz
• LSASS Access
• Credential Dumping

Detection Engineering

• Sigma Rule conversion
• Custom Wazuh rules
• MITRE ATT&CK mapping
• False positive tuning
• Detection validation

Each project will be documented with the same level of detail, focusing not only on the final solution but also on the investigation process and lessons learned.

Final Thoughts

This project began with a simple goal: detect PowerShell and Command Prompt execution using Wazuh.

What I gained was much more than two working detection rules.

I learned how Windows generates security telemetry, how Wazuh processes and evaluates events, how to investigate failures systematically, and how to validate detections using real endpoint activity.

Most importantly, I realized that detection engineering is not about writing the most complex rule — it is about understanding the data, asking the right questions, and solving problems through careful analysis.

As I continue learning, I plan to expand this home lab with additional detection use cases, simulate real-world attack techniques, and document each project to build a practical portfolio that reflects my growth as a cybersecurity professional.

Acknowledgements

This project was completed in a personal home lab for educational purposes. The goal was to gain practical experience in Wazuh, Sysmon, and detection engineering by building, troubleshooting, and validating custom detections in a controlled environment.

I hope this case study helps other cybersecurity learners understand not only how to build custom Wazuh detection rules, but also how to think through the troubleshooting process when things don’t work as expected.