Cant delete or chown file as a root

[postcd]

Hello,

some hack script suddenly appear in the /root directory of my VPS. Lets call it "badscript"

-rwxr-xr-x 1 root root 1.2M Jul 18 12:34 badscript

but i cant delete it or chown it being root..

it says:

rm: cannot remove `badscript': Operation not permitted
chown: changing ownership of `badscript': Operation not permitted

stat badscript

File: `badscript'
Size: 1189151 Blocks: 2336 IO Block: 4096 regular file
Device: 57h/87d Inode: 17932822 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2014-07-29 16:51:30.000000000 -0400
Modify: 2014-07-18 12:34:49.000000000 -0400
Change: 2014-07-29 16:51:25.000000000 -0400

Please any idea how to block that person who added this script to my linux redhat server?

"last" command shows only my regular ips, no stranger ip

and how to remove that script? Thank you

 

[rstanley]

Hello,

some hack script suddenly appear in the /root directory of my VPS. Lets call it "badscript"



but i cant delete it or chown it being root..

it says:


stat badscript


Please any idea how to block that person who added this script to my linux redhat server?

"last" command shows only my regular ips, no stranger ip

and how to remove that script? Thank you

Is this a computer at your location, or at a hosting company? If the latter, then you should contact tech support at the hosting company.

 

[postcd]

its unmanaged server under my management in pro datacenter..

 

[rstanley]

its unmanaged server under my management in pro datacenter..

I would guess that your system may have been compromised. Take a look at /etc/passwd, /etc/shadow, and /etc/group for any recent changes and/or additions. Look at root to see if it has been altered, and for any new users/groups you don't recognize. Is root still really root???

This is just a guess as I have never encountered anything like this before. I would change root's password to something more secure than your current password, whatever it is. You might want to change all the passwords, period.

Check your logs as well for unauthorized activity.

Last resort, a fresh installation of the server from scratch!

Good luck!

 

[JasKinasis]

Your server has obviously been compromised, so rstanleys advice is good.

If you are 100% sure you were logged in as root, then you should have been able to remove the file. Trying to think of reasons a file would not be deleted, I can think of two possibilities offhand:

1. If there is a program/process running which has that file open, that might prevent you from being able to remove the file. Not 100% on that though! But you might want to see what processes are running on that machine and try to kill any suspicious processes before attempting to delete the file again.

2. Are there any special characters at the start of the filename? If so, perhaps you need to escape them in order to delete the file.

Other than that, I have nothing. All the best though!

 

[postcd]

thx, when i run lsattrm it shows:

----i---------- ./badscript

groups

root

cat /etc/passwd | grep root

root:x:0:0:root:/root:/bin/bash
operator:x:11:0perator:/root:/sbin/nologin

Also thanks to command:
find /root -type f -name "*" -mtime -48

i found some modiffied files, amongs them:

/root/sent
/root/badscript
/root/conf.n
/root/.mysql_history
/root/.bash_history

cat /root/.bash_history

uname -a
passwd
ps -
killall -9 httpd
killall -9 pickup
killall -9 qmgr
killall -9 proftpd
killall -9 xinetd
wget url with bad script
chmod +x badscript
./badscript
chattr +i badscript
killall -9 sshpa

(i replaced ip by asterisks)

cat /root/.mysql_history

password
show databases;

please any ideas? I already changed root password, and its not guessable one..
how that person could access server like this while its in secure datacenter and password is not dictionary one with random chars..

 

[WharfRat]

As root

chattr -i /root/badscript

should remove the immutable attribute. Root should have been able to delete that file.

Not sure what you're running, but this 'might' be able to spot a rouge module that's not in the kernel tree.

find /lib/modules/$(uname -r)/ -type f|tr -d '_-' > /tmp/list;cat /proc/modules|tr -d '_'|awk '{print $1}'|\
while read m;do grep -qw "$m.ko" /tmp/list; if [ $? -eq 0 ];then echo "$m OK"; else echo "Check ---> $m";fi;done;rm /tmp/list

 

[postcd]

find /lib/modules/$(uname -r)/ -type f|tr -d '_-' > /tmp/list;cat /proc/modules|tr -d '_'|awk '{print $1}'|\
> while read m;do grep -qw "$m.ko" /tmp/list; if [ $? -eq 0 ];then echo "$m OK"; else echo "Check ---> $m";fi;done;rm /tmp/list
rm: remove regular file `/tmp/list'? y

[root@vps ~]# find /lib/modules/$(uname -r)/ -type f|tr -d '_-' > /tmp/list;cat /proc/modules|tr -d '_'|awk '{print $1}'|while read m;do grep -qw "$m.ko" /tmp/list; if [ $? -eq 0 ];then echo "$m OK"; else echo "Check ---> $m";fi;done;rm /tmp/list
rm: remove regular file `/tmp/list'? n

[root@vps ~]# cat /tmp/list
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.ccwmap
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.usbmap
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.inputmap
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.seriomap
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.alias.bin
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.isapnpmap
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.dep.bin
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.ieee1394map
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.symbols.bin
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.pcimap
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.dep
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.ofmap
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.symbols
/lib/modules/2.6.18371.3.1.el5.028stab110.1/modules.alias

 

[WharfRat]

Apparently, you're not getting the results that I get

Can I ask what you're running and what uname -a returns ?

 

[postcd]

uname -a
http://pastebin.com/e3i1rLtp

 

[WharfRat]

The problem here is you don't know how deeply this intrusion has intertwined itself in your system.

What I would do is boot a live media, mount the partition and run finds with the date range of that rouge file, then carefully move/rename questionable ones somewhere where they can't do any harm.

Then boot the system and check if there are any repercussions and, if not, keep diligent check on it.

I don't know what constraints you're under in that datacenter, but a fresh install should definitely be considered as a remedy.

Good luck