A few weeks apart, Twilio and Cloudflare described SMS phishing campaigns that looked remarkably similar. The messages posed as internal communications and led employees to fake Okta pages. People entered their credentials in both cases. What happened next is where the stories split.
- SMS impersonating an internal team
- credentials entered on a fake page
- access to internal tools
- customer information affected
- SMS and fake Okta page
- three employees entered credentials
- hardware key still required
- no system compromise reported
What happened at Twilio
Twilio’s final report, published on 27 October 2022, says that current and former employees received messages impersonating IT or administrative functions. After credentials were entered on the fake pages, the attackers used them to reach internal tools and some customer information.
Twilio reported that 209 customers and 93 Authy users were affected. These are separate categories, not two figures that can be combined into one neat count. The more useful observation concerns the reach of an internal account: a small number of compromised staff accounts can expose people who never saw the original phishing message.
The public report does not provide every authentication rule in place at the time. I would rather leave that gap visible than claim that Twilio had “no MFA”. What is documented is that usable access was obtained. The response included credential resets, session revocation, blocked indicators and efforts to remove the fraudulent domains.
Why Cloudflare stopped one step earlier
Cloudflare dates its campaign to 20 July 2022. Three employees entered their credentials on the fake page. The targeted applications still required proof from a physical security key, which the phishing page could not create for the real service. Cloudflare said it found no compromise of its systems in this incident.
Those three submissions still matter because the lure worked on a human level. They did not have the same effect as a successful sign-in. The technical control absorbed the mistake and stopped the next transition.
That protection depends on coverage. A security key helps little if a forgotten application accepts a weaker method, account recovery bypasses the requirement, or an exception becomes the usual route. Cloudflare later published a separate account of how it rolled out FIDO2 across its applications.
A useful comparison with limits
This was not a controlled experiment. The users, permissions, applications and public disclosures were different. Both accounts were written by the organisations involved, with their own choices about what to publish.
The comparison still isolates one concrete difference. At Cloudflare, the captured password was not enough to pass the next step. At Twilio, an internal account became usable. That does not rank the companies as a whole. It shows the value of authentication proof bound to the service receiving it.
Permissions still matter after sign-in
The login screen is only one boundary. Support and administration accounts may reach information belonging to many customers. Least privilege reduces that reach through task-specific permissions, temporary access for sensitive operations and logs detailed enough to reconstruct what was viewed.
I keep three measurements separate: did someone respond to the lure, did the attacker gain access, and did that access cause harm? Folding all three into a single “human failure rate” hides the most useful part of these incidents.