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.

Targets

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:

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:

Here’s a deobfuscated version of that PHP backdoor:

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):

hjt689ig9
trackstatisticsss

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:

185.189.13.165
198.154.112.83
89.179.243.3
132.148.91.196
104.236.133.77
188.166.176.210
77.238.122.196
74.94.234.151
188.166.176.184
68.183.50.252

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.

Conclusion

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.