Writing
Anatomy of an Identity Incident

Same Phish, Two Outcomes

Anatomy of an Identity Incident — the 0ktapus campaign, 2022. One phishing kit hit 130-plus companies. Why most got breached and at least one didn't comes down to a single control.

Michael AbramovichSeptember 12, 20226 min read

Forensic write-ups of public identity breaches, strictly at the identity layer. No vendor is the villain — the point is the structural class of failure, not the logo on it.

The 60-second version

Through 2022, a single, almost unglamorous campaign — later named 0ktapus — ran the same play against more than a hundred companies. Employees got a text message: your password is expiring, your schedule changed, click here to sign in. The link led to a counterfeit login page that looked exactly like the company's own single sign-on. People entered their username, password, and one-time MFA code, and a phishing server on the other end relayed all three to the real site in real time, while they were still valid.

By the time researchers tallied it, the campaign had harvested roughly 9,900 sets of credentials and 5,400 MFA codes across 136 organizations. Twilio was breached this way, and through Twilio, its downstream customers — including users of Signal — were exposed. But the most instructive data point is the company that got hit by the identical campaign and was not breached, because of one design decision. Same phish. Two outcomes.

The identity timeline

Only identity-relevant events; this is a campaign, so the shape matters more than precise minutes.

  • From early 2022 — Attackers register lookalike domains and stand up a phishing kit that impersonates Okta-style SSO login pages, one per targeted company. Harvested credentials are relayed out in real time.
  • The lure — Targets receive SMS messages (smishing) referencing password resets or schedule changes, with a link to the counterfeit page.
  • The relay — A victim enters username, password, and their current one-time code. The kit forwards them to the genuine login while the one-time code is still valid, completing authentication as the victim.
  • The pivot inward — With a valid session, attackers move into internal tooling, and in several cases use that access to reach the targeted company's own customers.
  • The supply-chain reach — Twilio is among the breached. Because other companies use Twilio for phone-number verification, the blast radius extends downstream — Signal, a Twilio customer, reports a set of its users exposed as a result.
  • The exception — At least one targeted company has employees fall for the same lure and enter credentials, yet the attackers cannot get in. That company had moved to phishing-resistant hardware keys.
  • Aug 2022 — Researchers attribute and name the campaign, putting the cross-company scale on the record: ~9,900 credentials, ~5,400 MFA codes, 136 organizations.

The pivot point

The pivot is the instant a valid one-time code lands on the phishing server. Everything before it — the text, the fake page — is just setup. Everything after is foregone.

Here is why that instant is fatal, and it is worth being precise. A one-time code, whether from an authenticator app or an SMS, is a shared secret that the user is expected to type wherever they are asked to authenticate. Its entire security model rests on one assumption: that the user is typing it into the real site. Phishing attacks the assumption directly. The code is perfectly valid; the user is perfectly cooperative; the only thing wrong is the destination, and the user cannot reliably tell. A push-approval prompt has the same flaw in a different costume — the user is asked to approve, and approves, because a login really is happening, just not theirs.

So the second a legitimate code reaches an illegitimate page, the "second factor" has done nothing, because it was never bound to anything. It is a number that proves the user has the factor, not that the user is talking to the right server. That distinction is the whole incident.

What would have caught it

Naming controls, not products.

Phishing-resistant MFA — the one that actually mattered. FIDO2/WebAuthn security keys (and platform passkeys) bind the credential to the real site's origin in the protocol itself. When the user lands on a lookalike domain, the key simply will not produce a usable assertion, because the origin doesn't match. There is no code to read aloud, no prompt to approve, nothing to relay. This is not a marginal improvement over one-time codes; it removes the pivot point entirely. The company that survived the campaign survived because of exactly this.

Treating SMS as a weak identity channel. SMS is fine for a coupon and dangerous for a credential. Both the lure (smishing) and the weaker MFA variants (SMS OTP) leaned on it.

Lookalike-domain monitoring. The kit needed freshly registered domains impersonating each target. Watching for newly registered lookalikes of your SSO domain turns the attacker's setup step into your early warning.

Fast session revocation and re-auth. Once a credential is known phished, the value of the stolen session collapses if you can kill it and force re-authentication quickly.

Mapping who depends on you for identity. Twilio's breach mattered to Signal because Signal depended on Twilio in the identity path. Knowing who is downstream of you — and who you are downstream of — is what lets you reason about blast radius before it happens.

The last mile

No identity provider was breached in this campaign. Let that sit for a second. The authentication systems worked exactly as designed; MFA was enabled at the victim companies. People were phished anyway, because "MFA is enabled" and "MFA that a phishing page cannot relay" are two very different states, separated by a stretch of work that the product does not do for you.

That stretch is the last mile here. Choosing phishing-resistant factors, rolling hardware keys or passkeys out across an entire workforce, killing the SMS fallbacks, training for the specific smishing pretext — none of it is a setting you flip once. It is continuous operational work, and it is owned by neither the IdP (whose job ended at "we support strong factors") nor, in practice, by overloaded internal teams who had MFA turned on and reasonably believed they were covered.

And then there is the counterfactual, which is the most useful thing this campaign produced. One company received the identical attack, with employees who made the identical mistake, and walked away unbreached — because someone there had owned that mile and moved the organization to hardware keys before the attack arrived. Same input, opposite outcome, and the only variable was whether the last mile had an owner. That is the entire thesis of this series, demonstrated by a controlled experiment that the attackers ran for us across 136 companies.

The supply-chain tail makes it sharper. Twilio's customers inherited Twilio's last mile whether they liked it or not; Signal's users were exposed by a control decision two companies upstream of them. When identity dependencies chain, so does the last mile — and each link is ownerless until someone names it.

For defenders

Five things, in priority order.

  1. Move to phishing-resistant MFA (FIDO2/WebAuthn, passkeys), privileged users first. This is the control that separated the breached from the unbreached. Everything else on this list is secondary to it.
  2. Kill SMS as a factor and de-emphasize one-time codes wherever a phishing-resistant option exists. Keep them only as a last-resort fallback, monitored.
  3. Monitor for lookalike domains of your SSO and key apps; newly registered ones are an early warning of a campaign aimed at you.
  4. Tighten session lifetimes and make revocation fast, so a phished credential has the smallest possible useful window.
  5. Map your identity supply chain — who you depend on, and who depends on you — so you can reason about downstream blast radius before an incident, not during one.

Built from public reporting and the parties' own disclosures; sources below.

Sources

#twilio #0ktapus #phishing #mfa #fido2 #last-mile