What Happened, Day by Day
Most coverage of the Twilio incident compresses it into a single sentence about phishing. The sequence is more useful than the summary, because each step is a point where a different control would have changed the outcome.
| Date | What happened | What it tells you |
|---|---|---|
| 29 June 2022 | A Twilio employee was talked into handing over credentials during a voice phishing call. The attacker used the access to view limited customer contact information. This was found later, during the August investigation. | The phone call came first. The same people, or people using the same methods, had already tested the organisation by voice. |
| Late July to early August | Current and former employees received text messages impersonating Twilio IT, warning of expired passwords or schedule changes, with links to lookalike sign-in pages. | The attackers had employee mobile numbers, probably gathered from data brokers and earlier breaches rather than from Twilio itself. |
| 4 August 2022 | Twilio detected unauthorised access to internal systems using stolen employee credentials. | Detection took days, not months, which limited the damage considerably. |
| 7 August 2022 | Twilio published an initial notice describing the SMS phishing campaign. | Public disclosure within three days of detection. Faster than most. |
| 9 August 2022 | Last observed unauthorised activity. | Five days inside the environment was enough to reach customer accounts. |
| Late August | Affected customer count revised upward as the investigation continued, and Authy impact disclosed. | Early numbers in any breach are a floor, not a ceiling. |
| October 2022 | Final report: 209 customer accounts accessed, 93 Authy users with devices added, no evidence customer passwords, authentication tokens or API keys were taken. | A small percentage of a very large customer base, and a very large problem for the customers concerned. |
Two details in that table deserve more attention than they usually get. The first is the June phone call. Before anybody sent a text, somebody rang a Twilio employee and got what they needed by talking. The second is the percentage. 209 customers out of more than 270,000 is well under a tenth of one per cent, and if you were one of the 209 the percentage is irrelevant. For those customers, a breach at their supplier became a breach of their own users, and they had done nothing wrong.
Anatomy of the Text Message
The messages worked because they were built around ordinary workplace anxiety rather than technical trickery. It is worth taking them apart, because the same structure turns up in the scam texts Australian businesses receive every day.
A trusted sender
The text claimed to be from the company's own IT department. Staff are trained to be suspicious of strangers. They are trained to cooperate with IT.
A plausible deadline
An expired password or a changed shift. Both are routine, both feel urgent, and neither sounds like a scam. Nobody wants to be the person locked out on Monday.
A familiar address
The links used domains such as twilio-sso.com and twilio-okta.net. On a phone screen, with the address bar half hidden, that reads as official.
A perfect copy
The page mirrored the real single sign-on screen, logo and all. There was nothing on it for a careful person to notice.
Notice what is missing from that list: bad spelling, a foreign prince, an obviously fake logo. The awareness training most businesses run is built around catching clumsy scams, and this was not clumsy. It was also delivered by SMS to a personal mobile, which matters for three reasons. A phone screen shows less of the web address than a desktop browser. Personal phones sit outside most corporate email filtering and link scanning. And people read texts faster and with less suspicion than email, because for most of us a text still feels like a message from someone we know.
The attack did not target Twilio's technology. It targeted the gap between what employees had been taught to distrust and what actually arrived on their phones. That gap exists in almost every business, and it is widest in small ones, where there is no security team filtering anything and where staff routinely use personal mobiles for work.
Why One-Time Codes Did Not Help
Twilio had multi-factor authentication in place. So did most of the other organisations hit by the same campaign. It did not stop the attackers, and understanding why is the single most practical lesson in this whole story.
A one-time code, whether it arrives by SMS or is generated by an authenticator app, proves that the person typing it has access to the phone at that moment. It does not prove where they are typing it. When an employee entered their username, password and code into the fake page, the phishing kit behind it passed all three to the attackers straight away, and the attackers used them on the real sign-in page within the code's short life. Researchers at Group-IB, who studied the wider campaign, found the kits forwarding captured details in real time for exactly this purpose.
| Step | What the employee saw | What was really happening |
|---|---|---|
| 1 | A text from "IT" with a link. | The attacker's message, sent to a number bought or scraped elsewhere. |
| 2 | The normal company sign-in page. | A copy on a lookalike domain, controlled by the attacker. |
| 3 | Enter username and password. | Credentials sent to the attacker instantly. |
| 4 | A prompt for the six digit code. | The attacker had already tried the real site, which sent the real code to the real phone. |
| 5 | Type the code. Page says "success" or quietly fails. | The attacker uses the code on the real site and is signed in as the employee. |
This is called a relay or adversary in the middle attack, and it defeats every form of authentication where a human reads something and types it somewhere. SMS codes, authenticator app codes and approve-this-sign-in push notifications are all vulnerable to it, to different degrees. What it cannot defeat is a method where the browser itself checks which website is asking before it answers. That is the difference between ordinary multi-factor authentication and phishing-resistant authentication, and the next section on Cloudflare shows it working under real attack.
The Blast Radius Downstream
Once inside, the attackers used Twilio's internal tools to look at customer accounts. The pattern of what they looked at says a lot about why they were there.
Signal. The encrypted messaging app used Twilio to send the SMS codes that verify a phone number when someone registers. Signal disclosed that for around 1,900 users, either their phone number was potentially revealed as registered to Signal, or the SMS registration code was exposed. It also said the attacker explicitly searched for three particular numbers, and that one of those three users reported their account had been re-registered on another device. Message history, contacts and profile details were not exposed, because Signal does not hold them in a form Twilio could reach. Signal's advice afterwards was to turn on its Registration Lock, a PIN that has to be entered before a number can be moved to a new device.
Authy. Twilio's own two-factor app had 93 users whose accounts had additional devices registered without their consent. For a two-factor app, that is the worst category of compromise, because an extra device can receive the codes that protect everything else.
The wider campaign. Twilio was not the only target. Group-IB named the operation 0ktapus, after the Okta sign-in pages it imitated, and linked it to more than 130 organisations and close to 10,000 captured credentials. Several victims were technology and communications companies whose own customers became the real prize. Twilio called the actor Scatter Swine, and researchers have since widely linked the same people and methods to the group known as Scattered Spider, whose later campaigns have relied heavily on phone calls to help desks.
Why a communications platform is such an attractive target
A platform that sends verification codes, carries calls and holds phone numbers is a skeleton key. Getting into one gives access to the SMS codes, numbers and message routing of every business that uses it, and through them to those businesses' customers. The attackers in 2022 were almost certainly not interested in Twilio's data for its own sake. They wanted what Twilio's position let them reach.
Same Texts, Different Outcome
The most instructive part of the whole episode happened at a different company. Cloudflare, the internet infrastructure firm, received almost identical text messages at around the same time. Seventy-six employees, and in some cases their family members, were targeted. Three of them clicked the link and typed their credentials into the fake page. Nothing happened.
Nothing happened because Cloudflare staff did not sign in with codes. They used FIDO2 hardware security keys, small physical devices that plug into a computer or tap against a phone. When a site asks a FIDO2 key to confirm a sign-in, the browser tells the key which website is asking, and the key will only respond to the site it was registered with. A lookalike domain gets nothing. There is no code for an employee to type and therefore nothing for a phishing page to capture and relay.
76
Cloudflare employees targeted with the same style of text message
3
Entered their credentials into the phishing page
0
Accounts compromised, because the second factor was a hardware key bound to the real site
This matters because it separates two questions that usually get blurred. The first is whether your staff will ever be fooled. The honest answer is yes, some of them, eventually, however good your training is. Cloudflare's staff are about as security literate as a workforce gets, and three still typed their passwords into a fake page. The second question is whether being fooled leads to a breach. That one you can control, and Cloudflare's result shows how. Twilio reached the same conclusion afterwards and distributed FIDO2 tokens to all its employees, alongside tighter controls on VPN and administrative tools and more frequent re-authentication.
The 2024 Epilogue: 33 Million Numbers
Two years later Twilio was back in the news for a different reason. In late June 2024 the ShinyHunters group posted a file containing around 33 million phone numbers associated with Authy accounts. Twilio confirmed that attackers had compiled the list using an Authy interface that did not require authentication. The method was simple: feed in a huge list of phone numbers, and the interface would confirm which ones had Authy accounts, along with basic account details. Twilio secured the endpoint and asked users to update their apps.
No passwords or codes were taken, and it is tempting to shrug at a list of phone numbers. That would be a mistake. A confirmed list of people who use a two-factor app is a targeting list for exactly the attacks described above: a text impersonating Authy support, a SIM swap attempt, a phone call from a fake help desk. The ShinyHunters group, incidentally, is the same name behind the 2026 extortion campaign that hit RingCentral and many other companies through social engineering. The techniques have moved on from text messages to phone calls and help desk impersonation, and the underlying idea has not moved at all: people are easier to get past than systems.
A phone number is not a secret, and that is the point
Businesses often use a mobile number as if it were a credential: the thing that receives the reset code, the thing that proves identity on a support call. Phone numbers are printed on business cards, leaked in every major breach and now verifiable in bulk. Anything in your business that treats possession of a number as proof of identity should be treated as a weak point, not a control.
Your Provider Is in Your Trust Chain
Here is the part that turns a four year old American incident into a live question for an Australian business. When you send an appointment reminder, a verification code or a two-way text to a customer, that message travels through a provider. When a customer rings your number, the call is routed by a provider. Your customers trust the message or the call because they trust you. They have no idea who the provider is, and they should not need to.
That trust flows straight through the provider's internal security. If someone can get into your provider's support tools, they may be able to see which of your customers you text, read message content, redirect a number, or send messages that appear to come from you. Signal's users did not choose Twilio. Signal did, and its users carried the consequences.
| What your provider holds | What an intruder could do with it | Who gets hurt |
|---|---|---|
| Your numbers and their routing | Divert calls or SMS to another destination, including verification codes. | Your customers, who reach someone who is not you. |
| Message logs and content | Read what you send and receive, including codes and personal details. | Your customers, and you under the Privacy Act. |
| Call recordings and transcripts | Access conversations that contain payment details, health information or account data. | Your customers and your staff. |
| Your sender identity | Send messages that appear to come from your business. | Your reputation, and any customer who believes the message. |
| Your contact lists | Build targeting lists for scams impersonating you. | Your customers, long after the breach is closed. |
None of this means a big international platform is less secure than a small local one. Twilio responded quickly, disclosed openly and fixed the underlying weakness properly. It means that when you choose a communications provider you are choosing part of your own security, and it is reasonable to ask how they protect the tools their staff use to manage your account. Most businesses never ask. We cover the broader picture in our VoIP security guide, and the questions specific to this incident are listed further down.
Ranking Your Sign-In Options
Every sign-in method sits somewhere on a scale from easy to phish to practically impossible to phish. The Twilio and Cloudflare results give that scale real-world evidence.
| Method | Stops password reuse? | Stops a relayed phishing page? | Stops SIM swap? | Verdict |
|---|---|---|---|---|
| Password only | No | No | Not relevant | Not acceptable for any business system in 2026. |
| SMS code | Yes | No | No | Better than nothing. Should not protect email, finance, admin or your phone system. |
| Authenticator app code | Yes | No | Yes | A clear step up from SMS. Still relayable, as 2022 showed. |
| Push approval | Yes | Partly | Yes | Vulnerable to people approving prompts they did not start. Number matching helps. |
| Passkey | Yes | Yes | Yes | Bound to the real site. The practical default for most staff where supported. |
| FIDO2 hardware key | Yes | Yes | Yes | Strongest widely available option. Use for admins and anyone with access to money or customer data. |
Passkeys are the development that makes this practical for small businesses in a way it was not in 2022. A passkey works on the same principle as a hardware key, bound to the real website, but it lives on the phone or laptop the person already has and unlocks with a fingerprint or face. Microsoft 365, Google Workspace and most major business platforms now support them. The Australian Signals Directorate's Essential Eight guidance also calls for phishing-resistant multi-factor authentication at its higher maturity levels, which is the direction regulators and insurers are heading.
A sensible order for a business of twenty to two hundred people: hardware keys for anyone with administrator rights, finance access or access to your communications platform settings, then passkeys for everyone on email and your core systems, then remove SMS as a fallback wherever you can. The fallback matters. An account protected by a passkey with SMS recovery switched on is only as strong as the SMS.
The Australian Picture in 2026
The Twilio incident happened in the United States, and the attacks it represents are thoroughly local now. SMS impersonation of banks, toll roads, delivery companies and government services is one of the most reported scam types in Australia, and the regulatory environment has changed a great deal since 2022 in response.
| Rule or scheme | What it does | What it means for your business |
|---|---|---|
| SMS Sender ID Register | Mandatory from 1 July 2026. Texts from unregistered alphanumeric sender names are labelled "Unverified" by carriers. | If you send branded SMS, your sender name must be registered, or your genuine messages look like scams. See our Sender ID Register guide. |
| Scams Prevention Framework | Makes banks, telcos and digital platforms legally accountable for preventing, detecting and responding to scams, with a telecommunications sector code and significant civil penalties. | Your providers are carrying more obligations, and you should expect more identity checks. See our Scams Prevention Framework explainer. |
| Customer identity authentication rules | ACMA rules require telcos to use multi-factor identity checks before high-risk transactions such as SIM swaps, number ports and account changes. | This is the Australian defence against the SIM swap that turns an SMS code into an attacker's code. Our customer identity authentication page explains how it applies to your account with us. |
| Notifiable Data Breaches scheme | Organisations covered by the Privacy Act must notify affected individuals and the OAIC of eligible data breaches. | A breach at your provider that exposes your customers' information can still land on your desk. Know what your contract says about notification. |
There is an uncomfortable irony in the Sender ID changes. They exist to make it harder for scammers to impersonate businesses by text, and they work. They also mean that an attacker who gets inside a legitimate provider, with access to registered sender identities, is in a much stronger position than one sending from a random number. The more a message is trusted, the more valuable it is to steal the ability to send it. That is the Twilio lesson restated for 2026. Our piece on the Unverified label covers the day to day side of this.
SIM swap fraud deserves a separate mention because it is the local attack that most directly defeats SMS codes. An attacker persuades a mobile carrier to move your number to a SIM they hold, and every code sent to "your phone" goes to them. The identity authentication rules have made this much harder in Australia than it was, and it still happens, usually by combining stolen personal details with a convincing story. If a staff member's work accounts are protected by SMS codes to their personal mobile, a SIM swap against that person is a breach of your business.
Training Staff for the Text, Not the Email
Most phishing training in Australian businesses is still built around email: hover over the link, check the sender address, look for bad grammar. The Twilio messages would have passed most of those tests, and they arrived somewhere the training never mentions.
Three rules cover most of what staff need, and they are short enough to remember.
Rule one: IT never sends a sign-in link by text. Make this true, then tell everyone. If your IT provider or internal team currently sends password reset links by SMS, stop. Then any text containing a sign-in link is fake by definition, and staff do not have to judge how convincing it looks.
Rule two: go to the site yourself. If a message says your password has expired, open the app or bookmark you normally use and check. Never follow the link to find out. This one habit would have stopped the Twilio attack at step one for every employee who followed it.
Rule three: report it, even if you clicked. The employees who typed their details into the fake page were not the problem. The delay before anyone knew was. A business where people report a mistake in five minutes without fear recovers. A business where they hope nobody notices does not. Twilio's detection within days was partly down to people noticing and saying so.
For the phone call version, which is the form the same attackers now prefer, the rule is simpler still: nobody is ever asked to read out a code, approve a sign-in or install remote access software because of an inbound call, including a call that appears to come from your own help desk number. Caller ID can be faked, and AI voice cloning makes the voice fakeable too. We cover that side in our guide to voice cloning and vishing.
Ten Questions for Any Communications Provider
These are the questions the Twilio incident suggests asking of whoever carries your calls and texts. A good provider will answer them plainly. Vague answers are an answer too.
| Question | What a good answer looks like |
|---|---|
| 1. How do your staff sign in to the tools that manage my account? | Phishing-resistant methods such as hardware keys or passkeys, not SMS codes. |
| 2. Who in your organisation can see my message content and recordings? | A small, named set of roles, with access logged. |
| 3. Can I see a log of access to my account? | Yes, or at minimum they will provide one on request after an incident. |
| 4. How do you verify me before a number port or account change? | Multi-factor identity checks consistent with ACMA rules, and a way to add extra protection. |
| 5. Where is my data stored, and who operates the systems? | A specific country and a specific operator. "The cloud" is not a location. |
| 6. How many other companies handle my calls and texts on the way through? | As few as possible, and they can name them. Every extra hop is another trust chain. |
| 7. How quickly will you tell me about an incident that affects my account? | A committed timeframe, in writing. |
| 8. Do your APIs require authentication on every endpoint? | Yes, without exception. The 2024 Authy exposure came from one that did not. |
| 9. Can I restrict who in my business can change routing and numbers? | Yes, with roles and approvals. |
| 10. Is your support team in-house, and where are they? | People you can reach, who work for the provider, and who are trained not to act on unverified requests. |
Question six is the one most businesses never think about. A cheap SMS service is often a reseller of a reseller, with your messages passing through several companies in several countries before they reach a carrier. Each of them holds some of your data and some of your customers' trust. Our overview of open APIs for voice and SMS discusses how to keep control of that chain when you integrate.
A Thirty Day Plan
| When | Action | Why it comes here |
|---|---|---|
| Week 1 | List every system where staff sign in with SMS codes. Start with email, banking, accounting, your phone system admin portal and your website. | You cannot fix what you have not counted, and the list is usually longer than expected. |
| Week 1 | Tell staff the three rules: IT never texts sign-in links, go to the site yourself, report it even if you clicked. | Costs nothing and closes the most common gap immediately. |
| Week 2 | Buy hardware keys for administrators and anyone with finance or communications platform access. Enrol two keys each, one as a spare. | These are the accounts an attacker actually wants. |
| Week 3 | Turn on passkeys for everyone on email and core systems. Remove SMS fallback where the platform allows. | Moves the whole workforce off relayable codes. |
| Week 3 | Send the ten questions to your communications provider and keep the answers. | You learn how much of your security sits with someone else. |
| Week 4 | Review how you verify customers. If you use SMS codes to confirm identity for account changes or payments, add a second check for anything high value. | Your customers face the same attack you do, and your process is their defence. |
| Week 4 | Check your SMS sender identity is registered, and that customers know what your genuine messages look like. | Makes impersonation of you harder and easier to spot. |
None of this needs a security team or a large budget. Hardware keys cost less than a staff lunch per person. Passkeys are free on the platforms you already pay for. The expensive part is the week of mild inconvenience while people get used to tapping a key instead of typing a code, and that is considerably cheaper than being on the wrong end of the next Twilio.
How We Approach This
Uniden Voice over Cloud carries calls and SMS for Australian businesses, which puts us in exactly the position this article describes: inside our customers' trust chain. We take that seriously in specific ways rather than general ones.
The platform is Australian owned, Australian hosted and Australian supported, so the number of companies and countries your calls and texts pass through is small and known. Business SMS is sent from your own recognised business number, which keeps your messages identifiable to customers under the Sender ID rules without relying on a chain of overseas gateways. Number ports and high-risk account changes go through identity checks that follow ACMA's customer identity authentication rules, and our support team is local and trained not to act on requests that cannot be verified, however urgent the caller sounds. Our AI features run inside the platform rather than being forwarded to a third party, so recordings and transcripts are not handed along a chain of providers.
We would rather you asked us the ten questions above than assumed the answers. If you want to go through them, or work out where SMS codes are still holding up your own business security, get in touch.