The mechanics of a sophisticated phishing scam and how we stopped it

Twilio-Stlye Phishing Wave Hits Cloudflare Employees

On August 8, 2022, Twilio disclosed a breach stemming from a targeted social engineering attack. At roughly the same time, Cloudflare observed an almost identical campaign aimed at its own personnel. While a small number of employees did take the bait, Cloudflare’s internal deployment of its Cloudflare One products and mandatory physical security keys stopped the intrusion cold. No Cloudflare systems were compromised, and the company's Cloudforce One threat intelligence team conducted a post-mortem to map out the attack's mechanics.

The attacker was not just going after Cloudflare; evidence indicates multiple organizations were targeted. The details below outline exactly what happened, step by step, to help other security teams identify and neutralize similar threats.

SMS Phishing Within Minutes of Domain Registration

The first sign of trouble surfaced on July 20, 2022, when Cloudflare’s Security team began receiving reports from employees. Starting at 22:50 UTC, a wave of text messages hit the personal and work phones of at least 76 employees—all within a single minute. Some family members received messages too. How the attacker assembled such an accurate phone list remains under investigation; a review of access logs for employee directory services showed no signs of compromise.

These were not generic spam texts. They appeared to come from four T-Mobile SIM card numbers—(754) 268-9387, (205) 946-7573, (754) 364-6683, and (561) 524-5989—and pointed to a deceptively named domain: cloudflare-okta.com. That domain was registered via Porkbun at 22:13:04 UTC, just 37 minutes before the SMS campaign began. Cloudflare’s internal systems for detecting lookalike brand registrations missed it because the domain was so new it had not yet appeared in public .com registration feeds.

Clicking the link led to a phishing page hosted on DigitalOcean. Visually, it was an exact replica of a Cloudflare Okta login page, prompting victims for their username and password. The site was built with a Nuxt.js frontend and a Django backend. The messages arrived from four T-Mobile-issued SIM cards: (754) 268-9387, (205) 946-7573, (754) 364-6683 and (561) 524-5989.

Real-Time Credential Relay

What made this attack more sophisticated than a typical credential harvester was its real-time relay mechanism. The instant a victim submitted their username and password, the phishing page forwarded those credentials to the attacker via Telegram. This speed was critical for the next stage of the attack.

After the initial credentials, the phishing page also requested a Time-based One Time Password (TOTP) code. Here is the trap: as the attacker received the username and password in real time, they could immediately enter them into the real Okta login page for the victim’s company. That would trigger a legitimate TOTP code to be sent to the employee. The employee, believing they were logging in legitimately, would then type that TOTP code into the phishing page. That code was instantly relayed to the attacker, who could use it before expiration to finish logging in, thereby bypassing most 2FA implementations.

Why the Attack Failed: Origin-Bound Hardware Keys

The attack sequence fell apart at Cloudflare because the company does not use TOTP codes at all. Instead, every employee is issued a FIDO2-compliant hardware security key (such as a YubiKey). These keys are tied to the user and enforce origin binding, meaning the cryptographic assertion they generate is only valid for the exact domain it was issued for. Even a real-time relay operation cannot harvest what the hardware key never produces.

Three Cloudflare employees did enter their credentials on the phishing page. The attacker did attempt to use those credentials against Cloudflare systems, but the login was blocked at the hardware key step. No Cloudflare employee progressed to the final stage of the phishing payload, which initiated a download of AnyDesk remote access software designed to give the attacker full control of the victim's machine. Even if that stage had been reached, Cloudflare’s endpoint security was configured to block such software installation.

Incident Response Timeline

Cloudflare’s security team mounted a five-pronged response once the threat was identified.

Domain Blocking via Cloudflare Gateway

Network teams immediately added cloudflare-okta.com to Cloudflare Gateway, the company’s Secure Web Gateway, blocking all employee access. Gateway’s automated malicious domain detection also flagged the site, but the window between domain registration and the first SMS was too short for automatic action to protect the first few clickers. In response, Cloudflare is accelerating the speed of new-domain detection and implementing access controls on newly registered domains for its own internal use—features already offered to its customers.

Credential Reset and Session Kill

By correlating phishing text recipients with login activity, the team identified threat-actor authentication attempts. Login logs revealed blocked attempts where the password matched but the U2F second factor could not be verified. For the three employees whose credentials were leaked, the team reset passwords, terminated active sessions, and scanned their devices.

Infrastructure Takedown

Cloudflare worked with DigitalOcean to shut down the phishing server and with Porkbun to seize control of the malicious domain. Analysis of failed authentication attempts revealed the attacker was operating over Mullvad VPN from a Windows 10 machine running Google Chrome. The two VPN exit IPs—198.54.132.88 and 198.54.135.222—were assigned to Tzulo, a US hosting provider, though geolocation suggested the servers actually operated in the Toronto and Washington, DC areas. These IPs were blocked at the edge.

Detection Updates and Threat Intelligence Sharing

The team augmented existing detection rules with specific threat-actor indicators. Although no second wave was observed, intelligence gathered from the server suggested the same attacker was hitting other targets, including Twilio; Cloudflare reached out to share its findings with those organizations.

Comprehensive Log Audits

Every system log was screened for fingerprints of this attacker. Because Cloudflare Access serves as central control for all internal applications, the team could search all authentication logs for any trace of unauthorized entry. Employee directory provider logs were also reviewed. No signs of a successful breach were found.

Hardening Measures Moving Forward

Beyond the immediate takedown, Cloudflare is making permanent configuration changes to reduce the risk of a follow-up incident:

• Gateway policy adjustments: Cloudflare Gateway will now restrict or sandbox access to sites hosted on domains registered in the last 24 hours.
• Browser isolation triggers: Any non-allowlisted site containing terms like “cloudflare,” “okta,” “sso,” or “2fa” will be routed through browser isolation technology to prevent payload execution.
• Web scanning: Cloudflare Area 1’s email security will be used to scan the broader web for pages specifically crafted to spoof Cloudflare.
• Stricter Access policies: Authentication policies are being tightened to block logins originating from unknown VPNs, residential proxies, and infrastructure providers—all standard features of the same products Cloudflare sells.

What This Incident Reinforces

This attack validated three core principles of Cloudflare’s security posture. First, hardware security keys remain an effective defense against phishing. Cloudflare has not seen a successful phishing attack since rolling out hard keys to all employees, echoing the experience at Google. Second, eating your own dogfood works: Cloudflare Access and Gateway provided both the protective layer and the central logging and session-management needed to respond swiftly. Third, a paranoid but blame-free culture is a first line of defense. Employees are explicitly encouraged to over-report anything suspicious, and the three staff members who fell for the phish were not punished. Reporting their mistake quickly, rather than hiding it, was precisely what allowed the incident response to succeed.

How the Attack Unfolded

The attacker began the campaign on 2022-07-20 at 22:49 UTC, sending over 100 SMS messages to Cloudflare employees and their family members. Within one minute, employees started reporting the messages to the Cloudflare Security team. The rapid internal reporting was critical—by 22:52 UTC, the team had already verified that the attacker's domain was blocked in Cloudflare Gateway for corporate devices.

At 22:58 UTC, a warning was pushed to all employees across both chat and email channels. Over the next half hour, from 22:50 UTC to 23:26 UTC, the security team continuously monitored the Okta system log and Cloudflare Gateway HTTP logs to identify any compromised credentials. Whenever a suspicious login was found, the session was cleared and the account suspended on discovery.

The phishing site itself was taken down by the hosting provider at 23:26 UTC. Leaked employee credentials were reset by 23:37 UTC. A deeper investigation into the attacker's infrastructure and capabilities began at 00:15 UTC on 2022-07-21.

Indicators of Compromise

The following indicators were observed during the incident and can be used to detect similar activity in your own environment:

Response Recommendations

Organizations facing similar SMS-based phishing campaigns should consider the following measures:

• Ensure that any known malicious domains are proactively blocked at the gateway level for all corporate devices.
• Establish a clear channel for employees to quickly report suspicious messages directly to the security team.
• Monitor identity provider logs and HTTP proxy logs in real time to spot credential reuse attempts immediately after a phishing wave is detected.
• Have a process ready to force logout and suspend accounts the moment a compromise is suspected, rather than waiting for the affected user to respond.
• Coordinate with hosting providers to expedite takedowns of phishing infrastructure.
• Reset any credentials that may have been exposed as soon as the scope of the leak is understood.
• After the immediate threat is contained, dedicate time to a full reconnaissance of the attacker's infrastructure to understand their methods and potential future targets.

For assistance with similar attacks, Cloudflare's incident response team can be reached at [email protected]. Additional details on implementing security keys are available in Cloudflare's public documentation, or via [email protected].