Example of how to detect basic brute force attacks?

[adukes_splunk]

Does anyone have examples of how to use Splunk to detect basic brute force attacks?

[adukes_splunk · Accepted solution]

The Splunk Product Best Practices team helped produce this response. Read more about example use cases in the Splunk Platform Use Cases manual.

For more information on this and other examples, download the free Splunk Security Essentials app on Splunkbase.

Discovering real credentials is a key component for any attacker. A time-honored way to find weak passwords is to try hundreds of common passwords. This is effective because most environments use Active Directory as a central storage repository for credentials. It’s important to include a search for brute force activity in Windows Security logs as a component of any security strategy.

This use case is from the Splunk Security Essentials app. Check it out for more examples and demo data for this type of use case.

Load Data

This use case depends security data from Windows, Unix and Linux, or any data properly tagged for authentication. While only one data source is required to get insights, collecting multiple data sources provides a more comprehensive view of the environment's security.

Best practice: Use the Splunk Add-on for Microsoft Windows to accelerate time to value with Windows data. For details, see Is it a best practice to use the Splunk Add-on for Microsoft Windows? on Splunk Answers.

1. Enable the [WinEventLog://Security] input in the add-on to collect Windows security data. For details, see How do I collect basic Windows OS Event Log data from my Windows systems? on Splunk Answers.
2. Deploy the add-on to the search heads to use the Common Information Model to normalize the data at search time. See Install the Splunk Add-on for Windows in Splunk documents for the procedure.
3. Run the following search to verify you are collecting Windows data: earliest=-1day index=* source=win*security tag=authentication user=* src=* | head 10

Best practice: Use the Splunk Add-on for Unix and Linux to accelerate time to value with Unix and Linux data.

1. Enable the [monitor:///var/log] input in the add-on to collect the Linux security data. See Enable data and scripted inputs for the Splunk Add-on for Unix and Linux in Splunk docs for the procedure.
2. Give Splunk permission to read the /var/log/secure file to allow Splunk to monitor the Linux secure data. For details, see Which UNIX permissions are best for monitoring files? on Splunk Answers.
3. Deploy the add-on to the search heads to use the Common Information Model to normalize the data at search time. See Install the Splunk Add-on for Unix and Linux in Splunk docs for the procedure.
4. Run the following search to verify you are collecting Unix and Linux data: earliest=-1day index=* sourcetype=linux_secure tag=authentication user=* src=*| head 10

Best practice: Since Splunk normalizes values from multiple source types regardless of source or format, it’s a best practice to make sure your data is CIM-compliant. For more information about CIM and the Splunk Common Information Model (CIM) add-on see the Splunk Common Information Model Add-on Manual. Run the following search to verify you are searching for normalized authentication data and ready for this use case: earliest=-1day index=* tag=authentication user=* src=* | head 10

Get Insights

The examples below use a simple threshold for Security logs to alert if there are a large number of failed logins, and at least one successful login from the same source.

Best practice: In searches, replace the asterisk in index=* with name of the index that contains the data. By default, Splunk stores data in the main index. Therefore, index=* becomes index=main. Use the OR operator to specify one or multiple indexes to search. For example, index=main OR index=security. See About managing indexes and How indexing works in Splunk docs for details.

Top Users Failing Authentication

index=* action=fail* OR action=block* (source=win*security OR sourcetype=linux_secure OR tag=authentication) user=* user!=""
| bucket _time span=1d
| stats count by user src _time
| stats sum(count) as count by user
| sort - count

Top Sources Failing Authentication

index=* action=fail* OR action=block* (source=win*security OR sourcetype=linux_secure OR tag=authentication) user=* user!=""
| bucket _time span=1d
| stats count by user src _time
| stats sum(count) as count by src
| sort - count

Failed Authentications Over Time

index=* action=fail* OR action=block* (source=win*security OR sourcetype=linux_secure OR tag=authentication) user=* user!=""
| bucket _time span=1d
| stats count by user src _time
| timechart span=1d sum(count) as count

Users with Persistent Failed Authentication

index=* (source=win*security OR sourcetype=linux_secure OR tag=authentication) user=* user!=""
| stats count(eval(action="success")) as successes count(eval(action="failure")) as failures by user
| eval perc_failures_to_total = round((100*failures) / (failures + successes), 2)
| sort - perc_failures_to_total failures

How to respond: When this search fires, you can assume that a 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, then reset the password for compromised accounts and look for other places where that username was used.

Known false positives: The only known scenario where this search generates false positives is if a single source, such as a web app, that centralizes the authentication for many people. In that scenario, consider adjusting thresholds for that source, or exclude it and build a separate similar search just using the logs from that host.

If no results appear, you may need to deploy the add-ons to the search heads to use the knowledge objects necessary for simple searching.

[adukes_splunk]

Added related video.