SSH Brute Force Detection with Security Onion
Lab Objective
Simulate an SSH brute-force attack from a Kali Linux attacker to an Ubuntu victim, capture the activity in Security Onion, and export detection logs for reporting.
Step 1 – Confirm Network Connectivity
Verify all VMs are on the same NAT network and Security Onion has visibility into the attack path.
# From Kali to Ubuntu
ping 10.0.2.4
Before launching anything, I confirmed that all machines could talk to each other. Without network connectivity, Security Onion’s IDS wouldn’t see any of the attack traffic and the lab would fail before it even started. This is also a basic step in real SOC workflows—connectivity issues can mask actual security events. It ties into NIST 800-53 CM-7 (Least Functionality) because it verifies that only intended connections are available, and ISO 27001 A.12.4.1 (Event Logging) because connectivity is the first step in ensuring log completeness. From a MITRE ATT&CK perspective, verifying communication paths sets the stage for detecting techniques like T1021 (Remote Services).
Step 2 – Launch SSH Brute Force from Kali
Use Hydra with the rockyou.txt password list.
gunzip /usr/share/wordlists/rockyou.txt.gz
hydra -l ubuntu -P /usr/share/wordlists/rockyou.txt 10.0.2.4 ssh
I used Hydra because it’s a fast, versatile password-cracking tool that can simulate a real-world SSH brute force attack. The -l flag sets the username and -P points to the password list, in this case, rockyou.txt. Each failed attempt generates network noise that Suricata in Security Onion should detect. This maps to MITRE ATT&CK T1110 (Brute Force), NIST 800-53 SI-4 (System Monitoring), and OWASP A2: Broken Authentication. It’s also an ISO 27001 A.12.6.1 (Technical Vulnerability Management) example, because identifying brute force attempts is part of preventing unauthorized access.
Step 3 – Monitor Alerts in Security Onion
In Kibana:
- Go to Dashboards > Security Onion > All Logs.
- Apply this filter:
event.module: "suricata" AND destination.port: 22 AND source.ip: 10.0.2.5 AND destination.ip: 10.0.2.4 - Set time range to match your attack.
In Kibana, I filtered the logs to only show SSH traffic from my Kali machine to my Ubuntu target. This removes unrelated noise so I can zero in on the specific attack pattern. SOC analysts do this daily to avoid wasting time on irrelevant events. This directly maps to NIST 800-53 AU-6 (Audit Review, Analysis, and Reporting) and ISO 27001 A.12.4.3 (Administrator and Operator Logs). It also aligns with MITRE ATT&CK TA0006 (Credential Access) because filtering by port 22 is a common way to detect credential-based attacks.
Step 4 – Review & Export Logs
- Click the Export - CSV button in the top-right.
- Save the file locally for reporting.
Exporting the CSV gives me a raw data set I can archive or share with incident response teams. This ensures the evidence is preserved in its original form, which is important for compliance and forensic investigation. In the real world, an SOC analyst might send this to a threat intelligence team for deeper review. This supports NIST 800-53 AU-9 (Protection of Audit Information) and ISO 27001 A.12.4.1 (Event Logging). It also supports MITRE ATT&CK T1078 (Valid Accounts) analysis if the brute force attack eventually succeeds.
Step 5 – Report Findings
From your exported CSV:
- Source IP: 10.0.2.5 (Kali attacker)
- Destination IP: 10.0.2.4 (Ubuntu victim)
- Timestamps: 19:28:00 – 19:29:54
- Rule Name: SSH Brute Force (Suricata)
(Here is a primlimary report that I wrote to give you idea)
"Between 19:28:00 and 19:29:54 UTC on Aug 13, 2025, Security Onion detected 33 Suricata alerts matching the signature SSH- against the Ubuntu host (10.0.2.4) on port 22. The alerts originated from the Kali attack machine (10.0.2.5), confirming the simulated SSH brute-force activity. Each log entry included a matching timestamp, source IP, destination IP, and rule signature. These findings validate that the IDS component successfully identified and recorded suspicious authentication attempts, meeting detection and logging requirements."
This final step turns raw logs into actionable intelligence. By mapping the detected traffic to known frameworks, I can justify why the detection matters and how it aligns with organizational policies. It directly relates to NIST 800-53 IR-5 (Incident Monitoring), ISO 27001 A.16.1.5 (Response to Information Security Incidents), and OWASP Top 10 A5: Security Misconfiguration. From a MITRE ATT&CK standpoint, the activity matches T1110, confirming the detection was accurate. Reporting findings is the SOC’s way of closing the loop between detection and response.
