August 4, 2022: Twilio discloses that its internal systems were breached after a coordinated SMS phishing campaign — later tracked as “0ktapus” (also “Scatter Swine”) — tricked employees into entering credentials and real-time MFA codes on fake Okta-branded login pages. The campaign’s scale was the story’s second act: the same infrastructure, domains, and playbook hit more than a hundred organisations in the months around the Twilio intrusion, harvesting thousands of identities. Among the cascade’s targets were DoorDash (which disclosed a related breach), Mailchimp (a vendor breach via a social-engineered support employee), and Cloudflare — whose experience became the campaign’s defining lesson. Cloudflare’s staff received the same texts, and some entered credentials on the phishing page; but the attackers got nothing durable, because Cloudflare’s mandatory hardware security keys made the stolen session path irrelevant where it mattered. Twilio’s own investigation traced the intrusion to a handful of employees succumbing to well-crafted lures, enumerated the data touched, and reset trust across affected systems. For defenders, August 2022 delivered the modern phishing canon in a single case: SMS lures impersonating identity providers work at industrial scale; credential+MFA interception defeats OTP-based second factors; and the only structural answer is phishing-resistant MFA — hardware-bound passkeys/FIDO2 — plus the assumption that some users will always click, so architecture must survive credential loss.
The 0ktapus campaign (June–August 2022, Twilio disclosure August 4) was a mass SMS-phishing (“smishing”) operation run by a crew later tracked as 0ktapus/Scatter Swine. Method: SMS messages impersonating IT/identity messaging (predominantly fake Okta SSO login pages — hence the name), harvested credentials + time-based OTP codes in real time via adversary-in-the-middle (AiTM) phishing proxies that relayed the victim’s live session into the real identity provider. Scale: 130+ organisations targeted, thousands of employee identities harvested (per Group-IB and similar threat-intel telemetry reporting), including household names — Twilio (breached, disclosed Aug 4), DoorDash (disclosed a related breach), Mailchimp (breached via social-engineered support staff), Signal (vendor-side impact via Twilio verification codes), and Cloudflare (heavily targeted, effectively unscathed thanks to mandatory hardware keys). The Twilio intrusion: phishing→credential+MFA harvest→internal systems access→data of a subset of customers touched (verification-code metadata for ~93 phone numbers belonging to 1,900 Signal users was the headline consequence). The Cloudflare counterpoint: employees phished, credentials entered, sessions attempted — but every privileged action path required hardware FIDO keys, which AiTM proxies cannot replay; the attacker footprint died at the key boundary. That contrast — same campaign, opposite outcomes — is the case’s teaching core. Root cause: SMS delivers lures with no sender authenticity; OTP codes are phishable by design (shared-secret, replayable-in-session); and humans under social pressure click. Remediation canon: phishing-resistant MFA (FIDO2/passkeys bound to origin), number-matching + push-fatigue protections as interim, conditional-access policies binding sessions to device posture, registered-devices pattern for SMS lures, and phishing-aware but non-blaming reporting culture — because the campaign also proved targeted employees report fast when the reporting path is frictionless. 2026 lens: the industry has since moved default-auth toward passkeys and origin-bound sessions, which would have structurally defeated 0ktapus-class AiTM; yet OTP-based flows persist in long-tail enterprises, so the campaign’s mechanics remain a live playbook — and the “assume breach of credentials; enforce key-bound privileged access” design rule it crystallised is now baseline architecture, not aspiration.
What happened
The campaign’s delivery was pedestrian and effective: SMS messages to employees, impersonating corporate IT, warning of schedule changes or password expiries, with links to domains mimicking the target’s identity provider — often Okta-styled pages, since so many targets shared that SSO layer. The pages were not static spoofs; they were adversary-in-the-middle proxies. When an employee entered credentials and the OTP prompt appeared, the proxy relayed both to the real provider in real time, captured the minted session cookie, and handed the attacker a live authenticated session — defeating TOTP, SMS-OTP, and push-approval factors alike, because all of them reduce to phishable shared secrets or replayable approvals within that relay window.
Twilio’s August 4 disclosure was candid about the mechanics: a handful of employees fell for the lures; attackers used harvested credential+MFA pairs to access internal systems; Twilio contained, rotated, and notified. The Signal side-effect drew outsized attention — Twilio acted as Signal’s verification-code vendor, and the intruders could have re-registered ~1,900 Signal numbers, an impact Signal disclosed transparently while emphasising message content and contact lists were not exposed. DoorDash, Mailchimp (in a separate but campaign-linked social engineering of a support staffer), and over a hundred other organisations unfolded across the same window, mapping the campaign’s true fan-out.
Cloudflare’s write-up, published weeks later, completed the picture. Their employees received thousands of the same texts; some entered credentials. But Cloudflare’s authentication architecture required hardware security keys for all sensitive access: FIDO2 protocols cryptographically bind the authentication ceremony to the legitimate origin, so a proxy presenting a look-alike domain cannot exercise the key — the phishing page can ask, but the user’s key will only answer the genuine article. Attackers pivoted to target Cloudflare’s own employees’ personal accounts and provider relationships, and the company caught the campaign via those employee reports. Same adversary, same lures, radically different outcome: the difference was architecture, not awareness.
The AiTM mechanics, in one diagram
0ktapus kill chain (2022):
STAGE 1 - LURE (SMS/smishing)
"IT: your password expires /
schedule changed -- resolve
at sso-<company>-auth[.]com"
(fake Okta-styled portal)
STAGE 2 - HARVEST (AiTM proxy)
victim -> proxy (fake page)
proxy -> real IdP (relay)
victim enters creds+OTP
proxy relays both live
-> captures session cookie
(TOTP/SMS-OTP/push ALL
defeated: they are shared
secrets / replayable)
STAGE 3 - USE (live session)
attacker enters IdP as
victim (valid cookie)
-> email, SSO apps, internal
tools, vendor consoles
TARGETS (130+ orgs):
Twilio breached (Aug 4)
DoorDash disclosed related
Mailchimp support-engineered
Signal vendor-side impact
Cloudflare targeted -- UN-
SCATHED (hardware keys)
WHY KEYS WIN:
FIDO2 ceremony is bound to
true origin (TLS+domain)
proxy domain != real domain
-> key simply refuses
no shared secret exists
to relay or replayImpact and numbers
| Metric | Value |
|---|---|
| Campaign window | June–August 2022 (peak July–August) |
| Organisations targeted | 130+ (per Group-IB/CrowdStrike-era reporting) |
| Identities harvested | ~10,000 credentials (per reporting) |
| Twilio disclosure | August 4, 2022 |
| Signal impact | Verification codes for ~1,900 users’ 93 phone numbers potentially exposed |
| Cloudflare outcome | Targeted at scale; no durable compromise (hardware FIDO keys) |
| Attribution | Single crew (“0ktapus”/Scatter Swine); financially motivated |
Timeline
| Date | Event |
|---|---|
| 2022-06 | Campaign infrastructure spun up; earliest smishing waves |
| 2022-07 | Peak targeting; Twilio employees phished; intrusion begins |
| 2022-08-04 | Twilio discloses breach; Signal notifies affected users |
| 2022-08 | DoorDash discloses related breach; Mailchimp incident unfolds |
| 2022-08-30 | Group-IB’s “0ktapus” research lifts the curtain on 130+ orgs |
| 2022-09–10 | Cloudflare publishes its hardware-key counterpoint analysis |
Why it still matters in 2026
Because every element of 0ktapus has become a permanent fixture of the threat landscape, and the case remains the cleanest A/B test of what actually works. The lure channel (SMS impersonating IT and identity providers) is now complemented by voice, Teams/Slack messages, and AI-personalised variants, but the mechanics are unchanged: urgency, authority, and a look-alike domain. The interception technique (adversary-in-the-middle relay of credentials plus second factor) remains the default phishing architecture precisely because it defeats every factor that reduces to a shared secret — TOTP codes, SMS codes, push approvals — and it will keep defeating them wherever those factors persist. Meanwhile the passkey/FIDO2 migration that 0ktapus accelerated has proven the structural answer at scale: origin-bound ceremonies cannot be proxied, which is why the industry’s 2023–2026 identity roadmaps treat phishing-resistant MFA as the terminal state for human authentication. The campaign’s second durable lesson is about vendor fan-out: one crew’s SMS blast became breaches at a communications provider, a delivery platform, a marketing vendor, and a near-miss at an internet backbone — because SSO credentials are keys to ecosystems, not just accounts. Modern supply-chain risk practice (vendor SSO isolation, least-privilege vendor consoles, verification-code metadata treated as sensitive) traces directly to this incident cluster. And the cultural note survived too: at both Twilio and Cloudflare, employees who received lures reported them, quickly, through frictionless channels — evidence that the “humans as sensors” model works when reporting is fast, blame-free, and visible in its effect. The 2026 synthesis is the one 2022 taught in a single campaign: train users, but build as if they will fail; authenticate with origin-bound keys; and assume your vendors are being phished the same week you are.
Detection and hardening takeaways
- Deploy phishing-resistant MFA everywhere privileged access exists. FIDO2 hardware keys or passkeys cryptographically bind sign-in to the true origin, making AiTM relay structurally useless. This is the single control that separated Cloudflare’s outcome from Twilio’s — same adversary, same lures, different architecture. Prioritise admins, then engineers, then everyone; treat OTP-only coverage as a known gap with an end date.
- Treat OTP codes and push approvals as phishable-by-design. If you still run TOTP/SMS/push, layer number-matching, push-fatigue rate limits, and session-anomaly detection (impossible-travel, new-device bindings, token-replay indicators). These raise attacker cost but do not close the hole — plan the key-bound migration while they buy time.
- Monitor for AiTM signatures. Look-alike domains with IdP-styled login forms, spikes in authentication from proxy-ish infrastructure (hosting ASNs, bulletproof ranges), session cookies used from geographies/IPs inconsistent with the user’s device history, and authentication events lacking the usual client fingerprint preceding them. The relay window leaves traces — two authentication paths, one human.
- Make reporting frictionless and celebrated. Both Twilio and Cloudflare benefited from employees reporting lures fast. One-tap phishing-report buttons in email/SMS clients, visible acknowledgement, and metricised “reports per attempted lure” beat annual-awareness theatre by orders of magnitude — humans as sensors only works when the sensor path has zero friction and zero blame.
- Segment what a stolen SSO session can reach. Assume some credentials+sessions will be harvested anyway. Conditional access binding sessions to compliant devices, step-up authentication for sensitive actions, JIT elevation for admin roles, and isolating vendor/partner consoles from internal data planes all shrink the blast radius of one phished session from “the ecosystem” to “one contained surface.”
FAQ
Why is it called “0ktapus”?
The Group-IB researchers who tracked the campaign named it for its signature: fake Okta-branded login pages across many targets — Okta plus octopus, reflecting the campaign’s reach into 130+ organisations. “Scatter Swine” was another tracker’s label for the same crew.
How did attackers defeat MFA?
They relayed it. The phishing sites were reverse proxies of the real identity provider: victim submits credentials, proxy forwards them live, provider issues an OTP challenge, victim types the code, proxy forwards it, provider mints a session — which the proxy captures. Any factor that is a shared secret or replayable approval (TOTP, SMS codes, push) fails to this design; the session itself, not the factor, was the prize.
Was Signal breached?
No — Signal’s own systems were not compromised. Twilio, Signal’s verification-code vendor, was; the attackers could access code-metadata for a small set of numbers (they attempted re-registration of 1,900 Signal users’ numbers per the disclosures, focused on ~93 accounts), so Signal warned affected users. Message content and contact lists were never at risk from this path.
Did anyone attacked stay fully secure?
Yes — Cloudflare is the canonical case: heavily targeted, employees phished, credentials entered on the proxy, and still no durable compromise because hardware security keys were mandatory for access that mattered. The campaign’s clearest lesson is architectural: origin-bound keys defeat the relay; awareness alone does not.
