One workforce phishing click left a medical-school employee mailbox open for ten days and put Social Security numbers for roughly 2,474 people in play. Closing that phishable login with phishing-proof, device-bound MFA stops the path at sign-in. According to MLive, an employee at Western Michigan University Homer Stryker M.D. School of Medicine clicked a phishing link and attackers held one workforce mailbox from 11 to 21 January 2021, later driving notices for employees and beneficiaries whose information included Social Security numbers. Reading mail after a successful attacker session is a separate problem no login MFA undoes.
For the full attack-chain write-up, see the companion on legacymfa.sucks.
FAQ
Would phishing-proof MFA have stopped the WMed mailbox takeover?
Yes, on the credential phase that public reporting actually documents. The WMed path was workforce email phishing that produced unauthorized access to a single employee mailbox. Public reporting does not establish a live second factor on that account at the January 2021 click; MLive reported WMed was already working toward two-factor authentication with a fall 2021 rollout. A phishing-proof control removes transferable passwords and OTP-style secrets from sign-in, so a stolen secret cannot complete attacker login at the real origin. Public reporting does not establish AiTM, device-code phishing, helpdesk recovery, or an MFA bypass of a deployed factor.
Why can’t MFA undo Social Security numbers already read from the WMed inbox?
Because that exposure is post-authentication data access. Once attackers already held the WMed employee mailbox session, they could read message content that exposed employee and beneficiary information, including Social Security numbers, for about 2,474 notified people per contemporaneous reporting and the related Montana Attorney General notice. No login MFA unreads mail already opened. Prevention value sits entirely in stopping the earlier sign-in. Revoke and mailbox forensics remain hygiene after the fact, not a substitute for closing the phishable login.
Does a planned 2FA rollout protect workforce email before go-live?
No. A roadmap is not a control. For WMed, the documented signal is a planned fall 2021 two-factor rollout while the phishing click and mailbox access window already ran in January 2021. Password-only or otherwise phishable sign-in is enough for a stolen secret to finish login before stronger authentication arrives. Medical-school and hospital workforce mail often carries HR, benefits, and identity paperwork, so the gap is operational, not theoretical.
How does MFA 2.0 differ from passwords, OTP, or passkeys alone for WMed-style phishing?
Passwords and OTP are transferable: whatever the phishing page or lure collects can be replayed at the real mailbox login. Passkeys and WebAuthn are phishing-resistant at the login ceremony when origin-bound signatures are required, which already beats typed secrets for a WMed-style click-and-reuse path. MFA 2.0 is phishing-proof across the identity lifecycle: device-bound keys, no central secret database to steal, and no phishable factor at registration, device onboarding, authentication, or decommissioning. For this incident, enrollment and recovery were not named in public reporting, so the decisive win is still removing the password-only email sign-in the attacker completed.
What should defenders lock after closing a WMed-style phishable login?
Keep the boundary honest. Closing phishable workforce email login stops remote credential replay of the kind WMed reported. It does not stop malware on a machine that already holds a legitimate session, and it does not erase data already copied from an opened mailbox. Prefer device-bound architecture that never issues a reusable secret, then treat revoke, short-lived sessions, and endpoint integrity as residual controls. Fooling a user into handing over a password is easy. Planting malware after a clean login is harder, and it is a different problem.
