hpthreatresearch/subcrawlFramework modulaire pour découvrir et analyser les répertoires ouverts sur le web. Explore les URLs, extrait le contenu, applique une analyse YARA/ClamAV, et envoie les résultats vers MISP, SQLite ou la console pour le renseignement sur les menaces.
SubCrawl est un framework développé par Patrick Schläpfer, Josh Stroschein et Alex Holland de l’équipe Threat Research de HP Inc. SubCrawl est conçu pour trouver, scanner et analyser des répertoires ouverts. Le framework est modulaire, composé de quatre composants : modules d’entrée, modules de traitement, modules de sortie et le moteur de crawl principal. Les URL sont les valeurs d’entrée principales, que le framework analyse et ajoute à un système de file d’attente avant de les crawler. L’analyse des URL est une première étape importante, car elle prend une URL soumise et génère des URL supplémentaires à crawler en supprimant les sous-répertoires, un par un, jusqu’à ce qu’il n’en reste plus. Ce processus garantit une tentative de scan plus complète d’un serveur web et peut mener à la découverte de contenu supplémentaire. Notamment, SubCrawl n’utilise pas de méthode par force brute pour découvrir des URL. Tout le contenu scanné provient des URL d’entrée, du processus d’analyse de l’URL et de la découverte lors du crawl. Lorsqu’un répertoire ouvert est découvert, le moteur de crawl extrait les liens du répertoire pour évaluation. Le moteur de crawl détermine si le lien est un autre répertoire ou un fichier. Les répertoires sont ajoutés à la file d’attente de crawl, tandis que les fichiers subissent une analyse supplémentaire par les modules de traitement. Des résultats sont générés et stockés pour chaque URL scannée, comme les hachages SHA256 et flous du contenu, la présence d’un répertoire ouvert, ou les correspondances avec des règles YARA. Enfin, les données de résultat sont traitées selon un ou plusieurs modules de sortie, dont il existe actuellement trois. Le premier fournit une intégration avec MISP, le second affiche simplement les données dans la console, et le troisième stocke les données dans une base de données SQLite. Comme le framework est modulaire, il est non seulement facile de configurer les modules d’entrée, de traitement et de sortie souhaités, mais aussi simple de développer de nouveaux modules.
Figure 1 - Architecture de SubCrawl
SubCrawl prend en charge deux modes de fonctionnement différents. Premièrement, SubCrawl peut être démarré en mode exécution unique. Dans ce mode, l’utilisateur fournit les URL à scanner dans un fichier où chaque valeur d’entrée est séparée par un saut de ligne. Le deuxième mode de fonctionnement est le mode service. Dans ce mode, SubCrawl s’exécute en arrière-plan et repose sur les modules d’entrée pour fournir les URL à scanner. La figure 1 montre un aperçu de l’architecture de SubCrawl. Les composants utilisés dans les deux modes de fonctionnement sont en bleu, les composants du mode exécution unique sont en jaune, et les composants du mode service sont en vert.
Selon le mode d’exécution choisi, d’autres conditions préalables doivent être remplies.
SubCrawl est écrit en Python3. De plus, plusieurs paquets sont nécessaires avant d’exécuter SubCrawl. La commande suivante peut être utilisée pour installer tous les paquets requis avant d’exécuter SubCrawl. Depuis le répertoire crawler, exécutez la commande suivante :
$ sudo apt install build-essential
$ pip3 install -r requirements.txt
Si SubCrawl est démarré en mode service, cela peut être fait en utilisant Docker. Pour cette raison, l’installation de Docker et Docker Compose est requise. De bonnes instructions d’installation se trouvent directement sur le site Web de Docker.com.
SubCrawl dispose d’une aide intégrée via l’argument -h/--help ou simplement en exécutant le script sans aucun argument.
******** ** ****** **
**////// /** **////** /**
/** ** **/** ** // ****** ****** *** ** /**
/*********/** /**/****** /** //**//* //////** //** * /** /**
////////**/** /**/**///**/** /** / ******* /** ***/** /**
/**/** /**/** /**//** ** /** **////** /****/**** /**
******** //******/****** //****** /*** //******** ***/ ///** ***
//////// ////// ///// ////// /// //////// /// /// ///
~~ Moissonnage du Web Ouvert ~~
usage: subcrawl.py [-h] [-f FILE_PATH] [-k] [-p PROCESSING_MODULES] [-s STORAGE_MODULES]
optional arguments:
-h, --help show this help message and exit
-f FILE_PATH, --file FILE_PATH
Path of input URL file
-k, --kafka Use Kafka Queue as input
-p PROCESSING_MODULES, --processing PROCESSING_MODULES
Processing modules to be executed comma separated.
-s STORAGE_MODULES, --storage STORAGE_MODULES
Storage modules to be executed comma separated.
Available processing modules:
- ClamAVProcessing
- JARMProcessing
- PayloadProcessing
- TLSHProcessing
- YARAProcessing
Available storage modules:
- ConsoleStorage
- MISPStorage
- SqliteStorage
Ce mode est adapté si vous souhaitez scanner rapidement un nombre gérable de domaines. Pour cela, les URL à scanner doivent être sauvegardées dans un fichier, qui sert ensuite d’entrée pour le crawler. Voici un exemple d’exécution en mode exécution unique, notez que l’argument -f est utilisé avec un chemin vers un fichier.
python3 subcrawl.py -f urls.txt -p YARAProcessing,PayloadProcessing -s ConsoleStorage
Avec le mode service, une plus grande quantité de domaines peut être scannée et les résultats sauvegardés. En fonction du module de stockage sélectionné, les données peuvent ensuite être analysées et évaluées plus en détail. Pour faciliter au maximum l’exécution du mode service pour l’utilisateur, nous avons intégré toutes les fonctionnalités dans une image Docker. En mode service, les domaines à scanner sont obtenus via les modules d’entrée. Par défaut, les nouvelles URL de malwares et de phishing sont téléchargées depuis URLhaus et PhishTank et mises en file d’attente pour le scan. Les modules de traitement et de stockage souhaités peuvent être saisis directement dans le config.yml. Par défaut, les modules de traitement suivants sont activés, utilisant le stockage SQLite :
En plus du module de stockage SQLite, une interface web simple a été développée qui permet de visualiser et de gérer les domaines et URL scannés.
Cependant, si cette interface ne suffit pas pour l’évaluation ultérieure des données, le module de stockage MISP peut être activé en alternative ou en complément. Les paramètres correspondants doivent être configurés dans config.yml sous la section MISP.
Les deux commandes suivantes suffisent pour cloner le dépôt GIT, créer le conteneur Docker et le démarrer directement. Ensuite, l’interface web est accessible à l’adresse https://localhost:8000/. Veuillez noter qu’une fois les conteneurs démarrés, les modules d’entrée commenceront à ajouter des URL à la file d’attente de traitement et le moteur commencera à crawler les hôtes.
git clone https://github.com/hpthreatresearch/subcrawl.git
docker-compose up --build
Les modules d’entrée ne sont utilisés qu’en mode service. Si SubCrawl est démarré en mode exécution unique, un fichier contenant les URL à scanner doit être fourni. Les deux modules d’entrée suivants ont été implémentés.
URLhaus est un service web important qui suit les URL malveillantes. Le service web fournit également des exportations contenant de nouvelles URL détectées. Ces URL de malwares servent d’entrée parfaite pour notre crawler car nous voulons principalement analyser des domaines malveillants. Les URL récemment soumises sont récupérées et les résultats de recherche ne sont pas affinés via la requête API (c’est-à-dire via des tags ou d’autres paramètres disponibles). La requête HTTP effectuée dans ce module d’entrée à l’API URLHaus peut être modifiée pour affiner davantage les résultats obtenus.
PhishTank est un site web qui collecte des URL de phishing. Les utilisateurs ont la possibilité de soumettre de nouvelles pages de phishing trouvées. Une exportation avec des URL de phishing actives peut être générée et téléchargée depuis ce service web via API. C’est donc aussi une collection idéale pour notre crawler.
SubCrawl est livré avec plusieurs modules de traitement. Les modules de traitement suivent tous un comportement similaire quant à la manière dont ils renvoient les résultats au moteur central. Si des correspondances sont trouvées, les résultats sont renvoyés au moteur central et ensuite fournis aux modules de stockage. Voici une liste des modules de traitement.
Le module de traitement SDHash est utilisé pour calculer un hachage de similarité de la réponse HTTP. La taille minimale du contenu doit être de 512 octets pour pouvoir calculer un hachage avec succès. C’est probablement le module de traitement le plus compliqué à installer, car il nécessite Protobuf et selon l’hôte cible, il doit être recompilé. Par conséquent, ce module de traitement est désactivé par défaut. Une version déjà compilée se trouve dans crawler/processing/minisdhash/ qui nécessite protobuf-2.5.0 et python3.6. Ces binaires ont été compilés sur un Ubuntu 18.04.5 LTS x64. Suivez les instructions d’installation :
# Installation de Protobuf
> apt-get update
> apt-get -y install libssl-dev libevent-pthreads-2.1-6 libomp-dev g++
> apt-get -y install autoconf automake libtool curl make g++ unzip
> wget https://github.com/protocolbuffers/protobuf/releases/download/v2.5.0/protobuf-2.5.0.zip
> unzip protobuf-2.5.0.zip
> cd protobuf-2.5.0
> ./configure
> make
> sudo make install
# Installation de Python3.6
> apt-get install python3.6-dev
> sudo ldconfig
# Installation de SDHash
> git clone https://github.com/sdhash/sdhash.git
> cd sdhash
> make
> make install
> ldconfig
JARM est un outil qui identifie les connexions TLS, développé par Salesforce. Le module de traitement JARM effectue un scan du domaine et renvoie un hachage JARM avec le domaine au moteur central. Selon la configuration d’un serveur web, la poignée de main TLS a des propriétés différentes. En calculant un hachage des attributs de cette poignée de main, ces différences peuvent être utilisées pour suivre les configurations de serveurs web.
Le module de traitement TLSH est similaire au module de traitement SDHash, utilisé pour calculer un hachage de similarité. L’avantage du TLSH est que l’installation est beaucoup plus simple et que la taille d’entrée minimale est plus petite, avec 50 octets. Comme la plupart des connexions webshell sont assez petites et étaient au centre de nos recherches, nous avons activé ce module de traitement par défaut.
Le module de traitement YARA est utilisé pour scanner le contenu des réponses HTTP avec des règles YARA. Pour invoquer ce module de traitement, fournissez la valeur YARAProcessing comme argument du module de traitement. Par exemple, la commande suivante charge le module de traitement YARA et produit une sortie dans la console via le module de stockage ConsoleStorage.
python3 subcrawl.py -p YARAProcessing -s ConsoleStorage
Actuellement, le module de traitement YARA est utilisé pour identifier les connexions webshell et divers autres contenus intéressants. Règles YARA incluses avec ce projet :
Exemple de sortie :
Pour ajouter des règles YARA supplémentaires, vous pouvez ajouter des fichiers .YAR dans le dossier yara-rules, puis inclure le fichier de règles en ajoutant une instruction include dans combined-rules.yar.
Le module de traitement ClamAV est utilisé pour scanner le contenu des réponses HTTP avec ClamAV pendant le scan. Si une correspondance est trouvée, elle est fournie aux différents modules de sortie. Pour invoquer ce module de traitement, fournissez la valeur ClamAVProcessing comme argument du module de traitement. Par exemple, la commande suivante charge le module de traitement ClamAV et produit une sortie dans la console via le module de stockage ConsoleStorage.
python3 subcrawl.py -p ClamAVProcessing -s ConsoleStorage
Exemple de sortie :
Pour utiliser ce module, ClamAV doit être installé. Depuis un terminal, installez ClamAV en utilisant le gestionnaire de paquets APT :
$ sudo apt-get install clamav-daemon clamav-freshclam clamav-unofficial-sigs
Une fois installé, le service de mise à jour ClamAV devrait déjà être en cours d’exécution. Cependant, si vous souhaitez mettre à jour manuellement en utilisant freshclam, assurez-vous que le service est arrêté :
sudo systemctl stop clamav-freshclam.service
Et ensuite exécutez freshclam manuellement :
$ sudo freshclam
Enfin, vérifiez l’état du service ClamAV :
$ sudo systemctl status clamav-daemon.service
Si le service ne tourne pas, vous pouvez utiliser systemctl pour le démarrer :
$ sudo systemctl start clamav-daemon.service
Le module de traitement Payload est utilisé pour identifier le contenu des réponses HTTP en utilisant la bibliothèque libmagic. De plus, SubCrawl peut être configuré pour sauvegarder le contenu d’intérêt, comme les fichiers PE ou les archives. Pour invoquer ce module de traitement, fournissez la valeur PayloadProcessing comme argument du module de traitement. Par exemple, la commande suivante charge le module de traitement Payload et produit une sortie dans la console :
python3 subcrawl.py -p PayloadProcessing -s ConsoleStorage
Il n’y a pas de dépendances supplémentaires pour ce module.
Exemple de sortie :
Les modules de stockage sont appelés par le moteur SubCrawl après que toutes les URL de la file d’attente ont été scannées. Ils ont été conçus avec deux objectifs en tête. Premièrement, obtenir les résultats du scan immédiatement après avoir terminé la file d’attente de scan et deuxièmement, permettre le stockage et l’analyse à long terme. Par conséquent, nous avons non seulement implémenté un module ConsoleStorage, mais aussi une intégration pour MISP et un module de stockage SQLite.
Pour analyser rapidement les résultats directement après le scan des URL, une sortie bien formatée est affichée dans la console. Cette sortie est mieux adaptée lorsque SubCrawl est utilisé en mode exécution unique. Bien que cette approche fonctionne bien pour scanner des domaines uniques ou générer une sortie rapide, elle est peu pratique pour la recherche et l’analyse à long terme.
L’intégration avec un cluster Elastic est également disponible. Chaque URL ainsi que ses données seront indexées comme un événement, cela inclura les sorties d’autres modules tels que Yara. Un tableau de bord par défaut a également été ajouté pour faciliter la prise en main de ce module. Des mises à jour de la section elasticsearch devront être effectuées, incluant :
Pour utiliser ce module de sortie, fournissez la valeur ElasticStorage avec l’argument -s.
Étant donné que l’installation et la configuration de MISP peuvent prendre du temps, nous avons implémenté un autre module qui stocke les données dans une base de données SQLite. Pour présenter les données à l’utilisateur de manière aussi simple et claire que possible, nous avons également développé une interface graphique web simple. En utilisant cette application web, les domaines et URL scannés peuvent être visualisés et recherchés avec tous leurs attributs. Comme il s’agit seulement d’une version précoce, aucune fonctionnalité complexe de comparaison n’a encore été implémentée.
MISP est une plateforme open-source de renseignement sur les menaces avec un modèle de données flexible et une API pour stocker et analyser les données de menaces. SubCrawl stocke les données crawlistes dans des événements MISP, publiant un événement par domaine et ajoutant les répertoires ouverts identifiés comme attributs. MISP permet également aux utilisateurs de définir des tags pour les événements et les attributs. Cela est utile pour la comparaison d’événements et les analyses de liens. Comme c’était l’un de nos principaux objectifs de recherche, nous avons enrichi les données de URLHaus lors de l’exportation de la sortie de SubCrawl vers MISP. URLHaus annote ses données en utilisant des tags qui peuvent être utilisés pour identifier une famille de malwares ou un acteur de menace associé à une URL. Pour chaque URL de répertoire ouvert, le module interroge les données URLHaus stockées localement et ajoute les tags URLHaus à l’événement MISP s’ils correspondent. Pour éviter d’avoir une collection d’attributs non liés pour chaque événement MISP, nous avons créé un nouvel objet MISP pour les URL scannées, appelé opendir-url. Cela garantit que les attributs liés restent ensemble, facilitant ainsi l’obtention d’un aperçu des données.
Des modèles pour les modules de traitement et de stockage sont fournis dans le framework.
Les modules de traitement se trouvent sous crawler->processing et un fichier exemple de module example_processing.py se trouve dans ce répertoire. Le modèle fournit l’héritage et les importations nécessaires pour garantir l’exécution par le framework. La fonction init fournit l’initialisation du module et reçoit une instance du logger et de la configuration globale. Le logger est utilisé pour fournir des informations de journalisation à partir des modules de traitement, ainsi que dans tout le framework.
La fonction process est implémentée pour traiter chaque réponse HTTP. À cette fin, elle reçoit l’URL et le contenu brut de la réponse. C’est là que le travail du module est implémenté. Cette fonction doit retourner un dictionnaire avec les champs suivants :
Un nom de classe unique doit être défini et est utilisé pour définir ce module lors de son inclusion via l’argument -p ou comme module de traitement par défaut dans le fichier de configuration.
Enfin, ajoutez une instruction d’importation dans __init__.py, en utilisant votre nom de classe :
from .<REMPLACER>_processing import <REMPLACER>Processing
Les modules de stockage se trouvent sous crawler->storage et un fichier exemple de module example_storage.py se trouve dans ce répertoire. Similaire aux modules de traitement, la fonction init fournit l’initialisation du module et reçoit une instance du logger et de la configuration globale. La fonction store_results reçoit des données structurées du moteur à des intervalles définis par la taille du lot dans le fichier de configuration.
Un nom de classe unique doit être défini et est utilisé pour charger le module lors de son inclusion via l’argument -s ou comme module de traitement par défaut dans le fichier de configuration.
2021 :
SubCrawl est sous licence MIT.