Responding to SSH Brute-Force Attacks in a Home Lab
Manish Rawat
System Weakness is a publication that specialises in publishing upcoming writers in cybersecurity and ethical hacking space. Our security experts write to make the cyber universe more secure, one vulnerability at a time.
By Manish — Aspiring SOC Analyst | Blue Team Learner
📌 Overview
This article documents a home lab simulation of a basic SSH brute-force attack and how I walked through the Incident Response (IR) lifecycle using a minimal setup. The goal was to detect, analyze, and respond to the attack using Wazuh and the ELK Stack, simulating the typical workflow of a SOC analyst.
🛠️ Lab Environment
OS: Kali Linux (single VM)
Monitoring Tools:
Wazuh Manager + Agent (local)
ELK Stack (Elasticsearch + Kibana)
Monitored Logs:
/var/log/auth.logThis setup reflects a minimal but functional home-based SOC environment.
🔧 Step 1: Preparing the Environment
Wazuh was installed and configured to monitor system authentication logs.
The Wazuh agent was installed on the same Kali VM.
Filebeat was used to forward logs to the local ELK Stack.
Kibana was configured with the Wazuh plugin for log analysis.
🎯 Step 2: Simulating the Attack
To simulate a brute-force SSH attack, I used
hydra, a popular password attack tool available by default on Kali Linux.This command attempts multiple SSH logins using the username
root and passwords from the rockyou.txt wordlist.🚨 Step 3: Detection & Alerting
Wazuh immediately picked up on the failed login attempts.
Alerts generated:
Rule: 5710 — SSHD: Attempt to login using a non-existent user.Rule: 5712 — SSHD: Attempt to login using a known user.Rule: 5715 — SSHD: Authentication failure.Using Kibana’s Discover panel, I filtered for:
This revealed a timeline of failed login attempts, source IPs, usernames, and timestamps — all critical for triage.
🛡️ Step 4: Containment
After confirming malicious behavior, I applied a temporary IP block as a containment measure:
This blocked incoming SSH traffic from the attack source (localhost in this case).
🧹 Step 5: Eradication
To prevent future brute-force attacks:
Disabled root SSH login in
/etc/ssh/sshd_config:PermitRootLogin noRestarted the SSH service:
sudo systemctl restart sshThis hardening step significantly reduced the attack surface.
♻️ Step 6: Recovery
Confirmed legitimate access via SSH using a non-root user and SSH keys.
Removed temporary IP block after validation.
Ensured Wazuh rules remained active for monitoring future attempts.
📓 Step 7: Lessons Learned
Alert quality matters: Wazuh’s built-in rules are effective out-of-the-box for brute-force attempts.
Log visibility is power:
/var/log/auth.log remains the primary source of truth for SSH-related activity.Simplicity is sufficient: Even without enterprise tools, effective detection and response is possible in a minimal lab.
🧠 Final Thoughts
Every SOC alert is a decision point. This project wasn’t just about simulating brute-force detection — it was about building the mental muscle of response: from understanding the source, validating the signal, taking decisive containment action, and hardening the system against recurrence.
What I gained here wasn’t just a functioning detection stack — it was the confidence that comes from making the right move at the right time with the tools available.
In a real SOC environment, speed matters. Clarity matters. Knowing what to ignore matters just as much as knowing what to escalate. This lab gave me that mindset — and that’s what I carry forward into every log I read, alert I triage, or rule I tune.
#cybersecurity #Splunk #Wazuh #BlueTeaming #SOC #SecurityAnalyst #LAB #IncidentResponse #Blog #ELKstack
Like this project
Posted Jun 16, 2025
Simulated SSH brute-force attack and response using Wazuh and ELK Stack in a home lab.
Likes
0
Views
0
Timeline
Jun 9, 2025 - Jun 10, 2025
