The Outlier Lab

MFA Bypass and OTP Interception

How a second factor gets defeated (codes socially engineered, push fatigue, real-time relays, SIM swaps, weak fallbacks) and why money-moving actions need their own transaction-level step-up.

What it is

Microsoft reports that MFA cuts identity-compromise risk by more than 99%, and that more than 97% of identity attacks are plain password attacks that MFA stops. That is why the remaining attacks are aimed at the factor itself. This note describes conceptually how factors fail so defenders can choose the right ones and add the right transaction controls. It does not explain how to defeat any specific product.

The main failure modes are below.

Failure modeWhat breaksPhishing-resistant authentication helps?
OTP social engineeringThe customer is persuaded to share a code (SMS, email, app)Yes. There's no code to share.
Push fatigue and prompt approvalThe customer approves a prompt they didn't start, under pressure or by habitMostly, especially with number matching and context
Real-time relay (AiTM)The customer completes genuine MFA on a proxy, and the session is capturedYes. Origin-bound credentials fail on lookalike domains.
Number takeoverSMS codes are rerouted (SIM Swap and Port-Out Fraud)Yes. Removes the phone number from the path.
Session theftMFA is skipped entirely (Session Hijacking and Infostealers)Partly. Needs session binding too.
Weak fallback or recovery"Can't get your code?" leads to email, security questions or support (Account Recovery Abuse)No, unless recovery is held to the same standard
Enrollment hijackAttacker registers their own factor or device after a partial compromiseNo, unless enrollment requires strong existing authentication
Inconsistent coverageMFA on web but not the API, or on login but not on payee addN/A. It's a coverage gap.

How it works

Diagram: Attacker, Customer, Platform

The pattern above (password plus a social-engineered code) is the one the FBI described in its November 2025 ATO alert. Attackers impersonating institution staff pressure victims to share MFA codes and one-time passcodes, then log in, change the password and wire funds out. The weakness is that a code proves the customer received something. It doesn't prove the customer understood and intended the action it authorizes.

Transaction footprint

StageWhat you see in the dataDecision point
TriggerCorrect password from new device; OTP requested; sometimes several prompts in a short windowThrottle prompts; enforce number matching; flag prompt bursts
Code useCode entered within seconds of delivery, from a device or network the customer has never used; customer may be on an inbound callTreat "code entered on a new device" as weak evidence
ControlPassword change; new factor or device enrolled; notifications mutedRequire the old factor or a cool-off for factor changes
AuthorizationNew payee, wire or wallet provisioning approved with an OTPUse transaction-bound confirmation that shows payee and amount; push to an existing trusted device
Cash-outFirst-time payee; amounts sized under limits; rapid sequenceReal-Time Transaction Risk Scoring; Velocity and Exposure Limits

Common variants

VariantWhat's differentWhere it shows up
Fake fraud-department callsCustomer reads codes believing they're stopping fraudBanks, P2P, brokerages
Callback scamsA lure gets the customer to call a number the attacker controlsBanking, tech-support themes
Push bombingRepeated prompts until one is approvedPush-based MFA, workforce and consumer
Automated OTP-capture callsRobocalls impersonating the bank prompt code entryBanking, card issuers
Wallet provisioning with captured OTPCode used to add the victim's card to an attacker's walletIssuers; see Digital Wallet Provisioning Fraud
Fallback downgradeAttacker chooses "try another way"Platforms offering SMS or email as alternatives

Where it shows up

  • Banks and P2P. OTPs used to approve new payees and transfers. See Real-Time Payment Rail Fraud.
  • Card issuers. OTPs that authorize token provisioning give the attacker a wallet-ready card. See Digital Wallet Provisioning Fraud.
  • Brokerage and crypto. OTP or push at login leads to liquidation and withdrawal, or ACATS Transfer Fraud.
  • Rewards and marketplaces. Email OTP leads to payout change. See Payout Redirection.

Impact

  • The FBI counted 5,100+ complaints and $262 million+ in losses from January to late November 2025, just for ATO schemes that impersonate financial institutions to capture credentials and codes.

  • FINRA has noted for years that brokers see MFA as one of the best protections but insufficient on its own, and that many have stopped trusting email as a factor.

  • Liability. The CFPB's Electronic Fund Transfers FAQs address the case where a customer is tricked into sharing a code and the attacker initiates the transfer. The FAQs were issued in June 2021, with P2P-focused additions in December 2021.

    • Unauthorized. A third party who fraudulently induces a consumer to share account access information, then uses it to make a transfer, has made an unauthorized EFT under Reg E.
    • No exception. The exclusion for someone the consumer "furnished" an access device to doesn't apply.
    • No negligence defense. Institutions can't weigh consumer negligence to impose more liability than Reg E allows.

    That makes OTP capture mostly an institution loss rather than a customer loss. The FAQs are non-binding interpretive guidance. A practitioner tracker of the CFPB's 2025 guidance withdrawals (updated April 2026) doesn't list them among the rescinded Reg E items. See Regulation E and Unauthorized Transfers.

Red flags

Prevention and detection at a glance

LayerControl or signalWhat it does here
PreventPasskeys and Phishing-Resistant AuthenticationRemoves shareable codes and defeats relays
PreventMulti-Factor Authentication (MFA) designNumber matching, prompt throttling, no silent fallbacks, MFA on every surface
PreventDevice Binding and Trusted DevicesSends high-risk approvals to an existing trusted device instead of the session asking for them
DetectRisk-Based Authentication and Step-UpStep-up is triggered by the transaction's risk as well as login risk
DetectPayee Confirmation and Payment FrictionShows payee and amount; adds friction for first-time payees
RespondCustomer Education and Scam WarningsWarns in the flow at the moment of approval
RespondSecure Account Recovery DesignKeeps fallbacks from becoming the bypass

Emerging variants and adversary adaptation

  • Pressure shifts to the customer. As codes give way to push and passkeys, pressure moves to persuading the customer to approve, and to the enrollment, recovery and support processes around the factor.
  • Phishing-resistant mandates. Japan's FSA now requires phishing-resistant MFA for internet securities trading, due in principle by the end of June 2026, after a 2025 wave in which conventional login protections failed. Where customers can't use the standard method, the FSA expects stronger detection and extra layers. That is a regulator explicitly asking for compensating transaction controls.
  • Passkey adoption is real but uneven. FIDO's 2026 survey reports 75% of consumers have enabled passkeys on at least some accounts, but only about 40% use them across most apps. The unenrolled minority, and anyone allowed to fall back to codes, is where attacks concentrate.
  • Voice and AI. Voice cloning and AI-scripted callers make fake fraud-team calls cheaper and more convincing (Generative AI and Deepfake Fraud). Assume caller ID and voice prove nothing.
  • What's next. Device-code and consent flows, cross-device sign-in prompts, and agent authorizations are the next "approve this?" surfaces. Each one needs the same context (who, what, how much) that a good payment confirmation shows.

Real-world examples

Sources and further reading