The August 4th compromise of Twilio via a targeted smishing attack has been a topic of wide concern and discussion on social media. My first thoughts on hearing of the attack were to virtually “pat myself down” with regard to exposure risk. Kind of like that feeling when you’re not sure if your car keys or wallet are in your pocket a few blocks after walking away from your parking space. Is my company affected by the breach? Did we receive a notification email from them? We need to check our platform audit logs ASAP. Thankfully we were not notified, but that does not mean we should not endeavor to take a valuable lesson from this event: low-code and no-code attacks can be devastatingly effective.
By now, we should all be well aware that it’s not a matter of if, but when a breach that you need to investigate will occur. It could be your own infrastructure, but more likely than not, you will need to fire up your incident response plan in dealing with a third-party breach. Such was the case with DoorDash and Okta, two of the 163 companies impacted by the Twilio attack and compromise.
This raises the question of the vector: low-code and no-code (LCNC) integrations. LCNC platforms allow developers as well as non-developers to create applications and services without coding by dragging and dropping application components and connecting them together with API tokens and workflow automation templates. This is also sometimes referred to as “citizen development.” Twilio’s cloud infrastructure participates in the data and automation workflows of their 270,000+ customers by providing and connecting such components and therefore serves as an example of this LCNC attack vector.
Twilio was also targeted because they own and operate Authy.com (since acquiring it in 2015). Of note here in the Twilio status update from August 24th:
‘…malicious actors gained access to the accounts of 93 individual Authy users – out of a total of approximately 75 million users – and registered additional devices to their accounts.”
This was done to bypass MFA controls for those users. As an attacker, being able to approve your own ill-begotten multi-factor authentication request is definitely a major bad guy milestone. Reviewing the Authy device registration logs allowed Twilio’s team to address this, but further investigation would be necessary to ascertain the potential further impacts for the period in which those Authy users had one or more “approver” devices in the hands of the attackers.
Based on the last few years of supply chain attacks and breaches, it seems that business ecosystem risk (often referred to as third-party risk) management will never want for a fresh example of bad guys taking an indirect approach toward compromising a target (or targets) of interest. Twilio itself was not the target but rather a means to an end. The real target of the breach has not, to the best of my knowledge, been made known. Still, when an APT immediately searches for just three phone numbers of the secure mobile messaging app Signal after gaining access to over 1,900 phone numbers, you know that Twilio was merely a stepping stone toward another compromise in the works.
With any security event or incident, the job of information security officers should be to understand the nature of the attack vector and, where possible, validate that we have observability into the activity that leads to a breach or compromise. If we find that there are no logs of the activity, it’s a straightforward mitigation to enable logging and monitoring. You cannot detect what you cannot see. Many of the companies compromised in the SolarWinds attack did not even have logfiles to inspect to see if they had been compromised by the Russian APT 29. Next, we should discuss with the business whether additional tools or technologies can and should be introduced to further mitigate the risk identified in the incident. We must make sure that we learn from these attacks. Lastly, I would like to applaud the transparency and resilience-inspiring work of the Twilio team, along with the firm they engaged to lead the forensics investigation, and the responsible legal teams who allowed all this information and insight to be shared with us. Together we are stronger and can craft a more robust and resilient economy, society, and business ecosystem risk landscape.
If you need help building the business case for having a digital forensics incident response retainer so that you too can recover from a breach or security incident, I suggest reaching out to SecurityScorecard’s professional services team. All it usually takes is a pentest, tabletop exercise, or red team exercise to demonstrate to your board or executive leadership team the value of being prepared and knowing how to work your incident to closure.
SecurityScorecard’s products and services can support efforts to prevent attacks by identifying vulnerabilities, investigating possible threats, and responding to incidents. SecurityScorecard can support organizations both before and after ransomware attacks:
Our Cyber Risk Intelligence as a Service (CRIaaS) offering can provide tailored insights about the threats facing them,
In the event of a successful or attempted attack, SecurityScorecard can support incident response efforts.