According to Okta's Newsroom on 15 December 2025, threat cluster O-UNC-034 (the payroll pirates) socially engineered IT helpdesks by phone, reset employee passwords, re-enrolled attacker-controlled MFA factors, then altered payroll banking in HR apps across a multi-organization workforce cluster. Phishing-proof MFA 2.0 treats recovery and factor enrollment as high-assurance events, so a vished helpdesk cannot hand the attacker a new password plus attacker-owned factors on weak phone verification alone. Once the account is already under attacker control, changing banking details in Workday, Dayforce, or ADP is authorization abuse no login MFA undoes. For the full attack-chain chronology, read the companion on legacymfa.sucks. The same recovery class showed up earlier in the M&S helpdesk password-reset case.

FAQ

Would phishing-proof MFA 2.0 have stopped O-UNC-034 helpdesk resets?

Yes. Phishing-proof MFA 2.0 would have stopped the O-UNC-034 credential-phase path because recovery and MFA factor enrollment cannot complete from a phone call with weak caller identity proofing alone. According to Okta's December 2025 Newsroom reporting, attackers obtained password resets through helpdesk social engineering, then enrolled factors they controlled (paths such as Okta Verify, SMS, voice, or security questions after the reset). Device-bound credentials leave no transferable password, OTP, SMS code, push approval, or recovery secret for IT to read out or re-issue on that call. Closing the phishable recovery path stops this attack. Public reporting does not establish reverse-proxy kits as the mechanism in this cluster.

How does MFA 2.0 block attacker MFA factor re-enrollment after a reset?

MFA 2.0 blocks O-UNC-034-style factor re-enrollment by requiring an already-enrolled device for adding or replacing authenticators, not a phishable enrollment code or helpdesk-issued secret. After a legacy helpdesk password reset, attackers bound the account to their own second factors, so later logins succeeded without another helpdesk call. That is persistence at enrollment, the same social-engineering class as coaching a user through a fake login. Protected enrolment removes transferable enrollment secrets across registration, device onboarding, and recovery. Passkeys that only harden the login ceremony still leave a gap if recovery stays phone-driven and phishable.

Why can't MFA stop payroll banking changes after account takeover?

MFA cannot stop O-UNC-034 payroll banking changes after account takeover because that step is authorization abuse inside HR apps, not another authentication challenge. With full control of the employee identity, attackers altered direct-deposit details in applications such as Workday, Dayforce, or ADP so paychecks could be diverted. No login MFA undoes in-app actions once someone authenticates as the employee. Prevention value sits upstream: block the helpdesk reset and factor replacement so the attacker never holds a legitimate session. HR-side change controls, out-of-band verification for banking edits, and monitoring remain separate from authentication. Public reporting does not establish quantified paycheck totals for the cluster.

Are passkeys enough if helpdesk recovery still uses phone proofing?

No. Passkeys alone are not enough for O-UNC-034-style attacks if helpdesk recovery still uses phone proofing and phishable factor replacement. Passkeys are phishing-resistant at the login ceremony. They do not automatically protect enrollment, device onboarding, or recovery when those stages still accept SMS, voice, email codes, or helpdesk-issued secrets. MFA 2.0 is phishing-proof across the identity lifecycle, so the same rules that block a coached fake login also block a vished helpdesk from minting attacker-owned factors. Ladder in plain terms: password and OTP sit below phishing-resistant login, which still sits below full-lifecycle phishing-proof recovery.

What should CISOs change first against helpdesk payroll vishing?

CISOs should first remove phishable recovery secrets and gate MFA factor replacement behind an already-enrolled device, then harden helpdesk identity proofing so a phone call cannot reset workforce access alone. For O-UNC-034 payroll pirates activity, Okta framed a multi-organization workforce-identity cluster with cross-sector exposure; public reporting does not name victim employers or a precise org count. Prevention, not detection is the right order: stop the transferable factor at recovery before investing in after-the-fact revoke theater. Token revoke and HR banking controls stay hygiene for residual sessions and in-app abuse, not a substitute for closing the helpdesk enrollment path.