Princeton OIT vishing won a Duo push approval

According to Princeton OIT, an actor posing as the OIT Service Desk steered an employee to a mimicked Princeton sign-on page, collected the username and password the employee typed, then triggered a Duo multifactor push the employee approved. That coached path opened the Advancement and fundraising database at midday on 10 November 2025. The university says the intrusion was blocked in under 24 hours, with a community notice on 15 November 2025.

According to Princeton OIT’s cybersecurity incident information and FAQ, an actor posing as the OIT Service Desk called an employee, steered them to a mimicked Princeton sign-on page, took the username and password entered there, and had the employee approve an attacker-initiated Duo multifactor push. With that live login complete, the actor accessed Princeton’s Advancement and fundraising database beginning midday 10 November 2025. The university reports the intrusion was blocked in under 24 hours and issued a community notice on 15 November 2025. Notices reference donors, alumni, and employees; public reporting does not establish a single fixed record count, a named threat actor, or ransom activity.

If you want the prevention angle, read the related article on mfa2point0.com.

FAQ

How did attackers get into Princeton Advancement?

Attackers got into Princeton Advancement by vishing an employee while impersonating the OIT Service Desk. According to Princeton OIT, the employee was steered to a mimicked Princeton sign-on page, entered a username and password, then approved a Duo multifactor push the attacker initiated. That authenticated session was used to reach the Advancement and fundraising database. Public reporting frames the start as coached credential entry plus push approval, not malware dropped before login.

Was this AiTM reverse-proxy or device-code phishing?

Public reporting does not establish an adversary-in-the-middle reverse proxy or a device-code OAuth flow in the Princeton Advancement incident. Princeton describes a fake university login page and a Duo prompt under live phone coaching. Treat Evilginx-style cookie harvest or device-code token handoff as unproven here unless a primary Princeton or forensic disclosure says otherwise.

Did Duo MFA actually protect the account?

Duo sent a push and the employee approved it under helpdesk-style pressure, so legacy MFA did what push MFA does when someone is coached live. Password plus an approve-able Duo prompt is still a transferable factor set on a spoofed sign-on page with a convincing OIT persona on the phone. The break is the phishable login path, not a missing “MFA enabled” checkbox.

What was accessed, and how long were attackers inside?

Princeton reports access to the Advancement and fundraising database. University notices discuss donors, alumni, and employees; public reporting does not establish one agreed victim-record total because those notices vary. The intrusion began midday 10 November 2025 and was blocked in under 24 hours. After a valid session exists, stopping further database use is containment and authorization work, not another login prompt.

Is OIT vishing plus a fake login the same class as helpdesk resets?

Yes. Coaching a workforce user to type a password and approve a Duo push on a fake page is the same social-engineering class as talking a helpdesk into a password reset or recovery secret. Both are live coaching of a transferable factor. The Marks & Spencer helpdesk password-reset case is the reset branch of that pattern. A fix that removes phishable passwords and coachable push from workforce login exists; the companion prevention piece covers that without rehashing this incident’s timeline.