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.
Video: Incident investigation
20 minutes - Step-by-step case study
Discover our Wazuh serviceLearn more about our managed Wazuh service
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 |
Next steps
Our managed Wazuh service dives deeper into more incident investigation case studies and advanced detection configurations. Discover our Wazuh service.