Day 2: Brute Force Simulation with Hydra – Detection Engineering in Action

I wanted to simulate a realistic attack that a SOC analyst would actually deal with. Brute force attacks are one of the most common entry points, so that is where I started.

Brute Force Simulation with Hydra

I enabled RDP on the Windows Desktop machine and created a test account:

• Username: testuser
• Password: Password123

This was done intentionally so I could safely simulate a compromise without affecting anything important.

To make sure Windows actually logged failed login attempts, I enabled auditing using auditpol. Without this step, you are essentially blind to authentication attacks.

There was also an issue with Network Level Authentication blocking the attack. I disabled the UserAuthentication requirement on the RDP service to allow Hydra to connect properly.

From Kali, I launched Hydra targeting the testuser account over RDP using the rockyou wordlist. This list contains millions of real passwords from past data breaches, which makes the attack far more realistic.

At this point, I was no longer just scanning. I was actively trying to break into a system.

Incident #002: Brute Force to Compromise

The logs started filling up immediately.

In Wazuh, I observed a clear sequence of events:

• Five failed logins within about 12 seconds
• A couple of logoff events
• Then a successful login

This pattern is exactly what you expect from an automated brute force attack that eventually guesses the correct password.

Triage conclusion: True Positive, High Severity

The key insight here is simple but important. Failed logins on their own are not enough to panic. They happen all the time. But when you see multiple rapid failures followed by a success, that is a strong signal of compromise.

This became Incident #002.

In plain terms, the system watched someone repeatedly try the door and then successfully get in. That is not normal behaviour. That is an attacker succeeding.

Writing My First Custom Detection Rule

Up until now, I was relying on default Wazuh rules. That is useful, but real SOC work goes further. You need to build your own detections based on patterns you care about.

I created my first custom rule:

• Trigger condition: 5 or more failed logon alerts
• Time window: 120 seconds
• Source: same origin
• Severity: Level 12
• MITRE mapping: T1110 (Brute Force)

I added the rule to:
/var/ossec/etc/rules/local_rules.xml

Then restarted the Wazuh manager to load it.

This was a big moment. Instead of just reacting to alerts, I started shaping how the system detects threats.

Incident #003: Validating the Detection

To test the rule, I ran the Hydra attack again.

This time, something different happened.

My custom rule fired multiple times at high severity, exactly as designed. On top of that, I saw a new alert:

• Rule 60115 indicating the account was locked out

Windows had automatically locked the testuser account after too many failed attempts.

Triage conclusion: True Positive, Immediate Escalation

This was the full chain in action:

• Attack begins
• Detection triggers
• System enforces protection

That is what a real defensive workflow looks like.

What I Learned Today

Brute force attacks are noisy but predictable. The real signal is in the pattern, not the individual events.

Logging matters more than tools. If auditing is not enabled, none of this gets detected.

Default rules are a starting point, not the finish line. Writing custom detections is where things get interesting.

Validation is critical. A rule that is not tested is not reliable.

Windows defensive mechanisms like account lockout are part of the story. Detection and prevention often work together.

Final Thoughts

Today was the first time I felt like I was doing actual detection engineering.

I simulated a real attack, confirmed the alert chain, built a custom rule, and validated it end to end. More importantly, I started thinking less like someone running tools and more like someone responsible for catching attackers.

Next step is to expand beyond brute force. I want to look at lateral movement or exploitation on Metasploitable and see how those behaviours show up in logs.

Day 2 felt less like setup and more like real SOC work.