Why would malware issue a HTTP “POST /wp-config.php.back” request?
Once in a while I see malware attempt to issue HTTP POST requests to non-existent paths. Most often the malware is attempting to exploit a bug in a WordPress plugin that I don’t have installed. Sometimes the malware is clearly probing to see if software other than WordPress is running on my web server. For example, two months ago I saw a “POST /api/v1/config” request. But today I saw a truly bizarre attack.
A server at 81.177.32.187 in Russia, domain in-solve.ru, issued the following HTTP requests against my server today:
POST /wp-config.php.bak POST /wp-config.php.swp POST /.wp-config.php.swp
Even if there were a backup of the wp-config.php file (“.bak”) or a temporary (“.swp”) version of that file present why does the malware author think they can issue a POST request to those paths? The POST data for all three requests was identical:
<?xml version="1.0" encoding="iso-8859-1"?>\n<methodCall>\n <methodName>wp.getUsersBlogs</methodName>\n <params>\n <param><value>alkoneron</value></param>\n <param><value>1234567890</value></param>\n </params>\n</methodCall>
So this attack is clearly meant to be issued against /xmlrpc.php in an attempt to guess WordPress account credentials (an attack signature I see every day). I can’t help but wonder if a malware author was testing new code and inadvertently targeted my server when they meant to test it against their own server. Because I find it hard to believe that someone has a WordPress installation that allows issuing xmlrpc commands against backups of the WP config file.
P.S., I’ve changed the password value to a generic “1234567890” because the original value actually looks like it might be the correct password for user alkoneron. The password in my logs is a random string of letters and numbers 13 characters in length. It is not the typical generic password I see from malware which is using a brute-force dictionary attack.