How to Test Wazuh Rules

Wazuh rules are the core detection mechanism within Wazuh.

They analyze events collected from endpoints, network devices, applications, cloud platforms, and security tools to determine whether an activity should generate an alert.

Every alert displayed in the Wazuh dashboard is the result of one or more rules matching specific conditions within incoming log data. Rules play a critical role in security monitoring because they transform raw log data into actionable security insights.

Without rules, Wazuh would simply collect and store logs without identifying suspicious behavior, compliance violations, configuration changes, authentication failures, malware indicators, or other security events that require investigation.

Testing Wazuh rules before deploying them into a production environment is essential. Even a well-written rule can fail to trigger if the associated decoder does not properly parse the log data.

Conversely, a rule that is too broad may generate excessive alerts, overwhelming security teams with false positives.

The MITRE ATT&CK framework encourages organizations to continuously test and evaluate detection capabilities against real-world attack techniques to ensure monitoring systems remain effective against evolving threats.

In this guide, you will learn how Wazuh rules work, how they interact with decoders, what prerequisites should be in place before testing, and how to validate both built-in and custom rules using Wazuh’s testing tools.

By the end of this article, you will have a repeatable process for verifying rule accuracy and improving the quality of your Wazuh detections.

Understanding Wazuh Rules

What Are Wazuh Rules?

Wazuh rules are XML-based detection definitions that evaluate decoded log events and determine whether an alert should be generated.

Rules contain matching conditions that inspect specific fields, keywords, event characteristics, or correlations between multiple events.

When a log enters the Wazuh analysis engine, it is first processed by a decoder.

The decoder extracts structured data from the raw log and makes those fields available to the rule engine.

The rule engine then evaluates all applicable rules and generates alerts when conditions are met.

Rules can perform simple matching operations, such as identifying failed login attempts, or more advanced detection logic that correlates multiple events across time.

This flexibility allows Wazuh to detect everything from basic operational issues to sophisticated attack patterns.

Purpose of Rules in Wazuh

The primary purpose of Wazuh rules is to convert raw telemetry into meaningful security alerts. They help security teams:

• Detect suspicious activity
• Identify policy violations
• Monitor system changes
• Track authentication events
• Generate compliance alerts
• Correlate multiple security events
• Prioritize incidents based on severity

Without rules, organizations would need to manually review large volumes of logs, making effective security monitoring nearly impossible.

Relationship Between Decoders and Rules

Decoders and rules work together within the Wazuh analysis pipeline.

The process typically follows this sequence:

1. A log is collected from an endpoint or device.
2. A decoder parses the raw log.
3. Fields are extracted from the event.
4. Rules evaluate the decoded data.
5. An alert is generated if conditions match.

This relationship is important because a rule can only evaluate information that has been successfully extracted by a decoder.

If the decoder fails to parse a log correctly, the rule may never trigger even if the detection logic itself is accurate.

For this reason, decoder validation should always be part of any rule testing process.

How Rules Generate Alerts

Each Wazuh rule contains conditions that determine when an alert should be created.

These conditions can evaluate:

• Keywords
• Extracted fields
• Event IDs
• Source IP addresses
• Usernames
• File paths
• Previous rule matches
• Time-based correlations

When a rule matches, Wazuh assigns an alert level that indicates severity. Higher levels generally represent events requiring greater attention from security analysts.

The resulting alert includes information such as:

• Rule ID
• Severity level
• Description
• Event details
• Groups
• Compliance mappings

These alerts become visible within the Wazuh dashboard and can trigger automated response workflows.

Types of Wazuh Rules

Wazuh supports several different rule categories, each serving a specific purpose within the detection framework.

Built-in Rules

Built-in rules are included with the Wazuh ruleset and cover common security scenarios.

These rules detect events such as:

• Authentication failures
• Privilege escalation attempts
• Malware activity
• Web attacks
• System modifications
• Network threats

Because they are maintained by the Wazuh community, built-in rules are often the starting point for most deployments.

Custom Rules

Custom rules are created by administrators to detect organization-specific events and use cases.

Examples include:

• Proprietary application logs
• Internal security policies
• Custom compliance requirements
• Environment-specific threat indicators

Custom rules are commonly stored in the local_rules.xml file to prevent them from being overwritten during upgrades.

Correlation Rules

Correlation rules identify patterns that involve multiple events rather than a single log entry.

For example, a correlation rule might detect:

• Multiple failed logins followed by a successful login
• Repeated privilege escalation attempts
• Sequential attack stages occurring within a short time period

These rules help uncover more sophisticated threats that may not be visible through individual alerts alone.

Compliance and Audit Rules

Compliance-focused rules map security events to regulatory frameworks and auditing requirements.

Common mappings include:

• PCI DSS
• HIPAA
• NIST
• GDPR
• CIS Controls

These rules help organizations demonstrate compliance while continuously monitoring for policy violations.

Prerequisites for Testing Wazuh Rules

Before testing any Wazuh rule, verify that the environment is functioning correctly.

Problems with agents, log collection, or manager services can lead to misleading test results and unnecessary troubleshooting.

Verify Wazuh Installation

Begin by confirming that all major Wazuh components are operational.

Confirm Manager Status

On the Wazuh manager, verify that the service is running:

sudo systemctl status wazuh-manager

A healthy manager should show an active running state.

If the manager is not operational, rule testing cannot proceed because the analysis engine will not process incoming events.

Check Agent Connectivity

Verify that agents are successfully connected to the manager.

Use:

sudo /var/ossec/bin/agent_control -l

Connected agents should display an active status and recent communication timestamps.

Disconnected agents may prevent logs from reaching the rule engine.

See our Wazuh Agent Not Connecting to Manager? 12 Proven Fixes guide.

Ensure Log Collection Is Working

Before testing rules, confirm that logs are actually reaching Wazuh.

Review:

/var/ossec/logs/archives/archives.log

or search for recent events in the dashboard.

If logs are not being collected, rule testing results will be unreliable because no data is available for evaluation.

Locate Rule Files

Understanding where Wazuh stores rules is important when creating or testing custom detections.

Default Rule Locations

Built-in rules are typically located under:

/var/ossec/ruleset/rules/

These files contain thousands of preconfigured detection rules maintained by the Wazuh project.

Custom Rule Files

Organizations often place custom rules within:

/var/ossec/etc/rules/

This location keeps custom content separate from vendor-maintained rules.

Local Rules Configuration

The most common custom rule file is:

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

Administrators typically add custom detections here because the file is preserved during upgrades.

Understand the Test Environment

Testing should be performed in a controlled environment whenever possible.

Production vs Testing Environments

A dedicated testing environment provides several advantages:

• Eliminates risk to production monitoring
• Prevents accidental alert floods
• Allows safe experimentation
• Simplifies troubleshooting

Production testing should be limited to carefully controlled scenarios.

Using Sample Logs Safely

Many administrators test rules using historical or simulated log samples.

Benefits include:

• Repeatable testing
• Faster troubleshooting
• Reduced operational risk
• Easier validation of expected outcomes

Maintaining a library of representative logs can significantly improve future rule development efforts.

Backing Up Custom Rule Configurations

Before modifying rules, create backups of all custom files.

For example:

cp local_rules.xml local_rules.xml.backup

This precaution allows you to quickly restore working configurations if testing introduces unexpected issues.

According to guidance from the official Wazuh documentation, maintaining separate backups of custom rules and decoders is considered a best practice because upgrades and configuration changes can impact detection behavior over time.

Methods for Testing Wazuh Rules

Testing Wazuh rules is a critical part of detection engineering.

A rule that looks correct on paper may fail in practice due to decoder issues, incorrect field matching, syntax errors, or overly restrictive conditions.

By testing rules before deployment, security teams can verify detection accuracy, reduce false positives, and ensure alerts are generated when expected.

There are several methods available for validating Wazuh rules, each serving a different purpose during the development and deployment process.

Using Wazuh Logtest

The Wazuh Logtest utility is the primary tool for testing rules. It allows administrators to submit log samples directly to the Wazuh analysis engine and view exactly how logs are processed.

Unlike testing through live event generation, Logtest evaluates logs without creating production alerts or affecting monitoring dashboards.

Benefits of using Logtest include:

• Immediate feedback on rule matching
• Safe testing in production environments
• Validation of decoder functionality
• Faster troubleshooting
• No alert noise generated

Because Logtest uses the same analysis engine as the Wazuh manager, it accurately reflects how events will be processed once deployed.

Common use cases include:

• Testing custom rules
• Verifying decoder functionality
• Troubleshooting rule matching issues
• Evaluating alert severity levels
• Validating rule updates before deployment

The official Wazuh documentation recommends using Logtest as the first step when developing or modifying custom detection content.

Testing Through Real Log Ingestion

While Logtest is useful for validation, testing through actual log ingestion helps confirm that the entire data pipeline is functioning correctly.

This approach involves generating events on monitored systems and allowing Wazuh agents to collect and forward logs naturally.

Examples include:

• Failed SSH login attempts
• Windows authentication failures
• Firewall deny events
• Application errors
• File modifications

After generating events, administrators can verify:

• Log collection
• Decoder execution
• Rule matching
• Alert generation
• Dashboard visibility

Testing through real ingestion helps identify issues that may not appear during isolated Logtest sessions.

Sending Logs to Agents

To perform live testing, generate sample events on monitored endpoints.

Examples:

Linux:

ssh invaliduser@localhost

Windows:

Attempt multiple failed logins

Firewall:

Generate blocked connection events

These actions create logs that agents forward to the Wazuh manager for analysis.

Verifying Rule Execution

Once logs have been collected, verify that alerts appear in the dashboard or alert files.

Check:

tail -f /var/ossec/logs/alerts/alerts.json

Look for:

• Rule ID
• Description
• Severity level
• Source information
• Event details

Successful alert generation confirms that the complete monitoring pipeline is working as expected.

Comparing Results with Logtest

A useful validation technique is comparing Logtest output against alerts generated from live ingestion.

The following should match:

• Decoder names
• Rule IDs
• Alert descriptions
• Severity levels

Differences may indicate variations in log formatting or environmental factors affecting event collection.

Testing Custom Rule Development

Custom rules should undergo repeated testing throughout development rather than only after completion.

An iterative approach helps identify problems early and reduces troubleshooting time.

Iterative Testing Workflow

A recommended workflow includes:

1. Create the rule.
2. Test with Logtest.
3. Refine matching conditions.
4. Test again.
5. Deploy to a non-production environment.
6. Generate real events.
7. Validate alerts.
8. Promote to production.

This process helps ensure reliable detections while minimizing operational risk.

Validating Rule Logic Before Deployment

Rule testing should verify both positive and negative scenarios.

Positive testing confirms:

• The intended event triggers the rule.

Negative testing confirms:

• Similar but unrelated events do not trigger the rule.

This approach reduces false positives and improves alert quality.

Confirming Alert Severity Levels

Every rule should be reviewed to ensure the assigned alert level accurately reflects the risk being detected.

Questions to consider include:

• Is the event informational or critical?
• Does the severity align with incident response procedures?
• Will analysts prioritize the alert appropriately?

Proper severity tuning helps security teams focus on meaningful threats rather than low-value events.

How to Test Rules with Wazuh Logtest

Wazuh Logtest provides a safe and efficient method for validating detection rules.

It allows administrators to submit log samples directly to the analysis engine and observe how decoders and rules process the event.

Launch the Logtest Tool

Begin by accessing the Wazuh manager.

Run:

sudo /var/ossec/bin/wazuh-logtest

The interface will display a prompt waiting for log input.

Example:

Starting wazuh-logtest
Type one log per line

Accessing Logtest from the Command Line

Logtest is available on the Wazuh manager server and does not require dashboard access.

Most administrators launch it through:

• SSH sessions
• Local terminal access
• Administrative consoles

This makes it useful even when dashboard connectivity is unavailable.

Understanding the Testing Interface

Each submitted log passes through three processing stages:

1. Pre-decoding
2. Decoding
3. Rule evaluation

The results display detailed information about each phase, making troubleshooting significantly easier.

Submit a Sample Log

After launching Logtest, paste a sample log entry into the prompt.

For best results, use actual logs collected from your environment whenever possible.

Using Real-World Log Samples

Real logs help ensure rules are tested against actual production formats.

Good sources include:

• Archived security logs
• Syslog files
• Windows Event logs
• Firewall logs
• Application logs

Using realistic samples helps avoid surprises after deployment.

Testing Syslog Entries

Example:

Jun 15 12:30:00 server sshd[1234]: Failed password for invalid user admin from 10.10.10.5

Paste the log directly into Logtest for evaluation.

Testing Windows Event Logs

Example:

EventID=4625 An account failed to log on

This helps verify Windows authentication detection rules.

INTERNAL LINK: How to Install a Wazuh Agent on Windows Server

Testing Application Logs

Example:

ERROR Unauthorized access attempt detected

Custom applications often require additional decoder validation before rules can function properly.

Analyze Decoder Results

After submitting a log, review decoder information carefully.

Decoder failures are one of the most common reasons rules do not trigger.

Confirming Correct Decoder Matching

A successful result may show:

decoder: 'sshd'

This indicates the event was parsed successfully.

Understanding Phase 1 and Phase 2 Outputs

Phase 1 performs pre-decoding tasks such as timestamp extraction.

Phase 2 identifies the decoder and extracts structured fields from the event.

Example:

Phase 1: Completed pre-decoding
Phase 2: Completed decoding
decoder: sshd

Successful completion of these phases is required before rule matching can occur.

Troubleshooting Decoder Failures

Common causes include:

• Incorrect log format
• Missing decoder definitions
• Faulty regular expressions
• Case-sensitive mismatches
• Unexpected spacing

If no decoder is identified, focus on decoder troubleshooting before modifying rules.

Analyze Rule Matching Results

Once decoding succeeds, Wazuh evaluates the event against available rules.

Understanding Phase 3 Output

Phase 3 displays rule evaluation results.

Example:

Rule id: 5710
Level: 5
Description: sshd authentication failed

Reviewing Matched Rule IDs

Rule IDs help identify exactly which detection generated the alert.

Administrators should verify that:

• The expected rule matched.
• No unintended rules triggered.
• Rule hierarchy behaved correctly.

Validating Alert Levels and Descriptions

Review:

• Alert severity
• Rule description
• Classification groups
• Compliance mappings

The alert should accurately describe the detected event.

Example: Testing a Failed SSH Login Rule

One of the most common examples involves testing failed SSH authentication detection.

Sample SSH Authentication Log

Failed password for invalid user admin from 192.168.1.50 port 22 ssh2

Decoder Analysis

Expected decoder:

decoder: sshd

Rule Matching Results

Expected rule:

Rule id: 5710

Expected Alert Output

Example:

Level: 5
Description: sshd: authentication failed

Successful output confirms both decoder and rule functionality.

Testing Custom Wazuh Rules

Custom rules should be tested extensively before deployment because they often contain organization-specific detection logic.

Create a Custom Rule

Most custom rules are stored in:

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

Example:

<group name="custom_security">
  <rule id="100500" level="8">
    <match>unauthorized_access</match>
    <description>Unauthorized access detected</description>
  </rule>
</group>

Restart the manager after saving changes.

Rule ID Selection Best Practices

When creating custom rules:

• Use IDs above 100000.
• Avoid conflicts with built-in rules.
• Follow a consistent numbering scheme.
• Reserve ID ranges for specific rule categories.

A structured approach simplifies long-term maintenance.

Rule Grouping Recommendations

Groups improve organization and reporting.

Examples:

<group name="custom_security">

<group name="custom_compliance">

<group name="custom_firewall">

Grouping also helps when creating correlation rules.

Test the Rule Against Sample Logs

After creating a rule, validate it using representative logs.

Matching Expected Events

Input:

unauthorized_access

Expected result:

Rule id: 100500

Verifying Rule Descriptions

Confirm the alert description accurately explains the event.

Example:

Unauthorized access detected

Clear descriptions improve analyst efficiency during investigations.

Confirming Alert Severity

Review whether the configured level appropriately reflects risk.

For example:

• Level 3–5: Informational
• Level 6–9: Medium severity
• Level 10+: High priority

Severity should align with incident response procedures.

Validate Rule Dependencies

Many custom detections rely on relationships between rules.

Parent-Child Rule Relationships

Example:

<rule id="100510" level="3">
  <match>failed login</match>
</rule>

<rule id="100511" level="10">
  <if_sid>100510</if_sid>
  <match>admin</match>
</rule>

Testing should verify both rules behave as intended.

Chained Rule Testing

When multiple rules depend on each other:

• Test each rule independently.
• Test the entire chain.
• Verify escalation logic.
• Confirm alert inheritance behavior.

Frequency-Based Detection Testing

Rules using:

<frequency>

or

<timeframe>

require repeated event generation.

Testing should confirm:

• Thresholds trigger correctly.
• Time windows function properly.
• Alerts do not trigger prematurely.

Example Custom Rule Walkthrough

Sample Custom Rule

<rule id="100520" level="10">
  <match>suspicious_process</match>
  <description>Suspicious process execution detected</description>
</rule>

Sample Log Event

suspicious_process powershell.exe

Test Execution

Submit the log using Logtest.

Expected result:

Rule id: 100520

Result Interpretation

A successful test should confirm:

• The decoder matched.
• The rule triggered.
• The correct severity was assigned.
• The alert description appeared correctly.

Once these validations are complete, the rule is ready for testing through live log ingestion and eventual production deployment.

Testing Decoders Before Rules

Before testing any Wazuh rule, you should first verify that the associated decoder is functioning correctly.

A rule can only evaluate data that has been successfully extracted from a log event. If the decoder fails to parse the log, even a perfectly written rule will never trigger.

Many rule-testing issues ultimately trace back to decoder problems rather than flaws in the rule itself.

For this reason, experienced detection engineers typically validate decoders before spending time troubleshooting rule logic.

Why Decoder Validation Matters

Wazuh processes logs through a multi-stage pipeline. Decoders serve as the bridge between raw log data and the rule engine.

The process typically follows this sequence:

1. Log collection
2. Pre-decoding
3. Decoder processing
4. Field extraction
5. Rule evaluation
6. Alert generation

If field extraction fails during the decoding phase, rules may not have access to critical information such as usernames, source IP addresses, process names, or event identifiers.

According to the official Wazuh documentation, decoders are responsible for transforming unstructured logs into structured data that rules can evaluate effectively.

Wazuh Decoder Documentation: https://documentation.wazuh.com/current/user-manual/ruleset/decoders/index.html

Decoder Functionality in the Detection Pipeline

Decoders analyze incoming logs and identify patterns using regular expressions, prematch conditions, and parsing logic.

For example, a Linux SSH log may be converted into structured fields such as:

srcip: 192.168.1.50
user: admin
program_name: sshd

Once these fields exist, rules can evaluate them to determine whether suspicious activity has occurred.

Without successful decoding, rule conditions that rely on these fields will fail.

Common Parsing Issues

Common decoder-related problems include:

• Incorrect regular expressions
• Unexpected log formats
• Missing fields
• Truncated logs
• Case sensitivity issues
• Improper field ordering
• Vendor log format changes

These issues often appear after application upgrades, operating system updates, or firewall firmware changes.

Verify Field Extraction

When testing decoders, verify that all required fields are being extracted correctly.

The easiest way to validate extraction is through Logtest output.

Source IP Extraction

Many security detections rely on source IP addresses.

Example:

Failed password for invalid user admin from 10.10.10.25 port 22 ssh2

Expected extraction:

srcip: 10.10.10.25

If the source IP is not extracted, brute-force detection and correlation rules may fail.

Username Extraction

Authentication monitoring depends heavily on username extraction.

Example:

user: admin

Verify that:

• Correct usernames are extracted
• Service accounts are identified properly
• Failed login attempts retain username information

Process Name Extraction

Endpoint detection rules frequently rely on process names.

Example:

process_name: powershell.exe

Verify that:

• Process names are extracted consistently
• Variations in capitalization are handled properly
• Command-line arguments do not interfere with parsing

This is particularly important for malware detection and endpoint monitoring.

See our How to Detect Ransomware Activity Using Wazuh guide for more information

Event ID Extraction

Windows monitoring often depends on Event IDs.

Examples include:

• 4624 (Successful login)
• 4625 (Failed login)
• 4688 (Process creation)
• 4720 (User creation)

Expected extraction:

event_id: 4625

Many Windows detection rules will fail if Event IDs are not parsed correctly.

Troubleshoot Decoder Issues

When expected fields are missing, focus on decoder troubleshooting before modifying rule logic.

Regex Mismatches

Regular expression errors are among the most common decoder problems.

For example:

src=(\S+)

may fail if the actual log format changes to:

source_ip=10.0.0.5

Whenever possible, test decoders against multiple log samples to account for format variations.

Incorrect Field Mapping

Sometimes the decoder extracts data successfully but stores it in the wrong field.

Example:

user=admin

might accidentally populate:

srcuser

instead of:

dstuser

Incorrect mappings can prevent rules from evaluating the expected values.

Log Format Variations

Logs generated by different software versions may contain formatting differences.

Examples include:

• Additional fields
• Different field ordering
• New timestamps
• Vendor-specific metadata

Testing with multiple log samples helps ensure decoder resilience across versions and environments.

Testing Correlation and Frequency Rules

While simple rules evaluate individual events, correlation and frequency rules analyze patterns that emerge across multiple events.

These rules are commonly used to detect attacks that unfold over time rather than within a single log entry.

Because they depend on multiple events, testing these rules requires a different approach than standard rule validation.

Understanding Correlation Rules

Correlation rules combine information from multiple events to identify suspicious behavior.

Rather than triggering on a single log, these rules evaluate relationships between events occurring within a specified timeframe.

Examples include:

• Multiple failed logins followed by a successful login
• Repeated malware detections
• Privilege escalation attempts across multiple hosts
• Sequential attack stages

Correlation significantly improves detection coverage because many real-world attacks generate patterns rather than isolated events.

Multi-Event Detection Logic

Correlation rules often use elements such as:

<if_sid>

<frequency>

<timeframe>

These components allow Wazuh to monitor event sequences and trigger alerts when thresholds are exceeded.

Behavioral Analysis Use Cases

Common correlation scenarios include:

• Brute-force login detection
• Password spraying attacks
• Malware outbreaks
• Reconnaissance activity
• Lateral movement attempts
• Privilege escalation patterns

Behavioral detections often provide higher-fidelity alerts than single-event rules.

Test Frequency-Based Rules

Frequency rules trigger when a defined number of matching events occur within a specified timeframe.

Testing requires generating multiple qualifying events.

Multiple Failed Logins

A common example is failed authentication monitoring.

Rule example:

<frequency>5</frequency>
<timeframe>60</timeframe>

This rule triggers after five failed logins within sixty seconds.

Testing should confirm that:

• Four failures do not trigger the alert.
• Five failures trigger the alert.
• The alert resets appropriately.

Brute Force Detection Scenarios

Generate repeated failed login attempts.

Example:

ssh invaliduser@server

Repeat the command until the frequency threshold is exceeded.

Expected outcome:

• Initial authentication failure alerts
• Subsequent brute-force detection alert

This validates both base rules and correlation logic.

Repeated Malware Alerts

Malware monitoring often uses frequency thresholds to identify widespread infections.

Testing may involve generating multiple malware-related events and confirming escalation occurs after the threshold is reached.

Simulate Event Sequences

Complex correlation rules frequently require carefully controlled testing scenarios.

Generating Multiple Test Events

Methods include:

• Repeating authentication failures
• Executing scripted commands
• Sending test syslog messages
• Replaying archived logs

Automated scripts are often useful when testing high-frequency thresholds.

Verifying Threshold Conditions

Ensure alerts trigger exactly when expected.

For example:

Threshold testing helps identify off-by-one errors and configuration mistakes.

Confirming Timeframe Settings

Timeframe validation is equally important.

Example:

<frequency>5</frequency>
<timeframe>120</timeframe>

Verify that:

• Events inside the timeframe trigger alerts.
• Events outside the timeframe do not.
• Expired events are removed correctly.

Improper timeframe settings are a common source of false positives.

Validating Rule Performance

A rule that triggers successfully is not necessarily a good rule.

Effective detection engineering requires ongoing validation to ensure alerts are accurate, meaningful, and aligned with organizational objectives.

Rule performance should be evaluated regularly after deployment.

Check for False Positives

False positives occur when legitimate activity generates alerts.

Excessive false positives can overwhelm analysts and reduce trust in the monitoring system.

Reviewing Alert Accuracy

Review generated alerts and determine whether they represent genuine security concerns.

Questions to ask include:

• Is the activity actually suspicious?
• Would an analyst need to investigate this event?
• Does the alert provide useful context?

Rules should prioritize actionable detections rather than generating noise.

Identifying Overly Broad Matching Conditions

Many false positives result from overly permissive rule logic.

Examples include:

• Generic keyword matching
• Broad regular expressions
• Missing exclusions
• Excessive wildcard usage

Consider refining:

• Field matching conditions
• Source restrictions
• Event categories
• Correlation requirements

see our How to Reduce False Positives in Wazuh guide.

Check for False Negatives

False negatives occur when malicious activity fails to generate an alert.

These are often more dangerous than false positives because attacks remain undetected.

Ensuring Malicious Activity Is Detected

Validate rules against known attack techniques.

Examples include:

• Failed login attacks
• Privilege escalation attempts
• Malware execution
• File integrity violations
• Unauthorized configuration changes

Security teams should periodically simulate attack scenarios to confirm detections remain effective.

The MITRE ATT&CK framework recommends continuous validation of detection coverage against adversary techniques to identify monitoring gaps before they can be exploited.

Expanding Rule Coverage Where Necessary

If testing reveals detection gaps, consider:

• Adding supplemental rules
• Expanding field matching
• Improving decoder coverage
• Introducing correlation logic
• Monitoring additional log sources

Detection content should evolve alongside the threat landscape.

Tune Rule Severity Levels

Severity levels help analysts prioritize alerts and allocate response resources efficiently.

Poor severity assignments can either overwhelm teams with low-priority alerts or cause critical events to be overlooked.

Adjusting Alert Levels

Review whether severity levels accurately reflect risk.

Examples:

Severity tuning should be reviewed regularly as environments evolve.

Aligning Severity with Organizational Requirements

Every organization has different risk tolerances and response procedures.

When assigning severity levels, consider:

• Regulatory requirements
• Business impact
• Asset criticality
• Threat likelihood
• Incident response workflows

Well-tuned severity levels help ensure security teams focus their attention on the events that matter most.

Common Rule Testing Scenarios

While every organization has unique detection requirements, certain categories of Wazuh rules are commonly tested across most environments.

These scenarios help validate that security monitoring functions correctly and that alerts are generated when important events occur.

Testing these common use cases provides confidence that your detection pipeline is operating as expected and helps uncover configuration issues before they impact production monitoring.

Authentication Monitoring Rules

Authentication monitoring is one of the most important security use cases in Wazuh.

Attackers frequently target login systems to gain initial access, making authentication-related detections a high priority.

Failed Login Attempts

Failed authentication events are often the first indicator of unauthorized access attempts.

Common test scenarios include:

• Invalid username attempts
• Incorrect password attempts
• Repeated login failures
• Service account authentication failures

Linux example:

ssh invaliduser@server

Windows example:

Generate Event ID 4625

Verify that:

• The appropriate decoder matches
• The correct rule triggers
• Alert severity aligns with organizational requirements

Successful Login Detection

Successful login monitoring helps organizations track user access and identify unusual authentication behavior.

Testing should verify:

• Interactive logins
• Remote logins
• Administrative logins
• Service account access

Examples of validation objectives include:

• Detecting privileged account usage
• Confirming audit logging
• Monitoring access to critical systems

Privilege Escalation Events

Privilege escalation is a common attack technique used after initial access.

Test scenarios may include:

• Use of sudo on Linux
• Administrative privilege assignment
• User role modifications
• Account permission changes

Organizations should verify that escalation events generate higher-severity alerts than standard authentication activity.

Additional Resources:

How to Monitor Kubernetes Using Wazuh

Network Security Rules

Network-related rules help identify suspicious traffic patterns, malicious connections, and potential attack activity.

Firewall Events

Firewall logs are among the most frequently monitored data sources in Wazuh.

Testing should include:

• Allowed connections
• Denied connections
• Blocked outbound traffic
• Policy violations

Verify that:

• Logs are collected successfully
• Decoders extract network fields properly
• Rules trigger expected alerts

see our How to Collect Firewall Logs in Wazuh guide

Port Scanning Detection

Port scanning often precedes exploitation attempts and reconnaissance activity.

Testing may involve tools such as:

nmap target-host

Verify that:

• Scan activity is detected
• Correlation rules trigger appropriately
• Alert severity reflects the threat level

Testing multiple scan types can help validate detection coverage.

IDS and IPS Alerts

Organizations frequently integrate Wazuh with network security tools such as Suricata.

Testing should verify:

• Alert ingestion
• Decoder functionality
• Rule mapping
• Alert enrichment

Example events include:

• Exploit attempts
• Malware traffic
• Command-and-control communications
• Reconnaissance activity

Additional Resources:

How to Integrate Wazuh with Suricata for Better Threat Detection

Malware Detection Rules

Malware detection rules help identify malicious software, suspicious behavior, and indicators of compromise.

Antivirus Alerts

If antivirus software is integrated with Wazuh, test scenarios should include:

• Malware detections
• Quarantined files
• Blocked threats
• Signature-based alerts

Verify that antivirus events generate the expected Wazuh alerts and contain sufficient investigation details.

Suspicious Process Execution

Many attacks involve the execution of suspicious processes.

Common testing examples include:

• PowerShell execution
• Encoded command execution
• Script interpreters
• Unapproved binaries

Examples:

powershell.exe

cmd.exe

Verify that:

• Process names are extracted correctly
• Detection rules trigger consistently
• Alert descriptions provide useful context

File Integrity Monitoring Events

File Integrity Monitoring (FIM) is often used to detect unauthorized modifications.

Testing should include:

• File creation
• File modification
• File deletion
• Permission changes

Verify that:

• Monitored files generate alerts
• Changes are captured accurately
• Alert details contain relevant file information

Related guide:

How to Configure File Integrity Monitoring (FIM) in Wazuh

Ransomware Detection Scenarios

Organizations should also test ransomware-related detections where applicable.

Examples include:

• Rapid file modifications
• Encryption tool execution
• Mass file renaming
• Suspicious process behavior

Related Guide:

How to Detect Ransomware Activity Using Wazuh

Compliance Monitoring Rules

Many organizations use Wazuh to support regulatory compliance and security audits.

Compliance-related rule testing helps ensure that required controls are functioning properly.

CIS Benchmark Events

Wazuh can monitor systems for compliance with CIS security benchmarks.

Testing may include:

• Insecure configurations
• Missing security settings
• Policy violations
• Unauthorized system changes

Verify that compliance findings are generated correctly and mapped to the appropriate controls.

PCI DSS Monitoring

Organizations handling payment card data often rely on PCI DSS monitoring.

Common testing scenarios include:

• Administrative access
• Authentication failures
• Audit log generation
• Security configuration changes

Validate that PCI-related alerts appear correctly and contain sufficient audit information.

Regulatory Audit Events

Many environments must support regulations such as:

• HIPAA
• GDPR
• SOX
• NIST frameworks

Testing should confirm:

• Required events are collected
• Rules trigger consistently
• Audit records remain available for review

According to guidance from the PCI Security Standards Council, organizations should regularly validate monitoring controls to ensure audit and security requirements remain effective as environments change.

Troubleshooting Wazuh Rule Testing Issues

Even well-designed rules may not behave as expected during testing.

Understanding common troubleshooting scenarios can significantly reduce investigation time and help identify the root cause of detection failures.

Rule Does Not Trigger

One of the most common issues is a rule failing to generate an alert when the expected event occurs.

Decoder Not Matching

If the decoder fails, the rule engine may never receive the required fields.

Use Logtest to verify:

decoder: sshd

or another expected decoder.

If no decoder appears, investigate decoder configuration before reviewing rule logic.

Incorrect Rule Conditions

A rule may fail because its conditions are too restrictive.

Examples include:

• Incorrect field names
• Improper regular expressions
• Invalid matching values
• Case-sensitive mismatches

Review the rule carefully and compare conditions against actual decoded output.

Rule Ordering Issues

Wazuh evaluates rules according to their relationships and configuration structure.

In some situations:

• Parent rules may not match
• Child rules may never execute
• Overrides may prevent expected alerts

Validate the complete rule chain rather than testing a single rule in isolation.

Wrong Rule Is Triggered

Sometimes alerts are generated, but the incorrect rule matches the event.

Rule Precedence Conflicts

Multiple rules may evaluate the same event.

When this occurs:

• A more generic rule may trigger first
• A custom rule may never execute
• Alert descriptions may not reflect the intended detection

Review rule hierarchy and inheritance settings carefully.

Overlapping Conditions

Rules with similar matching criteria can create conflicts.

Examples include:

• Shared keywords
• Identical event IDs
• Similar regex patterns

Testing with multiple event variations helps identify overlap issues.

Grouping Problems

Improper group assignments may affect:

• Correlation logic
• Alert categorization
• Reporting accuracy

Verify that groups align with the intended detection strategy.

Logtest Results Differ from Production Alerts

Administrators occasionally encounter situations where Logtest results differ from production alert behavior.

Agent-Side Processing Differences

Live environments introduce variables that are not present during Logtest execution.

Examples include:

• Agent configuration differences
• Log collection delays
• Filtering settings
• Data normalization

Testing through both Logtest and real log ingestion helps identify these issues.

Log Formatting Discrepancies

Production logs may differ from archived samples used during testing.

Examples include:

• Additional fields
• Vendor updates
• Different timestamps
• Alternate formats

Always compare production logs against the samples used during validation.

Timing and Correlation Factors

Correlation rules frequently behave differently in production because they depend on:

• Event timing
• Frequency thresholds
• Historical events
• Timeframe settings

Validate correlation logic using realistic event sequences whenever possible.

Custom Rule Not Loading

Custom rule deployment issues can prevent rules from being evaluated entirely.

Syntax Validation

Before restarting the manager, validate XML syntax carefully.

Common issues include:

• Missing tags
• Improper nesting
• Invalid attributes
• Typographical errors

A single syntax error can prevent multiple rules from loading.

XML Formatting Issues

Examples of common XML mistakes:

<rule id="100500">

without a matching closing tag.

Use XML validation tools whenever possible to identify formatting issues before deployment.

Manager Restart Requirements

After modifying rule files, restart the manager:

sudo systemctl restart wazuh-manager

Failure to restart the manager can result in outdated rules remaining active.

Related Guide:

Wazuh Vulnerability Detection Not Working? Here’s How to Fix It

Best Practices for Testing Wazuh Rules

Effective rule testing is an ongoing process rather than a one-time task.

Following established best practices helps maintain detection quality, improve alert accuracy, and reduce operational risk.

Use Representative Log Samples

The quality of testing depends heavily on the quality of the logs being used.

Capture Real Production Logs

Whenever possible, use actual production events rather than synthetic examples.

Benefits include:

• Realistic formatting
• Accurate field values
• Better decoder validation
• Improved detection accuracy

Production samples often reveal issues that artificial test logs miss.

Test Multiple Event Variations

Do not rely on a single log sample.

Instead, test:

• Different operating systems
• Various software versions
• Multiple user accounts
• Different event outcomes

This helps ensure rules remain reliable across diverse environments.

Test Before Production Deployment

Every new or modified rule should undergo validation before being deployed.

Validate All New Rules

Testing should verify:

• Decoder matching
• Rule execution
• Alert generation
• Severity assignments
• Correlation behavior

A structured testing process reduces the likelihood of production issues.

Review Detection Coverage

Periodically assess whether existing rules continue to provide adequate visibility.

Questions to consider include:

• Are critical attack techniques covered?
• Are important log sources monitored?
• Have new technologies been introduced?

Organizations should continuously improve detection coverage as environments evolve.

Maintain Rule Documentation

Proper documentation simplifies maintenance and improves operational efficiency.

Document Rule Purpose

Each custom rule should clearly document:

• Detection objective
• Use case
• Expected behavior
• Dependencies

Well-documented rules are easier to troubleshoot and update.

Record Testing Procedures

Maintain records of:

• Test logs used
• Validation steps
• Expected outcomes
• Known limitations

This information becomes valuable during audits and future troubleshooting efforts.

Track Rule Changes

Version control systems can help track:

• Rule modifications
• Severity adjustments
• Decoder updates
• Correlation changes

Change tracking improves accountability and simplifies rollback procedures.

Continuously Review Rule Effectiveness

Detection engineering is an ongoing process.

Rules that were effective six months ago may no longer provide adequate coverage today.

Monitor Alert Quality

Regularly review:

• False positive rates
• False negative trends
• Investigation outcomes
• Analyst feedback

Alert quality is often a better metric than alert quantity.

Update Rules as Threat Patterns Evolve

Attack techniques constantly change.

Organizations should update rules to address:

• Emerging threats
• New malware families
• Infrastructure changes
• Updated compliance requirements

The MITRE ATT&CK framework recommends continuously evaluating and improving detection capabilities as adversary behavior evolves.

Retest After Wazuh Upgrades

Major Wazuh upgrades can affect:

• Rulesets
• Decoders
• Correlation logic
• Log processing behavior

After every upgrade, retest:

• Custom rules
• Critical detections
• Compliance monitoring
• Security integrations

Related Guide:

How to Upgrade a Wazuh Agent

Frequently Asked Questions

How Do I Test a Wazuh Rule Without Generating Real Alerts?

The safest way to test a Wazuh rule is by using the Wazuh Logtest utility.

Logtest allows you to submit sample log entries directly to the Wazuh analysis engine and observe how decoders and rules process the event without generating production alerts.

This approach offers several advantages:

• No alert noise in production dashboards
• Immediate feedback on rule matching
• Easy troubleshooting of decoders and rules
• Faster validation of custom detection logic

To launch Logtest:

sudo /var/ossec/bin/wazuh-logtest

You can then paste log samples and review the decoding and rule evaluation results in real time.

What Is Wazuh Logtest?

Wazuh Logtest is a built-in testing utility that simulates how the Wazuh manager processes log events.

It allows administrators to:

• Test built-in rules
• Validate custom rules
• Verify decoder functionality
• Troubleshoot alert generation issues
• Test correlation logic

Logtest processes logs through the same analysis engine used in production, making it one of the most reliable methods for validating detection content before deployment.

The official Wazuh documentation recommends Logtest as the primary tool for testing custom rules and decoders.

 Wazuh Logtest Documentation: https://documentation.wazuh.com/current/user-manual/ruleset/testing.html

Why Is My Custom Wazuh Rule Not Matching Logs?

Several factors can prevent a custom rule from matching events.

Common causes include:

• Decoder failures
• Incorrect field names
• Invalid regular expressions
• Rule syntax errors
• Rule hierarchy issues
• XML formatting problems

When troubleshooting, start by confirming that the decoder is extracting the expected fields.

For example:

srcip: 10.0.0.5
user: admin

If the required fields are not present, the rule will not have the information needed to evaluate its conditions.

A good troubleshooting workflow is:

1. Test the log with Logtest.
2. Verify decoder output.
3. Confirm field extraction.
4. Review rule conditions.
5. Validate XML syntax.
6. Restart the Wazuh manager.

How Can I Test Frequency-Based Wazuh Rules?

Frequency-based rules require multiple matching events within a defined timeframe before an alert is generated.

Example:

<frequency>5</frequency>
<timeframe>60</timeframe>

This rule triggers after five matching events occur within sixty seconds.

To test frequency rules:

1. Generate multiple matching events.
2. Verify that alerts do not trigger before the threshold.
3. Confirm the alert appears when the threshold is reached.
4. Validate that timeframe restrictions function correctly.

Common test scenarios include:

• Failed login attempts
• Brute-force attacks
• Repeated malware detections
• Excessive firewall denials

Testing both threshold and timeframe behavior is important because correlation rules are more complex than standard event-based detections.

Should I Test Decoders Before Testing Rules?

Yes. Decoder validation should always occur before rule testing.

Decoders are responsible for extracting structured information from raw log data. Rules can only evaluate data that has already been extracted by a decoder.

For example:

Failed password for invalid user admin from 192.168.1.50

A decoder might extract:

srcip: 192.168.1.50
user: admin

The rule then uses these fields to determine whether an alert should be generated.

If the decoder fails, the rule will never receive the required data and may appear broken even when the rule logic is correct.

This is why many experienced Wazuh administrators troubleshoot decoder output before reviewing rule conditions.

How Do I Troubleshoot a Wazuh Rule That Is Not Triggering?

If a rule does not trigger as expected, follow a structured troubleshooting process.

Step 1: Verify Decoder Matching

Use Logtest and confirm the expected decoder appears:

decoder: sshd

If no decoder is identified, troubleshoot the decoder first.

Step 2: Review Extracted Fields

Confirm that required fields are present.

Examples:

srcip
user
process_name
event_id

Missing fields often explain rule failures.

Step 3: Validate Rule Conditions

Review:

• Field names
• Match conditions
• Regular expressions
• Parent-child relationships
• Frequency settings

Even minor mismatches can prevent alerts from being generated.

Step 4: Check Rule Loading

Validate XML syntax and ensure the manager successfully loaded the rule.

Restart the manager if necessary:

sudo systemctl restart wazuh-manager

Step 5: Compare Logtest and Production Results

If Logtest succeeds but production alerts do not appear, investigate:

• Agent configuration
• Log collection issues
• Correlation timing
• Event formatting differences

A methodical approach typically identifies the root cause quickly.

Conclusion

Testing Wazuh rules is a critical part of maintaining an effective security monitoring program.

Whether you are working with built-in rules, custom detections, correlation logic, or compliance monitoring content, thorough validation helps ensure that alerts are generated accurately and consistently.

Throughout this guide, we covered the complete Wazuh rule testing process, including validating prerequisites, using the Logtest utility, testing live log ingestion, troubleshooting rule issues, and evaluating correlation-based detections.

We also examined the importance of verifying decoder functionality before testing rules, since decoders provide the structured data that rules depend on to generate alerts.

By validating decoders and rules together, organizations can significantly reduce troubleshooting time, improve alert quality, and identify configuration problems before they impact production monitoring.

This approach also helps minimize false positives, reduce alert fatigue, and ensure that genuine security threats are detected reliably.

Effective rule testing does not end once a rule is deployed. Security environments constantly evolve as new technologies, log sources, applications, and attack techniques are introduced.

Regular testing and tuning help ensure that detection content remains relevant and continues to provide meaningful visibility into security events.

As your Wazuh deployment matures, consider expanding your testing process to include custom correlation rules, threat intelligence integrations, compliance monitoring controls, and attack simulation exercises.

Combining strong rule development practices with continuous validation will help you build a more reliable and effective detection program over time.

For organizations creating custom detection content, the next step is establishing a repeatable workflow for developing, testing, documenting, and maintaining rules throughout their lifecycle.

Doing so will improve detection accuracy, simplify troubleshooting, and ensure that your Wazuh deployment continues to deliver actionable security insights.