Sign-in error burst from source
A burst of sign-in errors from ONE ADDRESS, counted without needing to know who they were for.
What it detects
A burst of sign-in errors from ONE ADDRESS, counted without needing to know who they were for.
Every other authentication threshold in this pack groups by user_name, which is right when the account is the thing under attack. It also means that an export carrying no principal — and several real ones do, including federated SSO error streams where the identity provider has not resolved the user yet — is invisible. An event with no group identity is skipped rather than bucketed, deliberately, so twelve consecutive errors from a single address produced no finding at all.
This is the source-keyed complement. It answers "is something hammering us from there" rather than "is this account under attack", and it is the only question answerable when the records have no user on them.
Medium and 0.55 on purpose: a burst of errors from one address is a lead, not a verdict. A misconfigured client produces it as readily as an attacker.
MITRE ATT&CK mapping
False positives and triage
The commonest cause is not an attack: a service account with a rotated password, a mail client looping on stale credentials, or a NAT gateway aggregating a whole office behind one address. All three produce sustained errors from a single source, and in a busy tenant this rule will find them first.
Read the evidence for two things. WHETHER THE USERS DIFFER: one identity failing repeatedly is a broken client, many identities failing from one address is spraying — and the pack has m365_distributed_signin_spray for exactly that, so a hit here alongside it is the same event told twice, not two findings. WHETHER THE ADDRESS IS YOURS: corporate egress and known SaaS ranges should be allowlisted once identified, because their volume never stops. What is left — sustained errors from an address with no business relationship to the tenant — is worth pursuing, and worth checking for a success at the end of it.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 55%. Source: rules/cloud/signin_error_burst_from_source.yaml, licensed under the Apache License 2.0.
id: cloud.identity.signin_error_burst_from_source
version: 1.0.0
status: stable
severity: medium
confidence: 0.55
platforms: [application]
mitre_techniques: [T1110, T1078]
description: |
A burst of sign-in errors from ONE ADDRESS, counted without needing to know who
they were for.
Every other authentication threshold in this pack groups by `user_name`, which
is right when the account is the thing under attack. It also means that an export
carrying no principal — and several real ones do, including federated SSO error
streams where the identity provider has not resolved the user yet — is invisible.
An event with no group identity is skipped rather than bucketed, deliberately, so
twelve consecutive errors from a single address produced no finding at all.
This is the source-keyed complement. It answers "is something hammering us from
there" rather than "is this account under attack", and it is the only question
answerable when the records have no user on them.
Medium and 0.55 on purpose: a burst of errors from one address is a lead, not a
verdict. A misconfigured client produces it as readily as an attacker.
match:
event_category: authentication
event_outcome: failure
# Scoped to records with NO resolvable principal, which is what makes this
# complementary rather than a second copy of the user-keyed brute-force rules.
# An absent field never satisfies a positive predicate, so the negation matches
# exactly the events the other thresholds have to skip.
user_name_not_contains_any: ["@"]
threshold:
# Five, because the population this can see is small and specific — an ordinary
# tenant produces very few authentication failures with no principal at all.
count: 5
window_seconds: 600
group_by: [source_ip]
correlation_keys: [source_ip]
false_positive_guidance: |
The commonest cause is not an attack: a service account with a rotated password,
a mail client looping on stale credentials, or a NAT gateway aggregating a whole
office behind one address. All three produce sustained errors from a single
source, and in a busy tenant this rule will find them first.
Read the evidence for two things. WHETHER THE USERS DIFFER: one identity failing
repeatedly is a broken client, many identities failing from one address is
spraying — and the pack has `m365_distributed_signin_spray` for exactly that, so
a hit here alongside it is the same event told twice, not two findings. WHETHER
THE ADDRESS IS YOURS: corporate egress and known SaaS ranges should be
allowlisted once identified, because their volume never stops. What is left —
sustained errors from an address with no business relationship to the tenant —
is worth pursuing, and worth checking for a success at the end of 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.