Sorry about the long post but please bear with me.
I'm wondering if my system has been compromised. I've had issues in the past on this VM server with a Linux.BackDoor.Gates.5 Trojan that was DDoSing other servers. I have multiple backups of the VM at different points in time and have been trying to figure out when the intrusion may have happened (there is no real sensitive data on this VM and it is not on our network so I feel ok doing things this way).
The first couple of backups would systematically be infected by the aforementioned trojan even if they weren't initially. And then I reverted to a backup that seemed clean and have since kept a close eye on it. (PS: I have changed password on every restoration)
Today rkhunter found that /usr/bin/wget and /usr/bin/killall had their permissions changed from 0755 to 0777. Running ls -lct on these files showed the last modification to the file roughly two hours before I logged in (6:48 am).
Here are the steps I've taken:
- I've configured iptables to default drop outgoing as to not get the ip banned by service provider in the event of another DDoS
- Checked logs and nothing about a user login
- Checked logs and Apt did not run
- Installed and ran chkrootkit
- Compared md5sum for both of those files with a reference uncompromised install and they match. So I don't think the files have been altered
I realize logs can be altered on a compromised system so I'm not going by them 100%
chkrootkit sent a warning on a sucKIT rootkit. I've tested the first two point mentioned in this post
The SucKIT rootkit allows an attacker to hide malicious files by giving them a particular ending. The current attacker is hiding code that ends in xrk or mem. To test for the presence of the rootkit, create a file whose name ends in xrk or mem, then execute an "ls -l". If the files you just created are not shown in the output of ls, it means that the rootkit is hiding them, ie. your system is compromised and needs to be rebuilt.
Change directories to /sbin and execute an "ls -l init" -- the link count should be 1. Create a hard link to init using ln, and then execute the "ls -l init" again. If the link count is still 1, the SK rootkit is installed.
Rooted systems send usernames and passwords to other compromised machines using TCP port 55, so if you keep records of network connections, traffic to destination port TCP/55 merits further investigation.
The first two are negative hinting towards a false positive. I haven't checked for port 55 as I'm not sure how the best way of proceeding would be.
I've gone further into it and checked the following:
strings /sbin/init | grep HOME returns XDG_CACHE_HOME and XDG_CONFIG_HOME
and
sudo cat /proc/1/maps | grep init returns
7f396c089000-7f396c0c7000 r-xp 00000000 08:01 6553666 /sbin/init
7f396c2c7000-7f396c2c9000 r--p 0003e000 08:01 6553666 /sbin/init
7f396c2c9000-7f396c2ca000 rw-p 00040000 08:01 6553666 /sbin/init
So the HOME string is what triggers chkrootkit. I don't know if this is to be expected. again I have the same data on my reference system so I think it's a false positive.
Do you guys have any idea what I could check to see if the change in file permission is indeed a false positive or otherwise? thanks in advance.
