SSHStalker: la botnet Linux che riporta l’IRC nel cloud e punta alla persistenza

SSHStalker sembra una contraddizione vivente: una botnet che usa un backbone IRC in stile 2009, ma lo applica a infrastrutture moderne, spesso esposte su Internet e distribuite nel cloud. La novità non sta nella “finezza” del malware, perché i ricercatori la descrivono come un’operazione rumorosa ma efficace, quanto nella disciplina operativa: compromette, installa, si lega a un canale di controllo, poi rimane dormiente. Niente DDoS immediati, niente cryptomining come default. L’obiettivo dichiarato dal comportamento è un altro: retenzione, accumulo, disponibilità futura. Il quadro emerge da un honeypot SSH che, dall’inizio del 2026, intercetta ripetuti tentativi di intrusione e permette di ricostruire un flusso coerente. Il dato che pesa, per chi difende, è che questa botnet si muove come un kit modulare: scanner, dropper, tool di compilazione on-host, bot IRC, pulitori di log, persistenza tramite cron e, quando serve, un arsenale di exploit “vecchi” per sbloccare privilegi su sistemi dimenticati. La minaccia non vive di invisibilità assoluta, vive di inerzia operativa: gira dove nessuno guarda e rimane dove nessuno manutiene.

SSHStalker come “botnet da accumulo”: perché l’assenza di monetizzazione è un segnale

La maggior parte dei compromessi Linux su larga scala oggi segue un copione prevedibile: entra, mina, fa DDoS, monetizza. SSHStalker si distingue perché privilegia affidabilità e scalabilità rispetto alla monetizzazione immediata. Questo non rende l’operazione meno pericolosa, la rende più ambigua e quindi più difficile da classificare per le difese “a regole semplici”.

Una botnet che rimane in attesa ha due vantaggi strutturali. Il primo è tecnico: riduce il rumore e la probabilità di essere notata da chi guarda solo ai picchi di CPU, alla saturazione rete o ai processi miner. Il secondo è strategico: prepara una base pronta per essere attivata in blocco, venduta, noleggiata o utilizzata in campagne successive. In altre parole, il valore non è il singolo server compromesso, è il parco macchine “tenuto caldo” tramite persistenza. La presenza di componenti che appaiono ereditati o ispirati a playbook come Outlaw/Maxlas, senza attribuzione diretta, rafforza l’idea di un attore mid-tier che privilegia strumenti collaudati. Non serve inventare una nuova tecnica se l’obiettivo è conquistare il long-tail dei server Linux esposti e lasciati a se stessi.

Il ritorno dell’IRC come C2: basso costo, ridondanza e resilienza sociale

Il cuore concettuale di SSHStalker è l’uso di IRC come ossatura di comando e controllo. A prima vista sembra archeologia digitale, ma è una scelta razionale se l’obiettivo è ottenere un C2 economico e resistente. IRC offre canali, nick, join, gerarchie, messaggi: è un linguaggio operativo che permette di orchestrare bot in modo semplice, con ridondanza multi-server e multi-canale.

Il dettaglio che cambia la lettura è la capacità di “mimetismo sociale”. Un C2 su infrastruttura dedicata è un oggetto osservabile. Un C2 che si appoggia a reti IRC pubbliche o semi-pubbliche può confondere traffico e contesto, perché l’IRC esiste davvero, è rumoroso per natura e, in certi ambienti, non è un’anomalia totale. La botnet, in questo modello, non si nasconde nel silenzio: si nasconde nel rumore. Nel toolkit compaiono riferimenti a framework di gestione bot in stile EnergyMech, un vecchio ma efficace strato di orchestrazione con comandi remoti e gestione utenti/canali. È un esempio perfetto di “vecchio e nuovo”: tecnologia datata, utilità attuale. Il costo di gestione si abbassa e la resilienza aumenta, perché l’infrastruttura può cambiare server e canale con rapidità, mantenendo la stessa logica di controllo.

Compromissione: brute force SSH e scanner mascherati da nmap

La porta d’ingresso principale è la più banale e quindi la più comune: SSH. La ricerca descrive una pipeline automatizzata che combina scanner e compromissione di massa, con un componente in Golang mascherato da nmap per ridurre sospetti superficiali. Il concetto operativo è semplice: enumerare in scala, tentare accesso, e quando si entra, avviare subito lo staging.

Il mascheramento “nmap” non è un trucco sofisticato, è un trucco sufficiente. In molti server di produzione, soprattutto nel cloud, la presenza di un binario chiamato nmap non è di per sé impossibile. Il punto non è ingannare un blue team maturo, è passare su macchine dove il controllo è saltuario, i log non vengono letti e la posture di hardening è incompleta. Il dato che resta in testa è la dimensione dell’operazione: vengono citati 7.000 SSH compromessi registrati in un periodo preciso, con una concentrazione su infrastrutture cloud. Anche senza trattare quel numero come verità assoluta universale, il messaggio operativo è chiaro: la botnet non vive di colpi mirati, vive di produzione industriale.

Compilazione on-host: perché GCC su un server di produzione diventa un campanello d’allarme

Una delle scelte più interessanti di SSHStalker è l’installazione e l’uso di toolchain come GCC direttamente sulla macchina compromessa. Il vantaggio per l’attaccante è duplice: compatibilità e adattamento. Compilare on-host significa generare binari allineati all’ambiente, riducendo problemi di architettura e dipendenze, e permettendo un approccio cross-platform più naturale, includendo target come ARM, x86 e MIPS. Per i difensori, questo crea un indicatore “comportamentale” potente: in molti ambienti moderni, soprattutto quelli containerizzati o minimalisti, la presenza di un compilatore in produzione non è necessaria. Quando compare, spesso è perché qualcuno lo ha installato per un motivo. E quel motivo, in contesti esposti, può essere l’attacco. Il pattern descritto è coerente: drop di un file mascherato, installazione tool, compilazione rapida di sorgenti con nomi generici come 1.c e 2.c, esecuzione immediata e chaining verso archivi compressi che contengono ulteriori moduli. È una catena “da officina”, non da laboratorio: funziona, scala, richiede poca interazione manuale.

Persistenza: cron ogni minuto e watchdog che rianima i processi in 60 secondi

Se la backbone IRC è il sistema nervoso, la persistenza è il sistema circolatorio. SSHStalker usa una persistenza cron-based estremamente aggressiva: un job che gira ogni minuto e richiama uno script di update/watchdog. L’obiettivo è rendere irrilevante l’azione difensiva più comune e più veloce: uccidere un processo. Con un watchdog che verifica PID e rilancia il payload entro 60 secondi, il difensore entra in una guerra di attrito. Se la rimozione non è completa, il sistema si auto-ripara dal punto di vista dell’attaccante. Ed è qui che la botnet sembra “poco stealth” ma molto efficace: non tenta di essere invisibile, tenta di essere inevitabile. Un’altra scelta funzionale è l’uso di directory memory-backed come /dev/shm o tmpfs per ridurre la footprint su disco e complicare la risposta basata su scanning statico. Non è fileless nel senso assoluto, ma è fileless nel senso operativo: vive dove i controlli sono più deboli e dove la persistenza può essere rapida.

Pulizia log e artefatti rootkit-class: la difesa non deve aspettarsi “solo bot”

SSHStalker integra pulitori che alterano file come utmp, wtmp e lastlog, cioè i registri che raccontano accessi e sessioni. È un elemento che cambia la risposta incident: chi si limita a controllare “chi ha fatto login” rischia di leggere una storia riscritta. Qui la botnet non si limita a controllare la macchina, tenta di controllare la narrativa. Nel toolkit vengono menzionati artefatti rootkit-class e moduli progettati per mascherare processi, talvolta camuffati come -bash o come servizi di sistema (ad esempio “crond”). Non serve che il rootkit sia rivoluzionario: basta che riduca visibilità e renda più costosa la triage. E quando la botnet è pensata per scala, ogni minuto guadagnato su ogni host vale moltissimo.

Exploit legacy e kernel 2.6.x: la botnet vive sulle infrastrutture dimenticate

La parte “storica” dell’arsenale è anche la più attuale: un catalogo di exploit per kernel Linux 2.6.x datati 2009–2010, con riferimenti a vulnerabilità note e a exploit come Full Nelson. Questo punto va letto con freddezza: non è un segnale di debolezza dell’attaccante, è un segnale di debolezza del parco installato. La botnet non ha bisogno di zero-day se esiste una quota di sistemi ancora esposti con kernel legacy, VPS abbandonati, appliance non aggiornate, ambienti OT o long-tail che nessuno patcha perché “funziona”. SSHStalker costruisce un ponte tra due mondi: l’Internet moderna e il software dimenticato. E quel ponte regge perché il debito tecnico è reale. In questa logica, gli exploit non sono necessariamente il primo passo, sono una leva per l’upgrade dell’accesso: se entri via SSH con credenziali deboli hai già un foothold; gli exploit diventano lo strumento per ottenere privilegi, stabilizzare, installare rootkit, estendere capacità e rendere l’host “affidabile” per l’uso futuro.

Cloud targeting e concentrazione su provider: perché il dato “Oracle Cloud” è un campanello operativo

La ricerca cita una concentrazione di target in ambienti cloud e, in particolare, in un provider specifico. Il punto non è colpevolizzare il provider, ma capire il meccanismo: il cloud crea una superficie uniforme e ripetibile. Molti utenti usano immagini simili, configurazioni simili, posture simili, e la botnet industriale vive di ripetizione. Se una parte significativa dei target compromessi finisce su un provider, spesso significa che lì esiste una combinazione di esposizione, credenziali deboli, servizi pubblici e automazione. È esattamente il terreno dove una pipeline di brute force e installazione rapida diventa redditizia. Per chi gestisce flotte nel cloud, questo si traduce in una priorità: ridurre l’esposizione di SSH, limitare tentativi, imporre chiavi, ridurre toolchain e fissare egress.

IOC e impronta tecnica: cosa guardare quando l’attaccante punta su “affidabilità”

In un caso come questo, l’errore comune è cercare “il singolo file malevolo” e dimenticare che la botnet è una catena. Il segnale più utile è spesso comportamentale: connessioni outbound long-lived verso endpoint IRC, processi che mantengono socket persistenti, comandi tipici dell’IRC come NICK, USER, JOIN, e soprattutto la comparsa di cron job con frequenza innaturale e path sospetti.

Elenco completo degli Indicatori di Compromissione (IoC) analizzati, inclusi hash MD5 dei file binari (Rootkit Prochider, Bot IRC) e indirizzi IP di comando e controllo.

Un’altra area critica è l’accesso ai file di log di login e la loro modifica. L’attaccante che pulisce utmp e wtmp sta dicendo una cosa: si aspetta che qualcuno arrivi, ma vuole che arrivi tardi e con meno visibilità. Questo è un indicatore di maturità operativa più importante della scelta “vecchia” dell’IRC.

Mitigazione e hardening: cosa cambia davvero la probabilità di compromesso

La difesa efficace contro botnet SSH non nasce da un singolo blocco, nasce da una sequenza di decisioni che riducono la superficie e aumentano i costi dell’attaccante. Se l’autenticazione password rimane attiva, la pipeline di brute force resta economicamente sostenibile. Se la key-based diventa obbligatoria e l’accesso è ristretto, la botnet perde la scala. Un secondo punto spesso ignorato è la toolchain. Togliere compilatori e strumenti di build dalle immagini di produzione riduce drasticamente la capacità dell’attaccante di comporre e adattare payload. Non “risolve” l’intrusione, ma cambia il tipo di intrusione: rende più fragile l’installazione multi-arch e più visibile la catena. Poi c’è l’egress. Una botnet che usa IRC e connessioni persistenti vive di traffico outbound. Se l’host non dovrebbe parlare con l’esterno se non per pochi endpoint noti, l’egress filtering diventa un moltiplicatore difensivo. Non serve bloccare tutto, serve bloccare l’inutile. È un principio banale ma raramente applicato in ambienti dove la priorità è “non rompere nulla”. Infine, la persistenza a cron ogni minuto è un difetto strutturale dell’attaccante: è efficace, ma lascia impronte. Se si monitorano nuove entry cron, soprattutto in directory insolite, e se si impedisce l’esecuzione da percorsi memory-backed come /dev/shm, l’operazione perde una parte del suo vantaggio.