Is my server hacked?

newlotus007 · 05-09-2014, 03:36 AM

Hello All,

I see the following processes continuously run even after killing them.

13820 root 20 0 84264 1276 0 S 77.7 0.0 11:42.93 /etc/sfewfesfsh
13472 root 20 0 968 556 468 S 0.3 0.0 0:00.19 ./atack 700
14413 root 20 0 968 556 468 S 0.3 0.0 0:00.18 ./atack 700
14590 root 20 0 968 556 468 S 0.3 0.0 0:00.18 ./atack 700
14688 root 20 0 968 556 468 S 0.3 0.0 0:00.19 ./atack 700
15364 root 20 0 968 556 468 S 0.3 0.0 0:00.17 ./atack 700
15420 root 20 0 968 556 468 S 0.3 0.0 0:00.17 ./atack 700
15879 root 20 0 968 556 468 S 0.3 0.0 0:00.15 ./atack 700
15979 root 20 0 968 556 468 S 0.3 0.0 0:00.17 ./atack 700
16165 root 20 0 968 556 468 S 0.3 0.0 0:00.17 ./atack 700

cat /proc/version
Linux version 2.6.32-431.el6.x86_64 (mockbuild@c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Nov 22 03:15:09 UTC 2013

Is my server hacked? What steps I should do to stop this? Please advise ASAP.

Thanks in advance

pan64 · 05-09-2014, 03:45 AM

first you need to check the parent process.

newlotus007 · 05-09-2014, 04:47 AM

I don't think you got my question. Even if I delete the parent process, these programs restarts automatically.

unSpawn · 05-09-2014, 04:48 AM

Likely BillGates botnet, see ValdikSS/billgates-botnet-tracker.
Try searching this and post output:

Code:

ITEMS="pro proh sfewfesfsh pojie DbSecuritySpt xpacket.ko libamplify.so atddd ksapdd kysapdd sksapdd skysapdd ferwfrre gfhddsfew gfhjrtfyhuf rewgtf3er4t sdmfdsfhjfe"
for ITEM in $ITEMS; do find /boot /etc /usr /tmp /var -type f -iname "*${ITEM}*" -ls; done

Also check /etc/rc.d/rc.local and /var/spool/cron/root /var/spool/cron/crontabs/root.
*If you find any do contact me (or add them to http://sourceforge.net/p/rkhunter/feature-requests/) as I'd like a copy please.

pan64 · 05-09-2014, 05:10 AM

Quote:

Originally Posted by newlotus007

I don't think you got my question. Even if I delete the parent process, these programs restarts automatically.

You didn't talk a word about parent processes. Yes, you need to find the parent (if possible), look for the one which spawns these processes. Probably you will find a cronjob or daemon process. In such cases you need to detach the box from network too.

newlotus007 · 05-09-2014, 06:36 AM

Quote:

Originally Posted by unSpawn

Likely BillGates botnet, see ValdikSS/billgates-botnet-tracker.
Try searching this and post output:

Code:

ITEMS="pro proh sfewfesfsh pojie DbSecuritySpt xpacket.ko libamplify.so atddd ksapdd kysapdd sksapdd skysapdd ferwfrre gfhddsfew gfhjrtfyhuf rewgtf3er4t sdmfdsfhjfe"
for ITEM in $ITEMS; do find /boot /etc /usr /tmp /var -type f -iname "*${ITEM}*" -ls; done

Also check /etc/rc.d/rc.local and /var/spool/cron/root /var/spool/cron/crontabs/root.
*If you find any do contact me (or add them to http://sourceforge.net/p/rkhunter/feature-requests/) as I'd like a copy please.

You are spot on. PFA the reports. Let me know how to remove them permanently.

Thanks in advance.

newlotus007 · 05-09-2014, 06:47 AM

Also, I;'m not really sure why the find command takes 100% CPU.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18027 root 20 0 2024 532 456 R 100.0 0.0 0:14.86 find

Regards

unSpawn · 05-09-2014, 06:49 AM

Quote:

Originally Posted by newlotus007

You are spot on.

Then create a tar ball with these:

Code:

1322200 1492 -rwsrwsrwt   1 root     root      1524643 Nov 29 02:33 /etc/ferwfrre
1322175 1492 -rwsrwsrwt   1 root     root      1524643 Nov 29 02:29 /etc/sdmfdsfhjfe
1322178 1492 -rwsrwsrwt   1 root     root      1524643 Jan 10 07:06 /etc/gfhjrtfyhuf
1322199 1492 -rwsrwsrwt   1 root     root      1524643 Jan 31 08:06 /etc/rewgtf3er4t
1322067 1492 -rwsrwsrwt   1 root     root      1524643 Apr 11 14:38 /etc/gfhddsfew
1063281 1268 -rwxrwxrwx   1 root     root      1295069 Apr 20 10:46 /tmp/get/pro
    20  346 -rwxr-xr-x   1 root     root       352604 May  6 13:26 /boot/proh
1317982  348 -rwxr-xr-x   1 root     root       352604 May  9 06:00 /etc/sfewfesfsh
949562 1268 -rwxr-xr-x   1 root     root      1295031 May  9 06:00 /usr/bin/pojie
1317983    4 -rwxr-xr-x   1 root     root           27 May  9 06:00 /etc/rc.d/init.d/DbSecuritySpt

and add them to http://sourceforge.net/p/rkhunter/feature-requests/ or discuss sending the files to me.

Quote:

Originally Posted by newlotus007

Let me know how to remove them permanently.

This is a root compromise. There will be no restoring of backups and any other "fixing". This machine runs Xorg and GNOME and has not been maintained properly (see ancient kernel version). From the list above, unless time stamps have been modified, you cannot establish how long this compromise has been going on. This means you will have to sever network connection to the machine right now, isolate it so nobody can use it and investigate how the perp got in. Other than that it's game over: create a new machine, properly harden it before putting it into production and regularly audit its contents and logs and update software.

unSpawn · 05-09-2014, 06:54 AM

Quote:

Originally Posted by newlotus007

Also, I;'m not really sure why the find command takes 100% CPU.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18027 root 20 0 2024 532 456 R 100.0 0.0 0:14.86 find

Unless the following command shows "interesting" open files then this is of no concern right now as you have higher priorities.

Code:

cat -v /proc/18027/cmdline; lsof -Pwlnp 18027

*And I really need a copy of those files (to finish this) so come on and send me those files.

DJ Shaji · 05-09-2014, 02:35 PM

Quote:

Originally Posted by unSpawn

This is a root compromise.

I swear I got the chills when I read this.

Apparently the way to get this is via a weak root password and sshd running. So use key based authentication if possible, and always use a strong password for root (!).

btw unspawn, I didn't know you were a big security hotshot

I went to the rootkit hunter website, and I saw your name there, and I was like, hey, I know that guy! Glad you're on our team

unSpawn · 05-09-2014, 04:33 PM

Quote:

Originally Posted by DJ Shaji

Apparently the way to get this is via a weak root password and sshd running.

No. One shouldn't run services one doesn't need. And any account should have a strong password period.

Quote:

Originally Posted by DJ Shaji

So use key based authentication if possible, and always use a strong password for root (!).

SSH best practices include not allowing root access to any service directly (use an unprivileged account instead), limiting access and using public key authentication. There isn't any "if possible" in that nor should there be.

Quote:

Originally Posted by DJ Shaji

I didn't know you were a big security hotshot

I most certainly am not: that's your perception.

suicidaleggroll · 05-09-2014, 04:55 PM

Quote:

Originally Posted by unSpawn

This machine runs Xorg and GNOME and has not been maintained properly (see ancient kernel version).

2.6.32-431 is the current CentOS 6.5 kernel, and 6.5 is the current version of the 6.x series, and the 6.x series is the current version of CentOS. He can't get any newer than that without switching to a completely different distro.

unSpawn · 05-09-2014, 05:19 PM

Quote:

Originally Posted by suicidaleggroll

2.6.32-431 is the current CentOS 6.5 kernel, and 6.5 is the current version of the 6.x series, and the 6.x series is the current version of CentOS. He can't get any newer than that without switching to a completely different distro.

Not to go OT (I'd rather have to OP post the nfo I need) but his kernel version reads:

Code:

2.6.32-431.el6.x86_64 (mockbuild@c6b8.bsys.dev.centos.org) (..) #1 SMP Fri Nov 22 03:15:09 UTC 2013

which isn't:

Code:

2.6.32-431.17.1.el6.x86_64 (mockbuild@c6b8.bsys.dev.centos.org) #1 SMP Wed May 7 23:32:49 UTC 2014

as in kernel-2.6.32-431.17.1.el6.

suicidaleggroll · 05-09-2014, 05:40 PM

Nov 2013 is hardly ancient...

unSpawn · 05-10-2014, 03:16 AM

Please send me the files as requested (if the concept of reciprocity means anything to you) and know by doing so you'll be helping others.

Quote:

This is a root compromise. There will be no restoring of backups and any other "fixing". (..): create a new machine, properly harden it before putting it into production and regularly audit its contents and logs and update software.

Please confirm you understand the gravity of the situation and what steps you have to take next.
If unclear: ask.