SIEM 102 — Detect Windows bruteforce

In this post I’ll explain how to detect a bruteforce on Windows. This is a simple case so it’s a good use case to start learning to create alerts.

Note: In this post I use Logz.io for my examples, but I recently switched to Humio. For more details: https://www.tristandostaler.com/why-i-switched-from-logz-io-to-humio/

---

For this post, I assume you’ve read my SIEM 100 series where I explain the basics of Logz.io. I’ll be using the stack I created in this series to demonstrate what to do.

---

Why we need to detect Windows bruteforce

When we have a lot of Windows machine in our environment, it can be useful to be able to detect a bruteforce on a machine, be it over RDP or not. For example, with this Use Case, we could detect an attacker trying to login on a sensitive computer or trying to pivot between machine.

This Use Case is really simple so it’s rather easy to develop and test. But it’s also prone to false positive, so it’s a good Use Case to learn to reduce the false positives.

How

As I explained, this use case is really really simple. We’ll send an email if the event for a failed logon is triggered at least 5 times in a 5 minutes period. The Event ID for a failed logon in Windows is 4625 so the query is pretty simple: event.code: 4625. When creating the alert, we simply need to Group by beat_agent.hostname and winlog.event_data.TargetUserName and check if the number of logs in the last 5 minutes is ≥ than 5.

The group by beat_agent.hostname is necessary because if we have more than 1 Windows in our SIEM, as soon as 5 computers or less do 5 failed logon in the same 5 minutes block, the alert would trigger, and this is not a bruteforce and happens pretty often. The group by winlog.event_data.TargetUserName is necessary if you have some user that connects from time to time to different machines. If you were to not group by winlog.event_data.TargetUserName, you would detect a password spray attack which is an interesting Use Case but it’s not the purpose of this post.

For the sensitivity (5 failed logon in 5 minutes), I’ll explain how we can tweak it and reduce the false positive later in this post.

For the next part, head over to Logz.io and login to your account.

In practice

The first thing to do is simulate a bruteforce.

If you don’t have winrm enable on your computer, like it was the case for my test machine, open a PowerShell window as Administrator, and enter the following command:

Enable-PSRemoting -SkipNetworkProfileCheck -Force
Set-Item wsman:\localhost\Client\TrustedHosts -Value * -Force
Restart-Service WinRM

Next, enter this command to generate 5 failed logon on your computer:

[pscredential]$credObject = New-Object System.Management.Automation.PSCredential ("Non existent", (ConvertTo-SecureString "Bad password" -AsPlainText -Force))
for ($i=0; $i -lt 5; $i++) { Enter-PSSession -ComputerName localhost -Credential $credObject }

Now in Kibana, search the query:

event.code: 4625

You can add the following fields as columns: winlog.event_data.TargetUserName and beat_agent.hostname. You will get something similar to this:

Now click on Create alert and enter the alert name “Windows bruteforce”.

In the Group by field, add winlog.event_data.TargetUserName and beat_agent.hostname.

In the “Trigger if” section, change the values to match the following image:

In the Notify section, add your email and then save your new alert.

Managing false positives

When we first create this alert, the level of false positive we’ll receive is directly proportional to the size of the environment. The more Windows machines we have linked to the SIEM (inherently linked to the number of users) , the more likely false positives will arise.

There are a few strategies we can use to reduce the level of false positives:

1. We can reduce the sensitivity. Increase the threshold by reducing the time frame we look at, or increase the number of failed attempt.
2. Exclude some users from this specific alert and create a new alert less sensitive for these users.
3. Look only at bruteforce over RDP (query: “winlog.event_data.LogonType: 10”). And/or only at bruteforce over the nerwork (like in this example) (query: “winlog.event_data.LogonType: 3”). By doing this, we won’t alert when someone fails to enter his password on his own computer, which is the most frequent case of false positive we would get.
4. Whatever fits your environment. When creating an alert, it’s important to be creative and understand the usage patterns in our environments to reduce the level of false positive.

Note: you can see the logon types here: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4624y

Edit: since I originally wrote this post, I found better ways to minimize False Positives. I summed them up in this post: https://www.tristandostaler.com/siem-103-detect-windows-bruteforce-part-2/

Conclusion

That’s it, you can now detect a Windows bruteforce and know how to manage false positives!

Feel free to leave your comment down here for any questions or comments.