Cisco Duo supplier phish exposed SMS MFA logs

Phone numbers, carriers, timing, and MFA message-type metadata for roughly one percent of Duo customers left a North American telephony supplier after a workforce phishing attack. According to BleepingComputer on 15 April 2024, Cisco Duo told customers a threat actor phished credentials of an employee at an unnamed supplier used to send Duo multifactor authentication over SMS and VoIP, then downloaded MFA message log metadata for traffic roughly from 1 March to 31 March 2024. The provider said message contents were not accessed and the stolen access was not used to send messages. Public reporting does not name the supplier, the threat actor, or a confirmed follow-on takeover of Duo customer accounts from those logs. Cisco still warned that the metadata could fuel targeted SMS phishing campaigns and social engineering, the same class of phone-number abuse seen when attackers already know how to reach an employee MFA path, as in the Uber 2022 social-engineering case referenced in related coverage of residual SMS MFA risk.

If you want the prevention angle on dropping SMS and voice MFA so this supplier log surface goes away, read the related article on mfa2point0.com.

FAQ

How did attackers get access in the Cisco Duo telephony-supplier incident?

Attackers got access by phishing credentials of an employee at Duo’s unnamed North American telephony and SMS MFA provider, then using those credentials on the provider’s systems on or about 1 April 2024. According to Cisco’s customer notice as quoted by BleepingComputer, that supplier sends Duo multifactor authentication messages via SMS and VoIP. Public reporting describes a phishing attack and social engineering of supplier workforce credentials. It does not document AiTM, a helpdesk TAP, or a Duo-customer login bypass as the initial path.

What data was taken from the Duo SMS and VoIP MFA logs?

The stolen material was MFA message log metadata for Duo SMS and VoIP traffic tied to specific Duo accounts in the roughly 1 March to 31 March 2024 window, assessed by Cisco as about 1% of Duo customers. According to reporting on the customer notice, fields included phone number, carrier, location data, date, time, and message type. BleepingComputer noted Duo’s public customer base figure of about 100,000 and used Cisco’s 1% assessment to approximate on the order of 1,000 impacted customers. Public reporting does not establish an exact user or record count beyond that percentage.

Were Duo customer OTP codes or full MFA message bodies exposed?

No. The telephony provider stated that MFA message contents were not accessed and that the compromised access was not used to send messages. The Cisco Duo incident, as publicly described, is a metadata-log exposure on the SMS and voice delivery path, not a confirmed dump of one-time passcode bodies. Public reporting does not establish OTP or full message-body exposure beyond the vendor’s denial of content access.

Did this mean attackers signed into Duo customer IdPs or enterprise apps?

Public reporting does not establish that the stolen logs were used to complete Duo customer logins or take over enterprise accounts. The documented win was provider-side access after a phished supplier employee credential, then a download of SMS and VoIP MFA delivery logs. Cisco’s response framing was customer notice, vigilance against SMS phishing campaigns and social engineering built from phone numbers and timing, and a path for customers to request exposed log detail via msp@duo.com. After discovery, the provider invalidated the compromised credentials, reviewed activity logs, notified Cisco, and added security measures.

Why did SMS MFA put Duo customers on a third-party log surface at all?

SMS and voice MFA put Duo customers on a third-party log surface because those factors are delivered through a telephony supplier that must store enough routing and delivery metadata to send the message. Phone numbers, carriers, timing, location-related fields, and message type lived outside the customer IdP on that North American provider. Even when OTP bodies stay out of the export, the metadata is still a credential-phase reconnaissance package for later phishing attacks or vishing against the people those numbers reach. A fix that removes transferable SMS and voice factors exists; the companion post covers that prevention path without replaying this incident as a customer-side login story.