Crawlector

Crawlector (le nom Crawlector est une combinaison de Crawler & Detector) est un framework de threat-hunting conçu pour analyser des sites web à la recherche d'objets malveillants.

Note-1 : Le framework a été présenté pour la première fois à la conférence No Hat à Bergame, Italie, le 22 octobre 2022 (Diapositives, Enregistrement YouTube). Il a également été présenté une deuxième fois à la conférence AVAR, à Singapour, le 2 décembre 2022.

Note-2 : L'outil compagnon EKFiddle2Yara (est un outil qui prend les règles EKFiddle et les convertit en règles Yara) mentionné dans l'exposé a également été publié lors des deux conférences.

Note-3 : La version 2.0 (Photoid Build:180923), une version majeure, a été publiée le 18 septembre 2023.

Note-4 : La version 2.1 (Universe-647 Build:031023) a été publiée le 03 octobre 2023. Une nouveauté majeure est la fonction de notification Slack Alert.

Note-5 : La version 2.2 (Hallstatt Build:051123) a été publiée le 05 novembre 2023. Une nouveauté majeure est la fonction de contrôle à distance Slack.

Note-6 : La version 2.3 (Munich Build:241123) a été publiée le 24 novembre 2023. Une nouveauté majeure est la fonction de serveurs DNS.

Note-6 : La version 2.3.1 {Nero Build:131225} a été publiée le 13 décembre 2025. Il s'agit d'une version de maintenance.

Fonctionnalités

• Support du spidering de sites web pour trouver des liens supplémentaires à analyser (jusqu'à 2 niveaux seulement)
• Intègre Yara comme moteur backend pour l'analyse de règles
• Prend en charge l'analyse en ligne et hors ligne
• Prend en charge le crawling des certificats numériques des domaines/sites
• Prend en charge l'interrogation d'URLhaus pour trouver des URL malveillantes sur la page
• Extraction Profonde d'Objets (DOE)
• Notification Slack Alert
• Prise en charge paramétrée des redirections HTTP
• Récupération des informations Whois
• Prend en charge le hachage du contenu de la page avec TLSH (Trend Micro Locality Sensitive Hash), et d'autres fonctions de hachage cryptographique standard telles que md5, sha1, sha256, et ripemd128, entre autres
  • TLSH ne renvoie pas de valeur si la taille de la page est inférieure à 50 octets, ou si les données ne présentent pas assez d'aléatoire
• Prend en charge l'interrogation de la note et de la catégorie de chaque URL
• Prend en charge l'expansion d'un site donné en tentant de trouver tous les TLD et/ou sous-domaines disponibles pour le même domaine
  • Cette fonction utilise les API Omnisint Labs (ce site est hors ligne depuis le 10 mars 2023) et RapidAPI
  • L'implémentation de l'expansion des TLD est native
  • Cette fonctionnalité, avec la notation et la catégorisation, permet de trouver des domaines d'arnaque/hameçonnage/malveillants pour le domaine d'origine
• Prend en charge la résolution de domaine (IPv4 et IPv6)
• Sauvegarde les pages de sites web analysées pour une analyse ultérieure (peut être sauvegardé sous forme compressée zip)
• L'ensemble des paramètres du framework est contrôlé via un seul fichier de configuration personnalisable
• Toutes les sessions d'analyse sont sauvegardées dans un fichier CSV bien structuré avec une multitude d'informations sur le site web analysé, en plus d'informations sur les règles Yara qui ont été déclenchées
• De nombreuses autres fonctionnalités...
• Toutes les communications HTTP(S) sont conscientes des proxys
• Un seul exécutable
• Écrit en C++

Analyse et Intégration API URLHaus

Ceci sert à vérifier la présence d'URL malveillantes sur chaque page analysée. Le framework peut soit interroger la liste des URL malveillantes depuis le serveur URLHaus (configuration : url_list_web), soit depuis un fichier sur le disque (configuration : url_list_file). Si ce dernier est spécifié, il prime sur le premier.

Cela fonctionne en recherchant le contenu de chaque page dans toutes les entrées d'URL de url_list_web ou url_list_file, en vérifiant toutes les occurrences. De plus, en cas de correspondance, et si l'option de configuration check_url_api est définie sur true, Crawlector enverra une requête POST à l'URL d'API définie dans l'option de configuration url_api, qui renvoie un objet JSON contenant des informations supplémentaires sur une URL correspondante. Ces informations incluent urlh_status (ex. online, offline, unknown), urlh_threat (ex. malware_download), urlh_tags (ex. elf, Mozi), et urlh_reference (ex. https://urlhaus.abuse.ch/url/1116455/). Ces informations seront incluses dans le fichier journal cl_mlog_<current_date><current_time><(pm|am)>.csv (voir ci-dessous), seulement si check_url_api est défini sur true. Sinon, le fichier journal inclura les colonnes urlh_url (liste des URL malveillantes correspondantes) et urlh_hit (nombre d'occurrences pour chaque URL malveillante correspondante), sous condition que check_url soit défini sur true.

La fonctionnalité URLHaus peut être totalement désactivée en définissant l'option de configuration check_url sur false.

Il est important de noter que cette fonctionnalité peut ralentir l'analyse, étant donné le nombre énorme d'URL malveillantes (~ 130 millions d'entrées au moment de la rédaction) qui doivent être vérifiées, et le temps nécessaire pour obtenir des informations supplémentaires depuis le serveur URLHaus (si l'option check_url_api est définie sur true).

Structure des fichiers et dossiers

1. \cl_sites
   • c'est là que la liste des sites à visiter ou à crawler est stockée.
   • prend en charge plusieurs fichiers et répertoires.
2. \crawled
   • où toutes les URL crawlées/spiderées sont sauvegardées dans un fichier texte.
3. \certs
   • où tous les certificats numériques des domaines/sites sont stockés (au format .der).
4. \results
   • où les sites web visités sont sauvegardés. Ceci est configurable via l'option results_dir
5. \pg_cache
   • cache du programme pour les sites qui ne font pas partie de la fonctionnalité spider. Ceci est configurable via l'option cache_dir, section [default].
6. \cl_cache
   • cache du crawler pour les sites qui font partie de la fonctionnalité spider. Ceci est configurable via l'option cache_dir, section [spider].
7. \yara_rules
   • c'est là que toutes les règles Yara sont stockées. Toutes les règles qui existent dans ce répertoire seront chargées par le moteur, analysées, validées et évaluées avant exécution.
8. cl_config.ini
   • ce fichier contient tous les paramètres de configuration qui peuvent être ajustés pour influencer le comportement du framework.
9. cl_mlog_<current_date><current_time><(pm|am)>.csv
   • fichier journal contenant une multitude d'informations sur les sites web visités
   • date, heure, état de l'analyse Yara, liste des règles Yara déclenchées avec les décalages et longueurs de chaque correspondance, id, URL, code d'état HTTP, état de la connexion, en-têtes HTTP, taille de la page, chemin vers une page sauvegardée sur le disque, et autres colonnes liées aux résultats URLHaus.
   • le nom du fichier est unique par session.
10. cl_offl_mlog_<current_date><current_time><(pm|am)>.csv
    • fichier journal contenant des informations sur les fichiers analysés hors ligne.
    • liste des règles Yara déclenchées avec les décalages et longueurs des correspondances, et chemin vers une page sauvegardée sur le disque.
    • le nom du fichier est unique par session.
11. cl_certs_<current_date><current_time><(pm|am)>.csv
    • fichier journal contenant une multitude d'informations sur les certificats numériques trouvés
12. \expanded\exp_subdomain_<pm|am>.txt

Fichier de configuration (cl_config.ini)

Vous devez vous familiariser avec le fichier de configuration cl_config.ini avant d'exécuter une session. Toutes les sections et tous les paramètres sont documentés dans le fichier de configuration lui-même.

La fonctionnalité d'analyse Yara hors ligne est une option autonome ; cela signifie que si elle est activée, Crawlector exécutera uniquement cette fonctionnalité, indépendamment des autres fonctionnalités activées. Et il en va de même pour la fonctionnalité de crawling des certificats numériques des domaines/sites. Dans tous les cas, il est recommandé de désactiver toutes les fonctionnalités inutilisées dans le fichier de configuration.

• En fonction des paramètres de configuration (log_to_file ou log_to_cons), si une règle Yara ne fait référence qu'aux attributs d'un module (ex. PE, ELF, Hash, etc.), alors Crawlector n'affichera que le nom de la règle lors d'une correspondance, excluant les données de décalage et de longueur.

Remarque : pour toute option qui prend un chemin, fournissez toujours le chemin absolu.

Format des motifs de sites

Pour visiter/analyser un site web, la liste des URL doit être stockée dans des fichiers texte, dans le répertoire "cl_sites".

Crawlector accepte trois types d'URL :

1. Type 1 : une URL par ligne
   • Crawlector attribuera un nom unique à chaque URL, dérivé du nom d'hôte de l'URL
2. Type 2 : une URL par ligne, avec un nom unique [a-zA-Z0-9_-]{1,128} = <url>
3. Type 3 : pour la fonctionnalité spider, un format unique est utilisé. Une URL par ligne comme suit :

<id>[depth:<0|1>-><\d+>,total:<\d+>,sleep:<\d+>] = <url>

Par exemple,

mfmokbel[depth:1->3,total:10,sleep:0] = https://www.mfmokbel.com

ce qui équivaut à : mfmokbel[d:1->3,t:10,s:0] = https://www.mfmokbel.com

où, <id> := [a-zA-Z0-9_-]{1,128}

depth, total et sleep peuvent également être remplacés par leurs versions abrégées d, t et s, respectivement.

• depth : le spider prend en charge la recherche d'URL supplémentaires jusqu'à deux niveaux de profondeur (c'est un choix de conception).
• Une valeur de 0 indique une profondeur de niveau 1, la valeur après "->" étant ignorée.
• Une profondeur de niveau 1 est contrôlée par le paramètre total. Ainsi, d'abord, le spider essaie de trouver autant d'URL supplémentaires à partir de l'URL spécifiée.
• La valeur après "->" représente le nombre maximum d'URL à spider pour chacune des URL trouvées (selon la valeur du paramètre total).
• Une valeur de 1 indique une profondeur de niveau 2, la valeur après "->" représentant le nombre maximum d'URL à trouver, pour chaque URL trouvée selon le paramètre total. Pour clarifier, comme dans l'exemple ci-dessus, d'abord, le spider recherchera 10 URL (comme spécifié dans le paramètre total), puis chacune de ces URL trouvées sera spiderée jusqu'à un maximum de 3 URL ; par conséquent, dans le meilleur des cas, nous obtiendrions 40 (10 + (10*3)) URL.
• Le paramètre sleep prend une valeur entière représentant le nombre de millisecondes à attendre entre chaque requête HTTP.

Note 1 : Une URL de type 3 peut être transformée en URL de type 1 en définissant le paramètre de configuration live_crawler sur false dans le fichier de configuration, dans la section spider.

Note 2 : Les lignes vides et les lignes commençant par ";", "#" ou "//" sont ignorées.

La fonctionnalité Spider

La fonctionnalité spider permet à Crawlector de trouver des liens supplémentaires sur la page ciblée. Le Spider prend en charge les fonctionnalités suivantes :

• Le domaine doit être de Type 3 pour que la fonctionnalité Spider fonctionne
• Vous pouvez spécifier une liste de motifs avec caractères génériques (séparés par des barres verticales) pour empêcher le spidering des URL correspondantes via l'option de config. exclude_url. Par exemple, *.zip|*.exe|*.rar|*.zip|*.7z|*.pdf|.*bat|*.db
• Vous pouvez spécifier une liste de motifs avec caractères génériques (séparés par des barres verticales) pour spiderer uniquement les URL qui correspondent au motif via l'option de config. include_url. Par exemple, */checkout/*|*/products/*
• Vous pouvez exclure les URL HTTPS via l'option de config. exclude_https
• Vous pouvez également prendre en compte les liens externes sortants, uniquement pour la page principale, via l'option de config. add_ext_links. Cette fonctionnalité respecte les options de config. exclude_url et include_url.
• Vous pouvez prendre en compte uniquement les liens externes sortants de la page principale, en excluant toutes les autres URL, via l'option de config. ext_links_only. Cette fonctionnalité respecte les options de config. et .

Types d'ID

Dans la version 2.0, les ID ont leurs types explicitement attribués en ajoutant l'un des types suivants à l'ID lui-même :

Le fait que chaque ID porte son type permet de naviguer et de filtrer plus facilement les résultats. De plus, cela est utilisé en interne pour diverses raisons.

Fonctionnalité de classement des sites

• Ceci sert à vérifier le classement du site web
• Vous donnez un fichier contenant une liste de sites web, avec leur classement, au format de fichier CSV
• Les services fournissant des listes de classement de sites web incluent Alexa top-1m (arrêté en mai 2022), Cisco Umbrella, Majestic, Quantcast, Farsight et Tranco, entre autres
• Format du fichier CSV (2 colonnes seulement) : la première colonne contient le classement, et la deuxième colonne contient le nom de domaine
• Si une cellule contient des données entre guillemets, elles seront automatiquement déguillemetées
• Les sauts de ligne ne sont pas autorisés dans le texte entre guillemets
• Les espaces de début et de fin sont supprimés des cellules lues
• Les lignes vides et les commentaires sont ignorés
• La section site_ranking dans le fichier de configuration fournit quelques options pour modifier la façon dont le fichier CSV est lu
• Les performances de cette requête dépendent du nombre d'enregistrements dans le fichier CSV
• Crawlector compare chaque entrée du fichier CSV au domaine investigué, et non l'inverse
• Seul le domaine enregistré/domaine de niveau payant est comparé

Recherche de TLD et de sous-domaines - Section [site]

• La section site offre la possibilité d'étendre un site donné en tentant de trouver tous les domaines de premier niveau (TLD) et/ou sous-domaines disponibles pour le même domaine. S'ils sont trouvés, les nouveaux TLD/sous-domaines seront vérifiés comme n'importe quel autre domaine
• Cette fonction utilise les API Omnisint Labs (https://omnisint.io/) et RapidAPI
• L'API Omnisint Labs renvoie les sous-domaines et les TLD, tandis que RapidAPI ne renvoie que les sous-domaines (l'API Omnisint Labs est hors ligne depuis le 10 mars 2023 ; cependant, l'implémentation est toujours disponible au cas où le site serait de nouveau opérationnel)
• Pour RapidAPI, vous avez besoin d'une clé API "Domains records" valide que vous pouvez demander auprès de RapidAPI, et l'insérer dans la clé rapid_api_key dans le fichier de configuration
• Avec find_tlds activé, en plus des résultats TLD de l'API Omnisint Labs, le framework tente de trouver d'autres domaines actifs/enregistrés en parcourant chaque entrée TLD, soit dans le fichier tlds_file, soit dans l'URL tlds_url
• Si tlds_url est défini, il doit pointer vers une URL qui héberge les TLD, chacun sur une nouvelle ligne (les lignes commençant par un des caractères ';', '#' ou '//' sont ignorées)
• tlds_file contient le nom du fichier qui contient la liste des TLD (comme pour tlds_url ; seul le TLD est présent, sans le '.', par ex., "com", "org")
• Si est défini, il prime sur

Fonctionnalité de redirection

La fonctionnalité de redirection d'URL dans les versions précédentes était défectueuse. Cette version fournit une réécriture complète de la fonctionnalité de redirection, avec un haut degré de paramétrage pour contrôler son fonctionnement. Dans la version 2.0, la redirection a une section dédiée dans le fichier de configuration, nommée [redirect]. L'ensemble de la fonctionnalité de redirection peut être activé/désactivé via l'option follow_redir, dans la section [default].

La fonction de redirection vérifie les codes d'état de réponse HTTP : 301, 302, 303, 307 et 308. En cas de correspondance, Crawlector analysera l'en-tête Location pour l'URL de redirection, en tenant compte des URL de redirection absolues et relatives. La fonctionnalité de redirection dans Crawlector a été conçue pour la performance et la réactivité. La section [redirect] fournit la liste d'options suivante :

[redirect]

• depth = all ; (t: string)
• max_redirect = 200 ; (t: uint16_t)
• visit = true ; (t: bool)
• skip_similar = true ; (t: bool)

L'option depth prend l'une des valeurs suivantes : last ou all. Elle contrôle quelles URL de redirection trouvées visiter, selon que l'option visit est activée ou non. all sert à visiter toutes les URL de redirection trouvées. last sert à visiter la dernière URL de redirection. La visite de ces URL se produit dans la même session en cours. Gardez à l'esprit que, quelle que soit la valeur de depth, Crawlector enregistrera la liste de toutes les redirections vers les URL trouvées, ainsi que le nombre total, sous forme absolue. Elles seront écrites dans le fichier CSV cl_mlog, sous les colonnes redirect_urls et redirect_total.

L'option max_redirect définit une limite supérieure sur le nombre total de redirections d'URL à découvrir.

L'option skip_similar est mieux expliquée par l'exemple suivant :

Supposons que l'URL originale donnée à Crawlector à crawler soit "https://www.mfa.gov.law" et qu'une des redirect_urls trouvées soit "https://mfa.gov.law/". Comme vous pouvez le constater, la seule différence est la barre oblique à la fin de l'URL. Ces deux URL sont identiques, et le serveur répondra avec la même page. Si l'option visit est définie sur true, Crawlector crawlera les deux URL, gaspillant ainsi des ressources et effectuant la même tâche deux fois. Cela peut ne pas être un problème pour 1 ou 2 URL, mais si vous avez des milliers d'URL à crawler et que l'option visit est activée, alors les chances que plus de la moitié d'entre elles aient une telle URL découverte sont très élevées, auquel cas cela devient un problème pressant à prendre en compte. Ainsi, définir l'option skip_similar sur true aidera à résoudre ce problème en ignorant la visite d'URL similaires. En plus du scénario de la barre oblique, l'option skip_similar prend également en compte les deux scénarios suivants : si l'URL de redirection ne diffère que par l'un ou l'autre (ou les deux) des préfixes "https://" et "www.".

Extraction Profonde d'Objets (DOE)

L'une des principales nouveautés de la version 2.0 est la capacité d'extraire différents types d'objets de la page, de les sauvegarder sur le disque, de les analyser avec Yara et URLHaus, et de sauvegarder les résultats dans le fichier CSV. Pour activer cette fonctionnalité, définissez l'option extract_obj sur true, dans la section [page].L'implémentation de la fonctionnalité d'extraction approfondie d'objets fonctionne en créant un fichier d'archive web MHT à partir de la page web, incluant les scripts externes, les images et les fichiers CSS. Tous les fichiers intégrés seront extraits dans le chemin spécifié par l'option obj_dir (chemin : obj_dir/objects/), où chaque fichier sera scanné. Cette implémentation ne doit pas être confondue avec la fonctionnalité de navigateur sans tête. DOE est différent et n'implique pas le chargement de la page pour récupérer toutes les URL interrogées dynamiquement. Par conséquent, elle a ses limites.

Tous les objets extraits auront une partie de leurs métadonnées écrites dans le fichier CSV. Points à garder à l'esprit lors de la lecture du fichier CSV : l'ID du domaine avec l'objet extrait a un format unique, comme suit, <domain_id>_<type>_p_obj_<counter> (par exemple, _mfa_gov_cef40bc5-ba6a-41_t1_p_obj_0_). Et l'URL aura le format suivant, <url>__<object_filename> (par exemple, https://www.mfa.gov.law\_\_bilmur.min.js).

Si l'option delete_obj est définie sur true, alors tous les objets extraits qui ne sont pas détectés par Yara sont supprimés du disque. Si l'option log_all_objs est définie sur true, alors toutes les métadonnées des objets extraits sont journalisées dans le même fichier CSV cl_mlog. Si l'option check_urlhaus dans la section [page] est définie sur true, alors chaque objet extrait sera scanné par URLHaus. Notez que les options de cette option sont héritées de la section [urlhaus].

Remarque : si le domaine en cours de crawl redirige vers un autre domaine, alors la dernière redirection vers l'URL doit être transmise à DOE pour fonctionner. De plus, le domaine doit commencer par "HTTP(S)://" pour que DOE fonctionne.

Notification d'alerte Slack

Parfois, vous pouvez souhaiter exécuter des sessions Crawlector qui peuvent prendre des jours, par exemple en crawlant le top 1 million de sites Alexa, et pour un tel scénario, vous avez besoin d'un moyen de surveiller le fonctionnement et la progression du framework à distance. Par conséquent, dans la version 2.1, j'ai ajouté la fonctionnalité de notification d'alerte Slack pour fournir un mécanisme de surveillance en temps réel de l'exécution de Crawlector, en envoyant les alertes Yara, les événements std::exit(), ainsi que les avertissements et erreurs de processus, vers un canal Slack de votre choix. En plus de cela, Crawlector installe un gestionnaire de console pour tenter de surveiller certains types d'événements, notamment ctrl_c, ctrl_close, ctrl_break, ctrl_logoff et ctrl_shutdown. Il est important de garder à l'esprit que Crawlector ne modifie pas le comportement du gestionnaire par défaut ; il se contente de signaler au canal Slack la réception de l'un des événements listés. Cela pourrait être étendu à l'avenir pour prendre en compte d'autres types d'événements.

Cette fonctionnalité utilise l'API REST de Slack, et pour l'authentification avec le serveur, elle utilise OAuth 2.0. Vous aurez besoin d'un jeton API Slack pour l'utiliser, ainsi que d'un canal configuré avec les bonnes permissions. Cette fonctionnalité publie uniquement des messages sur le canal Slack et ne reçoit ni ne traite aucun message entrant.

La section [slack_alert] fournit la liste d'options suivante :

[slack_alert]

• alert = true ; (t: bool)
• api_token = ; (t: string)
• channel = ; (t: string)
• sleep = ; (t: uint32_t) en millisecondes

Pour désactiver ou activer cette fonctionnalité, définissez simplement l'option alert sur true ou false. De plus, vous devez spécifier le api_token, avec un nom de channel.

Remarque-1 : Dans la phase d'initialisation de Crawlector, il teste si le jeton d'authentification fourni est valide ou non, ou si le canal est défini, et en cas d'échec, cette fonctionnalité est désactivée automatiquement.

Toutes les alertes signalées sur le canal Slack sont signalées sous le nom d'utilisateur Crawlector v<version_number>, par exemple, Crawlector v2.1. L'utilisateur a l'icône d'une toile d'araignée. De plus, toutes les alertes sont enfilées, ce qui signifie que toutes les alertes suivantes après le premier message de démarrage sont publiées en tant que réponses. Ce fut une décision de conception et aide en cas d'exécution de plusieurs sessions en même temps, toutes rapportant au même canal. Certaines alertes utilisent le langage de balisage markdown pour la mise en forme.

Lorsque le processus s'est terminé avec succès et est sur le point de se fermer, il publie le message suivant :

Crawlector s'est terminé et s'arrête avec succès

Remarque-2 : La limite de débit de Slack sur l'API de publication de message est d'un message par seconde, avec une marge pour quelques rafales. Crawlector ne met pas en file d'attente les messages pour permettre plus de publications par seconde. Cela pourrait changer à l'avenir si nécessaire ; cependant, l'option sleep permet au processus de dormir pendant un certain temps après chaque message publié avec succès.

Contrôle à distance Slack

Avec la version 2.2 (nom de code Hallstatt), j'introduis la capacité de contrôler Crawlector à distance via un ensemble sélectionné de commandes de contrôle spécialement conçues. La raison d'introduire cette fonctionnalité est de surveiller et contrôler certains comportements de sessions censées durer des heures ou des jours. Par exemple, vous pouvez vouloir activer/désactiver la fonctionnalité d'alerte Slack, terminer Crawlector, et télécharger un fichier de configuration, entre autres.

Cette fonctionnalité utilise l'API REST de Slack, et pour l'authentification avec le serveur, elle utilise OAuth 2.0. Vous aurez besoin d'un jeton API Slack pour l'utiliser, ainsi que d'un canal configuré avec les bonnes permissions. Le jeton API est le même que celui utilisé dans la section [slack_alert], option api_token.

La section [slack_alert] fournit la liste supplémentaire d'options suivante pour la fonctionnalité de contrôle à distance :

[slack_alert] (options de contrôle)

• control = true ; (t: bool)
• ctrl_channel = ; (t: string) il doit s'agir de l'ID du canal et non du nom du canal
• ctrl_sleep = ; (t: uint32_t) en millisecondes

Pour désactiver ou activer cette fonctionnalité, définissez simplement l'option control sur true ou false. Le nom ctrl_channel doit être l'ID du canal et non le nom du canal. Vous pouvez l'obtenir en cliquant avec le bouton droit sur le nom du canal -> Afficher les détails du canal -> Faites défiler jusqu'en bas de la fenêtre, et vous verrez le champ ID du canal : <channel_id>.

L'option ctrl_sleep détermine la fréquence d'appel au canal de contrôle spécifié dans l'option ctrl_channel pour récupérer les commandes de contrôle. Vous pouvez également mettre à jour cette option via la commande de contrôle cl_update_delay <time_in_ms>.

La liste des commandes de contrôle prises en charge est la suivante :

Remarque-1 : Dans la phase d'initialisation de Crawlector, il teste si le jeton d'authentification fourni est valide ou non, ou si le canal est défini, et en cas d'échec, cette fonctionnalité est désactivée automatiquement.

Si cette fonctionnalité est activée et qu'elle réussit la validation du jeton API, Crawlector envoie le message « Crawlector est prêt à recevoir des commandes de contrôle. Tapez la commande cl_help pour une liste des commandes de contrôle prises en charge. » au ctrl_channel désigné.

Toutes les réponses à une commande de contrôle donnée sont enfilées. De plus, les commandes de contrôle sont lues session par session, à partir du moment où une session est démarrée.

Remarque-2 : La limite de débit de Slack sur l'API de récupération (historique des conversations) est d'une requête par seconde, avec une marge pour quelques rafales. Ainsi, si l'option ctrl_sleep est définie sur une valeur inférieure à une seconde ou supérieure à une seconde, Crawlector met en file d'attente les messages pour prendre en compte plus de commandes de contrôle par seconde, et les exécute dans l'ordre de réception.

Serveurs de noms DNS

Avec la version 2.3 (nom de code Munich), la capacité de spécifier une liste de serveurs de noms DNS pour toutes les requêtes DNS et résolutions DNS-IP tentées par Crawlector est introduite avec un haut niveau de contrôle. Ceci est important si vous crawlez des sites bloqués ou malveillants. Cette fonctionnalité s'applique à chaque fonction de Crawlector où une requête DNS ou une demande DNS-IP est effectuée. Plus important encore, elle offre la capacité d'effectuer du DNS sur TLS pour chaque serveur de noms qui le prend en charge.

La section [dns_ns] fournit la liste d'options suivante pour administrer cette fonctionnalité :

[dns_ns]

• enable = false ; (t: bool)
• name_servers = 8.8.8.8(e_tls),12.13.14.15(d_tls) ; (t: string)
• dns_tls = yes ; (t: string) (yes, no ou force)
• keep_default = false ; (t: bool)
• conn_time_out = 3000 ; (t: uint32_t) en millisecondes (0 pour attendre indéfiniment)

L'option name_servers prend une liste paramétrée de serveurs de noms DNS à utiliser, séparés par des virgules. La valeur de cette option a le format : <IPv4_address>(<tls_option>) où <tls_option> prend l'une des valeurs "d_tls" ou "e_tls". Les options "d_tls" ou "e_tls" indiquent respectivement si le serveur de noms en question prend en charge DNS over TLS ou non. Cette option sera appliquée en fonction de la valeur définie pour l'option dns_tls. Par exemple, l'entrée 8.8.8.8(e_tls) indique d'utiliser le serveur DNS Google 8.8.8.8 avec support TLS, tandis que l'entrée 12.13.14.15(d_tls) indique d'utiliser le serveur DNS 12.13.14.15 sans support TLS.

L'option dns_tls spécifie le niveau requis d'application de TLS. Cette option prend l'une des valeurs "yes", "no" ou "force".

• yes
  • Les serveurs de noms DNS avec support TLS seront tentés en premier, et si aucun serveur de noms avec support TLS n'est trouvé, la résolution UDP/TCP sera tentée à la place.
• no
  • pas de support TLS (ne pas utiliser les serveurs de noms DNS avec support TLS)
• force
  • seuls les serveurs de noms DNS avec support TLS seront utilisés, et toute requête DNS initiée par Crawlector utilisera DoT (DNS over TLS).

L'option keep_default indique s'il faut ajouter le(s) serveur(s) de noms par défaut à la liste des serveurs de noms. Un serveur de noms par défaut est supposé ne pas supporter TLS.

L'option conn_time_out spécifie le temps en millisecondes à attendre une réponse à une requête DNS.

L'option enable active ou désactive cette fonctionnalité.

Améliorations diverses dans la version 2.0

• Ajout des options de ligne de commande "-v" et "-c". L'option "-v" sert à afficher les informations de version dans la console. L'option "-c" sert à lire un fichier de configuration différent du fichier par défaut "cl_config.ini".
• Diverses optimisations de code et améliorations mineures
• Pour chaque domaine lu (sans sous-domaine), Crawlector ajoutera "www." à chaque entrée de site lue, si elle n'existe pas déjà. Par exemple, dans le cas d'une requête d'énumération de sous-domaines RapidAPI, le domaine interrogé doit commencer par "www.".
• Ajout des options clear_dns et upg_2_https à la section [default]. La première vide le cache DNS du nom d'hôte vers l'IP, et la seconde met à niveau chaque site vers HTTPS en y ajoutant "https://". De même, l'option tld_upgrd_2_https a été ajoutée à la section [site], pour mettre à niveau les domaines actifs avec différents TLD vers https.
• Ajout des options rapid_api_weeks et rapid_api_limit à la section [site] pour configurer la requête API vers RapidAPI. Les deux options sont facultatives. La première spécifie le nombre de semaines à interroger dans la base de données, tandis que la seconde spécifie le nombre de sous-domaines à retourner par site.
• Dans la version 2.0, vous pouvez spécifier un répertoire de cache différent pour les sections [spider] et [default], via l'option cache_dir.
• De nombreuses options ont été ajoutées à la section page dans la version 2.0, notamment :
• L'option whois_info récupère les informations whois du domaine, notamment le registrar, registered_on, expires_on et updated_on. Ces données sont extraites de https://www.whois.com/whois/. Les données sont sauvegardées dans le fichier CSV cl_mlog.
• L'option page_title sauvegarde le titre de la page dans le fichier CSV cl_mlog.
• L'option results_dir a été ajoutée pour offrir la possibilité de sauvegarder les pages sous un chemin différent. Si non définie, le dossier "results" sera créé dans le même répertoire que Crawlector.
• Mise à niveau du moteur Yara vers la version 4.3.2

Considérations de conception

• Une page URL est récupérée en envoyant une requête GET au serveur, en lisant le corps de la réponse du serveur et en le passant au moteur Yara pour détection.
• Certains attributs de la requête GET sont définis dans la section [default] du fichier de configuration, notamment les en-têtes User-Agent et Referer, ainsi que le délai d'attente de connexion, entre autres options.
• Bien que Crawlector enregistre les données d'une session dans un fichier CSV, il est recommandé de le convertir en fichier SQL pour de meilleures performances, manipulation et récupération des données. Cela devient évident lorsque vous crawlez des milliers de domaines.
• Les domaines/URL répétés dans cl_sites sont autorisés.

Limites

• Monothread
• Détection statique (pas d'évaluation dynamique du contenu d'une page donnée). Veuillez plutôt consulter la fonctionnalité DOE.
• Pas encore de support de navigateur sans tête !

Bibliothèques tierces utilisées

• Chilkat: bibliothèque pour le spidering de sites web, les communications HTTP, le hachage, l'analyse JSON et la compression de fichiers (ZIP), entre autres
• Yara: pour le scan de règles (v4.5.4)
• CrossGuid: pour la génération de GUID/UUID
• Inih: pour l'analyse du fichier de configuration
• Rapidcsv: pour l'analyse des fichiers CSV
• Color Console: pour la coloration de la console
• TLSH (Trend Micro Locality Sensitive Hash) (v4.8.2)

Contribuer

Ouvert aux pull requests et aux issues. Les commentaires et suggestions sont grandement appréciés.

Auteur

Mohamad Mokbel (@MFMokbel)