My server was hacked and we found it by noticing large amounts of bandwidth. A user had a common name and easy password. I disabled the user and installed denyhosts. The only item that I couldn't clean up was a cronjob found in the /var/spool/cron/crontabs directory listed as

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (cron.d installed on Wed Dec 8 09:12:22 2010)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
* * * * * /dev/shm/ /.access.log/y2kupdate >/dev/null 2>&1

Could someone tell me where to find this file or what is going on?

Thanks,

Jason

You don't see it in /dev/shm? That is a common directory where hackers put stuff because its writeable.

That space after shm/ and /.access looks a little strange though.

Yes, everything is gone in that directory. It looks like the hacker cleaned everything up except the .bash_history of the user they hacked. The computer was rebooted. Is it like the /tmp directory and everything is deleted on shutdown?

Jason

Please run '( /bin/ps axfwwwe; lsof -Pwln; netstat -antupe; who )| /tmp/result.log', shut down all 'net-facing services except SSH, make the firewall block IRC traffic, check any 'net-facing users crontab in /var/spool/cron and perform tasks as per the CERT Intruder Detection Checklist: http://web.archive.org/web/200801092...checklist.html ('tis an oldy BTW) and post feedback.

unSpawn,

Was the '|' a typo? In other words did you mean '( /bin/ps axfwwwe; lsof -Pwln; netstat -antupe; who ) > /tmp/result.log'?

Yes, thanks, either ')|tee /file' or ') >/file'.

Apart from vulnerabilities exploited in the OS due to lack of updates or severely misconfigured machines the most common infection vector would be in running outdated, vulnerable software in the web stack. While other languages are equally prone to this it's commonly PHP-based software. And while I don't know the exact contents of the kit that contains y2kupdate accounts here and elsewehere suggest it is used to deliver and run an IRC bouncer (usually PsyBNC). So if the application is active you should see any process ("httpd -DSSL"?) making connections to IRC servers.

On second thought it would be better to run 'mv -f /etc/cron.deny /etc/cron.deny_; echo root > /etc/cron.allow' as this would only allow the root user to use cron. If you however suspect a root compromise then that's not going to help and you should bring the machine down fast to avoid it being used against other systems. Also note that "fixing" one hole like you did does not automagically mean you should trust the machine: you have to ensure integrity by checking it, not just assume it's "OK".

1 members found this post helpful.