Threat Hunting: Ce que c'est et comment ça marche

Le threat hunting est la pratique de rechercher proactivement dans les réseaux et points de terminaison les attaquants qui ont déjà contourné vos détections existantes. Cela part d'une hypothèse simple et inconfortable : quelque chose de malveillant se trouve peut-être déjà à l'intérieur, sans que aucune alerte ne se soit déclenchée. Au lieu d'attendre qu'une règle SIEM se déclenche, un chasseur forme une hypothèse et cherche les preuves pour la confirmer ou l'éliminer.

Pourquoi la détection seule ne suffit pas

La détection basée sur des signatures et des règles capture les motifs connus. Les attaquants qui utilisent des binaires living-off-the-land (LOLBins), des identifiants valides, ou des techniques lentes et à bas volume peuvent rester en dessous de ces seuils pendant des semaines. Le threat hunting comble cette lacune en ayant un humain qui remet activement en question les données : est-ce que cet appel PowerShell depuis une station de travail en finance à 2 h du matin a du sens ? Pourquoi svchost.exe effectue-t-il une connexion sortante vers une adresse IP sans DNS inversé ?

Ce n'est pas la réponse aux incidents. La RI commence après que vous sachiez que quelque chose s'est passé. Le hunting commence quand vous ne le savez pas encore, et l'objectif est de le découvrir avant qu'un événement plus important ne force la question.

Les trois points de départ courants

La plupart des hunts commencent par l'un de ces trois angles :

• Intelligence-driven : un nouveau rapport de menace décrit un TTP (par exemple, l'abus d'une tâche programmée pour la persistance), et vous vérifiez s'il est présent dans votre environnement.
• Situational awareness : vous regardez ce qui est réellement inhabituel pour votre organisation — un compte de service s'authentifiant depuis un pays où il ne l'a jamais fait, ou une augmentation du trafic SMB entre des stations de travail qui ne communiquent normalement qu'avec des serveurs.
• Analytics-driven : vous construisez une référence du comportement normal (arbres de processus, heures de connexion, volume de requêtes DNS) et cherchez les anomalies statistiques.

MITRE ATT&CK est la référence que la plupart des équipes utilisent pour structurer les hypothèses. Au lieu de « chercher les malwares », vous choisissez une technique comme T1053 (Scheduled Task/Job) et demandez : à quoi cela ressemblerait-il dans nos journaux Windows Event ou la télémétrie EDR, et puis-je l'interroger maintenant ?

À quoi ressemble le flux de travail réel

Un hunt suit généralement cette boucle :

1. Formuler une hypothèse spécifique et testable (pas « vérifier les intrusions » mais « vérifier les nouvelles tâches programmées créées en dehors des fenêtres de patch au cours des 30 derniers jours »).
2. Identifier les sources de données nécessaires — Sysmon Event ID 1 pour la création de processus, Windows Security Event ID 4698 pour la création de tâche programmée, arbres de processus EDR, ou journaux de connexion Zeek pour le contexte réseau.
3. Interroger et pivoter. En pratique, cela signifie écrire du KQL dans Microsoft Sentinel, du SPL dans Splunk, ou des requêtes brutes contre un index Elastic.
4. Trier les résultats — la plupart seront des faux positifs ou des activités d'administration bénigne, et le travail consiste à réduire ce bruit à ce qui est réellement anormal.
5. Documenter les résultats, qu'il s'agisse d'un compromis confirmé, d'une lacune de détection, ou simplement d'un