Phishing campaigns that stop at credential capture are annoying. Phishing campaigns that go on to bypass MFA are a different category of problem. On March 23rd we had the latter.
Two users clicked a phishing link. Both entered their credentials on a fake login page hosted on framer.app. One of them also approved an MFA push they shouldn’t have. By the time we caught it, the bad actor had an active session and had accessed two W2 emails.
How It Started
The initial detection came through standard phishing IR workflow: messages flagged, quarantine search run, user responses checked. Two credential captures identified. The fake login page was a framer.app hosted site, which is a detail worth noting. Framer is a legitimate web design platform, and hosting phishing infrastructure on legitimate platforms is a deliberate evasion technique. URL filtering that blocks known-bad domains won’t catch a phishing page on framer.app because framer.app itself isn’t malicious.
The page was reported for abuse. That’s the right move, though the realistic outcome is the infrastructure gets taken down after the campaign is already over.
The MFA Bypass
The first user had entered their credentials but denied the MFA push prompts. Password scrambled, no active session, contained quickly. Standard credential compromise response.
The second user was different. They had approved an MFA push. By the time we got to them, there was an active session with a bad actor in it.
MFA bypass via push notification approval is worth understanding because it doesn’t require breaking any cryptography. The attacker captures the credentials, immediately attempts to log in, and the legitimate MFA system sends a push to the user’s phone asking them to approve. If the user approves without thinking, or approves because they’re confused about why they’re getting a prompt, the attacker is in. The second factor worked exactly as designed. The user made the wrong decision.
This is sometimes called MFA fatigue or push fatigue, where repeated prompts wear a user down until they approve just to make it stop. In this case it may have been a single prompt that the user approved reflexively. Either way, the result is the same.
Tracing the Access
The session logs showed the bad actor coming in through four Nigerian IPs routing through a Portland-based VPN. The VPN hop is standard practice for this kind of campaign. It moves the traffic away from a Nigerian IP (which would immediately flag in most environments) and puts it behind a US-based exit node that looks more plausible at a glance.
Digging into what the session actually did: two W2 emails accessed. No confirmed exfiltration, no direct deposit change requests found. W2 emails are a target because they contain enough personal information to enable identity theft and fraudulent tax filings. The absence of a direct deposit change is the good news. The W2 access is the bad news.
Containment
The account was disabled immediately. Password scrambled. All active sessions and cookies cleared. MFA profile cleaned and bypass tokens voided.
On the Google Admin side: messages marked as phish, all instances quarantined across the environment, auto-quarantine rule set for future messages matching the same indicators.
The framer.app phishing page was reported for abuse.
What This Illustrates
MFA is not a silver bullet. Push notification approval puts the final decision in the hands of the user, which means user behavior becomes part of the security model. A user who approves a push without verifying they initiated the login is functionally bypassing their own second factor. The technology worked. The human element didn’t.
The W2 access is a reminder that account takeovers don’t always announce themselves with obvious damage. An attacker who gets in, reads two emails, and gets out quietly is harder to detect and assess than one who immediately tries to change direct deposit. The session logs were the only record of what actually happened in that account during the compromise window.
No exfiltration confirmed. No financial changes made. One user’s W2 data potentially exposed. Contained within the same day it was detected.
This writeup describes an incident at a large institution. All internal IPs have been substituted with RFC 1918 ranges and identifying details have been generalized.