Brute Force Access Behavior Detected Over One Day - Against Category

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.

Content Mapping

This content is not mapped to any local saved search. Add mapping


Use Case

Compliance

Category

GDPR, Zero Trust

Alert Volume

Low

SPL Difficulty

Medium

Data Availability

Bad

Journey

Stage 4

MITRE ATT&CK Tactics

Credential Access
Privilege Escalation

MITRE ATT&CK Techniques

Brute Force
Valid Accounts

MITRE Threat Groups

Chimera
APT39
FIN5
FIN4
FIN10
Soft Cell
Night Dragon
TEMP.Veles
Turla
Leviathan
Dragonfly 2.0
Wizard Spider
OilRig
APT41
Suckfly
DarkVishnya
Silence
FIN6
Threat Group-3390
APT18
menuPass
APT28
Sandworm Team
PittyTiger
Carbanak
FIN8
APT33

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