Closing the live AiTM path at workforce email sign-in is what stops The Standard-style session harvest. According to the Maryland Attorney General breach notice, Standard Insurance Company (The Standard) used multi-factor authentication for email access, yet spear phishing from a former client's legitimate address steered employees into an Attacker-in-the-Middle intercept that captured live sign-in sessions and yielded intermittent access to several employee mailboxes from 20 April through 25 April 2023. Phishing-proof device-bound MFA 2.0 removes the transferable factors a reverse proxy can relay, so the kit never mints a usable session for the attacker. Mailbox contents after that hijack are residual post-auth exposure: revoke and review close that window.
For the full attack chain and disclosure facts, read the companion on legacymfa.sucks.
FAQ
Would phishing-proof MFA 2.0 have stopped The Standard AiTM login path?
Yes for the login harvest at The Standard. The AiTM path succeeded because email MFA still completed through a reverse-proxy intercept, so the real service issued a session the attacker held. Phishing-proof MFA 2.0 uses device-bound, origin-bound signatures with no password, OTP, SMS code, or push the proxy can steal or relay. Closing that phishable login stops this path. Malware after a legitimate login is a harder, separate problem.
Why did MFA already in use fail on The Standard email access?
MFA already in use on The Standard email access failed because Attacker-in-the-Middle kits do not need a missing second factor. They sit between the employee and the real login, capture whatever transferable proof the user presents, and receive the authenticated session live. Public reporting does not establish which MFA method The Standard used. Any factor the user can type, approve, or read out remains relayable through that proxy. The same reverse-proxy login pattern later hit UK industrial workforce campaigns.
Does MFA 2.0 undo mailbox access after The Standard session theft?
No. Once attackers already held intercepted The Standard mailbox sessions, login MFA could not revoke that access. According to the Maryland notice, unauthorized access to several employee email accounts ran intermittently until The Standard's security team detected it on 25 April 2023. Potentially exposed content included names and Social Security numbers; four Maryland residents received notice after broader review. Containment for that residual window is session invalidation, mailbox review, and detection. Prevention, not detection is the claim at authentication; revoke stays hygiene after a session exists.
How do passkeys compare to MFA 2.0 for this email AiTM vector?
Passkeys are phishing-resistant at the login ceremony: origin-bound signatures stop classic reverse-proxy relay of a reusable secret at authentication. MFA 2.0 is phishing-proof across the identity lifecycle, with no phishable factor at registration, device onboarding, authorisation, authentication, or decommissioning. For The Standard's documented path, which was credential-phase AiTM at email sign-in rather than helpdesk re-enrollment, phishing-resistant login already removes the live capture surface AiTM needs. Full-lifecycle phishing-proof coverage closes enrollment and recovery gaps that plain passkey deployments sometimes leave open. Public reporting does not show an enrollment or recovery path in this breach.
What should a CISO change after The Standard-style email AiTM?
A CISO facing The Standard-style email AiTM should replace transferable email MFA factors with device-bound, phishing-proof authentication so a proxied sign-in cannot complete. Keep fast session revoke and mailbox review as hygiene for residual token abuse and for malware on an already-logged-in PC. Fooling a user into a proxied login is easy. Planting malware is not. Shortening token lifetime alone does not prevent the harvest; it only forces the attacker to re-steal sooner if they never registered their own lasting factor during the window.
