AWS console login failure burst
Repeated failed AWS console sign-ins for one identity.
What it detects
Repeated failed AWS console sign-ins for one identity.
The AWS console is the one door into an account that does not need an access key, which makes it the door an attacker knocks on when all they have is a password or a guess. ConsoleLogin with errorMessage: Failed authentication is the record, and CloudTrail keeps it whether or not the attempt ever succeeds.
The pack had failed-logon burst detection for Windows and for Microsoft 365 and none for AWS, so an MSP whose customer runs on AWS had no password-guessing detection at all. That is the gap this closes; the technique is the ordinary one.
Note that CloudTrail redacts the principal on failed root sign-ins (HIDDEN_DUE_TO_SECURITY_REASONS). Those still group and still count — the redacted name is a stable value, and a burst against it is a burst against root, which is the version that matters most.
MITRE ATT&CK mapping
False positives and triage
Forgotten passwords and stale saved credentials produce this honestly, and in a large account they will be most of what it finds. The discriminators are the ADDRESS and what happens NEXT.
A user who has forgotten their password fails from their usual address and then either succeeds or resets. Escalate when the failures come from an address the account has never used, when they are spread across SEVERAL identities from one source (that is spraying, not forgetting), when they target the root account, or when a success follows from a different address than the failures. Check whether MFA was satisfied on the eventual success — a password-only console sign-in following a burst is worth treating as compromise until the user confirms it.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 65%. Source: rules/cloud/aws_console_login_failure_burst.yaml, licensed under the Apache License 2.0.
id: cloud.aws.console_login_failure_burst
version: 1.0.0
status: stable
severity: high
confidence: 0.65
platforms: [application]
mitre_techniques: [T1110.001, T1078.004]
description: |
Repeated failed AWS console sign-ins for one identity.
The AWS console is the one door into an account that does not need an access
key, which makes it the door an attacker knocks on when all they have is a
password or a guess. `ConsoleLogin` with `errorMessage: Failed authentication`
is the record, and CloudTrail keeps it whether or not the attempt ever succeeds.
The pack had failed-logon burst detection for Windows and for Microsoft 365 and
none for AWS, so an MSP whose customer runs on AWS had no password-guessing
detection at all. That is the gap this closes; the technique is the ordinary one.
Note that CloudTrail redacts the principal on failed root sign-ins
(`HIDDEN_DUE_TO_SECURITY_REASONS`). Those still group and still count — the
redacted name is a stable value, and a burst against it is a burst against root,
which is the version that matters most.
match:
provider: AWS
event_category: authentication
event_action: ConsoleLogin
event_outcome: failure
threshold:
# Three inside five minutes. A person who has forgotten a password tries twice
# and reaches for the reset link; the corpus capture behind this shows three in
# twelve seconds.
count: 3
window_seconds: 300
group_by: [user_name]
correlation_keys: [user_name, source_ip]
false_positive_guidance: |
Forgotten passwords and stale saved credentials produce this honestly, and in a
large account they will be most of what it finds. The discriminators are the
ADDRESS and what happens NEXT.
A user who has forgotten their password fails from their usual address and then
either succeeds or resets. Escalate when the failures come from an address the
account has never used, when they are spread across SEVERAL identities from one
source (that is spraying, not forgetting), when they target the root account, or
when a success follows from a different address than the failures. Check whether
MFA was satisfied on the eventual success — a password-only console sign-in
following a burst is worth treating as compromise until the user confirms it.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.