Nearly a Million WP Sites Targeted in Large-Scale Attacks

Nearly a Million WP Sites Targeted in Large-Scale Attacks

Our Threat Intelligence Team has been tracking a sudden uptick in attacks targeting Cross-Site Scripting(XSS) vulnerabilities that began on April 28, 2020 and increased over the next few days to approximately 30 times the normal volume we see in our attack data.

The majority of these attacks appear to be caused by a single threat actor, based on the payload they are attempting to inject – a malicious JavaScript that redirects visitors and takes advantage of an administrator’s session to insert a backdoor into the theme’s header.

After further investigation, we found that this threat actor was also attacking other vulnerabilities, primarily older vulnerabilities allowing them to change a site’s home URL to the same domain used in the XSS payload in order to redirect visitors to malvertising sites.

Due to the sheer volume and variety of attacks and sites that we’ve seen targeted, it is possible that your site may be exposed to these attacks, and the malicious actor will likely pivot to other vulnerabilities in the future. Indications of Compromise (IoCs) are listed below so you can monitor your sites.

While our records show that this threat actor may have sent out a smaller volume of attacks in the past, it’s only in the past few days that they’ve truly ramped up, to the point where more than 20 million attacks were attempted against more than half a million individual sites on May 3, 2020. Over the course of the past month in total, we’ve detected over 24,000 distinct IP addresses sending requests matching these attacks to over 900,000 sites.

All Wordfence users, including Wordfence Premium and free Wordfence users, are protected from XSS attacks via the Web Application Firewall’s built-in XSS protection. The Web Application Firewall also has a set of rules protecting against the attacks we’ve seen attempting to modify the home URL of a site. As these attacks appear to be targeted at vulnerabilities that have been patched for months or years, both Wordfence Premium and free Wordfence users should be protected.


Many of the targeted vulnerabilities have been attacked in previous campaigns. The most popular vulnerabilities targeted were:

  1. An XSS vulnerability in the Easy2Map plugin, which was removed from the WordPress plugin repository in August of 2019, and which we estimate is likely installed on less than 3,000 sites. This accounted for more than half of all of the attacks.
  2. An XSS vulnerability in Blog Designer which was patched in 2019. We estimate that no more than 1,000 vulnerable installations remain, though this vulnerability was the target of previous campaigns.
  3. An options update vulnerability in WP GDPR Compliance patched in late 2018 which would allow attackers to change the site’s home URL in addition to other options. Although this plugin has more than 100,000 installations, we estimate that no more than 5,000 vulnerable installations remain.
  4. An options update vulnerability in Total Donations which would allow attackers to change the site’s home URL. This plugin was removed permanently from the Envato Marketplace in early 2019, and we estimate that less than 1,000 total installations remain.
  5. An XSS vulnerability in the Newspaper theme which was patched in 2016. This vulnerability has also been targeted in the past.

Although it is not readily apparent why these vulnerabilities were targeted, this is a large scale campaign that could easily pivot to other targets.

Breaking Down the Attack Data

The majority of these attacks are attempting to insert a malicious JavaScript located at count[.]trackstatisticsss[.]com/stm (typically followed by what appears to be a version query string to prevent caching) into a site in the hopes that they’ll be executed by an administrator’s browser. In some cases these attempts include the plain URI of the malicious script, while in others they rely on String.fromCharCode to obfuscate the injected script location. Earlier iterations of these attacks appear to have used ws[.]stivenfernando[.]com/stm as the malicious payload.

Note: all screen shots contain deobfuscated/beautified versions of the scripts in question for readability.

The script checks to see if the victim has any WordPress login cookies set:

The malicious script's "check_adm" function.

If the victim is not logged in, and is not on the login page, it redirects them to a malvertising URL. If the victim is logged into the site, the script attempts to inject a malicious PHP backdoor into the current theme’s header file, in addition to another malicious JavaScript:

The malicious script's "make_theme" function.

Here’s a deobfuscated version of that PHP backdoor:

The PHP Backdoor added to the theme's header

The backdoor downloads yet another payload from https://stat[.]trackstatisticsss[.]com/n.txt, base64_decodes it, saves it to a temporary file htht, attempts to execute it by including it in the theme header, and then removes the temporary file. This method would allow the attacker to maintain control of the site, as they could simply change the contents of the file at https://stat[.]trackstatisticsss[.]com/n.txt to code of their choice which could be used to embed a webshell, create a malicious administrator, or even delete the entire contents of the site. While we have not included the current final payload for brevity, its functionality is to prepend a variant of the initial attack script to every JavaScript file and every .htm, .html, and .php file named “index” on the site, re-check every 6400 seconds to verify that the site is still infected, and reinfect the site if necessary.

Indicators of Compromise

The current final payload uses the following strings to determine whether or not the site’s files have already been infected, and as such they can be considered reliable Indicators of Compromise(IOCs):


The current final payload also writes timestamps denoting when the site was last checked for reinfection to a file named debugs.log (note the misspelling).

Additionally, this campaign appears to be associated with another domain, stivenfernando[.]com and as such any occurrences of this domain on your site or in your logs should be considered a potential Indicator of Compromise.

Unfortunately it is impractical to list all of the IP addresses performing these attacks, but the top 10 attackers by request volume are listed below:

What should I do?

The most important thing you can do in a situation like this is to keep your plugins up to date, and to deactivate and delete any plugins that have been removed from the WordPress plugin repository. The vast majority of these attacks are targeted at vulnerabilities that were patched months or years ago, and in plugins that don’t have a large number of users. While we did not see any attacks that would be effective against the latest versions of any currently available plugins, running a Web Application Firewall can also help protect your site against any vulnerabilities that might have not yet been patched. Most Cross-Site Scripting(XSS) attacks follow patterns that can be blocked regardless of the specific vulnerability being targeted.


In today’s post we covered a large-scale attack against nearly a million individual sites, including the functionality of the attack payload. All Wordfence users, including sites running the free version of Wordfence as well as Wordfence Premium, are protected against these attacks. Nonetheless, we urge site owners to ensure that all of their plugins are up to date and to deactivate and delete any plugins that have been removed from the WordPress plugin repository.

Credit to Wordfence Security Analyst Nate Smith and QA Lead Matt Rusnak who initially investigated the vulnerabilities being attacked in the earlier stages of this campaign.
This article was written by Ramuel Gall, a former Wordfence Senior Security Researcher.

Did you enjoy this post? Share it!


  • Should administrators also be advised to use a separate WordPress administrator account they use only for tasks that can only be done as an administrator and to not visit any other websites while they are logged in to WordPress as an administrator? Perhaps we should also open a new browser window that has a clean cache and no previous cookies?

    • Hi Duane. It does make sense to only grant rights for whatever a specific user needs to do their job. In security speak, we call that the principle of least privilege. And, it's always good to log out of a system if you're not in need of using it. Do we all do that? Not necessarily. But if you ARE logged into any system - whether your WordPress site or your bank - making sure you're not clicking links in emails, chats, or anything else would be prudent.

  • No security solution is perfect but the information and software you provide go a long way toward that goal and is very much appreciated.

  • I have a questions about hackers who are trying to access my website.
    They are using the xmlrpc.php methode. I do not know if I have the xmlrpc program on my website.
    My web is called
    Here below I found a website to give me the option to turn off that xmlrpc program.
    But what and who can I trust?
    Please advise what to do? As an 84 year person I have no idea what to do.
    Thank you

    • Hi Ronny,

      WordPress sites have xmlrpc enabled by default. Wordfence actually offers the ability to block xmlrpc requests in the Login Security module. If you have Wordfence installed, you can do this by logging into wp-admin, clicking on Wordfence->Login Security, then going to the "Settings" tab. From there you'll want to check the box that says "Disable XML-RPC authentication" and click "Save". After doing this xmlrpc requests should be blocked.

  • Thanks for this post. I am using wordfence in all my sites & subscribed the newsletter to stay up to date about WordPress

  • Thanks so much for this explanation, and all the work that you guys do to make the web a safer place!

  • The take away for me from what you have written, is to ensure that all my plugins are up to date. Thank you for all you do to defend those of us who are not technically savvy enough to fight off these attackers.

  • Thanks for the heads up and it is good thing I have wordfence installed.

    Always new threats good thing you guys are on the ball.

  • If you know that an attack is directing to a domain https://stat[.]trackstatisticsss[.]com, why anybody doesn't do something to catch the domain owner or get the domain down?

    • Usually these domains do not stay live for very long, though there are a group of "bulletproof" hosting providers that do not respond to abuse reports.

  • I have WP in 5.4.1 version, only popular and actual plugins and Wordfence in premium version.
    My website has been attacked for two weeks. Three times successfully. What should I do in this case?

    • Attacks on WordPress are common. Successful attacks are not. If you're seeing successful intrusion and you have all of your plugins, themes and core updated, there might be something else going on. We have some great resources in our learning center and our security services team is always available to help you analyze the intrusion vector for those successful attacks and make them stop for good.

  • Fantastic information that is ample reason why every Wordpress website should have Wordfence installed.

  • I use the Newspaper theme. It is becoming a very popular theme so I would expect that it will become more of a target going forward. I use Wordfence Premium on my WP sites.

  • The scale of information covered by your team is amazing. Thanks.

  • Thank you for this post. We are using Wordfence Premium on our four sites and we greatly appreciate the quick response from the Wordfence team when we needed assistance.

  • Hi Wordfence Thanks a lot to share those information with us. Do we have to add in our black list the ten IPs numbers listed? Thanks for your reply!

    • Hi Michele, Hackers typically move through IP addresses rather quickly as abuse reports end up alerting the owners of those IPs eventually. We provide the attack data to help anyone attempting to uncover the cause of an intrusion or attempted intrusion. Confirmation from our research may help them identify this in their forensic reporting.

  • How do I know when a plug-in is removed from the Wordpress repository?
    Thank you,

    • Hi John, Wordfence will alert you that a plugin is not in the repository anymore. Additionally, there will be a note on the plugin's detail page on that will identify when it was removed. The plugins team does not disclose why a plugin is removed. It could be a variety of reasons including a security issue (but not necessarily), so it's just something to watch carefully.

  • There is another one going one since yesterday 18:00 UTC

    • Hi Peter,

      Thanks for bringing this up! We actually started writing about this yesterday and published an article this morning: