Detecting & Responding to a Brute Force Attack with Wazuh — A Full Incident Response Walkthrough

Overview

This is a full incident response walkthrough from my Wazuh SIEM home lab. I simulated a real-world attack scenario, detected it through Wazuh, investigated the evidence, mapped it to the MITRE ATT&CK framework, and documented the response actions I would take in a live SOC environment.

This is not theory. Every alert, log entry, and command shown here was generated in my actual lab environment.

---

Lab Environment

Component	Details
SIEM Platform	Wazuh 4.7 (Manager + Dashboard)
Server OS	Ubuntu Server 22.04 LTS
Monitored Endpoint	Ubuntu Desktop 22.04 (Wazuh Agent)
Attack Simulation	Hydra SSH brute force from Kali Linux VM
Network	Isolated VirtualBox host-only network

---

Phase 1: The Alert Fires

At 14:32 local time, Wazuh generated a Rule 5763 alert — "SSHD brute force trying to get access to the system" — with a severity level of 10 (Critical).

The Wazuh dashboard showed a sudden spike in authentication failure events originating from a single source IP: 192.168.56.101 (my Kali Linux attacker VM).

Wazuh Alert — Rule 5763 (Level 10)
Dec 15 14:32:07 ubuntu sshd[2847]: Failed password for root from 192.168.56.101 port 54312 ssh2
Dec 15 14:32:07 ubuntu sshd[2848]: Failed password for root from 192.168.56.101 port 54313 ssh2
Dec 15 14:32:08 ubuntu sshd[2849]: Failed password for root from 192.168.56.101 port 54314 ssh2
[...repeated 487 times in 90 seconds]

487 failed authentication attempts in 90 seconds from a single IP. This is unambiguous — a brute force attack is in progress.

---

Phase 2: MITRE ATT&CK Mapping

Before investigating further, I mapped the observed behaviour to the MITRE ATT&CK framework — the industry-standard taxonomy for adversary tactics and techniques.

ATT&CK Field	Value
Tactic	Credential Access (TA0006)
Technique	Brute Force (T1110)
Sub-technique	Password Guessing (T1110.001)
Platform	Linux
Data Source	Authentication logs (/var/log/auth.log)
Mitigation	M1036 — Account Use Policies, M1032 — Multi-factor Authentication

Mapping to ATT&CK immediately tells me: this is a credential access attempt. The attacker's goal is to gain valid credentials for initial access or privilege escalation. I need to determine whether any attempt succeeded.

---

Phase 3: Investigation — Did Any Login Succeed?

The critical question in any brute force investigation is: did the attacker get in?

I queried the Wazuh dashboard for Rule 5715 (Successful SSH login) from the same source IP during the attack window:

# Query auth.log for successful logins from attacker IP
grep "Accepted password" /var/log/auth.log | grep "192.168.56.101"

Result: No output. No successful authentication from the attacker IP during or after the brute force window. The attack failed.

I also checked for lateral movement indicators — any new user accounts created, sudo commands executed, or cron jobs modified during the attack window:

# Check for new user creation
grep "useradd\|adduser" /var/log/auth.log

# Check sudo usage
grep "sudo" /var/log/auth.log | tail -20

# Check cron modifications (Wazuh FIM alert)
# Wazuh Rule 550 — Integrity checksum changed

All checks returned clean. No post-compromise activity detected.

---

Phase 4: Containment

Even though the attack failed, the source IP is actively hostile. Immediate containment action:

# Block the attacker IP at the firewall
sudo ufw deny from 192.168.56.101 to any
sudo ufw reload

# Verify the rule is active
sudo ufw status | grep 192.168.56.101

In a real enterprise environment, this would be escalated to the network team to block the IP at the perimeter firewall and add it to the threat intelligence blocklist. I would also check whether the same IP appeared in logs from other monitored endpoints.

---

Phase 5: Hardening Recommendations

After containment, a SOC analyst documents remediation recommendations to prevent recurrence:

Recommendation	ATT&CK Mitigation	Priority
Disable SSH password authentication — use key-based auth only	M1032	Critical
Implement fail2ban to auto-block IPs after N failed attempts	M1036	High
Change SSH from default port 22 to a non-standard port	M1056	Medium
Enable MFA for all remote access	M1032	High
Review and restrict which accounts can SSH remotely	M1026	High

---

Phase 6: Incident Report Summary

Field	Details
Incident ID	IR-2024-001
Date/Time	Dec 15, 2024 — 14:32 UTC
Severity	High
Type	Brute Force / Credential Access
Source IP	192.168.56.101 (Kali Linux — simulated attacker)
Target	SSH service on Ubuntu endpoint
MITRE ATT&CK	T1110.001 — Brute Force: Password Guessing
Outcome	Attack failed. No successful authentication.
Containment	Source IP blocked via UFW firewall rule
Status	Resolved

---

What This Exercise Taught Me

Running this scenario end-to-end in my home lab gave me a concrete understanding of what a Tier 1 SOC analyst actually does during an incident. The process is not just about reading alerts — it is about asking the right questions in the right order:

1. What happened? — Identify the alert and the raw evidence
2. What does it mean? — Map to ATT&CK to understand adversary intent
3. Did it succeed? — Determine if the attack achieved its objective
4. What do I do now? — Contain, eradicate, and recommend hardening
5. How do I prevent it next time? — Document and implement mitigations

This is the SOC analyst mindset. Every alert is a story — your job is to read it correctly and respond before the next chapter is written.

---

Tools & References

• Wazuh — open-source SIEM and XDR platform
• MITRE ATT&CK — adversary tactics and techniques framework (attack.mitre.org)
• Hydra — network login brute force tool (used for simulation only)
• UFW — Uncomplicated Firewall for Linux
• fail2ban — intrusion prevention framework