how it happened
- whoattackerphished a telephony vendor employee
- the gapSMS providerdelivered Duo's codes
- the resultMFA message logsphone numbers of ~1% of customers
what everyone assumed
A team flips on SMS multi-factor authentication and treats the account-takeover problem as handled, because for the most common attack it is. The reasoning is sound: a stolen password alone is no longer enough, and a code sent to the user’s phone is a real second factor. What the model quietly assumes is that the only thing worth protecting is the code itself, and that everything around the code, the phone number, the carrier, the where and when, is exhaust.
what happened
The weakness was not in Cisco Duo and not in the codes. It sat one link upstream, at a third-party telephony provider that delivered Duo’s SMS and voice messages. On April 1, 2024, an attacker phished an employee at that provider and used the credentials to reach its internal systems. Once inside, they downloaded message logs for messages sent during March 2024. The logs held no message content, no codes. They held phone numbers, carriers, the country and state each message went to, and metadata such as the time each one was sent. For a stretch, the access just sat there, a directory of who used MFA, on what number, served by which carrier.
step by step
- Duo's SMS and voice messages go through a telephony providerA third party one link upstream.
- 1 April 2024an employee at the provider is phishedThe attacker reaches its internal systems.the assumption breaks here
- message logs for March 2024 are downloadedNo codes or content: phone numbers, carriers, locations, timestamps.
- mid-April 2024about one percent of customers notifiedThe data is raw material for SIM swaps and targeted calls.
how it surfaced
Cisco Duo disclosed the breach to customers in mid-April 2024. The exposed logs covered messages sent between March 1 and March 31, and reached roughly one percent of Duo’s customers. No codes were taken and no accounts were directly broken into. What was taken was the raw material for the next step: a verified phone number tied to a carrier is what a SIM-swap or a tailored social-engineering call is built from. The assumption retired itself in the gap between the door and the doorframe.
SMS MFA protects the code, but the phone number underneath it is a credential of its own, and it lives in systems you do not run.
Closing one door is not the same as owning the wall it sits in.
picture it at a company like yours
The company here is made up. The other two paths are not: they happened, and each links to the story.
- in this storythe day it mattersThe provider is breached and the list is copied.what it costs youAttackers now know exactly whose phone to target with a SIM swap or a convincing call.
- or it goes like thisit happenedReddit, 2023howA fake login page passes the password and code to the real site as they are typed.what leavesinternal documents, code and dashboardswho ends up with itthe attacker behind the page
- or it goes like thisit happenedUber, 2022howLogin prompts keep coming until a tired employee taps approve.what leavesadmin tools and company chatwho ends up with itan attacker who bought a contractor's password
sources
your turn
what you can do about it
this week
List the third parties that touch your sign-in, from SMS provider to email gateway.
Your MFA works, which is exactly why no one is thinking about the telephony provider, the email gateway, or the SaaS that sits between your login screen and your user's phone. The quiet-months question is about that chain: this week, list the third parties that touch your authentication, and look at which factor you would still have if an attacker held the phone number rather than the password. If the answer is SMS alone, that is the same single link that carried these logs.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →