How Smishing Bypasses MFA: A Security Team's Guide

How smishing bypasses MFA using adversary-in-the-middle attacks

Smishing bypasses MFA not by breaking it cryptographically, but by relaying credentials in real time through an attacker-controlled proxy that sits between the victim and the legitimate service. The employee types their password, submits their OTP or approves a push notification, and the authentication succeeds exactly as designed. The attacker simply captures the resulting session token and replays it from a separate machine.

This technique is called an adversary-in-the-middle (AiTM) attack. Phishing-as-a-service toolkits like Evilproxy and Tycoon 2FA provide ready-built proxy infrastructure, lowering the technical barrier so that even non-technical threat actors can deploy convincing credential-harvesting portals within hours. The smishing message is the delivery mechanism: a text that creates urgency, provides a lookalike URL, and drives the victim to the proxy before they pause to question it.

The attack flow breaks down as follows:

A smishing message delivers a lookalike URL, often claiming an account has been compromised or requires immediate action.
The victim enters credentials on the proxy site, which forwards them to the real service in real time.
The legitimate service issues an MFA challenge; the proxy relays it back to the victim’s device.
The victim approves the MFA prompt, completing authentication on the attacker’s behalf.
The session token is captured by the proxy and replayed from a different machine, with no further authentication required.

Session tokens are bearer tokens with no binding to the device that generated them. An attacker who steals a session cookie from one location can replay it from anywhere, and the identity provider accepts it as the legitimate user.

Pro Tip: If your MFA strategy relies solely on SMS OTPs or push notifications, treat it as a speed bump rather than a barrier. AiTM proxies defeat both in real time without the attacker ever needing to crack a password.

Why SMS and push-based MFA are inherently phishable
How to transition to phishing-resistant MFA and block smishing bypass
How Smishalert gives security teams visibility into messaging-based threats
How to reduce human risk in MFA environments against smishing and vishing
Specific smishing tactics used to extract MFA credentials
Real-world smishing attacks that successfully bypassed MFA
How AiTM proxies technically intercept and manipulate MFA flows
Emerging smishing variants targeting authenticator apps and beyond
Key Takeaways

Why SMS and push-based MFA are inherently phishable

CISA explicitly warns that SMS and push-based MFA are vulnerable to phishing, push bombing, SS7 protocol exploitation, and SIM swap attacks. These are not edge-case threats. They are documented, repeatable attack patterns that security teams encounter regularly.

Infographic comparing phishing risks of SMS and push MFA

Push bombing works by flooding a user with repeated MFA approval requests until fatigue sets in and the user taps “Accept” to stop the notifications. SIM swapping involves social engineering a cellular carrier into transferring the victim’s phone number to an attacker-controlled SIM, routing all subsequent SMS OTPs directly to the attacker. Neither attack requires any technical sophistication against the MFA mechanism itself.

Key weaknesses in SMS and push-based MFA:

OTP codes and push approvals are phishable because they are transmitted as numbers or button taps that a proxy can copy and replay instantly.
Push notifications carry no context about the originating domain, so victims cannot distinguish a legitimate prompt from one triggered by a proxy.
SS7 protocol vulnerabilities in legacy telecommunications infrastructure allow interception of SMS messages in transit.
SIM swap attacks reroute SMS OTPs entirely, bypassing the victim’s device.
Push bombing exploits user fatigue rather than any technical flaw, making it effective regardless of how security-aware the employee is.
Helpdesk-based MFA resets introduce a social engineering vector: attackers call support staff impersonating the victim to request a factor reset after initial smishing contact.

How to transition to phishing-resistant MFA and block smishing bypass

FIDO2 and WebAuthn represent the current standard for phishing-resistant authentication. WebAuthn credentials are cryptographically bound to the specific domain they authenticate against. If an attacker’s proxy serves a lookalike URL, the credential simply refuses to sign the challenge. The authentication fails at the proxy, not at the user.

Hardware security keys and passkeys extend this protection by binding authentication to the user’s physical device. Because the cryptographic operation must occur on or near the device the victim is using, an AiTM proxy on a remote machine cannot complete the authentication on the attacker’s behalf. Cloudflare famously survived a targeted smishing campaign in 2022 precisely because its employees used WebAuthn-based MFA.

Recommended MFA technologies and supporting policies:

Deploy FIDO2 hardware security keys (YubiKey, Google Titan) or device-bound passkeys for all privileged accounts.
Enforce Conditional Access policies requiring managed, compliant devices so that stolen session cookies cannot be replayed from unmanaged machines.
Disable legacy authentication protocols and fallback SMS/email OTP options that attackers exploit as downgrade paths.
Block legacy authentication at the identity provider level to prevent protocol downgrade attacks.
Require phishing-resistant MFA strength for administrator roles and high-value application access.

Pro Tip: Start the FIDO2 rollout with finance teams, IT administrators, and executives. These accounts carry the highest blast radius if compromised, and prioritizing them delivers the greatest risk reduction per deployment dollar.

How Smishalert gives security teams visibility into messaging-based threats

Most enterprise security stacks are built around email and endpoint telemetry. Smishing attacks arrive on personal and corporate mobile devices through SMS, iMessage, and WhatsApp, entirely outside the corporate perimeter and invisible to traditional SIEM and email gateway tooling.

Smishalert addresses this visibility gap directly. The platform captures user-reported smishing attempts, correlates them across the organization to identify active campaigns, and surfaces threat patterns including executive impersonation, credential-harvesting portals, and payroll fraud lures. Security teams gain an understanding of their human attack surface that endpoint and email tools cannot provide.

Key Smishalert capabilities for defenders:

User reporting across SMS, iMessage, and WhatsApp with low-friction mobile submission.
Campaign correlation to connect individual reports into coordinated attack patterns.
Threat analysis identifying credential-harvesting infrastructure, lookalike domains, and impersonation tactics.
Attack surface visibility beyond the corporate network perimeter, covering channels traditional security tools do not monitor.
Detection support for post-authentication anomalies including impossible travel and new MFA device registration.

Smishalert is built for security leaders and IT teams who need to see threats that occur outside the corporate perimeter. Messaging-based social engineering is the first signal in the human layer — and it is the signal most organizations are currently missing entirely.

Defenders must also shift their incident response posture. Post-authentication monitoring for impossible travel, new MFA device registration within minutes of login, and inbox rule creation catches AiTM compromises that generate no failed login alerts. Password resets alone do not remediate a stolen session; all active sessions must be revoked.

How to reduce human risk in MFA environments against smishing and vishing

Technology controls address the authentication layer. Human controls address the social engineering layer. Both are necessary because attackers who cannot bypass FIDO2 directly will pivot to the helpdesk, the HR team, or the finance coordinator who can be convinced to approve an MFA reset.

Vishing combined with smishing is a documented attack pattern: the smishing message primes the target, and a follow-up phone call completes the compromise by social engineering telephone support staff into resetting MFA factors. The Scattered Spider group used exactly this sequence to breach multiple organizations, with the smishing message establishing a pretext that the vishing call then exploited.

Human risk controls that complement technical defenses:

Enforce a written policy prohibiting sharing of MFA codes, OTPs, or passwords via any messaging channel, with explicit acknowledgment that no legitimate IT representative will ever request them by SMS.
Require multi-channel verification for all MFA resets and high-risk account actions, using documented contact directories rather than callback numbers supplied by the requester.
Publish an intranet-hosted IT and HR contact directory so employees can verify inbound requests through a trusted channel independent of the message they received.
Provide a low-friction reporting path for suspicious texts, whether a dedicated forwarding number or a simple internal URL accessible from mobile devices.
Train employees on combined smishing and vishing attack sequences, not just isolated phishing URL recognition.

Pro Tip: Simulate the full attack chain in training exercises: send a fake smishing message, then follow up with a vishing call to the same employee. Single-channel simulations underestimate attacker sophistication and leave employees unprepared for the real sequence.

Specific smishing tactics used to extract MFA credentials

Smishing campaigns targeting MFA credentials rely on a small set of proven social engineering pretexts. The most common is the false account compromise alert: a text claiming the recipient’s account has been locked or flagged for suspicious activity, with a link to “verify” identity. The urgency is engineered to suppress critical thinking and drive immediate action.

A second pattern is the IT support impersonation, where the attacker poses as internal IT staff requesting MFA code confirmation for a “system migration” or “security upgrade.” Because the request appears to come from a trusted internal source, employees who would reject an external phishing link often comply. The reply-to-verify pattern extends this further: the attacker opens a conversational SMS exchange to build credibility before delivering the malicious link, making the interaction feel routine by the time the credential-harvesting step appears.

AI-generated conversations have made these pretexts harder to detect. LLM-generated smishing messages contain no grammatical errors, adapt to the victim’s responses, and can sustain multi-turn exchanges that extract credentials piece by piece without triggering the behavioral signals employees are trained to recognize.

Professionals reviewing AI-generated smishing messages

Real-world smishing attacks that successfully bypassed MFA

The Scattered Spider group, tracked by Mandiant as UNC3944, built its initial-access methodology around smishing combined with helpdesk vishing. The group sent employees SMS alerts claiming passwords had expired or accounts required urgent action, then called help desks impersonating those employees to request MFA bypass or password resets. This chain led directly to the 2022 Twilio breach, which compromised 209 customer accounts and exposed Authy tokens. Mandiant identified this pattern as the primary initial-access vector across the majority of incidents they observed from 2022 onward.

The Twilio case illustrates a critical point: the MFA mechanism itself was never broken. The attacker obtained a legitimate authenticated session by manipulating the humans responsible for maintaining and resetting authentication factors. Organizations that hardened their authentication technology but left helpdesk verification procedures unchanged remained exposed to the same attack chain.

How AiTM proxies technically intercept and manipulate MFA flows

An AiTM proxy operates as a transparent relay between the victim’s browser and the legitimate service. When the victim submits credentials to the proxy, the proxy forwards them to the real identity provider, which responds with an MFA challenge. The proxy passes that challenge back to the victim’s session. The victim completes MFA, the proxy forwards the response to the identity provider, and the identity provider issues a session cookie confirming successful authentication.

That session cookie passes through the proxy before it reaches the victim’s browser. The attacker captures it at that point. The victim’s browser also receives the cookie and lands on the expected authenticated page, so the login appears completely normal. The attacker then loads the captured cookie into a separate browser on a different machine, and the identity provider treats that session as fully authenticated because session tokens lack device binding by default. Conditional Access policies requiring device compliance are the primary technical control that breaks this replay.

Emerging smishing variants targeting authenticator apps and beyond

Attackers have moved beyond SMS OTP interception to target the MFA enrollment and recovery flows of authenticator apps directly. Because helpdesk-based MFA resets remain a preferred attacker tactic, organizations that deploy authenticator apps without hardening the reset process have simply shifted the attack surface rather than eliminated it. Once inside via an AiTM session, attackers frequently register their own device as a new MFA factor, ensuring persistent access that survives a password reset.

Hybrid kill chains now incorporate multiple channels in sequence. A smishing message primes the target, an email delivers a payload, and a fake MFA prompt completes the compromise. Each step looks plausible in isolation. The sequencing is what defeats conventional single-channel defenses. Security teams that detect phishing across SMS and messaging apps gain earlier visibility into these multi-stage campaigns before the MFA bypass step occurs.

Key Takeaways

Smishing bypasses MFA by relaying real-time credentials through AiTM proxies that capture session tokens, defeating SMS and push-based authentication without breaking any cryptographic mechanism.

Point	Details
AiTM proxies defeat SMS and push MFA	Attackers relay credentials and MFA codes in real time, capturing session tokens without breaking authentication.
Session tokens lack device binding	Stolen cookies can be replayed from any machine; Conditional Access policies requiring device compliance block this replay.
FIDO2/WebAuthn resists proxy attacks	WebAuthn credentials are domain-bound and device-bound, making AiTM interception technically ineffective.
Helpdesk vishing completes the chain	Smishing primes targets; follow-up vishing calls social-engineer MFA resets, as documented in the Twilio breach.
Post-authentication monitoring is critical	Defenders must watch for impossible travel, new MFA device registration, and inbox rule creation after login, not just failed attempts.