However as I began to scan through the events, I noticed that the vast majority of them were mostly the same. Again, not so surprising. The surprising bits were that so many unique IP addresses were dumping the exact same payload. In the end, from Friday of last week to Friday of this week, I counted close to 1k events, and 315 unique IP addresses all pitching the same payload. The astute among you will notice that I entered information regarding this payload last Friday:
Pitcher: 199.115.228.177 Catcher: unknown NSlookup (pitcher): NX WHOIS (pitcher): 199.115.228.0/22 VOLUMEDRIVE US info@volumedrive.com AS46664 NSlookup (catcher): unknown WHOIS (catcher): unknown Payload: unknown Description: Base64 Encoding on the payload. Too large for IDS to capture entire payload Server: unknown Port: unknown Channel: unknown NSlookup: unknown WHOIS: unknown Notes: - A lot of Base 64. So much that the IDS has trouble capturing the whole thing. Here's what the header and the start of the RFI looks like: POST /cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%22%79%65%73%22+%2D%64+%63%67%69%2E%66%69%78%5F%70%61%74%68%69%6E%66%6F%3D%31+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1 Host: xx.xx.xx.xx User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0 Content-Type: application/x-www-form-urlencoded Content-Length: 54569 Connection: close <?php $bufferf = '<tons of base64 encoding here> - The URL encoding is the part of the RFI exploit, where the header/PHP below is the portion that executes a payload, or tells the attacked system where to call back to get the payload.. Any information on this?
The URL encoded portion in the post above is the standard preamble for a 2012 vulnerability that allows attackers to perform a remote file inclusion attack by just posting the PHP they wish to execute. This vulnerability is still VERY active and is responsible for 100% of the PHP RFI attack listings made available in the Overwatch project. Here's what it looks like when it's properly decoded:
-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env="yes" -d cgi.fix_pathinfo=1 -d auto_prepend_file=php://input -n
This sets the stage for the next portion, which is a standard HTTP POST request:
These are standard HTTP header options. The malware specifies a User-Agent, content-length (most of the time, greater than 54000 bytes), then immediately posts the PHP payload it wants the target webserver to execute. In our case, it's a php script that specifies the variable $bufferf and assigns a boatload of base64 encoded data to that variable.
Host: xx.xx.xx.xx User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0 Content-Type: application/x-www-form-urlencoded Content-Length: 54569 Connection: close <?php $bufferf = '<tons of base64 encoding here>
Unfortunately, my IDS is NOT a full packet capture device, and is unable to capture the entirety of the payload. However, I _AM_ capable of capturing part of the payload. The payload for the variable $bufferf spans across 12-13 frames before the IDS stops capturing packets, all the data it captures is the base64 encoded data for the $bufferf variable and it doesn't even capture all of that.
I gather up the base64 encoded strings, line them all up, organize them into a file with no line breaks, and submit to a base64 decoding tool online and I ended up with a 32-bit ELF binary that is statically linked. Attempting to run strings on the binary reveals that it is UPX packed.
For the new malware initiates in the audience, It's obnoxiously simple to determine if a binary is UPX packed or not. run the command "strings -a -n3 <binary name> | egrep "UPX|UPX\!" If you get any hits back, the binary is definitely packed with the UPX packer. Another hint: on some linux distros, the "file" command can detect that a binary is UPX packed on its own.
Naturally, seeing the UPX markers in the file, I run upx -d to unpack the target binary and am immediately answered with an error:
CantUnpackException: header corrupted2
Sigh. I pored through my IDS logs to see if any of the alerts/packets captured on the system would reveal a more complete capture of the payload, alas, no luck. although, combing through strings, the last 10 lines reveal some interesting details:
%s : USERIDThe "USERID" and "NOTICE" strings scream IRC bot to me, while the cgi-bR/php shows that this malware has the ability to spread through attempting to exploit the PHP vulnerability in other hosts. I'm not saying this is a variant of bossabot.... but it looks like a variant of bossabot.
NIX
NOTICE
UnknowninK}
able
Sply
/OI
U74u.
cgi-bR/php
+.B.f
To summarize, here is what I know:
-a new RFI payload is making the rounds
-over 300 unique attackers in a 7-day period
-nearly 1000 attacks in the same 7-day period (some attackers attempted to exploit way more than others)
-the payload contains large amounts of base64 encoding
-the payload content-length specified was consistently over 50000 bytes
-the payload header's user-agent doesn't vary at all in any of the alerts I pulled
-the base64 encoding that I could recover becomes a 32-bit linux ELF binary with the following parameters:
--Statically compiled
--UPX packed
--sha1sum of the partial file I recovered: d71e39c29a079de3196cf1fbfa51fa9c38172d86
If you're interested in a list of hosts I found spreading this, check out:
https://github.com/wearetheartillery/OverWatch/blob/master/BossaBot%20Tracker/bossabot.txt
I dumped the IP addresses under the bossabot tracker, since I think the two bots may possibly be related. If you know anything about unpacking partially recovered UPX files, I would love to hear from you. For now, he's a screen cap as proof.
Until next time.
