Questo rootkit Linux è open source (e serve a capire perché i sistemi di difesa falliscono)

I rootkit Linux hanno sempre rappresentato una categoria “elitaria” e opaca di malware: potenti, difficili da individuare, spesso sviluppati come proof-of-concept o come strumenti offensivi destinati a cerchie ristrette. Singularity è un progetto che rompe deliberatamente questa tradizione, proponendosi come un rootkit open source per Linux pensato non per l’abuso, ma per la ricerca avanzata sulle tecniche di evasione e rilevamento.

Il progetto nasce dal lavoro di Matheus Alves, che dichiara esplicitamente l’obiettivo di mostrare cosa è realmente possibile oggi una volta che un attaccante abbia già compromesso un sistema e ottenuto l’accesso al kernel. Singularity non si occupa di intrusioni iniziali, exploit o privilege escalation tradizionale: parte dal presupposto che il kernel sia già stato violato e concentra tutta la sua logica sulla persistenza invisibile.

Un rootkit che sfrutta il kernel contro se stesso

L’elemento architetturale più interessante di Singularity è la scelta di basarsi quasi esclusivamente sull’infrastruttura ftrace, un meccanismo legittimo del kernel Linux progettato per il debugging e il tracing. Storicamente, molti rootkit venivano individuati perché modificavano direttamente il codice macchina delle syscall o i vettori di trap della CPU (tabelle di indirizzi che dicono al processore dove andare a eseguire codice quando si verifica un evento speciale). Singularity evita completamente questo approccio.

Utilizzando ftrace, il rootkit inserisce hook (punti di intercettazione inseriti nel flusso di esecuzione di un programma o del sistema operativo; permettono di “agganciarsi” a una funzione) in numerose funzioni critiche del kernel senza alterarne il codice binario.

In questo modo, da un lato, Singularity riduce drasticamente le superfici di rilevamento basate sull’integrità del kernel. Dall’altro, rende l’attacco molto più “compatibile” con kernel moderni, evitando patch invasive che potrebbero causare instabilità o crash evidenti.

Un aspetto particolarmente rilevante, dal punto di vista difensivo, è che Singularity protegge attivamente ftrace, impedendo che sia disabilitato a runtime. Se un amministratore tenta di spegnerlo, il sistema sembra accettare il comando, ma lo stato interno rimane invariato. Il comportamento, apparentemente marginale, è uno dei pochi segnali anomali osservabili dall’esterno.

Invisibilità sistemica: processi, file e kernel state

Singularity persegue un obiettivo ambizioso: non si limita a “nascondere” processi o file, ma modifica le risposte delle syscall in modo che il sistema continui a sembrare logicamente consistente.

I processi controllati dall’attaccante sono esclusi da tutte le interfacce standard di osservazione: /proc, segnali, scheduler, statistiche globali e contatori di sistema. Il kernel continua a funzionare correttamente, ma fornisce una rappresentazione filtrata della realtà. Persino il numero totale di processi restituito dalle API di sistema viene adattato per evitare discrepanze sospette.

Lo stesso principio si applica al file system. Singularity intercetta le chiamate che elencano directory e file, rimuovendo selettivamente gli elementi protetti dopo che il kernel ha già costruito i buffer di risposta. Questa scelta tecnica, dettata da vincoli interni al kernel, evidenzia quanto sia complesso mantenere l’illusione di normalità: ogni dettaglio, come il numero di link di una directory o la risoluzione dei link simbolici, deve essere armonizzato per evitare incoerenze.

Oltre i confini tradizionali del rootkit

Rispetto ai rootkit “classici”, Singularity estende il concetto di invisibilità a domini spesso trascurati. Le comunicazioni di rete sono occultate non solo a livello di strumenti user space come ss o netstat, ma anche nelle strutture netlink (canale di comunicazione diretto tra kernel Linux e spazio utente) e nei meccanismi di packet capture del kernel.

Uno schema davvero molto interessante per studiare le interazioni tra rootkit e sistemi EDR moderni, molti dei quali fanno affidamento su eBPF, netlink e tracing avanzato.

Non meno rilevante è l’attenzione dedicata alla forensic evasion. Singularity non può impedire un’analisi offline di un disco montato su un altro sistema, ma cerca di minimizzare le tracce lasciate durante il runtime. Filtra log del kernel, ring buffer, interfacce di debug e perfino output di strumenti che analizzano l’unità di memorizzazione a basso livello, senza usare le normali funzioni del sistema operativo, mantenendo la lunghezza dei buffer per non alterare checksum o strutture attese.

Un laboratorio per migliorare le tecniche difensive

Nonostante la sua complessità, Singularity non è progettato per essere utilizzato in attacchi reali. Il progetto è presentato come laboratorio di ricerca, uno strumento che costringe analisti, sviluppatori di EDR e ricercatori nell’ambito della kernel security a confrontarsi con scenari estremi.

Il fatto che il codice sia open source e rilasciato con licenza MIT permissiva non ne riduce la responsabilità etica. Al contrario, sposta l’attenzione sul vero valore del progetto: offrire una base concreta per comprendere fin dove può arrivare un attaccante e, soprattutto, quali assunzioni difensive non sono più valide.

Singularity dimostra che, una volta perso il controllo del kernel, molte tecniche di monitoraggio considerate “avanzate” diventano fragili. Ed è proprio questa consapevolezza il contributo più importante del progetto: non l’occultamento perfetto, ma la messa in discussione delle certezze su cui oggi costruiamo la sicurezza dei sistemi Linux.

In un altro articolo ci siamo chiesti se Linux è davvero invulnerabile a virus e malware.