Project 03 — Threat Detection

Attack &
Detection Lab

Simulated three distinct attack scenarios against a live Wazuh SIEM environment — network reconnaissance, SSH brute force, and Metasploit-based credential attacks — capturing real detections and analyzing them as a SOC analyst would in production.

Nmap Hydra Metasploit Nikto Wazuh Detection MITRE ATT&CK Rule 5763 SOC Analysis
3 Attack Scenarios
6 Rule 5763 Hits
10 Max Alert Level
2 Attack Tools Detected

Attack Scenarios

01 — Network Reconnaissance (Nmap) Reconnaissance
Attack

Executed an aggressive Nmap SYN scan against the Windows 11 workstation (192.168.56.1) targeting all 1,024 common ports with OS detection, service version enumeration, and script scanning enabled.

# Aggressive SYN scan from Kali
nmap -sS -A 192.168.56.1

# Results
PORT     STATE   SERVICE
8080/tcp open    http
         Apache Tomcat (en)

OS: Windows 11 21H2 (91%)
Distance: 1 hop
Detection & Analysis

Wazuh detected the scan via rootcheck anomaly rules on the Kali agent and port status change events. The scan revealed an Apache Tomcat instance running on port 8080 — an attack surface that would be prioritized in a real engagement. Windows Firewall filtered 999/1000 ports, demonstrating effective host-based defense.

Rule 510 — Rootcheck Anomaly Rule 533 — Port Status Change

MITRE ATT&CK: T1046 — Network Service Discovery

Nmap scan results showing open ports and OS detection

Nmap -sS -A scan results — port 8080 open (Apache Tomcat), OS detected as Windows 11 21H2 (91% confidence)

02 — SSH Brute Force (Hydra) Credential Access
Attack

Launched a dictionary-based SSH brute force attack against the Wazuh server (192.168.56.101) using Hydra with the rockyou.txt wordlist. 196 password attempts across 4 parallel threads over approximately 3 minutes.

# Hydra SSH brute force
hydra -l root \
  -P /usr/share/wordlists/rockyou.txt \
  192.168.56.101 ssh -t 4

# Output
[DATA] attacking ssh://192.168.56.101:22
[STATUS] 73 tries/min
196 login tries attempted
Detection & Analysis

Wazuh fired its highest-severity brute force rule (5763, level 10) within seconds of the attack beginning. The rule correlates multiple authentication failures into a single behavioral detection — exactly how a real SOC tool identifies credential stuffing and brute force campaigns.

Rule 5763 lvl 10 — SSH Brute Force Rule 40111 lvl 10 — Multiple Auth Failures Rule 5551 lvl 10 — PAM Multiple Failed Logins Rule 5758 lvl 8 — Max Auth Attempts Exceeded Rule 5760 lvl 5 — Auth Failed

MITRE ATT&CK: T1110.001 — Brute Force: Password Guessing

03 — Metasploit SSH Login Scanner Credential Access
Attack

Used the Metasploit Framework's auxiliary/scanner/ssh/ssh_login module to perform a second wave of credential attacks against the same target. Demonstrates that Wazuh detects the malicious behavior — not the specific tool.

# Metasploit SSH login scanner
use auxiliary/scanner/ssh/ssh_login
set RHOSTS 192.168.56.101
set USERNAME root
set PASS_FILE /usr/share/wordlists/rockyou.txt
set THREADS 4
run

[*] Starting bruteforce
[*] Testing User/Pass combinations
Detection & Analysis

Rule 5763 fired again — proving Wazuh's detection is behavior-based, not signature-based. The Wazuh dashboard showed two distinct attack clusters in the timeline graph: the Hydra attack at ~19:46 and the Metasploit attack at ~20:57. A SOC analyst would immediately recognize these as two separate attack campaigns against the same target.

Rule 5763 lvl 10 — SSH Brute Force (x2) Rule 5551 lvl 10 — PAM Multiple Failures (x4)

Key SOC Insight
Two different tools — Hydra and Metasploit — generated identical Wazuh rule 5763 detections because both exhibit the same behavior: rapid sequential SSH authentication failures. This is behavioral detection in action. A SIEM doesn't need to know what tool an attacker used — it identifies what the attacker is doing.

MITRE ATT&CK: T1110.001 — Brute Force: Password Guessing

Detection Timeline

Timestamp
Lvl
Rule Description
19:46:30
10
sshd: brute force trying to get access to the system [Hydra — Wave 1]
19:47:34
10
sshd: brute force trying to get access to the system [Hydra — Wave 1]
19:48:34
10
sshd: brute force trying to get access to the system [Hydra — Wave 1]
19:49:36
10
sshd: brute force trying to get access to the system [Hydra — Wave 1]
20:57:55
10
sshd: brute force trying to get access to the system [Metasploit — Wave 2]
20:59:21
10
sshd: brute force trying to get access to the system [Metasploit — Wave 2]
Wazuh Threat Hunting showing rule 5763 brute force detections

Wazuh Threat Hunting filtered to rule 5763 — 6 hits across 24 hours showing two distinct attack campaigns (Hydra + Metasploit), all level 10

MITRE ATT&CK Mapping

Reconnaissance
T1046
Network Service Discovery — Nmap used to enumerate open ports, services, and OS on target Windows machine.
Credential Access
T1110.001
Brute Force: Password Guessing — Hydra and Metasploit used to attempt SSH authentication with rockyou.txt wordlist.
Discovery
T1046 + T1595
Active Scanning — Nikto web vulnerability scanner used to probe the Tomcat instance for misconfigurations and missing security headers.

SOC Analyst Perspective

If this were a production SOC environment, here's how I would triage and respond to these alerts:

IMMEDIATE RESPONSE

Rule 5763 at level 10 would trigger an immediate ticket. Identify the source IP (192.168.56.102 — Kali), correlate with other events in the same time window, and determine if any login succeeded (rule 5715). Block the source IP at the firewall.

INVESTIGATION

Check for successful authentications after the brute force (rule 5715). Review lateral movement indicators. Determine if the source IP is internal (compromised insider) or external (perimeter breach). Timeline the full attack chain.

CONTAINMENT

Isolate affected host if compromise is confirmed. Reset credentials for targeted accounts. Enable fail2ban or equivalent automatic blocking on the SSH service. Review other services on the same host for similar exposure.

REMEDIATION

Disable root SSH login. Implement SSH key-based authentication only. Configure account lockout after failed attempts. Enable geographic IP restrictions if SSH access patterns are predictable. Document and close the incident ticket.