La chasse aux menaces (threat hunting)
Chercher l'attaquant sans attendre l'alerte : partir d'une hypothèse, fouiller les données, et transformer chaque chasse en nouvelle détection.
Elouan
Série Détection et supervision · article 4 sur 4
- SIEM, EDR, XDR, NDR, SOAR : qui fait quoi
- Trier une alerte : de la notification à la décision
- IOC, IOA, TTP et la pyramide de la douleur
- La chasse aux menaces (threat hunting)
Les détections automatiques ne voient que ce pour quoi elles ont été écrites. Un attaquant prudent, qui utilise les outils du système et imite l’activité normale, peut passer entre les mailles pendant des semaines. Le threat hunting part de ce constat : plutôt que d’attendre une alerte, on part à sa recherche.
Le principe
La chasse aux menaces (threat hunting) est une démarche proactive : on fait l’hypothèse qu’un attaquant est peut-être déjà présent et non détecté, et on fouille les données pour le confirmer ou l’infirmer.
| Travail sur alertes | Threat hunting | |
|---|---|---|
| Point de départ | Une alerte automatique | Une hypothèse |
| Posture | Réactive | Proactive |
| Question | « Cette alerte est-elle vraie ? » | « Qu’est-ce que nos détections ratent ? » |
| Résultat attendu | Une qualification | Une découverte, et une nouvelle détection |
Les trois approches
| Approche | Point de départ | Exemple |
|---|---|---|
| Fondée sur une hypothèse | Une technique d’attaque plausible dans l’environnement | « Un attaquant utilise WMI pour sa persistance » |
| Fondée sur la threat intelligence | Un rapport de veille, des IOC, les TTP d’un groupe | « Ce groupe, qui cible notre secteur, utilise tel outil d’accès à distance » |
| Fondée sur les données | Des statistiques, des anomalies | « Quels sont les programmes qui ne tournent que sur une ou deux machines ? » |
Une chasse, étape par étape
1. Formuler une hypothèse précise
Une bonne hypothèse est précise et vérifiable avec les données disponibles. « On est peut-être piratés » n’en est pas une. « Un attaquant a installé une tâche planifiée pour sa persistance sur l’un de nos serveurs » en est une.
Les sources d’inspiration : les techniques ATT&CK les plus utilisées, les rapports de veille sur les groupes qui ciblent le secteur, les incidents passés, les angles morts connus des détections.
2. Identifier les données nécessaires
Pour l’exemple des tâches planifiées : événements 4698 et 106, inventaire des tâches via l’EDR, fichiers dans C:\Windows\System32\Tasks. Si ces données ne sont pas collectées, la chasse s’arrête là… et on vient de trouver un angle mort.
3. Chercher
Quelques techniques classiques :
- Le stacking : compter les occurrences d’une caractéristique sur tout le parc, puis regarder les plus rares. Dans un parc homogène, ce qui n’existe que sur une ou deux machines mérite un coup d’œil.
- La recherche de valeurs anormales : chemins inhabituels (
AppData,ProgramData,Temp), noms aléatoires, binaires non signés, horaires étranges. - Le regroupement : rassembler des événements par machine, par compte ou par période pour voir des enchaînements.
- La comparaison à une référence : ce qui a changé depuis une date donnée ou par rapport à une machine saine.
Le stacking appliqué aux tâches planifiées
Sur 2 000 postes, on liste toutes les tâches planifiées avec leur commande. 1 950 postes ont exactement les mêmes 40 tâches (système, mises à jour, antivirus). En triant par nombre d’occurrences, une tâche nommée MicrosoftEdgeUpdateCore n’apparaît que sur 3 postes, et pointe vers un exécutable dans C:\ProgramData\. C’est là qu’on regarde en premier.
4. Conclure et capitaliser
Quelle que soit l’issue, la chasse se termine par :
- une conclusion : hypothèse confirmée (on ouvre un incident) ou infirmée, avec le niveau de confiance ;
- une documentation : données utilisées, requêtes, résultats ;
- les angles morts découverts (données manquantes, conservation trop courte) ;
- et, surtout, une nouvelle détection automatique quand c’est possible, pour ne plus avoir à refaire la même chasse à la main.
Ne rien trouver n’est pas un échec
Une chasse qui ne trouve pas d’attaquant a tout de même vérifié une hypothèse, mis au jour des angles morts et, souvent, produit une nouvelle règle. C’est le cycle normal : les chasses d’aujourd’hui deviennent les détections de demain.
Les méthodes formalisées
Plusieurs méthodes structurent la démarche, par exemple :
- TaHiTI (Targeted Hunting integrating Threat Intelligence), publiée par un groupe de banques néerlandaises, en trois phases : initier, chasser, finaliser ;
- le cycle classique hypothèse → investigation → découverte → enrichissement de la détection, décrit dans de nombreux ouvrages et formations.
L’ATT&CK Navigator sert à visualiser les techniques déjà couvertes par des chasses et des détections, et à choisir les suivantes.
Les prérequis
On ne chasse bien que ce qu’on collecte. Une chasse efficace demande :
- des journaux riches : création de processus avec ligne de commande, connexions réseau par processus, DNS, authentifications, Sysmon ou EDR ;
- une durée de conservation suffisante, parce que les intrusions sont souvent découvertes des semaines après le début ;
- un outil de recherche rapide sur de gros volumes (SIEM, plateforme de données de l’EDR) ;
- une bonne connaissance de l’environnement normal, pour reconnaître l’anormal.
C’est la fin de la série sur la détection : la suivante traite de ce qui se passe quand l’incident est confirmé, la réponse à incident et le forensic.
L'essentiel
- Le threat hunting est une recherche proactive : on suppose qu'un attaquant est peut-être déjà présent et non détecté, et on le cherche dans les données.
- Une chasse part d'une hypothèse précise et vérifiable, souvent tirée d'une technique ATT&CK, d'un rapport de veille ou d'une particularité de l'environnement.
- Trois approches courantes : fondée sur une hypothèse, fondée sur la threat intelligence (IOC, TTP d'un groupe), fondée sur les données (statistiques, anomalies).
- La technique du « stacking » (compter les occurrences et regarder les plus rares) est l'une des plus efficaces pour faire ressortir l'inhabituel.
- Une chasse réussie ne trouve pas forcément d'attaquant : elle peut révéler des angles morts, des mauvaises configurations, et produire de nouvelles règles de détection.
- On ne chasse bien que ce qu'on collecte : la qualité et la durée de conservation des journaux conditionnent tout.
Idées reçues
Une chasse qui ne trouve aucun attaquant est-elle un échec ?
L'erreur courante. Répondre oui.
En réalité. Non. Elle confirme (avec un certain niveau de confiance) que l'hypothèse n'est pas vérifiée, et elle produit presque toujours autre chose : un angle mort dans la collecte, une configuration à risque, un comportement légitime mieux compris, et souvent une nouvelle règle de détection automatique. C'est même l'un des objectifs principaux.
Quelle est la différence entre le travail sur alertes et le threat hunting ?
L'erreur courante. Dire que c'est la même chose avec plus de temps.
En réalité. Le travail sur alertes est réactif : on part d'une détection automatique et on la qualifie. Le threat hunting est proactif : on part d'une hypothèse, sans alerte, pour trouver ce que les détections automatiques ont raté. Les deux se nourrissent : une chasse fructueuse devient une règle, et les alertes donnent des idées de chasses.
Pourquoi le stacking fonctionne-t-il bien pour la chasse ?
L'erreur courante. Ne pas connaître la technique.
En réalité. Dans un parc homogène, la grande majorité des comportements sont répétitifs : les mêmes programmes dans les mêmes dossiers, les mêmes services, les mêmes tâches planifiées. En comptant les occurrences sur toutes les machines et en regardant les plus rares (la « longue traîne »), on fait ressortir ce qui n'existe qu'à un ou deux endroits, souvent là où se cache l'anomalie.
Tester ses connaissances
Références
- Practical Threat Intelligence and Data-Driven Threat HuntingValentina Costa-Gazcón · Packt
- The Practice of Network Security MonitoringRichard Bejtlich · No Starch Press
- Blue Team Handbook : SOC, SIEM, and Threat HuntingDon Murdoch · Autoédition