Between 2018-11-10T03:34:07.003-0700 and 2018-11-10T03:34:27.187-0700, my WordPress honey pot got 12 eerily similar HTTP requests.
This is my attempt to figure out if all these requests are somehow coordinated.
May be an extension or repeat of a similar campaign.
It looks like all these requests came from a global variety of Co-location or web site hosting places.
Timestamp | IP Address | DNS name or AS |
---|---|---|
2018-11-10T03:34:07.003-0700 | 198.57.247.159 | gemmajewels.com |
2018-11-10T03:34:09.053-0700 | 47.91.246.242 | AS45102, Alibaba |
2018-11-10T03:34:10.894-0700 | 69.89.31.63 | box263.bluehost.com |
2018-11-10T03:34:11.584-0700 | 160.153.154.25 | n3nlwpweb054.prod.ams3.secureserver.net |
2018-11-10T03:34:13.078-0700 | 50.87.144.83 | gator3064.hostgator.com |
2018-11-10T03:34:15.506-0700 | 82.223.18.202 | AS8560, arsys.es |
2018-11-10T03:34:18.003-0700 | 201.49.197.2 | prudenet.prudenet.com.br |
2018-11-10T03:34:19.296-0700 | 162.223.89.194 | host.coloup.com |
2018-11-10T03:34:22.290-0700 | 114.119.5.11 | AS17816, China Unicom CHINA169 Guangdong Province |
2018-11-10T03:34:24.279-0700 | 103.43.46.26 | AS58397, PT Infinys System Indonesia |
2018-11-10T03:34:26.226-0700 | 192.185.83.204 | storm.websitewelcome.com |
2018-11-10T03:34:27.187-0700 | 160.153.153.30 | n3nlwpweb036.prod.ams3.secureserver.net |
All attacks came from Linux machines.
Timestamp | IP Address | p0f3 OS guess | nmap 7.70 OS guess |
---|---|---|---|
2018-11-10T03:34:07.003-0700 | 198.57.247.159 | Linux 3.11 and newer | MikroTik RouterOS 5.25 (Linux 2.6.35) |
2018-11-10T03:34:09.053-0700 | 47.91.246.242 | Linux 3.11 and newer | Linux 3.10 - 4.11 |
2018-11-10T03:34:10.894-0700 | 69.89.31.63 | Linux 3.11 and newer | Linux 3.10 - 4.11 |
2018-11-10T03:34:11.584-0700 | 160.153.154.25 | ??? | Linux 3.11 (95%), Linux 2.6.32 - 3.13 (95%) |
2018-11-10T03:34:13.078-0700 | 50.87.144.83 | Linux 3.11 and newer | MikroTik RouterOS 5.X, Linux 2.6.X |
2018-11-10T03:34:15.506-0700 | 82.223.18.202 | Linux 3.11 and newer | Linux 3.10 - 4.11, Linux 3.2 - 4.9 |
2018-11-10T03:34:18.003-0700 | 201.49.197.2 | Linux 3.x | Linux 3.10 - 4.11 |
2018-11-10T03:34:19.296-0700 | 162.223.89.194 | Linux 3.11 and newer | Linux 3.2 - 4.9 |
2018-11-10T03:34:22.290-0700 | 114.119.5.11 | Linux 3.11 and newer | Linux 3.10 |
2018-11-10T03:34:24.279-0700 | 103.43.46.26 | Linux 3.11 and newer | Linux 3.10 - 4.11, Linux 3.2 - 4.9 |
2018-11-10T03:34:26.226-0700 | 192.185.83.204 | Linux 3.11 and newer | Linux 4.4 |
2018-11-10T03:34:27.187-0700 | 160.153.153.30 | Linux 3.11 and newer | Linux 3.11 (95%), Linux 2.6.32 - 3.13 (95%) |
About 5 of the IP addresses involved in this campaign have access my web site in the past.
IP Address | Previous Accesses | Earliest | Latest |
---|---|---|---|
198.57.247.159 | 3 | 2018-03-06 13:20:50-07 | 2018-03-19 00:26:09-06 |
69.89.31.63 | 1 | 2015-12-28 10:41:05-07 | 2015-12-28 10:41:05-07 |
50.87.144.83 | 1 | 2014-07-23 06:06:44-06 | 2014-07-23 06:06:44-06 |
160.153.153.30 | 4 | 2017-06-02 05:15:47-06 | 2018-10-09 14:58:29-06 |
201.49.197.2 | 2 | 2018-09-24 15:53:54-06 | 2018-09-26 15:49:40-06 |
Date of Access | IP Address | URI |
---|---|---|
2014-07-23 06:06:44-06 | 50.87.144.83 | /blog/wp-admin/ |
2015-12-28 10:41:05-07 | 69.89.31.63 | /wp-content/uploads/wpallimport/uploads/a5354ae7c78ac1d0dd5d5926fc843260/info.php |
2017-06-02 05:15:47-06 | 160.153.153.30 | / |
2017-06-02 05:15:47-06 | 160.153.153.30 | /wp-json/wp/v2/users/ |
2018-03-06 13:20:50-07 | 198.57.247.159 | /test/wp-admin/ |
2018-03-17 18:53:20-06 | 198.57.247.159 | /wordpress/wp-admin/ |
2018-03-19 00:26:09-06 | 198.57.247.159 | /wp-admin/ |
2018-09-05 10:45:48-06 | 160.153.153.30 | /blog/wp-content/themes/twentytwelve/404.php |
2018-09-24 15:53:54-06 | 201.49.197.2 | //blog/wp-content/plugins/wp_bing/wp-ajax.php |
2018-09-26 15:49:40-06 | 201.49.197.2 | //blog/wp-content/plugins/wp_bing/wp-ajax.php |
2018-10-09 14:58:29-06 | 160.153.153.30 | /blog/wp-content/themes/twentytwelve/404.php |
Honestly, it looks like none of the earlier accesses were up to anything legit. I see cold access of WordPress admin pages, or PHP files in themes that are often compromised, or access of PHP files deep in plugin code.
All IP addresses tried to send PHP code to what they thought were instances of Web Shell by oRb, the WSO or "FilesMan" web shell.
All (fake) WSO accesses were direct: no cold access to get a login screen, then a 2nd access to send a password and receive a WSO "logged in" cookie. All accesses arrived with an appropriate WSO logged-in cookie, the HTTP parameter named "a" had the value "RC", and the HTTP parameter named "p1" had a value of the PHP dropper code. This is reasonably common WSO access.
User Agent strings specify Mac OS X, iOS, two Windows variants, and Android.
Only Android is possible for the versions of Linux that nmap
or p0f3
find would be Android,
but none the other user agent strings match OS at all.
The direct logins with pre-hashed cookies also imply
that the user agent strings are fakes.
The attacking IP addresses send a piece of unobfuscated, unencoded PHP that were intended to get eval'ed immediately by the attacked web site's PHP interpreter. This PHP code would ordinarily leave no trace on the attacked web site's filesystem, except for writing a file or injecting code in already existent files.
There are two PHP droppers present, a short one, and a long one. They share a great deal of code. Both droppers are similar to extensible backdoor droppers, Vigilante Malware Cleaner dropper, and Back door executing out of HTTP cookies dropper.
Timestamp | IP Address | dropper style |
---|---|---|
2018-11-10T03:34:07.003-0700 | 198.57.247.159 | long |
2018-11-10T03:34:09.053-0700 | 47.91.246.242 | short |
2018-11-10T03:34:10.894-0700 | 69.89.31.63 | long |
2018-11-10T03:34:11.584-0700 | 160.153.154.25 | long |
2018-11-10T03:34:13.078-0700 | 50.87.144.83 | short |
2018-11-10T03:34:15.506-0700 | 82.223.18.202 | long |
2018-11-10T03:34:18.003-0700 | 201.49.197.2 | short |
2018-11-10T03:34:19.296-0700 | 162.223.89.194 | long |
2018-11-10T03:34:22.290-0700 | 114.119.5.11 | short |
2018-11-10T03:34:24.279-0700 | 103.43.46.26 | long |
2018-11-10T03:34:26.226-0700 | 192.185.83.204 | short |
2018-11-10T03:34:27.187-0700 | 160.153.153.30 | long |
The "short" dropper paradoxically includes a longer PHP payload, tries to find all writeable files (regardless of file name), residing below Apache's DocumentRoot in the file system. For as many as 5 of those writeable files, it composes a string by concatentating "<?php ", 512 ASCII blanks, and the decoded payload. It edits that string into the writeable files at their beginning. It will skip the editing step if the file contains the PHP "eval" builtin. Presumably, it doesn't want to inject PHP code into a file that already has PHP code injected in it, but there may be another reason.
The "long" dropper finds all writeable directories
below Apache's DocumentRoot.
It shuffles the list of writeable directories,
then composes a file name consisting of
random string of 8, lower-case letters, and a ".php" suffix.
It tries to write the decoded payload into a
randomly selected writeable directory,
with the random, 8-character file name.
If this succeeds, it reports the URL in a machine-readable string
like URL#http://stratigery.com/wp/content/themes/twentytwelve/akduwjcj.php
so that the attacking IP address can find the file it just wrote out remotely.
It sets the freshly-written file's "mtime" to that
of .htaccess
, index.php
, index.html
or the directory in which WordPress resides.
Presumably this gives the code some concealment.
There are 2 distinct backdoors, a long form, and a short form, which arrive with the short dropper and the long dropper respectively.
Each of the 12 pieces of code is individually obscured. In an apparent multi-pass obfuscation method, all unique characters used in function and PHP built-in calls are composed into a single string.
Any function or PHP built-in name necessary for operation is composed at run time by concatenating individual characters from that single string. All function or built-in calls are indirect.
After that obfuscation got applied, it looks like individual variable names got changed throughout into 4-8 random lowercase character strings.
By changing all variable names in each backdoor to
v
, and all function names to f
, I eliminated
all the variable-name-randomization.
This reveals that only 2 backdoors exist.
All other differences are due to choice of variable names.
The short backdoor ends up eval'ing any code that's present in specially-encoded cookies or POST HTTP parameters. Since both cookies and HTTP parameters are name/value pairs, the backdoor uses the name as an XOR-encoding key, and the value as ASCII-hex-encoded bytes. It "packs" the value, which turns strings like '20' into and ASCII space, then XORs the packed bytes with a key string that's the name of the parameter with a GUID-like string ('180f814b-aff1-4584-af52-7071732d4319') appended. It breaks apart the string on '#' character boundaries, then evals the result of calling the first such substring as a function name, with the second substring as an argument. That is, the code sent in a POST parameter or cookie can carry one more level of obfuscation.
The long backdoor code is essentially v1.0-1 of the Extensible backdoor. That is, the second batch of 5 primitive backdoors. In fact, I have to wonder if this campaign isn't the same as the more primitive backdoor campaign.
I'll try to make the case for a common origin of all 12 attacks.
Having two droppers sharing a lot of source seems like a giveaway. Using the same obfuscation method on the backdoor code also seems to indicate a common origin.
Having two separate backdoors looks like the only problem with this theory. Why do two different pieces of code, and then put one in a file, while injecting the other into a bunch of files?
The attackers went to some lengths to disguise the attacking software, changing user agent string frequently. But some similarities show up in all 12 attacking accesses.
- Extra Cookie with same name and value: [227e948fdbaaeccbbb7b3f42fbe848e8] => 227e948fdbaaeccbbb7b3f42fbe848e8 Same name/value cookie shows up in Backdoor executing out of cookie download. This is the host name used in the URLs hashed via a peculiar algorithm, and it's an extra layer of password protection installed by the Vigilante Malware Cleaner.
- Same referer: http://stratigery.com/wp-content/plugins/wp-db-backup-made/system.php
- Same "path" part of URL:
/wp-content/plugins/wp-db-backup-made/system.php
- Accept Language HTTP header of "en-US,en;q=0.8"
- Client used HTTP/1.0
I don't think that any of these commonalities taken alone would indicate a common origin. Taken together, I think there's a strong probability all these accesses were centrally coordinated, by someone who is in contact with the Vigilance Committee that "fixes up" WSO instances.
I speculate that the extra cookie with the same name and value is possibly related to getting proxied to attacking my honey pot, or in a more paranoid vein, identifies the downloading software to knowledgeable observers.