ATT&CK coverage › Technique

Brute Force: Password Spraying T1110.003

Adversaries may use a single or small list of commonly used passwords against many different accounts to attempt to acquire valid account credentials. Password spraying uses one password (e.g. 'Password01'), or a small list of commonly used passwords, that may match the complexity policy of the domain. Logins are attempted with that password against many different accounts on a network to avoid account lockouts that would normally occur when brute forcing a single account with many passwords.

Events covered

8 catalog events are tagged with this technique by at least one rule.

ProviderEvent IDTitle
Security-Auditing4624An account was successfully logged on.
Security-Auditing4625An account failed to log on.
Security-Auditing4648A logon was attempted using explicit credentials.
Security-Auditing4768A Kerberos authentication ticket (TGT) was requested.
Security-Auditing4771Kerberos pre-authentication failed.
Security-Auditing4776The domain controller attempted to validate the credentials for an account.
Defender-DeviceLogonEvents9003001Logon succeeded
Defender-DeviceLogonEvents9003002Logon failed

Authoring guide

Patterns shared across the 23 rules above: which fields they filter on, what specific values they look for, and what they exclude. Field names are normalized across vendors so Sigma's Image, Elastic's process.name, and Splunk's process_name collapse into one row. Each rule contributes at most once per row.

Fields filtered most (25 distinct)

The fields most rules look at when detecting this technique. The How column shows the operators authors use (eq, wildcard, regex_match, match) and how often each appears. Sample values are concrete examples to start from, not an exhaustive list.

FieldRulesHowSample values
EventID16eq 164768, 4776, 4625, 4648, 4771
user12ne 12*$, "*$"
Status10eq 100x12, 0x6, 0xc0000064, 0xC000006A, 0x18
isOutlier9eq 91
LogonType8eq 7, ne 1Network, 2, 3, Unlock
unique_accounts8gt 830
EventType3eq 3logon-failed, logged-in
source.ip3is_not_null 2, ne 1127.0.0.1, ::1
user.domain2ne 2NT AUTHORITY
event.category2eq 2authentication
computer_name2is_not_null 2
Esql.failed_auth_count2ge 2100, 50
.252gt 2
failed_dc2gt 2
Target_User_Name2ne 2*$

Top indicator values (38 distinct)

Specific (field, operator, value) combinations the rules check for, ranked by how many rules under this technique use each one. The Corpus reach column counts how many rules across the entire catalog (any technique) check the same combination. High numbers point to widely-used indicators that are likely noisy on their own; combine them with another condition for useful signal. Blank means the combination is specific to rules under this technique.

FieldKindValueRules (here)Corpus reach
userne*$1010
isOutliereq1916
unique_accountsgt3088
EventIDeq4768410
EventIDeq477644
EventIDeq462546
EventTypeeqlogon-failed33
LogonTypeeqNetwork34
user.domainneNT AUTHORITY22
event.categoryeqauthentication25
Statuseq0x1222
Statuseq0x623
Statuseq0xc000006422
EventIDeq464823
Target_User_Namene*$22
Statuseq0xC000006A22
process_namene"-"22
LogonTypeeq222
EventIDeq477122
userne"*$"27

Common exclusions (17 distinct)

Field/operator/value combinations that rules under this technique routinely exclude (top-level not() clauses). These are the false-positive paths the community has learned to filter out. A new rule that ignores the high-count entries here will likely fire on the same noisy paths.

FieldKindValueRules excluding
Statusin0xc00001332
Statusin0xc000005e2
Statusin0xc000015b2
Statusin0xc00000dc2
Statusin0xc00001922
userwildcard*$1
user.ideqS-1-0-01
userwildcardANONYMOUS LOGON1
Statuseq0xC000015B1
Statuseq0XC000005E1
Statuseq0XC00001921
userwildcard-1
Statuseq0XC00001331
TargetUserSideqS-1-0-01
userends_with$1

Rules under this technique

Every rule in the catalog tagged with this technique, grouped by vendor. Click a rule title for its full predicates, exclusions, and indicators.

Elastic 3 rules

Splunk 19 rules

Kusto Query Language 1 rule