A newly documented Linux botnet dubbed SSHStalker is actively targeting cloud infrastructure, with a particular focus on Oracle Cloud instances. The campaign combines large-scale SSH credential brute-forcing, worm-like self-propagation and exploitation of outdated Linux kernel vulnerabilities to gain root access and establish a resilient foothold on compromised servers.
New SSHStalker Linux botnet focuses on cloud servers and Oracle Cloud
According to research by Flare, SSHStalker is optimized for internet-exposed Linux servers in cloud environments. Cloud instances offer attractive characteristics for threat actors: reliable uptime, strong network bandwidth and often weaker controls on outbound traffic. Targeting Oracle Cloud is notable because organizations may assume major cloud platforms are inherently hardened, while misconfigurations at the customer level still create significant attack surface.
The SSHStalker operators appear to prioritize breadth of compromise over stealth during the initial intrusion stage. Evidence collected by researchers includes a file containing results of nearly 7,000 SSH scans performed in January 2026 alone, indicating an aggressive, continuous discovery process aimed at finding new, poorly protected hosts.
Attack chain: SSH brute-force and worm-like lateral spread
The intrusion begins with mass SSH scanning and automated password guessing. SSHStalker relies on a Go-based binary that is deliberately named and presented to resemble the widely used network scanner nmap. This masquerading strategy helps avoid immediate suspicion from administrators and monitoring tools that may whitelist or overlook processes with familiar names.
Once valid SSH credentials are found and a server is compromised, that host is immediately repurposed as an additional scanning and attack node. Each infected machine contributes to the ongoing brute-force campaign, creating a worm-like propagation model where the botnet grows organically as new victims join the scanning effort.
Privilege escalation via legacy Linux kernel vulnerabilities
If SSHStalker gains access to a non-privileged account, it attempts to escalate privileges to root using a toolkit of exploits targeting at least 16 known Linux kernel vulnerabilities dating back to approximately 2009–2010. These issues are long patched in supported distributions, but still appear in:
• poorly maintained legacy servers
• internal or lab systems never properly decommissioned
• outdated test environments accidentally exposed to the internet
By chaining credential compromise with kernel exploitation, attackers obtain full control of the operating system. This level of access enables them to hide malware components, manipulate logs and deploy additional payloads without interference from local security controls.
Botnet architecture, GCC-based build process and persistence
A distinctive feature of SSHStalker is its use of the victim’s own environment to build malware binaries. After infection, the botnet downloads and installs the GCC compiler on the host, then compiles its malicious payloads locally. This on-host compilation approach reduces the effectiveness of static signature-based detection, as each compiled binary can differ slightly from others in the campaign.
The primary payloads are C-based IRC bots with hard-coded command-and-control (C2) servers and channels. These IRC connections form the control backbone of the botnet, allowing operators to issue commands, update payloads and coordinate large-scale activities across infected nodes.
SSHStalker then retrieves additional archives named GS and bootbou, which contain different bot variants responsible for orchestrating task sequences and command execution on compromised systems. This layered architecture supports flexible tasking and easier updates as the campaign evolves.
Persistence is achieved via cron-based watchdog jobs. A scheduled task running roughly every 60 seconds checks whether the main bot process is active and restarts it if needed. This mechanism allows the botnet to survive process crashes, partial cleanups and some basic administrative remediation attempts.
Monetization: cryptomining, AWS key theft and dormant DDoS capabilities
Analysis of SSHStalker components shows several monetization and abuse vectors typical of modern Linux botnets. Compromised cloud servers are used to harvest AWS keys and other credentials, scan websites for further vulnerabilities and deploy cryptomining malware to exploit available CPU and GPU resources.
Among the observed payloads is PhoenixMiner, a high-performance Ethereum miner. The use of industrial-grade mining software aligns with trends seen in other campaigns such as Kinsing and similar cryptojacking operations, where attackers attempt to silently consume as much compute power as possible before detection.
Additionally, SSHStalker code includes functionality to conduct distributed denial-of-service (DDoS) attacks via the botnet. During the documented observation period, these DDoS features remained inactive, with infected bots connecting to C2 servers but largely staying in a standby state. This suggests either a testing phase or preparation for potential future disruption-focused operations.
Detection strategies and hardening recommendations for Linux and cloud environments
Organizations running Linux in the cloud or on-premises can detect SSHStalker-like activity by monitoring for several key anomalies:
- Unexpected installation or execution of compilers (e.g., GCC) on production servers, where build tools are normally not required.
- Unusual outbound connections to IRC-style infrastructure, especially to non-standard ports or low-reputation domains and IP ranges.
- High-frequency cron jobs (around every 60 seconds) originating from atypical paths, such as temporary directories or user-owned folders.
Recommended preventive measures include:
- Disable password-based SSH authentication and enforce key-based access, combined with rate limiting and fail2ban-style protections where appropriate.
- Remove compilers and development tools from production images and restrict package installation to a controlled configuration management process.
- Implement strict egress filtering for outbound traffic from servers, blocking unnecessary protocols such as IRC and restricting internet access for non-essential workloads.
- Mount temporary directories with no-exec options (e.g., /dev/shm), reducing the ability of malware to execute from these locations.
- Regularly update and consolidate Linux kernels, phasing out unsupported or legacy versions, particularly on any system accessible via SSH from the internet.
SSHStalker underscores that old vulnerabilities and basic configuration mistakes—such as weak SSH passwords and unpatched kernels—remain highly effective for attackers, especially against cloud-hosted Linux servers. Systematic hardening of SSH access, removal of unnecessary tools, strict outbound traffic controls and continuous monitoring for behavioral anomalies form a practical roadmap to reduce the risk of joining the next Linux botnet. Organizations that treat cloud instances with the same rigor as traditional critical infrastructure will be far better positioned to withstand this and future botnet campaigns.
