Threat Level: green Handler on Duty: Manuel Humberto Santander Pelaez

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2018-06-13 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

A Bunch of Compromized Wordpress Sites

Published: 2018-06-13
Last Updated: 2018-06-14 05:17:57 UTC
by Xavier Mertens (Version: 1)
4 comment(s)

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

4 comment(s)

From Microtik with Love

Published: 2018-06-13
Last Updated: 2018-06-13 11:55:01 UTC
by Remco Verhoef (Version: 1)
1 comment(s)

We've found interesting new traffic within our Honeytrap agents, originating from servers within Russia only (to be specific, the netblock owned by NKS / NCNET Broadband). The username and password combination being used is root / root, and they are executing all of the following ssh commands:

/ip cloud print
help
ifconfig
uname -a
show ip
cat /proc/cpuinfo
uptime
ls -la
ls /data/data/com.android.providers.telephony/databases
echo Hi | cat -n
ps | grep '[Mm]iner'
ps -ef | grep '[Mm]iner'

While searching for the "/ip cloud print" command,  I've found this command to be related to Microtik routers. Since RouterOS v6.27 the command has been changed, so the targetted devices are Microtik routers running RouterOS before v6.27. The username and password pair being used to gain access isn't a specific Microtik default username / password combination.

Because not all of the above commands are programmed to return the output expected by the script, it could be just probing for specifics about the attacked server.

One command we are not seeing very often is the check for Android databases, "ls /data/data/com.android.providers.telephony/databases". This is a bit weird, especially because of the combination RouterOS / Android, but it could be that the script is just trying to identify the os the device is running.

Another interesting command is the "echo Hi | cat -n" which just counts the number of output lines the echo command, which could be all fingerprinting. There is also a check for running miner processes, but we have seen more thorough checks in for example the Redis worm.

All ip addresses are located roughly at the same netblock / location, which could be an indication that this worm / script is explicitly targetting a vulnerability in the routers being used by the provider, while scanning a broader area not limited to their netblock(s).

Complete list of source addresses:

178.140.147.32
178.140.219.221
178.140.34.125
188.255.18.44
188.255.81.2
188.32.136.109
188.32.213.175
37.110.106.231
37.110.40.221
37.110.82.81
37.110.84.127
37.204.101.93
37.204.104.247
37.204.164.191
37.204.225.46
37.204.253.200
37.204.5.142
46.242.37.169
46.242.4.236
46.242.63.75
5.228.185.9
5.228.214.22
5.228.246.91
77.37.145.89
77.37.149.50
77.37.230.37
77.37.236.152
77.37.237.82
77.37.247.102
90.154.76.78
95.84.212.217

Let me know if you have additional information about this case.

Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec
PGP Key

Keywords: microtik worm
1 comment(s)
Diary Archives