I thought it was overly paranoid, but it seems that would have really helped in this case.
Tor is an essential tool for all citizens -- Especially those in the US who would be targeted by those who seek infinite, unrestrained power.
[1] https://i.kym-cdn.com/photos/images/original/002/128/768/403...
[2] https://travel.state.gov/content/travel/en/traveladvisories/...
And of course the privilege escalation is done by a polkit vulnerability...
A more appropriate but less clickbaity title would be "Stealthy malware targetting servers running RocketMQ"
Like, how one picks a lock versus how one lives rent free in the attic without discovery.
Theyre not specifically dependent activities.
> "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 current version of pkexec doesn't handle the calling parameters count correctly and ends trying to execute environment variables as commands.
Oh, for fucks sake.
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)."
And remember: echo * can be your "ls" in a pinch.
There were so.e great insights from this researcher but they're missing some very fucked up elements of this malware.
1. I'm pretty sure it has. "fuck with it" scale. It leaves you alone if you don't fuck with it. In fact, I'd bet money that this malware did all the cryptocurrency shit for a reason like a bait and switch.
2. It effects android too. Doesn't seem to matter what device or how updated it is.
3. And windows.
4. It isn't persistent through rootkits. I mean, it is. But it's also deeper. My current thinking is that is persistent on my machines using the RAM training alorithms to spin itself up. From..
5. Your display. I have four displays that have had their firmware fucked with. Just discovered it's on a brand new mobo that I set up ensuring there was not a single peripheral I'd used before, no leds. Hadn't even installed an os before running a ram only mode Linux session from a hardware write protected usb THROUGH a write protected usb bridge. The only thing it was connected to that wasn't new was my monitor, and the UBS key (created from a secure pc and immediately write protected).
I think that this thing is EVERYWHERE. I've seen references in bash files from the initramfs that allude to escalating is action based on variables I. Ould t pin down
Also did you figure out why it reprograms display firmware? It spreads through displays and webcams optically. It can send or receive from either (same way NSA uses speakers as microphones basically). That's not the crazy part though, the crazy part is that it does human and canine retinal embeddings from either. It basically writes code on the retina and then that person can spread it to new systems. That turned out to be the biggest problem on our side. Sunglasses don't work.
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?
IMHO, a simplest one is to check $PATH. If there are suspicious entries, like /bin/.local/bin, it's a sign of infection.
You can also check for presence of the specific files as mentioned close to the end of article.
I assume it starts by detecting a continuous 100% utilization of the cpu’s.
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.
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.
UEFI won't help here. But keeping your system up to date and limiting the system to the necessary functionality will help you.
