A lot of focus on the malware itself, but not so much on the misconfigurations and vulnerabilities which enable it. Would love to see that list. Other than that, the evasion techniques look pretty traditional.
And of course the privilege escalation is done by a polkit vulnerability...
Also more interested in what the misconfigs are.
It seems to be a RocketMQ vuln; it's described further down the page.
From the article:
> "Aqua Nautilus researchers aim to shed light on a Linux malware that, over the past 3-4 years, has actively sought more than 20,000 types of misconfigurations in order to target and exploit Linux servers. If you have a Linux server connected to the internet, you could be at risk. In fact, given the scale, we strongly believe the attackers targeted millions worldwide with a potential number of victims of thousands, it appears that with this malware any Linux server could be at risk.
...
- It utilizes rootkits to hide its presence.
- When a new user logs into the server, it immediately stops all “noisy” activities, lying dormant until the server is idle again.
- It utilizes Unix socket for internal communication and TOR for external communication.
- After execution, it deletes its binary and continues to run quietly in the background as a service.
- It copies itself from memory to various locations on the disk, using deceptive names.
- It opens a backdoor on the server and listens for TOR communications.
- It attempts to exploit the Polkit vulnerability (CVE-2021-4043) to escalate privileges.
In all the attacks observed, the malware was used to run a cryptominer, and in some cases, we also detected the execution of proxy-jacking software. During one of our sandbox tests, the threat actor utilized one of the malware’s backdoors to access the honeypot and started deploying some new utilities to better understand the nature of our server, trying to understand what exactly we are doing to its malware."
The article goes into more depth of the attack flow, what the malware does, and how they detected it.
The CVE has a typo; the actual is CVE-2021-4034. https://nvd.nist.gov/vuln/detail/CVE-2021-4034
> - It opens a backdoor on the server and listens for TOR communications.
So a `lsof -iTCP` should list it, right? Is it using TCP port 9050 or a custom port?
EDIT: Ha, they are (not surprisingly) way ahead of me. From the article: "The malware continues to copy itself from memory to half a dozen other locations, with names that appear as conventional system files. It also drops a rootkit and a few popular Linux utilities that were modified to serve as user land rootkits (i.e. ldd, lsof)."
are there any scripts or steps to 100% detect perfectl yet?
Article mentions couple of const paths that are used, like /root/.config/cron/perfcc.
Also, it mentions that ~/.profile is modified (EDIT: and many others, actually), so IDS like AIDE, if operated correctly, should alert you on that. I don't see any mentions about attempts to circumvent locally run IDS. I wonder if/why malware author did not attempt any evasive actions here, given how much they try otherwise. Maybe cost/benefit ratio is too low?
> In all the attacks observed, the malware was used to run a cryptominer
I assume it starts by detecting a continuous 100% utilization of the cpu’s.
Here is Ars Technica's write up: https://arstechnica.com/security/2024/10/persistent-stealthy...
And the discussion https://news.ycombinator.com/item?id=41736572.
Does uefi secureboot help or not at all?
The article describes a hooking library as a rootkit but I can't see any indication of this rootkit inserting itself into the boot process. Instead, it seems to LD_PRELOAD itself into processes at a later stage.
Secure boot won't help here. In theory one could configure a system to only trust executables and DLLs signed by a trusted, external signatory (like a locally hosted package repository) but I don't know of any Linux distros that make it easy to set up something like that. You'd also need to invent something to sign scripts, because signing binaries is only a part of the problem (in theory you could set this up Powershell, I think? But I doubt many Linux systems will boot with PS in the place of /bin/sh). Once the kernel launches the init process, the rest secure boot verification chain essentially ends.
It seems to me that prevention isn't hard by simply updating old software and perhaps running antivirus software on your servers.
I'm not sure, outside of my expertise, but I think it might not help.
The attack takes place after boot, so maybe at best UEFI secureboot could prevent persistence of the malware, but I don't think it'd even achieve that, as the malware adds popular Linux utilities that were modified to serve as user land rootkits, and runs them by modifying the ~/.profile script. That script is ran when the user logs in (it starts the malware first, and then everything that's supposed to run on the server after), and I don't believe UEFI secureboot has any protections against ~/.profile script modifications or rootkits ran after boot.
See the mitigation section in the article: https://www.aquasec.com/blog/perfctl-a-stealthy-malware-targ...
UEFI won't help here. But keeping your system up to date and limiting the system to the necessary functionality will help you.
In the mitigation section there is written 'Deploy Runtime Protection: Use advanced anti-malware and behavioral detection tools that can detect rootkits, cryptominers, and fileless malware like perfctl.' -- which tools can we currently use to detect perfctl?
Not at all.
I'm curious to understand why you would think that it would protect this at all?