Did you read the post on crowdstrike in detail? I suggest you do, your script will not work because
- rootkit re-adds itself to the /etc/rc.local
- it patches the filesystem functions to hide itself when you read the file, so I am not convined grep will pick it up anyway
- you do not unload the actual kernel module if it is running, nor destroy the rootkit kernel module
- did you test it by installing the rootkit in a vm, and confirm that your code will detect and remove it? if not, i do not think you should publish such code just to give people a false sense of security when they run it and says "rootkit not present"
I suggest you do not claim that your removal tool works until you have tested it successfully. this is true for all software, but is even more critical for something like this, since a false sense of security is actually far worse than just being infected.
Actually, this may be a way of detecting it. If you ls -l rc.local, ls should read the file size out of its inode (ie, not by reading the file itself). Which means that saving the buffer you get while reading rc.local in vim to another file will result create a file with a different size than the real rc.local.
I don't have access to a system with the root kit, but something like comparing the reported size of the file and the number of bytes you can read might work
if ls -l /etc/rc.local | awk '{print $5}' != \
cat /etc/rc.local | wc -c
Also looks like you might be able to see it running with a ps also.
- rootkit re-adds itself to the /etc/rc.local
- it patches the filesystem functions to hide itself when you read the file, so I am not convined grep will pick it up anyway
- you do not unload the actual kernel module if it is running, nor destroy the rootkit kernel module
- did you test it by installing the rootkit in a vm, and confirm that your code will detect and remove it? if not, i do not think you should publish such code just to give people a false sense of security when they run it and says "rootkit not present"
http://blog.crowdstrike.com/2012/11/http-iframe-injecting-li...