SSH Brute Force Detection with Layered Wazuh Rules

The objective was to design and implement layered detection logic for SSH brute-force attacks inside a controlled Wazuh SIEM lab. The project focused on moving beyond basic log monitoring and creating custom correlation-based rules that identify suspicious authentication behavior as it develops.

The goal was not only to generate alerts, but to better understand how SIEM rules operate, how multiple events can be correlated into meaningful patterns, and how threshold-based logic can be tuned to reflect realistic attack scenarios.

SSH brute-force attacks attempt to gain unauthorized access by repeatedly trying password combinations against a remote login service. A single failed login may not be meaningful by itself, but repeated failures from the same source can indicate automated attack behavior.

In this lab, Kali Linux was used to simulate a controlled brute-force attack against a Linux server running SSH. Wazuh collected authentication logs and analyzed the behavior so the detection logic could identify both early suspicious activity and confirmed brute-force behavior.

The Linux server recorded authentication activity in /var/log/auth.log, including timestamps, usernames, and source IP addresses. Wazuh ingested those logs through its agent and processed each failed login attempt.

Default Wazuh rule ID 5503 provided visibility into individual PAM authentication failures. However, single-event detection did not fully explain whether those failures were part of a larger attack pattern. Reviewing the logs showed repeated failures from the same source IP, which justified a stronger correlation-based approach.

From an analyst perspective, repeated failures from one source IP represent a clear deviation from normal user behavior and provide a strong signal for automated attack activity.

During implementation, the Wazuh manager failed to restart because of an XML configuration error in the custom rule file. A rule element was incorrectly placed outside a group block, causing the rule parser to fail.

I reviewed the service logs, identified the syntax issue, corrected the rule structure, and verified proper nesting. I also checked the use of if_matched_sid, frequency, and timeframe logic to confirm the custom rules behaved correctly.

This was one of the most useful parts of the project because it showed the real troubleshooting process behind detection engineering. Detection work is not just writing rules — it also requires validating syntax, service behavior, rule logic, and alert output.

In a real-world environment, repeated authentication failures could trigger response actions such as temporarily blocking the source IP address, enforcing account lockout policies, applying rate limiting, or disabling password-based SSH authentication in favor of SSH keys.

Although this project focused on detection, it shows how detection logic can support broader incident response by identifying suspicious behavior early and escalating confirmed attack patterns for analyst review.

After correcting the rule configuration, I ran the attack simulation again and confirmed that both detection stages worked as intended. The early warning rule triggered at a lower threshold, and the high-severity rule triggered after continued attack activity.

The results showed clear visibility into the progression of the brute-force attempt and confirmed that the layered rules accurately reflected attacker behavior. The final detection flow transformed raw authentication failures into meaningful, prioritized alerts.

The report includes evidence from the full attack and detection lifecycle, including Hydra output, Linux authentication logs, Wazuh authentication events, custom rule configuration, Wazuh manager troubleshooting, and layered alerts showing both early warning and high-severity detection stages.

The evidence supports the full workflow: attack simulation, log generation, SIEM ingestion, default alerting, custom rule configuration, service troubleshooting, and final validation.

This project maps to MITRE ATT&CK Credential Access technique T1110 — Brute Force. The simulated Hydra activity generated repeated SSH authentication attempts against the target system.

The layered detection approach supports this mapping by identifying both early suspicious activity and confirmed sustained brute-force behavior, which helps turn raw log data into standardized security reporting.