SSHStalker The return of IRC in the Linux botnets age

Cybersecurity sometimes seems like a temporary loop: techniques and protocols that seemed relegated to the past reappear with new victims. This is precisely the case of the newly documented botnet that researchers have baptized as SSHStalker, a malicious infrastructure for Linux that rests on a classic of Internet communication: IRC, the veteran Internet Relay Chat.

IRC was born in the late 1980s and during the 1990s was the dominant form of textual messaging for private groups and conversations. Even today, technical communities value their simplicity, interoperability and low bandwidth consumption - characteristics that, paradoxically, make it attractive also for malwarts operators who seek robustness and low cost in their control channels. To understand the protocol in its original form, see the historical document. RFC 1459 and an overview of Wikipedia.

The analysis of the Flare intelligence team shows that SSHStalker is not intended to be innovative in stealth techniques; rather, it is committed to scalability and resistance. Instead of modern C2 frameworks, malware deploys multiple C-written bots, relies on redundant IRC servers and channels and uses noisy strategies such as massive SSH scans and programmed tasks every minute to maintain presence. The details of the report are available in the analysis published by Flare Here..

The infection chain begins with a binary written in Go that passes through the nmap network discovery tool; this supplanting makes it easier for the sample to pass unnoticed initially in environments where nmap is usual. After gaining brute force access through SSH, the attacking team uses the committed teams to continue exploring and compromising other servers, a behavior that reminiscent of the dynamics of a worm. For those who want to compare, the official nmap page serves as a reference for legitimate utility: nmap.org.

Once inside, SSHStalker download compilation tools - in particular GCC - to compile your binaries directly into the infected host. This technique provides portability between architectures and can help to evade some signature-based defenses. The first binaries it deploys are IRC C bots, with encrypted C2 servers and channels, and then forces the download of additional packages (called in the find as GS and bootbou) that contain bot variants for orchestration and task execution.

To persist in the compromised systems the botnet uses cron jobs that run every 60 seconds. This mechanism acts as a watchman: it checks that the main process is active and reacts it if it is completed. In parallel, the set includes exploit kits that take advantage of the vulnerabilities of the Linux kernel of the period 2009-2010 to scale privileges when the initial intrusion only gets access as a low-confidence user. The NIST database (NVD) is a good resource to consult details on historical vulnerabilities: nvd.nist.gov.

In terms of monetization and operational capabilities, Flare detected hare of credentials and AWS keys, web scans and the presence of cryptomining kits - including tools known for their performance in Ethedium - as well as modules for DDoS attacks. However, the researchers point out that so far the bots are connected to the C2 and enter a largely inactive state, suggesting that operators could be testing infrastructure or accumulating accesses before putting them into malicious use.

In the telemetry examined by Flare, scans are mostly directed at cloud suppliers, with a visible concentration in Oracle Cloud infrastructure. The team has not conclusively attributed the work to a particular actor, although it notes technical similarities with previous botnet ecosystems and some indicators with possible geographical links.

In the face of such threats, practical recommendations aim to raise the cost of intrusion and reduce the exploitable area. The measures recommended by the specialists include disabling password authentication in SSH and using public keys, removing compilers and production image development tools to prevent on-site compilation, filtering out traffic to block C2 connections (including IRC-type patterns) and restricting execution from spaces like / dev / shm. In addition, it is appropriate to establish detections that alert to installations or executions of compilers on productive servers and to cron jobs with very short cadences created on unusual routes.

Practical and official SSH hardening guides are available in technical reference resources and OpenSSH manuals: OpenSSH Manual and teaching articles from infrastructure providers that detail how to configure key authentication and other measures, for example in DigitalOcean: How To Set Up SSH Keys. For network and output filtering policies, security control recommendations are often found in organizations such as the Center for Internet Security (CIS) and in cloud vendor documentation.

SSHStalker is a reminder that not always wins the one who innovates more technologically, but who optimizes a proven recipe: simple tools, light coding, redundancy and mass automation. For security managers and equipment, the lesson is double: on the one hand, to care for basic hygiene of access and production images; on the other, to implement detections that point to patterns previously considered "noisy" - cron every minute, compilers appearing on servers, outgoing connections to ports and IRC patterns - because that noise today may be the signal of a botnet that is building your army.

If you want to deepen the technical findings and the samples analysed, the Flare report provides a detailed breakdown with indicators for detection and response: Old school IRC, new victims - Flare.