DEV Community

StarkMan
StarkMan

Posted on

A Repeatable ZoomEye Workflow for Tracking Help TDS-Style Infrastructure

#helptds #zoomeye #wordpress #cloudflarepages

A Repeatable ZoomEye Workflow for Tracking Help TDS-Style Infrastructure

Ad hoc searches can produce impressive numbers without producing a defensible monitoring program. The Help TDS case needs a repeatable workflow because the actor rotates Pages domains, changes redirect destinations, hides content from scanners, and uses multiple naming algorithms. A single count on a single day cannot capture those changes.

The workflow below separates query purpose, scope, and confidence. It uses the observations collected on 2026-11-08 as a baseline. The counts are snapshots, not a permanent inventory or a victim estimate.

Define the question before the query

Start with one of four questions:

  • Are there public WordPress pages that expose the reported Help TDS redirect marker?
  • Are named control domains or addresses visible in public data?
  • Is the broad /help/?d string present beyond the WordPress population?
  • Are pages.dev pages using Microsoft or Windows brand terms?

Each question has a different query and a different action. A monitoring plan that asks "how much Help TDS is there?" without defining the unit will produce a number that cannot be compared over time.

Establish the baseline

On 2026-11-08, the narrow WordPress query app="WordPress" && http.body="/help/?d" returned 207 observations. The broader http.body="/help/?d" query returned 3,498.

The named-infrastructure query domain="hotejka.ink" || domain="hotcname.help" || ip="91.196.33.144" returned 11. The stored http.body="woocommerce_inputs" query returned seven.

The Pages brand-reference queries returned 61 for Microsoft, 83 for Windows, and 130 for the union. Those three are context measurements. They should remain in a separate section from the actor-specific and redirect-specific results.

Record the exact dork, scope, timestamp, count, status, and link for every query. Store the selected role and the selection reason. Do not overwrite a failed query with a zero. A failed request is missing evidence, not proof that the infrastructure disappeared.

Assign confidence tiers

Tier one is named, research-attributed infrastructure. The 11 observations for the Hotejka domains and IP belong here, with the caveat that current control still needs separate verification.

Tier two is a narrow behavioral marker. The 207 WordPress observations with /help/?d belong here. The string is event-specific enough to support triage, but a public match does not prove infection.

Tier three is a broad marker or malicious-string search. The 3,498 /help/?d observations and the seven woocommerce_inputs observations belong here. They can guide hunting and measure public visibility, but they require enrichment.

Tier four is generic platform context. The 61, 83, and 130 Pages brand-reference counts belong here. They describe a platform population and should never be labeled Help TDS.

The tiers should appear in dashboards and reports. A combined total that adds all of them would double count assets, mix unrelated infrastructure, and create a misleading exposure figure.

Compare like with like

A trend requires the same dork, scope, and collection method. A change from 207 to 250 on the same query might indicate more public matches, fewer blocked responses, index changes, or cleanup, but it does not prove more infections without a separate sample review.

A change from 130 to 207 across different queries is not a trend. It is a comparison of different populations. The same rule applies to search results with and without the WordPress fingerprint, or to IP lookups and domain lookups.

When a domain expires, a scan can return zero because the page is gone, because the scanner was blocked, or because the query was too strict. Preserve the result status and review a sample. A zero-count success and a failed query are different records.

Review samples, not just totals

For each tier, select a bounded sample and inspect:

  • The final URL and redirect chain
  • The page title and visible content
  • The hosting and DNS context
  • The response to a second request
  • Whether the page shows a decoy
  • Whether the marker appears in code or only in text
  • The first and last observation times

The sample review prevents a query from becoming a number-only exercise. It also gives the team a way to estimate precision without claiming that the entire population was manually verified.

Build an action map

High-confidence named domains should feed a blocklist and retrospective DNS or proxy hunt. The WordPress marker should feed web and server investigations. The broad body string should feed a lower-priority queue. Generic Pages matches should feed platform-abuse triage and user-awareness review, not automatic takedown or victim notification.

Each action needs an owner and a completion check. A block owner confirms that the rule is deployed and tested. A website owner confirms that the marker is gone from files and database content. An incident-response owner confirms that a user who installed remote software has been interviewed and that relevant credentials were rotated.

What ZoomEye adds

ZoomEye provides a public, timestamped view of services and page content. It can help a team discover candidate WordPress sites, monitor named infrastructure, and compare broad platform populations. It cannot see authenticated plugin inventories, local user records, call-center activity, or a complete victim population.

The strongest use of the tool is not a single headline number. It is a repeatable evidence set that lets analysts distinguish a named control domain from a behavioral marker and a generic brand match. That distinction is what makes the next investigation faster and the next report more honest.

References

Top comments (0)