
Genera impronte digitali uniche delle richieste HTTP di malware da file pcap utilizzando Tshark, consentendo l'identificazione e il raggruppamento di famiglie di malware attraverso l'analisi della struttura delle richieste, degli header e delle caratteristiche del payload.
Strumento per il fingerprinting delle richieste HTTP dei malware. Basato su Tshark e scritto in Python3. Stadio di prototipo funzionante :-)
Il suo obiettivo principale è fornire rappresentazioni uniche (fingerprint) delle richieste dei malware, che aiutano nella loro identificazione. Unico significa qui che ogni fingerprint dovrebbe essere vista solo in una particolare famiglia di malware, ma una famiglia può avere più fingerprint. Hfinger rappresenta la richiesta in una forma più breve rispetto alla stampa dell'intera richiesta, ma comunque interpretabile dall'uomo.
Hfinger può essere utilizzato nell'analisi manuale dei malware ma anche in sistemi sandbox o SIEM. I fingerprint generati sono utili per raggruppare le richieste, individuare le richieste di particolari famiglie di malware, identificare diverse operazioni di una famiglia, o scoprire richieste dannose sconosciute omesse da altri sistemi di sicurezza ma che condividono il fingerprint.
Un articolo accademico accompagna il lavoro su questo strumento, descrivendo, ad esempio, la motivazione delle scelte progettuali, e la valutazione dello strumento rispetto a p0f, FATT e Mercury.
L'assunzione di base di questo progetto è che le richieste HTTP di diverse famiglie di malware sono più o meno uniche, quindi possono essere fingerprintate per fornire una qualche forma di identificazione. Hfinger conserva informazioni sulla struttura e sui valori di alcune intestazioni per fornire mezzi per ulteriori analisi. Ad esempio, il raggruppamento di richieste simili - al momento, è ancora un lavoro in corso.
Dopo l'analisi delle richieste HTTP e delle intestazioni dei malware, abbiamo identificato alcune parti delle richieste come le più distintive. Queste includono:
Inoltre, sono state considerate anche alcune caratteristiche standard dell'URL della richiesta. Tutte queste parti sono state tradotte in un insieme di caratteristiche, descritte in dettaglio qui.
Le caratteristiche sopra descritte vengono tradotte in una rappresentazione di lunghezza variabile, che è il fingerprint effettivo. A seconda della modalità di report, vengono utilizzate caratteristiche diverse per il fingerprinting delle richieste. Maggiori informazioni su queste modalità sono presentate di seguito. Il processo di selezione delle caratteristiche sarà descritto nel prossimo articolo accademico.
Requisiti minimi necessari prima dell'installazione:
Python >= 3.3,Tshark >= 2.2.0.Installazione disponibile da PyPI:
pip install hfinger
Hfinger è stato testato su Xubuntu 22.04 LTS con il pacchetto tshark versione 3.6.2,
ma dovrebbe funzionare con versioni più vecchie come 2.6.10 su Xubuntu 18.04 o 3.2.3 su Xubuntu 20.04.
Si prega di notare che come per qualsiasi PoC, si dovrebbe eseguire Hfinger in un ambiente separato, almeno con un ambiente virtuale Python. La sua configurazione non è trattata qui, ma puoi provare questo tutorial.
Dopo l'installazione, puoi chiamare lo strumento direttamente dalla riga di comando con hfinger
o come modulo Python con python -m hfinger.
Ad esempio:
foo@bar:~$ hfinger -f /tmp/test.pcap
[{"epoch_time": "1614098832.205385000", "ip_src": "127.0.0.1", "ip_dst": "127.0.0.1", "port_src": "53664", "port_dst": "8080", "fingerprint": "2|3|1|php|0.6|PO|1|us-ag,ac,ac-en,ho,co,co-ty,co-le|us-ag:f452d7a9/ac:as-as/ac-en:id/co:Ke-Al/co-ty:te-pl|A|4|1.4"}]
L'aiuto può essere visualizzato con i flag brevi -h o lunghi --help:
usage: hfinger [-h] (-f FILE | -d DIR) [-o output_path] [-m {0,1,2,3,4}] [-v]
[-l LOGFILE]
Hfinger - fingerprinting malware HTTP requests stored in pcap files
optional arguments:
-h, --help show this help message and exit
-f FILE, --file FILE Read a single pcap file
-d DIR, --directory DIR
Read pcap files from the directory DIR
-o output_path, --output-path output_path
Path to the output directory
-m {0,1,2,3,4}, --mode {0,1,2,3,4}
Fingerprint report mode.
0 - similar number of collisions and fingerprints as mode 2, but using fewer features,
1 - representation of all designed features, but a little more collisions than modes 0, 2, and 4,
2 - optimal (the default mode),
3 - the lowest number of generated fingerprints, but the highest number of collisions,
4 - the highest fingerprint entropy, but slightly more fingerprints than modes 0-2
-v, --verbose Report information about non-standard values in the request
(e.g., non-ASCII characters, no CRLF tags, values not present in the configuration list).
Without --logfile (-l) will print to the standard error.
-l LOGFILE, --logfile LOGFILE
Output logfile in the verbose mode. Implies -v or --verbose switch.
Devi fornire un percorso a un file pcap (-f), o una directory (-d) con file pcap. L'output è in formato JSON. Verrà stampato sull'output standard o nella directory fornita (-o) utilizzando il nome del file sorgente. Ad esempio, l'output del comando:
hfinger -f example.pcap -o /tmp/pcap
verrà salvato in:
/tmp/pcap/example.pcap.json
La modalità di report -m/--mode può essere utilizzata per cambiare la modalità di report predefinita fornendo un intero nell'intervallo 0-4.
Le modalità differiscono per le caratteristiche della richiesta rappresentate o per le modalità di arrotondamento.
La modalità predefinita (2) è stata scelta da noi per rappresentare tutte le caratteristiche solitamente utilizzate durante l'analisi delle richieste,
ma offre anche un basso numero di collisioni e di fingerprint generati.
Con altre modalità, puoi raggiungere obiettivi diversi.
Ad esempio, nella modalità 3 ottieni un numero inferiore di fingerprint generati
ma una maggiore probabilità di collisione tra famiglie di malware. Se non sei sicuro, non devi cambiare nulla.
Maggiori informazioni sulle modalità di report sono qui.
A partire dalla versione 0.2.1 Hfinger è meno verboso. Dovresti usare -v/--verbose se desideri ricevere
informazioni su valori non standard delle intestazioni incontrati, caratteri non ASCII nella parte non payload della
richiesta, mancanza di tag CRLF (\r\n\r\n) e altri problemi con le richieste analizzate che non sono errori dell'applicazione.
Quando si incontrano tali problemi in modalità verbose, verranno stampati sull'output standard degli errori.
Puoi anche salvare il log in una posizione definita usando il flag -l/--log (implica -v/--verbose).
I dati del log verranno aggiunti al file di log.
A partire dalla versione 0.2.0, Hfinger supporta l'importazione in altre applicazioni Python.
Per usarlo nella tua app, importa semplicemente la funzione hfinger_analyze da hfinger.analysis
e chiamala con il percorso del file pcap e la modalità di report.
Il risultato restituito è una lista di dizionari con i risultati del fingerprinting.
Ad esempio:
from hfinger.analysis import hfinger_analyze
pcap_path = "SPECIFY_PCAP_PATH_HERE"
reporting_mode = 4
print(hfinger_analyze(pcap_path, reporting_mode))
A partire dalla versione 0.2.1 Hfinger utilizza il modulo logging per registrare informazioni su valori non standard delle intestazioni incontrati,
caratteri non ASCII nella parte non payload della richiesta,
mancanza di tag CRLF (\r\n\r\n) e altri problemi con le richieste analizzate che non sono errori dell'applicazione.
Hfinger crea il proprio logger utilizzando il nome hfinger, ma senza una configurazione precedente, le informazioni di log vengono di fatto scartate.
Se desideri ricevere queste informazioni di log, prima di chiamare hfinger_analyze, dovresti configurare il logger hfinger,
impostare il livello di log su logging.INFO, configurare il gestore del log secondo le tue esigenze, aggiungerlo al logger.
Maggiori informazioni sono disponibili nella docstring della funzione hfinger_analyze.
Un fingerprint si basa sulle caratteristiche estratte da una richiesta. L'utilizzo di specifiche caratteristiche dall'elenco completo dipende dalla modalità di report scelta da un elenco predefinito (maggiori informazioni sulle modalità di report sono qui). La figura sottostante rappresenta la creazione di un fingerprint esemplificativo nella modalità di report predefinita.

Tre parti della richiesta vengono analizzate per estrarre informazioni: URI,
struttura delle intestazioni (inclusi metodo e versione del protocollo) e payload.
Le caratteristiche particolari del fingerprint sono separate usando | (pipe). Il fingerprint finale generato per la richiesta POST
dell'esempio è:
2|3|1|php|0.6|PO|1|us-ag,ac,ac-en,ho,co,co-ty,co-le|us-ag:f452d7a9/ac:as-as/ac-en:id/co:Ke-Al/co-ty:te-pl|A|4|1.4
La creazione delle caratteristiche è descritta di seguito nell'ordine di apparizione nel fingerprint.
Innanzitutto, vengono estratte le caratteristiche dell'URI:
log10(43)≈2),log10(20/3)≈1),hfinger/configs/extensions.txt,log10(4)≈0.6).In secondo luogo, vengono analizzate le caratteristiche della struttura delle intestazioni:
PO),Per rappresentare l'ordine delle intestazioni nella richiesta, il nome di ogni intestazione viene codificato secondo lo schema in
hfinger/configs/headerslow.json, ad esempio, l'intestazione User-Agent è codificata come us-ag.
I nomi codificati sono separati da ,. Se il nome dell'intestazione non inizia con una lettera maiuscola
(o una qualsiasi delle sue parti quando si analizzano intestazioni composte come Accept-Encoding),
la rappresentazione codificata è preceduta da !.
Se il nome dell'intestazione non è nell'elenco delle intestazioni note,
viene sottoposto a hash utilizzando FNV1a hash,
e l'hash viene utilizzato come codifica.
Quando si analizzano le intestazioni popolari, la richiesta viene controllata per vedere se appaiono in essa. Queste intestazioni sono:
Quando l'intestazione viene trovata nella richiesta, il suo valore viene verificato rispetto a una tabella di
valori tipici per creare coppie rappresentazione_nome_intestazione:rappresentazione_valore.
Il nome dell'intestazione viene codificato secondo lo schema in hfinger/configs/headerslow.json (come presentato prima),
e il valore viene codificato secondo lo schema memorizzato nella directory hfinger/configs o nel file configs.py,
a seconda dell'intestazione. Nell'esempio precedente Accept è codificato come ac
e il suo valore */* come as-as (asterisk-asterisk), dando ac:as-as.
Le coppie vengono inserite nel fingerprint nell'ordine di apparizione nella richiesta e sono delimitate usando /.
Se il valore dell'intestazione non può essere trovato nella tabella di codifica, viene sottoposto a hash utilizzando FNV1a hash.
Se il valore dell'intestazione è composto da più valori, vengono tokenizzati per fornire un elenco di valori delimitati da ,,
ad esempio, darebbe . Tuttavia, a questo punto dello sviluppo, se il valore dell'intestazione
contiene un tag "quality value" (), l'intero valore viene codificato con il suo hash FNV1a.
Infine, i valori delle intestazioni e sono direttamente codificati utilizzando i loro hash FNV1a.
Infine, nelle caratteristiche del payload:
N, e con A altrimenti,Hfinger opera in cinque modalità di report, che differiscono per le caratteristiche rappresentate nel fingerprint, quindi
per le informazioni estratte dalle richieste. Queste sono (con il numero utilizzato nella configurazione dello strumento):
0 - produce un numero simile di collisioni e fingerprint rispetto alla modalità 2, ma utilizzando meno caratteristiche,1 - rappresenta tutte le caratteristiche progettate, ma produce un numero leggermente maggiore di collisioni rispetto alle modalità 0, 2 e 4,2 - ottimale (la modalità predefinita), rappresenta tutte le caratteristiche solitamente utilizzate durante l'analisi delle richieste,
ma offre anche un basso numero di collisioni e di fingerprint generati,3 - produce il numero più basso di fingerprint generati tra tutte le modalità,
ma raggiunge il numero più alto di collisioni,4 - offre la massima entropia del fingerprint,
ma genera anche leggermente più fingerprint rispetto alle modalità 0-2.Le modalità sono state scelte per ottimizzare la capacità di Hfinger di identificare in modo univoco le famiglie di malware
rispetto al numero di fingerprint generati. Le modalità 0, 2 e 4 offrono un numero simile di collisioni
tra famiglie di malware, tuttavia, la modalità 4 genera un numero leggermente maggiore di fingerprint rispetto alle altre due.
La modalità 2 rappresenta più caratteristiche della richiesta rispetto alla modalità 0 con un numero comparabile di fingerprint generati e collisioni.
La modalità 1 è l'unica che rappresenta tutte le caratteristiche progettate, ma aumenta il numero di collisioni di quasi due volte
rispetto alle modalità 0, 1 e 4. La modalità 3 produce almeno due volte meno fingerprint rispetto alle altre modalità, ma
introduce circa nove volte più collisioni. La descrizione di tutte le caratteristiche progettate è qui.
Le modalità sono costituite da caratteristiche (nell'ordine di apparizione nel fingerprint):
0:
1:
2:
3:

Accept: */*, text/*ac:as-as,te-asq=4: