When attackers already have the keys, MFA is just another door to open

Summary

A February 2026 breach at Figure exposed nearly 967,200 email records, enabling attackers to conduct credential stuffing, phishing, and help desk social engineering without exploiting vulnerabilities. The article argues that legacy MFA (push notifications, SMS, TOTP) cannot defend against real-time phishing relays (AiTM attacks) because they authenticate the code exchange, not the user identity. The structural problem is that MFA places the final authentication decision on a human under adversary-engineered conditions.

Full text

When attackers already have the keys, MFA is just another door to open Sponsored by Token April 9, 2026 10:02 AM 0 The Figure breach exposed 967,200 email records without a single exploit. Understanding what that enables — and why your MFA cannot contain it — is an architectural problem, not a user education problem. In February 2026, TechRepublic reported that Figure, a financial services company, exposed nearly 967,200 email records in a newly disclosed data breach. No vulnerability was chained. No zero-day was burned. The records were accessible, and now they are in adversary hands. Coverage of breaches like this tends to stop at the count. That is the wrong place to stop. The number of exposed records is not the event — it is the starting inventory for the event that follows. To understand the actual risk, you have to follow the attack chain that a credential exposure like this enables, step by step, and ask honestly whether the authentication controls in your environment can interrupt it at any point. Most cannot. Here is why. What Adversaries Do With 967,000 Email Records Exposed email addresses are not static data. They are operational inputs. Within hours of a record set like this becoming available, adversaries are running it through several parallel workflows simultaneously. The first is credential stuffing. Figure customers and employees almost certainly reused passwords across services. Adversaries combine the exposed addresses with breach databases from prior incidents — LinkedIn, Dropbox, RockYou2024 — and test the resulting pairs against enterprise portals, VPN gateways, Microsoft 365, Okta, and identity providers at scale. Automation handles the volume. Success rates on credential stuffing campaigns against fresh email lists routinely run at two to three percent. On 967,000 records, that is 19,000 to 29,000 valid credential pairs. The second workflow is targeted phishing. AI-assisted tooling can now generate personalized phishing campaigns from an email list in minutes. The messages reference the organization by name, impersonate internal communications, and are visually indistinguishable from legitimate correspondence. Recipient-specific targeting — using job title, department, or public LinkedIn data to tailor the lure — is standard practice, not a capability reserved for nation-state actors. The third is help desk social engineering. Armed with a valid email address and basic OSINT, adversaries impersonate employees in calls to IT support teams, requesting password resets, MFA device resets, or account unlocks. This attack vector bypasses authentication technology entirely — it targets the human process that exists to handle authentication failures. In each of these workflows, no technical vulnerability is required. The adversary’s goal is not to break in. It is to log in as a valid user. The breach does not create access. It creates the conditions under which access becomes achievable through the authentication system itself. Turn Authentication into Assurance Token’s Biometric Assured Identity platform is built for organizations where authentication failure is not an acceptable outcome. See how Token can strengthen identity assurance across your existing IAM, SSO & PAM stack. Learn More Why Legacy MFA Cannot Interrupt This Chain This is the part of the analysis that most incident post-mortems underweight. Organizations read about a credential exposure and conclude that their MFA deployment protects them. For the attack chain described above, that conclusion is structurally incorrect. Modern adversary tooling executes what security researchers call a real-time phishing relay, sometimes referred to as an adversary-in-the-middle (AiTM) attack. The mechanics are precise. An adversary builds a reverse proxy that sits between the victim and the legitimate service. When the victim enters credentials on the spoofed page, the proxy forwards those credentials to the real site in real time. The real site responds with an MFA challenge. The proxy forwards that challenge to the victim. The victim responds — because the page looks legitimate and the MFA prompt is real. The proxy forwards the response. The adversary receives an authenticated session. Push notification MFA, SMS one-time codes, and TOTP authenticator apps are all vulnerable to this relay. They authenticate the exchange of a code. They do not verify that the individual completing the exchange is the authorized account holder. They cannot distinguish a direct session from a proxied one. Toolkits that automate this attack — Evilginx, Modlishka, Muraena, and their derivatives — are publicly available, actively maintained, and require no advanced tradecraft to operate. The capability is not exotic. It is the baseline. MFA fatigue compounds this. Adversaries who obtain valid credentials but cannot relay the session in real time will instead trigger repeated push notifications until a user approves one out of frustration or confusion. This attack has been used successfully against organizations with mature security programs, including in incidents that received significant public coverage. The common thread across all of these techniques: legacy MFA places a human being at the final decision point of the authentication chain, then relies on that human to make the correct call under conditions specifically engineered to defeat it. The Structural Problem Legacy MFA Cannot Solve The security industry’s standard response to authentication failures is user education. Train people to recognize phishing. Teach them to verify unexpected MFA prompts. Remind them not to approve requests they did not initiate. This response is not wrong. It is insufficient, and the insufficiency is architectural, not motivational. A relay attack does not require a user to recognize a phishing page. The MFA prompt they receive is real, issued by the legitimate service, delivered through the same app they use every day. There is nothing anomalous for the user to detect. The attack is designed to be invisible to the human in the loop — and it is. The deeper problem is that the authentication architecture most organizations have deployed was not designed to answer the question that actually matters in a post-breach environment: was the authorized individual physically present and biometrically verified at the moment of authentication? Push notifications do not answer this question. SMS codes do not answer this question. TOTP does not answer this question. USB hardware tokens answer a related but different question — they prove the registered device was present, not the authorized person. Auditors, regulators, and cyber insurers are increasingly drawing this distinction explicitly. The question “can you prove the authorized individual was there?” is appearing in CMMC assessments, NYDFS examinations, and underwriter questionnaires. Device presence is no longer accepted as a proxy for human presence in high-stakes access contexts. What Phishing-Resistant Authentication Actually Requires FIDO2/WebAuthn gets cited frequently in this conversation, and it is a meaningful step forward — but it is not sufficient on its own. Standard passkey implementations bind the credential to a device or cloud account. Cloud-synced passkeys inherit the vulnerabilities of the cloud account: SIM swap attacks against the recovery phone number, account takeover via credential phishing, recovery flow exploitation. Device-bound passkeys prove device possession. They do not prove human presence. Phishing-resistant authentication that closes the relay attack vector requires three properties simultaneously: Cryptographic origin binding: the authentication credential is mathematically tied to the exact origin domain. A spoofed site cannot produce a valid signature because the domain does not match. The attack fails before any credential is transmitted. Hardware-bound private keys that never leave secure hardware: the signing key cannot be exported,

Indicators of Compromise

• malware — Evilginx
• malware — Modlishka
• malware — Muraena

Entities