Re: What is the best free HIDS for Debian
The next thing I would do is create a timeline. Mount the partition with
noatime so that access times are preserved as they are on new file
operations and then let find output access, modification and creation
time of all files. Look on when these three executables have been
modified/created and then search back on what has happened at the
earliest time right before the rootkit has been installed. Once I
analysed a system of mine like this and found out that some suspicious
files had been uploaded in the ~/.skype directory. If I remember back I
think I had used vim for it but it should also be possible to use sth.
Am 06.05.22 um 15:52 schrieb Elmar Stellnberger:
Am 04.05.22 um 13:17 schrieb Sylvain:
I've just tried debcheckroot too. It throws error. I'll try to fix them.
Am 06.05.22 um 15:05 schrieb Sylvain Sécherre:
> Here's the fileserror.lis:
> ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
> ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755
> ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
I hope you won´t mind that I am citing the output of debcheckroot you
have given me.
These three files point to an infection with a rootkit. Don´t care
about modified configuration files like in /etc too much (but you may
still have a look at them). Executable files on the other hand must
never be modified. If these three files are different it means that
someone has altered your system. If you look at the man pages of these
executables then you also know that a maker of a rootkit would have
interest to modify exactly these files.
> The file filesunverified.lis is very long, while pkgcorrupt.lis is
If you have updated your system some time ago and there are newer
versions on the update server now then debcheckroot can certainly not
find these packages any more. You could try to update your system and
then verify again. Normally the rootkit will persist. However connecting
your computer to a network may be detrimental since the rootkit owner
may simply uninstall his rootkit once he knows that his malware has been
I would at least save suspicious executables first and additionally
the packages with known good of the same version.