Il lavoro presentato in questa tesi mira a sviluppare un classificatore utilizzato all’interno del progetto europeo PhishSense, capace di distinguere URL di phishing da legittimi.

1. UNIVERSITÀ DEGLI STUDI DI
TRIESTE
Dipartimento di Ingegneria e Architettura
Laurea Magistrale in Ingegneria Informatica
Sviluppo di un sistema per la classificazione
di URL di phishing mediante tecniche di
Machine Learning
27 novembre 2017
Laureando Relatore
Federico Cergol Chiar.mo Prof. Alberto Bartoli
Correlatore
Ing. Marco D’Orlando
Anno Accademico 2016/2017

2. Being able to talk to people over long distances, to transmit images, flying,
accessing vast amounts of data like an oracle. These are all the things that
would have been considered magic a few hundred years ago. So engineering
is, for all intents and purposes, magic, and who wouldn’t want to be a
magician?
— Elon Musk —

3. Sommario
Il lavoro presentato in questa tesi mira a sviluppare un classificatore utilizza-
to all’interno del progetto europeo PhishSense, capace di distinguere URL di
phishing da legittimi. Il dataset su cui ci si è basati per lo studio successivo è
stato raccolto utilizzando tre fonti: Google, AlexaRanking, e PhishTank. La
costruzione del features vector di ogni URL comporta un’ampia analisi: viene
ispezionata la lessicografia, la pagina puntata, le informazioni contenute nei
record DNS e WHOIS, e le eventuali informazioni sui dettagli dei certificati
SSL. La scelta del classificatore è stata guidata dalle analisi e dall’osservazio-
ne dei dati nonché dalla tipologia di problema: l’algoritmo Random Forest
scelto presenta il miglior compromesso tra complessità computazionale e ac-
curatezza. Si è inoltre studiata una metodologia per adattare il classificatore
nel tempo in modo da non incorrere in un degrado delle prestazioni. Si
è validata poi la bontà dell’approccio adottato confrontando i risultati con
l’applicazione enterprise Symantec RuleSpace, servizio che permette di ca-
tegorizzare URL in funzione del loro contenuto. I risultati confermano le
potenzialità dell’approccio adottato e hanno permesso di costruire una mo-
dalità di integrazione di Symantec RuleSpace nel modello sviluppato al fine
di migliorarne le capacità.
Infine si è configurato un container per esporre il servizio al pubblico1.
1
Per ottenere l’URL, le specifiche, e le credenziali occorre farne richiesta a
precog-dev@emaze.net
i

4. Indice
Sommario i
Introduzione iv
1 Phishing 1
1.1 Statistiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Definizione del sistema 4
2.1 PhishSense . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Stato dell’arte 7
3.1 Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Classificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Validazione e risultati . . . . . . . . . . . . . . . . . . . . . . 10
4 Dataset 11
4.1 URL di phishing . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1 PhishTank . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 URL legittimi . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5 Caratteristiche 13
5.1 Raccolta dati . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.1 Lessicografia URL . . . . . . . . . . . . . . . . . . . . 14
5.2.2 Struttura pagina . . . . . . . . . . . . . . . . . . . . . 14
5.2.3 Informazioni dominio . . . . . . . . . . . . . . . . . . . 14
5.2.4 Caratteristiche certificato . . . . . . . . . . . . . . . . 17
5.2.5 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3 Vettore caratteristiche . . . . . . . . . . . . . . . . . . . . . . 19
ii

5. INDICE
6 Classificatore 20
6.1 Multilayer Perceptron . . . . . . . . . . . . . . . . . . . . . . 21
6.2 Decision Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.3 Random Forest . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7 Adattamento 29
8 Validazione esterna 31
8.1 Symantec RuleSpace . . . . . . . . . . . . . . . . . . . . . . . 31
8.2 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.3 Integrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Conclusioni 35
A Tecnologie utilizzate 36
iii

6. Introduzione
Purtroppo è sempre stato chiaro come gli utenti rappresentino uno tra i
punti più deboli di qualsiasi sistema informatico; da un lato perché è più
facile imbrogliare una persona rispetto ad un computer, dall’altro perché è
molto difficile tenere sotto controllo gli utenti e le loro interazioni.
Il phishing è un tipo di truffa effettuata su Internet attraverso la qua-
le un attaccante utilizza prevalentemente un canale di comunicazione ade-
guatamente configurato (solitamente email opportunamente strutturate) per
illudere l’utente della propria identità. Utilizzando questo approccio è pos-
sibile ottenere diversi esiti: diffusione di malware, attacchi CSRF, furti di
identità, etc. Inoltre attacchi di questo tipo danneggiano l’immagine delle
aziende vittime perché gli utenti tendono a cadere involontariamente nella
fallacia di “colpa per associazione” e considerare poco affidabili anche queste.
Nella sua forma più comune questa truffa consiste nel convincere la vit-
tima a fornire informazioni sensibili fingendosi un ente affidabile: questo
avviene attraverso un invio massivo di email che contengono un link ad un
sito web sviluppato ad hoc per ingannare l’utente ignaro ad inserire queste
informazioni.
Come verrà descritto nel Capitolo 1, il fenomeno del phishing è estre-
mamente esteso e risulta necessario trovare nuove metodologie di difesa. In
questo contesto, il lavoro presentato in questa tesi consiste nello sviluppo di
in un classificatore capace di riconoscere URL che puntano a siti di phishing,
in modo da riconoscere la minaccia e intraprendere azioni di notifica. Il risul-
tato di questo sviluppo è un modulo software integrato nel progetto europeo
PhishSense, a cui aderisce anche Emaze, l’azienda che ha reso possibile il
lavoro qui presentato. Per lo sviluppo di questo componente si sono seguite
le seguenti fasi:
1. Definizione del sistema: il primo punto è definire quali saranno i
casi d’uso del sistema che si vuole sviluppare e in che modo questo si in-
serisce all’interno di sistemi esistenti. Di questo si occupa il Capitolo 2,
descrivendo nello specifico l’architettura PhishSense e il contributo che
il lavoro qui svolto porta.
2. Raccolta dataset: per validare i risultati teorici e per eseguire il trai-
ning degli algoritmi di machine learning di cui si è fatto uso è neces-
iv

7. INTRODUZIONE
sario disporre di un dataset di campioni che rispecchi la distribuzione
di URL riscontrabile nella realtà. Varie modalità di compilazione e
relativi limiti vengono discussi nel Capitolo 4.
3. Individuazione features: in questa fase si individuano le featu-
res utili ai fini della classificazione e si sviluppa un metodo per l’e-
strazione di queste caratteristiche. Il Capitolo 5 presenta e descrive
approfonditamente le scelte compiute in questo ambito.
4. Classificazione: si costruisce un modello capace di eseguire la clas-
sificazione e lo si implementa. Il Capitolo 6 descrive i vari algoritmi
di classificazione, come sono stati implementati e quali sono i punti
di forza e le limitazioni di ogni approccio. Vengono inoltre discusse
le metodologie applicate per la validazione sperimentale dei risultati
ottenuti.
5. Adattamento: si sviluppa una metodologia che permetta di adattare
il classificatore mano a mano che nuovi dati diventano disponibili. Il
Capitolo 7 descrive questo sistema.
6. Validazione esterna: si comparano i risultati sperimentali ottenuti
con quelli forniti da una fonte affidabile. Il Capitolo 8 espone i risultati
del confronto con Symantec RuleSpace, un’applicazione enterprise di
classificazione di URL.
v

8. Capitolo 1
Phishing
Gli attacchi di phishing sono minacce informatiche diffuse su larga scala,
perché sono semplici da realizzare e perchè richiedono poche risorse. Di
questo tipo di attacchi esistono molte varianti, in questa tesi ci si è focalizzati
su quelle più comuni. L’obbiettivo dell’attacco è quello di impossessarsi di
informazioni personali, di solito credenziali di accesso ai portali bancari o
finanziari. In particolare l’attacco, come mostrato nel diagramma riportato
in Figura 1.1, è diviso in varie fasi:
1. Inizialmente l’attaccante imposta un webserver in modo che esponga,
ad un certo URL, una pagina creata in modo da convincere l’utente
ignaro ad inserire le proprie credenziali;
2. in un secondo momento l’attaccante esegue un invio massivo di email
create in modo da ingannare l’utente a visitare l’URL del punto pre-
cedente;
3. l’utente che riceve la mail visita la pagina fraudolenta e immette le
proprie credenziali nel form opportunamente configurato. A credenziali
inserite di solito l’utente viene rimandato alla pagina di login dell’entità
legittima con un messaggio di errore per evitare di insospettirlo;
4. l’attaccante può infine ritirare i dati mantenuti nel webserver impos-
sessandosi delle credenziali di tutti gli utenti ingannati.
Da questo emerge un altro grande problema del phishing: chi è vittima di
questa tipologia di attacco non ha modo di rendersene conto, possono passare
anche mesi, durante i quali le credenziali vengono vendute o passate di mano,
prima che queste vengano utilizzate e la vittima abbia la prima possiblità
di accorgersene. A quel punto poi, è troppo tardi anche solo per cercare di
capire come le credenziali siano state rubate.
Variazioni di questa tipologia di attacco consistono principalmente nella
modifica del canale di comunicazione scelto (per esempio chat o telefono),
1

9. CAPITOLO 1. PHISHING
tuttavia la mail resta il vettore preferito vista la facilità con cui è possibi-
le raggiungere le masse. Esiste anche una variante più precisa, chiamata
spear phishing, in cui l’obbiettivo consiste in informazioni (credenziali) mol-
to specifiche; per eseguire questo tipo di attacco sia il sito web che la mail
utilizzata come vettore vengono attentamente create in modo da conformarsi
alla vittima prescelta facendo largo uso di conoscenze sociali e psicologiche
della vittima.
Figura 1.1: Diagramma attacco di phishing
Attacker Database Web Server Mail Server Victim
Setup
Setup
Send email
Get email
Follow link
phishing page
credentials
save
disengage
collect
data
1.1 Statistiche
Come riportato da [15] in generale il numero di email di phishing è in calo
rispetto all’anno precedente (1 ogni 2596 nel 2016 contro 1 ogni 1846 nel
2015) tuttavia si è registrato un aumento degli attacchi mirati come spear
2

10. CAPITOLO 1. PHISHING
phishing, whaling (phishing su misura di singole persone), o Business Email
Compromise (variante del phishing che replica la fattura di specifiche mail
aziendali conosciute al ricevente). Purtroppo questo fenomeno non colpisce
solamente le grandi aziende ma anche le piccole e medie imprese; come si
può vedere in Figura 1.2 tutto lo spettro delle aziende in base ai dipendenti
è vittima di questi attacchi. Stime dell’FBI contano 3 miliardi di dollari di
danni con più di 22000 aziende colpite solo negli ultimi tre anni.
Figura 1.2: Percentuale di mail di phishing ricevute da varie aziende in base
al numero di dipendenti
500 1 000 1 500 2 000 2 500 3 000
0
0.1
0.2
0.3
n. dipendenti
percentualediemaildiphishing
A questo va aggiunta la poca conoscenza degli utenti a riconoscere que-
sta tipologia di attacchi. In [2] viene mostrato come il 60% degli utenti che
ricevono email di phishing contententi un URL fraudolento visitano il sito e,
sebbene questo non significhi che automaticamente cadano vittime del tenta-
tivo di phishing, dimostra la poca attenzione prestata dalle potenziali vittime
che sottovalutano o non conoscono il fenomeno. Ancora più allarmante è il
fatto che anche dopo una fase di training appropriata questa percentuale non
diminuisce significativamente.
Questo è il motivo principale del perché lo sviluppo di filtri che ricono-
scono le mail di phishing ha raggiunto la maturità odierna. Nonostante ciò,
vista la presenza continua e massiccia di questa minaccia, è indispensabile
ricercare nuove modalità e nuovi approcci per dare risposte efficaci a questo
problema.
3

11. Capitolo 2
Definizione del sistema
2.1 PhishSense
Il lavoro svolto in questa tesi si inserisce nell’ambito del progetto europeo
PhishSense1, il quale vuole essere la risposta europea al problema del phi-
shing. Fra i partecipanti merita citare Poste Italiane2, Engineering3, Pluribus
One4, ed Emaze5 che ha permesso di condurre la ricerca presentata in questo
elaborato.
PhishSense è un software anti-phishing as a Service che combina nume-
rosi componenti, tra cui un Web Application Firewall, un plugin per email
client e browser, vari servizi di classificazione di URL, e un orchestratore
per l’integrazione. Il lavoro svolto in questa tesi consiste nello sviluppo di
un classificatore di URL, il suo caso d’uso più importante è raffigurato in
Figura 2.1.
Questo caso d’uso prevede le seguenti fasi:
1. L’attaccante crea un sito web fraudolento attraverso il quale un utente
può inserire informazioni sensibili (ad esempio goodcompany.qwqw.co);
2. L’attaccante invia una email fraudolenta contenente un link al sito
creato in precedenza;
3. La vittima scarica la mail ma, nel farlo, un modulo del sistema Phish-
Senze sostituisce i link presenti nella email in modo che puntino ad un
server conosciuto (ad esempio il link precedente diventa:
http://phishsense-server.intranet/?url=goodcompany.qwqw.co);
4. La vittima clicca sul link ed invia così una richiesta al server Phish-
Sense;
1
http://phishsen.se
2
https://www.poste.it
3
http://www.eng.it
4
https://www.pluribus-one.it
5
https://www.emaze.net
4

12. CAPITOLO 2. DEFINIZIONE DEL SISTEMA
Figura 2.1: Caso d’uso di PhishSense per proteggere da attacchi di phishing.
Attacker Web Server Mail Server PhishSense Server Victim
1: setup
2: send email
3: get email
4: follow link
5a: inspect
5b: analyze
score
6a: Visit
page content
if safe:if safe:
6b: warning
warning page
else:else:
5. Il server PhishSense compie un’analisi accurata a partire dall’URL ri-
cevuto e decide se l’istanza considerata corrisponde ad un tentativo di
phishing;
6. Se il server PhishSense reputa l’URL sicuro allora risponde alla vitti-
ma con un redirect verso l’URL originale (per la vittima tutto questo
processo è stato trasparente), altrimenti viene visualizzata una pagi-
na dedicata che indica che l’utente è stato vittima di un attacco di
phishing, analogamente a quanto fa Google con il servizio Google Safe
5

13. CAPITOLO 2. DEFINIZIONE DEL SISTEMA
Browsing6.
2.2 Sistema
Il sistema presentato in questo lavoro si concentra sullo sviluppo del punto 5
dell’elenco precedente, ovvero sulla classificazione degli URL. In particolare
si è sviluppato un modulo capace di ricevere in input un URL e di fornire
un punteggio corrispondente alla confidenza legata all’affermazione “questo
URL punta verso un sito di phishing”. Inoltre questo modulo prevede la
possibilità di aggiornare il classificatore presente al suo interno in modo da
potersi adattare ai cambiamenti che inevitabilmente governano le variabili
in gioco.
Si è infine progettata un’interfaccia HTTP pubblica attraverso cui espor-
re questo sistema al resto dell’architettura di PhishSense che prevede l’in-
tegrazione di numerosi componenti sviluppati dagli altri partner del proget-
to al fine di dare una risposta efficace contro il phishing alle aziende che
sottoscrivono il servizio.
6
https://safebrowsing.google.com
6

14. Capitolo 3
Stato dell’arte
Di seguito viene presentata la sintesi dei contributi scientifici di alcuni dei
lavori di ricerca più influenti in questo ambito suddivisi per macroarea.
3.1 Dataset
Un punto critico è la raccolta di un dataset sia per validare i risultati teorici
sia per eseguire il training di eventuali algoritmi di machine learning. Per
garantire l’accuratezza nei risultati è necessario che il dataset rispetti alcune
caratteristiche suggerite della letteratura:
• la sua dimensione deve essere statisticamente rilevante: questo dipende
dai metodi utilizzati, se il dataset viene utilizzato solo per test e vali-
dazione 4000-5000 campioni divisi equamente nelle due categorie sono
sufficienti [16]. Se invece occorre una fase di training è indispensabile
prendere in considerazione dimensioni maggiori, per esempio [20] con-
sidera circa 200000 campioni distribuiti in maniera da rispecchiare il
più possibile la realtà.
• sia conosciuta a priori la loro classificazione, questa è una caratteristica
indispensabile per test e validazione e di norma anche per le fasi di
training. Tuttavia [17] riesce ad ottenere risultati significativi anche
nel caso in cui la classificazione sia incompleta o incorretta.
• sia omogeneo rispetto alle categorie, nel senso che, nei limiti del possi-
bile, gli URL di phishing e gli URL legittimi devono provenire da fonti
analoghe per evitare di introdurre una dipendenza artificiale tra le ca-
ratteristiche di ogni campione e la sua classificazione. La stragrande
maggioranza di studi sull’argomento utilizza PhishTank1, una piatta-
forma gestita da volontari che manualmente segnalano e classificano
link trovati in mail aziendali, per gli URL di phishing e Dmoz2, un
1
http://www.phishtank.com
2
http://www.dmoz.org/
7

15. CAPITOLO 3. STATO DELL’ARTE
archivio di link a siti legittimi mantenuto da volontari, e Alexa3, una
classifica dei domini di secondo livello maggiormente visitati, per gli
URL legittimi. Purtroppo questo approccio presenta dei problemi in
quanto si introduce un bias tra le due classi dal momento che Alexa
fornisce solo i domini di secondo livello e Dmoz contiene quasi unica-
mente link alle homepage mentre PhishTank fornisce URL completi.
Questo porta a risultati artificialmente migliori di quelli che l’algoritmo
presentato potrebbe ottenere nel caso reale; ciò è successo per esem-
pio con [5] e [13], nel quale sono stati utilizzati direttamente gli URL
forniti da PhishTank e Dmoz, e [1], in cui sono stati utilizzati gli URL
di PhishTank e del primo risultato di Google cercando il brand name
interessato. Una soluzione ottimale è quella presentata da [17]: tutti i
dati provengono dalla stessa fonte e sono classificati a mano dalle stesse
persone, tuttavia non sempre questo è possibile e occorre trovare un
compromesso accettabile.
3.2 Caratteristiche
Lo scopo di questa parte è quello di estrarre dall’URL un insieme di carat-
teristiche che rappresentano tutte le informazioni necessarie alla successiva
analisi. Queste caratteristiche possono essere estratte da varie fonti, a se-
conda del tipo di analisi che si vuole effettuare (interessanti informazioni
statistiche sono fornite da [12] per molte delle features possibili). Di seguito
vengono presentate le caratteristiche più utilizzate negli studi esaminati:
• URL: caratteristiche della stringa URL. Esempi di caratteristiche les-
sicali sono:
– lunghezza dell’URL
– numero di caratteri "."
– presenza di caratteri sospetti ("@", "%", ...)
– presenza di errori / parole non appartenenti ad alcun dizionario
– presenza di indirizzi IP numerici
– utilizzo https
– utilizzo della codifica punycode
• host: caratteristiche della macchina che risponde all’URL
– raggiungibilità
– velocità / banda disponibile
– software utilizzato
3
https://www.alexa.com/
8

16. CAPITOLO 3. STATO DELL’ARTE
– informazioni database WHOIS
– informazioni record DNS
– informazioni indirizzo IP (è presente in qualche blacklist/whitelist)
– informazioni contenute nei certificati SSL (come suggerisce [4])
• pagina: caratteristiche della pagina web associata all’URL
– utilizzo di particolari script o funzioni JS
– presenza di particolari sottoalberi del DOM
– presenza di immagini su host diversi
A seconda del tipo di analisi che si vuole effettuare, algoritmi diversi pren-
dono in considerazione un sottoinsieme di tutte le caratteristiche disponibi-
li; questo è anche funzione dei requisiti che il sistema finale deve rispetta-
re: per motivi di complessità (spaziale o temporale) alcuni algoritmi igno-
rano completamente alcune fonti o escludono alcune caratteristiche. Per
definire questo sottoinsieme principalmente possono essere impiegate due
metodologie:
• manuale: si studiano empiricamente i tratti caratterizzanti di un URL
di phishing e si decide a priori cosa considerare interessante. Per esem-
pio [20] utilizza questa tecnica con successo. Tra i vantaggi di questa
metodologia ci sono:
– la possibilità di ottimizzare questa funzione velocizzando conside-
revolmente la computazione;
– il non dover dipendere da una costosa fase di training;
– la possibilità di intervenire di persona e comprendere quanto buo-
no possa essere un confronto.
Tra gli svantaggi abbiamo:
– la ristrettezza alla vista dello sviluppatore;
– la staticità rispetto al cambiamento;
– la difficoltà nel generalizzare l’algoritmo.
• automatica: il dataset viene fornito in input ad un algoritmo oppor-
tuno che estrae le features più significative. Per esempio [1] dimostra
l’utilizzo di questa tecnica. In questo modo si cerca di evitare sia la
presenza di caratteristiche inutili sia l’assenza di caratteristiche signi-
ficative. Inoltre si apre la possibilità a rendere l’algoritmo adattivo
reiterando la fase di selezione quando nuovi dati sono disponibili; que-
st’ultima proprietà è fondamentale per mantenere l’algoritmo efficace,
come mostrato da [11] in cui vengono comparati classificatori adattivi
e non.
9

17. CAPITOLO 3. STATO DELL’ARTE
3.3 Classificazione
Nella classificazione occorre analizzare le caratteristiche che sono state estrat-
te nel punto precedente per effettuarne l’elaborazione. In generale due sono
gli approcci più diffusi:
• algoritmico: si utilizza un algoritmo appositamente sviluppato per
assegnare ad ogni URL la propria classe. Per la sua stessa natura può
essere impiegato solo se le caratteristiche vengono scelte manualmente
all’inizio.
• machine learning: i più comuni sono: MLP [11], J48/C4.5 [3], SVM
[21]. In questo modo è possibile evitare di dover scegliere a priori
l’importanza di ogni caratteristica. Inoltre questo metodo permette di
aggiornare il classificatore quando nuovi URL sono disponibili. Tutta-
via per implementare questa metodologia è necessaria una costosa fase
di training, continua se si vuole mantenere il sistema aggiornato come
descrive sempre [11].
3.4 Validazione e risultati
La tecnica di validazione più utilizzata è la 10-fold cross validation, ovvero:
si divide il dataset in 10 parti, iterativamente si costruisce un classificatore
utilizzando il 90% dei campioni e si misurano le performances della restante
fetta. In questo modo è possibile ottenere una stima valida della bontà
dell’algoritmo utilizzato.
Un ottimo risultato è stato ottenuto da [3] in cui si raggiunge una pre-
cisione di 98.8%, tuttavia in questo caso è presente un bias non indifferente
nel dataset utilizzato come descritto nella sezione 3.1. Un risultato forse più
significativo è dato da [19], con cui si è ottenuta una precisione di 98% ma
solo per pagine di phishing che imitano i maggiori siti web esistenti e avendo
quindi successo limitato per spear phishing e varianti. Come si vedrà, il lavo-
ro presentato in questa tesi consente di raggiungere precisioni anche migliori
utilizzando una fonte di dati il più omogenea possibile.
10

18. Capitolo 4
Dataset
Come già accennato è importante che il dataset considerato abbia una di-
mensione adeguata: in questo caso si è deciso di puntare ad una dimensione
di 50000 elementi, equamente ripartiti tra URL di phishing e legittimi. Inol-
tre è importante che gli URL utilizzati provengano da fonti omogenee per
evitare di introdurre un bias nei dati; per questo motivo è stata prestata par-
ticolare attenzione alla modalità di raccolta. Purtroppo non è stato possibile
utilizzare una fonte unica per compilare tutto il dataset; si è tuttavia prestata
particolare attenzione alla sorgente dei dati come descritto di seguito.
4.1 URL di phishing
Per ottenere un dataset ideale bisognerebbe avere accesso diretto ai canali
di comunicazione come email o chat ed estrarre gli URL contenuti in quei
messaggi che sono stati classificati come phishing. Un approccio simile non
è praticabile, per questo motivo si è dovuto fare uso di un servizio esterno.
4.1.1 PhishTank
PhishTank è un sito web gestito interamente da volontari grazie al quale
è possibile sottoporre email sospette contenenti URL potenzialmente peri-
colosi, questi verranno poi esaminati ed i risultati resi pubblici. In pratica
PhishTank mette a disposizione alcune API grazie alle quali è possibile ot-
tenere un elenco di URL di siti di phishing verificati e attualmente online.
Questa fonte è stata scelta perché fornisce un archivio affidabile di URL di
phishing certificati, infatti è utilizzata da numerose pubblicazioni scientifiche
sull’argomento. In particolare, grazie ad un’opportuna interfaccia, è possi-
bile ottenere la lista di URL confermati come phishing e navigabili; questa
lista, aggiornata ogni ora, viene filtrata per evitare di considerare troppi URL
afferenti allo stesso dominio. Tale lista rappresenta per noi l’intero dataset
di URL di phishing.
11

19. CAPITOLO 4. DATASET
4.2 URL legittimi
Per ottenere un dataset ideale di URL legittimi bisognerebbe accedere diret-
tamente ai canali di comunicazione ed estrarre gli URL contenuti in messaggi
verificati come leciti. Come illustrato nella sezione 3.1 molte delle pubblica-
zioni e dei lavori sull’argomento si appoggiano a repository di link mantenuti
da volontari che mirano a fornire un elenco di siti legittimi, come per esem-
pio Dmoz. Purtroppo utilizzare queste fonti di dati per gli URL legittimi
presenta dei problemi: la maggior parte di questi indirizzi, infatti, punta ver-
so la pagina principale o comunque qualche pagina di indice; per loro stessa
natura questi URL differiscono da quelli raccolti nel dataset di phishing. Per
eliminare questo bias tra i dati si è dovuto adottare un diverso approccio.
Analizzando alcune comunicazioni legittime è emerso che gli URL utiliz-
zati, nella grande maggioranza dei casi, fanno riferimento a specifiche pagine
di domini legittimi; il problema è quindi stato scomposto in:
1. identificare programmaticamente domini legittimi
2. estrarre pagine specifiche dai domini precedentemente trovati.
Per risolvere il primo problema si sono utilizzate due fonti: Google e
Amazon. Grazie alle API REST di Google è stato possibile effettuare del-
le query ed ottenere i domini che il motore di ricerca reputa legittimi nei
principali ambiti. Amazon, invece, eroga un servizio chiamato Alexa Ran-
king che mira a compilare una classifica dei domini più visitati, mettendola
a disposizione.
Si è quindi utilizzato un modulo sviluppato ad hoc per trovare le sitemap
dei domini così trovati; queste vengono analizzate per estrarre URL specifici
come possono essere quelli che si trovano nelle comunicazioni legittime tra
utenti. Per garantire omogeneità nei dati questo elenco viene ulteriormente
filtrato in modo da evitare di avere troppi URL per ogni dominio.
12

20. Capitolo 5
Caratteristiche
Una volta ottenuto un insieme di URL è necessario analizzarli per estrarne
le caratteristiche utili; queste saranno le features da utilizzare come input
per i vari algoritmi di machine learning che si è studiato. Quando poi verrà
presentato un URL sconosciuto, bisognerà applicare lo stesso meccanismo di
estrazione in maniera tale che il classificatore scelto possa riconoscerlo.
5.1 Raccolta dati
Inizialmente si sono raccolte quante più informazioni possibili per ogni URL
dato, in questo modo è stato possibile scegliere quelle più significative per
il problema trattato. In particolare vengono raccolte e persistite le seguenti
informazioni:
• risposta HTTP: si effettua una semplice richiesta GET verso l’URL
e si registra la risposta;
• pagina: si simula, attraverso un browser headless, la visita dell’URL e
si registra il DOM completo dopo aver atteso che tutte le risorse sono
state caricate correttamente;
• DNS: si registrano le risposte alle query DNS per i tipi A, AAAA, e
NS;
• WHOIS: si registra il record WHOIS corrispondente al dominio del-
l’URL;
• certificato: se il server accetta connessioni sicure, si registra il certi-
ficato del server.
13

21. CAPITOLO 5. CARATTERISTICHE
5.2 Analisi
Dalle informazioni raccolte si procede con l’analisi delle stesse. In particola-
re, dai dati salvati, si estraggono alcune caratteristiche attraverso le quali si
effettuerà la classificazione. Si è deciso di considerare un grande numero di
features, anche se alcune di queste sono interdipendenti o poco correlate con
la classe vengono considerate lo stesso perché in futuro potrebbero acquista-
re maggiore importanza. Sono stati sviluppati 5 diversi estrattori, ognuno
afferente ad una specifica area, descritto di seguito.
5.2.1 Lessicografia URL
L’estrattore lessicografico mira ad analizzare solamente la struttura della
stringa URL. Da questa vengono estratte le caratteristiche riportate in Ta-
bella 5.1. Come era possibile aspettarsi, gli URL di phishing tendono ad
essere più lunghi, e ad avere sottodomini e parole più lunghe; questo perché
ciò consente di ingannare l’utente che tenderà ad ignorare lunghe stringhe
poco significative. Tuttavia questo, da solo, non è sufficiente per discriminare
adeguatamente gli URL.
5.2.2 Struttura pagina
L’estrattore “struttura pagina” utilizza il DOM ottenuto simulando la visita
con un browser per analizzare il contenuto della pagina puntata dall’URL.
In questa fase si estraggono le caratteristiche riportate in Tabella 5.2
La raccolta di questi dati è stata effettuata attaraverso l’uso di un browser
headless che permette di simulare in maniera programmatica l’intero com-
portamento di un browser quando un utente visita l’URL. Questo si è reso
necessario dal momento che molte pagine di phishing utilizzano varie com-
binazioni di iframe, JavaScript e redirect sia lato client che lato server, che
rendono indispensabile un browser completo per renderizzare correttamente
la pagina. Purtroppo non è possibile sapere quando una certa pagina ha rag-
giunto la sua forma finale, per questo motivo si è arbitrariamente deciso di
tenere aperta ogni pagina per 10 secondi e solo dopo catturare un’istantanea
del DOM da cui estrarre le caratteristiche qui riportate.
5.2.3 Informazioni dominio
L’estrattore di informazioni del dominio raccoglie alcuni dati relativi al do-
minio utilizzato nell’URL. La Tabella 5.3 riporta le caratteristiche estratte.
In questo caso ci si è affidati al record WHOIS corrispodente al domi-
nio interessato; visto che le informazioni contenute non sono completamente
standardizzate si è scelto di raccogliere solo le informazioni relative alla data
di creazione del dominio. Investendo più tempo in questa parte potreb-
14

22. CAPITOLO 5. CARATTERISTICHE
Tabella 5.1: Caratteristiche estratte dall’URL
Nome Tipo Descrizione
hasIp booleano True se è presente un indirizzo IP
nell’URL
length numerico Lunghezza complessiva dell’URL
domainLength numerico Lunghezza del dominio dell’URL
pathLength numerico Lunghezza del path dell’URL
queryLength numerico Lunghezza della query dell’URL
fragmentLength numerico Lunghezza del fragment dell’URL
specialChar numerico Numero di caratteri speciali (-, @, &
e la loro controparte in codifica html)
presenti
subdomains numerico Numero di sottodomini
maxSubdomain numerico Lunghezza del sottodominio più lungo
avgWordLength numerico Lunghezza media delle sequenze alfa-
numeriche presenti nell’URL
maxWordLength numerico La lunghezza della sequenza alfanu-
merica più lunga
misplacedtld booleano True se è presente un TLD nel posto
sbagliato
hotWords numerico Numero di parole chiave sospette
presenti
misplacedHttp booleano True se è presente un proto-
collo nel posto sbagliato (es.
http://https-paypal.com )
isHttps booleano True se il protocollo è HTTPS
misplacedWWW booleano True se è presente una qualche va-
riazione di www (vvvvvv, wvvw,
...)
isPunycode booleano True se è utilizzata la codifica
punycode
15

23. CAPITOLO 5. CARATTERISTICHE
Tabella 5.2: Caratteristiche estratte dalla pagina
Nome Tipo Descrizione
isOnline booleano True se l’URL è navigabile
outbound_links numerico Numero di link che puntano verso altri
domini
outbound_links_ratio numerico Rapporto tra link verso l’esterno e link
verso l’interno
outbound_imgs numerico Numero di immagini ospitate su altri
domini
outbound_imgs_ratio numerico Rapporto tra immagini ospitate su
altri domini e immagini locali
hotWords numerico Numero di parole chiave sospette
presenti (login, verification, register,
username, password, credit, card,
account)
forms numerico Numero di form html presenti nella
pagina
hasAlert booleano True se la pagina produce alert
attraverso javscript
redirects numerico Numero di redirect seguiti per rag-
giungere la pagina
jsIsDifferent booleano True se è presente del codice javas-
script che modifica la struttura del
DOM
16

24. CAPITOLO 5. CARATTERISTICHE
Tabella 5.3: Caratteristiche estratte dal server.
Nome Tipo Descrizione
isValid booleano True se il server è raggiungibile
delta_days numerico Differenza in giorni tra la data di
creazione del dominio e la data di
analisi
creation_date data Data di creazione del dominio
rank numerico Posizione in classifica del dominio
secondo AlexaRanking
be essere possibile migliorarla raccogliendo anche informazioni riguardo la
geografia o la proprietà dell’indirizzo IP.
Inoltre si è raccolto anche un punteggio basato sul rank del dominio
secondo AlexaRanking; in questo modo è possibile avere una misura della
quantità di traffico generata.
5.2.4 Caratteristiche certificato
L’estrattore di certificati raccoglie, ove presente, il certificato SSL presentato
dal server. In Tabella 5.4 sono riportate le caratteristiche estratte.
In questo caso viene tentato l’ottenimento del certificato SSL diretta-
mente dal server. A estrazione avvenuta si è riscontrato che il 68.1% dei siti
legittimi possiede un certificato SSL valido, la percentuale nel caso di siti di
phishing scende a 28.1%.
Oltre a parametri diretti, come le date di validità, viene anche effettuato
un fuzzy match tra vari campi testuali del certificato. Questo fuzzy match
consiste in una funzione capace di restituire un valore percentuale relativo
alla somiglianza tra stringhe. Questo valore viene calcolato confrontando tra
loro varie possibile substringhe utilizzando la distanza di Levenshtein.
5.2.5 DNS
L’estrattore di record DNS raccoglie le risposte fornite dal DNS relative
agli eventuali record di tipo A, AAAA, e NS. In Tabella 5.5 sono riportate
le caratteristiche estratte. In particolare vengono effettuate le tre query
corrispondenti e si raccoglie il TTL relativo ad ogni entry. Possibili sviluppi
futuri possono includere, per esempio, informazioni riguardo il Name Server,
la storia dell’indirizzo IP coinvolto, ed eventuali record CNAME.
17

25. CAPITOLO 5. CARATTERISTICHE
Tabella 5.4: Caratteristiche estratte dal certificato SSL.
Nome Tipo Descrizione
isHttps booleano True se è presente una versione https
dell’URL
notBefore data Data di inizio validità del certificato
notAfter data Data di fine validità del certificato
periodValidityDays numerico Duarata, in giorni, del certificato
periodValidForDays numerico Periodo, in giorni, trascorso tra l’inizio
di validità e la data di ispezione
periodValidLeftDays numerico Periodo, in giorni, tra la data di
ispezione e la fine di validità
version numerico Numero di versione dello standard del
certificato
match_icn_io numerico Punteggio fuzzy match tra “issuer
common name” e “issuer organization
name”
match_io_iou numerico Punteggio fuzzy match tra “issuer or-
ganization name” e “issuer organiza-
tional unit name”
match_domain_scn numerico Punteggio fuzzy match tra il nome di
domino e “subject common name”
match_icn_scn numerico Punteggio fuzzy match tra “issuer
common name” e “subject common
name”
match_icn_domain numerico Punteggio fuzzy match tra “issuer
common name” e nome di dominio
isValid booleano True se il certificato è valido
Tabella 5.5: Caratteristiche estratte dal record DNS.
Nome Tipo Descrizione
ttlA numerico Valore del campo TTL del record A
ttlAAAA numerico Valore del campo TTL del record
AAAA
ttlNS numerico Valore del campo TTL del record NS
18

26. CAPITOLO 5. CARATTERISTICHE
5.3 Vettore caratteristiche
Con i risultati dei vari estrattori viene creato un vettore di features, ovvero
un vettore misto che rappresenta un URL come verrà visto dai classificatori.
Prove sperimentali hanno mostrato che la raccolta di queste informazioni
impiega circa 1 secondo. Questo incrementa notevolmente le tempistiche di
collezione dei dati e rende quindi indispensabile scegliere un algoritmo di
classificazione veloce.
Un punto critico è la scelta dei parametri da utilizzare per costruire il
vettore. Da un lato è opportuno considerare meno caratteristiche possibili
per limitare lo spazio della ricerca e velocizzare la classificazione; dall’altro
non si vogliono perdere informazioni importanti. Questo diventa un pro-
blema nel lungo termine, osservando infatti l’evoluzione delle strategie degli
attaccanti nel tempo, è emerso come non siano sempre gli stessi parametri
ad essere significativi. Alla luce di ciò si è deciso di mantenere anche features
apparentemente poco significative e non direttamente correlate con la classe
di appartenenza. Questa scelta sarà confermata dai risultati riportati nel
Capitolo 7, in cui si valutano le prestazioni del modello adattivo.
19

27. Capitolo 6
Classificatore
L’analisi delle caratteristiche presentate nel capitolo precedente ha eviden-
ziato come non sia possibile classificare gli URL sviluppando direttamente
un algoritmo di classificazione. Questo è il motivo principale del perché si
è deciso di impiegare tecniche di Machine Learning per costruire un classifi-
catore. Per scegliere l’algoritmo più adatto al problema affrontato in questa
tesi, sono stati presi in considerazione i seguenti aspetti:
• accuratezza: definita come rapporto tra campioni correttamente clas-
sificati e campioni totali presenti nel dataset di validazione, serve a
fornire una misura della bontà dell’algoritmo;
• rapporto falsi positivi: definito come il rapporto tra campioni clas-
sificati erroneamente come phishing e campioni legittimi, se questo
valore è troppo alto il sistema risulta troppo invasivo per l’utente;
• rapporto falsi negativi: definito come il rapporto tra campioni clas-
sificati erroneamente come legittimi e campioni di phishing, se questo
valore è troppo alto il sistema perde di utilità;
• complessità computazionale: sia temporale che spaziale, serve a
fornire una stima di quante risorse saranno necessarie sia per la fase di
training che per la classificazione.
Per ottenere una stima delle prestazioni di ogni modello si è impiegata
la tecnica della 10-fold cross validation, in quanto è un buon compromesso
tra complessità computazionale e affidabilità dei risultati. Questa tecnica
consiste nel ripetere la seguente procedura:
1. costruire un classificatore con il 90% del dataset disponibile;
2. utilizzare il restante 10% per valutare accuratezza, FPR e FNR espressi
dal classificatore.
20

28. CAPITOLO 6. CLASSIFICATORE
Iterando questa procedura in modo da coprire tutto il dataset e facendo la
media dei risultati ottenuti, si ottiene una misura degli indici del modello che
si otterrebbe costruendo il classificatore con il 100% dei dati. Da notare il
fatto che questa resta una stima: utilizzando solo il 90% dei dati per la fase di
training si ottiene un classificatore diverso rispetto a quello ottenuto con tutti
i dati; tuttavia questo rappresenta comunque una buona approssimazione.
Come baseline di confronto si sono utilizzati i risultati di [16] relativi agli
algoritmi studiati.
6.1 Multilayer Perceptron
Uno dei primi algoritmi sviluppati nella teoria delle reti neurali è il multilayer
perceptron. Un perceptron (Figura 6.1) è un entità che simula, in maniera
semplificata, il funzionamento di un neurone: possiede un certo numero di
input numerici (idealmente continui) ai quali è associato un peso, un output
discreto (solitamente codificato con i valori (0, 1) o (−1, 1)), e una funzione
di soglia. Quando viene presentato un input al perceptron questo combina
linearmente gli input utilizzando i pesi corrispondenti e utilizza la funzione
di soglia per computare il risultato; l’apprendimento avviene modificando
i valori dei pesi. Preso da solo un perceptron è troppo semplice per avere
alcuna utilità, tuttavia è possibile combinare vari perceptron in una rete. In
particolare il multilayer perceptron (Figura 6.2) utilizzato consiste in una
rete di perceptron feed-forward (ovvero senza cicli) formata da almeno tre
strati (uno strato di input, un certo numero di strati “nascosti”, e uno strato
di output) e con la clausola che ogni perceptron riceve i suoi input solamen-
te dallo strato precedente e presenta il proprio output solamente allo strato
successivo. L’apprendimento avviene utilizzando la tecnica della backpro-
pagation minimizzando il tasso d’errore: si valuta, sottoponendo alla rete
campioni di classificazione conosciuta e confrontando il risultato ottenuto
con quello atteso, il contributo agli errori per ogni neurone e si modificano i
suoi pesi di conseguenza. Per estrarre un valore numerico relativo alla confi-
denza della classificazione occorre utilizzare funzioni di attivazione continue,
questo aumenta leggermente la complessità computazionale ma non modifica
la struttura della rete.
Un multilayer perceptron è una delle tipologie di reti neurali più semplici
da realizzare, tuttavia soffre di molti problemi:
• la fase di training è computazionalmente molto complessa;
• a modello costruito è quasi impossibile comprendere cosa la rete abbia
“imparato”;
• è prono all’overfitting;
• è influenzato dal problema dei minimi locali.
21

29. CAPITOLO 6. CLASSIFICATORE
Figura 6.1: Struttura di un perceptron.
Activation
function
w2x2
...
...
wnxn
w1x1
w01
inputs weights
Output
Come si evince dalla Figura 6.3 si riesce a raggiugnere un’accuratezza
di 94.7% con due hidden layers; come si vedrà in seguito questo risultato è
ampiamente migliorabile. Il maggior svantaggio di questo approccio è proprio
la complessità computazionale di training e di validazione, in quanto, con un
dataset di 50000 elementi, si sono misurati tempi di training tra 80 e 250
minuti, lineare con il numero di hidden layer utilizzati.
6.2 Decision Tree
Un albero decisionale è un modello di classificazione rappresentabile attra-
verso un albero in cui ogni nodo interno rappresenta una variabile, ogni arco
rappresenta un valore possibile, e ogni foglia rappresenta un possibile valore
per la classificazione; la classificazione avviene confrontando il campione con
la radice e scendendo ricorsivamente attraverso gli archi corrispondenti. Un
esempio di albero decisionale è mostrato in Figura 6.5.
La costruzione di questo albero avviene attraverso l’analisi del dataset
di training: su ogni nodo si calcola la divergenza di Kullback-Leibler (intui-
tivamente una misura della distanza tra distribuzioni di probabilità) tra la
distribuzione di ogni attributo e la distribuzione della classificazione, in base
a questa si decide quale attributo assegnare a ciascun nodo. Si divide poi il
dataset sulla base dell’attributo scelto e si reitera l’algoritmo, se ad un nodo
sono associati solo campioni di una determinata classe, il nodo diventa una
foglia con associata quella classe. Segue poi una fase di pruning (potatu-
ra) necessaria per evitare l’overfitting; in questa fase si cerca di semplificare
l’albero eliminando i sottoalberi ritenuti inutili attraverso un analisi statisti-
ca dei campioni del dataset di training che possono raggiungere ogni nodo.
Questa fase è controllata dal confidence factor, un parametro limitato tra 0.0
22

30. CAPITOLO 6. CLASSIFICATORE
Figura 6.2: Struttura di un multilayer perceptron.
Input #1
Input #2
Input #3
Input #4
Output
Hidden
layer
Input
layer
Output
layer
e 0.5: a valori minori corrisponde una maggior aggressività della potatura,
al valore limite 0.5 non corrisponde alcuna potatura. Tutto ciò è trattato in
[14] in cui viene presentato lo storico algoritmo C4.5 da cui è stato svilup-
pato l’algoritmo J48 utilizzato in questo caso. Trovare un valore numerico
per la confidenza della classificazione in questo caso è più complesso ma co-
munque fattibile: per ogni foglia occorre ricordare il numero di campioni del
dataset di training che possono raggiungerla e di questi associare alla foglia
la percentuale di campioni relativi alla classe scelta.
Le ragioni che hanno portato a scegliere questo classificatore sono:
• molti lavori scientifici fra cui [16], [3], e [18] lo suggeriscono per affron-
tare questa tipologia di problemi;
• È veloce non solo nella fase di training ma anche nella classificazione
di un campione sconosciuto
• Data la sua natura è possibile controllare l’albero costruito e capire
che cosa è stato “imparato”: questa è una caratteristica che distingue
questo dagli altri algoritmi comuni nel campo del machine learning (i
quali vengono visti di solito come delle black box) ma che è molto utile
in fase di sviluppo anche per capire quali sono gli attributi importanti;
In Figura 6.6 è possibile apprezzare l’influenza del confidence factor, prove
sperimentali hanno mostrato che il miglior compromesso tra complessità del-
l’albero e accuratezza si raggiunge con il valore di 0.35, questo sarà il valore
utilizzato d’ora in avanti per questo algoritmo. Un’accuratezza leggermente
più alta si ottiene con il valore limite di 0.5, ma a questo corrisponde un
albero non potato. Questo non è desiderabile da un lato perché comporta
23

31. CAPITOLO 6. CLASSIFICATORE
Figura 6.3: Accuratezza nel modello a multilayer perceptron. In ascissa si è
riportato il numero di hidden layers. Il dataset consiste in 50000 URL equa-
mente suddivisi nelle due classi. Vengono forniti come confronto i risultati
di [16].
(a) Accuratezza
1 1.5 2 2.5 3 3.5 4
0.945
0.95
MLP
[16]
(b) Tassi d’errore
1 1.5 2 2.5 3 3.5 4
4 · 10−2
6 · 10−2
8 · 10−2
FPR
FNR
un albero più grande e complesso, dall’altro perchè è più prono all’overfitting
nel caso di campioni non presenti nel dataset iniziale.
Con questo approccio si riesce ad ottenere un’accuratezza utile del 96.57%;
per riferimento si riporta il risultato di [16] in cui, utilizzando lo stesso al-
goritmo ma un dataset ridotto (4500 URLs) si ottiene un’accuratezza di
96.46%; il dato simile non deve però trarre in inganno: come affermato nel
Capitolo 4, il dataset preso in considerazione è troppo piccolo rispetto alle
features considerate e questo indice è così alto solo perché la distribuzione
iniziale dei campioni presenta un bias. Con un dataset di 50000 elementi si
è misurato un tempo di training e validazione inferiore al minuto.
6.3 Random Forest
Un classificatore Random Forest è un estensione dell’algoritmo preceden-
te che tenta di minimizzare l’overfitting. Innanzitutto occorre introdurre il
Random Tree ovvero una variante del Decision Tree in cui, ad ogni nodo, in-
vece di selezionare l’attributo con la miglior divergenza di Kullback-Leibler,
se ne sceglie uno a caso tra i k migliori. L’idea alla base è che un albero
così costruito funziona molto bene su una certa parte del dataset. Su questa
idea si sviluppa l’algoritmo Random Forest: vengono infatti creati un certo
24

32. CAPITOLO 6. CLASSIFICATORE
Figura 6.4: Bontà del classificatore MLP nel caso migliore
(a) Matrice di confusione
x Phishing Legit
as Phishing 22673 9727
as Legit 2327 24028
(b) Curva ROC
(Area sottesa: 0.9812)
0 0.5 1
0
0.5
1
FPR
TPR
Figura 6.5: Esempio di albero decisionale: ad ogni nodo corrisponde una va-
riabile e la classificazione (cosa fare durante il pomeriggio) avviene seguendo
i rami che corrispondono al valore delle variabili.
isRaining
mum
STUDY TV
wind
CINEMA TENNIS
true
home out
false
strong calm
numero di Random Trees, nella fase di classificazione si prende semplice-
mente la media dei risultati dei singoli alberi. In questo modo è possibile
sfruttare alberi decisionali profondi e complessi senza rischiare l’overfitting,
che viene ridotto grazie alla grande quantità di alberi diversi. Inoltre è pos-
sibile ottenere un valore numerico legato alla confidenza della classificazione
in maniera molto semplice: basta utilizzare la media delle classificazioni dei
singoli alberi.
Per questo motivo la sostituzione del classificatore ad albero decisionale
con quest’altro algoritmo è stato un naturale miglioramento. Da un lato si
è persa la possibilità di visualizzazione empirica del classificatore, dall’altro
però si è ottenuto un modello migliore.
Grazie ai risultati riportati in Figura 6.9 si è scelto di utilizzare foreste di
25

33. CAPITOLO 6. CLASSIFICATORE
Figura 6.6: Accuratezza nel modello ad albero decisionale. In ascissa si è
riportato il confidence factor. Il dataset consiste in 50000 URL equamente
suddivisi nelle due classi. Per confronto viene fornita l’accuratezza riportata
da [16] usando lo stesso algoritmo.
(a) Accuratezza
0 0.1 0.2 0.3 0.4 0.5
0.96
0.96
0.96
0.97
0.97
Questo lavoro
[16]
(b) Confronto tra FPR e FNR
0.1 0.2 0.3 0.4 0.5
3.2 · 10−2
3.4 · 10−2
3.6 · 10−2
3.8 · 10−2
4 · 10−2
FPR
FNR
dimensioni pari a 100 perché aumentando ancora questo valore non si ottiene
un miglioramento apprezzabile ma soltanto foreste più complesse. Inoltre la
Figura 6.8 permette di motivare la scelta del paramtero k, ovvero del numero
di attributi tra cui scegliere in maniera casuale quello da associare ad ogni
nodo interno; si è infatti scelto un valore pari a 6.
Ulteriori prove sperimentali hanno portato alla scelta dei restanti para-
metri e si è raggiunta un’accuratezza di 98.38%; sempre per riferimento si
riporta il risultato di [16] in cui, utilizzandoun approccio simile si ottiene
un’accuratezza di 97.07%. Con un dataset di 50000 elementi si è misurato
un tempo di validazione e training medio di 7 minuti.
26

34. CAPITOLO 6. CLASSIFICATORE
Figura 6.7: Bontà del classificatore Decision Tree nel caso migliore
(a) Matrice di confusione
x Phishing Legit
as Phishing 23657 538
as Legit 1348 24462
(b) Curva ROC
(Area sottesa: 0.9802)
0 0.5 1
0
0.5
1
FPR
TPR
Figura 6.8: Accuratezza nel modello a foresta casuale. Il dataset è costi-
tuito da 50000 URL divisi equamente tra le due classi possibili. In ascissa
è riportato il parametro k (numero di attributi tra cui scegliere quello da
associare a ciascun nodo interno). Le foreste considerate contano 100 alberi
ciascuna. Vengono forniti come confronto i risultati di [16] utilizzando lo
stesso algoritmo.
(a) Accuratezza
0 5 10 15
0.97
0.975
0.98
0.985
Questo lavoro
[16]
(b) Confronto FPR e FNR
2 4 6 8 10 12 14 16
1.5 · 10−2
1.6 · 10−2
1.7 · 10−2
1.8 · 10−2
1.9 · 10−2
2 · 10−2
FPR
FNR
27

35. CAPITOLO 6. CLASSIFICATORE
Figura 6.9: Accuratezza nel modello a foresta casuale. Il dataset è costituito
da 50000 URL divisi equamente tra le due classi possibili. In ascissa è ripor-
tata la dimensione della foresta. Le foreste considerate sono state costruite
con k = 6. Vengono forniti come confronto i risultati di [16] utilizzando lo
stesso algoritmo.
(a) Accuratezza
0 50 100 150 200
0.97
0.97
0.97
0.98
0.98
0.98
0.98
Questo lavoro
[16]
(b) Confronto FPR e FNR
0 50 100 150 200
1.5 · 10−2
2 · 10−2
2.5 · 10−2
FPR
FNR
Figura 6.10: Bontà del classificatore Random Forest nel caso migliore
(a) Matrice di confusione
x Phishing Legit
as Phishing 24311 288
as Legit 689 24712
(b) Curva ROC
(Area sottesa: 0.9987)
0 0.5 1
0
0.5
1
FPR
TPR
28

36. Capitolo 7
Adattamento
Per garantire una maggiore robustezza del sistema costruito è stato necessa-
rio ipotizzare una modalità attraverso la quale il classificatore possa conti-
nuamente adattarsi ai cambiamenti delle strategie di costruzione delle pagine
di phishing. Il problema principale da affrontare in questo ambito è la dimen-
sione del dataset: non è infatti computazionalmente trattabile continuare a
raccogliere dati e costruire un nuovo classificatore con il dataset ingrandi-
to. Si è quindi sviluppato un algoritmo che permetta al modello di evolvere
senza inficiare l’accuratezza.
Periodicamente, quando sono disponibili nuovi dati, si costruisce un nuo-
vo dataset campionando i dati con probabilità proporzionale alla loro data
di inserimento. Da questo dataset si costruisce un nuovo validatore e lo si
valuta applicando la 10-fold cross validation sul nuovo dataset per ottenere
una misura dell’accuratezza; con lo stesso dataset e con la stessa metodologia
si valuta anche l’accuratezza del vecchio classificatore. Se, reiterando que-
sto procedimento un certo numero di volte con dataset diversi, si riesce ad
ottenere un classificatore migliore, allora lo si sostituisce a quello corrente.
Perché questo modello funzioni, occorre scegliere un intervallo di tempo
appropriato: se l’adattamento è troppo frequente è inutile, in quanto i pochi
dati raccolti non sono significativi e si utilizzano troppe risorse, se è troppo
poco frequente aumenta il tempo di reazione a fronte dell’impego di nuove
tecniche di phishing.
Come mostrato in Figura 7.1, in cui è possibile apprezzare la progressiva
discrepanza tra il modello statico e il modello adattivo, l’adattamento è
fondamentale per mantenere il modello valido nel tempo. Si nota infatti come
il modello adattivo subisce un lieve miglioramento dopo qualche iterazione
e resta poi costante, il modello statico invece peggiora con il passare del
tempo.
29

37. CAPITOLO 7. ADATTAMENTO
Figura 7.1: Performance con il passare del tempo. In ascissa è presentato il
rapporto normalizzato tra istanze classificate erroneamente e istanze totali
(utilizzando la 10-fold cross validation), in ordinata la data di esecuzione dei
test.
09/09 14/09 19/09 24/09 29/09 04/10 09/10
0
0.5
1
1.5
2
Modello dinamico
Modello statico
Differenza
30

38. Capitolo 8
Validazione esterna
Per valutare la bontà del classificatore costruito si è deciso di confrontarne
le capacità con quelle di un prodotto enterprise.
8.1 Symantec RuleSpace
Symantec RuleSpace è un prodotto commerciale che incorpora database di
classificazione degli URL Web consolidati e riconosciuti a livello globale con
analisi in tempo reale1. Essendo un prodotto commerciale non è possibi-
le sapere come la classificazione venga eseguita né quanto affidabile questa
possa essere, tuttavia, vista la reputazione di Symantec, è lecito utilizzare
questa applicazione per un confronto. È stata utilizzata una API che rispon-
de con una lista di categorie per ogni URL fornito in ingresso; poiché una
di queste categorie è proprio phishing si è potuto utilizzare questo servizio
per confrontare direttamente i risultati ottenuti dal classificatore costruito
in precedenza.
8.2 Risultati
Per ottenere dati significativi si è applicata una tecnica simile alla 10-fold
cross validation, dividendo il dataset in 10 “fette” e, iterativamente, costruen-
do un classificatore con il 90% dei dati ed analizzando la classificazione della
fetta esclusa. In particolare si sono contati:
• campioni classificati correttamente da entrambi
• campioni classificati correttamente solo dal classificatore RandomFo-
rest oggetto di questa tesi
• campioni classificati correttamente solo da Symantec RuleSpace
1
https://www.symantec.com/it/it/products/rulespace
31

39. CAPITOLO 8. VALIDAZIONE ESTERNA
Tabella 8.1: Risultati della comparazione con Symantec RuleSpace. Il
dataset comprende 44630 URL equamente divisi tra phishing e legittimi.
Algoritmo corretto URL legittimi URL di phishing
Entrambi 21725 19028
Solo Random Forest 0 2893
Solo Symantec RuleSpace 594 372
Nessuno 0 18
• campioni classificati non correttamente da entrambi
I risultati di questa analisi sono riportati in Tabella 8.1.
Si nota innanzitutto che i risultati differiscono di pochi punti percentuale,
questo è un punto a favore della bontà del risultato ottenuto. Inoltre il basso
numero di errori dell’applicazione enterprise convalida la bontà del dataset
costruito.
Un altro dato di interesse è costituito dal fatto che Symantec RuleSpace
ha un numero di falsi positivi pari a 0, ovvero tutti gli URL che l’applica-
zione riconosce come phishing lo sono. Questa è una caratteristica molto
apprezzata dagli utenti, in quanto non vengono mai bloccati URL legittimi.
8.3 Integrazione
Un altro dato molto importante è il numero di URL che nessuno dei due
approcci ha riconosciuto correttamente. Poiché questo numero è basso si
intuisce che i due algoritmi siano fondamentalmente diversi, quasi comple-
mentari; questo suggerisce che utilizzando entrambi gli approcci sia possibile
ottenere un classificatore migliore dei due presi singolarmente. In partico-
lare si è scelto di utilizzare la classificazione di Symantec RuleSpace come
ulteriore caratteristica del features vector ricevuto in input dalla Random
Forest, in questo modo, come è possibile vedere in Figura 8.1 è stato possi-
bile raggiungere un’accuratezza superiore al 99.5%. Purtroppo così facendo
si perda la caratteristica di avere i falsi positivi a 0, tuttavia questo è un
ottimo compromesso visto il miglioramento ottenuto.
Avendo introdotto una caratteristica estremamente correlata con la clas-
se di appartenenza, occorre prestare particolare attenzione alla scelta del
parametro k. In particolare si è osservato che il risultato migliore si ottiene
con k = 2 anche se le variazioni sono nell’ordine di pochi decimi di punto
percentuale.
Infine occorre ricordare che Symantec RuleSpace fornisce una lista di
categorie associate ad ogni URL, quindi è possibile utilizzare questa ap-
plicazione per migliorare l’accuratezza anche in un classificatore capace di
32

40. CAPITOLO 8. VALIDAZIONE ESTERNA
Figura 8.1: Accuratezza nel modello combinato. Il dataset è costituito da
50000 URL divisi equamente tra le due classi possibili. In ascissa è riportato
il parametro k (numero di attributi tra cui scegliere quello da associare a
ciascun nodo interno). Le foreste considerate contano 100 alberi ciascuna.
(a) Accuratezza
0 5 10 15
0.994
0.9945
0.995
0.9955
accuracy
(b) Confronto FPR e FNR
0 5 10 15
2 · 10−3
4 · 10−3
6 · 10−3
8 · 10−3
FPR
FNR
riconoscere più classi. Questo tuttavia esula dallo scopo del lavoro di questa
tesi e viene proposto come possibile futura estensione.
33

41. CAPITOLO 8. VALIDAZIONE ESTERNA
Figura 8.2: Bontà del classificatore Random Forest nel caso migliore
(a) Matrice di confusione
x Phishing Legit
as Phishing 24735 21
as Legit 265 24979
(b) Curva ROC
(Area sottesa: 0.9999)
0 0.5 1
0
0.5
1
FPR
TPR
34

42. Conclusioni
Il sistema descritto in questo lavoro consiste in un servizio esposto su Inter-
net capace di classificare, con elevato grado di accuratezza, URL nelle classi
“legittimo” o “phishing”. L’analisi degli URL va dalla lessicografia dell’URL
stesso all’analisi del DOM Tree della pagina web puntata, dalle informazioni
contenute nei record DNS a quelle del certificato SSL. Per quanto riguarda
la classificazione effettiva sono stati confrontati 3 algoritmi: Multilayer Per-
ceptron, Decision Tree, e Random Forest. Dopo attente analisi sperimentali
si è scelto di utilizzare Random Forest perché risulta particolarmente preciso
senza essere eccessivamente complesso dal punto di vista computazionale.
Inoltre è stata sviluppata una metodologia per adattare il classificatore nel
tempo, in modo da mantenerlo aggiornato ed evitare che nuove strategie di
phishing lo rendano meno performante.
In conclusione si può affermare che il sistema sviluppato presenta un’ac-
curatezza di 98.4% con una percentuale di URL di phishing classificati come
legittimi (rapporto falsi negativi) di 1.5%.
Si è inoltre validata la bontà del lavoro svolto confrontando i risultati
con l’applicazione commerciale Symantec RuleSpace. Questo confronto ha
evidenziato la validità di entrambi gli approcci, inoltre si è osservato che
gli URL non correttamente classificati da entrambi sono molto pochi; per
questo motivo si è studiata una possibile integrazione tra i due ottenendo
un’accuratezza superiore al 99.5%.
Il lavoro svolto in questo periodo ci ha permesso di far emergere numerosi
spunti per possibili miglioramenti ed estensioni fra cui:
• Approfondire la fase di analisi dei dati iniziali per costruire features
vector più significativi.
• Estendere il sistema per riconoscere URL legati a malware.
• Utilizzare il classificatore con i dati di servizi di Parental Control per
riconoscere altre categorie di URL.
35

43. Appendice A
Tecnologie utilizzate
Per realizzare tutti i componenti software descritti in questo elaborato è stato
scelto Python1 versione 3.5.2 per la sua semplicità e velocità nello sviluppare
proof of concept.
Per la raccolta dati da AlexaRanking e PhishTank si è utilizzata la libreria
requests2. Questa libreria è stata scelta per il grande controllo che offre
nell’effettuare richieste HTTP ed interpretare le risposte.
Per la raccolta di informazioni di Google si è utilizzata la libreria fornita
da Google3 per interfacciarsi con le complesse API esposte ed effettuare le
ricerche necessarie.
Per visitare la pagina si è utilizzato PhantomJS4, un browser headless,
e selenium5, una libreria atta a controllare ed automatizzare l’utilizzo di
browsers tra cui PhantomJS.
Per accedere al database WHOIS si è adattato un wrapper6 attorno al
programma GNU WHOIS per riconoscere e normalizzare le risposte di vari
database.
Per il classificatore si è utilizzata la libreria weka7 che contiene un’im-
plementazione in Java degli algoritmi di machine learning utilizzati. Per
comunicare con questa libreria si è utilizzato javabridge8, che permette di
controllare la JVM programmaticamente attraverso Python.
Si è poi utilizzato il modulo http.server 9 per trasformare l’applicazio-
ne in un servizio HTTP. Infine si è configurato un container Docker10 che
contenesse il servizio in modo da poterlo esporre in produzione.
1
https://www.python.org/
2
http://docs.python-requests.org/en/master/
3
https://developers.google.com/api-client-library/python/
4
http://phantomjs.org/
5
http://www.seleniumhq.org/
6
https://github.com/imfede/python-whois
7
https://www.cs.waikato.ac.nz/ml/weka/
8
https://pypi.python.org/pypi/javabridge/
9
https://docs.python.org/3/library/http.server.html
10
https://www.docker.com/
36

44. Bibliografia
[1] M. Aydin and N. Baykal. Feature extraction and classification phishing
websites based on url. In 2015 IEEE Conference on Communications
and Network Security (CNS), pages 769–770, Sept 2015.
[2] D. D. Caputo, S. L. Pfleeger, J. D. Freeman, and M. E. Johnson. Going
spear phishing: Exploring embedded training and awareness. IEEE
Security Privacy, 12(1):28–38, Jan 2014.
[3] M. Darling, G. Heileman, G. Gressel, A. Ashok, and P. Poornachandran.
A lexical approach for classifying malicious urls. In 2015 International
Conference on High Performance Computing Simulation (HPCS), pages
195–202, July 2015.
[4] Z. Dong, A. Kapadia, J. Blythe, and L. J. Camp. Beyond the lock icon:
real-time detection of phishing websites using public key certificates. In
2015 APWG Symposium on Electronic Crime Research (eCrime), pages
1–12, May 2015.
[5] M. N. Feroz and S. Mengel. Phishing url detection using url ranking. In
2015 IEEE International Congress on Big Data, pages 635–638, June
2015.
[6] V. R. Hawanna, V. Y. Kulkarni, and R. A. Rane. A novel algorithm
to detect phishing urls. In 2016 International Conference on Automa-
tic Control and Dynamic Optimization Techniques (ICACDOT), pages
548–552, Sept 2016.
[7] J. Al Helou and S. Tilley. Multilingual web sites: Internationalized
domain name homograph attacks. In 2010 12th IEEE International
Symposium on Web Systems Evolution (WSE), pages 89–92, Sept 2010.
[8] M. Khonji, A. Jones, and Y. Iraqi. A novel phishing classification based
on url features. In 2011 IEEE GCC Conference and Exhibition (GCC),
pages 221–224, Feb 2011.
[9] M. S. Lin, C. Y. Chiu, Y. J. Lee, and H. K. Pao. Malicious url filtering
- a big data application. In 2013 IEEE International Conference on Big
Data, pages 589–596, Oct 2013.
37

45. BIBLIOGRAFIA
[10] Justin Ma, Lawrence K. Saul, Stefan Savage, and Geoffrey M. Voelker.
Beyond blacklists: Learning to detect malicious web sites from suspi-
cious urls. 15th ACM SIGKDD International Conference on Knowledge
Discovery and Data Mining, pages 1245–1253, Jul 2009.
[11] Justin Ma, Lawrence K. Saul, Stefan Savage, and Geoffrey M. Voelker.
Identifying suspicious urls: An application of large-scale online learning.
In Proceedings of the 26th Annual International Conference on Machine
Learning, ICML ’09, pages 681–688, New York, NY, USA, 2009. ACM.
[12] R. M. Mohammad, F. Thabtah, and L. McCluskey. Intelligent rule-
based phishing websites classification. IET Information Security,
8(3):153–160, May 2014.
[13] L. A. T. Nguyen, B. L. To, H. K. Nguyen, and M. H. Nguyen. A novel ap-
proach for phishing detection using url-based heuristic. In 2014 Interna-
tional Conference on Computing, Management and Telecommunications
(ComManTel), pages 298–303, April 2014.
[14] J. Ross Quinlan. C4.5: Programs for Machine Learning. Morgan
Kaufmann Publishers Inc., San Francisco, CA, USA, 1993.
[15] Symantec. Internet security threat report. Symantec Intelligence
Resources, 22, April 2017.
[16] Pradeepthi K V and Kannan A. Performance study of classification tech-
niques for phishing url detection. In 2014 Sixth International Conference
on Advanced Computing (ICoAC), pages 135–139, Dec 2014.
[17] Colin Whittaker, Brian Ryner, and Marria Nazif. Large-scale automatic
classification of phishing pages. In NDSS ’10, 2010.
[18] L. Xu, Z. Zhan, S. Xu, and K. Ye. An evasion and counter-evasion
study in malicious websites detection. In 2014 IEEE Conference on
Communications and Network Security, pages 265–273, Oct 2014.
[19] Y. Xue, Y. Li, Y. Yao, X. Zhao, J. Liu, and R. Zhang. Phishing sites
detection based on url correlation. In 2016 4th International Conference
on Cloud Computing and Intelligence Systems (CCIS), pages 244–248,
Aug 2016.
[20] J. Zhang, Y. Pan, Z. Wang, and B. Liu. Url based gateway side phishing
detection method. In 2016 IEEE Trustcom/BigDataSE/ISPA, pages
268–275, Aug 2016.
[21] Mouad Zouina and Benaceur Outtaj. A novel lightweight url phi-
shing detection system using svm and similarity index. Human-centric
Computing and Information Sciences, 7(1):17, Jun 2017.
38

46. Ringraziamenti
Alla mia famiglia: mamma Anna, papà Maurizio, e fratello Gabriele che mi
hanno supportato (e sopportato) durante questo lungo e travagliato percorso.
A Lorenzo, senza il quale non avrei mai potuto sperare di raggiungere questo
traguardo.
A Cri, per gli innumerevoli aperitivi e cene, a Seb, per il supporto e la com-
pagnia, a Ste, per essere stato la voce fuori dal coro.
Ai colleghi di Emaze per avermi mostrato come fare le cose a regola d’arte.
Al prof. Fabris per la disponibilità dimostrata nei momenti del bisogno, al
prof. Bartoli per essere stato un eccellente insegnante.
E infine a me stesso, per non essermi mai arreso.
grazie