Twilio 2022 Breach and Transitive Access Through Vendor Credentials

The 2022 Twilio breach is usually filed under phishing, which is true only in the narrowest sense. It was a supply chain attack with a phishing entry point. The credential theft at Twilio was the door. The damage walked through it into organizations that never saw a phishing message themselves.

How a communications platform becomes a supply chain target

Twilio's position in the authentication ecosystem made it a target before any attacker sent a text message. The company delivers SMS verification codes and two-factor authentication to thousands of applications, which means a compromise inside Twilio lands directly on the security layer that other organizations delegated to it. That delegation was the vulnerability. Twilio operates two-factor authentication services including Authy, and a breach there does not merely expose one company's internal data. It undermines the authentication function itself across a customer base that had, at the time of the breach, more than 275,000 active accounts.

The framing matters because it changes what the breach teaches. A phishing story is about how attackers got in. A vendor access breach is about why so many others were harmed. The credential theft at Twilio was the entry point. The real damage flowed downstream to customers who never received a phishing message themselves. That is the structural difference between this event and a direct corporate hack. Twilio was not merely a corporate victim. It was a high-value intermediary, and the breadth of its customer dependency is what transformed a credential theft into a multi-organization exposure event.

How the attackers moved from SMS message to internal system access

The attack worked because the attackers relayed stolen credentials and one-time codes in real time. A fake login page captured credentials and one-time MFA codes simultaneously as employees entered them, then passed them instantly through a Telegram bot to the attackers. The codes were used while they were still valid. With the sequence, credential theft and account access happened at the same time.

The channel itself was also outside Twilio's defensive perimeter. SMS messages reached employees' personal phones directly, bypassing corporate email filtering entirely. The initial incident came to Twilio's attention on August 4, 2022, and a prior voice phishing attempt on June 29, 2022 was later linked to the same attackers. The timeline suggests a patient reconnaissance effort. Once inside, the attackers maintained access until August 9, 2022, a window of roughly five days in which internal systems were open to them.

The 0ktapus campaign that surrounded the Twilio breach

Twilio was not an isolated victim. It was one node in a deliberate, large-scale campaign designed to compromise identity and communications providers in order to reach their downstream customers. Per Group-IB, the campaign aimed to steal Okta identity credentials and two-factor authentication codes so it could carry out supply chain attacks later. Twilio was a means, not an end.

The campaign's infrastructure reflected that intent. Researchers identified 169 unique phishing domains supporting the operation, using keywords including "OKTA," "VPN," "HELP," "SSO," and "MFA." That is a purpose-built kit aimed at the identity and access management layer across many organizations, not an opportunistic spray. The campaign had been underway since at least March 2022, so attackers had months of reconnaissance and credential harvesting before Twilio detected it in August and before any downstream effect became visible.

The same campaign breached Mailchimp, which in turn exposed DigitalOcean's customer email addresses. Attackers obtained those addresses and in some cases initiated password reset requests on DigitalOcean accounts. DigitalOcean subsequently migrated away from Mailchimp entirely, with critical transactional emails moved to another provider by 11pm ET on August 9th. Klaviyo was also breached in the campaign, with cryptocurrency-sector customer data stolen. DoorDash appeared among the victims as well. The transitive access pattern repeated across the campaign, not just at Twilio.

How access moved from Twilio's systems to downstream customer accounts

Signal is the clearest case of downstream exposure. The company had no direct access relationship with the attacker, no phishing message, and no compromised employee. But Twilio's own disclosure said attackers could have seen about 1,900 Signal users' phone numbers or SMS verification codes. The access path ran entirely through Twilio's internal console. Signal's customers did nothing wrong and had no contact with the attackers. They were exposed because Signal had delegated a security-critical function, phone number verification, to a vendor whose internal access the attackers now controlled.

Inside Twilio's systems, the attackers could see customer data and the verification codes Twilio was delivering for those customers. This was access to the pipe, not just the pipe's metadata. Twilio stated there was no evidence that console account credentials, authentication tokens, or API keys were accessed. But even without those, the internal support consoles let attackers see verification codes in transit. That capability has real downstream consequences and cannot be fully audited after the fact.

The Authy case adds a second dimension. Twilio's own Authy two-factor authentication service was used to register additional devices on 93 individual Authy users' accounts during the breach. The attackers gained access to real two-factor authentication codes. A security vendor became the attack surface for the security function it provides. That is the transitive pattern at its most concentrated: the authentication layer itself was the vehicle.

The scope was narrow in percentage terms. Twilio's final count showed only a small fraction of its customer base was directly affected. Yet even that numerically small percentage represented dozens of downstream organizations. The breadth of the customer base amplified the reach of internal access. The Mailchimp-to-DigitalOcean chain in the same campaign shows the pattern is not unique to communications vendors. Any vendor with privileged access to customer data or accounts can become a transitive access vector.

Why standard MFA and perimeter controls did not contain the breach

The most common objection to the argument that vendor risk is insufficiently managed is that vendors have MFA. Twilio had MFA. The breach happened anyway. If you treat authentication, and vendor trust, as a compliance checkbox, you get less protection than most risk assessments assume.

The statement "we have MFA" on a vendor questionnaire does not distinguish between phishing-resistant and phishing-vulnerable implementations. That distinction is the one that matters. FIDO2 hardware security keys and passkeys verify the authenticity of the login domain during authentication. They produce no valid output on a fake phishing page, which means the attack fails at the credential relay step.

Cloudflare was targeted by the same campaign and defeated it. Cloudflare's own post-mortem confirms the company had deployed FIDO2 security keys internally. Attackers got employee phone numbers, but their phishing failed because the keys gave no usable output on a spoofed page. The defense existed and worked. The failure at Twilio was an implementation choice, not an unavoidable outcome.

The perimeter controls also missed the channel. SMS phishing delivered messages to employees' personal phones, so corporate email filtering never saw them. The defensive layer most organizations rely on was not covering the channel the attack used. For downstream organizations, the implication is direct: their vendor's internal authentication posture determines their own exposure. Standard vendor questionnaires do not measure that posture at the implementation level.

Why vendor relationships need to be treated as access boundaries, not trust relationships

The breach is best understood as an access boundary failure. Organizations extended implicit, unbounded trust to a vendor without modeling what access that vendor's compromise would give an attacker inside their own systems. A trust relationship with a vendor is effectively a one-way access grant. The vendor's internal systems, and anyone who controls them, inherit significant reach into the customer's environment.

Signal made that reach concrete. No attacker touched Signal's systems, and no Signal employee fell for a phishing message. Yet Signal's users were exposed because an attacker controlled the console that held their verification codes. The exposure was bounded entirely by what Twilio could see and touch. DigitalOcean reached the same conclusion after the Mailchimp breach. When a vendor is compromised, the downstream organization's exposure is bounded by what the vendor could reach. DigitalOcean concluded that boundary was unacceptable and terminated the relationship.

The access-boundary framing requires mapping what a vendor can actually reach inside customer data and operations, not just what the service agreement says the vendor is permitted to do. The urgency of that work is rising. The Verizon 2026 DBIR, cited by STIG's analysis, records that third-party involvement reached nearly half of all breaches, up significantly from the prior year. Vendor access modeling is now a priority, not a compliance formality.

The pattern has persisted. In 2024, Twilio's Authy app was breached again through an unauthenticated API endpoint, as noted by Breach History's timeline, exposing tens of millions of phone numbers. The platform-concentration risk that made Twilio a 2022 target has not diminished. If you know an organization uses a particular identity or communications vendor, that alone is a targetable signal. Attackers built phishing kits specifically against Twilio's and Okta's login flows. Platform concentration creates intelligence value for adversaries before any attack begins.

What treating vendors as access boundaries looks like in practice

To contain transitive access risk, you need controls at the access boundary that operate in real time. Discovery of what vendors can reach, monitoring of what they do, and enforceable policy on what they are permitted to do matter more than after-the-fact review of what was accessed. Phishing-resistant MFA must become a vendor requirement. The Cloudflare contrast shows that requiring FIDO2 hardware keys at the vendor's own employee authentication layer is a concrete, testable boundary condition. Vendor questionnaires should ask for implementation specifics, not checkbox compliance. "Do you have MFA" is the wrong question. "Do you require FIDO2 keys for all administrative access" is closer to the one that matters.

Mapping vendor access scope comes before any breach can happen. The downstream organization must know what internal data, credentials, and systems the vendor's personnel or platform can reach. This is access discovery applied to third-party relationships. Signal had no way to observe that its verification codes were being accessed inside Twilio's console. The monitoring gap was on the vendor side, and downstream organizations need visibility into actions taken on their behalf, not just their own perimeter.

Enforceable policy closes the gap that post-incident audit cannot. Logging what happened is insufficient when the exposure window is measured in days and the damage, such as re-registered phone numbers or exported customer lists, is immediate. Policy enforcement that can restrict or terminate vendor access in response to anomalous behavior is the control that matters. A vendor concentration risk assessment follows from the same logic. The 0ktapus campaign went after widely used identity and communications platforms because one compromise gave access to many downstream organizations. You should check how many critical operations run through a single vendor, and what a compromise there would expose.