Wazuh SIEM Lab Part 3: Attack Simulation and What the Dashboards Showed

Part 3 of 3. Brute forcing SSH, scanning DVWA with Nikto, and seeing how the alerts, MITRE mappings and vulnerability data came together.

This is the last of three posts on a Wazuh SIEM lab I built for a fictional fintech company, FireOps Systems, as part of a cybersecurity team project. Part 1 covered installing Wazuh and connecting three agents. Part 2 covered AWS CloudTrail, the DVWA web server and File Integrity Monitoring.

With all of that in place, it was time to actually attack the environment and see whether the SIEM caught it.

Part 7: Attack Simulation

Brute Force SSH

The first test was a simple brute force simulation. I ran repeated SSH attempts against the Ubuntu manager from the terminal:

ssh wronguser@192.168.191.129

Enter wrong password multiple times

Wazuh fired the alert within seconds of the attempts. The rule mapped to MITRE ATT&CK T1110 (Brute Force) and the severity hit level 10 on the first round of failures.

When I filtered for rule.level 12 to 14, I found a higher severity alert: multiple authentication failures followed by a successful login from IP 100.65.116.44, my Tailscale VPN address. That kind of pattern, repeated failures then a success, is usually the first thing a SOC analyst would want to look at.

Nikto Web Vulnerability Scan

From Kali Linux, I ran Nikto against the DVWA application:

nikto -h http://192.168.191.132/DVWA

Nikto running from the Kali Linux attack machine. The tool systematically probes thousands of known vulnerabilities and misconfigurations.

While the scan was running, Wazuh fired Critical level 15 alerts, including one for a Shellshock attempt pattern picked up by the web application rules.

Critical level 15 Shellshock alerts firing in the Wazuh Discover view during the Nikto scan. The source IP 192.168.191.130 is the Kali attacker. MITRE techniques T1068 (Exploitation for Privilege Escalation) and T1190 (Exploit Public-Facing Application) are mapped automatically.

The scan turned up exposed .git directories, missing security headers, directory indexing on sensitive paths, and the exposed DVWA admin page. All of it landed in the Wazuh logs.

Part 8: What the Dashboard Showed After Everything Was Running

Once all agents, CloudTrail, FIM and the attack simulations were complete, the Threat Hunting dashboard gave a full picture of what had happened across the lab.

45,285 total events recorded across all sources. The MITRE ATT&CK chart shows the techniques triggered during the session. Vulnerability Scanning and Exploit Public-Facing Application dominate from the Nikto run, while Process Injection, Valid Accounts and Password Guessing reflect the brute force tests.

The Overview dashboard showed the final 24-hour alert counts:

Final Overview dashboard with all 3 agents active. The 4 Critical alerts came from the Nikto scan hitting Shellshock detection rules. The 44,000+ Low severity events are mostly normal system activity that Wazuh logs for completeness.

Vulnerability Detection results across all three agents. Windows carries the largest exposure at 353 findings, mostly Firefox and OS-level CVEs. The ubuntu-webserver shows 65 vulnerabilities including aiohttp, pillow and pypdf packages.

The Malware Detection module flagged a rootcheck finding on the web server:

Malware Detection caught a “Possible kernel level rootkit” indicator alongside 324 host-based anomaly detection events. That’s the kind of result that would need someone to actually go check the box by hand, not just dismiss as noise.

The raw event stream in Discover showed the full mix of log sources, all indexed and searchable in one place: Windows authentication events, Kali netstat output, AppArmor denials from the web server.

Wazuh Discover view showing mixed log sources including Windows login events, netstat output from Kali and network connection data.

Wazuh Discover view showing AppArmor DENIED events from ubuntu-webserver and Kali netstat port listening output.

The raw event stream in Wazuh Discover. Windows authentication events, Kali network activity and AppArmor denials from the web server all land in the same searchable index, normalized and ready for correlation.

Key Things I Learned

The Wazuh Manager and Agent cannot coexist on the same machine. If you try to install an agent on the manager box, dpkg refuses with a conflicts error. That’s by design.

AWS CloudTrail does not push to Wazuh in real time. The integration polls the S3 bucket on a schedule (I set it to every 10 minutes). If you’re expecting immediate visibility into cloud events, this is a limitation worth knowing about going in.

Agent registration can fail silently. If your agent shows up in the dashboard but never goes Active, check /var/ossec/logs/ossec.log on the agent machine for connection refused or authentication failed errors. The most common cause is the manager IP not being set correctly in ossec.conf.

boto3 has to be installed before the AWS module will work. The error in the Wazuh logs when boto3 is missing isn’t very clear. If AWS events aren’t appearing, run python3 -c “import boto3” on the manager and install it if it fails.

FIM with realtime=yes has a very small detection window. The shell.php file I created was flagged before I’d even finished typing the next command.

Tools Used

What Comes Next

The next phase of this project involves:

• Running a full Hydra SSH brute force from Kali against the testuser account created specifically for attack simulation
• Connecting Suricata IDS to Wazuh so network-level alerts sit alongside host-level ones
• Building custom detection rules for patterns specific to payment API abuse
• Setting up automated email and webhook alerts for Critical severity events

All lab work was done in a controlled virtual environment.