Cyber Triage Playbook | Brute Force Authentication

Download Playbook PDF

Playbook Download

Oops! Something went wrong while submitting the form.

What is the threat scenario?

A brute force alert typically indicates repeated failed login attempts to one or many valid accounts. The analytics that produces these alerts aims to identify attackers trying to guess the correct password for a valid account. Modern authentication systems generally employ controls to prevent or limit password guessing, which has greatly reduced the number of actual brute force attacks in the wild. However, the prevalence of leaked user passwords and the value of obtaining access to a valid account means adversaries are encouraged to try this technique.

MITRE ATT&CK Reference

What context should you gather?

Account(s) involved

Identify which accounts were trying to be logged into.

Source of the authentication attempts

Where did the authentication attempts come from? Often, this is either a remote source not associated with your organization, a workstation or server in your environment, or locally on a workstation or server.

Time period over which the login activity occurred

Over what period of time did the related authentication activity occur? It can be instructive to note duration and distribution of events, as well as time of day and day of week.

Type(s) of Authentication

There can be many types of authentication, particularly in a traditional Active Directory based environment. Some authentication events occur strictly between systems with no user interaction, while others are specifically initiated by a user each time. It's important to understand the type of authentication events you are observing to understand what a normal or abnormal volume of events looks like.

Number of authentication attempts

How many times was there a related authentication attempt? Often, this context will exist in the alert detail. It's also important to note if any attempts were successful.

What questions should you ask?

Does it seem reasonable that the source of authentication would be using this type of account(s)?
For example, a non-interactive login from a server using a regular user account could be unusual whereas a service account in the same situation would be very common.
Is the source of the authentication attempts a proxy, vpn or other network aggregator?
Proxies, VPN and other network aggregators can make it seem like many events are coming from the same source, when in reality, there are many true sources of this activity.
Has the account password changed, expired, or has the account been disabled recently?
It's typical to see a spike in authentication failure when one of these actions is taken on an account.
Does the account(s) have high privilege or belong to a person with elevated privilege?
These types of accounts are more valuable and worth protecting more closely than other types of accounts.

False Positive Scenarios

Password Change: There is typically a spike in regular user authentication failures around password change events.
Expired Password: When service account credentials expire, the system using that account will likely keep trying to authenticate until the asset owner applies new credentials. This activity is likely very periodic (for example, a new event every 5 minutes).
Bad Data: Some audit logs will capture erroneous login failures in cases where many authentication protocols are tried in a fixed order. You'll observe this when all failures are of the same authentication type and failures are followed by a successful authentication of a different type. An example would be a system configured to try domain authentication before falling back to local authentication.
Blocked Attempts: Authentication attempts from external sources to internet-facing systems (such as a web server or VPN) are very common. Most organizations don't consider this to be a threat unless any of the attempts are successful. Be careful, if you accept authentication attempts from a service like TOR, it could appear that many sessions are related when they are not.

Actions you could take

Contact the user or system owner to see if they have an explanation for the activity
Be careful if you are contacting someone who's regular user account was under attack. There is an unlikely, but possible, chance that a bad actor could impersonate that user in company chat or email tools.
Require a user to change their password
If there was any successful login, having the user change their password can either indicate a real compromise and/or serve to protect the account.
In cases where there is reason to believe an account has been compromised, follow your incident response plan
In many cases, acting too quickly to block an attacker before understanding the whole situation can lead to worse outcomes.

Last Update

January 11, 2024

Brute Force Authentication

A cyber alert triage playbook with insights from former cyber analysts who have lived this pain