Devirt pubblica una checklist in otto punti per i report di reverse engineering al SOC
Testo scritto con l’intelligenza artificiale a partire da una fonte citata, senza revisione umana prima della pubblicazione.
Il documento stabilisce cosa consegnare dopo una passata di RE, come marcare funzioni virtualizzate e come dichiarare il grado di certezza di ogni finding.
Otto consegne chiudono una passata di reverse engineering: Devirt pubblica una checklist che fissa cosa deve arrivare al SOC, come marcare le funzioni virtualizzate e quanto è solido ogni finding1.
I packer commerciali sono comuni nei campioni. MITRE ATT&CK li traccia come T1027.002, Software Packing. Lì molti report diventano vaghi: la logica sparisce dietro i protettori e il SOC riceve poco che possa usare subito1.
La checklist chiede otto elementi, tutti consegnabili. Una sintesi breve per chi decide. Il comportamento su file, processi e rete, distinto tra quanto osservato in laboratorio e quanto emerge dal codice. Le meccaniche di persistenza e i trigger che attivano o bloccano il campione. Indicatori di compromesso pronti per le regole. La configurazione e i dettagli di C2 con il metodo di recupero. Le funzioni recuperate in un formato che il prossimo analista possa aprire. I limiti dell’analisi. Infine, il livello di confidenza per ogni singolo finding1.
La sintesi per i decisori sta in due o tre frasi. Indica la famiglia se sei sicuro, cosa può fare il campione, se ha girato nell’ambiente e cosa fare ora. Gli opcode restano in appendice1.
Il comportamento va in due colonne. “Osservato” significa che è successo in sandbox. “Da codice” significa che la logica c’è ma non si è manifestata. I lead di incident response pianificano il contenimento anche dalla seconda colonna, perché risponde a “cos’altro poteva fare?”1.
Persistenza e trigger sono separati. La prima dice se torna al riavvio. I secondi spiegano perché in sandbox non si è mosso. Esempi comuni: data, raggiungibilità del C2, locale o tastiera, check anti-VM. Ogni trigger va legato alla condizione che attende1.
Gli indicatori devono entrare nella pipeline di detection. Hash, domini, IP, mutex, percorsi. Meglio indicatori comportamentali o di codice rispetto all’hash del campione, che cambia a ogni rebuild1.
Il lavoro deve passare di mano. Servono un database IDA o Ghidra con nomi, tipi e commenti, oppure pseudocodice annotato delle funzioni chiave. Uno stack di screenshot in PDF non si cerca, non si diff, non si estende1.
La certezza va esplicitata, voce per voce. Devirt propone quattro stati di prova: proven, runtime-dependent, unresolved, permanently bounded. Ogni funzione in scope finisce in uno e un solo stato. La riga “runtime-dependent” evita il passaggio da “non l’abbiamo visto” a “non può farlo”1.
Quando il campione è VM-protected, alcune funzioni sono tradotte in bytecode ed eseguite da un interprete incluso. Il decompilatore mostra il dispatcher e i handler, non la logica. Il report deve dire quali funzioni sono virtualizzate, altrimenti sembra completo quando non lo è. Uno studio di ANY.RUN di giugno 2024 su campioni con Themida e VMProtect, da cinque famiglie, ha trovato che nessuno usava davvero la virtualizzazione del codice: i protectors venivano impiegati come packer di base1.
Sulla sicurezza operativa, la guida è chiara. I campioni vivi si analizzano solo in ambienti isolati, senza percorso verso reti di produzione, e si tengono fuori dallo storage condiviso a fine lavoro. Se entra un terzo, chiedi per iscritto dove girano i campioni, se vengono condivisi o usati per training e quando vengono cancellati. Devirt dichiara che gli upload girano in isolamento, non sono condivisi tra clienti né usati per training, e la cancellazione inizia al termine dell’elaborazione, quando l’output è disponibile1.
Se le funzioni che servono sono virtualizzate e c’è scadenza, si può usare una devirtualizzazione automatica. Devirt restituisce le funzioni recuperate come database IDA (.i64), pseudocodice annotato, un report completo e un’API JSON, ciascuno con un registro della copertura; è prevista anche una valutazione iniziale gratuita e uno scoping specifico per analisti malware. L’uso ammesso è l’analisi autorizzata e l’intelligence difensiva, non il dispiegamento o il miglioramento di malware1.
La checklist è fornita da incollare nel template del report, così il SOC può pretenderla già dal prossimo incarico1.
Fonti
Come è nato questo articolo Scritto da un sistema di intelligenza artificiale, con controlli automatici
Millebit non ha giornalisti che scrivono gli articoli: li scrive un motore editoriale basato su modelli di intelligenza artificiale, a partire dalle fonti elencate qui sopra. Prima di uscire, ogni testo passa questi controlli:
- Rilettura. Un passaggio toglie i tic della prosa generata da un modello, come i contrasti costruiti e le frasi che annunciano invece di informare, senza toccare fatti e fonti.
- Fedeltà alle fonti. Un passaggio dedicato toglie ogni affermazione che le fonti non sostengono. Valutazione su questo pezzo: 9/10.
- Anti-cliché. Un filtro scarta frasi fatte, enfasi e tic della prosa artificiale: superato.
- Giudizio editoriale. Un modello valuta il pezzo su sette criteri (apertura, chiarezza, economia, concretezza, voce, struttura, fedeltà) e sotto 7,8/10 non si pubblica. Questo articolo ha preso 7,9/10.
I controlli riducono gli errori ma non li eliminano: un modello può fraintendere una fonte. Per le decisioni importanti, risali alla fonte originale. Se trovi un errore, segnalacelo.
Per vedere Millebit nelle notizie principali di Google, aggiungilo alle tue fonti preferite. Oppure segui l’edizione di oggi, il feed RSS o La Sintesi.