Detecting and Mitigating Brute Force Attacks (T1110)

Brute Force (T1110) is a credential access technique in MITRE ATT&CK. The platform list is long: containers, ESXi, IaaS, identity providers, Linux, macOS, network devices, Office suites, SaaS and Windows. If something has a login, it is in scope.

This is the parent technique. It has four sub-techniques, and each one has its own post in this series: password guessing, password cracking, password spraying and credential stuffing. This post covers what they share and the controls that cover all of them.

How attackers use it

MITRE describes brute force as gaining access to accounts when passwords are unknown or when password hashes have been obtained. The adversary systematically guesses the password using a repetitive or iterative mechanism. That guessing can happen in two places:

• Online, by interacting with a service that checks whether the credentials are valid.
• Offline, against previously acquired credential data such as password hashes.

It can occur at several points in a breach. MITRE gives these examples:

• Against valid accounts inside a victim environment, using knowledge gathered from other post-compromise behavior such as credential dumping, account discovery or password policy discovery.
• Combined with external remote services as part of initial access.

One more point is easy to miss. If an adversary guesses the correct password but is stopped by a location-based conditional access policy, they may change their infrastructure until it matches the victim's location and so bypass that policy. A correct password and a blocked login can therefore still mean a compromised account.

The four sub-techniques differ in where the guesses come from:

• Password guessing: trying passwords against an account with no prior knowledge.
• Password cracking: recovering plaintext from stolen hashes, usually offline.
• Password spraying: one or a few common passwords against many accounts.
• Credential stuffing: username and password pairs from breaches of unrelated services.

How to detect it

MITRE's strategy is Brute Force Authentication Failures with Multi-Platform Log Correlation. Its analytics are all variations of a few patterns:

• A high volume of failed logons followed by a successful one from a suspicious user, host or time window.
• Multiple authentication failures for valid or invalid users, followed by success from the same address or user.
• Password spraying or brute force across a pool of users within short intervals.
• Multiple failed authentications in unified logs on macOS, such as loginwindow or sshd.
• Excessive login attempts followed by success in SaaS apps such as Office 365 and file sharing services.

The key is the failure followed by success. Many failures alone are noise on any internet-facing login. A success after them is the event that matters.

Logs to collect:

• Windows Security events: 4625 for failed logon, 4624 for successful logon.
• Linux auth logs for sshd and PAM.
• Identity provider and SaaS sign-in logs, with source address, user agent and result.
• Network device authentication logs through syslog or TACACS+ accounting.

Build detections on three shapes: many failures for one account, a few failures for many accounts, and many different usernames from one source. Each maps to a different sub-technique. Also alert on any success that follows a cluster of failures from the same source.

How to reduce the risk

MITRE lists four mitigations that apply across the technique:

1. Account use policies. Set account lockout after a number of failed logins. MITRE warns that a policy that is too strict can create a denial of service condition, where accounts used in the attack are locked out. Pair lockout with conditional access policies that block logins from non-compliant devices or from outside defined organization IP ranges, and consider blocking risky authentication requests, such as those from anonymizing services or proxies.
2. Multi-factor authentication. Use MFA, and where possible enable it on externally facing services. A guessed password alone then does not open the door.
3. Password policies. Follow NIST guidelines when creating password policies.
4. User account management. Proactively reset accounts known to be part of breached credentials, either immediately or after detecting brute force attempts.

The order of impact for most teams is MFA first, then breached-credential resets, then lockout and conditional access tuned so they do not become a denial of service lever.

Check your own environment

Work through these questions:

• Which externally facing logins have no MFA?
• What is your lockout threshold, and could an attacker use it to lock out your staff?
• Are failed logons from all identity sources, including SaaS and network devices, in one searchable place?
• Do you alert on success after a burst of failures?
• Do you check new breach data against your accounts and reset matches?
• Are there default or shared credentials left on network devices or management interfaces?

Read-only commands:

# Windows (cmd): show the local lockout threshold and password policy
net accounts

# Windows (PowerShell): count recent failed logons (event 4625) in the Security log
(Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 500 -ErrorAction SilentlyContinue | Measure-Object).Count

# Linux (Debian or Ubuntu): recent failed SSH password attempts (RHEL family: use /var/log/secure)
sudo grep "Failed password" /var/log/auth.log | tail -n 20

A lockout threshold of 0 means no lockout, which is worth knowing even if you rely on MFA.

Quick check

Sources

• MITRE ATT&CK, Brute Force (T1110)