Communications API developer Twilio has been the victim of a data breach following an SMS-based phishing attack.
The attack took place on 4 August, when a bad actor gained unauthorized access to information regarding a number of Twilio customer accounts via an SMS-based social engineering attack. The attack was designed to trick employees into providing their employee credentials. The stolen information was then used to gain access to Twilio’s internal systems, allowing them to access customer data.
The text messages sent to employees appeared to be from the company’s IT department, and told victims that their passwords had expired, or that they schedule had changes and they needed to log in via a link that the attacker controlled.
Twilio explained that the URLs “used words including ‘Twilio,’ ‘Okta’, and ‘SSO’ to try and trick users to click on a link taking them to a landing page that impersonated Twilio’s sign-in page” and that “the threat actors seemed to have sophisticated abilities to match employee names from sources with their phone numbers”. According to Twilio, other companies suffered similar attacks around the same time, although these companies were not named.
Twilio was able to work with the US carriers that the text messages originated from, as well as with the hosting providers for the malicious URL to shut the accounts down. Despite this, Twilio noted that “the threat actors have continued to rotate through carriers and hosting providers to resume their attacks”.
Twilio explained that it is “working directly with customers who were affected by this incident” and that the investigation is still ongoing. The company has not yet identified those involved in the hack, but it is working with law enforcement and said it will “perform an extensive post-mortem on this incident and begin instituting betterments to address the root causes of the compromise immediately”.
On 10 August, Twilio made an update to its incident report noting that it had identified and notified around 125 Twilio customers whose data had been accessed “for a limited period of time” during the breach and confirmed that there was “no evidence that customer passwords, authentication tokens, or API keys were accessed without authorization”.