Last month two companies, Twilio and Cloudflare, were attacked by cyber criminals. While it may be tempting to dismiss these attacks as simply being the latest in a long list of high-profile attacks that have occurred over the last few years, there were several aspects about the Twilio and Cloudflare attacks that made them stand out. The cyber attackers used new and advanced phishing techniques against these companies which are likely to be used again in the future.
How attackers used SMS text against Twilio and Cloudfare
Twilio and Cloudflare were unlike most phishing attacks, the attackers used SMS text messages as a delivery mechanism (a practice also known as smishing). Additionally, the attackers seemed to have targeted specific employees and they demonstrated significant knowledge of who those employees regularly interacted with.
The attackers sent text messages to specific employees claiming that there had been a recent schedule change or password change. The message included a link to a malicious website that looked legitimate and prompted the victims to enter their credentials. Upon doing so, the site not only stole their credentials, but it also attempted to install AnyDesk remote desktop software. This software could then be used to commandeer those employees’ systems.
Beyond conventional phishing attacks
There were two things that separated these attacks from more conventional phishing attacks. First, the attackers knew the employee’s cell numbers, which allowed the attackers to send text messages to the targeted victims. More importantly, the attackers knew the phone numbers of coworkers and in some cases, even family members. Having this information allowed the attackers to spoof the identities of trusted individuals. Those who received the messages were tricked into believing that the message was coming from someone they knew. It is also worth noting that links within the messages pointed to a seemingly legitimate domain containing the keywords Cloudflare and Okta.
The other thing that was so unique about these attacks is that they were specifically designed to circumvent multifactor authentication (MFA). MFA has long been regarded as one of the best tools for preventing an attacker from being able to use stolen credentials to log into a victim’s network. However, the attackers in the Twilio and Cloudflare attacks discovered how to beat the MFA requirement.
How the attackers overtook MFA
As previously noted, the smishing messages that were sent to the employees’ cell phones contained a link to a fake web site that was designed to steal their credentials. Both Twilio and Cloudflare require MFA, so simply stealing a username and a password was not sufficient for the attacker to be able to log in. The attacker also needed to be able to complete the network’s MFA requirement. The attackers were successful by using the Telegram messaging service as a real time relay.
When an employee clicked on the link in the phishing message, they were taken to a fake login page. At this point, an employee who fell for the ruse would enter their username and password into the fake site. The credentials would then be relayed to the organization’s real site. The real site would treat this forwarding of credentials as a legitimate logon attempt. Assuming that the username and password that had been entered were correct, the site would initiate an MFA security requirement. This means that a one-time use MFA code was sent to the employee’s phone via SMS text message. The employee, who still thinks that they are logging into a legitimate site enters the code into the phishing site, which in turn relays the code to the organization’s real site. The result is that the attackers gain access to the site despite any MFA requirements. The attackers deceived the employees into completing the MFA challenge for them.
How Cloudflare stopped the sophisticated smishing attacks
Although the attackers successfully compromised Twilio, Cloudflare successfully thwarted the attack. Three of Cloudflare’s employees took the bait and clicked on the link within the smishing messages. The difference, however, was that Cloudflare does not use Time-Based One-Time Password codes (also known as TOTP codes) sent through SMS messages. Instead, Cloudflare issues each employee a FIDO-2 compliant security key. These hardware-based keys prevent an attacker from being able to intercept information that would allow them to complete an MFA challenge and gain access to the system.
Adopting zero-trust policies as a defense
Even though Cloudflare stopped attackers from breaching their defenses, the attack against Twilio was highly successful. According to some industry estimates, this attack ultimately breached over 130 organizations, harvesting over 10,000 employees’ credentials. Given that this attack was so successful, it is a near certainty that similar attacks will be used against other organizations in the future.
Organizations should adopt zero trust policies as a defense against such attacks. In the past, access to the resources on Windows networks has been controlled through static access control lists. The access control list entries determine who has access to a given resource and the level of access that they receive (such as read only vs. read / write). Ultimately however, this technique means that a user either has access to a resource or they do not. There is no in between.
Today, conditional access policies allow other criteria to be considered when making access control decisions. These policies work a bit like if – then statements. An organization might for example consider things such as a user’s device type, geographic location, or the time of day when determining whether to allow access to a particular resource. Doing so makes it possible to prevent an attacker from accessing any data, even if that attacker has managed to successfully log into the network. In a Windows environment for example, this may mean using conditional access policies (which are available through Azure AD) as a tool for stopping suspicious logins.
Often Azure AD built-in “protections” are not enough, so you can implement Specops Password Policy and Breached Password Protection to enforce these policies in your on-prem environment + utilize a federation solution or Azure AD password write-back to enforce those policies for your users across environments.
Of course, zero trust comes in many different forms, so organizations should look for ways to integrate zero trust principles into all their IT procedures. For example, attackers often engage in social engineering schemes in which they contact an organization’s helpdesk requesting a password reset. If successful, this type of attack results in the helpdesk technician literally giving the attacker a password that they can use to gain access to the system. Specops Secure Service Desk can prevent this type of attack by requiring users to verify their identity through a trusted identity provider before the helpdesk technician will even be allowed to reset their password.