Detecting MFA Bypass and Push Fatigue in Duo Security Logs

Why this matters

MFA stops password reuse from becoming account takeover — until the attacker attacks the MFA layer itself. The three moves that work against Duo in practice are push fatigue (bomb the user with prompts until one gets approved), bypass-code abuse (a stolen or social-engineered bypass code sidesteps the factor entirely), and simply continuing after a user reports fraud, because nobody was watching the log. All three are recorded in the Duo Auth Log with explicit field values — the failure mode is not missing data, it is unreviewed data.

Indicators to look for in Duo authentication logs

• result: FRAUD with reason: user_marked_fraud — the user is telling you directly that someone else has their password
• result: DENY with reason: anomalous_push — Duo’s own push-bombing signature, especially in bursts against one account
• result: ALLOW with factor: bypass — authentication that succeeded without a real second factor (reason: bypass_user)
• access_device.ip values from anonymizing infrastructure or hosting providers rather than employee networks
• access_device.browser values like python-requests — a scripted client where a human browser should be
• MFA denials against one application (for example a VPN or an admin panel) from several unrelated accounts in one window

How LogTriage detects this

The Duo parser normalizes each authentication into a scored event: FRAUD and DENY results become 403s carrying the reason field as the failure reason, and any factor containing bypass is treated as a 403 even when Duo returned ALLOW — a bypass-code success is precisely the event that deserves scrutiny. Because each event is normalized to a POST against /auth/{factor}, repeated denials from one source IP feed the same failed-authentication pattern detector used for credential stuffing (three or more attempts with a 50%+ failure rate in a session window). Independently, every access_device.ip is checked against LogTriage’s confirmed-malicious CIDR table — the 185.220.101.0/24 Tor exit range in our sample data, for instance, is a confirmed IOC from real incident investigations — and against live IP reputation feeds, where a single confirmed-malicious verdict floors the event’s risk score to 75. There is also a published, sample-validated Sigma rule for this exact pattern: LTR-0013, Duo MFA fatigue and bypass abuse.

Detection / evidence checklist

• Pull the Duo Auth Log for the affected account and list every FRAUD, DENY, and bypass event with timestamps and source IPs
• Treat any FRAUD report as confirmed password compromise — reset the password, not just the session
• For bypass authentications, match each one to a helpdesk ticket; any orphan bypass is an incident
• Check whether the same source IP appears against other accounts — push fatigue campaigns rarely target one user
• Review which applications the account reached after any suspicious ALLOW, and rotate credentials the session could have exposed