A Field Guide to TDS Names
Learn what named systems and clusters represent before using them in an assessment.
In this lesson, you will learn to:
- Classify a TDS name by evidence type.
- Avoid turning overlap or shared infrastructure into unsupported common ownership.
A Field Guide to TDS Names
Introduces product names, actor-owned systems, shared services, campaign labels, aliases, and historical tools included in later case lessons.
Names refer to different kinds of things
Keitaro is a legitimate advertising tracker frequently abused in malicious campaigns. ParrotTDS or NDSW/NDSX is an actor-associated malicious routing system observed in compromised-site chains. 404 TDS is a researcher label based on an observed redirect mechanism and appears across unrelated campaigns. Prometheus TDS, also called Cookie Reloaded in Proofpoint reporting, has been used as a shared filtering layer.
VexTrio is an Infoblox actor and TDS ecosystem name. TAG-124, LandUpdate808, KongTuke, and Chaya_002 are overlapping vendor labels whose precise equivalence can depend on collection and analytic definitions. zTDS is an open-source tool abused by the 2026 DriveSurge cluster. BlackTDS was advertised as a criminal drive-by service. Sutra TDS is an older off-the-shelf example documented in academic and security research.
Record aliases with owner and date
Create a name table with the label, naming organization, first and last dates relevant to your case, what the label denotes, known aliases, confidence, and source. Do not silently treat every alias as exact. One vendor may name the delivery system, another the web-injection cluster, and another a broader affiliate network. Overlap can be real without being complete.
Product and service relationships also change. A threat actor may switch from Prometheus to Keitaro to 404 TDS, or use multiple routing layers in one chain. A legitimate product can run on actor-controlled infrastructure. Report “TA569 used a TA2726-operated Keitaro instance” rather than “Keitaro is TA569.” Precise nouns prevent false attribution and protect legitimate providers from guilt by association.
Historical examples still teach, but need dates
BlackTDS reporting from 2017–2018 and Sutra research from the exploit-kit era show how traffic brokerage and off-the-shelf routing developed. They should not be presented as confirmed current infrastructure in 2026 without fresh evidence. Their value is conceptual: customer panels, filtering, payload selection, service pricing, and separation between traffic supplier and malware customer.
For every named example, include an observation window. Use current-tense wording only for current evidence. If a domain, IP address, or provider appeared in an older case, record that it was observed then; do not imply it remains malicious now. Infrastructure can be reassigned, remediated, or shared.
Resources
- Microsoft Research: Dedicated Hosts in Malicious Web Infrastructure — Use the historical study for off-the-shelf TDS examples including Sutra, Simple TDS, and Advanced TDS.