La sicurezza tradizionale si basa spesso su cataloghi di firma e regole preconfezionate: antivirus, EDR e sistemi di intrusion detection confrontano ciò che osservano con liste note e generano alert quando trovano una corrispondenza. Questo modello funziona finché il catalogo include la minaccia, ma lascia un punto cieco quando l’attacco è nuovo o il malware vive solo in memoria. In questo scenario la capacità di interrogare direttamente lo stato del sistema diventa cruciale: non più uno strumento che cerca firme, ma una finestra che mostra cosa realmente sta accadendo su processi, rete e avvio del sistema.
Osquery nasce proprio per offrire questa visibilità. Anziché basarsi su pattern noti, trasforma il sistema operativo in un database relazionale interrogabile con il linguaggio SQL. Processi in esecuzione, socket, porte in ascolto, chiavi di registro, task pianificati e hash dei file diventano tutte tabelle virtuali su cui eseguire query ripetibili. Questo permette all’analista di rispondere in tempo reale a domande precise senza dipendere da firme esterne, aumentando la capacità di rilevare tecniche evasive come fileless malware o eseguibili rinominati.
Cosa è Osquery e perché è rilevante
Lo strumento è nato all’interno di Facebook nel 2014 per rispondere a esigenze di monitoraggio su larga scala: gestire decine di migliaia di endpoint eterogenei con risposte coerenti. La soluzione è stata rilasciata come progetto open source e ha trovato adozione in organizzazioni complesse, tra cui Palantir, che ne condivide configurazioni e pratiche. Nel 2019 lo sviluppo è passato alla Linux Foundation, garantendo indipendenza da vendor e un ecosistema collaborativo. L’ultima release stabile, la 5.22.1, è stata pubblicata a fine febbraio 2026, e oggi Osquery è disponibile per Linux, macOS e Windows con oltre duecento tabelle virtuali che coprono quasi ogni aspetto misurabile di un sistema.
Origini e adozione
La storia di Osquery è un esempio di come una soluzione interna possa diventare infrastruttura condivisa. Facebook l’ha progettata per interrogare endpoint su vasta scala, Palantir l’ha adottata in produzione e ne ha pubblicato esempi su GitHub; la comunità ha continuato lo sviluppo sotto l’egida della Linux Foundation. Questa traiettoria ha prodotto strumenti di gestione complementari, come Fleet, che orchestrano Osquery su migliaia di macchine, trasformando query individuali in policy centralizzate e pipeline di raccolta dati per analisi forense e monitoring continuo.
Tabelle virtuali e compatibilità
Le tabelle virtuali esposte da Osquery coprono processi, connessioni di rete, certificati TLS, chiavi di registro e molto altro. Interrogare queste tabelle con SQL consente di costruire indagini ripetibili e automatizzabili: per esempio, una query che incrocia processi e porte in ascolto identifica rapidamente servizi che comunicano con l’esterno, mentre una che confronta processi con il file system mette in luce eseguibili eseguiti solo in memoria.
Metodologia pratica: le tre condizioni di un attacco
Ogni compromissione reale rispetta tre esigenze fondamentali: un servizio in esecuzione che fornisce un punto d’appoggio, una connessione di rete verso l’esterno (spesso una reverse shell per aggirare firewall) e un meccanismo di persistenza che assicura la sopravvivenza al riavvio. Un’analisi efficace scompone l’attacco in queste componenti e le verifica con query mirate: se si trova almeno una di esse, si ha un punto di intervento valido per neutralizzare la minaccia.
Rilevare servizi sospetti
Con Osquery basta una query per estrarre l’elenco completo dei servizi: nome, tipo di avvio, percorso eseguibile e account utente. L’analista cerca anomalie evidenti, come software non autorizzato su macchine che non dovrebbero averlo, o nomi che imitano servizi di sistema con una lettera cambiata. Il controllo incrociato del path dell’eseguibile e una semplice ricerca online o su piattaforme di threat intelligence permettono di confermare rapidamente la natura di un processo sospetto.
Tracciare connessioni e persistenza
Una query che incrocia processi e socket mostra quali processi comunicano con indirizzi remoti e su quali porte: così si identifica la relazione diretta tra processo malevolo e infrastruttura di comando e controllo. Per la persistenza, le tabelle che elencano programmi di avvio automatico e task pianificati rivelano istruzioni che fanno ripartire malware dopo un reboot. Infine, una query che segnala processi senza corrispondente file su disco individua i casi di memory-only malware, un chiaro segnale di compromissione avanzata.
Da individuazione a bonifica e prospettive future
Una volta confermata la compromissione, la procedura pratica è consolidata: fermare il processo (task manager o kill), rimuovere l’eseguibile dal percorso indicato e arricchire l’indagine con fonti di threat intelligence. Nella maggior parte dei casi si tratta di malware noti o varianti comuni, quindi la ricerca del nome del processo e il confronto con repository pubblici accelerano la bonifica. Inoltre, l’approccio basato su query ripetibili facilita la documentazione e la riproducibilità dell’attività forense.
Guardando avanti, l’integrazione con intelligenza artificiale promette di automatizzare il riconoscimento di pattern sospetti — dai nomi processuali manipolati alla correlazione di migliaia di connessioni — rendendo accessibile una parte dell’analisi anche a team con competenze più limitate. Per ora, però, il vantaggio più concreto resta la possibilità di interrogare direttamente la macchina e verificare le tre condizioni fondamentali: servizio, connessione e persistenza.
