Threat Hunting : méthodes, résultats et limites observées en SOC

Face à des attaques toujours plus discrètes et évolutives, les SOC ne peuvent plus se reposer uniquement sur des mécanismes de détection automatisés. Malgré des cas d’usage bien définis et des règles affinées, certains comportements malveillants échappent inévitablement aux radars.

C’est dans ce contexte que le Threat Hunting prend tout son sens. Cette approche proactive vise à rechercher des signaux faibles, formuler des hypothèses et identifier des menaces potentielles avant qu’elles ne déclenchent une alerte formelle.

Dans les environnements à forte surface d’attaque, notamment au sein de grands groupes ou d’organisations stratégiques, cette démarche devient un levier clé d’amélioration continue.

Après avoir rappelé les principes du Threat Hunting, je présenterai un cas concret issu d’un SOC de grande envergure : l’analyse des noms de domaine suspects. Nous verrons les apports réels de cette méthode, mais aussi ses limites opérationnelles.

---

La chasse aux menaces ou « Threat Hunting »

Une activité :

La chasse aux menaces (ou threat hunting) est une activité de recherche proactive visant à identifier des menaces présentes ou émergentes au sein d’un système d’information. Cette activité est généralement menée par le SOC, soit par des analystes, soit par des spécialistes dédiés appelés Threat Hunters.

Un SOC assure la détection selon des cas d’usage définis sur une surface donnée. De nombreux facteurs interviennent dans l’évaluation de la couverture du système d’information par le SOC : l’évolution permanente du SI, la communication des administrateurs lors de modifications (réseau, applicatif), les techniques et tactiques surveillées, la qualité des règles de détection, la pertinence des points de surveillance ainsi que les données traitées, entre autres. Ces éléments peuvent être mesurés à l’aide d’indicateurs clés de performance afin d’évaluer la maturité du SOC.

En cybersécurité, les mécanismes de détection reposent sur des processus automatisés, fonctionnant principalement en temps réel avec un délai de traitement court. Ceux-ci s’appuient sur des modèles de correspondance de données permettant d’identifier des actions et des comportements spécifiques.

Or, les attaquants innovent constamment ; il est donc nécessaire de s’intéresser aux techniques et menaces non prises en compte par ces processus de détection. C’est dans ce contexte que la chasse aux menaces intervient afin d’améliorer en continu la surveillance effective du SOC.

Un processus

Le Threat Hunting est un processus cyclique d’amélioration continue, basé sur l’analyse des données événementielles issues de sources surveillées par le SOC. Celui-ci vise à déterminer les risques cyber associés à ces sources.

À partir d’une analyse approfondie des logs, l’analyste formule des hypothèses sur des comportements potentiellement malveillants. Ces hypothèses permettent ensuite de concevoir de nouveaux cas d’usage à implémenter dans le SOC afin de renforcer la détection.

Le cycle se poursuit par l’implémentation des cas d’usage, le paramétrage des règles de détection ainsi que la vérification de la pertinence des alertes générées après investigation. Les phases de tuning des règles et d’investigation sur les nouvelles alertes se répètent de manière continue.

Cycle type :
Récupération des données → Analyse des logs → Définition des hypothèses (comportements malveillants possibles) → (Optionnel : validation avec les équipes opérationnelles des applicatifs) → Définition des cas d’usage associés aux hypothèses → Création des règles de détection → Paramétrage / tuning → Investigation → Tuning → …

Dans les grands groupes, la cybersécurité occupe une place essentielle. Plus la maturité des processus de sécurité mis en place est élevée, plus les efforts d’amélioration continue autour du Threat Hunting sont importants.

Ce processus est généralement déclenché par la survenue d’un événement de sécurité. Celui-ci peut être courant ou inhabituel, mais il permet à l’analyste d’émettre des hypothèses sur de potentiels comportements malveillants et d’en rechercher des traces ou des logs susceptibles d’être utiles à leur détection.

Une chasse aux intrusions et à l’exfiltration de données

Selon les données récupérées et monitorées, il est possible de mener des recherches approfondies sur certains types de risques. Lors de mon expérience au sein du SOC d’un grand groupe, j’ai participé à plusieurs activités de threat hunting.

Je me concentrerai ensuite sur une investigation spécifique de threat hunting : la recherche et l’analyse de noms de domaines malveillants.

L’analyse des noms de domaines

Les noms de domaines constituent une donnée précieuse pour un analyste SOC. Ils permettent de suivre avec précision les activités d’un serveur, d’une machine ou d’un utilisateur.

L’analyse d’un domaine ou d’un site web permet de déterminer si une connexion est légitime ou malveillante. Il est donc essentiel de vérifier les noms de domaines inconnus ou présentant des comportements suspects.

Le volume de données à traiter constitue un véritable enjeu lorsque l’on souhaite réaliser cette opération sur un périmètre de grande envergure. Chaque jour, des millions de domaines différents sont consultés par des utilisateurs, des applications et d’autres systèmes.

Face à cette quantité considérable, il est impossible pour un analyste de vérifier chaque domaine manuellement. C’est pourquoi une tâche automatisée et régulière a été mise en place afin d’examiner quotidiennement un ensemble de domaines, sans surcharger les analystes SOC.

Paramètres

Certains paramètres ont été configurés afin de filtrer les domaines les plus pertinents à analyser :

• Le volume de données échangé entre la source et la destination,
• Le nombre de requêtes envoyées et reçues entre la source et la destination.

Ces deux indicateurs ont été retenus, mais d’autres paramètres pourraient également être envisagés selon les besoins, comme les connexions en heures non ouvrées ou la régularité des envois de requêtes vers un même domaine (détection de C2).

Il serait possible de créer une règle de détection simple, visant à identifier les connexions avec un volume de données important. Cependant, sur un périmètre de grande envergure, les limitations seraient significatives, et selon les seuils définis :

• Si le seuil est trop bas, le nombre d’alertes générées risque d’être très élevé, entraînant surcharge et fatigue pour les analystes,
• S’il est trop élevé, le nombre d’alertes est réduit, mais certains comportements malveillants pourraient passer inaperçus.

C’est pourquoi le choix s’est porté sur l’analyse des TOP domaines de la journée précédente.

Après plusieurs itérations, les actions suivantes ont été retenues :

• Une investigation pour les domaines dont les requêtes sont entrantes, et une autre pour ceux dont les requêtes sont sortantes. La première est réalisée le matin, la seconde le soir.
• L’investigation porte sur les 24 dernières heures.
• L’investigation se concentre sur le TOP 10 des domaines liés au plus gros volume de trafic et sur le TOP 10 des domaines avec le plus grand nombre de requêtes.

Ainsi, deux investigations sont effectuées chaque jour.

Une liste d’exclusion a été ajoutée à la règle afin d’éviter le traitement multiple d’un même domaine. Cette liste est mise à jour par chaque analyste après traitement.

Avantages

Grâce à ce format, de nombreux domaines peuvent être traités en quelques jours, ce qui permet de repérer d’éventuels comportements malveillants ou exfiltrations. L’analyse ne se limite pas à un seuil volumique ou au nombre de requêtes, mais repose sur un TOP qui permet de limiter et de contrôler la charge des analystes SOC.

Ces investigations permettent également d’identifier des éléments suspects présents dans les logs et de lancer des investigations plus approfondies de chasse aux menaces, contribuant ainsi à l’amélioration continue.

Par exemple, dans le cas de la détection de TLD (domaine de premier niveau ou top-level domain) inconnus ou interdits, il pourrait être envisagé de mettre en place un blocage global de ces TLD.

Dans le cas d’un vrai positif, le domaine malicieux pourrait servir de C2 à un attaquant. Il serait alors possible d’investiguer sur le modèle de domaine et de réaliser des recherches basées sur ces hypothèses.

À titre d’exemple, les domaines « 11mo4fsx[.]ho1idayt2rn[.]ru » et « w6lcjzd6[.]ei8hthyp0[.]ru » sont tous deux associés à la famille de malware Clearfake. Il est très probable que le modèle d’expression régulière suivant puisse correspondre à des domaines malicieux : /[\w]{5,8}\.[\w]{6,12}\.ru/. Bien sûr, de nombreux autres modèles de correspondance peuvent également être étudiés.

Limitations

Par expérience, ce type d’investigation s’avère efficace, même s’il présente de nombreuses limitations.

En effet, les limitations suivantes peuvent être constatées :

• Difficulté à connaître le contenu échangé entre la source et la destination
  Pour un analyste, il est souvent difficile de connaître le contenu échangé entre la source et la destination. Les données récupérées dans les journaux d’événements sont souvent limitées à la taille des paquets et au nombre de paquets associés au flux. Statuer sur la légitimité du flux n’est pas toujours aisé, et le risque d’erreur est important.
  La meilleure solution serait de vérifier la légitimité du flux en demandant à l’utilisateur ou au responsable de la machine concernée. Cependant, la charge pour l’analyste serait très élevée.
  Dans mon contexte, les erreurs de blocage étaient très fréquentes (plusieurs fois par semaine) et impactaient l’expérience utilisateur. La solution appliquée fut l’ajout d’une étape de vérification supplémentaire, réalisée par les analystes SOC de niveau N2/N3 en cas de doute afin de limiter les contacts externes. Elle s’avérait assez efficace, mais demandait tout de même une charge supplémentaire qui devrait être prise en charge par le N1 en temps normal.
• Informations limitées pour juger de la légitimité d’un flux
  Comme le point précédent l’illustre, l’analyste ne possède que très peu d’informations pour déduire si un flux de données est légitime ou non. Nous pouvions être fréquemment amenés à investiguer des domaines dont les volumes de données étaient ambigus : prenons l’exemple d’un site vitrine d’une marque de cosmétique. L’utilisateur effectue un téléchargement depuis ce site de 10 Mo en une seule requête. Une page web peut-elle réellement atteindre cette taille ? A-t-il simplement téléchargé une image en haute définition ? Dans quel cas peut-il s’agir d’un comportement anormal ?
  Autant de questions auxquelles il est difficile de répondre, et souvent il est nécessaire de prendre une décision en fonction des éléments disponibles et du risque que présente le site pour la sécurité de l’entreprise.
• Largeur des exclusions sur les domaines
  La plupart des exclusions ajoutées sur un domaine étaient très larges (domaine global) ou très précises (chaque sous-domaine traité indépendamment).
  Dans le cas des serveurs hébergés sur le Cloud d’Amazon, comme « product-as-01-d[.]amazon[.]com », chaque sous-domaine doit être examiné indépendamment. Si le domaine « amazon[.]com » dans son ensemble est mis en liste blanche, des éléments potentiellement malveillants peuvent ne pas être détectés.
  À l’inverse, pour les sous-domaines tels que page1[.]mondomaine[.]com ou page2[.]mondomaine[.]com, il peut être pertinent d’ajouter en liste blanche le domaine en totalité s’il est légitime (mondomaine[.]com).
  Il s’agit donc d’une décision de l’analyste, soumise à un fort risque d’erreur.
• Petit trafic malveillant difficile à détecter
  Le petit trafic malveillant est très souvent impossible à détecter avec cette méthode. En effet, sur un large périmètre, le nombre de domaines différents consultés chaque jour est de l’ordre du million.
  Les flux malicieux de petite taille et de faible envergure passent très facilement sous les radars du centre de détection.
• Maintenance de la liste blanche
  La liste blanche doit être vérifiée et mise à jour régulièrement. Certains domaines n’ont peut-être plus leur place dans cette liste, par exemple à cause d’un changement de politique de sécurité. Des erreurs peuvent également s’y être glissées, provoquant des failles dans la sécurité mise en place.
  La vérification périodique est donc nécessaire pour conserver un niveau de détection pertinent tout en évitant au maximum la fatigue opérationnelle.
• Limitation en temps réel
  L’analyse n’est pas réalisée en temps réel. Chaque investigation est ouverte après récupération des données sur les dernières 24 heures.
  Un comportement malicieux peut donc être détectable jusqu’à 24 heures après l’ouverture de l’investigation, sans compter le temps nécessaire à l’analyste pour examiner les domaines.
  Dans certains contextes, ce délai peut être difficilement acceptable. C’est pourquoi il est important de compléter ces investigations par des règles de détection supplémentaires en temps réel.

Ces limites ne doivent pas empêcher la mise en place de ces recherches régulières. Elles doivent surtout permettre de prévenir les angles morts de cette investigation et inciter les analystes à réfléchir à des moyens complémentaires pour les couvrir.

Pistes d’amélioration

Les limitations induisent nécessairement des recherches et des réflexions pour améliorer la détection.

• Définir des règles de détection précises et adaptées au temps réel
  Il ne faut pas oublier qu’il s’agit davantage d’investigations liées au threat hunting que d’une détection automatique de comportements malicieux. La chasse aux menaces consiste à rechercher des domaines ou indicateurs potentiellement malveillants, et non à détecter directement des incidents. Elle contribue à la création de certaines règles de détection, mais ne doit pas en constituer l’unique source.
• Disposer d’une base d’indicateurs de compromission à jour
  Si l’on se concentre sur la détection de domaines malveillants, mais aussi sur d’autres éléments de détection, il est nécessaire de disposer d’une base d’indicateurs de compromission constamment mise à jour. Les détections effectuées en temps réel sur ces indicateurs offrent une précision relative selon les sources utilisées. Il est très fréquent de recourir à des outils dédiés tels que MISP.
• Ajouter les domaines jamais observés auparavant
  Il est également possible d’inclure dans les investigations les domaines jamais observés auparavant. Cependant, cette tâche s’avérerait complexe, car il faudrait conserver tous les domaines déjà observés et comparer chaque nouveau domaine à cette liste sans cesse croissante. Sur des périmètres de grande envergure, le stockage et la recherche dans cette liste représenteraient une charge importante : la mémoire vive serait rapidement saturée et le SIEM pourrait être impacté.
• Construire des règles de détection basées sur des modèles et propriétés particulières
  À la suite des investigations déjà menées ou simplement sur la base de recherches et d’idées, il est possible de créer des règles de détection portant sur des modèles et propriétés spécifiques : similarité de noms de domaine (ex. : mondomaine.com <> mondomalne.com), CDN non commun, utilisation de Punycode, etc.
• Détection basée sur l’IA
  Plus complexe à mettre en place mais désormais incontournable, la détection basée sur l’IA fait partie intégrante des outils de cybersécurité. Elle permet d’analyser les domaines de façon plus rapide et plus complète, en intégrant des paramètres complexes tels que la régularité des requêtes, le comportement des machines associées ou la corrélation d’événements sur de multiples sources. Cet outil libère l’analyste de tâches répétitives, comme l’analyse de domaines légitimes, et lui permet de se concentrer sur des missions à plus forte valeur ajoutée.

Les menaces évoluent constamment, tout comme les méthodes d’attaque. Il est donc essentiel d’innover en permanence. Les pistes listées ci-dessus ne sont pas exhaustives, et de nombreuses autres possibilités sont envisageables.

Conclusion

Le Threat Hunting constitue un pilier essentiel de la maturité d’un SOC. Il ne remplace pas les mécanismes de détection en temps réel, mais les complète en permettant d’identifier des angles morts et d’améliorer continuellement la couverture du système d’information.

L’analyse des noms de domaine présentée ici illustre bien cette réalité : efficace pour révéler certains comportements suspects ou des tentatives d’exfiltration, elle reste néanmoins contrainte par le volume de données, le manque de contexte et le délai d’analyse.

La valeur du Threat Hunting réside donc autant dans ses résultats que dans la dynamique qu’il installe : remise en question des règles existantes, création de nouveaux cas d’usage, meilleure compréhension des flux légitimes et malveillants.

Dans un contexte où les techniques d’attaque évoluent en permanence, l’intégration progressive de mécanismes avancés — notamment fondés sur l’analyse comportementale et l’intelligence artificielle — représente une piste structurante pour renforcer encore l’efficacité des SOC.

Le Threat Hunting n’est pas un processus parfait. Mais il est aujourd’hui indispensable pour construire une détection adaptée, évolutive et réellement alignée sur les risques.

Sources et pour aller plus loin…

1. https://www.nexa.fr/post/threat-hunting-la-chasse-aux-menaces-informatiques
2. https://www.itrust.fr/comment-le-threat-hunting-accelere-la-reponse-a-incident
3. https://urlhaus.abuse.ch/browse/tag/ClearFake/
4. Icones par pixelmeetup, Afian Rochmah Afif, Vectorslab, Uniconlabs, Freepik : https://www.flaticon.com/