A stranger on the phone. A fake login page. The MFA code you type finishes their login.
According to Reuters reporting that places a Levi Strauss cybersecurity event inside a wider wave, attackers spent five weeks building phishing infrastructure against more than 200 organizations, then used voice phishing to steer employees onto spoofed workforce login pages and harvest passwords plus MFA codes. The product was transferable employee secrets, not a novel exploit.
Training people to be careful does not fix a factor designed to travel. MFA 2.0 leaves nothing to read out, type, or approve for a stranger.
What the 200-organization vishing wave harvested
Public reporting describes a multi-week effort to stand up phishing infrastructure against more than 200 organizations, then use voice phishing to steer employees to spoofed workforce login pages. The harvested material is credentials and MFA codes. Levi Strauss appears among the organizations placed in that public campaign frame. Shared threat-actor attribution has not been officially confirmed by Levi Strauss, and per-organization forensic detail remains thin.
That thinness does not blur the authentication problem. The campaign did not need malware on the endpoint for the initial collection step. It needed employees who could still type a reusable password and produce a one-time factor on a page the attacker controlled, while a caller applied urgency. Affected record counts, ransom figures, industry breakdowns, and exact calendar start and end dates for the five-week window are not established here. Treat those as unknown until primary disclosures say otherwise.
Named company filings in this wave, including Levi Strauss, are listed under Updates. For the attack-side walkthrough, see the related post on legacymfa.sucks: five-week vishing harvested MFA codes at 200 orgs.
Why transferable MFA codes still completed the login
The failure sits in the credential phase. Authentication for the attacker is still ahead. The spoofed page and the phone call exist to collect the material that finishes it.
Voice phishing is social engineering over a live call. The employee must judge whether the caller is legitimate. Humans make mistakes. Same problem as credential phishing. Training does not fix a factor an employee can still hand to a stranger.
Once the employee lands on a clone of the corporate IdP or portal, the ceremony looks normal. OTP codes, SMS codes, email codes, and many push-style approvals leave the device as something a human can read, paste, or approve. If it can leave under pressure, an attacker can replay it.
An adversary-in-the-middle attack is a hostile page or proxy between the user and the real login service so secrets and one-time proofs can be captured as the user produces them. Public coverage of this wave emphasizes spoofed login pages and harvested MFA codes. It does not establish cookie theft, OAuth token replay, Golden SAML, or other post-authentication persistence as confirmed facts for the full 200-plus set. Analyze what reporting actually documents: passwords and MFA codes collected before the attacker's own authenticated session would be issued.
| Factor class | What the caller needs | Why a spoofed page wins |
|---|---|---|
| Password | Employee types it | Reusable, origin-agnostic secret |
| OTP / SMS / email code | Employee reads or pastes it | Transferable one-time secret |
| Push-style approval | Employee accepts under pressure | Human-approved, not origin-bound |
| Device-bound private key | Nothing the employee can dictate | Private key never leaves hardware |
Checkbox "MFA enabled" metrics do not survive this table. Coverage is irrelevant if the covered factor is still something a stressed employee can hand over. Five weeks of infrastructure against more than 200 organizations is time to tune domains, page kits, caller scripts, and target lists while many enterprises still treat the voice channel as softer than email filtering. The companion on how vishing plus spoofed login pages harvested employee credentials shows the same factor-class failure at company scale.
Nothing in the public framing requires every victim to have used the same vendor product. The durable weakness is the factor class, not a single brand name. If the second factor can be dictated over the phone or typed into a hostile form, the spoofed portal remains a collection point.
This wave is not a helpdesk TAP-reset story. Public reporting describes callers steering employees onto spoofed pages and harvesting login secrets there. Keep those two vishing directions separate.
How phishing-proof MFA 2.0 removes that surface
Prevention starts where the wave collected value. Device-bound, origin-bound authentication issues no password the employee can type and no code the employee can read to a caller. The private key stays on the enrolled device. The signature the identity provider accepts is bound to the legitimate origin. A spoofed page on an attacker domain cannot obtain a usable assertion for the real workforce IdP. Live vishing pressure has nothing transferable left to harvest.
That is a credential-phase win. The attacker never completes the login ceremony remotely, so forced resets, emergency re-enrollment, and session revocation theater are not the primary control story. Those steps matter after a phishable login already succeeded. They are residual hygiene, not a substitute for removing the secrets the kit was built to steal.
| Control | Against vishing + spoofed portal | Against later malware token theft |
|---|---|---|
| Password + OTP / push | Fails; secrets are transferable | N/A; login already lost |
| Phishing-resistant passkey at login only | Strong at ceremony if enrolled cleanly | Does not stop endpoint malware |
| Phishing-proof MFA 2.0 | Removes harvestable login secrets | Residual endpoint problem only |
MFA 2.0 is phishing-proof across the identity lifecycle because no phishable factor is used at registration, device onboarding, authorisation, authentication, or decommissioning. The private key never transits the network. The server stores public keys, not symmetric OTP seeds that become a single database prize. Same-device cryptography means the employee is not juggling a second gadget just to produce a code a caller can request. No support call needed to "fix" MFA under urgency. There is nothing to coach onto a fake page.
Contrast that with revoke-and-detect thinking. Shortening session lifetime does not stop a vishing-driven harvest. It only narrows how long a stolen session would last after a phishable login already worked. If the attacker never obtains the login material, lifetime knobs are secondary. Endpoint malware that steals a cookie after a legitimate login is a harder, different path. Tricking someone on a phone call costs an attacker little; malware on a signed-in endpoint costs far more. For this wave, a login with nothing to read out is what prevents the harvest. Keep revoke tools for the residual malware case.
The prevention-first architecture is the point: stop the transferable secret from existing, rather than racing to detect its abuse after a five-week infrastructure build already paid off.
Passkeys and FIDO2 against spoofed workforce portals
Passkeys and FIDO2-style WebAuthn credentials put a key pair on the user device. The private key stays in hardware. The IdP verifies an origin-bound signature instead of a typed secret. Against the spoofed portals in this wave, that login ceremony is phishing-resistant: a fake host should not receive a signature meant for the real enterprise issuer. Illustrate it on a generic enterprise IdP that only accepts hardware-bound signatures, not on a consumer tech login hostname. Fresh signature demand per login is the mechanical break with OTP paste and push taps.
The enrollment gap after a vishing-driven harvest
This wave did not need a helpdesk re-enrollment story to make sense. Public reporting describes credential and MFA code harvest on spoofed pages, which means the login factors themselves were already phishable. Still, passkeys alone are phishing-resistant at authentication only. If enrollment, device add, or recovery falls back to email OTP, SMS, or push, an attacker who later controls those channels can register their own authenticator and look legitimate forever after. MFA 2.0 is phishing-proof because phishable factors are barred at every lifecycle stage, including enrolment. Closing login without closing issuance leaves a second door.
Callers harvest what employees can still produce. Remove the producible secrets and the five-week infrastructure investment stops paying at the login form.
FAQ
Would phishing-proof MFA 2.0 have stopped the five-week vishing wave?
Yes, at the credential harvest. Employees would have had no password or MFA code to type into a spoofed workforce login page under phone pressure. According to Reuters, attackers built phishing infrastructure against more than 200 organizations and used vishing to collect credentials and MFA codes. Origin-bound private keys do not transit a fake portal, so the attacker never completes remote workforce authentication that way.
Do passkeys alone stop spoofed login page MFA code harvests?
Passkeys stop spoofed-page code harvests at the login ceremony when authentication itself is WebAuthn-bound and users are not falling back to OTP or push. That login hardening is phishing-resistant. Passkeys alone do not automatically secure enrollment, device add, or recovery. MFA 2.0 is phishing-proof across the full identity lifecycle, which is the stronger bar when operators later try re-issuance paths.
Why doesn’t shorter session lifetime fix vishing-driven credential harvest?
Lifetime limits act after a login secret has already been stolen and used. The public technique class here is collection of passwords and MFA codes on spoofed pages. Prevention removes those transferable factors so the attacker never obtains a session through that kit. Lifetime tuning only forces faster re-theft after a phishable login already succeeded.
What should CISOs change first after a campaign like this 200-plus organization wave?
Eliminate phishable workforce login factors on the paths employees actually use under urgency: passwords plus OTP, SMS, email codes, or fatigueable push. Pair that with enrollment rules that refuse phishable re-issuance. Keep revoke tooling for residual endpoint malware cases, not as the answer to live code harvest.
Is voice phishing out of scope for authentication redesign?
No. When the call's job is to drive employees onto spoofed login pages that collect workforce credentials and MFA codes, the telephone is only the delivery system. The authentication stack decides whether the employee still holds secrets worth collecting. Redesign the factors, and the caller loses the product even if the social script stays sharp.
Updates
2026-09-14: Related disclosure
The Cloaked Ursa (APT29) disclosure frames Microsoft Teams credential-harvesting and fake Entra ID tenant lures as continued proof that authentication remains the decisive control surface in voice-phishing follow-on activity.
Source: unit42.paloaltonetworks.com, Cloaked Ursa (APT29) Teams-based attacks
2026-08-31: Named victim filing
Jack Henry’s disclosure that a ShinyHunters vishing wave reached a limited non-production internal environment underscores how voice phishing still converts human trust into access even when core and client-facing systems stay isolated.
Source: ir.jackhenry.com, Jack Henry
2026-08-28: Named victim filing
McKesson’s disclosure of an incident discovered 25 August 2026, with unauthorized access to third-party apps and unconfirmed ShinyHunters claims that voice phishing compromised Okta SSO en route to Salesforce and Snowflake, keeps workforce voice-phishing against SSO at the center of the authentication story in this wave.
Source: BleepingComputer, McKesson
2026-08-23: Named victim filing
ReliaQuest’s filing shows that after a vishing-driven password entry and MFA push approval, device-trust still confined the session to a brief view-only identity dashboard and blocked app access and new authenticator enrollment.
Source: reliaquest.com, ReliaQuest
2026-08-21: Named victim filing
Apollo Global Management’s filing ties a July 2026 cloud intrusion and theft of SSNs and other personal data to the same helpdesk-vishing wave that harvested passwords and live MFA codes, while leaving the firm’s MFA method unnamed.
Source: techcrunch.com, Apollo
2026-08-07: Named victim filing
Levi Strauss & Co. disclosed in an SEC Form 8-K that social engineering reached three company-issued computers and certain corporate information was taken, with no consumer data impact.
