{"id":15784,"date":"2026-02-12T00:55:56","date_gmt":"2026-02-12T00:55:56","guid":{"rendered":"https:\/\/newestek.com\/?p=15784"},"modified":"2026-02-12T00:55:56","modified_gmt":"2026-02-12T00:55:56","slug":"sshstalker-botnet-brute-forces-its-way-onto-7000-linux-machines","status":"publish","type":"post","link":"https:\/\/newestek.com\/?p=15784","title":{"rendered":"SSHStalker botnet brute-forces its way onto 7,000 Linux machines"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/div>\n<\/section>\n

A newly discovered botnet is compromising poorly-protected Linux servers by brute-forcing weak SSH password login authentication.<\/p>\n

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.<\/p>\n

The botnet\u2019s weapons include exploits for unpatched Linux vulnerabilities going back as far as 2009.<\/p>\n

The researchers describe the botnet<\/a>, dubbed SSHStalker, as \u201ca sophisticated operation that blends 2009-era Internet Relay Chat (IRC) botnet tactics with modern mass-compromise automation.\u201d<\/p>\n

It has a \u201cstitched together botnet<\/a> kit\u201d that executes fileless malware, rootkits, log cleaners and a wide array of kernel exploits. Among other things, it harvests AWS credentials.<\/p>\n

The researchers call SSHStalker a\u00a0\u201cscale-first operation that favors reliability over stealth.\u201d<\/p>\n

However, so far the botnet<\/a> hasn\u2019t 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\u2019t done anything yet to monetize its access. That, Flare says, suggests either the operator is still staging the botnet\u2019s infrastructure, is in a testing phase, or is maintaining access for future use.<\/p>\n

The good news for CSOs, according to Flare cybersecurity researcher Assaf Morag<\/a>, is that at this point there\u2019s 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Security fundamentals are key<\/h2>\n

Chris Cochran<\/a>, SANS Institute field CISO and VP of AI security, said SSHStalker is a reminder that security fundamentals still decide the fight<\/a>.\u00a0<\/p>\n

\u201cYes, AI is changing the threat landscape. Yes, automation is accelerating attacks. But this campaign proves something simpler and more uncomfortable: Old tricks still work,\u201d he said. \u201cIf I\u2019m talking to another CISO today, my advice isn\u2019t \u2018buy more AI.\u2019\u201d<\/p>\n

CSOs and infosec leaders should use this report as an excuse to finally lock in some of the security basics they\u2019ve always wanted to implement, he said. These include killing the use of passwords for logins. \u201cIf you are still allowing password-based SSH access in 2026, you are essentially inviting botnets in for coffee,\u201d Cochran said.<\/p>\n

Infosec leaders should either move to key-based authentication, or to solutions with short-lived credentials or identity-aware proxies.<\/p>\n

Second, they need to aggressively inventory their IT assets, given the old rule, \u2018You cannot protect what you don\u2019t know exists.\u2019<\/p>\n

Most of the thousands of systems hit by SSHStalker were forgotten servers, he said.<\/p>\n

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 \u2018we\u2019ll get to it next quarter\u2019 backlog.<\/p>\n

\u201cThose are what get exploited,\u201d he said. \u201cWe need to stop chasing the 1% cool threats until we\u2019ve solved the 99% boring ones.\u201d<\/p>\n

Dave Lewis<\/a>, 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<\/em> integrity monitoring, especially for \u2018runs every minute\u2019 patterns.<\/p>\n

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.<\/p>\n

How it was discovered<\/h2>\n

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.<\/p>\n

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\u00a0Linux gcc (the GNU Compiler Collection) for compiling and running malware.<\/p>\n

This stage is \u201cloud,\u201d Morag said, so defenders should note it can be detected with an application that looks for abnormal server behavior.<\/p>\n

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.<\/p>\n

\u201cThis entire execution chain is very loud,\u201d Morag said. \u201cthey don\u2019t 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.\u201d<\/p>\n

It also suggests that the operator is still in the early stage of building the botnet, he said.<\/p>\n

But the report also says the IRC components could be used to hide activity, through things like included random chat phrases. \u201cThis strongly suggests the bot was configured not only for control, but also for behavioral camouflage,\u201d says the report, by generating human-like noise in IRC channels to obscure real operator activity or to make automated presence appear organic. \u201cThis 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,\u201d the report says.<\/p>\n

The malware hunts for older Linux kernels, including versions 2.6.18, 2.6.18-164, 2.6.31, and 2.6.37.\u00a0This would include roughly up to 3% of internet-facing Linux servers, Flare estimates.<\/p>\n

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.<\/p>\n

The kernel exploit inventory includes 16 different CVEs, five dating back to 2009 and three to 2010. Judging by the components of the malware,\u00a0the operator likely understands kernel version fingerprinting, privilege escalation chaining, and mass exploitation workflows, even if they are not developing novel exploits, the report says.\u00a0<\/p>\n

Advice for infosec leaders<\/h2>\n

In addition to disabling SSH password authentication, the report recommends that infosec leaders:<\/p>\n