On 29 June 2022 a Twilio employee was talked into handing over credentials on a live voice phishing call. That credential-phase win was enough to reach customer contact information for a limited number of customers. Twilio cut the access in about 12 hours. Later Twilio incident reporting concluded the same malicious actors were likely behind the larger mid-July and August 2022 smishing wave often tied to the 0ktapus family. Public reporting does not establish an exact affected-customer count, which internal systems were hit beyond customer contact data, or how any second factor was handled on the call.
If you want the prevention angle, read the related article on mfa2point0.com.
FAQ
How did attackers get into Twilio on 29 June 2022?
Attackers got into Twilio on 29 June 2022 by voice phishing a Twilio employee into providing their credentials. That is a credential-phase win: a live call socially engineered a transferable secret the employee could speak or type. Public reporting does not name a spoofed login page, device-code flow, TAP, or AiTM reverse proxy for this June path. With a valid employee login in hand, the actor did not need a separate post-auth malware plant to start looking at customer contact data.
What data did the Twilio June 2022 vishing reach?
The Twilio June 2022 vishing reached customer contact information for a limited number of customers. Public reporting does not establish an exact customer count or a full inventory of internal apps beyond that contact data. Twilio identified and eradicated the access within about 12 hours, so the dwell window on that path was short, not multi-week silent persistence.
Was the June Twilio vishing the same campaign as the later 0ktapus smishing?
Twilio’s later August and October 2022 reporting concluded the same malicious actors were likely responsible for both the June employee-vishing incident and the larger mid-July through August 2022 smishing campaign against Twilio-related targets. Treat June as the earlier credential-handoff event and the summer smishing wave as the broader follow-on campaign from the same actor family, not as a duplicate write-up of one login. The June path was voice-driven credential transfer from an employee; the later wave was SMS-driven social engineering at scale.
Did MFA stop the Twilio employee vishing call?
Public reporting does not establish whether MFA was enrolled on the targeted Twilio employee account or how any second factor was handled on the 29 June 2022 call. What the disclosure does establish is that credentials were obtained through vishing and were sufficient to reach limited customer contact data. Any factor an employee can read out, type, or approve under live coaching on a phone call is still a transferable secret. That is the same social-engineering class as coaching someone through a fake login: the attacker is harvesting a factor a human can hand over, not forging a hardware-bound signature.
Would closing the phishable login have stopped this Twilio path?
Yes. Closing the phishable login stops this path. If authentication cannot complete from secrets and prompts an employee can speak, type, or approve on a vishing call, the actor never receives a usable workforce session and never reaches the customer-contact systems touched in this incident. A fix for that verbal credential-transfer surface exists; the prevention write-up is on the companion site. Malware after a legitimate login is a harder, separate problem, and it is not what public reporting describes for this June Twilio access.
