A newly discovered botnet is compromising poorly-protected Linux servers by brute-forcing weak SSH password login authentication.
Researchers at Canada-based Flare Systems, who discovered the botnet, got into its staging server and believe at least 7,000 servers had been compromised by the end of January, half of them in the US.
The botnet’s weapons include exploits for unpatched Linux vulnerabilities going back as far as 2009.
The researchers describe the botnet, dubbed SSHStalker, as “a sophisticated operation that blends 2009-era Internet Relay Chat (IRC) botnet tactics with modern mass-compromise automation.”
It has a “stitched together botnet kit” that executes fileless malware, rootkits, log cleaners and a wide array of kernel exploits. Among other things, it harvests AWS credentials.
The researchers call SSHStalker a “scale-first operation that favors reliability over stealth.”
However, so far the botnet hasn’t done much other than maintaining persistence on infected machines. It has the ability to launch DDoS (distributed denial of service) attacks and conduct cryptomining, but hasn’t done anything yet to monetize its access. That, Flare says, suggests either the operator is still staging the botnet’s infrastructure, is in a testing phase, or is maintaining access for future use.
The good news for CSOs, according to Flare cybersecurity researcher Assaf Morag, is that at this point there’s one way to stop this particular botnet cold: Disable SSH password authentication to Linux machines and replace it with SSH-key based authentication, or hide password logins behind a VPN.
This change should be accompanied by implementation of SSH brute-force rate limiting, monitoring who is trying to access internet-connected Linux servers, and limiting remote access to servers to specific IP ranges.
However, Morag cautioned, right now SSHStalker is looking for Linux servers with weak SSH protection, but at any moment, the operator may add another attack vector, such as an unpatched server vulnerability or misconfiguration.
Security fundamentals are key
Chris Cochran, SANS Institute field CISO and VP of AI security, said SSHStalker is a reminder that security fundamentals still decide the fight.
“Yes, AI is changing the threat landscape. Yes, automation is accelerating attacks. But this campaign proves something simpler and more uncomfortable: Old tricks still work,” he said. “If I’m talking to another CISO today, my advice isn’t ‘buy more AI.’”
CSOs and infosec leaders should use this report as an excuse to finally lock in some of the security basics they’ve always wanted to implement, he said. These include killing the use of passwords for logins. “If you are still allowing password-based SSH access in 2026, you are essentially inviting botnets in for coffee,” Cochran said.
Infosec leaders should either move to key-based authentication, or to solutions with short-lived credentials or identity-aware proxies.
Second, they need to aggressively inventory their IT assets, given the old rule, ‘You cannot protect what you don’t know exists.’
Most of the thousands of systems hit by SSHStalker were forgotten servers, he said.
Third, infosec leaders have to realize the real problem in their environments is security debt: The backlog of unpatched systems, the lingering known vulnerabilities, and the ‘we’ll get to it next quarter’ backlog.
“Those are what get exploited,” he said. “We need to stop chasing the 1% cool threats until we’ve solved the 99% boring ones.”
Dave Lewis, global advisory CISO at 1Password, added that infosec leaders should make sure there are no compilers on production servers, and that build tools are only on designated build hosts. There should be alerts on IRC-like traffic, and, on Linux servers, cron/systemd integrity monitoring, especially for ‘runs every minute’ patterns.
Finally, because SSHStalker looks for older Linux machines, admins should have a legacy Linux eradication plan prioritizing the unhooking of machines with any version of Linux kernel 2.6, because these servers are being targeted.
How it was discovered
Discovery of SSHStalker came after Flare created an SSH honeypot with intentionally weak credentials at the beginning of this year, to see what happened. While the majority of attacks came from known threat actors, there was a distinct cluster from one source with no similar execution flow or prior indicators of compromise.
After getting into a Linux machine, the malware creates a backdoor with its own SSH key to maintain access. It also installs a binary that scans port 22 for servers with unprotected SSH, trying to find other new and vulnerable servers. The payload also contains several C scripts, including the Linux gcc (the GNU Compiler Collection) for compiling and running malware.
This stage is “loud,” Morag said, so defenders should note it can be detected with an application that looks for abnormal server behavior.
Secondary payloads in a zip file include an IRC (internet relay chat) bot for communicating with a command and control server. Other stages install malware that runs in memory.
“This entire execution chain is very loud,” Morag said. “they don’t need to do all of it. I guess what they are trying to do is run on Internet-of-Things [devices], but also on commercial servers.”
It also suggests that the operator is still in the early stage of building the botnet, he said.
But the report also says the IRC components could be used to hide activity, through things like included random chat phrases. “This strongly suggests the bot was configured not only for control, but also for behavioral camouflage,” says the report, by generating human-like noise in IRC channels to obscure real operator activity or to make automated presence appear organic. “This tactic is consistent with legacy botnet operational tradecraft, where blending into public channels reduced suspicion while still allowing operators to issue commands via private messages, DCC (direct client-to client) sessions, or linked bot networks,” the report says.
The malware hunts for older Linux kernels, including versions 2.6.18, 2.6.18-164, 2.6.31, and 2.6.37. This would include roughly up to 3% of internet-facing Linux servers, Flare estimates.
But it could be as much as 10% in what Flare calls long-tail environments like legacy hosting providers, abandoned VPS images, outdated appliances, industrial/OT gear, or niche embedded deployments.
The kernel exploit inventory includes 16 different CVEs, five dating back to 2009 and three to 2010. Judging by the components of the malware, the operator likely understands kernel version fingerprinting, privilege escalation chaining, and mass exploitation workflows, even if they are not developing novel exploits, the report says.
Advice for infosec leaders
In addition to disabling SSH password authentication, the report recommends that infosec leaders:
- set up alerts triggered when non-system processes attempt to modify login accounting records.
- remove compilers from production images if possible;
- allow toolchain execution only in controlled build environments;
- enforce egress filtering based on business need;
- use an anti-virus scanner to pick up binaries dropped by SSHStalker;
- monitor for unauthorized execution of gcc;
- set up alerts when compilers run from user directories, /tmp or /dev/shm;
- set up alerts when newly-compiled binaries execute within seconds or minutes of creation;
- set up alerts on servers to detect communication with unknown external chat or relay infrastructure.