Skip to main content
Tier One
Medium

Repeated MFA push prompts rejected by user (push fatigue)

A-1071

00:00time on this alert, target 20 minutes

Back to queue

Alert details

Source
Cloud Audit Log
Detection rule
CLOUD-IDENT-MFA-FATIGUE-002
Affected user
dtanaka
Affected host
LAPTOP-DTANAKA
Source IP
103.114.161.7
First seen
2026-07-24T13:06:00Z

Why this fired, in plain English

Someone tried to sign in as this user over and over, sending a stream of approve/deny prompts to their phone hoping they would eventually tap Approve by mistake.

Suggested playbook

Impossible travel / anomalous sign-in

  1. 1. Compare device IDs and user agents between the two sign-ins.
  2. 2. Check the VPN logs — corporate VPN egress is the single most common cause of false positives.
  3. 3. Check the IP owner: corporate egress, consumer ISP, hosting provider, or anonymizer?
  4. 4. Check MFA state on each sign-in.
Open the full checklist

Raw log evidence

Exactly what the tools recorded — 4 events.

  1. Guided hint: this line matters

    ts=2026-07-24T13:02:51Z src="cloud_audit" event=SignInAttempt user="dtanaka@northwind-mfg.example" src_ip=103.114.161.7 geo="Singapore, SG" result=mfa_required password=correct user_agent="python-requests/2.31.0"

    The password was already correct — so the attacker has valid credentials and only MFA is standing in the way.

  2. Guided hint: this line matters

    ts=2026-07-24T13:03:10Z src="cloud_audit" event=MfaPush user="dtanaka@northwind-mfg.example" push_count=11 window_sec=180 results="denied x10, timeout x1" src_ip=103.114.161.7

    Eleven push prompts in three minutes is not a user struggling to log in — it is someone hammering the account.

  3. Guided hint: this line matters

    ts=2026-07-24T13:05:40Z src="helpdesk" event=ticket_created user="dtanaka" summary="My phone keeps buzzing with login approvals I did not start" priority=low

    The real user reported it. That is your confirmation the sign-ins are not theirs.

  4. ts=2026-07-24T13:06:00Z src="cloud_audit" event=alert_raised rule="CLOUD-IDENT-MFA-FATIGUE-002" user="dtanaka@northwind-mfg.example"

Related events

The order things happened in.

  1. 13:02Z

    Correct password submitted from Singapore

  2. 13:03Z

    11 MFA pushes in 180 seconds, all denied

  3. 13:05Z

    User raises a helpdesk ticket

  4. 13:06Z

    Alert raised

Enrichment lookups

Mock lookups. Run each one yourself — a real analyst never guesses what a lookup would have said. There is no "run everything" button on purpose.

0 of 4 lookups checked

  • Not checked yet.

  • Not checked yet.

  • Not checked yet.

  • Not checked yet.

Part of incident INC-2201

Account takeover of dtanaka — Singapore VPN

Three separate alerts fired across the shift. On their own each looks survivable. Together they are one intrusion: stolen password, MFA bypassed, mailbox looted, then cloud persistence.

What links them: Source IP 103.114.161.7 and the user dtanaka appear in all three.

  1. 1 · Credential access

    Correct password from Singapore, 11 MFA pushes denied. The password was already stolen.

    A-1071 — you are here
  2. 2 · Impossible travel & collection

    Same IP finally signs in without MFA, creates a hidden inbox rule and reads 284 messages.

    Open A-1047
  3. 3 · Cloud persistence

    Same IP creates a long-lived access key on an admin service principal — access that survives a password reset.

    Open A-1061

Tier 1 work is not just judging one alert. When the same user, host or IP shows up twice in a shift, link the tickets — the severity of the chain is always higher than the severity of its parts.

techniques

Your verdict

Keyboard shortcuts 1–4, or click. You can always change your mind afterwards.