Snort local rule to detect slow-rate Hydra attacks

Overview

This project is the one that I presented as a final project for my degree in MSc Cyber Security.
Slow-rate brute force attacks represent a genuine challenge for network intrusion detection systems: by reducing connection frequency, an attacker can operate below the threshold of signature-based rules while still systematically enumerating credentials. This project investigates that evasion technique in a controlled lab environment, using Hydra as the attack tool and Snort 2.9 as the IDS.
The core research question was simple: can a custom Snort local rule reliably detect a Hydra SSH brute force attack — and at what point does slowing the attack rate allow it to evade detection entirely?
Three virtual machines were configured to simulate a realistic scenario: an Ubuntu target running SSH and Snort, a Kali attacker running Hydra, and a second Kali machine generating legitimate SSH traffic to test for false positives. The experiment iterated through multiple rule configurations, measuring detection rate against attack speed and false positive rate — arriving at a threshold-based rule that balances sensitivity with operational viability.

Languages and Utilities Used

- OpenSSH 3.0.13 - Snort 2.9.20 - Bash - Hydra Brute Force

Environments Used

- Oracle VM Virtual Box 7.0 - Ubuntu 24.04 LTS - Kali Linux 2023.1

Program walk-through:

Before launching Snort I needed to configure some parameters in the file etc/snort/snort.conf, such as network adapter and IP range addresses. When Snort is launched, any alert will be printed to the console. For ease of use, I created a script that launches snort, redirects the output to the text file snortlog.txt, and once I interrupt the execution of snort, the command WC -l snortlog.txt will print in the console the number of lines generated (a.k.a detections).

Then I created two text files with ten usernames and ten passwords to be used with the Hydra attack


Without launching Snort, I just ran a hydra attack as a test to ensure the attack would succeed. Hydra -L users.txt -P password.txt ssh://10.0.2.12 -t 8

After starting Snort, I performed the same attack, but Snort did not detect any attacks. Unsure if the number of combinations and the pace of the attack would be enough to be detected, I increased the number of combinations to 400 and set the flag -T 20 to perform 20 simultaneous threads.
Here is the local rule that I implemented in an attempt to detect the attack:
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg: "Possible SSH brute forcing!" ;\ flags: 5+; threshold: type both, track by_src, count 5, seconds 30; sid:1000002; rev: 1;) [Reference](https://stackoverflow.com/questions/47742405/using-snort-suricata-i-want-to-generate-an-ssh-alert-for-every-failed-login-to) This rule focuses on the number of inbound connections from the same source that are asking for a TCP connection to the SSH port 22. If more than five connection attempts in 30 seconds are detected, it will send a single alert.

With the local rules, Snort created one alert at a maximum once every 30, generating only 5 alerts while the brute force was running.

So, I proceeded to eliminate the threshold parameters, and out of 420 attacks from Hydra, Snort created 169 alerts, which equals 40.2% of the total attacks.

So far, I have not considered the possibility of false positives. Without the threshold parameters, Snort could likely send an alert for a legitimate login attempt.
Therefore, I repeated the experiment, and from a third VM, I created an SSH connection three times, pretending to be a legitimate user. The result is that Snort created three extra alerts, and inspecting the log file, I could find the three legitimate connections. I concluded that the local rule would not be viable without the threshold parameter.

To eliminate false positives, I reintegrated the parameter threshold: this time, the count of attempted connections is three instead of 5, and the time span is 3 seconds instead of 30. The idea is still to receive a certain number of alerts without the false positives.
The new rules generated fewer alerts, 25, due to the threshold parameters, but they did not generate any false positives against the five SSH legitimate connections I executed.

### Avoid detection hydra -L users.txt -P password.txt ssh://10.0.2.12 -t 4 And Failed

hydra -L users.txt -P password.txt ssh://10.0.2.12 -t 2

Was detected only once

hydra -L users.txt -P password.txt ssh://10.0.2.12 -t 1

The previous attack was not detected by Snort

### Adapting the local rules I tested the local rule, increasing the period for detection to 10, 15, 30 and 60 seconds.
With 60 seconds period for detection, Snort was able to send 6 alerts for the attack.

### Analysis and Evaluation Increasing the time span of the threshold parameters helps in detecting the brute force attack, but is also prone to false positives. Giving more time to do three attempts from the same source could easily create false positives. But here is the thing: the dictionary files of brute force attacks contain thousands and thousands of entries that, combined with a few users' names, can create combinations in the order of hundreds of thousands. If a malicious actor wants to perform a brute force attack, performing an attempt every 5 seconds would take a long time to succeed, so much that it would act as a deterrent.
Another consideration is that I used Snort exclusively in IDS mode (detection) and not in IPS mode (prevention). The prevention mode may have some rule that may drop packets and close connections when certain requirements are met. Furthermore, in a secured system there is not only a network intrusion detection system but many other tools that together complete each other. One example is the firewall, that in the case of experiment could have picked up the fast and massive attempts of Hydra in the first stage of the experiments.