Modern Windows environments generate an enormous amount of security telemetry. While this visibility is valuable, it can also overwhelm security teams if they rely solely on default detection rules. Attackers increasingly use legitimate Windows tools, PowerShell, WMI, scheduled tasks, and signed binaries to avoid traditional antivirus detection. Identifying these techniques requires detailed endpoint telemetry and well-crafted detection logic.This is where Wazuh Sysmon Rules become essential.

By combining Microsoft’s Sysmon with Wazuh’s rule engine, organizations can detect suspicious process execution, persistence mechanisms, credential theft attempts, lateral movement, and other advanced attack behaviors that would otherwise remain hidden in standard Windows Event Logs.

Although Wazuh includes built-in support for many Sysmon events, every organization has unique applications, administrators, and security requirements.

Creating custom Sysmon rules allows you to detect behaviors specific to your environment while reducing false positives and improving incident response.

In this guide, you’ll learn how Wazuh processes Sysmon events, how custom rules work, how to build and test them, and how to create production-ready detections that generate actionable alerts instead of unnecessary noise.

What Are Wazuh Sysmon Rules?

Wazuh Sysmon Rules are custom or built-in detection rules that analyze events generated by Microsoft Sysmon (System Monitor).

These rules evaluate Sysmon event data after it has been collected by the Wazuh agent and determine whether an event should generate a security alert.

Rather than relying solely on native Windows Security logs, Sysmon records significantly richer telemetry, including:

Process creation
Parent-child process relationships
Command-line arguments
Network connections
DLL loading
File creation timestamps
Registry modifications
Driver loading
Named pipe creation
WMI activity
DNS queries
Process injection attempts

Wazuh parses these events, extracts relevant fields through decoders, and evaluates them against XML-based rules.

If rule conditions match, Wazuh generates alerts with severity levels, MITRE ATT&CK mappings, and detailed forensic information.

This layered architecture makes Wazuh far more effective than monitoring Windows Event Logs alone.

How Sysmon Improves Windows Security Monitoring

Sysmon is part of the Sysinternals Suite developed by Microsoft.

Unlike Windows Security logs, which primarily focus on authentication and system auditing, Sysmon continuously records detailed endpoint activity that security analysts use to identify attacker behavior.

For example, Sysmon can capture:

Every process that launches
Full command-line arguments
Parent process information
Hashes of executable files
Outbound network connections
Registry persistence changes
PowerShell execution
DLL injection activity

These events remain available in the Microsoft-Windows-Sysmon/Operational event log, where Wazuh can collect and analyze them.

Security researchers at Microsoft and the MITRE ATT&CK project consistently recommend process creation telemetry and command-line logging because they provide valuable visibility into attacker techniques such as credential dumping, living-off-the-land attacks, persistence, and privilege escalation.

How Wazuh Processes Sysmon Events

When Sysmon records an event, it writes it to the Windows Event Log rather than sending it directly to Wazuh.

The processing workflow typically follows these steps:

Sysmon captures an endpoint event.
The event is written to the Sysmon Operational log.
The Wazuh agent monitors the event channel.
The event is securely forwarded to the Wazuh Manager.
Wazuh decoders extract useful fields.
Detection rules evaluate the decoded data.
Matching rules generate alerts.
Alerts appear in the Wazuh Dashboard or trigger Active Response actions.

Because Wazuh separates data collection, field extraction, and rule evaluation, administrators can customize detections without modifying how events are collected.

Related Guides:

Why Custom Sysmon Rules Are Important

The default Wazuh ruleset provides excellent baseline detection, but every environment behaves differently.

For example:

A software development company regularly launches PowerShell scripts.
A financial institution blocks PowerShell almost entirely.
An enterprise management platform may legitimately spawn thousands of scheduled tasks every day.
A small business may never use scheduled tasks outside Windows updates.

Using identical detection rules across all environments often leads to either excessive false positives or missed attacks.

Custom Sysmon rules allow you to:

Detect organization-specific attack techniques
Ignore trusted administrative tools
Alert only on high-risk behaviors
Add custom severity levels
Detect suspicious command-line arguments
Identify unauthorized software
Monitor critical business applications
Map alerts to MITRE ATT&CK techniques

This customization dramatically improves detection quality while reducing alert fatigue.

Related Guide: How to Reduce False Positives in Wazuh

Benefits of Extending the Default Wazuh Ruleset

Extending Wazuh’s built-in Sysmon rules provides several operational and security advantages.

Some of the biggest benefits include:

Improved visibility into attacker behavior
Faster detection of lateral movement
Better ransomware detection
Earlier identification of persistence mechanisms
Organization-specific threat detection
Reduced false positives
Better compliance reporting
Easier threat hunting
More accurate severity scoring
Custom MITRE ATT&CK mappings

Many mature Security Operations Centers (SOCs) treat vendor-provided detection rules as a starting point rather than a finished solution.

They continuously refine detections using their own infrastructure, threat intelligence, and incident history.

This approach aligns with guidance from organizations such as the Center for Internet Security (CIS), which recommends continuous monitoring and environment-specific detection tuning as key elements of effective cyber defense.

How Wazuh Integrates with Sysmon

Wazuh and Sysmon complement one another by combining rich endpoint telemetry with a flexible detection engine.

Sysmon focuses on collecting detailed Windows activity, while Wazuh centralizes, parses, correlates, and analyzes that information to generate meaningful security alerts.

Understanding how data flows between the two systems helps when creating custom rules, troubleshooting missing alerts, or optimizing detection performance.

Installing and Configuring Sysmon

Before Wazuh can analyze Sysmon events, Sysmon must be installed on each Windows endpoint.

A typical installation involves:

Downloading Sysmon from Microsoft’s Sysinternals website.
Selecting a trusted configuration file.
Installing Sysmon using administrative privileges.
Verifying that the Sysmon service is running.
Confirming events are appearing in the Sysmon Operational log.

While Sysmon can run with its default configuration, most organizations deploy a community-maintained configuration that enables useful event types while filtering excessive noise.

One of the most widely used configurations is maintained by SwiftOnSecurity, whose Sysmon configuration has become a de facto standard across many enterprise environments because it balances visibility with manageable event volume.

Forwarding Sysmon Logs to Wazuh

Once Sysmon is installed, the Wazuh agent must monitor the appropriate Windows Event Channel.

Typically, this is accomplished by configuring the agent to collect events from:

Microsoft-Windows-Sysmon/Operational

The Wazuh agent continuously reads new events from this channel and securely forwards them to the Wazuh Manager over an encrypted connection.

Unlike traditional log forwarding tools, Wazuh also enriches the incoming data, correlates events, and applies custom detection rules before generating alerts.

Event Flow from Windows Endpoint to Wazuh Manager

A typical Sysmon event follows this processing path:

Windows Activity
       │
       ▼
Microsoft Sysmon
       │
       ▼
Windows Event Log
(Microsoft-Windows-Sysmon/Operational)
       │
       ▼
Wazuh Agent
       │
       ▼
Encrypted Transmission
       │
       ▼
Wazuh Manager
       │
       ▼
Decoder
       │
       ▼
Rules Engine
       │
       ▼
Alerts
       │
       ▼
Wazuh Dashboard / Active Response

This modular pipeline allows administrators to customize decoding logic and detection rules independently, making it easier to adapt to new log formats or evolving attack techniques.

Related Guide: How to Configure Wazuh Active Response

Relationship Between Decoders and Rules

Many new Wazuh users confuse decoders with rules, but they perform different functions.

A decoder extracts structured data from incoming logs, such as:

Process name
Username
Parent process
Destination IP
Command line
Hash values
Event ID

A rule then evaluates those extracted fields to determine whether the activity matches suspicious behavior.

Without a decoder, Wazuh cannot reliably identify individual log fields. Without rules, decoded data is simply collected without generating meaningful alerts.

Understanding this relationship is fundamental when creating custom Sysmon detections.

Related Guides:

Understanding Sysmon Event IDs

Every Sysmon event belongs to a specific Event ID that represents a particular type of system activity.

Custom Wazuh rules often target one or more of these IDs to detect malicious behavior.

Some of the most commonly monitored Event IDs include:

Sysmon Event ID	Description	Common Detection Use Cases
1	Process Creation	Malware execution, PowerShell abuse, LOLBins
3	Network Connection	C2 traffic, suspicious outbound connections
7	Image Loaded	DLL hijacking, unsigned modules
8	CreateRemoteThread	Process injection
10	Process Access	Credential dumping, LSASS access
11	File Create	Ransomware activity, malware drops
12–14	Registry Events	Persistence mechanisms
22	DNS Query	Malicious domains, DNS tunneling
25	Process Tampering	Defense evasion

Rather than alerting on every occurrence of these events, effective custom rules combine Event IDs with additional conditions, such as process names, parent processes, command-line arguments, or destination IP addresses, to improve detection accuracy and reduce false positives.

Prerequisites

Before creating custom Wazuh Sysmon rules, verify that your environment is correctly configured.

Missing components or incorrect configurations can prevent Sysmon events from reaching the Wazuh Manager or stop detection rules from triggering altogether.

The following prerequisites help ensure a smooth implementation.

Supported Wazuh Versions

Custom Sysmon rules are supported in all modern Wazuh releases that include Windows Event Channel monitoring and the current XML-based rules engine.

For production environments, use a currently supported Wazuh release to benefit from the latest:

Security updates
Decoder improvements
Built-in detection rules
Dashboard enhancements
Performance optimizations
Bug fixes

Keeping managers and agents on compatible versions also helps avoid decoding inconsistencies and rule compatibility issues.

Related Guide: How to Upgrade a Wazuh Agent

Supported Windows Versions

Sysmon supports a broad range of Windows operating systems, including:

Windows 10
Windows 11
Windows Server 2016
Windows Server 2019
Windows Server 2022
Newer supported Windows Server releases

For enterprise deployments, ensure all endpoints receive consistent Sysmon configurations so your custom Wazuh rules behave predictably across the environment.

Installing Sysmon with an Appropriate Configuration

Installing Sysmon with its default settings provides only limited visibility.

Most organizations deploy a carefully curated configuration that enables valuable event types while filtering common noise sources.

A well-designed configuration should:

Enable process creation logging
Capture command-line arguments
Monitor network connections
Log registry persistence events
Record driver loading
Track DNS queries
Exclude trusted system activity where appropriate

This approach produces high-quality telemetry while keeping storage requirements manageable.

Configuring Windows Event Channel Collection

The Wazuh agent must be configured to collect the Sysmon Operational event channel.

Verify that:

The Sysmon Operational log is enabled.
The Wazuh agent monitors the correct event channel.
Event collection settings have been applied successfully.
The agent service is running.
The manager is receiving Windows event data.

Incorrect channel names or disabled event logs are common reasons for missing Sysmon alerts.

Verifying Sysmon Events Are Reaching Wazuh

Before creating custom rules, confirm that Sysmon events are successfully reaching the Wazuh Manager.

You can verify this by:

Launching a test process (such as Command Prompt).
Confirming a Process Creation (Event ID 1) appears in the Sysmon Operational log.
Checking that the event reaches the Wazuh Dashboard.
Running wazuh-logtest against a sample event.
Verifying that the appropriate decoder extracts the expected fields.

Testing the full ingestion pipeline before writing rules helps isolate configuration issues early and ensures your custom detections behave as expected.

Related Guide: How to Use Wazuh Logtest

Understanding the Wazuh Rule Structure

Every Wazuh rule follows a structured XML format that tells the rules engine what to detect, how to evaluate an event, and what alert to generate.

Understanding each component of a rule is essential before writing custom Sysmon detections.

Although Sysmon provides detailed telemetry, Wazuh rules determine which events are considered suspicious.

Well-designed rules are easier to maintain, generate fewer false positives, and can be extended as your environment evolves.

Rule IDs

Every Wazuh rule must have a unique numeric Rule ID.

The Rule ID allows Wazuh to uniquely identify each detection and is used when:

Referencing parent or child rules
Testing rules with wazuh-logtest
Reviewing alerts
Troubleshooting rule behavior
Updating or disabling rules

For custom rules, avoid modifying built-in rule IDs.

Instead, place your rules in the local_rules.xml file and use IDs from the custom rule range recommended by Wazuh documentation to prevent conflicts during upgrades.

For example:

<rule id="100500" level="10">
    ...
</rule>

Using a consistent numbering scheme also makes large rule sets easier to organize.

Rule Levels

The level attribute determines the severity of an alert.

Higher levels indicate more serious security events and can influence dashboards, notifications, and Active Response actions.

A typical severity strategy might look like this:

Rule Level	Severity	Typical Use Case
0	Ignore	Event intentionally discarded
1–4	Informational	Normal activity
5–7	Low	Suspicious but low risk
8–10	Medium	Potential attack requiring review
11–13	High	Strong indicators of compromise
14–16	Critical	Active attack or confirmed malicious behavior

Choosing the correct severity prevents analysts from being overwhelmed with unnecessary high-priority alerts.

Parent and Child Rules

Wazuh supports hierarchical rule relationships using parent and child rules.

A parent rule performs broad matching, while child rules perform increasingly specific checks.

For example:

Parent rule:

Matches all Sysmon Process Creation events.

Child rule:

Matches only Process Creation events where PowerShell launches with suspicious command-line arguments.

This layered approach offers several advantages:

Less duplicated rule logic
Easier maintenance
Better organization
Improved performance
More granular detections

Complex Sysmon detections often rely heavily on parent-child relationships to build reusable rule logic.

Rule Groups

Groups organize related rules into logical categories.

Examples include:

sysmon
windows
malware
persistence
privilege_escalation
process_creation
network
ransomware

Groups make it easier to:

Filter alerts
Build dashboard visualizations
Create correlation rules
Export reports
Search historical events

Using descriptive group names becomes increasingly important as your custom ruleset grows.

Matching Conditions

Matching conditions define when a rule should trigger.

Wazuh supports numerous condition types, including:

Event ID
Field values
Regular expressions
Exact string matches
Command-line arguments
Process names
Registry paths
IP addresses
Hashes
Parent process names
Usernames

Conditions can also be combined to detect sophisticated attack behavior.

For example, a rule could require all of the following:

Sysmon Event ID 1
Process is powershell.exe
Command line contains -EncodedCommand
Parent process is winword.exe

This combination dramatically reduces false positives compared to matching PowerShell execution alone.

Rule Descriptions

Every rule should contain a clear description explaining what was detected.

For example:

Suspicious PowerShell launched from Microsoft Word

Good descriptions should:

Be concise
Explain the suspicious behavior
Avoid vague wording
Help analysts immediately understand the alert

A descriptive alert saves valuable investigation time during incident response.

MITRE ATT&CK Mapping

One of Wazuh’s strongest capabilities is mapping detections to the MITRE ATT&CK framework.

A Sysmon rule can reference one or more ATT&CK techniques, helping analysts understand:

The attacker’s objective
The phase of the attack
Common adversary behaviors
Related detections

For example:

Activity	ATT&CK Technique
PowerShell abuse	T1059.001
Process Injection	T1055
Registry Persistence	T1547
Credential Dumping	T1003
DLL Search Order Hijacking	T1574

MITRE mappings also improve reporting, threat hunting, and security maturity assessments.

Compliance Mappings

Many organizations use Wazuh to support regulatory compliance.

Rules can include mappings for frameworks such as:

PCI DSS
HIPAA
NIST Cybersecurity Framework
NIST SP 800-53
GDPR
ISO/IEC 27001

Compliance mappings allow alerts to contribute directly to audit evidence and security reporting.

For organizations subject to regulatory requirements, adding appropriate mappings to custom rules improves documentation and simplifies future audits.

Common Sysmon Event IDs Used in Detection

Sysmon generates dozens of event types, but a relatively small number account for most security detections in enterprise environments.

Understanding what each Event ID represents helps you decide which events deserve custom Wazuh rules and which can safely be ignored or filtered.

Event ID 1 – Process Creation

Event ID 1 records every newly created process.

It is the most commonly used Sysmon event because it captures:

Executable name
Full command line
Parent process
User account
Process GUID
Hashes
Integrity level

Common detection opportunities include:

Encoded PowerShell
LOLBins
Suspicious scripting engines
Office macro execution
Malware launchers
Ransomware execution

Many advanced detections begin with Event ID 1.

Event ID 3 – Network Connection

Event ID 3 records outbound network connections initiated by processes.

Useful fields include:

Source IP
Destination IP
Destination port
Protocol
Process name
User account

Typical detections include:

Command-and-control traffic
Reverse shells
Unexpected internet connections
Malware beaconing
Lateral movement

Event ID 5 – Process Terminated

Event ID 5 records when a process exits.

While less commonly monitored, it can help:

Build complete process timelines
Correlate malware execution
Detect unusually short-lived processes
Identify suspicious crash behavior

Event ID 7 – Image Loaded

Event ID 7 records DLL loading activity.

Security teams often monitor this event for:

DLL hijacking
Unsigned DLLs
Malicious module injection
Untrusted libraries

Because Windows loads many legitimate DLLs, careful filtering is important to avoid excessive alerts.

Event ID 8 – CreateRemoteThread

Event ID 8 detects one process creating a thread inside another process.

This behavior is strongly associated with:

Process injection
Malware loaders
Credential theft
Remote code execution

Because legitimate software rarely performs remote thread creation, this event often deserves high-severity investigation.

Event ID 10 – Process Access

Event ID 10 records one process accessing another process.

It is commonly used to detect:

LSASS access
Credential dumping
Process memory inspection
Malware reconnaissance

Security teams frequently build custom Wazuh rules around Event ID 10 to identify tools such as Mimikatz and similar credential theft utilities.

Event ID 11 – File Create

Event ID 11 records newly created files.

Detection opportunities include:

Malware payload drops
Web shell creation
Ransomware encryption artifacts
Executables written to temporary directories

Monitoring sensitive directories can significantly improve malware detection.

Event ID 12–14 – Registry Events

Events 12, 13, and 14 monitor registry activity.

These events capture:

Registry key creation
Registry value modification
Registry key deletion

They are particularly useful for detecting persistence mechanisms.

Examples include:

Run keys
Services
Scheduled task registrations
Startup modifications

Event ID 13 – Registry Value Set

Although included within the registry event family, Event ID 13 deserves special attention because it records registry value modifications.

Common malicious examples include:

Adding startup entries
Disabling Windows Defender
Modifying security policies
Changing execution settings

Registry value changes are frequently used during persistence and defense evasion.

Event ID 15 – FileCreateStreamHash

Event ID 15 records Alternate Data Stream (ADS) creation.

Attackers sometimes hide payloads inside NTFS alternate data streams to evade detection.

Custom rules can identify:

Hidden executables
Suspicious ADS creation
Persistence using alternate streams

Although less common, these events often have high investigative value.

Event ID 22 – DNS Query

Event ID 22 logs DNS lookups initiated by processes.

Useful detection scenarios include:

Malware contacting malicious domains
DNS tunneling
Domain generation algorithms (DGAs)
Unexpected cloud service communication

Combining DNS queries with Process Creation events often provides valuable attack context.

Event ID 23–26 – File Delete Events

Events 23–26 record various file deletion activities.

These events can reveal:

Log wiping
Malware cleanup
Ransomware deleting backups
Secure file deletion
Tampering with forensic evidence

While file deletions are common in normal operations, monitoring sensitive directories or combining these events with other indicators can reveal attacker attempts to cover their tracks.

Creating Your First Custom Wazuh Sysmon Rule

Now that you understand how Sysmon events are structured and how Wazuh evaluates rules, it’s time to build your first custom detection.

The following workflow demonstrates the general process security teams use when developing production-ready Sysmon rules.

Selecting the Event to Detect

Begin by identifying a behavior that provides meaningful security value.

Good starting points include:

Encoded PowerShell execution
LSASS access
Office spawning command shells
Process injection
Registry persistence
Suspicious DNS requests
Execution from temporary folders

Start with simple, well-understood detections before building complex multi-condition rules.

Examining the Raw Sysmon Log

Before writing any XML, inspect the original Sysmon event.

Look for fields such as:

Event ID
Image
ParentImage
CommandLine
User
DestinationIp
TargetFilename
RegistryPath

Understanding the raw event ensures you reference the correct fields in your rule.

Using wazuh-logtest during development makes it easier to validate field extraction before enabling the rule in production.

Related Guide: How to Use Wazuh Logtest

Identifying Available Fields

Next, determine which decoded fields Wazuh exposes for matching.

Common fields include:

eventID
Image
ParentImage
CommandLine
CurrentDirectory
User
Hashes
ProcessGuid
DestinationIp
TargetFilename

Only decoded fields can be referenced within rule conditions, making this verification step essential.

Related Guide: Wazuh Decoder Guide

Creating a Custom XML Rule

Custom Sysmon detections are typically created inside the local_rules.xml file.

A basic rule generally includes:

Rule ID
Severity level
Matching conditions
Description
Groups
Optional MITRE mappings
Optional compliance mappings

As your rule set matures, you can build more sophisticated detections by combining multiple conditions, parent-child relationships, and regular expressions.

Assigning an Appropriate Rule ID

Every custom rule requires a unique ID.

Adopt a consistent numbering strategy, for example:

100000–100999 for PowerShell
101000–101999 for persistence
102000–102999 for credential access

A logical numbering convention makes troubleshooting and future maintenance significantly easier.

Setting Severity Levels

Assign a severity level that reflects the actual risk.

For example:

Informational process creation → Low
Suspicious PowerShell execution → Medium
Process injection → High
LSASS credential access → Critical

Avoid assigning every rule a high severity, as doing so can overwhelm analysts and reduce the effectiveness of alert prioritization.

Saving the Rule

After validating the XML syntax, save the rule to your custom rules file.

Before deployment, verify:

XML formatting is valid.
Rule IDs are unique.
Parent references are correct.
Groups are appropriate.
Descriptions are meaningful.
MITRE mappings are included where applicable.

Testing before enabling rules in production helps prevent configuration errors and unintended alerting.

Restarting the Wazuh Manager

Once the rule has been saved, restart or reload the Wazuh Manager so the updated ruleset is loaded.

After the restart:

Generate a matching Sysmon event.
Run wazuh-logtest if necessary.
Confirm the rule matches as expected.
Verify the alert appears in the Wazuh Dashboard.
Fine-tune conditions if false positives occur.

Iterative testing and refinement are key to building reliable custom Sysmon detections that remain effective as your Windows environment changes.

Related Guide:

Example Custom Wazuh Sysmon Rules

One of the biggest advantages of using Wazuh Sysmon Rules is the ability to create detections that target the specific threats your organization is most likely to encounter.

While Wazuh includes many built-in Windows detection rules, custom Sysmon rules allow you to detect emerging attacker techniques, organization-specific abuse, and suspicious behavior that generic rules may overlook.

The examples below illustrate common detection scenarios.

Rather than copying them verbatim into production, treat them as starting points that should be tested and refined using representative logs from your environment.

Best Practice: Always validate new rules with wazuh-logtest before deploying them to production.

Related Guide: How to Test Wazuh Rules

Detect PowerShell Execution

PowerShell is an essential administrative tool but is also one of the most abused utilities during cyber attacks.

A simple detection can alert whenever powershell.exe launches.

Common fields to match include:

Image
ParentImage
CommandLine
User

Consider increasing the severity when PowerShell is launched from:

Microsoft Word
Excel
Outlook
Adobe Reader
Browser processes

This helps identify macro-based malware and phishing attacks.

Detect Encoded PowerShell Commands

Attackers frequently use Base64-encoded commands to hide malicious PowerShell activity.

Watch for command-line arguments such as:

-EncodedCommand
-enc
FromBase64String
IEX
Invoke-Expression

These switches often indicate obfuscated scripts and deserve higher-priority investigation.

According to Microsoft’s security guidance, monitoring encoded PowerShell commands is an effective way to identify post-exploitation activity.

Detect Suspicious Command-Line Arguments

Many legitimate Windows utilities become dangerous when launched with unusual parameters.

Examples include:

Hidden execution
Downloading remote payloads
Disabling security features
Launching scripts from temporary folders
Bypassing execution policies

Rather than matching only executable names, inspect the full command line for suspicious arguments.

This approach greatly improves detection accuracy.

Detect LOLBins Abuse

Living-off-the-Land Binaries (LOLBins) are trusted Windows executables frequently abused by attackers.

Common examples include:

certutil.exe
mshta.exe
regsvr32.exe
rundll32.exe
wmic.exe
bitsadmin.exe
installutil.exe

A useful custom rule combines:

Process name
Parent process
Command-line arguments
Network activity

Monitoring LOLBins is recommended by the MITRE ATT&CK framework because they are commonly used to evade traditional defenses.

Detect PsExec Execution

PsExec is widely used by administrators for remote management but is also popular among attackers performing lateral movement.

Monitor for:

psexec.exe
PsExec service creation
Remote process execution
Administrative shares
Unexpected parent processes

In environments where PsExec is rarely used, these events may warrant medium or high severity.

Detect Mimikatz-Related Activity

Mimikatz remains one of the best-known credential theft tools.

Although attackers frequently rename the executable, many behaviors remain detectable.

Useful indicators include:

Access to LSASS
Process injection
Privilege escalation
Suspicious command-line arguments
Known hashes (where applicable)

Behavior-based detection is generally more resilient than relying solely on executable names.

Detect Credential Dumping Attempts

Credential dumping tools typically interact with LSASS.exe to extract cached credentials.

Useful Sysmon indicators include:

Event ID 10 (Process Access)
Access rights associated with memory reading
Suspicious requesting process
Unexpected parent processes

Combining multiple conditions significantly reduces false positives while improving confidence.

Detect Suspicious Registry Modifications

Registry changes often indicate persistence or security bypass attempts.

Monitor sensitive locations such as:

Run keys
RunOnce
Services
Image File Execution Options
Winlogon
AppInit_DLLs

Rather than alerting on every registry modification, focus on high-risk paths commonly abused by attackers.

Detect Scheduled Task Creation

Scheduled tasks are frequently used for persistence.

Look for:

schtasks.exe
Task Scheduler COM interfaces
XML task imports
Tasks created by Office applications
Tasks launched from temporary directories

A scheduled task created immediately after PowerShell execution is often more suspicious than either event alone.

Detect Startup Persistence

Attackers commonly establish persistence through startup mechanisms.

Examples include:

Startup folder modifications
Registry Run keys
Startup shortcuts
Startup scripts
Autorun locations

These events become more valuable when correlated with earlier malware execution.

Detect Suspicious Service Creation

Creating new Windows services is another common persistence technique.

Useful indicators include:

Service executable path
Temporary directory execution
Unsigned binaries
Randomized service names
Service creation immediately following malware execution

Legitimate software installations can also create services, so allowlisting known installers is important.

Detect Ransomware Behavior Indicators

No single Sysmon event definitively identifies ransomware, but several behaviors together provide strong indicators.

Examples include:

Large numbers of file creations
File deletions
Registry modifications
Shadow copy deletion
PowerShell execution
Network connections
Process spawning patterns

Correlating multiple Sysmon events generally produces more reliable ransomware detections than relying on a single rule.

Detect Malicious DLL Loading

Event ID 7 provides visibility into DLL loading.

Useful detection opportunities include:

DLLs loaded from temporary folders
Unsigned DLLs
DLL side-loading
DLL search-order hijacking
Suspicious application directories

Because Windows loads thousands of legitimate DLLs, combining Event ID 7 with process information helps reduce unnecessary alerts.

Detect Unusual Outbound Network Connections

Sysmon Event ID 3 records outbound connections initiated by processes.

Custom rules can detect:

Connections to rare countries
Unexpected ports
Command-and-control infrastructure
Internal lateral movement
Administrative tools communicating externally

Combining network activity with process names often yields much higher detection fidelity.

Detect Suspicious DNS Requests

Sysmon Event ID 22 records DNS queries.

Potential detection scenarios include:

Newly registered domains
Dynamic DNS providers
Known malicious domains
Domain Generation Algorithms (DGAs)
DNS tunneling patterns

Security teams often enrich DNS detections with threat intelligence feeds before generating high-severity alerts.

Correlating Multiple Sysmon Events

Modern attacks rarely consist of a single suspicious event.

Instead, attackers perform a sequence of actions that collectively reveal malicious intent.

By correlating multiple Sysmon events, Wazuh can identify complete attack chains rather than isolated activities.

This approach improves detection accuracy, reduces false positives, and provides analysts with valuable context during investigations.

Using Parent-Child Rules

Parent-child rules provide one of the most effective methods for correlating Sysmon events.

For example:

Parent Rule

Matches every Process Creation event.

Child Rule

Matches PowerShell.

Grandchild Rule

Matches encoded PowerShell launched by Microsoft Word.

This layered approach avoids repeating matching logic while making complex detections easier to manage.

Building Multi-Stage Detections

Many attacks involve several related actions.

For example:

Word launches PowerShell.
PowerShell downloads malware.
Malware creates a scheduled task.
Malware contacts a command-and-control server.

Instead of alerting independently on each event, custom rules can correlate these stages to generate a higher-confidence alert representing the complete attack.

Tracking Attacker Behavior

Correlating Sysmon events helps analysts reconstruct attacker activity.

Typical sequences include:

Initial execution
Privilege escalation
Credential access
Persistence
Defense evasion
Lateral movement
Data exfiltration

This timeline provides significantly more investigative value than isolated alerts.

Mapping correlated detections to the MITRE ATT&CK framework also helps identify the attack lifecycle.

Reducing Duplicate Alerts

Without correlation, one malicious process can generate dozens of alerts.

For example:

Process Creation
DNS Query
Network Connection
Registry Modification
File Creation
DLL Loading

Grouping related events prevents analysts from receiving multiple alerts describing the same underlying activity.

Benefits include:

Less alert fatigue
Faster investigations
Cleaner dashboards
Higher analyst productivity

Creating High-Confidence Detections

High-confidence detections combine multiple independent indicators.

Instead of matching:

PowerShell execution

Consider combining:

Office application launches PowerShell
Encoded command detected
External network connection
Registry persistence created
Scheduled task installed

The more corroborating evidence included, the greater the confidence that malicious activity is occurring.

Reducing False Positives

An effective detection strategy balances visibility with accuracy.

Alerting on every Sysmon event quickly overwhelms analysts and can obscure genuinely malicious activity.

Reducing false positives requires continuous tuning, careful rule design, and an understanding of normal behavior within your environment.

Creating Allowlists

Allowlists prevent alerts for approved software and expected activity.

Examples include:

Corporate management tools
Backup software
Monitoring agents
Antivirus products
Software deployment platforms

Allowlists should be reviewed regularly to ensure they remain accurate as the environment evolves.

Excluding Trusted Applications

Some applications legitimately perform actions that resemble attacker techniques.

Examples include:

PowerShell automation
SCCM
Configuration management tools
Endpoint security software
Backup solutions

Rather than disabling rules entirely, exclude only trusted executables or verified digital signatures where appropriate.

Filtering Administrative Activity

System administrators often perform tasks that would be suspicious for standard users.

Examples include:

Remote PowerShell
PsExec
Scheduled task deployment
Service installation
Registry editing

Filtering known administrative accounts or management servers can substantially reduce unnecessary alerts while preserving visibility into suspicious activity elsewhere.

Limiting Noisy Events

Certain Sysmon events generate extremely high volumes of data.

Examples include:

DLL loading
DNS queries
Network connections
File creation
Registry activity

Consider:

Monitoring only sensitive directories
Filtering common Windows binaries
Excluding known-safe domains
Limiting network events to external destinations
Monitoring only high-value assets

Thoughtful filtering improves performance without sacrificing meaningful detection coverage.

Tuning Severity Levels

Not every suspicious event deserves a critical alert.

Adjust severity based on factors such as:

Asset importance
User privilege
Parent process
Threat intelligence
Historical behavior
Number of correlated events

Risk-based severity assignments help analysts prioritize the events most likely to represent genuine threats.

Regular Rule Maintenance

Attack techniques evolve continuously, and detection rules should evolve with them.

Establish a regular review process to:

Remove obsolete rules
Refine noisy detections
Update MITRE ATT&CK mappings
Incorporate new Sysmon Event IDs
Add detections for emerging attacker techniques
Validate rules after Wazuh or Sysmon upgrades

Microsoft, the Sysinternals team, and the broader security community periodically introduce new Sysmon capabilities and detection recommendations.

Periodic testing with representative production logs helps ensure your custom Wazuh Sysmon rules remain accurate, efficient, and aligned with current threat landscapes.

Related Guides:

Testing Custom Sysmon Rules

Creating a custom rule is only the first step. Before deploying it to production, you should verify that it behaves exactly as intended.

Proper testing confirms that Wazuh correctly parses Sysmon events, evaluates your matching conditions, and generates alerts with the expected severity and metadata.

A thorough testing process also helps identify false positives, missed detections, and performance issues before they affect your Security Operations Center (SOC).

Using wazuh-logtest

wazuh-logtest is one of the most valuable tools for developing and validating custom Wazuh rules.

It allows you to submit sample log events directly to the Wazuh analysis engine without waiting for live data.

When a Sysmon event is tested, wazuh-logtest shows:

Which decoder processed the event
Extracted fields
Matching parent rules
Matching child rules
Final rule that generated an alert
Assigned severity level
Alert description

This immediate feedback significantly shortens the development cycle and helps identify configuration problems early.

A typical workflow is:

Copy a real Sysmon event from the Windows Event Log.
Paste the event into wazuh-logtest.
Review the decoded fields.
Confirm the expected rule is triggered.
Modify the rule if necessary.
Repeat until the desired result is achieved.

Using real production events rather than synthetic examples helps ensure your rules behave correctly in your environment.

Related Guide: How to Use Wazuh Logtest

Validating Rule Matches

A rule triggering successfully is only part of the validation process.

You should also verify that it matches for the correct reasons.

Review the following:

Correct decoder is used
Expected Event ID is matched
All required fields are present
Parent rules execute first
Child rules inherit properly
Severity level is appropriate
MITRE ATT&CK mappings appear correctly
Compliance mappings are included where applicable

Testing multiple variations of the same event helps confirm that your matching conditions are neither too broad nor too restrictive.

Reviewing Generated Alerts

After confirming that a rule matches in wazuh-logtest, verify that the alert appears correctly in the Wazuh Dashboard.

Review important alert fields such as:

Rule ID
Alert level
Timestamp
Endpoint
Process name
Command line
Parent process
Username
MITRE ATT&CK technique
Rule groups

Ensure the alert provides enough context for an analyst to understand the suspicious activity without immediately consulting the original log.

Meaningful alert content reduces investigation time and improves incident response.

Testing Multiple Attack Scenarios

A rule should be tested against more than one event.

For example, a PowerShell detection should be validated using:

Normal administrative PowerShell
Encoded PowerShell
PowerShell launched by Word
PowerShell launched from Explorer
PowerShell downloading remote content
PowerShell executed from scheduled tasks

Similarly, a network detection should be tested using:

Normal web browsing
Internal management traffic
Known malicious domains
Command-and-control simulations
Unexpected outbound ports

Testing both expected and unexpected behaviors helps identify false positives and false negatives before deployment.

Security teams often use frameworks such as Atomic Red Team to safely simulate attacker techniques and verify that detections behave as expected.

Troubleshooting Failed Matches

If a rule does not trigger, work through the detection pipeline step by step.

Verify that:

Sysmon generated the event.
The event reached the Wazuh agent.
The event was forwarded to the manager.
The correct decoder parsed the event.
Required fields exist.
XML syntax is valid.
Rule IDs are unique.
Parent rules match successfully.
Child rules reference the correct parent.
The Wazuh Manager has been restarted or reloaded.

Avoid making multiple changes simultaneously. Test one modification at a time so the root cause is easier to identify.

Best Practices for Writing Wazuh Sysmon Rules

Well-written rules are easier to maintain, generate fewer false positives, and remain effective as your environment grows.

The following best practices are widely adopted by experienced Wazuh administrators and SOC teams.

Use Unique Custom Rule IDs

Assign every custom rule a unique Rule ID that does not conflict with the default Wazuh ruleset.

Consider reserving ID ranges for different detection categories, such as:

PowerShell detections
Persistence
Credential access
Lateral movement
Network activity

A consistent numbering scheme simplifies troubleshooting and long-term maintenance.

Keep Custom Rules Separate from Default Rules

Never edit the built-in Wazuh rules directly.

Instead:

Store custom rules in local_rules.xml or dedicated custom rule files.
Keep custom decoders separate from default decoders.
Preserve vendor-supplied files during upgrades.

This approach prevents customizations from being overwritten when Wazuh is updated and makes future maintenance much easier.

Build Modular Parent-Child Rules

Rather than writing large, repetitive rules, build reusable parent-child hierarchies.

Benefits include:

Reduced duplication
Easier maintenance
Better readability
Improved scalability
More precise detections

For example, create a parent rule that matches all Process Creation events, then use child rules to detect specific tools, command-line arguments, or parent processes.

Map Detections to MITRE ATT&CK

Whenever possible, associate custom rules with relevant MITRE ATT&CK techniques.

This helps:

Classify attacker behavior
Improve threat hunting
Support reporting
Standardize detection coverage
Identify gaps in defensive controls

Maintaining ATT&CK mappings also makes it easier to communicate detection capabilities to security teams and auditors.

Add Meaningful Rule Descriptions

Alert descriptions should clearly explain what was detected.

Instead of:

PowerShell detected

Use:

Encoded PowerShell launched by Microsoft Word

Good descriptions provide analysts with immediate context and reduce the time needed to understand an alert.

Test Every Rule Before Deployment

Never deploy an untested rule into production.

Before enabling a rule:

Validate XML syntax.
Test with wazuh-logtest.
Use real Sysmon events.
Confirm alert formatting.
Verify dashboard visibility.
Check severity levels.
Review parent-child relationships.

Testing significantly reduces deployment issues and unnecessary alert noise.

Related Guide: How to Test Wazuh Rules

Minimize Performance Impact

Highly complex rules can increase CPU usage and processing time, especially in environments generating millions of Sysmon events per day.

To improve performance:

Match only necessary fields.
Avoid excessive regular expressions.
Filter noisy events early.
Reuse parent rules.
Exclude trusted applications.
Limit expensive comparisons where possible.

Efficient rules improve scalability while maintaining detection quality.

Document Rule Changes

Maintain documentation for every custom rule, including:

Rule ID
Purpose
Author
Creation date
Last modified date
ATT&CK mappings
Expected behavior
Testing results

Clear documentation simplifies future troubleshooting and knowledge transfer within the security team.

Version Control Custom Rules

Treat your Wazuh configuration as code.

Store custom rules and decoders in a version control system such as Git to:

Track changes
Review modifications
Roll back mistakes
Support collaborative development
Integrate automated testing into CI/CD pipelines

Version control also provides an audit trail that is invaluable during incident investigations or compliance reviews.

Review and Update Rules Regularly

Attack techniques, operating systems, and applications evolve continuously.

Schedule periodic reviews to:

Remove obsolete detections
Tune noisy rules
Add new Sysmon Event IDs
Improve ATT&CK mappings
Validate compatibility after Wazuh upgrades
Incorporate lessons learned from recent incidents

Routine maintenance ensures your custom rules remain accurate and continue providing meaningful security visibility over time.

Common Problems and Troubleshooting

Even well-designed custom rules can fail if Sysmon, Wazuh, or the Windows environment is not configured correctly.

Understanding the most common issues makes it easier to diagnose problems and restore detection capabilities quickly.

Sysmon Events Are Not Reaching Wazuh

If no Sysmon alerts appear, begin by verifying the data collection pipeline.

Check that:

Sysmon is installed and running.
The Sysmon Operational log contains events.
The Wazuh agent is monitoring the correct Windows Event Channel.
Agent-manager communication is functioning.
Firewall rules permit communication.
The agent configuration has been reloaded after changes.

Working through the pipeline one component at a time is usually the fastest way to isolate the problem.

Custom Rules Never Trigger

If the events reach Wazuh but your rule never matches, verify that:

The rule file is loaded.
XML syntax is valid.
Rule IDs are unique.
Matching conditions reference the correct fields.
Parent rules execute successfully.
Field names match the decoder output.
The Wazuh Manager has been restarted or reloaded.

Testing the same event with wazuh-logtest often reveals where the matching process fails.

Related Guide: How to Use Wazuh Logtest

Incorrect Event IDs

One of the most common mistakes is matching the wrong Sysmon Event ID.

For example:

Using Event ID 3 when the event is actually Event ID 22.
Confusing Registry Events 12–14.
Assuming Process Access is Event ID 8 instead of Event ID 10.

Always verify the Event ID directly from the original Sysmon log before writing detection logic.

Rules Generate Too Many Alerts

Excessive alerting usually indicates that a rule is too broad.

Consider narrowing the scope by matching:

Parent process
Command-line arguments
User account
File path
Host group
Registry location
Network destination

Adding allowlists for trusted software can also significantly reduce noise without sacrificing detection coverage.

Related Guide: How to Reduce False Positives in Wazuh

Fields Are Missing from Events

If expected fields are unavailable:

Verify the decoder supports the event format.
Confirm Sysmon is generating the required data.
Check the Sysmon configuration file.
Inspect the raw event.
Test the decoder independently.

Missing fields often indicate decoding issues rather than problems with the rule itself.

Related Guide: Wazuh Decoder Guide

XML Syntax Errors

Malformed XML prevents rules from loading.

Common mistakes include:

Missing closing tags
Invalid nesting
Incorrect quotation marks
Duplicate attributes
Invalid regular expression syntax
Improper escaping of special characters

Validate XML after every modification and make incremental changes so syntax errors are easier to locate.

Parent-Child Rules Not Matching

If child rules never trigger:

Confirm the parent rule matches first.
Verify the child references the correct parent Rule ID.
Ensure inherited fields remain available.
Check rule evaluation order.
Test both rules independently with wazuh-logtest.

Building parent-child hierarchies incrementally is generally easier than creating complex relationships all at once.

Rules Stop Working After a Wazuh Upgrade

After upgrading Wazuh, review your custom rule set to ensure it remains compatible with the updated platform.

Verify that:

Custom rule files are still present.
Rule IDs do not conflict with newly added built-in rules.
Decoders still expose the expected fields.
XML syntax remains valid.
Deprecated rule options have not been removed.
Custom detections still pass wazuh-logtest.

As part of your upgrade process, maintain backups of custom rules and decoders, compare them against the new default ruleset, and perform regression testing using representative Sysmon events before returning the system to production.

Related Guide: How to Upgrade a Wazuh Agent

Real-World Example

Scenario

A security team manages a large enterprise environment containing hundreds of Windows workstations and servers across multiple business units.

To improve endpoint visibility, the organization deploys Microsoft Sysmon on all Windows systems and forwards the collected telemetry to Wazuh for centralized monitoring, detection, and incident response.

Initially, the team relies on default Wazuh Windows detection rules.

However, after investigating several fileless malware incidents, analysts discover that attackers are increasingly abusing legitimate Windows tools such as PowerShell, WMI, and signed binaries to avoid traditional endpoint protections.

The security team decides to extend the Wazuh ruleset by creating custom Wazuh Sysmon Rules focused on identifying advanced attacker behavior.

Detecting Fileless Malware Activity

The first improvement focuses on detecting malicious PowerShell usage.

The team creates custom rules to identify:

Base64-encoded PowerShell commands
PowerShell launched from Office applications
Hidden PowerShell execution
Remote script downloads
Suspicious PowerShell parent-child relationships

For example, instead of generating an alert for every PowerShell execution, the rule only triggers when PowerShell is launched with suspicious characteristics, such as:

An unusual parent process
Obfuscated commands
External network communication
Execution from temporary directories

This reduces unnecessary alerts while improving detection accuracy.

Identifying Suspicious Process Creation Chains

The team then analyzes Sysmon Event ID 1 data to detect abnormal process relationships.

They create detections for attack patterns such as:

winword.exe
     |
     └── powershell.exe
             |
             └── rundll32.exe
                     |
                     └── malware.exe

Although each executable may be legitimate individually, the sequence represents a highly suspicious attack chain.

Using Wazuh parent-child rules, the security team creates layered detections that identify these multi-stage behaviors rather than isolated events.

Detecting Malicious DLL Loading

The organization also creates custom rules around Sysmon Event ID 7 to identify suspicious DLL activity.

The detections monitor:

DLLs loaded from user directories
Unsigned libraries
DLL side-loading attempts
Unexpected modules loaded by trusted applications

For example, if a normally trusted application suddenly loads a DLL from a temporary folder, Wazuh generates an alert for investigation.

This helps identify malware techniques that bypass traditional executable-based detection.

Monitoring Credential Dumping Attempts

Because attackers frequently attempt to steal credentials after gaining access, the team creates rules targeting Sysmon Event ID 10.

The rules monitor:

Unauthorized access to LSASS memory
Suspicious processes reading credential-related memory
Known credential theft behaviors
Unexpected privilege escalation attempts

Instead of relying on malware signatures, these detections focus on attacker behavior.

Detecting Abnormal Network Connections

The security team also creates custom detections using Sysmon Event ID 3.

The rules identify:

Unknown processes making outbound connections
Connections to suspicious external IP addresses
Unusual communication patterns
Command-and-control behavior

For example, a document reader launching PowerShell and immediately connecting to an external server would generate a high-confidence alert because multiple suspicious indicators are present.

Testing and Validating Custom Rules

Before deploying the new rules broadly, the team tests every detection using wazuh-logtest.

The validation process includes:

Collecting representative Sysmon events.
Testing events against Wazuh decoders.
Confirming rule matches.
Reviewing alert severity.
Checking MITRE ATT&CK mappings.
Adjusting conditions to remove false positives.

The team also performs controlled attack simulations to confirm that the rules detect real-world techniques without generating excessive noise.

Related Guide: How to Use Wazuh Logtest

Reducing False Positives Through Tuning

After initial deployment, analysts review generated alerts and identify legitimate administrative activity causing unnecessary detections.

The team creates exclusions for:

Approved management tools
Security software
Automation platforms
Known administrative scripts

They also refine rules by adding additional conditions, such as:

Specific users
Approved hosts
Trusted file paths
Digital signatures
Known command-line patterns

This tuning process significantly reduces alert fatigue while maintaining strong detection coverage.

Related Guide: How to Reduce False Positives in Wazuh

Mapping Detections to MITRE ATT&CK

Each custom detection is mapped to the appropriate MITRE ATT&CK technique.

Examples include:

Detection	MITRE ATT&CK Technique
Encoded PowerShell	T1059.001
Credential dumping	T1003
Process injection	T1055
Scheduled task persistence	T1053
DLL side-loading	T1574

These mappings help the security team measure defensive coverage and communicate detection capabilities to leadership.

Improved Security Outcomes

After deploying the custom Sysmon rules across the environment, the security team achieves several improvements:

Faster detection of fileless malware
Improved visibility into attacker behavior
Reduced alert fatigue
More accurate severity prioritization
Faster incident investigations
Better MITRE ATT&CK coverage
Stronger Windows endpoint monitoring

The organization also gains a repeatable detection engineering process where new rules can be created, tested, documented, and deployed as threats evolve.

Custom Wazuh Sysmon rules become an important layer in the organization’s broader security strategy, complementing vulnerability management, threat intelligence, endpoint monitoring, and automated response capabilities.

Frequently Asked Questions (FAQ)

Question: What are Wazuh Sysmon rules?

Wazuh Sysmon rules are detection rules that analyze events generated by Microsoft Sysmon and determine whether specific Windows activities should create security alerts.

They allow security teams to detect behaviors such as:

Suspicious PowerShell execution
Credential dumping
Process injection
Malware execution
Persistence techniques
Abnormal network activity

Wazuh processes Sysmon events through decoders and rules before generating alerts in the Wazuh Dashboard.

Question: Does Wazuh include built-in Sysmon rules?

Yes. Wazuh includes built-in rules and decoders for many Windows and Sysmon events.

However, built-in rules provide general detection coverage.

Organizations typically create custom Sysmon rules to address:

Internal applications
Unique infrastructure
Industry-specific threats
Custom attack scenarios
Organization-specific false positives

Custom rules extend Wazuh’s capabilities beyond the default ruleset.

Question: Where are custom Sysmon rules stored?

Custom Wazuh rules are typically stored in:

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

Organizations with larger deployments often create separate custom rule files inside the Wazuh rules directory and include them through the Wazuh configuration.

Custom rules should always remain separate from default Wazuh rules to prevent changes from being overwritten during upgrades.

Question: Which Sysmon Event IDs are most useful?

The most commonly used Sysmon Event IDs for security detection include:

Event ID	Purpose
1	Process Creation
3	Network Connections
7	Image Loaded
8	CreateRemoteThread
10	Process Access
11	File Creation
12–14	Registry Changes
15	Alternate Data Streams
22	DNS Queries
23–26	File Deletion

The most valuable events depend on your organization’s threat model and monitoring objectives.

Question: How do I test a custom Sysmon rule?

The recommended method is using wazuh-logtest.

Testing involves:

Copying a Sysmon event.
Submitting it to wazuh-logtest.
Reviewing decoded fields.
Confirming the expected rule matches.
Adjusting conditions if necessary.

Testing before deployment helps prevent false positives and missing detections.

Related Guide: How to Use Wazuh Logtest

Question: Can I map Sysmon rules to MITRE ATT&CK?

Yes. Wazuh rules can include MITRE ATT&CK metadata.

Mapping detections helps security teams:

Understand attacker techniques
Measure detection coverage
Improve threat hunting
Create security reports

MITRE mappings are especially valuable when building mature detection engineering programs.

Question: How do I reduce false positives?

Reduce false positives by:

Creating allowlists
Excluding trusted applications
Filtering known administrative activity
Adding more specific matching conditions
Adjusting severity levels
Correlating multiple events
Reviewing alerts regularly

The goal is not to detect every event but to identify meaningful security behaviors.

Related Guide: How to Reduce False Positives in Wazuh

Question: Will custom rules survive Wazuh upgrades?

Yes, custom rules stored separately from default rules are designed to survive upgrades.

However, you should always test custom detections after upgrading because:

Decoder behavior may change
Built-in rules may be updated
Field names may change
New rules may introduce conflicts

Maintaining backups and version control for custom rules is strongly recommended.

Question: Can Sysmon rules detect ransomware?

Yes, Sysmon-based Wazuh rules can help identify ransomware-related behavior.

Useful indicators include:

Rapid file creation
File deletion activity
Suspicious process execution
Shadow copy deletion
Registry modifications
Unusual network behavior

However, ransomware detection is most effective when multiple indicators are correlated rather than relying on a single event.

Question: What is the difference between Sysmon configuration and Wazuh rules?

Sysmon configuration determines what telemetry is collected.

Examples:

Process creation
Network connections
Registry changes
DLL loading

Wazuh rules determine what collected events should generate alerts.

The relationship can be summarized as:

Sysmon Configuration
        |
        ▼
Collect Security Events
        |
        ▼
Wazuh Decoders
        |
        ▼
Wazuh Detection Rules
        |
        ▼
Security Alerts

A strong security monitoring strategy requires both a well-designed Sysmon configuration and carefully tuned Wazuh detection rules.

Conclusion

Custom Wazuh Sysmon Rules provide organizations with deeper visibility into Windows endpoint activity and allow security teams to detect advanced attacker techniques that may bypass traditional monitoring solutions.

By combining Sysmon’s detailed telemetry with Wazuh’s flexible detection engine, organizations can identify suspicious behaviors such as:

Fileless malware execution
Credential theft attempts
Process injection
Persistence mechanisms
Abnormal network activity
Ransomware indicators

Creating effective detections requires a structured process:

Install and configure Sysmon.
Forward Sysmon events to Wazuh.
Identify useful event fields.
Create custom XML rules.
Test rules with wazuh-logtest.
Tune detections to reduce false positives.
Map rules to MITRE ATT&CK.
Continuously maintain and improve the ruleset.

Threat actors constantly adapt their techniques, meaning detection rules must evolve as well.

\Regular testing, documentation, and refinement ensure that custom Sysmon rules remain accurate and effective.

For organizations using Wazuh as their security monitoring platform, custom Sysmon detections should be part of a broader security strategy that includes vulnerability management, threat intelligence, endpoint monitoring, compliance reporting, and automated response.

A well-maintained Wazuh Sysmon ruleset transforms raw Windows telemetry into actionable security intelligence and provides stronger protection against modern endpoint threats.

Step-by-Step: Custom Wazuh Sysmon Rules Guide

What Are Wazuh Sysmon Rules?

How Sysmon Improves Windows Security Monitoring

How Wazuh Processes Sysmon Events

Why Custom Sysmon Rules Are Important

Benefits of Extending the Default Wazuh Ruleset

How Wazuh Integrates with Sysmon

Installing and Configuring Sysmon

Forwarding Sysmon Logs to Wazuh

Event Flow from Windows Endpoint to Wazuh Manager

Relationship Between Decoders and Rules

Understanding Sysmon Event IDs

Prerequisites

Supported Wazuh Versions

Supported Windows Versions

Installing Sysmon with an Appropriate Configuration

Configuring Windows Event Channel Collection

Verifying Sysmon Events Are Reaching Wazuh

Be First to Comment

Leave a Reply Cancel reply