Authors: Infoblox Threat Intel and Confiant
Executive Summary
This post is part 3 in our multi‑part series examining abuse of Keitaro Tracker. In part 1 and part 2, we documented several threat types and actors that leverage Keitaro for a range of malicious activities. Part 2 also provided additional visibility into the prevalence of Keitaro abuse across spam and malvertising ecosystems.
In this final segment, we step back from individual campaigns to look more closely at the ecosystem dynamics behind Keitaro‑leveraged operations. Rather than focusing on specific actors, this post examines structural and behavioral patterns that emerged when we analyzed Keitaro abuse at scale. The blog is organized into four sections:
- A closer look at trends we observed across multiple data sources and analytical lenses
- An overview of Keitaro features commonly used by threat actors for malicious activity
- A discussion of Keitaro cookies and naming collisions
- A candid account of our engagement with Keitaro’s leadership and the takedown results
Gauging Keitaro’s responsiveness to abuse reporting was an important part of this research. We are often asked “did you report X to Y for a takedown?”. While “takedown” by service providers, registrars, or others may seem straightforward, in practice, it is quite complex—whether the provider is a small one like Keitaro, or a giant enterprise like Cloudflare. The complexity arises from the asymmetric advantage threat actors have in the domain name space over both defenders, like us, and providers, like Keitaro. For a security vendor to report abuse, we must compile sufficient evidence. On the provider side, they need to have confidence that the reporter is correct, and most providers try to validate the abuse themselves. In the case of traffic distribution systems and domain cloaking, validation can be difficult. The threat actors, on the other hand, can anonymously register domains in bulk using, if they choose, bulletproof registrars and hosting services. For every domain taken down, they can register five more.
In reality, abuse reporting at the true scale of cybercrime is a resource exhaustion attack against the good guys. As a result, we believe that takedown requests need to be balanced with methods that limit access to malicious resources by the security stack. When we engage with a provider on abuse of their services—whether that be Keitaro or Cloudflare— we are looking to understand their responsiveness, rather than their ability to act on every case of abuse. In both of those examples, we could spend our entire day compiling reports, and they could spend their entire day closing accounts, without long-lasting impact. Instead, we want to measure how readily, when asked, will the provider act. We found Keitaro to be both responsive and proactive to our reporting.
At the same time, abuse reporting is inherently reactive. Heavily abused providers—big and small—should do more to preemptively protect users from their own malicious customers. We said the same in our December reporting on “direct search” (or “zero click”) parking. In a world where cybercrime continues to evolve and explode, it takes a village to combat the multi-trillion-dollar losses and we believe abused providers need to play a bigger part.
Data Sources & Trends
To characterize the Keitaro abuse landscape, we combined datasets from Infoblox and Confiant and analyzed complementary vantage points across the adtech and DNS layers. Infoblox contributed DNS‑centric telemetry for security and threat research, along with adjacent signals (e.g., email logs, HTTP data, and web‑server fingerprints). Confiant’s detections and threat research are driven by telemetry from live advertising transactions (client‑side and server‑side header bidding) and live impression data captured by its real‑time creative verification across thousands of websites and mobile apps. To balance freshness with analytical depth, we scoped this study to October 1, 2025 through January 31, 2026.
Passive DNS and Registration Trends
Across the time window, passive DNS (pDNS) from Infoblox customers recorded ~226,000 DNS queries spanning ~13,500 domains associated with Keitaro‑related activity. Within the same period, we attributed over 8,000 new domain registrations to threat actors using Keitaro. These registrations were concentrated among five registrars: Dynadot, Namecheap, Public Domain Registry, Global Domain Group, and Sav. On most days, query volumes and new registrations were relatively even; a few discrete events, however, skewed the daily counts (see Figure 2).
- October 7, 2025: A threat actor that targets Russian-speaking users with fake government-funded social dividend scams registered hundreds of .com domains (see Figure 1). The timing coincides with a Dynadot promotion celebrating their milestone of 8 million domains under management, which offered unlimited $6.88 .com registrations through Oct 12, 2025.
- November 26, 2025 (Black Friday week): The same actor executed a second bulk buy with hundreds of new domains across .icu, .click, and .digital zone registries. This occurred during Dynadot’s Black Friday/Cyber Monday event.
- October 30 to Nov 1, 2025: We observed orders‑of‑magnitude spikes in DNS queries to Keitaro‑associated domains across multiple customer networks. Our investigation attributed the surge to a single actor abusing the Keitaro TDS for conditional redirects: non‑targeted users were sent to a decoy site closely mimicking a small mobile game company, while targeted users were redirected to online gambling sites.
Figure 1. Fake Russian government social dividend scam using sunpetalra[.]com (image credit: URLScan)
Registrar promotions do not explain all the registration activity, but they lowered acquisition costs at scale, and we observe that multiple actors leveraging Keitaro systematically front‑load domain registrations into such windows before staging campaigns (Figure 2).
Figure 2. DNS queries versus domain registrations
The gambling actor’s Keitaro TDS implemented conditional redirects keyed to IP geolocation and device fingerprinting (OS, browser). Since the actor’s Keitaro traffic rule set generated too many permutations, we summarized it by country, browser, and OS (see Figure 3). Nearly all web visitors that matched the targeting rules fell into one of two cohorts: Android users in Germany and Windows PC users in the United States or Switzerland. Non‑target traffic was diverted to a mobile game decoy or benign Google properties (e.g., YouTube, Google Play). This case illustrates that Keitaro not only scales but also enables fine‑grained audience targeting.
Figure 3. Gambling actor targeted Android users in Germany more than any other group; other targets included Windows PCs in U.S. and Switzerland
Spam Emails
Infoblox also analyzed tens of thousands of emails and clustered 120+ distinct campaigns that abused Keitaro’s TDS for link delivery. As highlighted in our Keitaro part 2 blog, approximately 96% of Keitaro‑linked spam traffic promoted cryptocurrency wallet‑drainer schemes, primarily via fake airdrop/giveaway lures centered on AURA, SOL (Solana token), Phantom (wallet), and Jupiter (DEX/aggregator). Based on infrastructure characteristics and language targeting, many of these wallet-draining actors are likely part of a Russian‑speaking ecosystem. Additional themes included job fraud, subscription phishing (Spotify/Netflix), Amazon Prime renewal notices aimed at Japanese‑speaking users, and “free loan” offers targeting Russian‑speaking users. Figure 4 shows a frequency‑scaled word cloud of token/brand labels extracted from subject lines.
Figure 4. Popular spam token labels
Advertising Channels
Using Confiant’s visibility into digital advertising supply chains, we analyzed 275 million ad impressions delivered via supply paths impacting premium publishers over the observation window. From this telemetry, we identified nearly 2,000 domains hosting Keitaro instances used in malvertising campaigns. To characterize pace and volatility, Figure 5 plots the daily first‑seen volume of newly observed domains.
Figure 5. New Keitaro domains observed daily in advertising channels
Keitaro Features
Keitaro is first and foremost a self-hosted advertising performance tracker designed to conditionally route visitors using flows. Threat actors repurpose this mechanism, transforming a Keitaro server into an all-in-one tool that acts as a traffic distribution system, tracker, and cloaking layer. To help the security industry understand how actors achieve this, we examine a few of Keitaro’s software features, including functionality not explicitly described in its documentation.
Routing Traffic via Campaigns
Keitaro operators can create campaigns to route different visitors to different landing content based on defined rules. Every Keitaro campaign is its own routing container and has a canonical campaign URL, which is built from the domain the operator selects plus the campaign’s unique alias (see Figure 6). Administrators can also park a campaign as the index page of a domain to ensure the campaign loads at the domain root. In many deployments, they assign multiple domains to resolve to the same campaign via the domain settings.
Figure 6. A Keitaro campaign URL with unique alias
The campaign functions like its own TDS configuration inside a single Keitaro instance. The campaign is made up of flows, and each flow has its own filters and logic. Flows use filters to determine eligible web visitors based on their internet profile: device type, model, operating system, geolocation, referrer, browser, or URI parameters. Using schemas, a flow can define the routing action for matching internet profiles, such as splitting traffic between two landing pages, sending them directly to a single page, or triggering another action. This is extremely powerful for a threat actor that wants to serve multiple threat types and maximize the capitalization of a visit. Actors can even layer filters together, starting with broad strokes such as checking geolocation or browser language preferences, and then examining each visitor’s system attributes. A Keitaro campaign can consist of multiple traffic flows. When a visitor hits a campaign URL, Keitaro decides where to send that click by following a standard priority order of Forced → Regular → Default. Figure 7 illustrates Keitaro’s decision tree for prioritizing and routing web traffic. Incoming clicks are evaluated against any forced flows first; if none apply, the system checks regular flows using position or weight‑based rotation, then falls back to the default flow or serves a white page.
Figure 7. Keitaro flow priority ordering
- Flow: the container/lane Keitaro selects for a click (Forced → Regular → Default). It’s the unit that handles the visitor’s routing direction.
- Filter: the gate on a flow that decides who is allowed in (e.g., by geo, device, referrer, time). It’s attached to a specific flow and can be as strict or open as you need, even empty (meaning everyone).
- Schema: the action plan inside the chosen flow (split landers/offers, direct redirect, or another action). It defines what happens after a visitor passes the filter.
Cloaking
Cloaking can be implemented using multiple homebrewed techniques or via commercial cloaking kits that are sold as software-as-a-service (SaaS) services. These kits usually support both server-side and client-side integrations, and Keitaro can integrate seamlessly into some of these kits. However, the core TDS feature set of Keitaro can be (and often is) used for cloaking without any additional external tooling. Figure 8 shows a typical cloaking kit integration diagram.
Figure 8. Architecture diagram of a typical cloaking kit integration
For several years, Keitaro offered direct integrations with third-party cloaking software, such as IMKLO, and even advertised cloaking as a feature early on in their company history. However, they removed these integrations in recent versions of the software. Keitaro is so feature-rich though, that threat actors are undeterred by these changes and still use the software to hide their true intent. Even though Keitaro removed direct integrations, there are several ways to enable cloaking from the instance and third-parties provide documentation on how to use their cloaking software with Keitaro. We have also observed a number of threat actors who continue to use IMKLO integrations with older versions of the tracker.
By combining Keitaro flows with filters, actors can show benign pages to bots or ad reviewers, cloaking the malicious pages reserved for the users targeted by the campaign. As part of the bot control aspect, Keitaro operators commonly leverage the standard and built-in antibot feature. More tech-savvy operators will supplement the Keitaro default bot IP block list with third-party data that is more complete. Affiliate networks have often shared variants via GitHub repositories or advertising affiliate network forums (see Figure 9).
Figure 9. Free antibot IPs available in GitHub and advertising forums
Keitaro also supports custom stream filters implemented as PHP files placed under its server directory, which allows operators to integrate third-party cloakers directly into flows. The HideClick cloaking kit markets PHP and JavaScript integrations and can be wired in through a custom filter or a vendor-generated PHP gate; the service advertises machine learning-based detection and blocking of bots, VPN and proxy traffic, and spy tools with real-time database updates. In practice, operators mix tracker rules, vendor cloakers, and shared bot lists to maximize the effectiveness of their campaigns. HideClick even features a February 2021 video on their YouTube channel (Figure 10) teaching their customers how to integrate with Keitaro in just a few clicks.
Figure 10. Screenshot of HideClick cloaking kit video on Keitaro integration
Other cloaking kits offer variations of the same features, including the more premium Adspect Cloaker, which boasts AI-enabled traffic filtering capabilities and the ability to circumvent detections by major platforms like Google, TikTok, Meta, and various security vendors. Adspect documents a custom filter that, once installed, adds a stream ID field in the Keitaro filter UI (Figure 11); Adspect then makes the allow or deny decision while Keitaro handles the final routing. Figure 12 shows Adspect’s documentation for Keitaro integration.
Figure 11. Adspect stream ID Keitaro integration
Figure 12. Adspect Cloaker documentation for Keitaro integration
Client-Side JavaScript Execution
Threat actors can also abuse Keitaro to direct users to different sites without the tell-tale sign of a redirect. KClient JS is Keitaro’s JavaScript-based campaign integration method. Using this approach, the operator inserts a Keitaro-generated script into the head of a site that is hosted outside the Keitaro server. When the page loads, the script contacts the Keitaro campaign and, if the configured flow calls for substitution, replaces the page content without a visible redirect. The visitor remains on the same domain, while the DOM reflects whatever the flow returns.
Public reporting most often shows threat actors use Keitaro as a traffic distribution gate that fingerprints visitors and redirects them to attacker-controlled fake update pages or other payload deliveries (e.g., SocGholish, or ISO loaders), rather than relying on KClient JS. Still, a threat actor who already controls a WordPress site could pair KClient JS with flow decisions to turn that page into a client-side delivery surface at the same URL, which can make a content swap less obvious to simple redirect detection. In practice, many sites either lack a content security policy (CSP) or deploy permissive policies (e.g., allow unsafe-inline), meaning inline scripts delivered through such a swap often do execute. HTTP Archive’s Web Almanac found that CSP appears on a minority of sites, and among pages with script-src, unsafe-inline shows up in ~94% of cases.
Keitaro Cookies
The widespread abuse of Keitaro as a TDS by malicious actors makes any HTTP-level artifacts particularly valuable for tracking and correlating malicious activity. One way the security community has tracked threat actors is via the cookies set by the server. Domains running Keitaro typically use a combination of tracking cookies such as _token, _subid, and a license-related cookie. Older versions of the tracker set a five‑character alphanumeric cookie (e.g., 3mt5l) while versions 11 and up use a more complicated structure. The value of these cookies, up to version 11 of the software, was a JWT token. The alphanumeric cookie used in early Keitaro versions was often reported as a signature for a specific threat actor. For example, in reporting on fake browser updates, the autoIT loader, and DarkGate spread of remote access trojans.
In August 2026, through collaboration with Randy McEoin, we realized that although these cookie values were often presumed to be unique, they were not. We saw overlaps between cookie values used by TA2726 and seemingly unrelated scam actors. In other words, there was a collision between the cookie names set by the infamous malware actor and an unknown affiliate advertising actor. The question became: is this collision random or is it due to shared licenses of some form?
The answer turned out to be elusive, but, working with Keitaro’s Trust and Safety team we were able to determine that there were some cases where two independent, active Keitaro licenses (version 9) set the same cookie value. In some ways, this is not surprising: at random, the same cookie would likely occur after about 10,000 instances. At the same time, it would still be quite rare. Indeed, it is. During the last nine months, we found about half a dozen instances of collision. However, many of those included stolen licenses. We have validated one random collision with Keitaro.
It’s a bit nerdy, but our cookie quest was interesting enough to us that we figured we’d share the details with others.
Cookie Collisions
One way to identify a cookie collision is to analyze the domains that are setting these cookies. Keitaro’s licensing model allows a single license to be linked to only one IP address at any given time. The same cookie being set by domains resolving to multiple IPs, either in a single day or over a period of time, suggests a cookie collision. In some cases, these collisions have persisted over months or even years and have appeared across different cybercriminal ecosystems, ranging from malware distribution networks to malicious adtech operations.
TA2726
One of the most prominent examples of a cookie collision we observed involves threat actor TA2726. This actor, a traffic broker that distributes SocGholish and other malware, is widely known for its abuse of Keitaro as part of its TDS operations. Beginning in March 2025, we observed TA2726 domains (apiexplorerzone[.]com and rapiddevapi[.]com) setting a five-character cookie that had already appeared in a variety of unrelated malicious activity ranging from crypto scams and dark web entry points, to TDS domains routing users to adult content and fake dating sites. While the majority of these domains resolve to Cloudflare IPs, many also leverage dedicated malicious IPs from a variety of ASNs, including Aeza International. Table 1 below shows examples of the different types of activity setting this cookie using separate infrastructure on a single day in April 2025. Rows highlighted in green are confirmed TA2726 domains. tds11111[.]com, shown in the table as redirecting to a fake search page, frequently used this cookie as part of their campaigns. This domain belongs to a publishing affiliate that we observed directing traffic to domains associated with multiple affiliate marketing platforms, including Los Pollos and Propeller Ads.
| Domains Setting Cookie | Landing Page | IP Address | ASN |
|---|---|---|---|
| apiexplorerzone[.]com blessedwirrow[.]org rednosehorse[.]com digdonger[.]org | Blank | 185[.]184.123.58 | AS213877 u1host ltd |
| ryptosell[.]shop | Crypto scam page impersonating MAJOR crypto | 62[.]60.246.29 | AS210644 Aeza International LTD |
| subiz[.]tds11111[.]com | Fake search page indicating malicious file download | 104[.]21.9.36 172[.]67.141.109 | AS13335 Cloudflare, Inc. |
| tonamlchecks[.]com | Fake tool for analyzing TON blockchain transactions | 188[.]114.97.3 | AS13335 Cloudflare, Inc. |
| Table 1. Examples of the different types of activity and domains observed on a single day. Domains associated with TA2726 are in the highlighted row | |||
Screenshots in Figure 13 show the campaign landing pages mentioned in Table 1 above.
Figure 13. Landing pages triggered from different Keitaro instances. Image credit: urlscan.io
In September 2025, we reached out to Keitaro to verify whether the domains setting this cookie were linked to active licenses. We provided them with six SLDs and one hostname, each used in different campaigns and hosted on different IPs and name servers. These included a confirmed TA2726 domain, fetchapiutility[.]com, as well as the publishing affiliate domain tds11111[.]com. Keitaro confirmed that four of the seven domains using this cookie were running the outdated version 9 and were associated with cracked licenses: hmedshop[.]shop, juxysij[.]hkjhsuies.com[.]es, swim39[.]ru, and tds11111[.]com (linked to an outdated license key). For the other three domains we provided, they were unable to find a connection to any active Keitaro licenses, stating the domains, including the one controlled by TA2726, “showed no trace of Keitaro.” This exchange was one of several we had over a six-month period related to cookie collisions and stolen licenses.
Cracked Versions
Cracked or “nulled” Keitaro versions play a significant role in the abuse of the tracker across the cybercriminal ecosystem. These unauthorized builds are widely distributed on web forums, such as the Russian-language sites UCRACK and NullSEO, where users share nulled versions of Keitaro, installation guides, and troubleshooting advice for bypassing license validation. The nulled versions of the software come “pre-activated,” allowing threat actors to bypass the step of license validation normally required during the set-up process of legitimate versions. Most of these distributions are for versions 7.x through 9.x; forum discussions indicate cracked distributions for the most recent versions 10.x and 11.x are not widely available, with users frequently requesting these updated builds.
Keitaro itself has publicly acknowledged the existence and widespread use of these versions in a September 2024 article from TechTarget, indicating some threat actors using the product for malicious activity, such as Storm-0569, do so via the cracked versions. However, as noted in the article, it can be difficult to confirm whether or not certain malicious activity is directly tied to either a nulled or a legitimate version of the software without direct confirmation from the company.
Based on our extensive engagement with Keitaro, we believe that both TA2726 and TA576 are using cracked, or otherwise stolen, version 11 licenses.
Keitaro Trust and Safety
As we began this longitudinal study in late Summer, we contacted Keitaro and began a series of information exchanges. Because Keitaro is widely abused, we wanted to gauge their interest in and ability to fight malicious actors. Since our initial discussion, Keitaro transitioned from using Telegram-only abuse reporting to an email-based reporting system at report-abuse@keitaro.io. Their Trust and Safety guidelines were updated in September 2025 to reflect their commitment to respond to abuse of the product.
During the past several months, we reported over a hundred Keitaro instance domain names to them, and they canceled over a dozen accounts. We monitored the activity of the threat actors whose accounts were canceled and saw only one of these actors return to Keitaro during the review time. In most of these cases, the domains were cloaked and used by investment scam actors.
We also discovered through these interactions that the most notorious malware actors, such as TA2726, appear to use stolen or cracked licenses. These included Keitaro version 11 licenses. We did not determine how these illegitimate instances were acquired, but in every case that a Keitaro instance was used by one of the malware actors, there existed a valid license connected to an instance using affiliate advertising platforms with the same cookie. The activity on the registered licenses seemed completely unrelated to malware distribution, and so it is unclear whether these are merely coincidences.
While many industry partners initially questioned this engagement, we found Keitaro to be very responsive—both in timeliness and action—to our reporting. We did not seek takedowns for all of the domains that we identified during this research, but for those we did, Keitaro acted on every instance.
Indicators
The table below offers a curated selection of indicators related to the threats discussed. A more comprehensive list of indicators can be found in our GitHub repository.
Note: These domains may be associated with inactive or stolen licenses.
| Indicators | Description |
|---|---|
| tds11111[.]com | Publishing affiliate domain previously associated with Los Pollos and Propeller Ads |
| subiz[.]tds11111[.]com | Domain associated with fake search page indicating malicious file download |
| scyphoserippleepidosite[.]com | Landing page domain routed from subiz[.]tds11111[.]com |
| apiexplorerzone[.]com blessedwirrow[.]org rednosehorse[.]com digdonger[.]org fetchapiutility[.]com rapiddevapi[.]com | Confirmed TA2726 domains |
| 185[.]184.123.58 | Dedicated TA2726 IP address (inactive) |
| ryptosell[.]shop | Domain hosting crypto scam page impersonating MAJOR crypto |
| 62[.]60.246.29 | IP address previously hosting crypto scams |
| tonamlchecks[.]com | Domain associated with scam page |
| hmedshop[.]shop juxysij[.]hkjhsuies[.]com[.]es swim39[.]ru |
Domains running the outdated Keitaro version 9 and associated with cracked licenses |
| sunpetalra[.]com | Domain used in fake Russian government dividend income scam |
