![\"Figure](\"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/compromised-routers-dns-and-a-tds-hidden-in-aeza-networks-figure1.jpg\")
<\/p>\n
Figure 1. An overview of the two-part TDS hosted in Aeza International<\/p>\n
This system appears to be operated by a financially motivated actor in the affiliate marketing space. Since mid-2022, they have directed user traffic to adtech platforms through \u201csmartlinks,\u201d a mechanism used in affiliate advertising to fingerprint a device and redirect the user to \u201cadvertising\u201d content. The links contain unregistered domains and require interaction with one of the shadow DNS servers to resolve. We use quotes here for advertising because often this content is malware or scams.<\/p>\n
While the actor\u2019s verified activity is affiliate marketing, they could have interfered in other ways with devices in the network. As a trusted source, they could alter DNS records for any domain and run adversary-in-the-middle (AiTM) operations, not just for websites, but for the domain names of critical applications and services.<\/p>\n
We cannot emphasize this enough: the DNS resolver is in a position of power.<\/p>\n
Shadow DNS Network<\/h3>\n
The threat actor compromises routers, particularly older models, and changes the DNS settings on them. Every device using that router will unwittingly use the shadow DNS network.<\/p>\n
One user described their experience in early 2025 in a Reddit post<\/strong><\/a> titled \u201cHELP im going insane\u201d [sic]. In a now-deleted response, another user describes their own experience, which hints that the exploitation goes beyond the router exploitation that we verified; see Figure 2. This threat is deceiving and will lead to the assumption that a problem exists in other services: online users complained that they could not access Google Sheets<\/strong><\/a> or that they were regularly redirected when using Google Chrome<\/strong><\/a>. These user reports indicate that the threat actor has manipulated DNS in some cases where we would expect the encrypted DNS-over-HTTPS (DoH) to be used and the router-set DNS server to be ignored. It\u2019s possible that in these cases, the user has turned off the secure DNS option or there is another underlying compromise on the device; we don\u2019t know.<\/p>\n Figure 2. A Reddit response to a user post about being unable to use their home network without interference; this response and the original question<\/strong><\/a> are now deleted but were online in November 2025. <\/p>\n There are dozens of recursive resolvers in the shadow Aeza network. Each compromised router is assigned a pair of them for DNS resolution. Answers to queries contain a time-to-live (TTL) of 20 seconds, forcing the devices to regularly connect to the Aeza resolver and ensuring that malicious redirects are difficult to replicate.<\/p>\n The threat actor modifies responses based on the domain name requested, the router\u2019s location, time between queries from the router, and randomization. Extremely popular domains such as Google or Facebook are, in our experience, usually answered truthfully. Others that are still popular or related to critical services may be modified. For example, we have seen altered responses for domains like shopify[.]com and okta[.]com. The resolvers will also answer queries for non-existent domains, which are often seen because of typos or as leaks from devices on a network for local domains.<\/p>\n Answers from the resolvers change based on several factors, and the correct IP address is frequently returned so that malicious redirects are limited and unpredictable. If any of the resolvers are queried \u201ctoo often\u201d in a short period of time, they will return 255.255.255.255 to the query. The reason for this response in lieu of the correct resolution is unclear to us.<\/p>\n The DNS portion of the TDS uses a surprising trick to hide from security testing: it only answers DNS queries with a specific format. For example, if you query one of the name servers, e.g., 89.208.105.113, for the IP address of shopify[.]com, under most conditions you will get an error:<\/p>\n ;; Warning: Message parser reports malformed message packet.<\/p>\n This stumped us for months. We knew that the queries were resolving for some devices but couldn\u2019t trigger a response ourselves. Persistent tinkering led to a solution! If we sent a query without the Extension Mechanisms for DNS (EDNS0) included, voila! The name server replied.<\/p>\n This restriction by the threat actor is surprising because EDNS0 was introduced over a decade ago and is part of a standard DNS implementation. As a protocol extension, EDNS0 can serve a variety of purposes, including increasing the accepted size of a response, supporting DNSSEC, and providing hints about the client device location. Because most DNS resolvers enable EDNS0, queries to the Aeza hosts will usually result in a malformed response.<\/p>\n Here is how to trigger a response from the command line:<\/p>\n dig +noedns @89.208.105.113 shopify.com<\/p>\n After building signatures, we found over three dozen resolvers for the system in early November 2025. Some of those IP addresses include: 104[.]238[.]29[.]136, 138[.]124[.]101[.]153, 193[.]233[.]232[.]229, 45[.]80[.]228[.]233, 89[.]208[.]103[.]145. <\/p>\n Thus far, we have only triggered a response by disabling EDNS0, but we suspect there is more to be learned. The number of routers that don\u2019t use EDNS0 is dwindling and would seem to limit their operation. Additionally, from one of our research partners, we know that the threat actor is broadly and regularly searching for new routers to attack. So, why keep this restriction? But\u2026.<\/p>\n Getting the DNS resolvers to respond is only the first piece of this puzzle\u2026. <\/p>\n When a user\u2019s browser connects to the altered IP address, e.g., 147.45.69.3, the device is fingerprinted and then directed to the next stage of the TDS if it passes the initial checks. This IP address serves as a proxy for the HTTP TDS, see Figure 3 for the host posture. Upon connection, a JavaScript file is returned that includes additional DNS queries which ensure that the connecting device is behind a compromised router. This is accomplished by including a URL with a domain name that should not resolve, e.g., gettranslate[.]ir. If the domain does not resolve, the script will redirect the user to www[.]google[.]com.<\/p>\n Figure 3. Host posture of TDS proxy (147.45.69.3) returned by the shadow DNS servers as of January 21, 2026 <\/p>\n The script we analyzed contained seemingly old code, including URLs hosted on domains that were apparently never registered. See Figure 4. The purposes of the various functions re(), red(), redbo(), etc., are unknown. If the device is unable to resolve gettranslate[.]ir and connect on port 18443, it will do a refresh and load Google\u2019s primary landing page. We have uncovered other versions of the scripts which use a different .ir domain.<\/p>\n Figure 4. Malicious script received in November 2025 through the Aeza TDS showing historical code using links on unregistered domains; the current function redbool() will attempt to connect to gettranslate[.]ir on port 18443.<\/p>\n If the first connection is successful, the device will be redirected again to another affiliate marketing platform link. From the URL<\/p>\n we were redirected to an adtech TDS that we track via<\/p>\n From there, our traffic was resold and eventually we were shown various advertisements. But with all these checks in place to ensure the traffic is coming from the compromised routers, our browser would frequently end up at the requested site or redirected to Google.<\/p>\n We have found instances where directly visiting the TDS IP address resulted in an immediate redirection to a smartlink. For example, in the past, connecting to 89.208.107.49:8081 redirected to a smartlink using jackpotshop[.]life hosted in AS6898.<\/p>\n For reasons that are unclear, portions of the script<\/strong><\/a> were injected into comments in online forums, as well.<\/p>\n In our research, the TDS always forced the browser into one of the two adtech platforms. But it is possible the threat actor is doing more with this system; the Reddit thread we uncovered indicated that bitcoin miners were installed and the admin was locked out. <\/p>\n While not overly sophisticated, the design of this TDS is clever and has a reasonable amount of infrastructure to maintain just to deliver unwanted advertising. And it\u2019s clearly worked\u2014this actor has operated undetected for years. <\/p>\n The Aeza shadow TDS we discovered harkens back to the days of DNSChanger malware<\/strong><\/a>, which was the work of an Estonian company. Distributed as software necessary to view videos on websites, the malware changed DNS configurations and served advertising content from the company. The FBI seized the C2 servers and indicted key figures in 2011.<\/p>\n Controlling DNS resolution is extremely powerful and goes well beyond the ability to deliver ads to a user. For example, a threat actor can selectively answer queries for critical services that are not protected by SSL certificates, or they can deny access to resources. The DNSChanger malware prevented antivirus updates on infected machines as a means of persistence.<\/p>\n More recently, ESET Research published findings<\/strong><\/a> on a Chinese actor who had tampered with DNS resolver settings and targeted software updates. The ability to determine when software is updated and to deliver modified updates can allow lateral movement within a network. Beyond these examples, DNS is used to discover services, check systems, establish trust, and connect to resources for every aspect of internet communication.<\/p>\n Overlay networks like this one can also impact DNS research because the false records get absorbed into some databases. There are many commercial sources for passive DNS available and some of these rely on \u201cport 53\u201d collection. In these cases, responses from authoritative name servers within the global DNS are mixed with the responses from alternate resolvers like the ones we\u2019ve described here. If researchers aren\u2019t aware of the type of DNS data they are using, they can draw false conclusions. <\/p>\n In our case, a third-party \u201cport 53\u201d collection helped us recognize this overlay network. There were Kimwolf botnet<\/strong><\/a> domains in that database, which resolved incorrectly to 89[.]208[.]107[.]49, an IP address we had already been monitoring for a few years. Independently, we had been \u201cnoodling\u201d over mysterious DNS resolutions for domains like gettranslate[.]ir. Suddenly, we were able to put these two puzzles together and once we had the EDNS0 trick, the mystery quickly unraveled. How fun is that? <\/p>\nThis happened to me - I use OpenMTCPRouter (virtual router instead of a physical one, based on OpenWrT), with a public (virtual private server) VPS for aggregating network connections, I had misconfigured network rules, which exposed my \"router\" virtual machine to the internet, which was exposed publicly via my public VPS, which when compromised, had several things done: \r\n- did DNS redirection to https:\/\/gettranslate[.]ir:18443 and profitablecpmrate.com. \r\n- Locked out the root\/admin user \r\n- Loaded a crypto miner <\/pre>\n
The HTTP TDS<\/h3>\n
![\"Figure](\"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/compromised-routers-dns-and-a-tds-hidden-in-aeza-networks-figure3.jpg\")
<\/p>\n![\"Figure](\"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/compromised-routers-dns-and-a-tds-hidden-in-aeza-networks-figure4.jpg\")
<\/p>\n\n
\n
Impacts<\/h3>\n