The Low-Code / No-Code Attack Vector

The August 4th compromise of Twilio in 2022 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 of the fact 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 that were identified to have been impacted by the Twilio attack and compromise.

This raises the question of the vector: low-code and no-code integrations. Twilio is an example of this attack vector because of the data and automation workflows in which they participate for their 270,000+ customers. They were 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 in order 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 need to be done in order 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 just a means to an end. The real target of the breach has not, to the best of my knowledge, been made known. But when an APT immediately searches for 3 phone numbers of the secure messaging mobile app Signal after gaining access to over 1,900 mobile 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.

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 also the responsible legal teams who allowed all of 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.