L’obiettivo della ricerca
Riconoscere un malware già noto è solo una parte del lavoro di un antivirus. Volevo capire quanto cambiasse il risultato modificando il modo in cui lo stesso codice veniva presentato ed eseguito: come script, come file eseguibile o all’interno di un processo.
Ho esaminato Avast, Bitdefender, Dr.Web, ESET, F-Secure, Kaspersky e Sophos su Linux. La tesi comprende anche campioni sviluppati in C e Python per studiare keylogging, cifratura dei file e comportamento dei trojan. Qui riporto il confronto tra le tre tecniche di evasione per le quali la tesi presenta tabelle dei risultati.
Lo stesso codice, modi diversi di eseguirlo
Negli esperimenti ho usato come riferimento uno shellcode Meterpreter già noto agli antivirus. Per ogni prova verificavo che la protezione fosse attiva, osservavo la risposta al campione non codificato e poi ripetevo il test con le diverse varianti.
-
01
Partire da un campione noto
Verificare se l’antivirus riconosce lo shellcode di riferimento, non codificato, quando viene trasferito sulla macchina.
-
02
Cambiare il modo di eseguirlo
Confrontare un programma Python che carica il codice in memoria, la sua versione eseguibile, l’iniezione in un processo già attivo e la self-injection in un thread.
-
03
Documentare il risultato
Raccogliere le notifiche dell’antivirus e le prove di esecuzione, riportando per ogni prodotto se il campione viene rimosso o non rilevato.
I programmi di test usano allocazione ed esecuzione in memoria in
Python, ispezione dei processi tramite ptrace e
self-injection in C, anche con codifica XOR. Il confronto permette
di osservare come cambia la capacità di rilevamento al variare
della tecnica.
I risultati dei test
La tabella riunisce i risultati delle tre tabelle riepilogative del capitolo 4. “Rimosso” indica che l’antivirus ha rilevato ed eliminato il campione; “Non rilevato” indica l’esito osservato durante quella specifica prova.
| Prodotto | Shellcode non codificato | Caricamento da Python, con codifica | Eseguibile ELF con PyInstaller | Process injection* | Self-injection senza codifica | Self-injection con codifica |
|---|---|---|---|---|---|---|
| ESET | Rimosso | Non rilevato | Non rilevato | Non rilevato | Non rilevato | Non rilevato |
| Avast | Rimosso | Non rilevato | Non rilevato | Rimosso | Rimosso | Non rilevato |
| Sophos | Rimosso | Non rilevato | Rimosso | Non rilevato | Non rilevato | Non rilevato |
| F-Secure | Rimosso | Non rilevato | Non rilevato | Non rilevato | Non rilevato | Non rilevato |
| Bitdefender | Rimosso | Non rilevato | Non rilevato | Non rilevato | Non rilevato | Non rilevato |
| Kaspersky | Rimosso | Non rilevato | Non rilevato | Non rilevato | Non rilevato | Non rilevato |
| Dr.Web | Rimosso | Non rilevato | Non rilevato | Non rilevato | Non rilevato | Non rilevato |
* I risultati della process injection si riferiscono alla variante
Meterpreter. La tesi documenta anche una variante più semplice,
basata su /bin/sh, che non è stata rilevata da
nessuno dei sette antivirus.
Cosa ha fatto cambiare il risultato?
Anche il formato del file conta
Nessun prodotto ha rilevato la variante Python codificata. Convertendo lo stesso programma in un eseguibile ELF con PyInstaller, Sophos lo ha invece rimosso. In questo esperimento, cambiare il formato del file ha quindi modificato l’esito del test.
Una tecnica, risultati diversi
Avast ha rimosso sia l’eseguibile che iniettava Meterpreter in un altro processo, sia il programma di self-injection non codificato. Non ha invece rilevato la variante con codifica. Per interpretare i risultati occorre quindi considerare insieme la forma del payload e la modalità di esecuzione.
Il risultato non spiega da solo il perché
Le schermate e le tabelle documentano ciò che è accaduto durante i test. Non permettono, da sole, di individuare la regola che ha generato un rilevamento, escludere ogni controllo comportamentale o prevedere come si comporterebbe una versione più recente dell’antivirus.
I limiti dello studio
- I test risalgono al 2022: prodotti, motori di analisi e firme sono cambiati da allora.
- La tesi non riporta, per ogni prova, un insieme completo e uniforme di versioni dei prodotti, aggiornamenti delle firme e impostazioni utilizzate.
- È uno studio su campioni specifici, non un confronto basato su un insieme rappresentativo di malware né una valutazione di certificazione indipendente.
- I risultati riguardano soltanto i sette prodotti e i campioni esaminati. Non consentono di calcolare percentuali generali di rilevamento o di protezione.
Cosa ho imparato
Questa tesi mi ha insegnato a distinguere ciò che ipotizzo da ciò che osservo e da ciò che posso concludere. Ho scritto programmi di test in C e Python, confrontato sette prodotti e documentato le differenze, senza generalizzare a partire da un singolo risultato.
È un metodo che applico ancora oggi: definire cosa sto verificando, raccogliere riscontri, descrivere con precisione l’impatto e chiarire i limiti dell’analisi.
Fonti
Davide Di Matteo, Analisi di sicurezza e capacità dei software Anti Malware su Linux. Tesi di laurea triennale in Informatica, Università di Roma “Tor Vergata”, 28 ottobre 2022.
- Capitolo 1: sistemi di protezione e i sette prodotti analizzati.
- Capitolo 2: campioni sviluppati in C e Python.
- Capitolo 4: esecuzione di shellcode, process injection e self-injection, con tabelle comparative e schermate dei test.
- Introduzione e conclusioni: obiettivi della ricerca e interpretazione dei risultati.
Questa pagina riprende e commenta i risultati della tesi originale. È stata redatta nel settembre 2026.