Vi ricordate IRC? Acronimo di Internet Relay Chat, è una tecnologia nata nel 1988 che ha reso popolare la messaggistica istantanea testuale negli anni ’90. Nonostante si tratti di una tecnologia decisamente “vintage”, il protocollo rimane apprezzato per la sua semplicità, leggerezza e capacità di gestire chat di gruppo senza interfacce complicate. Proprio IRC viene oggi sfruttato da una nuova botnet Linux chiamata SSHStalker, che utilizza questa infrastruttura per controllare migliaia di dispositivi compromessi in modo scalabile ed economico.
La botnet è stata analizzata dai ricercatori della società di threat intelligence Flare. Il suo approccio operativo privilegia la resilienza, la scalabilità e il contenimento dei costi, piuttosto che la sofisticazione tecnica. La botnet si basa su bot multipli scritti in C e su server IRC ridondanti, integrando tecniche automatizzate di compromissione di massa. Secondo Flare, si tratta di un’operazione “scale-first”, pensata per massimizzare l’affidabilità piuttosto che la furtività.
Modalità di infezione e architettura della botnet
L’accesso iniziale alla rete di SSHStalker avviene tramite scansioni SSH automatizzate e attacchi brute force, condotti con un eseguibile scritto in Go che si maschera da nmap, la nota utility open-source per la scoperta di reti. I sistemi compromessi diventano a loro volta strumenti per scansionare altri target SSH, creando un meccanismo di propagazione simile a quello di un worm.
Secondo Flare, un’analisi dei log di quasi 7.000 scansioni bot effettuate nel solo gennaio 2026 mostra che gli attacchi sono stati concentrati soprattutto su provider di hosting cloud, in particolare all’interno dell’infrastruttura Oracle Cloud. Una volta compromesso un host, SSHStalker scarica GCC per compilare i payload direttamente sul dispositivo della vittima, migliorando così portabilità ed evasione.
I primi payload distribuiti sono bot IRC scritti in C, con server e canali di comando già preconfigurati, che integrano automaticamente la nuova vittima nell’infrastruttura IRC della botnet. Successivamente, il malware recupera archivi denominati GS e bootbou, contenenti varianti di bot utilizzate per orchestrare e sequenziare l’esecuzione delle operazioni.
La persistenza dei bot è assicurata tramite cron job eseguiti ogni 60 secondi, che implementano un meccanismo di watchdog: se il processo principale viene interrotto, viene automaticamente rilanciato. La botnet sfrutta inoltre exploit per 16 CVE che prendono di mira versioni del kernel Linux datate 2009-2010, impiegati per l’escalation dei privilegi dopo la fase di brute forcing.
Capacità e obiettivi della botnet
Per quanto riguarda la monetizzazione, la botnet esegue raccolta di chiavi AWS e scansione di siti web. Include inoltre kit di cryptomining come PhoenixMiner, un miner Ethereum ad alte prestazioni. Sono presenti anche capacità di attacchi DDoS (distributed denial-of-service), sebbene i ricercatori non abbiano ancora osservato attacchi di questo tipo.
Attualmente i bot di SSHStalker si limitano a connettersi al C2 e rimanere in stato idle, suggerendo una fase di testing o accumulo di accessi per utilizzi futuri. Questo comportamento dormiente distingue SSHStalker da tipiche operazioni botnet opportunistiche e suggerisce staging dell’infrastruttura, fasi di testing o ritenzione strategica degli accessi.
Attribuzione e somiglianze con altre campagne
Flare non ha attribuito SSHStalker a un gruppo di minaccia specifico, ma ha notato somiglianze con l’ecosistema delle botnet Outlaw/Maxlas e vari indicatori rumeni. Il malware Outlaw è noto per utilizzare attacchi brute-force SSH, cryptomining tramite XMRig e bot IRC per il controllo remoto.
L’infrastruttura IRC di SSHStalker appare ospitata su quella che sembra essere una rete IRC pubblica legittima, suggerendo un’infrastruttura dormiente o l’uso di ecosistemi IRC reali per mimetizzare le operazioni malevole nel traffico normale della piattaforma. Il protocollo IRC rimane apprezzato dalle comunità tecniche per la semplicità di implementazione, l’interoperabilità, i bassi requisiti di banda e l’assenza di necessità di una GUI.
Raccomandazioni per la mitigazione
I ricercatori di Flare suggeriscono di implementare soluzioni di monitoraggio per l’installazione e l’esecuzione di compiler sui server di produzione, oltre ad alert per connessioni in uscita in stile IRC. Anche i cron job con cicli di esecuzione brevi da percorsi insoliti rappresentano segnali d’allerta significativi.
Le raccomandazioni di mitigazione includono la disabilitazione dell’autenticazione SSH tramite password, la rimozione dei compiler dalle immagini di produzione, l’implementazione del filtraggio in uscita e la restrizione dell’esecuzione dalla directory /dev/shm. Il monitoraggio di binari compilati di recente che vengono eseguiti entro secondi o minuti dalla creazione può aiutare a rilevare l’attività di SSHStalker.