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 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
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
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
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 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 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 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 “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
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
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
The final HTML page is returned and saved on the server in case the same query is performed again.
Figure 17. Final webpage
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
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
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)
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