Why is a single FRAUD event treated as critical rather than medium?

Because of what it implies rather than what it is. A user can only be prompted to approve an MFA push if someone already submitted their correct username and password. When that user marks it fraudulent, they are telling you the first factor is already compromised and an attacker is actively holding valid credentials. The MFA prompt is the last control standing, and it held once — there is no guarantee it holds on the tenth attempt.

What exactly is MFA fatigue or push bombing?

An attacker with a valid password triggers authentication repeatedly, spamming the victim's phone with push prompts until they approve one out of confusion or to stop the notifications. It defeats push-based MFA without any technical exploit — it is purely a human-endurance attack. Duo's anomalous_push reason is its own detection of this pattern, which is why the rule keys on it directly.

Why flag bypass codes when they are a legitimate feature?

Because they are a legitimate feature that completely sidesteps MFA, which makes them a favourite target. A bypass code turns a compromised password into full access with no second factor. Legitimate use is rare, ticketed, and issued by a known admin — so every use is worth a look. Bypass authentication from an unusual IP, or against an admin account, should be treated as compromise until proven otherwise.

How should this rule be tuned for a large tenant?

Do not threshold FRAUD or bypass — both are rare and individually meaningful, so alert on every occurrence. The anomalous_push condition is the one that benefits from correlation: group by user and look for repeated denies in a short window, since a single denied push is often benign but five in two minutes is an attack in progress.

Detect MFA Fatigue and Bypass Abuse in Duo Security Logs

Sigma Rule

title: Duo MFA Fatigue, Fraud Report, and Bypass Abuse
id: 6d1a8f34-2c97-4e05-b8d6-91f7a3e4c25b
status: experimental
description: >
  Detects abuse of the MFA layer in Duo. Three distinct high-signal conditions:
  a user explicitly marking an authentication as fraudulent, Duo flagging a push
  as anomalous (the push-bombing signature), and an authentication succeeding via
  a bypass code rather than a real factor. A FRAUD report is a user telling you
  directly that an attacker holds their password.
references:
  - https://attack.mitre.org/techniques/T1621/
  - https://attack.mitre.org/techniques/T1556/006/
author: LogTriage
date: 2026/08/04
logsource:
  product: duo
  service: authentication
detection:
  user_reported_fraud:
    result: 'FRAUD'
    reason: 'user_marked_fraud'
  push_bombing:
    result: 'DENY'
    reason: 'anomalous_push'
  bypass_used:
    factor: 'bypass'
    result: 'ALLOW'
  condition: user_reported_fraud or push_bombing or bypass_used
falsepositives:
  - Single unexpected DENY from a background app re-authenticating
  - Helpdesk-issued bypass code during phone replacement (correlate with a ticket)
  - Push timeout and retry caused by a flaky mobile connection
level: critical
tags:
  - attack.credential_access
  - attack.t1621
  - attack.defense_evasion
  - attack.t1556.006

What this rule detects

Most MFA attacks do not break the cryptography — they go around it. This rule targets the three clearest signals in Duo’s authentication log that the second factor is being attacked rather than simply used:

FRAUD / user_marked_fraud — a user explicitly reported an authentication as fraudulent.
DENY / anomalous_push — Duo’s own detection that a push looks like push-bombing.
bypass factor with ALLOW — someone authenticated using a bypass code instead of a real second factor.

Any one of these fires the rule. They are independently meaningful, so there is no threshold.

Detection logic

The rule is an or across three narrow selections rather than a count, because each condition is rare enough that a single occurrence justifies an alert.

Why a fraud report is critical. The MFA prompt only happens after a correct username and password. When a user marks it fraudulent, they are reporting — with more confidence than any detection engine could — that an attacker already holds their credentials. The attack is at the final control. Treating that as a medium-severity informational event is the mistake this rule exists to prevent.

Why bypass codes deserve their own selection. A bypass code is a deliberate MFA escape hatch for lockouts and lost devices. That also makes it the cleanest way to turn a stolen password into full access. Legitimate use is rare, ticketed, and traceable to an admin; anything else should be treated as compromise until proven otherwise.

Validated against a real sample

Validated against duo_attack.json (shipped with LogTriage), which contains all three conditions:

A FRAUD result for user jsmith with reason: user_marked_fraud, from 185.220.101.42 with hostname attacker.ru
A DENY with reason: anomalous_push against alice on Office365 SSO from 45.142.212.100
An ALLOW for admin on the Admin Panel using factor: bypass, from the same 185.220.101.42 — with the browser reported as python-requests, which is not a browser

That last event is the whole attack chain in one line: the same source that triggered a fraud report reaching an admin panel through a bypass code, driven by a script.

The rule fires on that sample and stays silent on the matching benign log, which contains only ALLOW results via duo_push and totp with reasons like user_approved and valid_passcode — zero occurrences of FRAUD, DENY, anomalous_push, or bypass.

False positives

Genuine ones are quiet and isolated: a single unexpected DENY when a background app re-authenticates, or a push that timed out on a bad connection. Neither produces the fraud report or bypass signal.

Helpdesk-issued bypass codes during phone replacement are the one recurring benign case — they should correlate with a ticket and originate from a known admin. If bypass codes are routine in your tenant, that is worth addressing as a policy problem rather than tuning the rule to ignore them.

Frequently Asked Questions

Why is a single FRAUD event treated as critical rather than medium?: Because of what it implies rather than what it is. A user can only be prompted to approve an MFA push if someone already submitted their correct username and password. When that user marks it fraudulent, they are telling you the first factor is already compromised and an attacker is actively holding valid credentials. The MFA prompt is the last control standing, and it held once — there is no guarantee it holds on the tenth attempt.
What exactly is MFA fatigue or push bombing?: An attacker with a valid password triggers authentication repeatedly, spamming the victim's phone with push prompts until they approve one out of confusion or to stop the notifications. It defeats push-based MFA without any technical exploit — it is purely a human-endurance attack. Duo's anomalous_push reason is its own detection of this pattern, which is why the rule keys on it directly.
Why flag bypass codes when they are a legitimate feature?: Because they are a legitimate feature that completely sidesteps MFA, which makes them a favourite target. A bypass code turns a compromised password into full access with no second factor. Legitimate use is rare, ticketed, and issued by a known admin — so every use is worth a look. Bypass authentication from an unusual IP, or against an admin account, should be treated as compromise until proven otherwise.
How should this rule be tuned for a large tenant?: Do not threshold FRAUD or bypass — both are rare and individually meaningful, so alert on every occurrence. The anomalous_push condition is the one that benefits from correlation: group by user and look for repeated denies in a short window, since a single denied push is often benign but five in two minutes is an attack in progress.

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs