> The CronRAT adds a number of tasks to crontab with a curious date specification: 52 23 31 2 3. These lines are syntactically valid, but would generate a run time error when executed. However, this will never happen as they are scheduled to run on February 31st
If cron doesn't execute it because February 31st isn't a date that cron will ever reach, then how is the script executed?
> The researchers note that the malware contacts a command and control (C2) server (47.115.46.167) using an “exotic feature of the Linux kernel that enables TCP communication via a file.”
This appears to be referencing the /dev/tcp usage [0]. This is not an exotic feature of the Linux kernel but part of bash for some time now (not sure when it was added). I'm not sure what's supposed to be exotic about it.
That github link refers to a better write-up https://sansec.io/research/cronrat (which the bleepingcomputer article rehashes, because hey, this is 2021 and ad views is the goal...).
> CronRAT’s main feat is hiding in the calendar subsystem of Linux servers (“cron”) on a nonexistant day. This way, it will not attract attention from server administrators. And many security products do not scan the Linux cron system.
It also seems to be trying to sell their "eComscan" product, which is a vulnerability scanner dedicated to eCommerce... what a weird specialization.
> That github link refers to a better write-up https://sansec.io/research/cronrat (which the bleepingcomputer article rehashes, because hey, this is 2021 and ad views is the goal...).
I looked through that one also, no mention about how the bash script is executed.
The 2nd screenshot on the bleedingcomputer article shows a bash function called "extract_payload_from_crontab" in the file decoder.sh
Maybe the malware relies on the scanner scanning executables (so sh files) for things like wget/curl, but since it ignores crontab, it will deem decoder.sh to be harmless.
I don't think it's weird at all. It's a large and at risk customer base that will be willing to pay for added protection, because the cost of some software is negligible compared to the damage that might be prevented.
8 comments
[ 0.29 ms ] story [ 31.3 ms ] threadIf cron doesn't execute it because February 31st isn't a date that cron will ever reach, then how is the script executed?
> The researchers note that the malware contacts a command and control (C2) server (47.115.46.167) using an “exotic feature of the Linux kernel that enables TCP communication via a file.”
This appears to be referencing the /dev/tcp usage [0]. This is not an exotic feature of the Linux kernel but part of bash for some time now (not sure when it was added). I'm not sure what's supposed to be exotic about it.
[0] https://gist.github.com/gwillem/fbe3e6b98e2e10d7f1f271ca4b6e...
> CronRAT’s main feat is hiding in the calendar subsystem of Linux servers (“cron”) on a nonexistant day. This way, it will not attract attention from server administrators. And many security products do not scan the Linux cron system.
It also seems to be trying to sell their "eComscan" product, which is a vulnerability scanner dedicated to eCommerce... what a weird specialization.
I looked through that one also, no mention about how the bash script is executed.
Maybe the malware relies on the scanner scanning executables (so sh files) for things like wget/curl, but since it ignores crontab, it will deem decoder.sh to be harmless.
I don't think it's weird at all. It's a large and at risk customer base that will be willing to pay for added protection, because the cost of some software is negligible compared to the damage that might be prevented.