Chasse aux menaces pour débutants : trouver ce que les alertes ratent

TL;DR

La chasse aux menaces est la pratique proactive de recherche à travers les réseaux et les jeux de données pour trouver les adversaires que les outils de détection automatisée ratent. Des recherches du SANS Institute montrent que les organisations avec des programmes dédiés de chasse aux menaces détectent les brèches 2,5 fois plus rapidement que celles qui s'appuient uniquement sur les alertes. Ce guide couvre la méthodologie basée sur les hypothèses, le framework MITRE ATT&CK comme carte de chasse, les sources de données essentielles comme la télémétrie EDR et les logs DNS, et les outils pratiques incluant Elastic, Splunk et Velociraptor.

Le tableau de bord du SIEM affichait du vert sur tous les panneaux. Aucune alerte critique. Aucun événement de haute gravité. Rien qui nécessite attention. Dans ce même réseau, un groupe de menaces persistantes avancées avait maintenu un accès pendant six mois. Ils avaient compromis un contrôleur de domaine, exfiltré 14 gigaoctets de propriété intellectuelle et établi trois mécanismes de persistance distincts sur des endpoints répartis sur deux continents. Chaque action qu'ils ont menée est restée en dessous des seuils de détection que l'équipe de sécurité avait configurés. Chaque outil a fonctionné exactement comme prévu. Et chaque outil les a complètement manqués.

C'est une chasseuse de menaces qui les a trouvés. Pas grâce à une alerte. Pas grâce à une correspondance de signature. Grâce à une hypothèse : « Si un adversaire avait compromis notre environnement, où établirait-il sa persistance et à quoi cela ressemblerait-il dans notre télémétrie ? » Cette seule question, posée par une analyste qui a refusé de considérer le silence comme une preuve de sécurité, a mis au jour six mois d'espionnage non détecté.

C'est la promesse fondamentale de la chasse aux menaces. Vous arrêtez d'attendre que les outils vous disent que quelque chose ne va pas. Vous allez chercher.

Réactif vs. proactif : pourquoi les alertes ne suffisent pas

Les centres d'opérations de sécurité traditionnels fonctionnent sur un modèle réactif. Les outils de détection déclenchent des alertes. Les analystes les trient. Le cycle se répète. Ce modèle fonctionne pour les menaces connues, les attaques qui correspondent aux signatures et règles existantes. Il échoue face aux adversaires qui étudient vos capacités de détection et opèrent délibérément en dessous.

Selon le rapport CrowdStrike 2025 Global Threat Report, 75 % des intrusions impliquaient une activité manuelle au clavier générant un minimum d'alertes automatisées. Les attaquants ont utilisé des identifiants légitimes, des outils natifs du système d'exploitation et des utilitaires administratifs de confiance. Pas de malware pour déclencher l'antivirus. Pas d'exploit pour correspondre à une signature. Juste un humain assis devant un clavier, utilisant les mêmes outils que vos administrateurs utilisent chaque jour.

La chasse proactive aux menaces inverse le modèle. Au lieu d'attendre que la machine dise « quelque chose ne va pas », un analyste humain dit « laissez-moi vérifier que rien ne va pas ». La distinction semble subtile. En pratique, c'est la différence entre découvrir une brèche en 8 jours versus 21. Le rapport M-Trends 2025 de Mandiant a documenté cet écart exact : les organisations avec des programmes de chasse structurés ont réduit le temps de séjour médian de 21 jours à 8.

Le modèle réactif répond à la question : « Qu'ont détecté nos outils ? » Le modèle proactif répond : « Qu'auraient pu manquer nos outils ? » Les deux questions comptent. Seule l'une d'elles attrape l'adversaire qui a lu votre documentation de détection avant de lancer sa campagne.

Chasse basée sur les hypothèses : commencer par une question

Chaque chasse aux menaces efficace commence par une hypothèse. Pas une vague suspicion, mais une déclaration spécifique et testable sur le comportement de l'adversaire. Une hypothèse donne une direction à la chasse, définit quelles données examiner et établit des critères clairs de succès ou d'échec.

Une hypothèse faible : « Il y a peut-être un problème sur notre réseau. »

Une hypothèse forte : « Un adversaire pourrait utiliser des tâches planifiées sur des endpoints Windows pour maintenir sa persistance, créant des tâches qui exécutent des commandes PowerShell encodées en dehors des heures ouvrables. »

La différence est la testabilité. L'hypothèse forte vous indique exactement quelle source de données interroger (logs du Planificateur de tâches Windows, event ID 4698), quel motif rechercher (commandes encodées en Base64 dans les actions de tâches) et quand chercher (heures d'exécution entre 23h et 5h). Vous pouvez la prouver ou l'infirmer dans une fenêtre d'investigation définie.

Le framework Sqrrl (désormais archivé, sa méthodologie reste fondamentale) identifie trois sources pour la génération d'hypothèses :

Les hypothèses basées sur le renseignement proviennent des rapports de renseignement sur les menaces. Quand une nouvelle campagne APT est documentée, vous demandez : « Ce groupe aurait-il pu nous cibler en utilisant ces techniques ? » Vous chassez ensuite les indicateurs et comportements spécifiques décrits dans le rapport.

Les hypothèses situationnelles proviennent de votre propre environnement. Une nouvelle migration cloud, une acquisition récente ou un pic inhabituel de trafic DNS sortant peuvent tous générer des questions de chasse. Ces chasses sont uniques à votre organisation et ne peuvent pas être externalisées vers des règles de détection génériques.

Les hypothèses basées sur l'analytique proviennent d'anomalies statistiques dans vos données. Un endpoint qui commence soudain à faire des requêtes DNS vers des domaines à noms de haute entropie. Un compte de service qui s'est authentifié depuis un poste de travail pour la première fois en six mois. Un processus qui lit des fichiers de 400 répertoires en moins d'une minute. Ces anomalies ne déclenchent pas d'alertes, mais justifient une investigation.

MITRE ATT&CK comme cadre de chasse

Le framework MITRE ATT&CK est la structure la plus adoptée pour organiser les activités de chasse aux menaces. Il catalogue plus de 200 techniques adverses à travers 14 tactiques, de l'accès initial à l'exfiltration. Pour les chasseurs de menaces, ATT&CK sert à la fois de carte et de liste de contrôle.

Chaque technique ATT&CK décrit comment les adversaires accomplissent un objectif spécifique. La technique T1053 (Scheduled Task/Job) décrit comment les attaquants utilisent les planificateurs de tâches du système d'exploitation pour exécuter du code malveillant à des moments prédéterminés. La technique T1071 (Application Layer Protocol) décrit comment les attaquants canalisent le trafic de commande et contrôle via HTTP, HTTPS ou DNS pour se fondre dans l'activité réseau normale. Chaque entrée inclut des exemples réels, des conseils de détection et des références à des groupes de menaces spécifiques ayant utilisé la technique.

Voici comment ATT&CK se traduit en workflow de chasse structuré :

1. Sélectionnez une tactique. Commencez par l'une des 14 tactiques ATT&CK. La persistance et l'évasion de défense sont de bons points de départ car les attaquants doivent les utiliser dans presque toute intrusion.

2. Choisissez des techniques spécifiques. Sous la tactique Persistance, ATT&CK liste des techniques comme Boot or Logon Autostart Execution, Create or Modify System Process et Scheduled Task/Job. Sélectionnez-en une basée sur votre hypothèse basée sur le renseignement ou situationnelle.

3. Mappez aux sources de données. ATT&CK vous indique exactement quelles sources de données révèlent chaque technique. Pour Scheduled Task/Job, vous avez besoin du Windows Event Log (Event IDs 4698, 4702), des logs de création de processus (Sysmon Event ID 1) et des événements de création de fichiers dans les répertoires de tâches.

4. Écrivez des requêtes de détection. Traduisez la description de la technique en requêtes spécifiques contre vos données de log. Recherchez les tâches planifiées créées par des comptes utilisateur non standards, les tâches avec des arguments de commande encodés ou les tâches pointant vers des exécutables dans des répertoires temporaires.

5. Investiguez les anomalies. Tout résultat ne correspondant pas aux schémas administratifs connus devient une piste. Suivez chaque piste en examinant les événements environnants : que s'est-il passé sur cet endpoint avant et après la création de la tâche suspecte ?

L'enquête SANS 2025 sur la chasse aux menaces a révélé que 68 % des organisations avec des programmes actifs de chasse ont découvert des menaces que les outils de détection existants n'avaient pas identifiées. ATT&CK est le cadre qui rend ce type de découverte structurée reproductible.

Sources de données : où les adversaires laissent des traces

Une chasse aux menaces est aussi efficace que les données disponibles. Sans visibilité, même la meilleure hypothèse reste non testée. Cinq sources de données forment le socle d'une chasse efficace.

La télémétrie EDR est la source individuelle la plus précieuse. Les plateformes d'Endpoint Detection and Response comme CrowdStrike Falcon, Microsoft Defender for Endpoint et SentinelOne enregistrent les arbres de création de processus, les modifications de fichiers, les changements de registre, les connexions réseau et les chargements de DLL au niveau de l'hôte. Quand un adversaire exécute cmd.exe pour lancer powershell.exe pour exécuter une commande encodée, l'EDR capture toute la chaîne de relation parent/enfant. Cette visibilité permet de distinguer l'activité administrative légitime de l'exécution d'outils adverses.

Les logs de requêtes DNS révèlent la communication avec l'infrastructure de commande et contrôle. Les attaquants utilisent fréquemment des algorithmes de génération de domaines (DGA) pour créer des domaines qui ne résolvent que pendant quelques heures avant rotation. Ces domaines ont une haute entropie de caractères, des schémas TLD inhabituels et aucune réputation historique. Le logging DNS passif capture chaque requête de chaque endpoint, créant un enregistrement consultable qui survit aux domaines éphémères.

Les logs de proxy et passerelle web capturent les métadonnées du trafic HTTP/HTTPS sortant. Même quand le trafic est chiffré, vous pouvez analyser les domaines de destination, les chaînes User-Agent, les schémas de temporisation des requêtes et les volumes de transfert de données. Un poste de travail qui envoie exactement 4 096 octets de données à la même IP externe toutes les 60 secondes présente un comportement de beaconing cohérent avec un malware de commande et contrôle.

Les logs d'authentification d'Active Directory et des fournisseurs d'identité exposent les mouvements latéraux. Un adversaire qui compromet un endpoint doit typiquement se déplacer à travers le réseau pour atteindre des cibles de haute valeur comme les serveurs de bases de données et les contrôleurs de domaine. Chaque saut nécessite une authentification. Les schémas inhabituels incluent un compte unique s'authentifiant sur 30 systèmes en une heure, des comptes de service se connectant de manière interactive, ou des comptes administratifs s'authentifiant depuis des postes de travail dans des zones géographiques où aucun administrateur n'est basé.

Les données de flux réseau (NetFlow, sFlow) fournissent un enregistrement de chaque conversation réseau : source, destination, ports, protocoles, comptage d'octets et durée. Bien qu'ils manquent de contenu de payload, les données de flux excellent pour identifier les connexions de longue durée, l'utilisation inhabituelle de ports et les transferts de données importants signalant une exfiltration.

Le workflow de chasse : de l'hypothèse à la découverte

Une chasse aux menaces structurée suit un cycle reproductible. Bien que les chasses individuelles varient en périmètre et en technique, le workflow reste cohérent.

Étape 1 : Formulez l'hypothèse. Définissez ce que vous cherchez, où vous vous attendez à trouver des preuves et à quoi ressemble la « normale » dans ce contexte. Écrivez-le. Une hypothèse que vous ne pouvez pas articuler est une hypothèse que vous ne pouvez pas tester.

Étape 2 : Identifiez les données nécessaires. Mappez l'hypothèse à des sources de données et types de logs spécifiques. Vérifiez que les données existent, couvrent la période pertinente et sont interrogeables. Découvrir un manque de données avant de commencer la chasse est mieux que de le découvrir en cours de route.

Étape 3 : Construisez et exécutez les requêtes. Traduisez l'hypothèse en requêtes de recherche contre votre SIEM, plateforme EDR ou data lake. Commencez large pour comprendre la ligne de base, puis affinez progressivement pour isoler les anomalies.

Étape 4 : Analysez les résultats. Évaluez chaque anomalie au regard de votre connaissance de l'environnement. Tout ce qui est atypique n'est pas malveillant. Un serveur qui fait 10 000 requêtes DNS par heure pourrait être une application web chargée, pas un hôte compromis. Le contexte transforme les points de données en renseignement.

Étape 5 : Documentez et escaladez. Enregistrez vos découvertes, que vous ayez trouvé une menace ou confirmé que l'environnement est sain pour le périmètre examiné. Si vous découvrez une activité malveillante confirmée, escaladez vers votre processus de réponse aux incidents. Si vous découvrez des lacunes de détection, créez de nouvelles alertes ou règles pour empêcher le même angle mort de persister.

Étape 6 : Affinez et répétez. Chaque chasse génère de nouvelles questions. La tâche planifiée que vous avez investiguée était légitime, mais vous avez remarqué trois comptes de service avec des privilèges administratifs que personne dans l'équipe ne reconnaît. Cela devient la prochaine hypothèse.

Outils du métier

Vous n'avez pas besoin d'une plateforme dédiée de chasse aux menaces pour commencer. Les outils que la plupart des organisations déploient déjà pour la surveillance de sécurité servent d'instruments de chasse quand ils sont utilisés avec intention.

Elastic Security (ELK Stack)

Le Stack Elastic (Elasticsearch, Logstash, Kibana) est largement déployé pour l'agrégation et la recherche de logs. Pour la chasse aux menaces, ses atouts sont les requêtes flexibles avec KQL (Kibana Query Language), la recherche rapide en texte intégral sur des milliards d'événements et les tableaux de bord de visualisation qui révèlent des schémas.

Un exemple de requête KQL chassant l'exécution suspecte de PowerShell :

process.name: "powershell.exe" AND process.args: ("-enc" OR "-encodedcommand" OR "FromBase64String") AND NOT user.name: ("SYSTEM" OR "svc-deploy")

Splunk

Le Search Processing Language (SPL) de Splunk est conçu pour l'investigation de sécurité. Ses commandes statistiques permettent aux chasseurs d'identifier les valeurs aberrantes dans des jeux de données massifs.

Un exemple de requête SPL chassant le comportement de beaconing DNS :

index=dns sourcetype=stream:dns
| stats count dc(query) as unique_queries avg(bytes_out) as avg_bytes by src_ip dest_ip
| where count > 500 AND unique_queries < 10 AND avg_bytes < 512
| sort - count

Velociraptor

Velociraptor est un outil open source de visibilité et forensique des endpoints conçu spécifiquement pour la chasse aux menaces et la réponse aux incidents. Contrairement à la chasse basée sur le SIEM, Velociraptor interroge les endpoints directement et en temps réel en utilisant VQL (Velociraptor Query Language).

Pour les équipes sans plateforme EDR commerciale, Velociraptor fournit une chasse aux endpoints à l'échelle de l'entreprise sans coût de licence. Il est particulièrement puissant pour chasser les mécanismes de persistance car il peut interroger l'état actuel des endpoints plutôt que de s'appuyer sur des événements de log historiques.

Chasse aux menaces vs. réponse aux incidents : disciplines complémentaires

La réponse aux incidents commence quand quelque chose se déclenche : une alerte se déclenche, un utilisateur signale une activité suspecte ou un tiers vous notifie d'un compromis. Vous savez que quelque chose s'est produit. Le travail est le confinement, l'investigation et la remédiation.

La chasse aux menaces commence quand rien ne s'est déclenché. Pas d'alerte, pas de signalement, pas de notification. Vous opérez en supposant qu'un adversaire pourrait être présent malgré le silence. Le travail est la découverte.

Les deux disciplines s'alimentent mutuellement. Les chasses qui découvrent des menaces transitionnent vers des workflows de réponse aux incidents. Les investigations de réponse aux incidents qui révèlent des lacunes dans la couverture de détection génèrent des hypothèses pour de futures chasses. L'analyste SOC qui a investigué un incident de phishing le mois dernier et découvert que l'organisation n'avait aucune visibilité sur l'abus de jetons OAuth a maintenant une hypothèse de chasse pour le prochain trimestre.

Les organisations avec des programmes de sécurité matures mènent les deux activités en continu. La capacité réactive gère le connu. La capacité proactive cherche l'inconnu. Aucune des deux seule ne suffit.

Construire votre premier programme de chasse

Lancer une pratique de chasse aux menaces ne nécessite pas une équipe dédiée ni des outils spécialisés. Cela nécessite une décision délibérée d'allouer du temps à l'investigation proactive.

Commencez par consacrer quatre heures par semaine à la chasse structurée. Choisissez une technique ATT&CK par session. Écrivez l'hypothèse. Exécutez les requêtes. Documentez les résultats. Quatre heures par semaine sur 52 semaines produisent 52 chasses documentées, un corps de preuves qui démontre à la fois la conscience de la posture de sécurité et l'amélioration continue auprès des auditeurs, dirigeants et régulateurs.

Constituez un backlog d'hypothèses. Chaque rapport de renseignement sur les menaces que vous lisez, chaque incident auquel vous répondez, chaque anomalie que vous remarquez pendant le monitoring de routine peut générer une hypothèse de chasse. Maintenez une liste priorisée pour toujours savoir quoi chasser ensuite.

Mesurez l'impact de votre programme. Suivez le nombre de chasses réalisées, les techniques ATT&CK uniques couvertes, les découvertes confirmées, les nouvelles règles de détection créées à partir des résultats de chasse et les lacunes de détection identifiées.

Le modèle de maturité de chasse aux menaces du SANS Institute décrit cinq niveaux de HMM0 (initial, principalement réactif) à HMM4 (leader, avec des workflows de chasse automatisés intégrés aux opérations SOC). La plupart des organisations commencent à HMM1. L'objectif n'est pas d'atteindre HMM4 immédiatement mais de progresser régulièrement en faisant de la chasse une pratique cohérente et documentée plutôt qu'un exercice occasionnel.

De la surveillance passive à la découverte active

L'industrie de la sécurité a passé deux décennies à construire des machines d'alertes plus rapides, plus intelligentes et plus coûteuses. Elles fonctionnent. Elles attrapent la plupart des menaces. Mais « la plupart » n'est pas « toutes », et les menaces qu'elles ratent tendent à être celles qui causent des dommages catastrophiques.

La chasse aux menaces comble cet écart. Elle reconnaît une vérité fondamentale qu'aucun système de détection n'est complet et canalise cette reconnaissance en action productive. L'analyste qui a trouvé l'APT de six mois n'a pas utilisé un outil que le reste de l'équipe n'avait pas. Elle a utilisé le même SIEM, le même EDR, les mêmes données auxquelles tout le monde avait accès. La différence était une question : « Et si quelque chose était ici que nous n'avons pas vu ? »

Cette question, posée de manière cohérente et investiguée méthodiquement, est toute la discipline. Commencez par une hypothèse. Menez une chasse. Documentez ce que vous trouvez. Puis refaites-le la semaine prochaine. Les adversaires n'attendent pas que vos outils rattrapent leur retard. Vous non plus ne devriez pas.