Cloudflare: Someone tried to pull the Twilio phishing tactic on us too

Attack was foiled by content delivery network's hardware security keys

Cloudflare says it was subject to a similar attack to one made on comms company Twilio last week, but in this case it was thwarted by hardware security keys that are required to access applications and services.

Twilio reported a breach after employees received phishing text messages claiming to be from the company's IT department. These fooled them into logging into a fake web page designed to look like Twilio's own sign-in page, using pretexts such as claiming they needed to change their passwords. The attackers were then able to use credentials supplied by the victims to log into the real site.

According to Cloudflare, it recorded a very similar incident late last month, which could suggest the two attacks may have originated from the same attacker or group.

Detailing the incident on its blog, the content delivery network claimed that no Cloudflare systems were compromised, but said it was "a sophisticated attack targeting employees and systems in such a way that we believe most organizations would be likely to be breached."

In Cloudflare's case, its security team first started receiving reports on July 20 that employees got text messages containing a link to what appeared to be a Cloudflare Okta login page (Cloudflare uses Okta's identity and access management services internally).

Although the incident started late in the evening, Cloudflare said it operates a 24x7 Security Incident Response Team (SIRT), and has trained its employees to report anything that looks suspicious to the SIRT to investigate. The vast majority of reports turn out to be false alarms, but in this case it appears at least 76 company employees received the phishing messages within the space of a single minute.

The sophistication of the attack can be gauged by the fact that the URL in the text messages linked to a domain (cloudflare-okta.com) appeared to be legitimate, and had not been picked up by the company's monitoring systems. Cloudflare has systems to watch for domains being registered with its name and get them shut down, but in this case the domain had been registered less than 40 minutes before the phishing messages were sent, and so it had not yet been detected.

As with the Twilio incident, the fake Cloudflare Okta login page prompted any employee who visited it for their username and password. Alerted by their employees contacting SIRT, Cloudflare was able to analyze the payload of the phishing attack based on the message employees received, as well as what was posted to services like VirusTotal by other companies that had been victims of similar attacks.

It appears that if a victim keyed in their credentials, those were immediately relayed to the attacker via the messaging service Telegram. The reason for doing this was because the phishing page would also prompt for a Time-based One Time Password (TOTP) code, according to Cloudflare, and it would be necessary for the attacker to attempt to login using the code before it expired.

The way it was supposed to work is that the attacker would receive the victim's credentials and enter these into the real login page, whereupon the site would generate a code and typically send it to the victim via text message again. Once keyed in, this would also be relayed to the attacker, who could then use it to authenticate themselves and gain access.

This method would defeat most two-factor authentication implementations, according to Cloudflare, but the company was saved because it does not use TOTP codes, but instead uses a different system that requires each employee to have a FIDO2-compliant security key (Cloudflare mentions YubiKey) that implements origin binding.

The latter refers to an authentication token being cryptographically tied to a specific site via the TLS layer, which means that a man-in-the-middle attack such as this one will fail. This meant that even though Cloudflare found that three of its employees fell for the phishing message and entered their credentials, the attacker was not able to gain access.

This was fortunate as Cloudflare says that its analysis shows that if a victim made it past those steps, the fake page would then initiate the download of remote access software that would allow an attacker to control the victim's machine remotely.

Cloudflare details the steps it took in responding on its blog so other organisations can learn from the incident. The company said it is already making adjustments to its security posture from what it has learned, including tweaking Cloudflare Gateway to restrict or sandbox access to sites running on domains that have been registered within the last 24 hours. ®