Singularity Rootkit: come bypassare Elastic Defend e la telemetria eBPF
- Il rootkit Singularity elude Elastic Defend manipolando le mappe eBPF dei processi fidati.
- L'evasione combina offuscamento dei simboli, frammentazione del modulo e codifica XOR.
- La telemetria eBPF viene resa cieca poiché il loader dinamico impedisce la generazione di eventi di caricamento.
- Il caso evidenzia vulnerabilità strutturali negli EDR Linux che si affidano a liste di esclusione per le performance.
Un sistema di sicurezza che non vede l'intruso non è un sistema di sicurezza, ma un placebo. È questo il presupposto tecnico che emerge dall'analisi del rootkit Singularity, sviluppato dal ricercatore 0xMatheuZ. Il cuore del problema risiede in un punto cieco di Elastic Defend, specificamente nel modo in cui il modulo eBPF gestisce il monitoraggio del caricamento dei moduli del kernel Linux.
Perché Elastic Defend non vede il rootkit Singularity?
L'invisibilità di Singularity non è frutto di un errore di programmazione casuale, ma di un'operazione chirurgica sulla telemetria. Elastic Defend, a partire dalla versione 8.14, utilizza un meccanismo basato su BPF per monitorare il caricamento dei moduli. Con l'introduzione della versione 9.5, è stato aggiunto il campo taint_flags, progettato per identificare moduli non firmati o costruiti esternamente che potrebbero compromettere l'integrità del kernel.
Il bypass avviene sfruttando la gestione dei processi fidati. Il programma eBPF di Elastic, prima di raccogliere informazioni sul caricamento di un modulo, verifica se l'identificativo del processo corrente (PID) è presente in una mappa dedicata ai processi fidati. Se il processo è classificato come trusted, il programma BPF termina l'esecuzione anticipatamente. In questo modo, l'evento di caricamento non viene generato e la regola di rilevamento basata sui taint_flags non riceve i dati necessari per scattare. Singularity, di fatto, convince l'EDR che chi sta caricando il rootkit sia un'entità di cui fidarsi, rendendo l'operazione invisibile ai sistemi di monitoraggio.
76 avvisi in un solo caricamento
L'efficacia del bypass è evidente se confrontata con il rumore generato da un tentativo di installazione non ottimizzato. In un ambiente di test basato su Ubuntu con kernel 6.8 e Elastic Defend 9.5.2, il caricamento di Singularity senza alcuna modifica ha prodotto 76 avvisi di sicurezza.
La maggior parte di queste segnalazioni è derivata da scansioni YARA effettuate sul modulo del rootkit presente sul disco. Altre erano invece legate al monitoraggio runtime tramite BPF. Questo volume di alert dimostra che le difese perimetrali e comportamentali di Elastic sono estremamente aggressive, ma anche che sono concentrate su pattern noti o comportamenti standard. Quando l'attaccante sposta l'azione all'interno della logica di fiducia dell'EDR, l'intero castello di avvisi crolla.
L'inganno della mappa BPF
La tecnica utilizzata da 0xMatheuZ per silenziare l'EDR non si basa su un identificatore statico. Poiché gli ID delle mappe BPF possono cambiare ogni volta che l'agente Elastic viene riavviato, un approccio rigido fallirebbe rapidamente. Il loader di Singularity implementa invece una ricerca dinamica della mappa BPF appropriata.
Analisi strategica: Questo passaggio trasforma il rootkit da un semplice malware a uno strumento di precisione. La capacità di localizzare dinamicamente le strutture di memoria dell'EDR significa che l'attaccante non deve conoscere preventivamente la configurazione della macchina vittima, ma può adattarsi in tempo reale all'ambiente di esecuzione. È un esempio di come l'automazione dell'evasione superi la staticità delle regole di detection.
Frammentazione e XOR per confondere YARA
Oltre a colpire la telemetria eBPF, Singularity deve sopravvivere alla scansione dei file. Le regole YARA di Elastic, come Linux_Rootkit_Generic.yar o quelle mirate a pattern di hooking e prefissi sospetti, sono in grado di isolare e cancellare il kernel object (.ko) prima ancora che venga caricato. Per contrastare questo, il ricercatore ha implementato tre livelli di offuscamento:
- Randomizzazione dei simboli: I nomi delle funzioni vengono rinominati intelligentemente per evitare che le firme YARA identifichino pattern comuni di rootkit.
- Frammentazione del modulo: Il codice non viene presentato come un unico blocco sospetto, ma viene frammentato.
- Codifica XOR: I frammenti vengono cifrati tramite XOR e caricati direttamente in memoria.
L'uso di memfd_create permette di creare file anonimi in memoria, evitando che fanotify possa vedere un percorso file reale sul disco, bypassando così ulteriormente i controlli di integrità del file system.
Come 0xMatheuZ ha reso invisibile il codice
Il profilo di 0xMatheuZ, descritto nelle sue pubblicazioni su matheuzsecurity.github.io, è quello di un Red Team Operator focalizzato sulla sicurezza offensiva Linux. La sua metodologia non si limita a trovare un bug, ma a costruire una pipeline di offuscamento automatizzata.
Il ricercatore ha affrontato il problema dell'offuscamento del framework Ftrace, rinominando le funzioni di supporto per evitare che l'EDR riconoscesse l'uso di tecniche di hooking del kernel. L'approccio di 0xMatheuZ è sistematico: identificazione della regola YARA, analisi della firma, sviluppo di una tecnica di evasione (come la randomizzazione dei simboli) e test di validazione. Questo processo trasforma lo sviluppo del rootkit in un ciclo di ingegneria inversa applicata.
Il loader dinamico è l'arma segreta?
Il vero punto di forza di Singularity non è il rootkit in sé, ma il suo loader. Mentre il rootkit fornisce le capacità di persistenza e occultamento, il loader gestisce la fase critica dell'ingresso. La capacità di interagire con le mappe BPF per 'avvelenare' o manipolare lo stato di monitoraggio dell'EDR è ciò che rende l'attacco efficace.
Se l'EDR si fida ciecamente di certi PID o di certe mappe di memoria per ottimizzare le performance (evitando di monitorare processi interni per non rallentare il sistema), crea un varco. Il loader dinamico di Singularity non evita semplicemente il monitoraggio, ma entra nel sistema di monitoraggio per dirgli di non guardare. È una distinzione fondamentale tra evasione passiva e manipolazione attiva della telemetria.
Quali sono i limiti della telemetria eBPF?
La questione sollevata da questa ricerca riguarda la natura stessa di eBPF come strumento di sicurezza. Ecco un'analisi strutturata dei limiti emersi:
Domanda: eBPF è intrinsecamente vulnerabile?
Risposta: No, ma la sua implementazione lo è. Se un sensore eBPF memorizza lo stato del monitoraggio in mappe BPF senza l'applicazione di security_bpf_map, quelle mappe possono essere riscritte o manipolate da un attaccante con privilegi sufficienti.
Domanda: Perché le liste di esclusione dei processi sono un rischio?
Risposta: Perché creano zone d'ombra. Per ridurre l'overhead computazionale, gli EDR escludono processi fidati. Se un attaccante può far apparire il proprio processo come fidato o manipolare la mappa di tali processi, l'EDR diventa cieco per design.
Domanda: Le firme YARA sono ancora utili?
Risposta: Sì, ma solo contro minacce non sofisticate. La combinazione di XOR, frammentazione e caricamento in memoria rende le firme statiche quasi irrilevanti contro un rootkit moderno.
La cecità degli EDR tra AI Act e la resilienza delle infrastrutture UE
Per un imprenditore o un CTO che opera in Europa, il caso Singularity non è solo un dettaglio tecnico, ma un segnale di rischio sistemico. Con l'entrata in vigore di normative come NIS2, la resilienza delle infrastrutture critiche diventa un obbligo legale. Se le soluzioni di sicurezza (EDR) possono essere rese cieche manipolando le mappe di memoria del kernel, la conformità formale non coincide con la sicurezza reale.
L'AI Act europeo spinge verso l'automazione della difesa, ma l'automazione dell'attacco (come la pipeline di offuscamento di 0xMatheuZ) sta procedendo a una velocità simile. La dipendenza eccessiva da strumenti di telemetria che possono essere 'avvelenati' dall'interno suggerisce la necessità di un approccio di difesa in profondità che non si affidi solo al kernel Linux, ma integri monitoraggi esterni e analisi comportamentali fuori banda.
Scenari futuri e indicatori:
1. Diffusione di rootkit che utilizzano il BPF Map Poisoning su larga scala. Indicatore: Aumento di incidenti di data breach in cui l'EDR non ha generato alcun alert nonostante la compromissione del kernel.
2. Evoluzione di Elastic e altri vendor verso l'implementazione di security_bpf_map per proteggere le proprie mappe di monitoraggio. Indicatore: Rilascio di patch o aggiornamenti specifici per la protezione delle mappe eBPF nei log di release dei vendor.
3. Integrazione di controlli di integrità hardware (come TPM) per validare il caricamento dei moduli kernel indipendentemente dal software EDR. Indicatore: Nuovi requisiti di certificazione per i server Linux destinati a infrastrutture critiche UE.
Domande frequenti
Cos'è il rootkit Singularity?
È un rootkit per Linux progettato per evadere i sistemi di rilevamento EDR, in particolare Elastic Defend, utilizzando tecniche di offuscamento e manipolazione della telemetria eBPF.
In che modo Singularity bypassa Elastic Defend?
Manipola le mappe eBPF dei processi fidati per impedire che l'EDR generi eventi di caricamento del modulo, rendendo il rootkit invisibile ai controlli di sicurezza.
Quali tecniche usa per evitare le scansioni YARA?
Utilizza la randomizzazione dei nomi dei simboli, la frammentazione del modulo, la codifica XOR e il caricamento in memoria tramite memfd_create.
Fonti: Gbhackers, Matheuzsecurity (2) ·
glacom · Intelligenza artificiale per aziende: i modelli girano sui tuoi server, i dati non escono →Scrivila qui: Susanna, l assistente AI di glacom, ti risponde via email con un approfondimento gratuito.
Nessuna consulenza personalizzata (finanziaria, legale o medica): solo informazione e fonti. Email usata solo per rispondere.
oppure scrivile su: WhatsApp · Telegram · SimpleX · Delta Chat · Email
