A few days ago, one of our readers contacted reported an incident affecting his website based on Wordpress. He performed quick checks by himself and found some pieces of evidence:
- The main index.php file was modified and some very obfuscated PHP code was added on top of it.
- A suspicious PHP file was dropped in every sub-directories of the website.
- The wp-config.php was altered and database settings changed to point to a malicious MySQL server.
The strange PHP file (called “thnxx.php”) discovered in multiple directories was easy to spot. It is a web shell (SHA256:4eb36a7229f7a799ac321b989e12b4007df8d86057752cb182f409f32c4b4fec) with a nice score on VT: 2/58[1]. This web shell is in the wild for some time and used by many Indonesian hacker groups. There are plenty of Google hits[2][3].
![]()
The PHP code added to the index.php is pretty well obfuscated and performs the following tasks.
First, it modifies the .htaccess file and adds the following lines:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .*.html?$ index.php [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
</IfModule>
What do they mean? Basically, if a visitor tries to access *any* page or directory that does not exist, it will be redirected to the index.php page.
Then, the site_map.xml file is generated with plenty of random URLs:
<?xml version="1.0" encoding="UTF-8"?><urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url><loc>http://www.xxxxxx.com/cDZEMTE4NU82dTc1ODQ1RHZ5Mzlo</loc><lastmod>2018-06-07</lastmod><changefreq>weekly</changefreq></url>
<url><loc>http://www.xxxxxx.com/6vv1185Yvv75846by39h0</loc><lastmod>2018-06-07</lastmod><changefreq>weekly</changefreq></url>
<url><loc>http://www.xxxxxx.com/dnl2MTE4NVl5djc1ODQ3YjM5aDAw</loc><lastmod>2018-06-07</lastmod><changefreq>weekly</changefreq></url>
<url><loc>http://www.xxxxxx.com/y3u1185qN75848C</loc><lastmod>2018-06-07</lastmod><changefreq>weekly</changefreq></url>
<url><loc>http://www.xxxxxx.com/Mzl1MTE4NXFONzU4NDlD</loc><lastmod>2018-06-07</lastmod><changefreq>weekly</changefreq></url>
<url><loc>http://www.xxxxxx.com/9h0p1185xh0b75850O</loc><lastmod>2018-06-07</lastmod><changefreq>weekly</changefreq></url>
Introduced by Google, the Sitemaps protocol to help web developers to publish lists of links across their sites. The Sitemap files contain URLs to these pages so that web crawlers can find them. Bing, Google, Yahoo and Ask now jointly support the Sitemaps protocol[4].
Combined with the .htaccess described above, this will redirect all the traffic to the index.php page. If the traffic is coming from a crawler or the referer is a search engine, a spam page is displayed:
if (isset($_SERVER['HTTP_USER_AGENT']) && preg_match('/(googlebot|yahoo|slurp|baiduspider|bingbot|google|baidu|aol|bing)/si', $_SERVER['HTTP_USER_AGENT'])) { }
if (isset($_SERVER['HTTP_REFERER']) && preg_match('/(google.co.jp|yahoo.co.jp|bing.com)/si', $_SERVER['HTTP_REFERER'])) { }
Note that Japanese versions of the crawlers or search engine are targeted. Here is an example of the page displayed to the visitor:
![]()
What about the altered wp-config.php? It’s the first time that I see this behaviour. The database configuration in wp-config.php has been changed:
define('DB_NAME', 'leticiaale’);
define('DB_USER', 'leticiaale’);
define('DB_PASSWORD', ‘xxxxxxxxxxx’);
define('DB_HOST', ‘dbmy0052.xxxxxxxxx’);
$table_prefix = 'wp_torsia4';
The MySQL host has a PHPMyAdmin interface available. Let's use the credentials from the wp-config.php:
![]()
The next step was to investigate the "new" database used. I was able to dump a copy of the ‘leticiaale’ database (it took a few hours due to the bad connectivity with the host):
$ mysqldump -u leticiaale -p -h xxxxxxxx leticiaale >dump.sql
The security of the database is very weak. Personally I would restrict access to the database to the compromized servers only. I said "serverS" because the database dump contained multiple Wordpress databases with different table prefixes. I extracted all Wordpress home URLs from the dump file:
$ grep siteurl dump.sql |awk -F ',' '{ print $3 }'|tr -d "'" >urls.tmp
$ wc -l urls.tmp
519 urls.tmp
519 compromized websites! Some of them were already cleaned, others are still running the malicious databases. Let's inspect one of the malicious database. The Wordpress settings are almost the default ones, with the default Wordpress post and one admin user:
LOCK TABLES `wp_torsia4users` WRITE;
/*!40000 ALTER TABLE `wp_torsia4users` DISABLE KEYS */;
INSERT INTO `anacapit29users` VALUES (1,'hamconage','$P$BbTujEbiRE2HQeLcmiXXXXXXXXXXXX.','hamconage','hamconage@hotmail.com','','2018-06-10 13:02:33','',0,'hamconage');
/*!40000 ALTER TABLE `wp_torsia4users` ENABLE KEYS */;
UNLOCK TABLES;
It seems also that a specific plugin is installed. Let's import the database in a sandbox running a Wordpress. The default page looks normal:
![]()
Let's change the 'hamconage' hash password in the database and connect to the Wordpress admin dashboard, you can see the malicious plugin "UBH" or "United Bangladeshi Hackers":
![]()
![]()
![]()
The next question is: how did the attacker compromise the Wordpress instance (fully patched, according to our reader)? He was able to get Apache logs from his hosting company and provided them to us. Let’s build a timeline of the accesses. It was easy to spot multiple POST requests to xmlrpc.php around the 7th of June. If the server was fully patched, the xmlrcp.php might have been brute forced but I did not see a lot of attempts. Or the password was very weak? A good recommendation is to enable logging of POST data or to enable full packet capture to be sure to investigate the complete HTTP flows. I found reference to the same hack already in March 2018 with a peak end of May 2018.
If you have more information about this attack, feel free to share!
[1] https://www.virustotal.com/#/file/4eb36a7229f7a799ac321b989e12b4007df8d86057752cb182f409f32c4b4fec/detection
[2] https://www.google.com/search?q=intitle:"JINGKLONG+BAJINGAN”
[3] https://www.google.com/search?q=Psycho00.dat
[4] https://en.wikipedia.org/wiki/Site_map
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
