This post details the forensics performed by Information security trainingprofessional during the clean-up operation. The expert also note specific WordPress security recommendations based on analysis.
The client had recently registered new domain name, set up some webspace on their VPS and then manually started installing the most recent version of WordPress. Before completing the install by running the WordPress installation script, they then went away on holiday for a week presuming they could complete the install on their return. Ordinarily, the WordPress install would be completed by entering database credentials.
After the client returned from their holiday, they tried accessing their site to complete the install, but they received a browser warning.
Ignoring the warning and entering the site showed a black page with a “Rooted Syntax” logo.
A quick Google for “Rooted Syntax” led the Information security training expert to a hacker group’s Facebook page, which contained posts with details about sites they have defaced and hacked.
It was also clear from a Google search that other sites had been defaced in the same way.
The first task was to SSH into the server where the hacked site was hosted to look at the WordPress root. The professional noticed a few oddities that wouldn’t normally be part of a WordPress base install.
The following files and directories caught the eye:
As well as the non-standard files, he also noted the timestamps of the files, the original install had been done on March 20th, and it was clear that files had been added after that date.
To start the clean-up, the expert moved the document root to another location for further analysis and installed a new static HTML holding page for the site.
One of files that were modified since the original install was wp-config.php.
Upon viewing, it was immediately clear that the hacker had completed the WordPress install by entering their own MySQL credentials, which was hosted on a server used by the hacker.
Using those MySQL credentials, I was able to run SQL queries from my client’s host to help my investigation. I ran SHOW TABLES and it showed me 2,310 tables — considering each WordPress instance uses 12 tables by default, that makes approximately 192 hacked WordPress installation on this one MySQL server. The $table_prefix option in the MySQL wp-config.php had been use to give each install a unique prefix.
I was interested in seeing what files, if any, had been recently edited through the WordPress admin system. I ran the SQL select option_value from jhmxeoptions where option_name=’recently_edited’G to see what files had been recently edited by an admin user.
The hackers had gained control of the site by entering their own database details, and subsequently altered the homepage of the default Twenty Seventeen theme by dropping in this new index.php file via the admin system.
Within the index.php was a large amount of obfuscated code. The hackers left in a comment to the tool used to generate the obfuscated code: FOPO. Unfortunately, the tool won’t un-obfuscate code without a cipher key.
The obfuscator works by running the initial PHP code through a series of stages involving PHP’s str_rot13, gzinflate and base64_decode functions. Eventually, this led the expert to the original source PHP file.
Examining the source code more closely revealed that many of the actions of the script are to download and install malicious scripts from remote locations, including the previously found wso.php. Additional scripts are downloaded by passing in the root GET parameter, for example index.php?root=domains.
There is also a generic file upload option available under root=home.
After gathering this information, Information security training professional has clear that the hackers could have accessed other parts of the web server. The analyst continued the investigation by looking for other malicious files across the filesystem, but found nothing.
Information security training researcher did reach out the [email protected] address for the network that owns the IP address used by the MySQL server so they can take further action.
The assumption for this particular case was that hackers are scanning for websites on newly registered domains, then trying to see if a WordPress setup has been completed. If they find such a scenario, they are then taking over the site by putting in their own MySQL details. Scanning for such sites is trivial, for example, Shodan allows you to search for websites exposing the wp-admin/setup-config.php installation script.