MFA Bypass Attack Detection: How Attackers Get Past Two-Factor Authentication

Multi-factor authentication (MFA) was supposed to end account takeover. For a while, it nearly did. But attackers adapted. Today, entire phishing kits are purpose-built to intercept MFA codes in real time — and most SaaS applications have no visibility into when it's happening.

This post covers the most common MFA bypass techniques, the security events you should be monitoring, and how to configure LiteSOC to alert on these patterns before an attacker gets a foothold.

Why MFA Is No Longer Enough on Its Own

MFA stops credential stuffing cold. If an attacker only has a password, TOTP or push-based MFA is an effective barrier. The problem is the threat model has shifted. Attackers no longer just steal credentials — they proxy the entire authentication session.

The result: a user completes MFA successfully, and an attacker on the other end simultaneously captures a valid session token with full access.

Attack Technique 1: Adversary-in-the-Middle (AiTM) Phishing

AiTM is the dominant MFA bypass technique today. Toolkits like Evilginx and Modlishka act as a reverse proxy between the victim and the real login page.

How it works:

1. Victim receives a convincing phishing email with a link to login.yourapp-secure.com
2. The attacker's proxy forwards every request to the real login.yourapp.com
3. The victim sees and interacts with the real UI, including entering their MFA code
4. The proxy intercepts the authenticated session cookie in real time
5. The attacker replays the session cookie from a different IP

From the perspective of your authentication system, the login was completely legitimate — correct password, valid OTP, no anomalies. The session cookie, however, is now being used from a different geographic location and device.

Detection signal — impossible travel on session use:

The login succeeds from the victim's IP. Within seconds or minutes, the same session is used from a datacenter IP in a different country. This is where LiteSOC's impossible travel detection fires — not on the authentication event, but on subsequent auth.session_used or API activity events.

// Track session activity with location context
await litesoc.track({
  event_name: 'auth.session_used',
  user_id: userId,
  org_id: orgId,
  ip_address: req.headers['x-forwarded-for'],
  metadata: {
    session_id: sessionId,
    user_agent: req.headers['user-agent'],
    endpoint: req.path,
  },
});

Key indicator: A new session from a residential IP immediately followed by activity from a hosting provider or VPN IP using the same session token.

Attack Technique 2: Real-Time OTP Phishing

Simpler than AiTM but still effective against TOTP-based MFA. The attacker calls or texts the victim, impersonating IT support, and asks them to read out their one-time code.

How it works:

1. Attacker already has valid credentials (from a prior breach or phishing)
2. Attacker initiates a login, triggering an OTP to the victim's device
3. Attacker contacts the victim under a social engineering pretext to obtain the OTP
4. Attacker enters the OTP before it expires (usually 30 seconds)

Detection signal — failed login followed by immediate success from a different IP:

10:02:14 - auth.login_failed  - user@example.com - 203.0.113.50 (attacker IP)
10:02:31 - auth.mfa_challenge - user@example.com - 203.0.113.50 (OTP sent)
10:02:58 - auth.login_success - user@example.com - 203.0.113.50

The sequence looks clean in isolation. But if your user's previous 90 days of logins all originate from a consistent city and ISP, and this session comes from a different country, the auth.login_success event should trigger a geo-anomaly alert.

Attack Technique 3: SIM Swapping

SIM swapping attacks SMS-based MFA at the carrier level. An attacker convinces a mobile carrier to transfer a victim's phone number to a SIM the attacker controls. All SMS messages — including OTP codes — are then delivered to the attacker.

How it works:

1. Attacker gathers personal information about the victim (social engineering, OSINT)
2. Attacker contacts the carrier, impersonating the victim, and requests a SIM transfer
3. Victim's phone loses service; attacker receives all messages
4. Attacker uses the victim's credentials + intercepted OTP to authenticate

Detection signal — multiple auth.mfa_failed events before a success:

SIM swapping often involves some trial-and-error. Attackers may trigger MFA multiple times before the swap succeeds.

// Detect repeated MFA failures followed by success
const MFA_FAILURE_THRESHOLD = 3;
const WINDOW_SECONDS = 300;

async function detectMFASuspicion(event: SecurityEvent) {
  if (event.event_name === 'auth.mfa_failed') {
    const key = `mfa_fail:${event.user_id}`;
    const count = await redis.incr(key);
    if (count === 1) await redis.expire(key, WINDOW_SECONDS);

    if (count >= MFA_FAILURE_THRESHOLD) {
      await createAlert({
        type: 'mfa_exhaustion',
        severity: 'high',
        user_id: event.user_id,
        org_id: event.org_id,
        failure_count: count,
      });
    }
  }
}

Additional signal: The victim contacts support reporting they've lost phone service. This is often the first real-world indicator of a SIM swap in progress.

Attack Technique 4: MFA Fatigue (Push Bombing)

Push-based MFA (like Duo or Microsoft Authenticator) is vulnerable to exhaustion attacks. An attacker with valid credentials repeatedly triggers push notifications, hoping the victim will approve one just to make them stop.

How it works:

1. Attacker has valid username and password
2. Attacker initiates 10–50 login attempts in rapid succession
3. Victim receives a flood of push notifications
4. Victim approves one accidentally or out of frustration
5. The one successful push grants the attacker full access

This technique was used in high-profile breaches including the Uber breach in 2022.

Detection signal — high-velocity auth.mfa_challenge events:

const PUSH_BOMB_THRESHOLD = 5;
const PUSH_BOMB_WINDOW = 120; // 2 minutes

async function detectMFAFatigue(event: SecurityEvent) {
  if (event.event_name !== 'auth.mfa_challenge') return;

  const key = `push_bomb:${event.user_id}`;
  const count = await redis.incr(key);
  if (count === 1) await redis.expire(key, PUSH_BOMB_WINDOW);

  if (count >= PUSH_BOMB_THRESHOLD) {
    await createAlert({
      type: 'mfa_fatigue',
      severity: 'critical',
      user_id: event.user_id,
      org_id: event.org_id,
      challenge_count: count,
      recommendation: 'Temporarily lock account and notify user via backup channel.',
    });
  }
}

Response: Lock the account after the threshold is reached and notify the user through an out-of-band channel (email to a secondary address). The user can verify via identity verification before regaining access.

The Events to Track in LiteSOC

To catch MFA bypass attempts, you need to log more than just login successes and failures. Here is the full set of auth events relevant to MFA bypass detection:

Event	Description	Severity Trigger
auth.login_failed	Wrong password	Low
auth.mfa_challenge	MFA code sent/push triggered	Informational
auth.mfa_failed	Wrong or expired OTP entered	Medium (3+ in 5 min)
auth.mfa_success	MFA passed	Informational
auth.login_success	Full login completed	High if geo-anomaly
auth.session_used	Authenticated session activity	High if impossible travel
auth.password_reset	Password reset initiated	Medium

Putting It Together: A Composite Detection Rule

The most reliable detection combines multiple weak signals into a composite rule. A single geo-anomaly might be a false positive (VPN user). A single MFA failure is noise. But a cluster of signals is a strong indicator:

auth.mfa_failed (x3 within 5 min)
→ auth.login_success
→ auth.session_used from different country within 10 min
→ ALERT: probable MFA bypass, severity=critical

In LiteSOC, each event carries its ip_address and enriched geolocation fields. You can build this composite rule in the alert configuration, or let the behavioral AI surface it automatically as a correlated incident.

Hardening Recommendations

Detecting MFA bypass is reactive. Ideally, you layer detection with prevention:

1. Move to phishing-resistant MFA — FIDO2/WebAuthn hardware keys or passkeys are immune to AiTM proxying because the key response is domain-bound.
2. Bind sessions to IP or device fingerprint — A session cookie used from a different IP than the one that authenticated should require re-authentication.
3. Limit push MFA retries — After 3 unapproved push requests, require the user to enter a TOTP instead.
4. Avoid SMS OTP for high-risk accounts — SMS is carrier-dependent and vulnerable to SIM swapping. Use authenticator apps or hardware keys for admin accounts.
5. Monitor for new device logins — A successful login from a device that has never been seen for that account should trigger an email confirmation.

Conclusion

MFA is still worth deploying — it blocks the vast majority of credential stuffing attacks. But it is not the final layer. The signal that MFA was bypassed is almost always there in your auth event stream; you just need to be looking for it.

With LiteSOC tracking auth.mfa_challenge, auth.mfa_failed, auth.login_success, and auth.session_used events, you have everything you need to build real-time detection rules for every bypass technique covered here. The session anomalies, the push bombing patterns, the impossible travel on session replay — none of them are invisible. They are just unmonitored.

Start monitoring them.