1

I'm currently attempting to clean and secure a server that has pnscan running on it. This instance of pnscan was installed by an outside party most likely to use our server as part of a port scanning botnet. It seems to be able to write it's binaries to /dev/shm and /tmp.

Here's the output of "lsof | grep pnscan":

root@xxx.xxxx.xxx:/home/bitnami# lsof | grep pnscan
pnscan     9588     daemon  cwd       DIR    8,1      4096      647169 /tmp
pnscan     9588     daemon  rtd       DIR    8,1      4096      2      /
pnscan     9588     daemon  txt       REG    8,1      18468     647185 /tmp/pnscan
pnscan     9588     daemon  mem       REG    8,1      42572     418331 /lib/tls/i686/nosegneg/libnss_files-2.11.1.so
pnscan     9588     daemon  mem       REG    8,1    1421892     418349 /lib/tls/i686/nosegneg/libc-2.11.1.so
pnscan     9588     daemon  mem       REG    8,1      79676     418329 /lib/tls/i686/nosegneg/libnsl-2.11.1.so
pnscan     9588     daemon  mem       REG    8,1     117086     418343 /lib/tls/i686/nosegneg/libpthread-2.11.1.so
pnscan     9588     daemon  mem       REG    8,1     113964     402913 /lib/ld-2.11.1.so
pnscan     9588     daemon    0r      CHR    1,3        0t0     705    /dev/null
pnscan     9588     daemon    1w      CHR    1,3        0t0     705    /dev/null
pnscan     9588     daemon    2w     FIFO    0,8        0t0     37499  pipe
pnscan     9588     daemon    3r      REG    8,1        203     516243 /opt/bitnami/apache2/cgi-bin/php-cgi
pnscan     9588     daemon    4u      REG    0,15         0      37558 /dev/shm/.x
pnscan     9588     daemon    5u     IPv4    37559      0t0     TCP  domU-12-31-39-14-41-41.compute-1.internal:52617->lab1.producao.uff.br:www (ESTABLISHED)
pnscan     9588     daemon    6u     IPv4    3688467    0t0     TCP  domU-12-31-39-14-41-41.compute-1.internal:55926->200.25.69.27:www (SYN_SENT)

And here's the output of "ps aux | grep pnscan":

daemon    9588  2.3  0.1 3116204 3272 ?        Sl   21:42   1:55  /tmp/pnscan -rApache -wHEAD / HTTP/1.0\r\n\r\n 200.0.0.0/8 80

Any advice on how we can find the source of this would be greatly appreciated.

Thanks!

Zack Lerner
  • 11
  • 3
  • Please try to reformat your paste using the code button and not the quote button. It is unreadable as it is and it cannot be repaired in the state it's in now. – Michael Hampton Dec 16 '13 at 23:32
  • Thanks for the suggestion Michael. I'm a little new at this so my attempts to replace the output I had pasted haven't been so successful. As soon as I have a chance I'll look into the proper formatting techniques. – Zack Lerner Dec 17 '13 at 16:15

2 Answers2

5

Normally, a compromised server is

  1. backed up as an image for further investigation in a closed down lab
  2. reimaged or reinstalled/restored, to keep production going

Leaving a compromised machine, even if you seemingly clean it out, in production, isn't a safe practice

dyasny
  • 18,802
  • 6
  • 49
  • 64
  • Thanks for the reply. We've actually attempted moving the site to a few fresh servers with little luck. Unfortunately, the site is on an older version of ExpressionEngine that requires PHP 5.2.17. Our php compilation efforts have only been partially successful on these newly deployed servers. In a nutshell, the site appears to be immovable/unupgradable due to certain customizations, and the client would prefer to not rebuild the site. I realize that this screams "security vulnerabilities", but I'm hoping I can find a creative solution before telling our client we're out of options left. – Zack Lerner Dec 17 '13 at 16:24
  • Are we out of luck? We've had a lot of trouble finding an image that has a lamp stack with 5.2.17 precompiled on it. – Zack Lerner Dec 17 '13 at 16:31
  • This is a separate question, off topic here – dyasny Dec 17 '13 at 21:28
0

it looks like this "pnscan" code is running from UID 9588.

you could set up an iptables directive to match on this UID and DROP any outgoing traffic. or lock down to only outgoing tcp/80 and tcp/22 or something....

nandoP
  • 2,021
  • 14
  • 15