Cloudflare’s 36-Minute Phishing Window: What a Look-Alike Domain Can—and Cannot—Tell You

A suspicious domain does not always sit dormant for weeks. Sometimes the gap between registration and a live attack is measured in minutes.

On July 20, 2022, attackers targeted Cloudflare employees with text messages linking to a counterfeit login site. Three employees entered credentials, but Cloudflare reported that none of its systems were compromised: its required security keys prevented the attackers from completing authentication. Cloudflare published its account on August 9, 2022. These are the company’s reported findings, not an independent forensic audit. Source: Cloudflare incident report, August 9, 2022.

For business owners and security teams, the useful question is not which single product would have stopped everything. It is how to connect a suspicious-domain signal to decisions quickly enough—and how to remain protected when that signal arrives too late.

What happened: the verified timeline

Cloudflare reported that the phishing domain, rendered here in non-clickable form as cloudflare-okta[.]com, was registered at 22:13:04 UTC on July 20. The name combined the target’s brand with that of its identity provider. This was a plausibly business-related domain, not simply a one-letter typo. The phishing page impersonated an Okta login screen. Cloudflare, August 9, 2022.

The report’s detailed timeline places SMS sending at 22:49 UTC; its narrative says messages began at 22:50. That one-minute discrepancy does not change the central finding: registration preceded the attack by less than 40 minutes. The approximately 36-minute window in this article’s headline is calculated from the registration time to the timeline’s 22:49 entry, not a claimed measurement of a monitoring service’s latency.

Cloudflare’s account records the following sequence, all on July 20, in UTC:

• 22:13:04: The phishing domain was registered.
• 22:49: The timeline records 100+ SMS messages being sent. Separately, the narrative says at least 76 employees received messages within less than a minute; message count is not employee count.
• 22:50: Employees began reporting the texts.
• 22:52: Security verified that the domain was blocked through Gateway for corporate devices.
• 22:58: A company-wide warning went out through chat and email.
• 23:26: The hosting provider took the phishing site down.
• 23:37: Leaked employee credentials had been reset.

These times come from the published incident timeline. They describe this response, not service-level targets that every organization should assume it can reproduce.

Cloudflare also reported clearing active sessions and suspending affected accounts during the response. Its monitoring had not detected the registration before the attack because the domain had not yet been published as a new .com registration. That is evidence about the registration information available to Cloudflare at that moment—not proof that every monitoring system would have seen the same delay. Source: Cloudflare’s registration and response analysis.

The mechanism: borrowed credibility, then credential relay

The domain joined two familiar names into something that could plausibly look like an employee sign-in destination. That makes it a useful example of combosquatting: a brand combined with another meaningful term to create apparent legitimacy. The lure arrived by SMS, outside the normal corporate inbox.

According to Cloudflare, the fake site relayed entered credentials to the attacker through Telegram in real time. The attack flow included a prompt designed to capture time-based one-time passwords. A short-lived code is not necessarily safe from phishing: an attacker can submit a captured code to the real service before it expires. Cloudflare described an additional AnyDesk download stage, but said no team members reached that stage. It did not report a successful remote-access installation through this attack. Source: Cloudflare’s mechanism and outcome analysis.

The decisive authentication control was different from a typed code. Cloudflare required FIDO2-compliant physical security keys. Although three employees submitted credentials, the attacker could not satisfy that requirement.

Correctly implemented WebAuthn uses credentials scoped to a relying-party identifier, alongside verification of the expected origin. A look-alike website cannot simply obtain a valid authentication assertion for the legitimate relying party by asking someone to type a code. This is a technical explanation of the protection, not a claim that all implementations or account-recovery paths are equally secure. See the W3C WebAuthn Level 2 Recommendation, April 8, 2021, especially the authentication verification requirements.

CISA’s October 31, 2022 guidance announcement recommends moving toward phishing-resistant MFA. For procurement, the practical distinction is between authentication designed to resist a counterfeit origin and authentication that merely adds another secret or approval step.

What defenders could observe—and what those signals mean

1. A new brand-plus-login domain is a lead, not a verdict

A registration combining your brand with an identity-provider name, support term or sign-in cue deserves contextual review. Ask whether your organization or an authorized supplier actually owns and uses it. Compare it with a maintained inventory of approved login destinations.

Registration age and name similarity alone do not establish malicious intent. In this case, the employee texts and counterfeit login page supplied much stronger evidence than the name alone. The general recommendation is to prioritize the combination of suspicious naming, observed delivery and impersonating content—not to label every unfamiliar registration fraudulent.

2. No email evidence does not clear a domain

This attack’s initial delivery channel was SMS. An MX record, which identifies a domain’s mail-handling destination, was not necessary for the attacker to send those text messages. That is an inference from the documented channel; it is not a claim about the domain’s actual MX configuration.

DNS Twister’s current features page describes look-alike monitoring and MX-related alerts. Those can contribute investigation leads, but an MX-focused signal must not become a gate that prevents investigation of a text-message lure or fake web login. Nor should monitoring be treated as a guarantee of detection before first use.

3. Local visibility may begin with a person

Cloudflare’s timeline shows employee reports beginning at 22:50. Messages reached personal and work phones, and some employees’ family members were targeted. The source of the phone-number list was not established in the report. Do not turn that uncertainty into an unsupported claim that an employee directory was breached. Source: Cloudflare’s targeting analysis.

The operational lesson is to give people an obvious reporting route that works when the suspicious message is on a personal device. A screenshot, sender number and receipt time can give responders an initial lead without asking the recipient to open the link again.

A practical investigation and response workflow

The following is a recommended workflow derived from the case, not a reconstruction of every action Cloudflare performed. A small business can assign these responsibilities to its IT provider; a larger team can map them to its incident-response process.

Step 1: Preserve the report safely

Record the original message, sender number, recipient, received time and time zone, plus the destination URL as text. Preserve the original message where possible. Distinguish the first time your team saw it from the first time it existed: those are different facts.

Do not ask an employee to revisit the page or enter test credentials. Keep personal information and potentially sensitive URL parameters out of public scanners and public abuse reports. Investigate web content only through an appropriately isolated environment and an authorized process.

Step 2: Establish the legitimate destination

Check your approved identity-provider configuration and domain inventory. Confirm uncertainty through a known IT contact, not the number in the suspicious text. Determine whether the URL belongs to an approved service or to a separate registration borrowing familiar words.

Write down the actual hostname and registrable domain. A brand name appearing somewhere in a URL is not equivalent to ownership by that brand. If the page impersonates a supplier’s login, involve that supplier through a verified security channel.

Step 3: Build a small, timestamped evidence record

Collect available registration data, DNS answers, hosting information and safely obtained page evidence. Record when and how each observation was made. Missing public registration details are a limitation, not proof of concealment by a criminal.

Separate observations from conclusions. “The page displays our login branding and requests credentials” is an observation if safely verified. “The domain is controlled by the same actor as another campaign” requires additional evidence. Shared hosting or a similar name alone is insufficient attribution.

Step 4: Check exposure, not just clicks

Ask affected users whether they opened the link, entered a password or code, approved an authentication request, or downloaded and ran anything. Make reporting non-punitive so the response team gets the facts quickly.

Review identity-provider and relevant endpoint logs for the reported period. A blocked phishing page does not establish that every recipient was blocked, especially on unmanaged phones. Conversely, a visit does not prove account takeover. Record successful logins, failed attempts and visibility gaps separately.

Step 5: Contain the relevant risk

Where evidence supports credential exposure, follow your identity provider’s process to reset credentials, revoke active sessions and inspect authentication-method changes. If software was executed, invoke endpoint incident response as well; a password reset alone is not a complete response to a potentially compromised device.

Block confirmed malicious destinations in the controls you operate, and warn affected staff through known channels. Send the registrar or hosting provider a concise, evidence-based report identifying the impersonated organization, URLs, timestamps and observed abuse. DNS Twister’s guide to writing a takedown email can help structure that report. Preserve evidence before disruption where practical, but do not delay urgent containment just to perfect a case file.

Step 6: Close with a recorded decision

Assign an owner, disposition and next review time. If a provider removes the page, verify the result and check for replacement messages or domains. Takedown does not undo exposed credentials or automatically remove an attacker’s access.

For a compact incident checklist, confirm that you have:

• Preserved the lure and its timestamps.
• Verified the legitimate domains and login destinations.
• Assessed recipient actions, not just link visits.
• Reviewed account and device evidence.
• Contained relevant access and endpoint risks.
• Reported the abuse with supporting evidence.
• Documented unresolved visibility gaps and assigned a follow-up owner.

What this case does not prove

This is a historical case study, not evidence that every current phishing campaign follows the same sequence. Cloudflare’s account does not establish a universal detection window, the source of the targeting list, or what would have happened under another company’s identity controls.

Likewise, successful security-key protection here does not make endpoint compromise, stolen sessions or weak account recovery irrelevant. That limitation follows from the scope of authentication protection: verifying a login is not the same as protecting every subsequent use of the account. Review fallback factors, help-desk recovery and authenticator enrollment alongside the main login path.

Domain monitoring and authentication answer different questions. Monitoring asks whether suspicious infrastructure exists and warrants investigation. Phishing-resistant authentication makes stolen credentials less useful against protected login flows. Reporting and response connect those layers when the attacker moves faster than discovery.

The durable lesson is not to wait for a perfect alert. Build a process that can act on an imperfect signal, and authentication controls that still help when someone trusts the wrong domain.