A newly identified botnet is compromising poorly secured Linux servers by brute-forcing weak SSH password logins. Researchers at Flare Systems, based in Canada, uncovered this botnet and accessed its staging server. They estimate that by the end of January, at least 7,000 servers had been compromised, with half located in the United States.
The botnet utilizes exploits for unpatched Linux vulnerabilities dating back to 2009.
Details about SSHStalker
The researchers describe this botnet, named SSHStalker, as “a sophisticated operation that blends 2009-era Internet Relay Chat (IRC) botnet tactics with modern mass-compromise automation.”
SSHStalker is equipped with a “stitched together botnet kit” that executes fileless malware, rootkits, log cleaners, and various kernel exploits. Notably, it also harvests AWS credentials. The researchers characterize SSHStalker as a “scale-first operation that favors reliability over stealth.”
However, so far the botnet has primarily focused on maintaining persistence on infected machines. While it has the capability to launch distributed denial of service (DDoS) attacks and conduct cryptomining, it has not yet monetized its access. Flare suggests this could indicate that the operator is still developing the botnet's infrastructure, is in a testing phase, or is keeping access for future use.
Countermeasures to combat SSHStalker
According to Flare cybersecurity researcher Assaf Morag, there is a straightforward way to stop this botnet: disable SSH password authentication on Linux machines and switch to SSH-key based authentication, or protect password logins behind a VPN. This change should be coupled with implementing SSH brute-force rate limiting, monitoring attempts to access internet-connected Linux servers, and restricting remote access to specific IP ranges.
Morag also warned that, while SSHStalker is currently targeting Linux servers with weak SSH protection, the operator could add another attack vector at any time, such as exploiting an unpatched server vulnerability or configuration error.
Security fundamentals remain essential
Chris Cochran, field CISO and VP of AI security at the SANS Institute, emphasized that SSHStalker serves as a reminder that security fundamentals are crucial. He stated, “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 advised fellow CSOs that the solution is not to simply invest in more AI technology.
Cochran encouraged CSOs and information security leaders to utilize this report as a motivation to finally implement essential security practices, such as eliminating password-based logins. He remarked, “If you are still allowing password-based SSH access in 2026, you are essentially inviting botnets in for coffee.” He advocates for transitioning to key-based authentication or utilizing solutions with short-lived credentials or identity-aware proxies.
Additionally, he stressed the importance of aggressively inventorying IT assets, as the old adage states, “You cannot protect what you don’t know exists.”
Many of the systems affected by SSHStalker were likely forgotten servers. Cochran also pointed out that security debt consisting of unpatched systems, lingering vulnerabilities, and postponed updates poses a significant risk. “Those are what get exploited,” he noted. “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 information security leaders should ensure there are no compilers on production servers, and that build tools are restricted to designated build hosts. Alerts should be set for IRC-like traffic, and integrity monitoring should be implemented for cron/systemd tasks, particularly for patterns that run every minute. Furthermore, because SSHStalker targets older Linux machines, administrators should have a plan in place for phasing out any servers running Linux kernel version 2.6 or earlier.
How SSHStalker was discovered
The discovery of SSHStalker occurred when Flare established an SSH honeypot with intentionally weak credentials at the beginning of the year to observe attack patterns. While most attacks originated from known threat actors, one specific cluster exhibited a unique execution flow and lacked prior indicators of compromise.
Once inside a Linux machine, the malware creates a backdoor using its own SSH key to maintain access. It installs a binary that scans port 22 for servers with unprotected SSH, seeking out additional vulnerable targets. The payload also includes several C scripts, including the Linux gcc (GNU Compiler Collection) for compiling and executing malware.
Morag noted that this stage is “loud,” meaning it can be detected by applications that monitor for abnormal server behavior.
Secondary payloads are packaged in a zip file and contain an IRC bot for communication with a command and control server. Other stages of the malware operate in memory.
Morag emphasized, “This entire execution chain is very loud. 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.” This suggests the operator is still in the early stages of constructing the botnet.
The report indicates that the IRC components could be utilized to conceal activity by employing random chat phrases. “This strongly suggests the bot was configured not only for control but also for behavioral camouflage,” the report states. By generating human-like noise in IRC channels, operators can obscure real activities or create an appearance of organic automated presence. “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 sessions, or linked bot networks,” the report adds.
The malware specifically targets older Linux kernels, including versions 2.6.18, 2.6.18-164, 2.6.31, and 2.6.37. Flare estimates that this could affect approximately 3% of internet-facing Linux servers. However, in long-tail environments, such as legacy hosting providers or outdated appliances, it could be as high as 10%.
The kernel exploit inventory for SSHStalker includes 16 different CVEs, five of which date back to 2009 and three to 2010. The report suggests that the operator possesses knowledge of kernel version fingerprinting, privilege escalation chaining, and mass exploitation workflows, even if they are not creating novel exploits.
Recommendations for infosec leaders
Along with disabling SSH password authentication, the report outlines several recommendations for infosec leaders:
- Establish alerts triggered when non-system processes attempt to modify login accounting records.
- Remove compilers from production images wherever possible.
- Allow toolchain execution only in controlled build environments.
- Enforce egress filtering based on business requirements.
- Utilize an anti-virus scanner to detect binaries introduced by SSHStalker.
- Monitor for unauthorized execution of gcc.
- Set up alerts for compilers running from user directories, /tmp, or /dev/shm.
- Establish alerts for newly-compiled binaries executing shortly after creation.
- Set up alerts on servers to identify communication with unknown external chat or relay infrastructures.
