Recently we have done cleanups of a number of hacked WordPress websites where part of what the hacker did after they have gained access to the website involved something we think would be useful to share with others in case they have even less information to go in trying to figure out how the website got hacked (attempting to determine how they were hacked is one of three basic steps in a proper hack cleanup).
In looking at the logging and other data, we have seen that the hackers were logging in to WordPress using existing WordPress accounts on the websites. From there they would install the plugin File Manager (WP File Manager). Here are the set of log entries where that occurred on one of the websites:
121.118.203.38 – – [15/Jan/2018:14:41:04 -0700] “GET /wp-login.php HTTP/1.1” 200 1693 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:07 -0700] “POST /wp-login.php HTTP/1.1” 302 1258 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:09 -0700] “GET /wp-admin/ HTTP/1.1” 200 22557 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:24 -0700] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 553 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:26 -0700] “GET /wp-admin/plugin-install.php?tab=plugin-information&plugin=wp-file-manager& HTTP/1.1” 200 9499 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:31 -0700] “GET /wp-admin/update.php?action=install-plugin&plugin=wp-file-manager&_wpnonce=c0ba6299b7 HTTP/1.1” 200 10849 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
121.118.203.38 – – [15/Jan/2018:14:41:37 -0700] “GET /wp-admin/plugins.php?action=activate&plugin=wp-file-manager%2Ffile_folder_manager.php&_wpnonce=67fdf3eee0 HTTP/1.1” 302 480 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”
As you can guess from the name that plugin is a file manager. The hackers then use the legitimate capabilities of that to modify existing files or add new files with malicious code. Here are the log entries from the same website where the same hacker looks to have logged in from another IP address and accessed the plugins functionality:
189.72.69.203 – – [15/Jan/2018:15:11:14 -0700] “GET /wp-login.php HTTP/1.0” 200 1731 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:18 -0700] “POST /wp-login.php HTTP/1.0” 302 1296 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:21 -0700] “GET /wp-admin/ HTTP/1.1” 200 22745 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:26 -0700] “GET /wp-admin/admin.php?page=wp_file_manager HTTP/1.1” 200 12922 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:31 -0700] “GET /wp-admin/admin-ajax.php?action=mk_file_folder_manager&_wpnonce=4028a67f1f&cmd=open&target=&init=1&tree=1 HTTP/1.1” 200 3150 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
189.72.69.203 – – [15/Jan/2018:15:11:35 -0700] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 2068 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”
The most important question in all this is how the hackers got access to the logins for the websites, since without access they couldn’t have installed the plugin or done anything else. Unfortunately the cause is something we haven’t been able to say for sure since the evidence we have is somewhat limited when it comes to determining that part of these hacks.
In at least some of the cases the website were using extremely weak passwords (on one website the password was “admin1234”), so it is possible that a previous dictionary attack had determined the password. A dictionary attack involves try to log in using common passwords. Those types of attacks are fairly common, unlike brute force attacks, which despite inaccurate claims frequently made by security companies, are, based on those companies own evidence, not happening. The logging available so far hasn’t shown that occurring though, but it could have occurred outside the time period that there was logging available (the longer websites store logging the easier it would be to trace the original source of hacks).
In some instances the password being used was also used as the password for other services as well, so it possible that it was compromised somewhere else and the hackers tried it on the websites.
That all leads to the first take away from this, which is to make sure to use strong passwords (something WordPress does a good of making sure you can do) and to use separate password for each login connected to a website.
The second is that if you are dealing with a hacked website where the plugin File Manager was recently installed and it wasn’t installed by someone involved with the website, a compromise of a WordPress account with the Administrator role should be considered a possible source of the hack and further investigated. In one of the websites the plugin was later removed by the hacker, so you if see logging showing it being used, but it isn’t currently installed, that could have occurred on the website you are dealing with as well.
The third is that is that trying limit hackers once they have high level access is not necessarily very useful. In the past we have seen it suggested disabling the plugin and theme editors, since hackers could use those to modify files with malicious code. But as what happened here shows, hackers can easily get around that possible limitation.
Hi .. thank you for the article.
I recently went through the same thing. The hacker was very competent and we have been battling to get him out for a few weeks. I found that he had stolen or was given a login password from a plugin vendor who was given “temporary” access to help fix a technical problem. Then they began installing their back doors.
I am also perplexed because he used the same IP every attack, but none of my firewalls (UFW and a WAF) had any affect blocking the IP — the IP never shows up in the firewall logs or the auth.log, on in the nginx logs. I wish i understood how that happened — spoofed IPs ?
When he logs in he does not use the wp-login.php ever again after the first time. After which 2FA is of no value. I found copies of adminer.php uploaded (after he uploads wp-filemanager) that when accessed provided phymysqladmin type access to the database — but i do not see how he got db password since it was fortunately behind the wp root directory which is not accessible via wp-filemanager. No the less it was changed.
So I was online monitoring users online taking note that I and another admin were the only admins — when suddenly my IP switches to his IP and from the logs and wp_activity report we see he immediately begins to add advertisements to our webpages. I cannot use the firewall to block him so we took control of the pages he was editing until he finally successfully forwarded the whole site to his affiliate advertising site. Which was returned to our control from the backend in the wp-config file using the define(‘WP_HOME’, ‘site’) and define(‘WP_SITEURL,’url’).
It was also required to add define( ‘DISALLOW_FILE_MODS’, true ) to prevent uploading plugins (turning it on as needed and then off) ..
After he suddenly becomes my IP he magically became my friend as his IP shows up as the other admin. This can only be done by some form of PHP session hijack as far I can tell. Come in access the database somehow gain access to the active admin sessions and boom you are in .. just show up at /wp-admin . Does anyone know how that was done ?
Finally removing all the malware and locking down all access points we could find, he is out for now …but his first night without entry filled up my server log with dozens of wordpress vulnerability searches .. including an attempt to use the fail2ban plugin available graphs — repeatedly . no idea what he was looking for there –but for the no logged it .. it produces a blank page.
Maybe this info can help another rid themselves of these parasites.
JM