One coached phone call turned an employee password into a usable workforce login. On 29 June 2022, voice phishing against a Twilio employee yielded credentials that reached customer contact information for a limited number of customers before access was cut in about 12 hours. Closing the phishable login stops this path: phishing-proof, device-bound MFA 2.0 leaves no password, OTP, SMS code, or push an employee can speak, type, or approve on a call, so the actor never receives a usable workforce session. For the full attack-chain write-up, see the companion on legacymfa.sucks. Later Twilio incident reporting tied the same actor family to the broader mid-July and August 2022 smishing wave.
FAQ
Would phishing-proof MFA 2.0 have stopped the Twilio employee vishing?
Yes. Phishing-proof MFA 2.0 would have stopped the Twilio June 2022 employee vishing at authentication because that path depended on transferable credentials obtained on a live voice call. Device-bound keys never leave the enrolled hardware, produce origin-bound signatures, and give the employee nothing useful to read out or type under coaching. If that login cannot complete, the actor never reaches the customer-contact systems touched in this incident. Public reporting does not establish which second factor, if any, sat on the targeted account; any factor a human can hand over on a call still fails the same way.
Why do passwords, OTP, and push fail on a vishing call?
Passwords, OTP codes, SMS or email codes, and push approvals fail on a Twilio-style vishing call because they are transferable factors. A coached employee can speak a password, read a code, or tap approve while the attacker listens or waits. That is the same social-engineering class as coaching someone through a fake login page: live pressure harvests a factor a human can surrender. Prevention, not detection, means removing that surface entirely rather than hoping staff resist a polished IT pretext.
How is full-lifecycle phishing-proof MFA stronger than passkeys only at login here?
Passkeys and WebAuthn are phishing-resistant at the login ceremony when the private key stays device-bound and origin-checked. MFA 2.0 is phishing-proof across the identity lifecycle: registration, device onboarding, authorisation, authentication, and decommissioning use no phishable factor. For the documented Twilio June path, the decisive gap was verbal transfer of employee credentials at authentication. Closing every lifecycle stage still matters for related workforce attacks, including helpdesk password-reset social engineering, where recovery becomes the coached step.
What does device-bound authentication not undo after a Twilio-style session already exists?
Device-bound authentication does not undo work done with a session that already exists after a completed legitimate login. In the Twilio June 2022 case, public reporting describes credential-phase access from vishing, not malware planted on an already-signed-in PC. Closing the verbal credential path is the prevention claim. If an attacker later steals cookies via endpoint malware after a real login, that is a harder residual problem: revoke, short-lived sessions, and endpoint controls, not another prompt at a login that already succeeded.
Did public reporting prove AiTM, TAP, or device-code on the June Twilio call?
No. Public reporting does not establish AiTM reverse-proxy pages, Temporary Access Pass issuance, helpdesk reset coaching, or device-code OAuth flows for the 29 June 2022 Twilio employee path. What it does establish is voice phishing that obtained employee credentials and brief access to limited customer contact data, later linked by Twilio to the same malicious actors behind the summer smishing wave. Design controls for the verbal credential-transfer class anyway; the disclosure never named kit details.
