Anthropic Multiple Authentication Failures


Description

Detects at least five failed Anthropic authentication events for the same user email within one hour. Failures are matched by authentication category and failure outcome (for example magic-link or SSO login failures). That pattern fits repeated guessing, stale magic link abuse, or automated login attempts against one account.

Query · esql

from logs-anthropic.audit-*
| where
    data_stream.dataset == "anthropic.audit" and
    mv_contains(event.category, "authentication") and
    event.outcome == "failure" and
    user.email is not null
| stats
    Esql.event_count = count(*),
    Esql.event_id_values = values(event.id),
    Esql.event_action_values = values(event.action),
    Esql.source_ip_values = values(source.ip),
    Esql.source_ip_distinct_count = count_distinct(source.ip),
    Esql.user_agent_original_values = values(user_agent.original),
    Esql.anthropic_audit_actor_type_values = values(anthropic.audit.actor.type),
    Esql.timestamp_first_seen = min(@timestamp),
    Esql.timestamp_last_seen = max(@timestamp)
  by user.email
| where Esql.event_count >= 5
| keep user.email, Esql.*

Investigation fields

Pivot points the source recommends for triage.

  • user.email
  • Esql.event_count
  • Esql.event_id_values
  • Esql.event_action_values
  • Esql.source_ip_values
  • Esql.source_ip_distinct_count
  • Esql.user_agent_original_values
  • Esql.anthropic_audit_actor_type_values
  • Esql.timestamp_first_seen
  • Esql.timestamp_last_seen

Known false positives

  • A user repeatedly clicking an expired or invalid magic link from the same browser session can produce several failures before requesting a new link or signing in successfully.
  • IdP or SSO cutover testing against a pilot account can generate a short burst of failed attempts for one email during maintenance windows.

Analyst notes

Investigating Anthropic Multiple Authentication Failures

One mailbox produced a burst of authentication failures (magic-link, SSO, or other auth failures) within an hour. Use IP diversity on the alert to separate focused retries from distributed automation.

Escalate when many distinct IPs hit one email, failures precede a successful login from an unfamiliar IP, or SSO / magic-link second-factor weakening sits nearby. Close as FP for expired magic-link retries from one IP/UA or IdP pilot testing with a ticket.

Possible investigation steps

  • Read Esql.event_count, Esql.event_action_values, Esql.source_ip_values, and Esql.source_ip_distinct_count.
  • Low IP diversity → one device/egress (typos, expired links, focused guessing). High diversity → distributed automation or proxy rotation — higher priority.
  • Inspect UA / actor-type values for automation. Search for successful magic_link_login_succeeded / sso_login_succeeded for the same email or IPs in the window.
  • Correlate with Anthropic SSO Disabled or Connection Removed or magic-link second-factor disablement when org-scoped admin events are present.

False positive analysis

  • Expired magic-link click storms from one IP and named IdP cutover tests are common FPs.

Response and remediation

  • On suspected stuffing/takeover: invalidate sessions, reset credentials/MFA, and review successful logins from new IPs. If failures precede a successful unfamiliar login, expand to data access and admin changes.
Raw source Anthropic Multiple Authentication Failures · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified.
[metadata]
creation_date = "2026/09/12"
integration = ["anthropic"]
maturity = "production"
updated_date = "2026/09/25"

[rule]
author = ["Elastic"]
description = """
Detects at least five failed Anthropic authentication events for the same user email within one hour. Failures are
matched by authentication category and failure outcome (for example magic-link or SSO login failures). That pattern fits
repeated guessing, stale magic link abuse, or automated login attempts against one account.
"""
false_positives = [
    """
    A user repeatedly clicking an expired or invalid magic link from the same browser session can produce several
    failures before requesting a new link or signing in successfully.
    """,
    """
    IdP or SSO cutover testing against a pilot account can generate a short burst of failed attempts for one email
    during maintenance windows.
    """,
]
from = "now-60m"
interval = "15m"
language = "esql"
license = "Elastic License v2"
name = "Anthropic Multiple Authentication Failures"
note = """## Triage and analysis

### Investigating Anthropic Multiple Authentication Failures

One mailbox produced a burst of authentication failures (magic-link, SSO, or other auth failures) within an hour.
Use IP diversity on the alert to separate focused retries from distributed automation.

Escalate when many distinct IPs hit one email, failures precede a successful login from an unfamiliar IP, or SSO /
magic-link second-factor weakening sits nearby. Close as FP for expired magic-link retries from one IP/UA or IdP
pilot testing with a ticket.

#### Possible investigation steps

- Read `Esql.event_count`, `Esql.event_action_values`, `Esql.source_ip_values`, and
  `Esql.source_ip_distinct_count`.
- Low IP diversity → one device/egress (typos, expired links, focused guessing). High diversity → distributed
  automation or proxy rotation — higher priority.
- Inspect UA / actor-type values for automation. Search for successful `magic_link_login_succeeded` /
  `sso_login_succeeded` for the same email or IPs in the window.
- Correlate with **Anthropic SSO Disabled or Connection Removed** or magic-link second-factor disablement when
  org-scoped admin events are present.

### False positive analysis

- Expired magic-link click storms from one IP and named IdP cutover tests are common FPs.

### Response and remediation

- On suspected stuffing/takeover: invalidate sessions, reset credentials/MFA, and review successful logins from new
  IPs. If failures precede a successful unfamiliar login, expand to data access and admin changes.
"""
references = ["https://platform.claude.com/docs/en/api/compliance/activities/list"]
risk_score = 47
rule_id = "25647990-cc37-430c-9a4e-2793bb5445f5"
severity = "medium"
tags = [
    "Domain: GenAI",
    "Domain: Identity",
    "Platform: Anthropic",
    "Data Source: Anthropic Audit Logs",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Resources: Investigation Guide",
    "Rule Type: ES|QL",
    "Tactic: Credential Access",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-anthropic.audit-*
| where
    data_stream.dataset == "anthropic.audit" and
    mv_contains(event.category, "authentication") and
    event.outcome == "failure" and
    user.email is not null
| stats
    Esql.event_count = count(*),
    Esql.event_id_values = values(event.id),
    Esql.event_action_values = values(event.action),
    Esql.source_ip_values = values(source.ip),
    Esql.source_ip_distinct_count = count_distinct(source.ip),
    Esql.user_agent_original_values = values(user_agent.original),
    Esql.anthropic_audit_actor_type_values = values(anthropic.audit.actor.type),
    Esql.timestamp_first_seen = min(@timestamp),
    Esql.timestamp_last_seen = max(@timestamp)
  by user.email
| where Esql.event_count >= 5
| keep user.email, Esql.*
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1110"
name = "Brute Force"
reference = "https://attack.mitre.org/techniques/T1110/"


[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[[rule.threat_mappings]]
framework = "MITRE ATLAS"
version = "2026.08"
[[rule.threat_mappings.threat]]
framework = "MITRE ATLAS"

[rule.threat_mappings.threat.tactic]
id = "AML.TA0013"
name = "Credential Access"
reference = "https://atlas.mitre.org/tactics/AML.TA0013/"

[rule.alert_suppression]
group_by = ["user.email"]
missing_fields_strategy = "suppress"

[rule.investigation_fields]
field_names = [
    "user.email",
    "Esql.event_count",
    "Esql.event_id_values",
    "Esql.event_action_values",
    "Esql.source_ip_values",
    "Esql.source_ip_distinct_count",
    "Esql.user_agent_original_values",
    "Esql.anthropic_audit_actor_type_values",
    "Esql.timestamp_first_seen",
    "Esql.timestamp_last_seen",
]

[rule.alert_suppression.duration]
unit = "h"
value = 1

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.