cert-polska/hfingerGénère des empreintes uniques de requêtes HTTP de malwares à partir de fichiers pcap en utilisant Tshark, permettant l'identification et le regroupement de familles de malwares via l'analyse de la structure des requêtes, des en-têtes et des caractéristiques de la charge utile.
Outil pour l'empreinte numérique (fingerprinting) des requêtes HTTP de malwares. Basé sur Tshark et écrit en Python3. Stade de prototype fonctionnel :-)
Son objectif principal est de fournir des représentations uniques (empreintes) des requêtes de malwares, ce qui facilite leur identification. Unique signifie ici que chaque empreinte ne devrait être observée que dans une seule famille de malwares particulière, mais une famille peut avoir plusieurs empreintes. Hfinger représente la requête sous une forme plus courte que l'affichage complet de la requête, mais toujours interprétable par un humain.
Hfinger peut être utilisé dans l'analyse manuelle de malwares mais aussi dans des systèmes de sandbox ou des SIEMs. Les empreintes générées sont utiles pour regrouper des requêtes, identifier des requêtes appartenant à des familles de malwares particulières, distinguer différentes opérations d'une même famille, ou découvrir des requêtes malveillantes inconnues négligées par d'autres systèmes de sécurité mais qui partagent une empreinte.
Un article académique accompagne le travail sur cet outil, décrivant par exemple la motivation des choix de conception, et l'évaluation de l'outil par rapport à p0f, FATT, et Mercury.
L'hypothèse de base de ce projet est que les requêtes HTTP de différentes familles de malwares sont plus ou moins uniques, de sorte qu'elles peuvent être empreintes (fingerprinted) pour fournir une forme d'identification. Hfinger conserve des informations sur la structure et les valeurs de certains en-têtes pour permettre une analyse plus poussée. Par exemple, le regroupement de requêtes similaires - pour l'instant, il s'agit encore d'un travail en cours.
Après analyse des requêtes HTTP et des en-têtes de malwares, nous avons identifié certaines parties des requêtes comme étant les plus distinctives. Celles-ci incluent :
De plus, certaines caractéristiques standard de l'URL de la requête ont également été prises en compte. Toutes ces parties ont été traduites en un ensemble de caractéristiques, décrites en détail ici.
Les caractéristiques ci-dessus sont traduites en une représentation de longueur variable, qui est l'empreinte réelle. Selon le mode de rapport, différentes caractéristiques sont utilisées pour empreinter les requêtes. Plus d'informations sur ces modes sont présentées ci-dessous. Le processus de sélection des caractéristiques sera décrit dans le prochain article académique.
Prérequis minimum avant l'installation :
Python >= 3.3,Tshark >= 2.2.0.Installation disponible depuis PyPI :
pip install hfinger
Hfinger a été testé sur Xubuntu 22.04 LTS avec le paquet tshark en version 3.6.2, mais devrait fonctionner avec des versions plus anciennes comme 2.6.10 sur Xubuntu 18.04 ou 3.2.3 sur Xubuntu 20.04.
Veuillez noter que comme pour toute preuve de concept (PoC), vous devriez exécuter Hfinger dans un environnement isolé, au moins avec un environnement virtuel Python. Sa configuration n'est pas couverte ici, mais vous pouvez essayer ce tutoriel.
Après installation, vous pouvez appeler l'outil directement depuis une ligne de commande avec hfinger ou en tant que module Python avec python -m hfinger.
Par exemple :
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'aide peut être affichée avec les options courtes -h ou longues --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.
Vous devez fournir un chemin vers un fichier pcap (-f), ou un répertoire (-d) contenant des fichiers pcap. La sortie est au format JSON. Elle sera affichée sur la sortie standard ou dans le répertoire fourni (-o) en utilisant le nom du fichier source. Par exemple, la sortie de la commande :
hfinger -f example.pcap -o /tmp/pcap
sera enregistrée dans :
/tmp/pcap/example.pcap.json
Le mode de rapport -m/--mode peut être utilisé pour changer le mode de rapport par défaut en fournissant un entier dans la plage 0-4. Les modes diffèrent selon les caractéristiques de requête représentées ou les modes d'arrondi. Le mode par défaut (2) a été choisi par nous pour représenter toutes les caractéristiques qui sont habituellement utilisées lors de l'analyse des requêtes, mais il offre également un faible nombre de collisions et d'empreintes générées. Avec les autres modes, vous pouvez atteindre différents objectifs. Par exemple, dans le mode 3, vous obtenez un nombre plus faible d'empreintes générées mais une probabilité plus élevée de collision entre familles de malwares. Si vous n'êtes pas sûr, vous n'avez rien à changer. Plus d'informations sur les modes de rapport sont ici.
À partir de la version 0.2.1, Hfinger est moins verbeux. Vous devez utiliser -v/--verbose si vous souhaitez recevoir des informations sur les valeurs non standard des en-têtes rencontrées, les caractères non-ASCII dans la partie non-charge utile de la requête, l'absence de balises CRLF (\r\n\r\n), et d'autres problèmes avec les requêtes analysées qui ne sont pas des erreurs d'application. Lorsque de tels problèmes sont rencontrés en mode verbeux, ils seront imprimés sur la sortie d'erreur standard. Vous pouvez également enregistrer le journal dans un emplacement défini en utilisant l'option -l/--log (qui implique -v/--verbose). Les données du journal seront ajoutées au fichier journal.
À partir de la version 0.2.0, Hfighter permet l'importation dans d'autres applications Python. Pour l'utiliser dans votre application, importez simplement la fonction hfinger_analyze depuis hfinger.analysis et appelez-la avec le chemin du fichier pcap et le mode de rapport. Le résultat retourné est une liste de dictionnaires avec les résultats d'empreinte numérique.
Par exemple :
from hfinger.analysis import hfinger_analyze
pcap_path = "SPECIFY_PCAP_PATH_HERE"
reporting_mode = 4
print(hfinger_analyze(pcap_path, reporting_mode))
À partir de la version 0.2.1, Hfinger utilise le module logging pour enregistrer des informations sur les valeurs non standard des en-têtes rencontrées, les caractères non-ASCII dans la partie non-charge utile de la requête, l'absence de balises CRLF (\r\n\r\n), et d'autres problèmes avec les requêtes analysées qui ne sont pas des erreurs d'application. Hfinger crée son propre logger avec le nom hfinger, mais sans configuration préalable, les informations de journal sont en pratique ignorées. Si vous souhaitez recevoir ces informations de journal, avant d'appeler hfinger_analyze, vous devez configurer le logger hfinger, définir le niveau de journalisation sur logging.INFO, configurer un gestionnaire de journal selon vos besoins, et l'ajouter au logger. Plus d'informations sont disponibles dans la docstring de la fonction hfinger_analyze.
Une empreinte est basée sur des caractéristiques extraites d'une requête. L'utilisation de caractéristiques particulières parmi la liste complète dépend du mode de rapport choisi parmi une liste prédéfinie (plus d'informations sur les modes de rapport sont ici). La figure ci-dessous représente la création d'une empreinte exemplaire dans le mode de rapport par défaut.
Trois parties de la requête sont analysées pour extraire des informations : l'URI, la structure des en-têtes (incluant la méthode et la version du protocole), et la charge utile. Les caractéristiques particulières de l'empreinte sont séparées par | (pipe). L'empreinte finale générée pour la requête POST de l'exemple est :
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 création des caractéristiques est décrite ci-dessous dans l'ordre d'apparition dans l'empreinte.
Premièrement, les caractéristiques de l'URI sont extraites :
log10(43)≈2),log10(20/3)≈1),hfinger/configs/extensions.txt,log10(4)≈0.6).Deuxièmement, les caractéristiques de la structure des en-têtes sont analysées :
PO),Pour représenter l'ordre des en-têtes dans la requête, chaque nom d'en-tête est encodé selon le schéma dans hfinger/configs/headerslow.json, par exemple, l'en-tête User-Agent est encodé comme us-ag. Les noms encodés sont séparés par ,. Si le nom de l'en-tête ne commence pas par une lettre majuscule (ou l'une de ses parties lors de l'analyse d'en-têtes composés comme Accept-Encoding), alors la représentation encodée est préfixée par !. Si le nom de l'en-tête ne figure pas dans la liste des en-têtes connus, il est haché en utilisant le hachage FNV1a, et le hachage est utilisé comme encodage.
Lors de l'analyse des en-têtes courants, on vérifie s'ils apparaissent dans la requête. Ces en-têtes sont :
Lorsque l'en-tête est trouvé dans la requête, sa valeur est vérifiée par rapport à une table de valeurs typiques pour créer des paires représentation_nom_en-tête:représentation_valeur. Le nom de l'en-tête est encodé selon le schéma dans hfinger/configs/headerslow.json (comme présenté précédemment), et la valeur est encodée selon le schéma stocké dans le répertoire hfinger/configs ou le fichier configs.py, selon l'en-tête. Dans l'exemple ci-dessus, Accept est encodé comme ac et sa valeur */* comme as-as (asterisk-asterisk), donnant ac:as-as. Les paires sont insérées dans l'empreinte dans l'ordre d'apparition dans la requête et sont délimitées par /. Si la valeur de l'en-tête ne peut pas être trouvée dans la table d'encodage, elle est hachée en utilisant le hachage FNV1a. Si la valeur de l'en-tête est composée de plusieurs valeurs, elles sont tokenisées pour fournir une liste de valeurs délimitées par ,, par exemple, donnerait . Cependant, à ce stade du développement, si la valeur de l'en-tête contient une balise "quality value" (), alors toute la valeur est encodée avec son hachage FNV1a. Enfin, les valeurs des en-têtes et sont directement encodées en utilisant leurs hachages FNV1a.
Enfin, dans les caractéristiques de la charge utile :
N, et par A sinon,Hfinger fonctionne en cinq modes de rapport, qui diffèrent par les caractéristiques représentées dans l'empreinte, donc les informations extraites des requêtes. Ce sont (avec le numéro utilisé dans la configuration de l'outil) :
0 - produisant un nombre similaire de collisions et d'empreintes que le mode 2, mais en utilisant moins de caractéristiques,1 - représentant toutes les caractéristiques conçues, mais produisant un peu plus de collisions que les modes 0, 2 et 4,2 - optimal (mode par défaut), représentant toutes les caractéristiques qui sont habituellement utilisées lors de l'analyse des requêtes, mais offrant également un faible nombre de collisions et d'empreintes générées,3 - produisant le plus faible nombre d'empreintes générées parmi tous les modes, mais atteignant le plus grand nombre de collisions,4 - offrant la plus haute entropie d'empreinte, mais générant également légèrement plus d'empreintes que les modes 0-2.Les modes ont été choisis afin d'optimiser les capacités de Hfinger à identifier de manière unique les familles de malwares par rapport au nombre d'empreintes générées. Les modes 0, 2 et 4 offrent un nombre similaire de collisions entre familles de malwares, cependant, le mode 4 génère un peu plus d'empreintes que les deux autres. Le mode 2 représente plus de caractéristiques de requête que le mode 0 avec un nombre comparable d'empreintes générées et de collisions. Le mode 1 est le seul à représenter toutes les caractéristiques conçues, mais il augmente le nombre de collisions de presque deux fois par rapport aux modes 0, 1 et 4. Le mode 3 produit au moins deux fois moins d'empreintes que les autres modes, mais il introduit environ neuf fois plus de collisions. La description de toutes les caractéristiques conçues est ici.
Les modes sont constitués des caractéristiques (dans l'ordre d'apparition dans l'empreinte) :
0 :
1 :
2 :
3 :
Accept: */*, text/*ac:as-as,te-asq=4 :