A phone call and a familiar-looking login form still beat most workforce MFA stacks. Over a five-week campaign that built phishing infrastructure against more than 200 organizations, attackers used voice phishing to push employees onto spoofed login pages and harvest passwords plus MFA codes. According to Reuters reporting that places a Levi Strauss cybersecurity event inside that wider wave, the product of the attack was transferable employee secrets, not a novel exploit. Phishing-proof, device-bound authentication removes those secrets so a live caller and a fake portal cannot complete workforce login for the attacker.
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 described as 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 to make the initial collection step work. 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 in the material used here. Treat those as unknown until primary disclosures say otherwise.
Named company filings in this wave, including Levi Strauss, are listed under Updates. If you want more detailed information about this attack, read 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. An operator contacts an employee, builds authority or urgency, and steers that person to a URL the attacker owns. Once the employee lands on a clone of the corporate IdP or portal, the ceremony looks normal: username, password, then the second factor the organization already trained people to produce on demand. OTP codes, SMS codes, email codes, and many push-style approvals are transferable. If the employee can read, type, paste, or approve the factor under pressure, the attacker can replay it on the real service in real time.
An adversary-in-the-middle attack is a hostile page or proxy that sits 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 to a stranger. The five-week duration also matters for defenders. Building 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. Related parent coverage of 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.
How phishing-proof authentication 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, and live vishing pressure has nothing transferable left to harvest.
That is a credential-phase win. The attacker never completes the login ceremony remotely, so the usual follow-on scramble (forced resets, emergency re-enrollment, session revocation theater) is 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 device-bound MFA | 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.
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. Fooling someone on a phone call is easy. Planting malware is not. Closing the phishable login is the prevention claim for this wave. 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.
Key Takeaways for Defenders
- Treat vishing into spoofed workforce portals as a credential-phase failure, not a mysterious “MFA bypass” abstraction.
- Inventory which remote login paths still accept passwords, OTP, SMS, email codes, or fatigueable push.
- Prefer device-bound, origin-bound signatures so employees have nothing transferable to dictate on a call.
- Do not count “MFA enabled” as done if the second factor can be typed into a hostile page.
- Keep session revoke and short lifetimes as residual controls for malware-grade theft, not as the answer to live code harvest.
The durable lesson from a campaign framed around more than 200 organizations is simple. 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 have stopped the five-week vishing wave?
Phishing-proof, device-bound MFA would have stopped the credential harvest that defined the five-week vishing wave, because employees would have had no password or MFA code to type into a spoofed workforce login page under phone pressure. According to public reporting via 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. For the five-week voice-phishing wave against more than 200 organizations, that login hardening is phishing-resistant and directly targets the transferable-code failure. 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?
Shorter session lifetime does not fix vishing-driven credential harvest in campaigns like the five-week wave that targeted more than 200 organizations, because lifetime limits act after a login secret has already been stolen and used. The public technique class 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 or re-use after a phishable login already succeeded.
What should CISOs change first after a campaign like this 200-plus organization wave?
CISOs should first eliminate phishable workforce login factors on the paths employees actually use under urgency, including any portal that still accepts passwords plus OTP, SMS, email codes, or fatigueable push. The five-week vishing wave shows that scale comes from infrastructure plus transferable secrets, not from a rare exploit. Pair that factor removal with enrollment rules that refuse phishable re-issuance, then keep revoke tooling for residual endpoint malware cases.
Is voice phishing out of scope for authentication redesign?
Voice phishing is not out of scope for authentication redesign when the call’s job is to drive employees onto spoofed login pages that collect workforce credentials and MFA codes, as reported in the five-week wave affecting more than 200 organizations. The telephone is 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-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.
