How I Tried Hacking My Own Ubuntu Server with Password Guessing and Here’s How Wazuh Caught It Live

Introduction

In the world of cybersecurity, few attacks are as persistent and preventable as SSH brute-force attempts. Every day, millions of login attempts hammer exposed SSH servers worldwide, hoping to guess the right password. But what happens when you simulate one yourself in a safe lab environment? Can a modern SIEM/XDR tool like Wazuh actually catch it in real time?

In this hands-on lab, I set out to find out. I built a virtual lab with a Kali Linux attacker machine, an Ubuntu target server, and a full Wazuh deployment. Using the legendary Hydra tool, I launched a controlled brute-force attack and watched Wazuh turn raw authentication logs into clear, actionable security alerts.

If you’re a security enthusiast, student, or sysadmin looking to understand brute-force detection from the inside out, this guide walks you through exactly what I did, why it matters, and what I learned.

Why This Lab Matters

SSH remains one of the most targeted services on the internet. Brute-force attacks are noisy, low-effort, and incredibly common. Tools like Wazuh help security teams move from “we have logs” to “we’re actively detecting and responding.”

My goal? To generate realistic SSH brute-force traffic, observe how Wazuh’s rules and correlation engine work, and understand the difference between a few failed logins and a full-blown attack.

Lab Environment Setup

I kept the setup simple but realistic, using a bridged network on my virtualization platform (VirtualBox).

Virtual Machines:

• Attacker: Kali Linux, which is equipped with Hydra for the brute-force attack.
• Target: Ubuntu Linux, which is running OpenSSH on a non-standard port 3521 (security best practice) with the Wazuh agent installed.
• Monitoring: Full Wazuh stack (Manager + Indexer + Dashboard) on its own VM.

Network Details (example IPs — replace with yours):

• Kali (Attacker): 192.168.1.XXX (K)
• Ubuntu (Target): 192.168.1.173
• Wazuh Server: 192.168.1.XXX (W)

All VMs were on the same bridged network, so they could communicate directly.

Key Tools:

• Hydra (brute-force tool)
• OpenSSH on Ubuntu
• Wazuh agent + manager + dashboard
• rockyou.txt wordlist (for the scaled attack)

Step-by-Step: How I Executed the Brute-Force Attack

1. Preparation on the Target (Ubuntu)

Before launching any attack, I made sure the environment was ready:

• Verified OpenSSH was installed and running on port 3521 (changed from the default 22 for realism).

Figure 1: Ensuring our SSH server is installed and active

• Confirmed the Wazuh agent was active and connected to the manager.

Figure 2: Confirming if our Wazuh manager is running on our Ubuntu server

• Checked the Wazuh dashboard to ensure logs were flowing from the Ubuntu agent.

Figure 3: Screenshot of the Wazuh dashboard

I also opened the necessary firewall rules on Ubuntu to allow traffic on port 3521.

2. Small-Scale Test (Proof of Concept)

On the Kali attacker machine, I started small to confirm everything worked:

1. Created a tiny passwords.txt file with a few fake passwords.

nano passwords.txt

1. Ran this Hydra command:

hydra -l root -P passwords.txt -s 3521 192.168.1.173 ssh -t 4 -V

Command breakdown:

• -l root: Username to attack (root is a common target).
• -P passwords.txt: Password list.
• -s 3521: Custom SSH port on the target.
• 192.168.1.173: Target IP.
• ssh: Service type.
• -t 4: 4 parallel threads.
• -V: Verbose output so I could watch every attempt live.

Figure 4: Screenshot of the Hydra attack on our Kali

This generated a handful of failed logins. Wazuh immediately picked them up, but the alerts were low-severity because the volume was tiny.

Figure 5: The Wazuh dashboard shows relevant alerts

I also performed a few manual failed SSH attempts from Kali for extra log noise:

ssh root@192.168.1.173 -p 3521

(Then typed wrong passwords repeatedly.)

3. Scaling Up: The Real Attack with rockyou.txt

After fixing a couple of initial configuration hiccups (wrong IP, firewall rules), I went big.

Kali already ships with the famous rockyou.txt wordlist containing millions of real-world passwords. I launched the full attack with this command:

hydra -l root -P /usr/share/wordlists/rockyou.txt -s 3521 192.168.1.173 ssh -t 4

Figure 6: Insert screenshot of Hydra running here

Thousands of login attempts began hammering the Ubuntu server. Each failure was logged. /var/log/auth.log on Ubuntu with entries like:

authentication failure; rhost=192.168.1.XXX user=root

The Wazuh agent shipped these logs to the manager in real time.

Figure 7: Screenshot of the Wazuh log view

What Wazuh Saw: Live Detection in Action

While Hydra ran, I monitored the Wazuh dashboard:

• Switched to Explore then selected the wazuh-alerts- index.
• Filtered for SSH-related events from the Ubuntu agent.

Figure 8: Screenshot of Wazuh dashboard showing the alerts and filters you used

What stood out:

• Repeated failed logins from the same source IP (Kali).
• Same target username (root).
• Rapid frequency within a short time window.
• Alert severity increased as the attack continued.

Wazuh triggered Rule ID 2502: “syslog: User missed the password more than one time”

Key alert details included:

• Rule level: 10 (high severity)
• MITRE ATT&CK Technique: Brute Force
• Source IP, destination IP, port 3521, and targeted user are clearly visible.

As the attack scaled with the massive wordlist, Wazuh’s correlation engine connected the dots and escalated the alerts appropriately.

Results & Key Takeaways

Wazuh performed exactly as expected:

• It ingested SSH logs from /var/log/auth.log.
• It detected the pattern of repeated failed logins from a single source.
• It raised the alert level as the volume increased.
• It provided rich context (source IP, user, port, timestamp, MITRE mapping).

A small number of failures triggered only minor alerts. The full rockyou.txt attack produced clear brute-force detections.

Discussion: Strengths, Limitations, and Hardening Tips

Strengths of Wazuh in this scenario Wazuh turned noisy logs into meaningful security events. The dashboard made investigation intuitive, and the rule-based detection worked perfectly for this classic attack pattern.

Limitations & Possible Evasions

• Slowing down attempts (low-and-slow) could reduce severity.
• Using multiple source IPs or proxies could bypass single-IP correlation.
• Misconfigured agents or ports (as I experienced in my first attempt) can blind the system.

Practical Hardening Recommendations

• Enable Wazuh active response to automatically block offending IPs.
• Disable password authentication and enforce SSH key-only access.
• Change SSH from port 22 to a non-standard port (like I did with 3521).
• Disable direct root login.
• Use fail2ban or Wazuh’s built-in response capabilities as an extra layer.
• Always monitor with strong SIEM rules and keep agents updated.

Conclusion

This lab brought brute-force attacks out of theory and into my own virtual lab. I started with a tiny test, fixed my configuration mistakes, and then unleashed a realistic attack using rockyou.txt. Watching Wazuh detect and escalate the activity in real time was incredibly satisfying.

It reinforced a crucial lesson: logs are useless without proper monitoring. Wazuh transformed raw authentication failures into high-fidelity alerts with rich context, proving why SIEM/XDR platforms are essential in modern security operations.

If you run SSH services anywhere, this type of exercise is worth doing yourself. You’ll gain confidence in your detection capabilities and a deeper appreciation for proactive defense.

Reflection

Moving from reading about brute-force attacks to actually running one (safely) was eye-opening. The mistakes I made early on were wrong IP, firewall blocks, and a small wordlist, which taught me how fragile detection can be if the basics aren’t right.

Seeing Wazuh correlate hundreds of failures into a single coherent attack story made the power of SIEM click for me. It also reminded me that great detection is only half the battle; prevention (strong passwords, keys, restricted access) and automated response are what truly matter.

I’m now far more comfortable navigating Wazuh dashboards, filtering logs, and understanding how security tools turn noise into signals.

References

• Wazuh Documentation: https://documentation.wazuh.com/
• Hydra (thc-hydra): https://github.com/vanhauser-thc/thc-hydra
• OpenSSH Manual: https://www.openssh.com/manual.html