Say Hi to HelloTDS: The Infrastructure Behind FakeCaptcha

Key Points

• Gen Threat Labs has discovered and analyzed an elaborate Traffic Direction System infrastructure delivering FakeCaptcha, tech scams and other malware campaigns to select users. 

• The campaign entry points are infected or otherwise attacker-controlled streaming websites, file sharing services, as well as malvertising campaigns. 

• Victims are evaluated based on geolocation, IP address, and browser fingerprinting; for example, connections through VPNs or headless browsers are detected and rejected. 

• The FakeCaptcha campaign is increasing its stealth by mimicking legitimate software websites. 

• A new variant of FakeCaptcha spreading information stealers and RATs avoids detection by employing Unicode math fonts. 

Introduction

The FakeCaptcha campaigns have become a widespread malware infection vector, using clever social engineering and exploiting internet users’ confusion about common CAPTCHA practices to trick victims into infecting their own computers, typically with information-stealing malware like LummaC2, by pasting malicious commands into the Windows Run dialog. 

We have discovered an elaborate infrastructure actively used to deliver multiple variants of FakeCaptcha and other malicious content to select users. At the core of the operation is an attacker-controlled Traffic Direction System network. It has a single purpose—to fingerprint the visitor’s device and network details to determine what type of content to deliver. This could be malicious, monetized or decoy content, or no content at all. For reasons we will describe later, we are calling this infrastructure HelloTDS.

As shown in the graphic above, the scope of the campaign is massive; in April and May 2025 alone, we have protected over 4.3 million users worldwide. In terms of absolute numbers, the most affected regions include the United States, Brazil, India, and Western Europe. However, when adjusting for population size and user base, a different trend emerges: the highest relative risk is concentrated in the Balkan countries of Europe and in parts of Africa, particularly Rwanda, Egypt, Tanzania, and Kenya.

Attack Chain

At a high level, the attack works as follows: The victim visits an infected website or clicks on a malicious ad. The entry website requests a JavaScript file from the initial HelloTDS endpoint, which fingerprints the connection and decides whether to serve content or stay idle. If the user is not deemed a suitable victim, the attack stops here. Otherwise, the server responds with a script that further fingerprints the browser, logs mouse movements and similar, eventually sending another request to receive the final payload containing a redirect to the malicious landing page. Among users who passed the initial check, FakeCaptcha was observed to be the most prevalent malicious landing page, with Fake Updates, file downloads containing encrypted malware, tech scams and other fraudulent campaigns also having a share. 

One specific example of the full attack chain is illustrated in the next figure: We visited the website dailyuploads[.]net, uploaded an arbitrary image file, and navigated to the link generated by the service. The resulting page included a script from HelloTDS, and when we clicked the download link, we were involuntarily redirected to a FakeCaptcha landing page attempting to trick visitors into executing the Emmenhtal loader.

From Movie Streaming or File Sharing to Malware

Besides ad networks, the primary source of traffic for HelloTDS are legitimate-looking, properly functioning websites, such as movie streaming sites, torrent mirrors, file-sharing services, link shorteners, or porn websites. However, these websites are specifically crafted or manipulated—presumably also by the attacker—to cooperate with the attacker’s infrastructure and load malicious scripts. This tactic completely bypasses the need for malvertising campaigns through “legitimate” advertising companies, as these websites request the attacker’s scripts directly.

Moreover, we have observed a repeating pattern in some of these websites, which offer file sharing services and promise their users financial gains. These include dailyuploads[.]net, streamtape[.]{com,net,to}, watchadsontape[.]com, bigwarp[.]art or savefiles[.]com to name a few. Security or data privacy is clearly not a priority for these services, as anyone can sign up with any e-mail address without verification. We suspect that these websites are cloned from some existing file sharing service and controlled by the same threat actor who controls HelloTDS and eventually delivers FakeCaptcha, for the primary purpose of embedding malicious popups and redirects within the page (although email & password harvesting could be a “welcome” byproduct).

The Anatomy of a HelloTDS Domain

An “entry point” website, like those described previously, will usually statically embed one or more HTML snippets loading remote JavaScript that look like this:

(In case of file-sharing websites described above, this snippet will be included in the page with the uploaded file, i.e. the one you share the link to, but not on the main page itself.)

The source domain is randomly rotated and both path segments are randomly generated (although their length and character sets are always the same), presumably to prevent static detection. Despite this, it is easy to spot these URLs with a human eye (or a clustering algorithm). All the HelloTDS domains we have seen so far have the same format: The apex domain consists of 2-3 (pseudo)words with a “.top”, “.shop” or sometimes “.com” TLD; optionally, a short subdomain is used, consisting of usually 2, but up to 4 random letters. 

Examples of these domains include:

• yr[.]unasonoric[.]com
• gq[.]binesyorker[.]com
• sb[.]rowlandpodogyn[.]shop
• nutatedtriol[.]com

Apart from the distinctive domain names, another sign that speaks for HelloTDS is that the domain names are almost exclusively registered in Panama through the Pananames registrar, and the servers reliably present Let’s Encrypt certificates during TLS handshakes.

In an attempt to make tracking HelloTDS infrastructure difficult, the authors designed it to be highly dynamic, frequently rotating active domains and their DNS records. Even so, we have identified that all domains associated with this infrastructure are registered under AS7979 (SERVERS-COM) within the following IP ranges:

• 23.83.64.0/22
• 23.109.120.0/22
• 23.109.128.0/19
• 23.109.170.0/24
• 94.242.232.0/21
• 172.240.104.0/21
• 172.241.48.0/21
• 172.255.96.0/20
• 173.0.146.0/23
• 173.237.64.0/20
• 188.42.104.0/21
• 188.42.240.0/21
• 209.192.192.0/18
• 212.117.184.0/21 

Another interesting aspect shared by all HelloTDS servers is the usage of the non-standard HTTP header “megageocheckolololo”, which we believe is not commonly used by any well-known service. Its presence in the “Access-Control-Allow-Headers” HTTP response header is another indicator of a HelloTDS server.

Lastly, domains belonging to HelloTDS can be reliably identified using the information they expose via “robots.txt”:

The “/hi” endpoint always returns a simple HTML response with a single text node that says “Hello!” — hence the name HelloTDS.

First Stage: Fingerprinting Based on Network Information

The first decision is made by the HelloTDS server immediately upon receiving the request sent from one of the entry point websites. Since we can only send requests and observe the servers’ responses, it is difficult to tell the exact shape of the server’s decision tree. We suspect that several factors, such as IP/geolocation checks, timeouts, or maybe even pure randomness, may contribute to the result in some way.

From the user’s point of view, there are two possible outcomes. In one case, the server responds with a no-op script (usually an empty function or a single-line comment containing 2 or 3 letters, like “// ipx” or “// mt”, likely codes used for “debugging” the TDS), meaning the user will not get any malicious content (from that endpoint). Alternatively, the server will respond with a large JavaScript that performs heavy client-side fingerprinting and eventually performs a subsequent request to another HelloTDS endpoint. Either way, the server sets a pair of cookies in the response; these encode information about the client’s browser, operating system and network, as detected by the server, and may be used as a client-side cache for further requests (although we have found that tampering with them is generally not useful).

The cookie values contain Zlib-compressed binary data encoded in Base64. Although the low-level data format is unknown, the data itself contains readable ASCII strings like the client’s IP address, country, or ISP, which reveal the purpose these cookies likely serve.

Second Stage: Fingerprinting in the Browser

Contrary to the logic executed on the server, the next fingerprinting routine is performed in the browser (by the returned JavaScript) and can thus be reverse-engineered. The exact code returned from different HelloTDS endpoints varies somewhat in structure and complexity (at the very least, the server appends a timestamp comment to hinder hash-based detection), but all of them share the same basic high-level functionality.

Crucially, the JavaScript sent by the server contains an encrypted configuration variable — a JSON string where each alphanumeric character is substituted with some other. This part of the code can be easily identified: Look for a function call with two arguments, the first being the encrypted JSON string and the second being the key: A concatenation of the characters a-z, 0-9 and a random permutation thereof. This obfuscation is not unique to HelloTDS; however suspicious it may be for an ad network to employ this technique, we have also observed this behaviour in scripts employed by the Czechia-based Clickadu ad network, which happens to share certain characteristics with the threat actor’s infrastructure.

The number of key-value pairs in the configuration object varies, but some common ones we regularly encounter are “url”, “zone_id”, “uuid_url”, “rot_url”, “metric_url”, “timezone_offset” and/or “timezone_diff”. Other keys that particularly stand out due to their names are “devtools_protection” and “philanthropic_level”, which were set to “true” and 0 respectively whenever we inspected a chain that landed on FakeCaptcha in the end.

The “*_url” keys contain further HelloTDS URLs, which are used to retrieve a sort of unique identifier (“uuid_url”), the target URL (“rot_url”), an endpoint to report errors and other metrics to (“metric_url”), and an endpoint for mouse movement and device sensors tracking (“url”). Notably, the “rot_url” always contains a special parameter named “md” with a placeholder for the fingerprinting information collected by the script.

The JavaScript collects the following information:

• Basic browser info: window width and height, document referrer, window location (URL), browser language, current datetime, time zone offset, and whether the site is shown in a top-level window or an iframe,

• the “user id” previously returned by the UUID endpoint,

• whether or not a mobile browser is used (by checking if the deprecated window.orientation property is defined),

• whether or not a touch screen is present (by reporting the value of the window.navigator.maxTouchPoints property),

• page title information, most common words in the host webpage as well as any keywords declared in the host document’s head element,

• the approximate amount of physical memory and the number of processor cores,

• battery status (level, charging state),

• WebGL vendor and renderer,

• a “sandbox score” consisting of 6 flags, e.g., whether the browser is Headless Chrome, or whether specific video codecs are supported,

• network information, e.g., network type (Wi-Fi, Ethernet, cellular, …), effective and maximum bandwidth, or the estimated round-trip time,

• screen orientation and colour depth,

• whether cookies are enabled.

A JSON object containing this information (as well as some keys from the config) is Base64-encoded and sent in the md parameter to the rotated URL from the config via a POST request. The response contains a JSON object with a “url” key as well as a TTL and bidding details.

The returned URL is the last HelloTDS endpoint in the whole chain.

Third Stage: Final Payload with Redirect to Landing Page

The final step in the HelloTDS pipeline is a simple JavaScript-based redirect to the target URL.

In this case, bestfree4u[.]com simply responded with a 301 redirect to a FakeCaptcha landing page at finding-from-internet[.]fly[.]storage[.]tigris[.]dev/seacrh-result[.]html. However, when accessed from a different environment, the same domain may seem harmless. In other cases, the final HelloTDS redirect leads to tech support scams, malicious file downloads, fake browser updates, potentially unwanted browser extensions, or cryptocurrency investment platforms.

The Destination: FakeCaptcha Redirectors

In the past months, we have seen a highly predictable pattern in the malicious URL payloads served by HelloTDS: Almost universally, they were machine-generated domains consisting of a couple of English words and a “.com”, “.shop”, “.online”, “.info”, “.live”, “.pro” or similar TLD, and the URL path was a string with 24 hexadecimal digits, the first two usually being 67 or 68. These URLs served as simple redirects, either to FakeCaptcha, or sometimes to a decoy—usually some (benign but potentially unwanted) browser extension or cryptocurrency product website. We have seen multiple of these URLs redirect to both a FakeCaptcha landing page and a decoy at different times, which removes any doubt about this being an inherently malicious service. Example URLs include the following:

• actednow[.]com/675cb495c39bc481ddf8edd6,

• buzzflying[.]shop/6767af2ee2aa535e92d62a64,

• goldtera[.]live/6758b1d6467532a801fa06c4,

• orbito[.]online/677120fb2cca41d88a7392a2.

The domains used by this service could be reliably identified by being registered under Namecheap in Reykjavik, Iceland, using a Let’s Encrypt TLS certificate, and resolving to one of the following IP addresses:

• 5.161.37.228,

• 5.161.110.119,

• 5.161.178.111,

• 23.105.163.27,

• 23.105.163.55,

• 34.142.174.238,

• 172.104.80.249.

Recently, the attacker has started employing more sophisticated masking even at the level of the final payload.Additionally, the structure of served URLs redirecting to FakeCaptcha has changed – they now often include parameters with placeholders, which may not even be filled in, yet the victim can still be redirected to a FakeCaptcha landing page. We have seen different variations of these URLs, some of which omit specific parameters.

Interestingly, some of the URLs served by HelloTDS redirect victims to FakeCaptcha landing pages, but when accessed in a controlled environment, they often mimic some legitimate websites and serve some benign content. One example of such a website is 

hxxps[://]avs4u[.]net/?sub1=39388&sub2=…&sub3=ID&sub4=677886&sub5=0.0004752 — while it often redirects the victims to FakeCaptcha landing pages, it may also display mimicked content of the legitimate website www.avs4you.com, a software for processing videos and images. The downloadable binary is also legitimate, indicating an attempt to conceal malicious activity.

Another example of a URL redirecting victims to FakeCaptcha but serving legitimate content in a controlled environment is hxxps[://]arcadeclassic[.]org/?sub1=681978&sub2=0.00037565.

We therefore tried to understand the reasoning behind the decision of whether malicious content is served. As part of this effort, we explored the potential influence of the cookies being set, which we mentioned earlier. Ultimately, we have concluded that the decision is probably based solely on the IP address of the client. We suspect that if the IP address originates from a known VPN or other anonymizing services, the victim is consistently redirected to some benign content, likely because such users are not target victims and may potentially be security analysts. In such cases, HelloTDS delivers benign content to obscure its actual behavior, effectively evading analysis and avoiding detection.

Delivered Malicious Content

In our analysis of HelloTDS landing page redirectors, we observed that they serve a mix of both malicious and legitimate content. These “clean” redirects, however, often lead to investment-related sites, especially those involving cryptocurrencies. We believe that this choice is deliberate. Firstly, generating traffic to advertisers through non-consensual clickjacking may serve as an alternative, more predictable source of income for the attacker without “stepping into the dark” and serving hard malware. Furthermore, if the primary objective of FakeCaptcha is to infect victims with information stealers that ubiquitously target crypto wallets, redirecting users who were not deemed as ideal victims to a crypto investment platform may be the most logical strategy for the attacker in the long run.

On the unequivocally malicious side, various forms of FakeCaptcha were predominant, but we have also encountered Fake Updates, tech scams, download links with encrypted archives delivering LummaC2, and various other scams. Some specific examples are listed below.

Key Takeaways and Defensive Measures

The HelloTDS infrastructure behind FakeCaptcha campaigns demonstrates how attackers continue to refine their methods to bypass traditional protections, evade detection, and selectively target victims. By leveraging sophisticated fingerprinting, dynamic domain infrastructure, and deception tactics (such as mimicking legitimate websites and serving benign content to researchers) these campaigns achieve both stealth and scale.

What You Can Do:

• Use reputable security software with real-time protection to block known TDS and FakeCaptcha domains. Products from Norton, Avast, AVG, and Avira automatically protect users against these threats.
• Enable browser-level protections like anti-tracking and ad-blocking extensions, which may prevent the initial malicious scripts from loading.
• Be cautious with file-sharing and streaming sites, especially those that promise monetary rewards or allow anonymous uploads without verification.
• Avoid copying and pasting commands from unknown or suspicious websites into system dialogs like Windows Run.
• Inspect suspicious domains manually or through security tools—look for signs like oddly-structured URLs, frequent domain rotation, or generic domain names.

FakeCaptcha is not just a social engineering trick. It's the final step in a well-orchestrated system that filters, evaluates, and targets users with precision. Understanding the infrastructure—HelloTDS in this case—is key to disrupting the full chain of attack.

Indicators of Compromise (non-exhaustive)

You can find the complete list of IoCs on our GitHub.

File Sharing Entry Websites

dailyuploads[.]net

streamtape[.]to

streamtape[.]net

streamtape[.]to

watchadsontape[.]com

bigwarp[.]art

savefiles[.]com

HelloTDS Domains

yr[.]unasonoric[.]com

gq[.]binesyorker[.]com

sb[.]rowlandpodogyn[.]shop

nutatedtriol[.]com

mixscoggan[.]shop

bu[.]unrimedironize[.]shop

FakeCaptcha Redirectors

actednow[.]com/675cb495c39bc481ddf8edd6

buzzflying[.]shop/6767af2ee2aa535e92d62a64

goldtera[.]live/6758b1d6467532a801fa06c4

orbito[.]online/677120fb2cca41d88a7392a2

bestfree4u[.]com

avs4u[.]net/

arcadeclassic[.]org

FakeCaptcha Landing Pages

adelaidavizcaino[.]com/cpw

partage-de-medias[.]fly[.]storage[.]tigris[.]dev/affiliate-link[.]html

finding-from-internet[.]fly[.]storage[.]tigris[.]dev/seacrh-result[.]html