Real-time OTP harvest on typosquat fake Okta pages is what let the Twilio 0ktapus smishing path mint workforce sessions in mid-July 2022. Smishing texts posing as Twilio IT steered employees onto attacker-controlled IdP lookalikes where passwords and OTP or 2FA codes were collected live; phishing-proof device-bound MFA closes that path because no phishable code exists to type on a wrong-origin page. According to Twilio's incident report, unauthorized access ran through 9 August 2022 and residual impact hit 209 Twilio customers and 93 Authy end users. Closing the phishable login stops the kit from minting the session. Malware after a legitimate login is a harder, separate problem. The full attack chain is on legacymfa.sucks.
FAQ
Would phishing-proof MFA have stopped the Twilio 0ktapus login?
Yes. The Twilio 0ktapus initial access depended on employees typing passwords and OTP or 2FA codes on attacker-controlled fake Okta pages, with 0ktapus/Scatter Swine-style tooling harvesting those factors live. Phishing-proof MFA 2.0 uses device-bound public-key credentials with no phishable OTP, SMS code, or push to type or approve on a wrong-origin page, so the real-time harvest cannot finish a legitimate workforce sign-in. Closing that phishable login stops this path. That is prevention, not detection.
Why are passkeys alone not the full fix for this smishing class?
Passkeys and WebAuthn are phishing-resistant at the login ceremony: origin-bound signatures stop a reusable secret on a fake Okta page. They do not automatically make enrollment, recovery, and every other lifecycle stage phishing-proof if phishable factors remain elsewhere. MFA 2.0 is phishing-proof across registration, device onboarding, authorisation, authentication, and decommissioning, so a smishing lure has no transferable factor to coach. For Twilio 0ktapus the decisive failure was a phishable OTP at login; full-lifecycle coverage removes the broader class, not only the password field.
Does MFA 2.0 undo Twilio admin-tool access after the session exists?
No. Once the phished Okta path had already succeeded and attackers used internal admin tools, that phase is post-authentication session use. No login MFA undoes data access after authentication has completed. According to Twilio's final investigation, residual impact reached 209 Twilio customers and 93 Authy end users. Prevention value is upstream: stop the smish from minting the session. Revoke and containment remain hygiene when a token is already out. Public reporting does not establish a ransom demand for this incident.
How does device-bound MFA block real-time OTP harvest on typosquat IdP pages?
Real-time OTP harvest kits win when the victim types a reusable second factor on a spoofed or proxied IdP page and the kit replays it before it expires. Device-bound phishing-proof MFA never issues a network-transiting OTP or approval the kit can steal. The private key stays on the enrolled device and signs only for the legitimate origin. A typosquat fake Okta page is the wrong origin and has nothing transferable to collect. The device-bound architecture removes that harvest surface at the credential phase.
What still matters after you close the Twilio-style smishing login?
After phishing-proof MFA closes the fake Okta OTP path, treat residual risk honestly. Tokens already stolen need revoke and containment. Okta-style SSO still amplifies blast radius across admin tools and apps once any session exists; Secure Explicit Sign-On issues per-app device-bound proofs instead of one replayable federation cookie. Endpoint malware after a legitimate login remains a harder problem no login control erases. Fooling a user into a proxied login is easy. Planting malware is not.
