New Linux Malware Downloader for Compromised Servers Spotted in the Wild (bleepingcomputer.com) 30
"A new Linux malware downloader created using SHC (Shell Script Compiler) has been spotted in the wild," reports the site Bleeping Computer, "infecting systems with Monero cryptocurrency miners and DDoS IRC bots...
"The analysts say the attacks likely rely on brute-forcing weak administrator account credentials over SSH on Linux servers.... " According to ASEC researchers, who discovered the attack, the SHC loader was uploaded to VirusTotal by Korean users, with attacks generally focused on Linux systems in the same country.... When the SHC malware downloader is executed, it will fetch multiple other malware payloads and install them on the device. One of the payloads is an XMRig miner that is downloaded as a TAR archive from a remote URL and extracted to "/usr/local/games/" and executed....
The second payload retrieved, dropped, and loaded by the SHC malware downloader is a Perl-based DDoS IRC bot. The malware connects to the designated IRC server using configuration data and goes through a username-based verification process. If successful, the malware awaits commands from the IRC server, including DDoS-related actions such as TCP Flood, UDP Flood, and HTTP Flood, port scanning, Nmap scanning, sendmail commands, process killing, log cleaning, and more.
ASEC warns that attacks like these are typically caused by using weak passwords on exposed Linux servers.
"The analysts say the attacks likely rely on brute-forcing weak administrator account credentials over SSH on Linux servers.... " According to ASEC researchers, who discovered the attack, the SHC loader was uploaded to VirusTotal by Korean users, with attacks generally focused on Linux systems in the same country.... When the SHC malware downloader is executed, it will fetch multiple other malware payloads and install them on the device. One of the payloads is an XMRig miner that is downloaded as a TAR archive from a remote URL and extracted to "/usr/local/games/" and executed....
The second payload retrieved, dropped, and loaded by the SHC malware downloader is a Perl-based DDoS IRC bot. The malware connects to the designated IRC server using configuration data and goes through a username-based verification process. If successful, the malware awaits commands from the IRC server, including DDoS-related actions such as TCP Flood, UDP Flood, and HTTP Flood, port scanning, Nmap scanning, sendmail commands, process killing, log cleaning, and more.
ASEC warns that attacks like these are typically caused by using weak passwords on exposed Linux servers.
Detection? (Score:2)
Re: Detection? (Score:1)
I miss the old exploit-db site format as I would have found an example of this "brute force" tactic by now.... So what is it a presentation layer thing? A python thing? A python presentation layer thing?
Re: (Score:2)
Re: (Score:2)
It would be real helpful if someone could post a way to detect this bit of malware once it's been planted, and/or the password cracker that it uses, so we can check the vulnerability of our passwords.
I guess if you need to use a password cracker to test the vulnerability of your passwords then they are probably vulnerable.
Re: (Score:2)
Probably just look which processes consume CPU. Remember this gets in via weak root-passwords, so the admin of the targeted systems is usually already a moron and no advanced hiding techniques are needed.
TFA (Score:2)
s/Pearl/Perl/
I'm pretty lax on my administration (Score:3)
I do automatically blackhole IPs that fail SSH logins too many times. Which seems to keep most of the riff-raff out. Make offline backups of the entire server (restic) once a week, so theoretically if something looks weird I can wipe the system and start over. But it would be a few days before I would likely notice anything was amiss.
Password? (Score:5, Insightful)
Why in the world let ssh accept a password login for root at all these days? Particularly over the open Internet?!?
Re: (Score:2)
I think I am guilty of it on at least one machine. Not open Internet, but still using passwords. It is a home VM, and I just never bothered to fix it. Thanks for the reminder to do better...
Re: (Score:3)
It seems common for little embedded devices or boards like the Pi. Even recent versions of AIX will install with a blank root password and have telnet (yes telnet) running by default.
Re: (Score:2)
It's not surprising for a just installed default, but on something like a Pi, you can change that and should. Otherwise, just don't allow access outside of the LAN.
Re: (Score:1)
It’s not surprising that an old IBM product barely gets any TLC. They have a lot of old products that they still sell, that still have a few tricks you don’t see in other products, and they don’t add simple features like “sort by” that you practically expect when being presented with data in a table.
Re: (Score:2)
AIX is an odd bird. IIRC, IBM tries to ensure compatibility [ibm.com] so that new versions of AIX can still run binaries made from the 3.2.5.1 days. Having telnet present makes sense for older setups, but a quick /etc/inetd.conf and restart of that will make short work of that.
As for Raspberry Pis, newer ROM revisions don't always use the "pi" user anymore. You can make your own username when making an SD card image. This is in part to an EU/UK law stipulating that default usernames can't exist... which does at l
Re: (Score:3)
Sooo, you know a reason to not do this? I am curious. Because I have yet to find a single valid reason to not allow ssh directly to root. And I have looked and have more than 30 years IT security experience and an on-topic PhD on top. The user-login & sudo mechanism is a lot worse security-wise. Yes, your root-password needs to be a tiny bit better because the attacker does not need to guess the user name. But that is not a convincing reason.
Re: (Score:3)
Because people are running password guessers daily. There's usually quite a few running at any given time. Since they generally don't care which host they compromise, they tend to go slowly from the perspective of any individual host so they don't hit the tilt switch like the old ones did. They will eventually guess the password. It's a variation on the million monkeys thought.
They WILL one day make a good guess, unless root with a password is disabled over SSH.
If you don't like sudo, turn that off too and
Re: (Score:2)
Ok, so all you have is nonsense that ignores real-world probabilities. Thanks.
Nope, nobody will guess my root password or the root password of anybody that knows what they are doing. It is just not possible.
Re: (Score:2)
Good luck with that. And read up on statistics...
Re: (Score:2)
Seriously? Talk about being arrogant and clueless. BTW, I passed my academic statistics course, but I guess you never had one. Now, I could explain in detail why you are _fundamentally_ wrong, but that would require some actual base-understanding on your side. I do not think that is present so I would be wasting my effort.
Just one hint: If you were correct, _all_ symmetrical encryption would be worthless because some real-world not very intense trying (we are talking ssh-logins over a network here, not dire
Re: (Score:2)
You seem to be working from outdated information or false assumptions. You also seem to be quite full of yourself.
Re: (Score:2)
Even though in theory, a root PW can't be guessed, I either use SSH keys, or I use a google authenticator PAM library which prompts for a six digit code after the password. This just gives me peace of mind, although if one has a long enough password, in theory, that is good enough... but it means that people can fill your logs up by guessing it.
With SSH, I use multiple ways to protect it. First is narrowing down the IP ranges of machines that can access the incoming SSH daemon. If Lower Elbonia doesn't n
Re: (Score:3)
Even though in theory, a root PW can't be guessed, I either use SSH keys, or I use a google authenticator PAM library which prompts for a six digit code after the password. This just gives me peace of mind, although if one has a long enough password, in theory, that is good enough...
It is good enough in practice. With massive room to spare if you select reasonably well.
but it means that people can fill your logs up by guessing it.
Huh? Fascinating. I have had several Internet-facing Linux machines for about 20 years now, all with root-login via password and nobody has ever "filled up my logs". In fact, on the system hosting my personal web-server, I have about 250k "Failed password for root" messages in the last 7 days, amounting to a mere 25MB non-compressed or 2.4MB compressed. Now, I only keep 7 days in logs, but since there are really hard lim
Re: (Score:1)
Re: (Score:2)
> sudo mechanism is a lot worse security-wise.
What do you mean by 'security'?
Auditing is far more important than cryptosystems or local exploits.
Breaks in the latter two are guaranteed.
Don't use password auth for SSH! (Score:2)
It's 2023. Password-cracking attacks have been around for decades now.
SHC ? (Score:2)
AFAIK, the SHC (Shell Script Compiler) does not come by default with any distro. So it is a Utility Issue, not a Linux Issue.
My question is why would someone want to use SCH, unless they are trying to hide something. :)
Why are people blaming Linux for this spreading? (Score:2)
Blaming the OS for people's weak passwords is like blaming Abloy because someone left a PROTEC2 deadbolt lock with the key under the mat, or Chubb because someone left the safe in a day lock [howstuffworks.com] state.
As for SHC, I've seen it used, mainly for obfuscation. For example, storing some value for decrypting a database key, but in an obfuscated format. Of course, a secret storage place like Hashicorp Vault or another PAM would be the best, but having heavy obfuscation is better than nothing.
Use port knocking when you can (Score:2)
A good reminder that port knocking can be a great added defense to protecting your ssh servers.