Powerful New Linux Malware Shikitega Uses Unusual Multi-Stage Stealth (att.com) 22
Here's a warning from the threat intelligence unit of AT&T Cybersecurity, AT&T Alien Labs:
With a rise of nearly 650% in malware and ransomware for Linux this year, reaching an all-time high in the first half year of 2022, threat actors find servers, endpoints and IoT devices based on Linux operating systems more and more valuable and find new ways to deliver their malicious payloads. New malwares like BotenaGo and EnemyBot are examples of how malware writers rapidly incorporate recently discovered vulnerabilities to find new victims and increase their reach.
But they've discovered a new malware targetting Linux endpoints and IoT devices, stealthily "delivered in a multistage infection chain where each module responds to a part of the payload and downloads and executes the next one. An attacker can gain full control of the system, in addition to the cryptocurrency miner that will be executed and set to persist."
The Register summarizes their report: The malware was dubbed "Shikitega" for its extensive use of the popular Shikata Ga Nai polymorphic encoder, which allows the malware to "mutate" its code to avoid detection. Shikitega alters its code each time it runs through one of several decoding loops that AT&T said each deliver multiple attacks, beginning with an ELF file that's just 370 bytes... AT&T didn't say how the initial infection occurs, but it did say Shikitega exploits two Linux vulnerabilities disclosed in 2021 to achieve its ultimate objective, which AT&T said appears to be the installation and execution of the XMRig cryptocurrency miner.
The final stage also establishes persistence, which Shikitega does by downloading and executing five shell scripts that configure a pair of cron jobs for the current user and a pair for the root user using crontab, which it can also install if not available. Shikitega also uses cloud hosting solutions to store parts of its payload, which it further uses to obfuscate itself by contacting via IP address instead of domain name....>
>
Bottom line: Shikitega is a nasty piece of code. AT&T recommends Linux endpoint and IoT device managers keep security patches installed, keep EDR software up to date and make regular backups of essential systems.
Ars Technica reports: The ultimate objective of the malware isn't clear. It drops the XMRig software for mining the Monero cryptocurrency, so stealthy cryptojacking is one possibility. But Shikitega also downloads and executes a powerful Metasploit package known as Mettle, which bundles capabilities including webcam control, credential stealing, and multiple reverse shells into a package that runs on everything from "the smallest embedded Linux targets to big iron." Mettle's inclusion leaves open the potential that surreptitious Monero mining isn't the sole function....
Given the work the unknown threat actors responsible devoted to the malware's stealth, it wouldn't be surprising if the malware is lurking undetected on some systems.
But they've discovered a new malware targetting Linux endpoints and IoT devices, stealthily "delivered in a multistage infection chain where each module responds to a part of the payload and downloads and executes the next one. An attacker can gain full control of the system, in addition to the cryptocurrency miner that will be executed and set to persist."
The Register summarizes their report: The malware was dubbed "Shikitega" for its extensive use of the popular Shikata Ga Nai polymorphic encoder, which allows the malware to "mutate" its code to avoid detection. Shikitega alters its code each time it runs through one of several decoding loops that AT&T said each deliver multiple attacks, beginning with an ELF file that's just 370 bytes... AT&T didn't say how the initial infection occurs, but it did say Shikitega exploits two Linux vulnerabilities disclosed in 2021 to achieve its ultimate objective, which AT&T said appears to be the installation and execution of the XMRig cryptocurrency miner.
The final stage also establishes persistence, which Shikitega does by downloading and executing five shell scripts that configure a pair of cron jobs for the current user and a pair for the root user using crontab, which it can also install if not available. Shikitega also uses cloud hosting solutions to store parts of its payload, which it further uses to obfuscate itself by contacting via IP address instead of domain name....>
>
Bottom line: Shikitega is a nasty piece of code. AT&T recommends Linux endpoint and IoT device managers keep security patches installed, keep EDR software up to date and make regular backups of essential systems.
Ars Technica reports: The ultimate objective of the malware isn't clear. It drops the XMRig software for mining the Monero cryptocurrency, so stealthy cryptojacking is one possibility. But Shikitega also downloads and executes a powerful Metasploit package known as Mettle, which bundles capabilities including webcam control, credential stealing, and multiple reverse shells into a package that runs on everything from "the smallest embedded Linux targets to big iron." Mettle's inclusion leaves open the potential that surreptitious Monero mining isn't the sole function....
Given the work the unknown threat actors responsible devoted to the malware's stealth, it wouldn't be surprising if the malware is lurking undetected on some systems.
Powerful new malware in form of 2 cron jobs??? (Score:3)
It's been years ago, that we heard about malware hiding in kernel modules, modifying libraries and whatnot, and now we are supposed to be up in arms about malware "hiding" in crontab entries? I accept, that their ELF modification system is clever, but everything else is pretty old school IMHO. Exploits from Metasploit? From 2021? In a time, in which updates are almost forcefully shoved down your throat?
Re: (Score:3)
Indeed. It seems there is a whole bunch of Linux "sysadmins" that do not understand the very basics these days. Probably people from the Microsoft quagmire that now think (or their bosses think) they can use the same no skill, no-clue approach that works for MS "system administration", with predictable results.
I mean, "hidhing" in a cron-job? I would not even have considered that an option because it is blatantly obvious you check there. Apparently attackers can still be successful on a really low skill-lev
Re:Powerful new malware in form of 2 cron jobs??? (Score:4, Insightful)
Well, *I* don't regularly check crontab entries. So I assume that many Linux systems are installed on personal computers where crontab entries aren't regularly checked.
What's missing, though, is an explanation of how the infection is passed. Usually I find that I don't have the method of infection implemented. This time I can't tell.
Re: (Score:3)
I don't check crontab entries either, but tripwire has an eye on /etc/crontab and /etc/crontab.d and will alert everyone involved in case these change. And yes, tripwire (among others) is an expected skill for everyone running a production server.
Re: (Score:2)
Yep. There is a number of files that are not supposed to be changed on a production server. This does obviously include the crontabs. But the poster one above you has a point: What is the infection vector here and is this primarily a threat for installations that are not considered "production"?
Re: (Score:2)
You said "production server", but mine is just a personal computer. This may be included in what you mean, in which case I think your assumption is unreasonable. (I install tripwire when I think of it, but after a new install I frequently don't.)
And that STILL doesn't tell me how the infection happens. I generally find that I don't have a required application installed or service active. This time I can't tell. I.e., tripwire is all fine and good, but I'd like to not get the original exposure, even if
Re: (Score:2)
I don't have tripwire running on my home computer either, but my home computer is fully updated and therefore not susceptible to 2021's exploits, and it also doesn't run publicly accessible services. Therefore it is rather unlikely, that this type of malware will ever reach my home computers.
Embedded systems seem indeed to be the main target of this malware, and they most likely won't run tripwire :-(
Re: (Score:2)
The problem is, while I don't *THINK* I'm likely to get exposed to this exploit, I can't tell. The necessary information doesn't seem to be present.
Re: (Score:2)
Just say file integrity monitoring (it's what you're talking about I think, and it is more descriptive of what is required and descriptive might teach someone better than just mentioning a product). Some people don't want to use proprietary even if it is good. And like you said, there are others. And yes, it is required on any system, production or personal.
Re: (Score:2)
Embedded systems: routers, smarthome controllers, etc. Those don't get administered. They get plugged in and forgotten about, particularly by end users. And small businesses. And non-profits. And other entities that should know better, but don't because they're run by the mental midgets churned out by MBA schools, who are trained to regard security and IT in general as cost centers that, because they generate no income, are of no value.
Re: (Score:2)
You are right, and these would also be susceptible to exploit code from 2021 :-(
On the other hand: these are barely useful for crypto mining ...
Re: (Score:2)
Still, these need system administration as well. It is probably time to classify non-administrated systems per default as gross negligence and make the owner accountable for any damage done.
Re: Powerful new malware in form of 2 cron jobs??? (Score:1)
Just more automated ways of doing stuff... (Score:2)
We have seen many effective ways of keeping access once something gets root... but that isn't really the point. We have had malware which would toss in kernel modules to hide itself, use filesystem tricks to hide file access, and even write to other places. That is important... but if malware doesn't get a foothold in the first place, that all is moot.
In the early 1990s, Macs would load code from the SCSI hard drives, and execute it. This was back in the days of System 6/7. It was trivial to write a vir
Re: (Score:2)
Overall, Linux still is pretty good.
And much more so with a competent system administrator. Of course, if you can barely get the default image deployed in a cloud, and looking into a crontab is outside of your skill-set, then your Linux installations will probably not be very secure...
Re: (Score:2)
We have seen many effective ways of keeping access once something gets root... but that isn't really the point. We have had malware which would toss in kernel modules to hide itself, use filesystem tricks to hide file access, and even write to other places. That is important... but if malware doesn't get a foothold in the first place, that all is moot.
The scary part is, that at least according to this article the story is over as soon as the "evil crontab entries" are created and deployed. No mentioning of evil kernel modules or file system tricks.
nothing new (Score:1)
Re: (Score:2)
> A long time ago ... just a small change in code you can often bypass antivirus.
It got better.
Missing vital information (Score:2)
From TFS: "AT&T didn't say how the initial infection occurs".
Without that information it is relatively impossible to say how bad this could be. Does it require the user to be logged in as root? Does it require user interaction besides receiving mail or visiting a website? Is it zero interaction or do you have to acknowledge security prompts? Etc.
I'm going to put this down as "Meh, so what?" even though I run Linux "endpoints".