Questo articolo è il primo di una serie dedicata all’analisi malware, un percorso dedicato che possa permetterti di apprendere le basi di questa disciplina. In questo primo articolo, ci concentriamo sull’analisi statica di base di un file ELF a 64 bit. ELF (Executable and Linkable Format) è il formato standard per i programmi eseguibili su Linux, l’equivalente di un file .exe su Windows.

Questo genere di file contiene il codice macchina del programma e le istruzioni per il sistema operativo su come caricarlo in memoria ed eseguirlo correttamente. Oltre ai programmi, il formato ELF è usato anche per le librerie condivise (.so) e i file oggetto (.o). L’obiettivo in questa fase non è il reversing completo né l’esecuzione del campione, ma imparare a ricavare rapidamente indicatori utili (metadata, segmenti, entropia, stringhe e informazioni riguardo il packing) senza eseguire il binario.

L’analisi statica di base consiste nell’esaminare il file eseguibile senza visualizzarne direttamente le istruzioni. Questo tipo di analisi può confermare se un file è malevolo, fornire informazioni sulla sua funzionalità e, talvolta, permettere di ricavare semplici firme di rete (network signatures: nome di dominio, IP, porte, URL). L’analisi statica di base è semplice da eseguire e può essere molto rapida, ma risulta poco efficace contro malware sofisticati e può tralasciare comportamenti importanti.

“everything is open source if you can reverse engineer”

Step Fondamentali dell’Analisi Statica di Base

Nelle prossime sezioni verranno descritte le procedure metodologiche per ispezionare il file malevolo a riposo (ovvero, senza eseguirlo), un processo cruciale per ottenere una prima, fondamentale comprensione della sua struttura e dei suoi intenti. Di seguito un sunto per punti di quello che andremo a vedere:

  • Analisi preliminare del File tramite Hash
  • Malware impacchettato e offuscato e analisi dell’Entropia
  • Analisi dell’Entropia con binwalk
  • Analisi delle funzioni importate con Radare2
  • Analisi del malware con il comando file
  • Analisi del malware con il comando readelf

Analisi preliminare del File tramite Hash

L’hashing è un metodo comune utilizzato per identificare in modo univoco un malware. Il software malevolo viene elaborato da un programma di hashing, che produce un hash unico capace di identificare quel malware, una sorta di impronta digitale.

La funzione di hash MD5 (Message-Digest Algorithm 5) è stata a lungo la più utilizzata nell’analisi dei malware, ma oggi è considerata obsoleta e insicura. Al suo posto si preferiscono algoritmi più moderni e affidabili come SHA-256 (Secure Hash Algorithm 256-bit), anche se SHA-1 può ancora comparire in alcuni contesti legacy o di compatibilità.

L’hash del file permette di ricercare informazioni correlate al malware online, in particolare su piattaforme specializzate come VirusTotal.

Malware impacchettato e offuscato e analisi dell’Entropia

Gli autori di malware spesso usano packing o offuscamento per rendere i loro file più difficili da rilevare o analizzare. I programmi offuscati sono quelli il cui codice sorgente o binario è stato deliberatamente reso illeggibile e difficile da analizzare, pur mantenendo la sua funzionalità originale. I programmi impacchettati (packed) sono un sottoinsieme dei programmi offuscati in cui il programma malevolo è compresso o criptato e quindi non può essere analizzato direttamente. Entrambe le tecniche limiteranno fortemente i tentativi di analisi statica del malware.

I programmi legittimi contengono quasi sempre molte stringhe (testo leggibile). Il malware che è impacchettato o offuscato contiene poche stringhe intelleggibili. Se, cercando le stringhe in un programma con strings, si scopre che ne ha soltanto poche intelleggibili, è probabile che sia offuscato o impacchettato, il che suggerisce che potrebbe essere malevolo. Probabilmente si dovrà ricorrere a tecniche oltre l’analisi statica per investigare più a fondo.

Il comando strings estrae e mostra le sequenze di caratteri stampabili (testo leggibile) da qualsiasi file, ma è usato principalmente sui binari. Permette di trovare rapidamente testo, come messaggi di errore o percorsi di file, all’interno di file non testuali senza doverne analizzare la struttura. In questo caso il comando strings ha rivelato esclusivamente stringhe intellegibili relative al packer UPX.

Una volta accertato che il file è stato compresso con UPX, si può procedere alla decompressione (unpacking) tramite il seguente comando:

Analisi dell’Entropia con binwalk

Binwalk è un’utility usata per analizzare, estrarre e “smontare” file binari. È particolarmente efficace con le immagini firmware (il software che fa funzionare dispositivi come router, telecamere, etc.). La funzione di analisi dell’entropia di Binwalk è cruciale per identificare rapidamente le aree “interessanti” di un file.

Analizzando un altro campione di malware ELF compresso (packed), si notano subito due indicatori. Primo, il comando strings, come si è potuto già vedere, rivela quasi esclusivamente stringhe intellegibili relative al packer UPX. Secondo, l’analisi dell’entropia con binwalk -E mostra un valore uniformemente elevato, un’ulteriore conferma che il file è stato offuscato tramite compressione. Un valore di entropia elevato, infatti, implica un alto grado di caos e casualità nei dati.

In altri casi, l’analisi dell’entropia con Binwalk potrebbe non produrre risultati significativi. Ad esempio, potrebbe non rilevare alcuna variazione utile oppure potrebbe evidenziare picchi di entropia elevata solo in aree molto limitate dell’eseguibile. Nel caso del malware che stiamo analizzando, il cui hash sha256 abbiamo calcolato all’inizio, non abbiamo informazioni sull’Entropia, perché il file eseguibile ha dimensioni troppo ridotte.

Analisi delle funzioni importate con Radare2

Radare2 (spesso abbreviato in r2) è un framework completo e open source per il reverse engineering e l’analisi di file binari. Non è un singolo strumento, ma una suite di potenti utility a riga di comando che possono essere usate insieme per disassemblare, analizzare, modificare e sfruttare qualsiasi tipo di file binario, come eseguibili, librerie, firmware e malware.


afl (Analyze Function List)

Il comando afl elenca tutte le funzioni che Radare2 è riuscito a identificare all’interno del file binario che si sta analizzando, comprese le funzioni importate.  È uno dei primi comandi da eseguire per ottenere una mappa generale del programma e decidere da dove iniziare l’analisi.

Se l’output di Radare2 fosse simile a questo si potrebbero trarre alcune ipotesi iniziali sul comportamento del programma:

  • Gestione dell’Input/Output: La presenza di funzioni come fgets (per leggere stringhe), strcspn (per l’analisi delle stringhe) e printf/puts (per stampare a schermo) suggerisce che il programma interagisce con l’utente tramite input e output testuale.
  • Comportamento Locale: Un dato fondamentale è l’assenza di funzioni importate relative a operazioni di rete (es. socket, connect), accesso al file system (es. fopen) o gestione di altri processi. Questo indica fortemente che le sue azioni sono confinate all’ambiente locale.

L’analisi statica suggerisce che il programma potrebbe essere un semplice interprete di comandi o un software che richiede l’inserimento di dati, come una password o una flag (es. un crackme o un CTF). Sebbene non emergano attività palesemente sospette, non è possibile escludere una natura malevola senza un’analisi più approfondita, come quella dinamica o l’analisi del codice disassemblato, per comprendere la logica interna del programma.

Nel caso del malware che stiamo analizzando, l’analisi iniziale con Radare2, tramite il comando afl, non rivela alcuna funzione di libreria importata, mostrando unicamente il punto d’ingresso (entry0). Questa assenza è un forte indicatore che l’eseguibile è stato compilato staticamente. Invece di fare affidamento su librerie esterne (es. libc), il compilatore ha incluso tutto il codice macchina necessario direttamente all’interno del file. Di conseguenza, funzioni standard come printf, socket o connect non appaiono come funzioni importate ma come parte integrante del codice del malware stesso, rendendo l’analisi iniziale più complessa.

Analisi del malware con il comando file

Il comando file determina il tipo di un file analizzandone il contenuto anziché l’estensione. Esegue una serie di test, come la ricerca di “magic number” (sequenze di byte identificative), per riconoscere il formato. Restituisce una breve descrizione del tipo di file, ad esempio JPEG image data o ASCII text.

Il malware che stiamo analizzando è un ELF a 64 bit minimale, privo della Section Header Table (SHT) (tipico di alcuni malware offuscati per ostacolare l’analisi statica e i tool come readelf/objdump). Questo non impedisce l’esecuzione del file: il loader del kernel si basa sulla Program Header Table (PHT) per mappare i segmenti in memoria; il fatto che sia linkato staticamente e con permessi RWE (vedere sezione readelf) indica che è stato costruito per essere autosufficiente, senza dipendenze, e magari pronto per eseguire codice decrittato/iniettato dinamicamente.

Analisi del malware con il comando readelf

Il comando readelf è uno strumento specializzato che analizza e visualizza informazioni estremamente dettagliate sulla struttura dei file in formato ELF (eseguibili e librerie su Linux). Si concentra sulla visualizzazione precisa di ogni componente dello standard ELF, come le intestazioni (headers), le sezioni e le informazioni sul linking dinamico.

-l (–program-headers)

Mostra la program header table, ovvero i segmenti che dicono al sistema operativo come caricare il file in memoria.

Intestazioni di programma:

-h (–file-header)

Mostra l’ELF header: formato (32/64 bit), endianness, versione, tipo (EXEC/DSO/REL), architettura, entry point, offset delle table, flags ecc. Utile per capire a colpo d’occhio che tipo di ELF stai analizzando.

Intestazione ELF:

Analisi dei risultati di readelf

Ricapitolando per punti quanto abbiamo osservato finora:

  • Il binario è un ELF64 eseguibile per x86-64, entrypoint 0x400078.
  • Non contiene Section Header Table (size section headers = 0), tipico dei malware minimali o offuscati/packed.
  • Program header singolo con flags RWE (read-write-exec), cioè tutta la memoria caricata è leggibile, scrivibile ed eseguibile.
  • Statically linked, quindi non dipende da librerie esterne.

Le evidenze raccolte suggeriscono che il malware possa agire come stager o dropper: la sua struttura minimale e autosufficiente (dimensioni ridotte, 227 bytes, compilazione statica), l’uso di tecniche di anti-analisi come l’assenza di section headers per ostacolare il reverse engineering, e soprattutto la presenza di un segmento di memoria con permessi di Lettura, Scrittura ed Esecuzione (RWE). Quest’ultima caratteristica, in particolare, è un forte indicatore di un codice progettato per auto-modificarsi, caricando e avviando un payload successivo.

Conclusioni

In questo articolo abbiamo esplorato le fasi fondamentali dell’analisi statica di base, dimostrando come, attraverso una serie di strumenti essenziali (sha256sum, strings, binwalk, radare2, file e readelf), sia possibile costruire un profilo iniziale di un malware ELF sconosciuto. Abbiamo imparato a identificare il file, a rilevarne eventuali tecniche di offuscamento come il packing, e ad analizzarne la struttura per raccogliere indicatori cruciali, come la compilazione statica, l’assenza di section headers e la presenza di segmenti di memoria con permessi RWE.

Sebbene questa analisi ci abbia permesso di formulare un’ipotesi solida sulla natura del campione,  probabilmente uno stager o dropper, essa si ferma alla superficie, senza svelare la logica esatta del suo codice. Per comprendere appieno le sue azioni, è necessario fare un passo avanti.

Nel prossimo articolo, ci addentreremo nell’analisi statica avanzata, immergendoci nello studio del codice disassemblato per decifrare le istruzioni macchina e svelare le reali intenzioni del malware.

Autore

HCF: hacker artist, reverse engineer, battle programmer e malware & cybersecurity analyst.
blog: spaghetti-hacker.blogfree.net

Halt and Catch Fire, indicato con la sigla mnemonica di HCF, è un’istruzione fittizia del linguaggio assembly, intesa prevalentemente come uno scherzo, che è stata usata per definire istruzioni solitamente non documentate che portano la CPU in uno stato da cui può essere fatta uscire solo con un reset; solitamente con la sigla HCF si descrive una o più istruzioni non documentate presenti in molte architetture e utilizzate per poter effettuare agevolmente particolari test durante lo sviluppo dei prodotti, ma che non sono da utilizzarsi nella normale operatività.

Ti è piaciuto l’articolo? Seguici su Linkedin per sostenerci!

consigliati