Phishing-proof MFA stops OIT vishing Duo push

Princeton Advancement was reached after OIT-impersonation vishing steered an employee through a fake university login and a coached Duo push. Phishing-proof MFA 2.0 removes the password and the approve-able push from that path so live coaching cannot mint a session. Access after a valid login is still containment work.

According to Princeton OIT’s cybersecurity incident information and FAQ, an actor posing as the OIT Service Desk steered an employee to a mimicked Princeton sign-on page, captured the username and password entered there, and had the employee approve an attacker-initiated Duo push. That finished a real workforce login and opened the Advancement and fundraising database. Phishing-proof MFA 2.0 is built so there is no password to type on a fake page and no push to approve under phone pressure, which closes this initial path. Once a valid session already exists, no login MFA undoes database use.

For the full attack-chain write-up, read the companion on legacymfa.sucks.

FAQ

Would MFA 2.0 have stopped the Princeton OIT vishing login?

Yes. The Princeton Advancement path started with helpdesk-style vishing, a mimicked university sign-on page, and a coached Duo push approval. Phishing-proof MFA 2.0 uses device-bound credentials with no transferable password, OTP, SMS code, email code, or push for an attacker to harvest or talk someone into approving. Closing that phishable login stops this path. Malware after a legitimate login is a harder, separate problem.

Why did Duo push fail under OIT impersonation?

Duo push failed in the Princeton incident because an approve-able prompt is still a coachable factor. According to Princeton OIT, the employee approved an attacker-initiated multifactor push while under live Service Desk pressure on the same call that steered them to a fake login. Legacy MFA did what push MFA does when someone is coached in real time. The break is the transferable second factor, not a missing “MFA enabled” checkbox.

Does phishing-proof MFA undo Advancement database access after login?

No. Princeton reports the Advancement and fundraising database was reached after the authenticated session existed, with the intrusion beginning midday 10 November 2025 and blocked in under 24 hours. MFA of any kind does not reverse post-authentication data access. Session revoke and authorization limits remain the controls once a good session is already in play. Prevention, Not Detection is the right frame for the login phase only.

How should workforce identity stop fake-login vishing like this?

Workforce identity should remove every factor a helpdesk persona can coach someone to type or approve. Device-bound, origin-bound signatures mean a spoofed Princeton-style page is the wrong origin and has nothing transferable to steal. The same design stops the related pattern of helpdesk recovery coaching, because there is no TAP, OTP, or recovery secret to read out. The Marks & Spencer helpdesk reset prevention piece covers that branch of the same class.

Are passkeys enough against this Duo-push coaching path?

Passkeys are phishing-resistant at the login ceremony when the deployment forbids fallback to password or push. That hardens the authentication act itself. MFA 2.0 is phishing-proof across the identity lifecycle, with no phishable factor at registration, device onboarding, authentication, or decommissioning. For Princeton-style password-plus-Duo coaching, the decisive fix is ending transferable factors at login so a vishing call cannot finish sign-in. Public reporting does not establish AiTM reverse-proxy cookie theft or device-code OAuth as the mechanism here.