Ready to Start Your Career?

Reduce Authentication Alert Fatigue In Your Kibana Logs

Owen Dubiel's profile image

By: Owen Dubiel

June 28, 2021

Authentication events can be confusing when you start receiving alerts for them, especially failed logins. Sometimes it can be hard to wrap your head around the idea of what a malicious actor would look like attempting a password spray attack on your network or a compromised account trying to move laterally. This article will look closely at what some of those use cases look like and dig into how you can implement a detection within your Kibana Logs.

Considerations when tuning authentication events

Authentication events can be the noisiest and confusing to determine legitimacy. Many factors come into play. Below we will review some of the most famous figures to figure out how to reduce overall false-positive results.

Consider the Password Policy

Understanding the company's password policies help to set specific thresholds on alerts. For example, if the password lockout policy is three failed attempts, it would be silly to create a detection rule that only triggers after five within a given timeframe. Another item to consider would be the password reset timeframe. For example, if users are forced to change theirs every 90 days, you can build in this logic to only alert if the last known password change was less than 90 days prior.

Do you have an MFA enforced?

Multi-factor Authentication is essential, but it adds to the confusion within your Kibana logs if not adequately ingested. A great example is the difference between a failed login attempt and a failed challenge attempt (Yubi-key or push notification). By default, these all may be treated as failed login attempts with Kibana. By adding logic to your alerting to separate the two events, will you add clarity to what is going on?

Another example is by ensuring your geo-location data is correct. Some MFA providers, like Okta, allow you to attach location data with each event. It is crucial to understand if the circumstances are triggering from the user location or centralized to wherever "home base" is for your corporation.

Create Multiple rules to map the timeline of events

Another pro tip to better map out authentication-related events is to create multiple rules with simplistic scopes and small timeframes. For example, create one alert that detects only when a password spray attack is in progress. Then you can create a rule to identify all accounts that have had recent failed login attempts. Lastly, you would have another alert for any account logged into from that same source and within a given timeframe of the password spray attack. By taking on this approach, you are painting a picture of what a successful attack looks like and limiting your team's overall investigation time. Once the third rule is triggered, only then is it when you should have a human dig into the events.

Kibana search query

The following search query can be used directly in Kibana and should be a great starting point for detecting multiple failed logins from different accounts on a single source system. This search would work as a tremendous 3rd alert as described above and should result in an investigation along with some password resets of affected accounts at a minimum.

[ { "_id": "Multiple-Failed-Logins-with-Different-Accounts-from-Single-Source-System", "_type": "search", "_source": { "title": "Sigma: Multiple Failed Logins with Different Accounts from Single Source System," "description": "Detects suspicious failed logins with different user accounts from a single source system Author: .", "hits": 0, "columns": [], "sort": [ "@timestamp", "desc" ], "version": 1, "kibanaSavedObjectMeta": { "searchSourceJSON": "{"index": "winlogbeat-", "filter": [], "highlight": {"pre_tags": ["@kibana-highlighted-field@"], "post_tags": ["@/kibana-highlighted-field@"], "fields": {"": {}}, "require_field_match": false, "fragment_size": 2147483647}, "query": {"query_string": {"query": "(pam_message:\"authentication\\ failure\" AND pam_user:\"not\\ null\" AND pam_rhost:\"not\\ null\")", "analyze_wildcard": true}}}" } } } ]


Ingesting authentication event logs into Kibana is only the first step; proper tuning needs to happen regularly to ensure false positives remain at a minimum. The possibilities are endless on how and when you alert. To learn more about SIEM tuning or how to identify web attacks, check out the resources provided by Cybrary to capitalize and optimize your SIEM solution today fully.

Schedule Demo