In our last article, How WordPress Gets Hacked in 2022 – Initial Reconnaissance, we analyzed the behaviors (TTPs) of bad actors trying to hack a vanilla WordPress deployment. Confirming our suspicions, attacks targeting access controls continues to be the #1 preferred vector by bad actors.
Analysis showed that attackers were especially interested in abusing WP-JSON and XMLRPC. WP-JSON to identify the potential users on the site, and XMLRPC to brute force the application log in mechanism.
From there, we wanted to better understand the rest of the kill chain process. What will the bad actors do next?
Unlike our first article, we didn’t have a strong opinion. It would be highly dependent on the group that successfully takes control of the site.
This article will share what we are learning as we actively monitor our honeypot.
**Updated: 2022-08-24: Include a more direct list of all articles related to this research:
- Part 1: How WordPress Gets Hacked in 2022 – Initial Reconnaissance
- Part 2: What Hackers Do with WordPress in 2022 – Post Hack Analysis
- Part 3: Analyzing 17,000 Spam Links on a Hacked WordPress Site
- Part 4: Hijacking a Websites SERP Results with SEO SPAM
- Part 5: Navigating 81 Layers of Encoding to Reveal the C&C
Taking Control
In the interest of time, after waiting two weeks, we changed the password to an easier variation to speed up the process. Over 98% of the attacks against the site were hitting XMLRPC and wp-login and we were getting impatient. This doesn’t change our opinion around what bad actors find successful.
This article will pick up from the time that the bad actor successfully logged in.
It begins here:
36.70.226.251 - - [21/Aug/2022:15:32:46 +0000] "GET //wp-login.php HTTP/1.1" 200 6992 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"Analyzing the POST request we see what they used as the password:
2022-08-21 15:32:53 - 36.70.226.251 {"log":"administrator","pwd":"admin","wp-submit":"Log In","redirect_to":"https:\/\/[honeypot domain]\/wp-admin\/","testcookie":"1"} /wp-login.php Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36If you’re curious, the above log is hijacking all POST requests via a custom script. It is not a normal log.
Shortly after logging in, they navigate to the plugins page:
36.70.226.251 - - [21/Aug/2022:15:33:04 +0000] "GET /wp-admin/plugin-install.php HTTP/1.1" 200 14231 "[honeypot domain]/wp-admin/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"
They then proceed to install the File Manager plugin
36.70.226.251 - - [21/Aug/2022:15:33:12 +0000] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 31240 "https://[honeypot domain]/wp-admin/plugin-install.php?s=filemanager&tab=search&type=term" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"The File Manager plugin allows you to edit, delete, upload, download, zip, copy and paste files and folders directly from the WordPress backend. It’s a powerful file management system that forgo’s the need for things like FTP or SFTP.
After installing, they activate the plugin here:
36.70.226.251 - - [21/Aug/2022:15:34:41 +0000] "GET /wp-admin/plugins.php?_wpnonce=2baae1448a&action=activate&plugin=wp-file-manager/file_folder_manager.php HTTP/1.1" 302 851 "https://[honeypot domain]/wp-admin/plugin-install.php?s=filemanager&tab=search&type=term" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"
36.70.226.251 - - [21/Aug/2022:15:34:41 +0000] "GET /wp-admin/plugins.php?activate=true&plugin_status=all&paged=1&s= HTTP/1.1" 200 11599 "https://[honeypot domain]/wp-admin/plugin-install.php?s=filemanager&tab=search&type=term" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"After some fiddling around, they proceed to use this plugin to upload three backdoors:
36.70.226.251 - - [21/Aug/2022:15:35:50 +0000] "GET /wp-admin/admin-ajax.php?action=mk_file_folder_manager&_wpnonce=efad7de300&networkhref=&cmd=ls&target=l1_d3AtY29udGVudA&intersect%5B%5D=qiqi.php&intersect%5B%5D=ar.php&reqid=182c10bbbdd300 HTTP/1.1" 200 870 "https://[honeypot domain]/wp-admin/admin.php?page=wp_file_manager" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"and
36.70.226.251 - - [21/Aug/2022:15:36:00 +0000] "GET /wp-admin/admin-ajax.php?action=mk_file_folder_manager&_wpnonce=efad7de300&networkhref=&cmd=ls&target=l1_d3AtY29udGVudA&intersect%5B%5D=klee.php&reqid=182c10be2771e8 HTTP/1.1" 200 870 "https://[honeypot domain]/wp-admin/admin.php?page=wp_file_manager" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"These two requests upload three backdoors:
- qiqi.php
- ar.php
- klee.php
They confirm access to the files via simple requests like this:
36.70.226.251 - - [21/Aug/2022:15:36:11 +0000] "GET /wp-content/qiqi.php HTTP/1.1" 404 21485 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"And they test it to make sure it is working:
36.70.226.251 - - [21/Aug/2022:15:36:15 +0000] "GET /wp-content/qiqi.php?path=/var/www HTTP/1.1" 404 13240 "https://[honeypot domain]/wp-content/qiqi.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"This is what they would see via their browser:
Side Note: Importance of Testing
Testing is actually very important for bad actors because things don’t always work. A great example of this can be found here when the attacker tried access ar.php:
[Sun Aug 21 15:36:15.560063 2022] [php:error] [pid 58786] [client 36.70.226.251:51039] PHP Fatal error: Uncaught Error: Call to undefined function create_function() in /var/www/[honeypot domain]/wp-content/ar.php:13\nStack trace:\n#0 {main}\n thrown in /var/www/[honeypot domain]/wp-content/ar.php on line 13The page was failing to render because of an undefined function create_function(), this function which was deprecated in PHP 7.2.0:
This function has been DEPRECATED as of PHP 7.2.0, and REMOVED as of PHP 8.0.0. Relying on this function is highly discouraged.
This server is running PHP 8.1.2:
# php -v PHP 8.1.2 (cli) (built: Jul 21 2022 12:10:37) (NTS)Just like that, the bad actor has taken control of your website. For the moment, they are isolated to the web directories. Let’s see what they do with the site itself.
Deploying a Payload
The big question we had after this was, what will they do once they get access?
We were thinking that it might be used for Denial of Service (DOS) attacks, as we have been seen a spike in this, but we were pleasantly surprised.
The bad actor took a bit of a break, then switched their virtual location:
216.24.210.135 - - [22/Aug/2022:03:07:19 +0000] "GET /wp-content/qiqi.php HTTP/1.1" 301 621 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"From here, they went to the themes folder:
143.244.46.229 - - [22/Aug/2022:04:44:54 +0000] "GET /wp-content/qiqi.php?path=/var/www/[honeypot domain]/wp-content/themes HTTP/1.1" 404 16446 "https://[honeypot domain]/wp-content/qiqi.php" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"Then to the active theme
143.244.46.229 - - [22/Aug/2022:04:45:38 +0000] "GET /wp-content/qiqi.php?path=/var/www/[honeypot domain]/wp-content/themes/twentytwentytwo HTTP/1.1" 404 26414 "https://[honeypot domain]/wp-content/qiqi.php?path=/var/www/[honeypot domain]/wp-content/themes" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"They then proceed to modify the functions.php
143.244.46.229 - - [22/Aug/2022:04:45:45 +0000] "GET /wp-content/qiqi.php?path=/var/www/[honeypot domain]/wp-content/themes/twentytwentytwo&aksi=edit&dirf=/var/www/[honeypot domain]/wp-content/themes/twentytwentytwo/functions.php&nama_file=functions.php HTTP/1.1" 404 28593 "https://[honeypot domain]/wp-content/qiqi.php?path=/var/www/[honeypot domain]/wp-content/themes/twentytwentytwo" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"Coincidently, we were monitoring POST requests in wp-content folder. So when they did this:
143.244.46.229 - - [22/Aug/2022:04:46:04 +0000] "POST /wp-content/qiqi.php?path=/var/www/[honeypot domain]/wp-content/themes/twentytwentytwo&aksi=edit&dirf=/var/www/[honeypot domain]/wp-content/themes/twentytwentytwo/functions.php&nama_file=functions.php HTTP/1.1" 404 1570296 "https://[honeypot domain]/wp-content/qiqi.php?path=/var/www/[honeypot domain]/wp-content/themes/twentytwentytwo&aksi=edit&dirf=/var/www/[honeypot domain]/wp-content/themes/twentytwentytwo/functions.php&nama_file=functions.php" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"We were able to see the payload come across.
To better understand what they did, let’s look at the functions.php file. When we open it, at the bottom, past the ?> close tag we find this:
What they have done is injected the site with SEO Spam. Those are all links to other domains that are siphoning traffic from your site, and will likely get your domain blacklisted.
They went so far as to hide it from the viewport (browser) to make it harder to detect for a user by wrapping it in this div
<div style="display:none;">If we open the site in the browser, we don’t see the payload, but if we view the page source, we see this:
They injected the site with over 17,000 links (more on this in another post)
Learning From a Post-Hack Experience
One of the reasons we do this research is so that we can learn as a community what bad actors are doing, and so that we can pressure test recommendations. What works? What doesn’t?
When we look at the scenario above, besides the obvious issue with a weak password, the things that comes to mind as being the most effective would have been to prevent the web user (i.e., www-data) from making changes on the server. We discus this more in our article – Securing WordPress in the Enterprise.
But if that is not an option, doing something like preventing plugins from being installed could have gone a long way to slow the attacker down. Something as simple as adding this to your wp-config.php:
define('DISALLOW_FILE_MODS',true);DISALLOW_FILE_MODS is a constant defined in wp-config.php, which disables plugin and theme updates and installation through the Dashboard. It also disables all file modifications within the Dashboard, thus removing the Theme Editor and Plugin Editor.
We hope you enjoyed, stay tuned as we follow the other bad actors hitting the server and what we learn as we analyze the payloads.