Brute Force Access Behavior Detected Over One Day - Against Category

Description

Monitor your security controls and prove your GDPR compliance by detecting slow and low brute force (or password guessing) attacks on GDPR-tagged systems that occur gradually over the day.


Use Case

Compliance

Category

GDPR

Alert Volume

Low (?)

SPL Difficulty

Medium

Journey

Stage 4

MITRE ATT&CK Tactics

Credential Access
Privilege Escalation

MITRE ATT&CK Techniques

Brute Force
Valid Accounts

MITRE Threat Groups

APT18
APT28
APT3
APT32
APT33
APT39
APT41
Carbanak
Dragonfly 2.0
FIN10
FIN4
FIN5
FIN6
FIN8
Lazarus Group
Leafminer
Leviathan
Night Dragon
OilRig
PittyTiger
Soft Cell
Stolen Pencil
Suckfly
TEMP.Veles
Threat Group-1314
Threat Group-3390
Turla
menuPass

Data Sources

Windows Security
Authentication

   GDPR Relevance

Problem:

Attackers leverage brute-force authentication attempts to bypass weak cryptographic standards, or to exploit infrastructure or applications where password best practices are not consistently applied.

Impact:

Brute force access is a common attack vector. Under the GDPR, monitoring and demonstrating that security controls are effective is required by Article 32, therefore immediate awareness of any brute force attempts is critical to maintaining compliance posture. Demonstrating that any such attempts have not been successful will help to prove compliance for data privacy audits initiated by data privacy authorities (Article 58) and also help counteract compensation claims (Article 82).

Resolution Path:

Identify GDPR-relevant resources and systems and monitor for a large number of authentication failures within a short time period, on any of those resources or systems. It is important to adjust for the scenario where a single source (such as a web app) might centralize the authentication for a large number of users, to reduce false positives.

   How to Implement

If you have followed the data onboarding guides in this app, this search will work immediately for you. You should generally specify the index where you are storing Windows Security logs (e.g., index=oswinsec), and if you use a mechanism other than the Splunk Universal Forwarder to onboard that data, you should verify the sourcetype and fields that are used. The rest is simple!

   Known False Positives

The only known scenario where this search could generate false positives is if you have a single source (for example, a web app) that centralizes the authentication for many people. In that scenario, you might need to adjust thresholds for that source, or exclude it and build a separate similar search just using the logs from that host.

   How To Respond

When this search fires, the immediate concern is that the brute force search was successful. See if it is coming from a host that typically logs in with that account to make sure it is not just coincidental, and then reset the password for any compromised accounts and look for any other places where that username was used.

   Help

Brute Force Access Behavior Detected Over One Day - Against Category Help

This example leverages the Simple Search assistant. Our example dataset is a collection of anonymized Windows Authentication logs, during which someone attempts a brute force against a series of usernames. Our live search looks for Windows Authentication activity across any index in the standard sourcetype.

SPL for Brute Force Access Behavior Detected Over One Day - Against Category

Demo Data

First we bring in our basic demo dataset. In this case, Windows logs. We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data.
Next we look up the host in the GDPR categorization lookup. Because we only care about GDPR hosts for this example, we filter for only the hosts that are in scope for GDPR.
Bucket (aliased to bin) allows us to group events based on _time, effectively flattening the actual _time value to the same hour.
Next we use the magic of stats+eval to count how many events there are where the action is success, or the action is failure
Finally we filter for where there is at least one success, and more than 100 failures.

Live Data

First we bring in our basic dataset. In this case, Windows logs.
Next we use the magic of stats+eval to count how many events there are where the action is success, or the action is failure
Finally we filter for where there is at least one success, and more than 100 failures.
Next we look up the host in the GDPR categorization lookup. Because we only care about GDPR hosts for this example, we filter for only the hosts that are in scope for GDPR.

Screenshot of Demo Data