Stop university Duo SMS OTP phishing

Proofpoint’s late-2021 university campaigns harvested passwords and SMS one-time passcodes on spoofed campus, Office 365, and Duo pages. Phishing-proof device-bound MFA 2.0 removes that transferable factor so the fake form never completes login. The attack chain write-up lives on the companion site; this post is the prevention cut.

According to Proofpoint on 7 December 2021, COVID- and Omicron-themed lures sent North American university staff to spoofed campus or Office 365 logins, and some runs also spoofed Duo pages to steal SMS one-time passcodes after username and password capture. Phishing-proof device-bound MFA 2.0 stops that path at login: there is no password or SMS code to type on an attacker form, and signatures are origin-bound to the real IdP. Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem.

Factor at fake campus / Duo page	Result for the attacker
Password + SMS OTP	Secrets are typed and reusable on the real login
Phishing-proof device-bound MFA	No transferable secret; wrong origin gets no signature

For the full campaign chain, named schools, and mailbox-relay detail, read the companion on legacymfa.sucks.

FAQ

Would phishing-proof MFA have stopped the Proofpoint university Duo campaigns?

Phishing-proof MFA 2.0 would have stopped the documented login harvest in the Proofpoint university Duo SMS OTP phishing campaigns. Attackers needed victims to enter usernames, passwords, and live SMS codes on pages that only looked like campus portals, Office 365, or Duo. Device-bound credentials never leave the enrolled hardware, produce no OTP to type, and will not complete a signature for the wrong origin. Public reporting does not establish reverse-proxy session-cookie theft as the primary steal; the win was password plus SMS OTP on spoofed pages. That is prevention, not detection.

Why does SMS OTP fail when Duo pages are spoofed?

SMS OTP fails against university Duo SMS OTP phishing because the code is a transferable secret anyone who sees it can reuse. According to Proofpoint Threat Insight (Selena Larson and Jake G, 7 December 2021), some campaigns spoofed MFA providers such as Duo, and stealing MFA tokens lets an attacker bypass the second layer once they already know the username and password. The user typed a real SMS code into an attacker-controlled form, so the second factor never bound to a legitimate university or Office 365 session. Push approvals and email codes fail the same way when they can be coached or relayed.

Are passkeys enough for this higher-ed phishing class?

Passkeys and WebAuthn are phishing-resistant at the login ceremony and would block typing a password or SMS code into a fake university or Duo page for that authentication step. MFA 2.0 is phishing-proof across the identity lifecycle: registration, device onboarding, authorisation, authentication, and decommissioning use no phishable factor. For this Proofpoint wave, public reporting does not establish helpdesk re-enrollment as the path, so the decisive failure was transferable SMS OTP at login. Still prefer full-lifecycle coverage so a later recovery flow cannot reintroduce a typed secret. An enterprise IdP that issues only hardware-bound signatures keeps that bar consistent, including at enrolment.

Does stopping the login also stop mailbox-to-mailbox relay?

Stopping the initial university Duo SMS OTP harvest sharply reduces mailbox-to-mailbox relay because attackers need fewer compromised campus senders. Proofpoint stated it is likely the actors stole credentials and used compromised university mailboxes to send the same COVID-themed threats to other universities. A completed campus or Office 365 sign-in is also a wide door: one session often reaches mail and other federated apps without a fresh login. Phishing-proof login shrinks the pool of those sessions. It does not by itself detect abuse of a mailbox already taken, and it does not undo mail already sent from a live session. Revoke, mailbox audit, and transport controls remain hygiene after a session exists.

What still needs handling if a session already exists?

If a university session already exists after a completed login, no login MFA undoes use of that mailbox or cloud apps. For the Proofpoint campaigns the primary documented failure was password and SMS OTP harvest on fake logins, so the prevention claim is closing the phishable login so the kit never finishes sign-in. Fooling a user into a spoofed portal is easy. Planting malware on an already-logged-in PC is not. Short token lifetimes and revoke still matter as backup; they are not a substitute for removing SMS OTP and passwords from workforce authentication.