In early 2026, cybersecurity researchers uncovered a stealthy Linux botnet operation that has infected nearly 7,000 servers worldwide — not with advanced AI or zero-day exploits — but by resurrecting old-school techniques: SSH brute-force compromise, decade-old Linux vulnerabilities, and text-based IRC (Internet Relay Chat) command-and-control (C2) communication.
Dubbed SSHStalker, this campaign staggering in scale highlights a sobering reality: many modern systems remain vulnerable to attacks that have been well-documented for years, simply because basic security hygiene is still not universally applied.
Here’s an in-depth look at SSHStalker — how it was discovered, how it operates, the vulnerabilities it exploits, its architecture and persistence mechanisms, and most importantly how organizations can defend against it and avoid similar threats in the future.
How SSHStalker was discovered?
The first clues that something unusual was happening came from SSH honeypots — servers deliberately deployed with weak credentials to attract unauthorized access attempts. Over the course of two months of monitoring, researchers began capturing repeated infection attempts that did not match known malware or botnet signatures in public threat intelligence databases.
What made these intrusions stand out was a combination of:
- Automated SSH scanning and brute-force credential attempts
- Downloads of unusual malware binaries
- Outbound connections to IRC servers rather than modern C2 protocols
By correlating these activity patterns with other security telemetry, researchers concluded that this was a previously undocumented botnet operation, now named SSHStalker — a scale-focused botnet that mixes decades-old malware tradecraft with modern automation tools.
A closer look: How SSHStalker operates
SSHStalker isn’t a single one-trick pony, it’s operation unfolds in several stages, each combining old-school and modern elements.
1. Initial Reconnaissance: Scanning and Brute-Forced SSH Access
The botnet begins with unrelenting scanning.
A binary disguised as “nmap”, but actually written in Go, is deployed on infected systems. This scanner probes the internet for open SSH ports (TCP 22) and attempts to log in using:
- Weak or default credentials
- Common username/password combinations
- Dictionary-based brute force lists
Because many administrators still allow SSH access directly from the internet, these brute-force attempts successfully gain entry on a large number of servers.
Once access is gained via SSH, the malware steps through the next stages.
2. Pulling Down Tools and Compilers
After gaining SSH access, one of the first actions the malware takes is to download the GCC compiler to the compromised machine. This step — unusual in many modern botnets — demonstrates an intentional strategy: compile code on the host itself, ensuring compatibility across diverse Linux distributions, architectures, and library versions.
Once the compiler is present, the botnet pulls multiple source code files and:
- Compiles them into IRC bots
- Compiles persistence helpers
- Compiles privilege-escalation and rootkit modules
This on-host compilation process makes detection and analysis more challenging because it avoids storing complete binaries on disk until they’re compiled and run, and it allows the malware to adapt to the exact environment it has compromised.
3. Deploying Multiple Bot Variants
SSHStalker’s payload is not a single binary — it’s a layered toolkit. According to the Flare’s research team, the malware deploys:
- Two distinct C-based IRC bots
- A Perl bot component that connects to IRC
- Utility scripts for system modification
- Cleaning and log tampering programs
- Persistence helpers that restart the malware if it’s terminated
Files extracted from the botnet reveal an arsenal of artifacts:
- IRC bots with hard-coded server and channel information
- Rootkit modules and privilege escalation helpers
- Log cleaners that scrub system logs
- Shell scripts that adjust execution based on Linux distribution
- A cron-based persistence mechanism that runs every minute
This layered design means each infected machine becomes both a scanner and a potential C2 endpoint. The inclusion of log-cleaning utilities suggests the malware attempts to make forensic investigation harder.
Description: SSHStalker’s attack flow, Source: flare.io
Command-and-Control: Why IRC?
One of the most striking aspects of SSHStalker is its C2 architecture. Instead of modern encrypted HTTP/S sessions, domain-registered C2 servers, or peer-to-peer overlays, its control structure is based on Internet Relay Chat (IRC) — a protocol invented in the late 1980s for real-time text chat.
It uses:
- Multiple IRC servers and channels
- Hard-coded networks and channel keys
- IRC bots that join specified channels and await commands
IRC’s advantages for threat actors include:
- Minimal infrastructure cost
- Ease of use
- Ability to blend with legitimate IRC traffic
- Flexibility to issue commands across large numbers of bots
Though considered “vintage,” IRC remains effective for C2, especially in environments where outbound filtering is lax or monitoring is focused only on modern C2 patterns.
Persistence and Resilience
SSHStalker doesn’t rely on subtle persistence techniques. Instead, it favors a simple but effective cron-based watchdog model.
A cron job is installed to run every minute, executing a watchdog script that:
- Checks if the main bot process is running
- If not, relaunches it silently
- Continues indefinitely
This ensures that even if a defender kills the malware process, it reappears within seconds — giving defenders only a narrow window to disrupt execution before it restarts.
A Massive Toolkit of Legacy Linux Exploits
Contrary to many modern botnets that rely on a couple of vectors, SSHStalker comes equipped with a large library of old Linux kernel exploits — at least 16 distinct CVEs dating back to 2009 and 2010. These include remote denial-of-service and local privilege escalation vulnerabilities that, while unimpactful against updated servers, remain devastating on legacy and unpatched systems.
Some of the kernel vulnerabilities exploited include:
- CVE-2009-2692 (sock_sendpage NULL pointer deref) present as both linux-sendpage.c (“Linux kernel exploit”) and simple.c (“Linux exploit”).
- CVE-2009-2698 (udp_sendmsg) present as udp_sendmsg.c (“Linux kernel exploit”).
- CVE-2010-3849 present as full-nelson.c, described as “Local root for Linux <= 2.6.37 (x86/x64)”.
- CVE-2010-1173 present as sctp-boom.py, explicitly a remote DoS against Linux Kernel <= 2.6.33.3 (SCTP INIT crash).
- Additional CVEs appear inside the exploit module set (e.g., CVE-2009-2267, CVE-2009-2908, CVE-2009-3547, CVE-2010-2959, CVE-2010-3437, and others), with many tracked as “Linux exploit” modules even when the sheet doesn’t include a full one-line description for each.
Kernel targeting in the dataset clusters around older enterprise-era Linux:
- Explicit kernel/version references and/or builds for 2.6.18, 2.6.18-164, 2.6.31, and 2.6.37.
- The kit includes exploit modules named for 2.6.31 (e.g., exp_2.6.31-2010.c, plus exp_ingom0wnar.c and exp_powerglove.c as “Linux exploit”),
- and a clearly scoped “works up to” boundary via full-nelson.c (<= 2.6.37).
These exploits, while obsolete for modern Linux distributions receiving regular updates, still work on long-neglected environments such as:
- Legacy enterprise servers
- Unmaintained cloud VMs
- Abandoned or forgotten virtual appliances
- Industrial or embedded Linux systems
SSHStalker’s inclusion of kernel exploits of this vintage shows an understanding that not all infrastructure is kept up to date — and that even low-skill attackers can launch widespread campaigns using publicly available exploit code.
What SSHStalker Does Once It’s In
The core purpose of SSHStalker isn’t immediately monetization through ransomware or data theft; rather its observed behavior so far suggests the botnet’s purpose is persistence and expansion.
At the moment, researchers have NOT observed active DDoS campaigns or large cryptomining — though the toolkit includes support for:
- DDoS flooding routines via IRC bots
- Cryptocurrency mining software like PhoenixMiner
- Tools for harvesting AWS credentials and exposed secrets from websites
This suggests a couple of possibilities:
- The botnet is still in its propagation phase
- operators may be accumulating access for future monetization
- The infrastructure may serve multiple purposes in the future
Regardless of motive, the combination of aggressive scanning, persistence, and rootkit-like components makes SSHStalker a serious threat to unmanaged Linux environments.
Why SSHStalker has been able to spread so broadly?
The success of SSHStalker comes down to one uncomfortable truth:
Many modern Linux deployments still lack even the most basic protections.
Despite decades of warnings about SSH hardening and patching, many servers:
- Allow password authentication instead of SSH key-only access
- Permit direct internet exposure to SSH
- Don’t enforce strong passwords
- Don’t use multi-factor authentication
- Haven’t been updated for years or even decades
These security gaps create fertile ground for a botnet that requires nothing more sophisticated than brute-force access and legacy exploit chains.
How to detect SSHStalker infections?
Here are signs your systems may be compromised:
- Unexpected outbound IRC connections
- Cron entries scheduled to run every minute invoking unknown scripts
- Unusual processes running under typical system accounts
- Compilers (e.g., GCC) installed unexpectedly on production systems
- SSH logs showing repeated failed logins followed by successful ones
- Altered or missing log entries (because of log cleaners)
- Roots or unknown accounts added to your system
Checking for these behaviors across your fleet can help identify early infections.
Mitigation and Defense: What works?
Defending against SSHStalker and future similar threats starts with basic hygiene but requires a layered approach.
1. Harden SSH Access
SSH remains the most common initial entry point:
- Disable password authentication entirely
- Use only SSH key-based authentication
- Disable direct root login
- Use multi-factor authentication
- Rate-limit login attempts
- Consider non-default SSH ports (defense-in-depth)
2. Patch and Update Systems Regularly
If your Linux kernel and userspace packages are not maintained, you remain vulnerable to old exploit code. Regular automated patching reduces the likelihood of compromise.
3. Restrict SSH Exposure
Ideally, SSH should not be exposed publicly:
- Use Modern Centralized Access Management Solutions like Ezeelogin
- Implement firewall rules to allow access only from known IPs
- Use zero-trust access models
4. Monitor Outbound Traffic and Cron Jobs
Unusual IRC or any unknown outbound connections should trigger alerts. Similarly, cron jobs running every minute are abnormal on most production systems unless explicitly configured.
5. Limit Compilers in Production
Seeing a compiler like GCC suddenly on a server that shouldn’t need it is a strong anomaly. Restrict compilers or use filesystem controls where possible.
6. Use Endpoint Monitoring and Response
Standard signature-based antivirus won’t catch everything. Behavioral monitoring and EDR solutions that track process and network anomalies improve detection.
Lessons Learned: Old Threats Never Truly Die
SSHStalker proves that the cyber threats least discussed can sometimes be the most effective. The botnet doesn’t innovate — it leans on:
- SSH brute force
- Outdated exploits
- IRC C2
- Cron persistence
Yet it still manages to compromise thousands of systems because basic defenses are often missing.
In cybersecurity, the biggest gaps are rarely technical depth, they’re operational failures in patching, access control, monitoring, and hygiene.
Until those gaps are closed, even “vintage” attack techniques remain dangerous.
- Tags:
- sshstalker