Threat hunting : mener une vraie chasse aux menaces (2026)

Qu'est-ce que le threat hunting ?

Le threat hunting est la pratique consistant à rechercher de façon proactive, dans les données de sécurité, une activité d'attaquant que la détection automatisée a manquée. Plutôt que d'attendre une alerte, le chasseur formule une hypothèse sur la manière dont une intrusion précise apparaîtrait dans la télémétrie disponible, requête ce motif, puis soit le confirme, soit l'écarte, soit découvre que les données nécessaires pour trancher n'ont jamais été collectées.

Ce troisième dénouement est celui dont personne ne fait la publicité, et c'est le plus fréquent dans un programme de chasse récent. Vous supposez qu'un attaquant a créé une tâche planifiée pour sa persistance, vous partez chercher les évènements de création de tâches, et vous découvrez que la stratégie d'audit qui les génère n'a jamais été activée en dehors des contrôleurs de domaine. Vous n'avez attrapé personne. Vous avez en revanche établi que 4 000 postes de travail sont aveugles sur l'une des techniques de persistance les plus utilisées en conditions réelles, ce qui vaut mieux qu'une alerte de plus refermée.

Trois éléments distinguent la chasse de la supervision. La chasse est menée par un humain : la requête vient du raisonnement d'un analyste et non d'un moteur de règles. Elle est guidée par une hypothèse, autrement dit vous décidez de ce que vous cherchez avant de chercher. Et elle présume la compromission : le postulat de travail est que quelque chose est déjà à l'intérieur et qu'il vous revient de le prouver ou de l'écarter, pas d'attendre confirmation.

Une chasse connaît exactement trois issues honnêtes. Vous trouvez une activité malveillante et vous la transmettez à la réponse à incident. Vous ne trouvez rien et vous convertissez la requête en détection planifiée, pour que le même terrain soit couvert automatiquement la prochaine fois. Ou vous constatez que la question est sans réponse, et le livrable devient une lacune de journalisation accompagnée d'un ticket.

Threat hunting, réponse à incident et threat intelligence

Ces trois termes sont employés indifféremment dans les offres d'emploi, alors qu'il s'agit d'activités réellement distinctes qui partagent seulement un jeu de données.

Les trois s'alimentent en boucle. Le renseignement vous indique quelles techniques un acteur pertinent privilégie, ce qui devient votre hypothèse de chasse. La chasse trouve parfois quelque chose de réel, ce qui devient un incident. L'incident produit des artefacts qui repartent vers le renseignement. Si votre organisation n'a pas de cellule de renseignement, la base de connaissances gratuite MITRE ATT&CK fait largement l'affaire pour démarrer, et projeter les phases d'une intrusion sur la cyber kill chain aide à repérer l'étape sur laquelle votre couverture est la plus faible.

Les cinq étapes d'une chasse aux menaces

Quelles sont les étapes d'une chasse aux menaces ? Choisir une hypothèse, déterminer quelle télémétrie permettrait de la prouver ou de l'écarter, requêter puis réduire les résultats à un ensemble examinable, trier ce qui survit, et transformer le résultat en quelque chose de durable : une règle de détection ou une correction de journalisation.

1. Choisissez une hypothèse assez étroite pour pouvoir être invalidée. « Y a-t-il un malware sur le réseau » n'est pas une hypothèse, c'est de l'angoisse. « Un attaquant a établi une persistance sur notre parc Windows via des tâches planifiées qui s'exécutent depuis un répertoire accessible en écriture à l'utilisateur » se teste, et vous savez d'avance à quoi ressemble la réponse.
2. Déterminez quelles données y répondraient, avant toute requête. Notez les sources d'évènements et les champs nécessaires. C'est là que la plupart des chasses meurent en silence, et le découvrir sur le papier en cinq minutes vaut mieux que le découvrir après deux heures d'ajustement de requêtes.
3. Requêtez, puis réduisez. La première requête renvoie toujours trop de choses. La réduction est la vraie compétence : filtrez le bon connu par certificat de signature et processus parent plutôt que par nom de fichier, agrégez au lieu de lister, et descendez jusqu'à un ensemble assez petit pour qu'un humain regarde chaque ligne.
4. Triez les survivants. Pivotez sur chaque élément restant : quel processus l'a créé, qu'a fait ce processus ensuite, quel compte, quelle machine, la même chose existe-t-elle ailleurs. La plupart des lignes se résoudront en un script d'administration inhabituel mais légitime, et chaque écartement doit être consigné pour que la prochaine chasse ne le réexamine pas.
5. Rendez le résultat permanent. Convertissez la requête en détection planifiée, déclarez l'angle mort, documentez ce à quoi « normal » ressemblait finalement. Une chasse que vous ne pouvez pas rejouer est un loisir.

C'est à l'étape cinq que les programmes de chasse réussissent ou s'enlisent. Une équipe qui chasse toutes les semaines sans rien automatiser rejoue éternellement les cinq mêmes requêtes et cesse peu à peu de trouver quoi que ce soit, parce que le terrain couvert ne s'élargit jamais.

Les techniques de threat hunting qui trouvent vraiment quelque chose

Quatre techniques couvrent presque tout le travail d'un chasseur. Elles ne se valent pas, et celle par laquelle commencent la plupart des débutants est la plus faible.

Le comptage par pile, la technique de fond

On parle aussi d'analyse de fréquence ou d'analyse de longue traîne. Vous prenez un champ, vous comptez la fréquence de chaque valeur distincte dans l'environnement, et vous triez par ordre croissant. L'activité malveillante est rare par nature : elle se dépose donc au bas de cette liste. Appliquez-le aux lignes de commande de processus, aux actions de tâches planifiées, aux chemins de binaires de services, aux couples processus parent-enfant ou aux chaînes user-agent.

Si cela fonctionne aussi bien, c'est parce qu'aucune connaissance préalable de la menace n'est requise. Vous ne demandez pas « est-ce malveillant », vous demandez « est-ce inhabituel ici », question à laquelle vos données peuvent répondre seules. En pratique, c'est de là que provient à peu près la moitié des découvertes réelles.

Établissement de référence et détection d'anomalies

Construisez une image du normal pour un comportement précis, puis cherchez l'écart. Quels comptes s'authentifient habituellement sur le serveur de fichiers de la comptabilité, et lequel l'a fait pour la première fois mardi dernier à 3 h du matin. Quel volume de trafic DNS un poste type génère-t-il par heure, et quelle machine en produit huit fois plus avec des labels de sous-domaines anormalement longs. Ce second exemple est l'exfiltration DNS de manuel, et le lab DNS Tunneling Detective vous fournit une capture pour vous y exercer.

La recherche d'indicateurs connus

Vous prenez les empreintes, adresses IP et domaines d'un rapport de renseignement et vous balayez vos données historiques. C'est la technique la plus facile et la moins rentable, à cause de ce que David Bianco a appelé la Pyramid of Pain : empreintes et adresses IP occupent la base, et un attaquant les change sans effort. Comportements et TTP occupent le sommet et coûtent cher à changer. Un balayage d'indicateurs vous dit si vous avez été touché par cette campagne précise, sur cette infrastructure précise, ce qui est une question plus étroite qu'il n'y paraît.

Faites ces balayages parce qu'ils coûtent peu, mais ne bâtissez pas un programme dessus. Si votre équipe de chasse se contente de coller des IOC dans une barre de recherche, vous avez automatisé la consommation de renseignement, pas fait de la chasse.

La chasse assistée par modèle

Vous employez un modèle statistique ou d'apprentissage automatique pour faire remonter des candidats qu'un humain examine ensuite : regroupement de lignes de commande similaires, score d'aléa sur les noms de domaine, signalement des couples parent-enfant rares. L'enquête SANS 2025 est explicite : l'effet des techniques fondées sur l'IA sur la découverte effective d'acteurs malveillants reste limité à ce jour. Voyez ces modèles comme un moyen de trier une botte de foin, pas comme une détection.

Une chasse réelle, du début à la fin

Voici une chasse écrite intégralement, pour donner un support concret aux abstractions ci-dessus.

L'hypothèse

Un adversaire disposant de l'exécution de code sur un poste a créé une tâche planifiée pour sa persistance, exécutant une charge depuis un chemin accessible en écriture à l'utilisateur. En langage ATT&CK, il s'agit de T1053.005, Scheduled Task, rattachée aux tactiques Execution, Persistence et Privilege Escalation. Bonne hypothèse de départ, parce qu'elle est extrêmement courante et que les tâches planifiées légitimes sont assez stables pour que les anomalies ressortent.

Les données

Deux sources y répondent. L'évènement Windows Security 4698 enregistre la création d'une tâche planifiée, et l'évènement Sysmon 1 enregistre la création de processus, ce qui capte l'appel de schtasks.exe. Vérifiez les deux : les tâches enregistrées via l'interface COM ou via Register-ScheduledTask en PowerShell ne touchent jamais schtasks.exe et resteraient invisibles si vous ne regardiez que la création de processus.

Un prérequis piège tout le monde : les évènements Windows 4688 bruts n'incluent pas la ligne de commande tant que ProcessCreationIncludeCmdLine_Enabled n'est pas activé par stratégie de groupe. Sans cela, toute chasse sur ligne de commande dans votre environnement renvoie silencieusement du vide. Vérifiez-le avant la chasse, pas pendant.

Les requêtes

Comptage par pile sur la création de tâches, dans l'advanced hunting de Microsoft Defender XDR (KQL) :

DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "schtasks.exe"
| where ProcessCommandLine has "/create"
| summarize Hosts = dcount(DeviceName), Runs = count()
    by ProcessCommandLine
| order by Runs asc

La même idée dans Splunk, sur des données Sysmon :

index=sysmon EventCode=1 Image="*\\schtasks.exe"
| search CommandLine="*/create*"
| stats count AS runs, dc(ComputerName) AS hosts,
    values(ParentImage) AS parents BY CommandLine
| sort runs asc

Lisez à partir du haut de la sortie, là où se trouvent les lignes de commande les plus rares. Une ligne de commande qui apparaît une fois, sur une seule machine, ne prouve rien, mais c'est là que vous investissez votre attention.

Le tri

Quatre questions décident si une ligne mérite une escalade. Quel est le processus parent : une tâche créée par cmd.exe dont le grand-parent est winword.exe raconte une tout autre histoire qu'une tâche créée par votre agent de gestion de configuration. Où réside le binaire de la tâche : C:\Windows\System32 n'a rien de notable, C:\Users\Public et %APPDATA% si. Quel compte l'a créée, et ce compte administre-t-il habituellement cette machine. Et quand : une création de tâche à 3 h 14 sur une machine dont l'utilisateur badge à 9 h mérite un appel téléphonique.

Attendez-vous à des faux positifs, et attendez-vous à ce qu'ils soient instructifs. Outils de déploiement logiciel, agents de sauvegarde et installeurs créent tous des tâches planifiées d'allure étrange. Chaque écartement doit finir dans une liste d'autorisation documentée, car la valeur d'une chasse ne se cumule que si la suivante démarre là où celle-ci s'est arrêtée.

Le livrable

Supposons que vous n'ayez rien trouvé de malveillant. Vous livrez quand même trois choses : une détection planifiée qui se déclenche sur toute création de tâche dont le chemin d'action se situe sous un répertoire accessible en écriture à l'utilisateur, une référence écrite des douze lignes de commande de tâches normales dans votre parc, et un ticket pour les quatre sous-réseaux d'où aucun évènement 4698 n'est jamais remonté. Rejouez la même chasse au trimestre suivant : elle prend vingt minutes au lieu d'une journée.

Frameworks de threat hunting et modèle de maturité

Deux travaux publiés méritent votre temps. Le reste de la littérature sur les frameworks relève du positionnement d'éditeur.

PEAK

Développé par l'équipe de recherche SURGe de Splunk, PEAK signifie Prepare, Execute, and Act with Knowledge. Prepare couvre le choix du sujet, la recherche et la planification. Execute couvre le travail sur les données. Act couvre la documentation, l'automatisation et la communication, et la connaissance circule à travers les trois : vous l'utilisez avant la chasse, vous en produisez pendant, vous en tirez parti après.

La contribution la plus utile de PEAK est de nommer explicitement trois types de chasse. Les chasses guidées par hypothèse testent une affirmation précise. Les chasses de référence caractérisent le normal sur un périmètre que vous n'avez jamais examiné. Les chasses assistées par modèle emploient des algorithmes pour générer des candidats. Les équipes qui ne pratiquent que le premier type finissent par chasser en boucle la même poignée de techniques bien documentées, faute de pouvoir formuler une hypothèse sur les autres.

Le Hunting Maturity Model

Le Hunting Maturity Model de David Bianco note un programme sur cinq niveaux :

• HMM0, Initial : l'organisation s'en remet à l'alerte automatisée. Les analystes traitent des alertes. Aucune chasse n'a lieu.
• HMM1, Minimal : la télémétrie est collectée de façon centralisée et les analystes peuvent fouiller l'historique à partir d'indicateurs tirés de rapports. C'est le premier niveau où la chasse existe.
• HMM2, Procedural : l'équipe exécute régulièrement des procédures de chasse publiées par d'autres, avec des modifications mineures.
• HMM3, Innovative : l'équipe crée ses propres procédures au lieu de les emprunter.
• HMM4, Leading : toute chasse fructueuse est opérationnalisée en détection automatisée, ce qui libère les analystes pour développer de nouvelles techniques.

Soyez honnête sur votre position. Bon nombre d'équipes qui se décrivent en HMM3 exécutent des requêtes empruntées selon un calendrier, ce qui est du HMM2, et le saut de HMM1 à HMM2 vaut bien plus que l'étiquette. La distinction qui compte au niveau HMM4 est l'automatisation : si les chasses réussies ne deviennent pas des détections, l'équipe fournit un travail manuel dont le coût croît proportionnellement aux effectifs.

Les outils de threat hunting qui méritent votre temps

Vous n'avez pas besoin d'une plateforme de threat hunting. Vous avez besoin d'un accès en requête à une télémétrie réellement bonne, ce qui est un problème de données déguisé en problème d'outillage. Réglez d'abord la collecte, l'interface viendra après.

• Sysmon pour la télémétrie des postes Windows. Gratuit, et il produit les évènements de création de processus, de connexion réseau et de requête DNS dont dépendent la plupart des chasses de cet article. Partez d'une configuration maintenue, comme la configuration modulaire d'Olaf Hartong, plutôt que d'écrire la vôtre de zéro, sinon vous collecterez soit trop peu, soit beaucoup trop.
• Velociraptor pour chasser à l'échelle du parc. Son langage de requête VQL permet de poser une question à des milliers de machines d'un coup et d'obtenir les réponses en quelques minutes, ce qui s'apparente au superpouvoir de cette liste.
• Sigma pour écrire une logique de détection une fois et la convertir vers la syntaxe de requête de votre SIEM. Associez-le à Hayabusa ou Chainsaw pour exécuter des règles Sigma directement sur des fichiers de journaux d'évènements Windows pendant une investigation.
• Zeek pour la télémétrie réseau. Il transforme le trafic en logs structurés de connexions, DNS, HTTP et TLS, bien plus exploitables en chasse qu'une capture complète que vous n'aurez jamais le temps d'ouvrir. Wireshark garde toute sa place pour le dernier kilomètre, une fois qu'un log Zeek vous a désigné la connexion à ouvrir.

Une opinion à énoncer clairement : laissez de côté la catégorie commerciale des « plateformes de threat hunting » tant que vous n'avez pas chassé manuellement pendant six mois. Ces produits supposent que vous savez déjà quelles questions poser, et en acheter un avant cela vous laisse un tableau de bord coûteux que personne n'ouvre.

Comme référentiel de techniques, ATT&CK reste la carte commune. La version v19 du 28 avril 2026 porte Enterprise à 15 tactiques, 222 techniques et 475 sous-techniques, et scinde l'ancienne tactique Defense Evasion en Stealth et Defense Impairment. Si vous suiviez votre couverture de chasse sur l'ancienne liste de tactiques, cette scission mérite un après-midi de remise en correspondance : l'abus de rundll32.exe, par exemple, relève désormais de Stealth sous l'identifiant T1218.011.

Comment devenir threat hunter

Comment devient-on threat hunter ? La plupart des chasseurs viennent de l'analyse SOC, de la réponse à incident ou de l'administration système plutôt que directement des études. Le niveau attendu à l'embauche, c'est la capacité à raisonner sur le comportement normal d'un système d'exploitation, plus assez d'aisance en requêtage pour confronter ce raisonnement à des données réelles.

Quatre compétences portent le métier, à peu près dans l'ordre où elles constituent le facteur limitant :

• Les internes des systèmes d'exploitation. Impossible de repérer une relation parent-enfant anormale sans savoir à quoi ressemble la normale. La généalogie des processus Windows, la mécanique des services et des tâches planifiées, et leurs équivalents Linux comptent davantage que n'importe quel outil.
• Les langages de requête. KQL, SPL ou la syntaxe Elasticsearch, selon ce que fait tourner votre employeur. C'est l'agrégation qu'il faut maîtriser, pas le filtrage.
• La connaissance des techniques offensives. Assez de familiarité offensive pour prévoir ce qu'un intrus tenterait ensuite. Les chasseurs qui ont élevé leurs privilèges à la main sur une machine écrivent des hypothèses nettement meilleures que ceux qui n'en ont que lu la théorie.
• L'écriture. Une chasse non documentée ne peut pas être rejouée, et le rapport de chasse est l'artefact que la direction voit. C'est la compétence que négligent le plus les candidats les plus solides techniquement.

La situation de l'emploi joue en votre faveur. 61 % des organisations interrogées par SANS en 2025 citaient la pénurie de personnel qualifié comme premier frein à leur programme de chasse, tandis que la part de celles qui externalisent totalement la chasse passait de 37 % à 30 %, les équipes internalisant la compétence. Si vous cherchez à cartographier la route vers un poste défensif, notre guide de carrière analyste SOC couvre la voie d'entrée que la plupart des chasseurs empruntent d'abord.

Considérations légales et éthiques

Deux points pèsent ici plus qu'en sécurité offensive. Sous le RGPD et les régimes de protection des données comparables, la télémétrie des postes et de l'authentification constitue une donnée à caractère personnel : un programme de chasse a donc besoin d'une base légale documentée, d'une durée de conservation et de contrôles d'accès proportionnés au caractère révélateur de ces données. Associez votre délégué à la protection des données ou votre service juridique à la conception de la collecte, plutôt qu'après qu'une chasse a fait remonter quelque chose de gênant sur un salarié nommé.

Le second point est la gestion de la preuve. Dès qu'une chasse met au jour une activité malveillante réelle, ce n'est plus une chasse mais un incident, et votre geste suivant peut détruire des preuves. Ne vous connectez pas à la machine suspecte pour aller voir, ne supprimez pas la tâche planifiée que vous avez trouvée, et n'alertez pas un intrus actif. Transmettez à la réponse à incident votre requête, vos résultats et vos horodatages, et laissez le processus conçu pour préserver la preuve prendre le relais.