Cloudflare Pages is designed to make deployment easy. That ease is also attractive to criminals who need many short-lived web pages. Infoblox reports that Help TDS has used free pages.dev sites since April 2026 and creates hundreds of new Pages sites per day. The case is an abuse problem on a legitimate platform, not evidence that Cloudflare endorsed or operated the scam.

Defenders need to separate three questions. How large is the Pages platform? How many observed Pages pages contain terms associated with the scam? How many can be attributed to Help TDS? The answers are very different, and the measurements should not be merged.

The hosting pattern

Cloudflare documents Pages as a service for deploying applications to its global network. Infoblox says Pages sites inherit Cloudflare's bot detection, which can complicate automated scraping, and describes more than 125,000 new pages.dev subdomains per day. The actors reportedly create about 300 sites per day, with most domains resolving for about one week.

The operator uses multiple naming conventions and sometimes shows a decoy page when a domain is scanned directly. Infoblox detected about 30,000 actor-associated domains by mid-September, only about 16,000 of which had been announced on the Telegram channel. Its model identified some domains about seven days before use.

Those facts explain why a simple "all Pages are suspect" rule is not useful. Legitimate Pages sites vastly outnumber the actor's sites, and the actor can choose names that overlap with ordinary naming patterns.

What ZoomEye returned

On 2026-11-08, hostname="*.pages.dev" && http.body="Microsoft" returned 61 observations. The corresponding Windows query returned 83. The union returned 130.

These results show that public Pages content can be found with brand-related body strings. They do not show that the 130 observations are malicious, that they belong to Hotejka, or that a user was redirected. A tutorial, a product page, a test site, or a cloned page can contain the same strings.

The generic union count is useful as a candidate population for manual review. A reviewer should inspect the page's full URL, response behavior, hosting project name if visible, redirect chain, and historical changes. A body string alone is not enough to submit an abuse report.

The event-specific /help/?d query returned 207 WordPress-fingerprinted observations. That count is more defensible as a Help TDS-related candidate because it combines a WordPress fingerprint with the redirect marker described by GoDaddy. It still does not prove actor control of each website.

Where platform abuse reporting fits

Cloudflare provides an abuse reporting process. Its documentation notes that the response depends on the service involved and asks reporters to include specific URLs. A report should contain the exact pages.dev URL, a description of the observed content, access time, and evidence that the page is being used for phishing or another prohibited activity.

The report should not claim that every Pages domain is part of Help TDS. It should identify the individual page and the evidence that connects it to the lure. Cloudflare cannot investigate a generic hosting platform based on a brand keyword.

For defenders, the abuse report is one action in a larger response. It can remove a specific page. It does not recover a user's account, clean a compromised WordPress site, or prevent the operator from creating another project.

Why attribution needs the actor's evidence

Infoblox supports its attribution with Telegram announcements, domain-generation analysis, DNS history, decoy pages, named domains, affiliate code, and relationships to prior infrastructure. The report ties Hotejka to the operation and assesses ROI777 as a predecessor. These are not conclusions that can be derived from a ZoomEye body match.

External scanning can confirm that a page contains a string. It can show that a hostname resolves to a service. It can provide a timestamped count. It cannot establish why a particular page was created or who controls the account behind it.

That distinction matters for reporting and remediation. A high-confidence actor domain can justify blocking and investigation. A generic brand match can justify a queue item. A named account-level finding requires separate evidence from the hosting provider, DNS records, or the actor's own publications.

A proportionate response

Organizations should block known actor infrastructure and predicted high-confidence domains where their threat-intelligence process supports it. They should also block the behavioral sequence: a compromised WordPress page, an unexpected redirect, a full-screen browser warning, and a remote-access download.

Website operators should monitor for the /help/?d marker, hidden plugin files, unauthorized administrator activity, and outbound requests to the reported C2 endpoints. Users should be taught not to call the number on an unexpected security pop-up.

Cloudflare Pages is not the root cause of the campaign. It is a convenient hosting layer that the actor has learned to use at scale. The useful metric is not how many Pages sites exist. It is how many observed pages can be connected to the actor with documented evidence, and how quickly the organizational response can act on those high-confidence findings.

References

  • Infoblox, "Inside Help TDS: Hotejka, Cloudflare Pages and Predictive Detection": https://www.infoblox.com/blog/threat-intelligence/2026/10/inside-help-tds-hotejka-cloudflare-pages-and-predictive-detection

  • Cloudflare, "Cloudflare Pages": https://developers.cloudflare.com/pages/

  • Cloudflare, "Report abuse to Cloudflare": https://developers.cloudflare.com/fundamentals/reference/report-abuse/

  • Cloudflare, "View and submit reports": https://developers.cloudflare.com/fundamentals/reference/report-abuse/submit-report/

  • GoDaddy, "Help TDS and its Malicious Plugins Redirect Thousands of Sites to Tech Support Scams": https://www.godaddy.com/resources/news/help-tds-malicious-plugins-redirect-tech-support-scams