To investigate an SSH attack with Wazuh, use the Threat Hunting panel to detect the brute-force pattern and the Discover panel to trace every event chronologically: failed attempts, the attacker's successful login, and password changes.
What is the scenario for this case study?
A user reports they can no longer access the Linux server. Their password doesn't work and nobody changed it. What happened? In this article we investigate the incident step by step using Wazuh's Threat Hunting and Discover panels.
How did the attack unfold?
Monday morning. The user jperez reports they can't access the Linux server over SSH. The password that has always worked is now rejected. No one on the systems team changed it.
⚠️ First warning signs
Checking the inbox, we find 20 Wazuh alerts starting at 1:43 AM. All related to SSH login attempts against the user jperez. This smells like a brute-force attack.
How do you use the Threat Hunting panel for proactive hunting?
The Threat Hunting panel is designed to search for threats proactively. We filter by the affected server and authentication events:
Findings in Threat Hunting
- 362 authentication failures (level 12+ rules)
- 7 successful authentications - the attacker got in
- All concentrated between 1:43 AM and 2:15 AM
The ratio is clear: 362 failed attempts followed by 7 successes. A dictionary attack that succeeded.
How do you use the Discover panel for forensic analysis?
The Discover panel gives direct access to Wazuh's search engine. It's perfect for detailed forensic analysis. We build specific queries:
How do you filter failed and successful attempts at the same time?
We filter by the affected machine and SSH events:
agent.name: "servidor-linux" AND rule.groups: "authentication"Result: a full timeline of the attack, from the first failed attempt to the successful logins.
How do you pinpoint the exact moment of the successful login?
login ssh jperez successWe find exactly when the attacker gained access: 2:08 AM.
How do you detect the password change made by the attacker?
passwd jperezBingo! At 2:10 AM there's a password change event for the user jperez. The attacker changed the password to keep access and lock out the legitimate user.
How do you check whether the attacker hit other machines?
We filter by the attacker's source IP to see if they tried to access other systems:
srcip: "IP_ATACANTE" AND rule.groups: "authentication"We discover that the same IP attempted access to 3 other servers without success.
What was the attack timeline?
| Time | Event |
| 01:43 AM | SSH brute-force attempts begin |
| 01:43 - 02:08 | 362 failed authentication attempts |
| 02:08 AM | Attacker's first successful authentication |
| 02:10 AM | Password change for the user jperez |
| 08:30 AM | Legitimate user reports they can't log in |
What remediation measures should you apply after the attack?
With the analysis complete, we implement the following measures:
How do you install Fail2ban for automatic blocking?
Automatically blocks IPs after X failed attempts:
apt install fail2ban
systemctl enable fail2banConfiguration in /etc/fail2ban/jail.local:
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600
findtime = 600Result: After 5 failed attempts in 10 minutes, the IP is blocked for 1 hour.
How do you set up public key authentication for SSH?
Disable SSH passwords and use public keys only:
# Generate a key on the client
ssh-keygen -t ed25519
# Copy the key to the server
ssh-copy-id usuario@servidorEdit /etc/ssh/sshd_config:
PasswordAuthentication no
PubkeyAuthentication yesRestart SSH:
systemctl restart sshdResult: Brute-force attacks are completely neutralized.
Which regulatory frameworks does this case study cover?
ISO 27001 - Incident management
- A.5.24: Information security incident management planning and preparation
- A.5.25: Assessment and decision on information security events
- A.5.26: Response to information security incidents
- A.5.27: Learning from information security incidents
- A.5.28: Collection of evidence
This case study demonstrates compliance across the entire cycle: detection, assessment, response, learning, and evidence documentation.
ENS - National Security Framework
- op.exp.7: Security incident management
Wazuh provides the detection, analysis, and documentation capability the ENS requires for incident management.
Summary
| Panel | Main use |
| Threat Hunting | Proactive hunting, threat overview |
| Discover | Forensic analysis, specific queries, event correlation |
What does this case study teach about detection speed?
The most uncomfortable lesson is in the timeline: the attacker began at 1:43 AM, broke in at 2:08 AM after 362 failed attempts, and locked out the legitimate user with a password change at 2:10 AM, yet the breach was only noticed at 8:30 AM when the user couldn't log in. That is a detection gap of more than six hours during which the intruder had full control. Wazuh recorded every step in real time, but recording is not the same as reacting.
This is precisely why an automated active response matters. With Fail2ban the same source IP would have been blocked after 5 failed attempts in 10 minutes, well before reaching 362; with public-key-only authentication the dictionary attack would have been impossible from the start. The forensic value of Discover and Threat Hunting is in reconstructing what happened, but the real win is configuring the environment so the next attempt never gets past the first few minutes.
Frequently Asked Questions
How do you investigate an SSH brute-force attack with Wazuh?
Start in the Threat Hunting panel to confirm the brute-force pattern by counting failed versus successful authentications, then switch to the Discover panel to build precise queries and reconstruct the timeline event by event: the failed attempts, the attacker's successful login, the password change, and any attempts against other hosts. In this case study Threat Hunting revealed 362 failed and 7 successful authentications concentrated between 1:43 AM and 2:15 AM.
What is the difference between the Threat Hunting and Discover panels?
Threat Hunting is designed for proactive, high-level hunting: filtering by host and event type to spot patterns such as an abnormal ratio of authentication failures to successes. Discover gives direct access to Wazuh's search engine for detailed forensic analysis, letting you write specific queries to pinpoint the exact moment of compromise and correlate individual events.
How do you identify the exact moment of an SSH compromise in Wazuh?
In the Discover panel you filter by the affected machine and authentication group (for example agent.name and rule.groups: "authentication") to get the full timeline, then narrow the query to the successful SSH login for the targeted user. In this incident the attacker's first successful login was at 2:08 AM, followed by a password change for the user jperez at 2:10 AM.
How do you stop SSH brute-force attacks after an incident?
Two measures neutralize them. Fail2ban automatically bans an IP after a set number of failed attempts (for example 5 attempts in 10 minutes, banned for 1 hour). More definitively, disabling password authentication and switching to public-key authentication in sshd_config removes the attack surface entirely, since there is no password to guess.
Which compliance controls does an SSH incident investigation cover?
It covers the full ISO 27001 incident-management cycle: A.5.24 (planning and preparation), A.5.25 (assessment of events), A.5.26 (response), A.5.27 (learning), and A.5.28 (collection of evidence). For the Spanish ENS framework it satisfies op.exp.7 (security incident management), because Wazuh provides the detection, analysis, and documentation the regulation requires.
Next steps
Our managed Wazuh service dives deeper into more incident investigation case studies and advanced detection configurations. Discover our Wazuh service.