web analytics

Looking into Attacks and Techniques Used Against WordPress Sites

By David Fiser (Senior Cyber Threat Researcher)

WordPress is a well-known open-source content management system (CMS) used for creating websites and personal blogs. The CMS is estimated to be used by 35% of all websites today, which makes it an ideal target for threat actors. A weak point in the platform is all it takes to allow an attacker to break a website’s security — a risk compounded by security issues brought about by poor cybersecurity hygiene.

Attacks against CMS platforms are not news, but threat actors still find that attacking sites is an effective way to gain a foothold on organizations’ assets to use for malicious purposes. This blog post lists different kinds of attacks against WordPress, by way of payload examples we observed in the wild, and how attacks have used hacked admin access and API, Alfa-Shell deployment, and SEO poisoning to take advantage of vulnerable sites.

Attacking WordPress sites via hacked admin access

This method involves gaining administrator access to a WordPress-powered website. An attacker could exploit a vulnerability or simply log in via leaked or weak credentials, which can be done by sending a POST request to /wp-login.php on a targeted website.

Figure 1. A sample of an attempt to log in with weak credentials

Figure 1. A sample of an attempt to log in with weak credentials

Figure 2. Passwords tested by attackers

Figure 2. Passwords tested by attackers

After successfully logging in, an attacker with administrator access is presented with multiple options. We observed these actions:

  • Installation of a custom theme with a backdoor included
  • Installation of a plugin to upload files

The first two actions are mostly used after successfully gaining administrator privileges, optionally followed by changing the administrator password or creating a new administrator account. The common approach is to use a public theme and embedding custom backdoor(s) with remote code execution (RCE) functionality. There are also several file uploading plugins that allow an attacker to upload payloads directly.

It should be noted that a backdoor that deploys another backdoor with similar functionality is common. The deployment is done by using GET or POST requests when the payload/command/code is encoded inside COOKIES or POST data. The decoding logic is inside the previously deployed backdoor. After deployment, the attacker receives the URL of the newly uploaded component.

One of the interesting features that we also observed is the ability to patch an already existing .php file, allowing malicious requests to be more hidden. At first, all writable paths are recorded, a random suitable path is picked, and then the chosen file is patched.

Figure 3. Patched existing .php file function in served payload

Figure 3. Patched existing .php file function in served payload

In this case, the patch feature was applied to index.php to include a malicious script inside a Unix hidden file (dot file) with .ico extension pretending to be an icon.

Figure 4. A sample of a patched WordPress index.php including the hidden .ico

Figure 4. A sample of a patched WordPress index.php including the hidden .ico

Another notable feature is the ability to infect neighbor domains (provided that the web server is handling more domains and the current user has write access to their directories).

Figure 5. Attempting to upload payload into neighbor domains

Figure 5. Attempting to upload payload into neighbor domains

Deploying Alfa-Shell in infected WordPress sites

Web shells are known to be deployed on infected WordPress websites. We will be describing one of the advanced ones that uses Alfa-Shell by ALFA TEAM/solevisible.

 Figure 6. Alfa-ShellFigure 6. Alfa-Shell

Figure 7. Solevisible’s GitHub account

Figure 7. Solevisible’s GitHub account

The web shell provides a user-friendly interface for RCE (e.g., registering CGI handlers that allow execution of Perl, Python, and Bash scripts.) The Alfa-Shell is also capable of getting database credentials from the WordPress configuration file, dumping the database, and getting all virtual domains and DNS settings, to name a few.

Figure 8. CGI handlers for the execution of various script types

Figure 8. CGI handlers for the execution of various script types

Figure 9. A sample of deployed Bash script

Figure 9. A sample of deployed Bash script

The web shell also supports multiple platforms, including Windows. In fact, it is capable of downloading and executing a reverse shell from the developer website.

Figure 10. Alfa Team’s simple Windows reverse shell binary

Figure 10. Alfa Team’s simple Windows reverse shell binary

An infected WordPress can also serve as an advertisement redirector, for instance, by patching a theme’s JavaScript file or header/footer generator function (e.g., wp-contentthemestwentyseventeenfunctions.php). The modified JavaScript redirects users to a website specified by the attacker.

Figure 11. Obfuscated JavaScript redirection

Figure 11. Obfuscated JavaScript redirection

Figure 12. Webpage after redirection

Figure 12. Webpage after redirection

Search engine optimization (SEO) poisoning in infected WordPress sites

Another use case for infected WordPress sites is search engine optimization (SEO). We found deployed PHP scripts accepting keywords inside a GET request.

Figure 13. WordPress

Figure 13. WordPress “search engine”

The scripts first check for User-Agent if it matches with one of the following regular expressions, or if the Reverse DNS lookup for $_SERVER[“REMOTE_ADDR”] (IP address of actor making the HTTP request) contains a Google substring. If it checks out, it then sets the $isbot variable to 1.

Figure 14. Part of the deployed script

Figure 14. Part of the deployed script

If $isbot is not zero, then another HTTP request will be made to a hardcoded URL address, using the same keywords.

Figure 15. Part of the deployed script

Figure 15. Part of the deployed script

If the returned text length is below 1,000 characters, other queries will be performed using the Bing search engine, with the results that match the specified regular expression appended to the $text.

Figure 16. Served text

Figure 16. Served text

The final HTML page is returned and saved on the server in case the same query is performed again.

Figure 17. Final webpage

Figure 17. Final webpage

As we can see from the crafted HTML file (see Figure 17), there are parts from Cockeysville Eagle’s Football webpage that contain text pertaining to the JavaScript frameworks that obviously do not relate, thus the SEO Poisoning.

In case the $isbot is not set and HTTP_REFERER contains strings like Google, Bing, or Yahoo, it is then redirected to another serving website.

Figure 18. Part of the deployed script

Figure 18. Part of the deployed script

Spreading false or misleading articles

A hacked WordPress site may also be used to spread false or misleading articles, where the content presents little or no factual details. Instead, attention-grabbing headlines and stories are used.

Figure 19. Samples of stories posted on compromised sites

Figure 19. Samples of stories posted on compromised sites

As seen in the above examples, compromised sites post stories that have glaring grammatical errors or sensationalized reporting. Often, the articles are written unintelligibly. The compromise is done through WordPress’s XML-RPC application programming interface (API), which enables data to be transmitted and performs several tasks such as uploading a new file, editing and publishing a post.

Figure 20. POST /xmlrpc.php and metaWeblog.newPost (left); sample of posted text (right)

Figure 20. POST /xmlrpc.php and metaWeblog.newPost (left); sample of posted text (right)

A hacker can use POST /xmlrpc.php and metaWeblog.newPost, which allows for posting blogs directly (and even remotely) to a WordPress site.

Security recommendations for WordPress sites

The abovementioned examples are only some of the techniques that attackers have been known to use. Vulnerable WordPress websites can be easily abused if not secured properly. To reduce the risk of compromise, we recommend using two-factor authentication (2FA) plugins to secure against credential abuse and scanning for unpatched vulnerabilities. Here are other measures users and site admins can take:

  • Adopt basic security hygiene to reduce the website’s attack surface
  • Disable or delete outdated or vulnerable plugins
  • Employ virtual patching to address vulnerabilities for which patches are not available yet, especially for systems that need to be constantly up and running
  • Enforce the principle of least privilege
  • Regularly update the CMS to the latest version, including plugins

The post Looking into Attacks and Techniques Used Against WordPress Sites appeared first on .