MITRE ATT&CK T1110 Brute Force: Defender's Guide

Brute force is the oldest credential attack and still one of the most successful, because every internet-facing login, legacy protocol and forgotten test account is a place to guess. MITRE ATT&CK T1110 Brute Force, in the Credential Access tactic (TA0006), covers four sub-techniques: Password Guessing, Password Cracking, Password Spraying and Credential Stuffing. ATT&CK lists it across Windows, Linux, macOS, identity providers, SaaS, IaaS, containers, ESXi, network devices and office suites, which makes it one of the broadest techniques in the matrix. This guide gives defenders the technique-level picture: what distinguishes the sub-techniques, where to see them in logs, the controls ATT&CK and NIST SP 800-63B recommend, and how to roll those controls out without locking out the business. It is for identity, SOC and platform teams. It contains no attack tooling or procedures.

Key takeaways

Four sub-techniques, two defences each. Online guessing, spraying and stuffing are stopped by MFA and rate limiting; offline cracking is stopped only by long, unique passwords and by keeping hashes out of reach.
Lockout alone is not a strategy. Spraying stays under per-account thresholds, and strict lockout becomes a denial of service; ATT&CK itself warns that too strict a policy can make environments unusable.
Detect across accounts, not per account. The signature of spraying is many accounts failing once or twice from one source or one password, not one account failing many times.
Legacy protocols are the soft spot. Authentication paths that cannot do MFA, such as basic authentication, older mail protocols, LDAP and Kerberos pre-authentication, are where sprays succeed and where ATT&CK notes alerts are less likely.
Non-human and forgotten accounts are prime targets. Service accounts excluded from MFA and lockout, and test accounts nobody owns, are how spraying turned into a major breach at Microsoft in 2024.

How the technique works

ATT&CK describes T1110 as gaining access to accounts when passwords are unknown or when hashes have been obtained, by systematically guessing either against a live service or offline against captured credential data. The four sub-techniques differ in where the guessing happens and what the attacker already holds:

Sub-technique	Where guessing happens	Attacker starts with	Typical pattern	Strongest control
T1110.001 Password Guessing	Online, against a login service	Usernames, common or default passwords	Many attempts against one or a few accounts	MFA, rate limiting, removing default credentials
T1110.002 Password Cracking	Offline, on attacker hardware	Password hashes or Kerberos material from a prior compromise	Invisible to the victim until credentials are used	Long random passwords, strong hashing, protecting hash stores
T1110.003 Password Spraying	Online, across many accounts	A list of valid usernames and a few common passwords	One password tried against many accounts, slowly, to avoid lockout	MFA everywhere, banned password lists, cross-account detection
T1110.004 Credential Stuffing	Online, across many accounts	Username and password pairs from unrelated breaches	High-volume automated attempts, often from residential proxies	MFA, breached password screening, bot defence

ATT&CK lists the services commonly targeted by spraying: SSH (22/TCP), Telnet (23/TCP), FTP (21/TCP), SMB (139 and 445/TCP), LDAP (389/TCP), Kerberos (88/TCP), RDP (3389/TCP), HTTP management services (80 and 443/TCP), MSSQL (1433/TCP), Oracle (1521/TCP), MySQL (3306/TCP) and VNC (5900/TCP), plus SSO and cloud applications using federated authentication and externally facing email. It also notes that attackers who guess a password but are blocked by location-based conditional access may change infrastructure to match the victim's location, so location rules are a speed bump, not a defence.

Where it shows up

State and criminal groups: ATT&CK v20 records password spraying by groups including HAFNIUM, APT29, APT33 and Lazarus Group, and password guessing by APT28, APT29 and Salt Typhoon. It is a staple initial access step, and a post-compromise step after password policy discovery (T1201) or account discovery (T1087).
Cloud tenants: in the Microsoft Midnight Blizzard Breach, a password spray against a legacy, non-production test tenant account without MFA gave the attacker a foothold, which it extended through a legacy OAuth application to read corporate mailboxes.
Consumer platforms: in the 23andMe Breach, credential stuffing with reused passwords opened more than 18,000 accounts, and features that shared data between accounts extended the exposure to almost 7 million people.
Exposed infrastructure: RDP, SSH, VPN portals and management interfaces of network devices and hypervisors face constant guessing. See the Remote Desktop (RDP) Security Guide.

Detection

ATT&CK's detection strategy for T1110 correlates authentication failures across platforms: on Windows, a high volume of failed logons followed by a success from a suspicious user, host or timeframe; on Linux, multiple failures for valid or invalid users followed by success from the same address or user; on identity providers, spraying across the user pool in short intervals; on SaaS, excessive attempts followed by success.

Source	Events or fields	What to look for
Windows DCs, Kerberos	4771 with failure code 0x18 (wrong password); 4768 with result 0x6 (unknown user)	Many accounts failing pre-authentication from one client address; bursts of unknown usernames (enumeration)
Windows DCs, NTLM	4776 with error codes; NTLM operational 8004	Failures across many accounts from one workstation name; NTLM use from unexpected sources
Windows hosts	4625 failed logon (logon type 3 network, 10 remote interactive); 4740 account locked out	RDP and SMB guessing; lockout waves across many users
Entra ID and other IdPs	Sign-in logs: failure reason, client app, user agent, IP, smart lockout results	One IP or ASN failing for many users; legacy client apps; success after many failures
Linux and network devices	sshd authentication failures in auth logs or the journal; device AAA logs	Failures for invalid users; success after a failure run from the same address
Web applications and APIs	Login endpoint access logs and application auth events	Request rates, distinct usernames per IP, failure ratios, credential stuffing via residential proxies

Useful detection logic for spraying is two-dimensional: count distinct accounts failing per source (IP, ASN, workstation) and distinct sources per failing password hash where the platform exposes it, over windows long enough (hours, not minutes) to catch throttled sprays. Always pair failure rules with "success after failures" rules, because the success is the incident. Platform detail is in the Entra ID Sign-In and Audit Log Detection Guide, the Okta System Log Detection Guide and the Active Directory Security Monitoring and Event IDs Guide.

Mitigations and how to apply them

ATT&CK mitigation	Sub-techniques	Practical control
M1032 Multi-factor Authentication	All four	MFA on every externally reachable login, and block authentication paths that cannot perform it. Phishing-resistant methods also stop stolen passwords from being replayed. See the MFA Guide.
M1036 Account Use Policies	.001, .003, .004	Lockout or throttling after failed attempts, balanced against denial of service. NIST SP 800-63B (SP 800-63-4 suite) requires verifiers to limit consecutive failed attempts on one authenticator to no more than 100.
M1027 Password Policies	All four	NIST SP 800-63B requires checking passwords against a blocklist of common, expected and compromised values, a minimum of 15 characters for single-factor passwords and 8 when used within MFA, and no other composition rules. See the Password Policy Guide (NIST-aligned).
M1018 User Account Management	.004	Reset accounts known to appear in breached credential sets, immediately or after brute-force activity is detected.
M1051 Update Software	.001	Upgrade management services to versions that enforce stronger password policy and remove default or weak credentials.

For Password Cracking, the controls sit elsewhere: prevent the theft of hashes (OS credential dumping, T1003), remove RC4 from Kerberos so captured tickets are harder to crack, and give service accounts long random passwords or managed identities. The MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide covers the Kerberos side.

Lockout settings that work together

In hybrid estates the cloud and directory lockout policies interact. Microsoft Entra smart lockout locks an account for 60 seconds after 10 failed attempts by default (3 in Azure US Government tenants), keeps separate counters for familiar and unfamiliar locations, and ignores repeats of the last three bad password hashes. With password hash sync or pass-through authentication, Microsoft advises setting the Entra threshold lower than the AD DS threshold (ideally AD DS at two or three times the Entra value) and the Entra duration longer than the AD DS duration, so cloud lockout triggers first and attackers cannot lock out on-premises accounts through the cloud. Customising smart lockout requires Entra ID P1. The Account Lockout and Brute-Force Protection Guide gives platform-by-platform settings.

Rolling out brute-force defences

Map every authentication surface: IdP sign-in, VPN, RDP gateways, SSH, OWA and mail protocols, web application logins, APIs, admin consoles of network devices and hypervisors. Mark which support MFA and which do not.
Turn on telemetry first: collect the events in the detection table into the SIEM and run spraying and stuffing rules in report-only mode for two weeks to learn the baseline of failed sign-ins.
Close legacy authentication: identify use of basic and legacy protocols from sign-in logs, migrate the remaining clients, then block legacy authentication with a conditional access policy in report-only mode before enforcement. Roll back by excluding a named group, not by disabling the policy. See the Conditional Access Guide.
Enforce MFA in rings: administrators first, then all users on external access, then internal access. Keep emergency access accounts excluded, monitored and protected with phishing-resistant credentials.
Deploy banned and breached password screening: enable the IdP's banned password list, extend it to on-premises directories, and add custom terms (company, product and location names).
Tune lockout and throttling: align cloud and directory thresholds, add progressive delays or bot challenges on web logins, and test that a spray against a test OU locks no real accounts.
Remove exposure: take RDP, SSH and management interfaces off the internet or behind a VPN or broker with MFA.
Test and repeat: run authorised spray simulations against test accounts quarterly and confirm alerts fire and lockouts behave as designed.

Responding when a guess succeeds

Scope the spray: list every account that failed from the attacking sources, and every account that then succeeded from them or from related infrastructure.
Reset and revoke: force password resets for accounts with successful sign-ins, revoke their refresh tokens and sessions, and review MFA methods registered after the success, a common persistence step.
Check what followed: look for mailbox rules, OAuth consent grants, new app credentials and role assignments made by the compromised accounts.
Close the gap that let it work: the successful account usually reveals a missing MFA policy, a legacy protocol or an unowned account; fix that class of gap, not just the account.
Block and share: block the sources at the IdP and edge, and add the observed passwords to the custom banned list.

Where identity fits: service accounts and NHIs

Brute force increasingly lands on accounts that are not people. Service accounts are often excluded from MFA and lockout so that applications do not break, which makes them ideal spraying targets; test and legacy accounts are left without owners; and API keys or tokens with low entropy can be guessed against APIs that lack rate limits. Controls: give service accounts long random passwords or replace them with managed identities and gMSAs, block interactive and external sign-in for them with conditional access or logon restrictions, rate-limit API authentication endpoints (OWASP ASVS 5.0 V6.3.1 requires controls against credential stuffing and brute force), and disable unowned test accounts. See the Service Account Security Guide.

Decision guidance

Lockout or throttling: use throttling and progressive delays on customer-facing logins where lockout would let attackers deny service to customers; use lockout with short durations for workforce accounts, combined with smart lockout or familiar-location logic.
Small organisations: the highest-value steps are MFA on all external access, blocking legacy authentication and removing internet-exposed RDP. Built-in IdP protections then handle most volume.
Large organisations and consumer platforms: add bot management on web logins, breached password screening at sign-up and change, cross-platform correlation in the SIEM and automated response that forces resets for accounts with successful logins after spray activity.
Accounts that cannot use MFA: restrict them by network location and source host, give them long random passwords, and alert on any failed authentication.

Measuring effectiveness

Percentage of sign-ins using legacy authentication, trending to zero.
Percentage of accounts, including service and test accounts, covered by MFA or compensating network restrictions.
Successful sign-ins following spray or stuffing activity per month, and time to reset those accounts.
Lockout events affecting legitimate users per month (a rising number signals denial of service or mistuned thresholds).
Internet-exposed RDP, SSH and management interfaces found by external scanning (target zero).
Passwords rejected by banned or breached password screening at change time, as evidence the control is live.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Other
Unsuccessful logon attempts	AC-7	PR.AA-03	ATT&CK M1036
Password strength and screening	IA-5(1)	PR.AA-01	NIST SP 800-63B; ATT&CK M1027
MFA	IA-2(1), IA-2(2)	PR.AA-03	ATT&CK M1032
Monitoring authentication	SI-4, AU-6	DE.CM-03	OWASP ASVS 5.0 V6.1.1, V6.3.1

Common failure patterns

Per-account thresholds only: detection fires when one account fails ten times, but a spray of one attempt per account across 5,000 accounts goes unseen.
MFA with legacy back doors: MFA is enforced in the browser while basic authentication to mail or LDAP binds still accept passwords alone.
Forgotten test and legacy accounts: accounts outside the MFA policy and without an owner, as in the Midnight Blizzard incident.
Lockout as an outage: aggressive on-premises lockout lets an attacker lock out executives or service accounts, and teams respond by switching lockout off entirely.
Misaligned hybrid thresholds: a directory threshold lower than the cloud threshold lets cloud-facing sprays lock out on-premises accounts.
Ignoring success after failure: alerting on failures but not on the successful sign-in that follows them, which is the event that needs response.

Practitioner checklist

Inventory every authentication surface and record whether it enforces MFA and rate limiting.
Block legacy authentication after measuring its use in report-only mode.
Enforce MFA for all external access, starting with administrators.
Screen passwords against banned and breached lists and apply the NIST SP 800-63B length rules.
Align cloud smart lockout and directory lockout thresholds and durations.
Detect spraying by distinct accounts per source over hours, and alert on success after failures.
Remove internet exposure of RDP, SSH and management interfaces.
Restrict service accounts to their hosts and networks, and block interactive sign-in for them.
Disable test and legacy accounts without owners.
Run authorised spray simulations quarterly against test accounts and verify alerts.

MITRE ATT&CK T1110 Brute Force Guide