Threat hunting : définition - Méthodes, outils, organisation

Le threat hunting est la recherche proactive et hypothesis-driven de menaces qui ont échappé aux détections automatisées. Ce n'est ni du monitoring, ni de l'incident response, ni du pentest. C'est une discipline propre avec ses méthodes, ses outils, ses métriques et son profil de praticien. Ce guide donne la définition précise, les méthodes de référence (Sqrrl, Pyramid of Pain), les techniques concrètes et comment démarrer un programme de hunting dans un SOC existant.

1. Définition précise

Le SANS Institute définit le threat hunting comme :

"The practice of proactively searching for cyber threats that are lurking undetected in a network. Cyber threat hunting digs deep to find malicious actors in your environment that have slipped past your initial endpoint security defenses."

Décomposition :

• Proactif : on ne répond pas à une alerte, on part à la recherche de quelque chose de précis.
• Undetected : on cherche ce qui n'a pas déclenché d'alarme. L'hypothèse de base est que certaines menaces ont contourné la détection automatisée.
• Dig deep : on va plus loin que le triage, on corrèle, on émet des hypothèses, on teste.
• Slipped past : on accepte qu'aucun système de détection n'est parfait.

1.1 Ce que le threat hunting N'EST PAS

• Ce n'est pas du monitoring SIEM : le monitoring réagit aux alertes, le hunting les cherche.
• Ce n'est pas du triage d'alertes : le triage est réactif, sur alerte existante. Le hunting est proactif, sans alerte.
• Ce n'est pas de l'incident response : l'IR gère une compromission déjà identifiée. Le hunting cherche à la détecter avant l'IR.
• Ce n'est pas du pentest : le pentest attaque, le hunting cherche des attaques réelles.
• Ce n'est pas du scan de vulnérabilités : les vulns sont des points d'entrée possibles, les TTPs sont des comportements observés.

1.2 Hypothèse de compromission (Assume Breach)

Le threat hunting repose sur une hypothèse fondatrice : l'organisation est déjà compromise, ou sera prochainement compromise, et certaines compromissions passent inaperçues. Cette posture, popularisée par Microsoft dès 2012 et adoptée par le NIST dans SP 800-207 (Zero Trust), change la philosophie : on ne se demande plus "sommes-nous compromis ?", on se demande "comment trouver la compromission qui est déjà là ?"

Les chiffres du marché soutiennent la posture. Selon le rapport Mandiant M-Trends 2024 :

• Dwell time médian global : 10 jours en 2024 (vs 21 jours en 2021 — en amélioration, mais toujours trop long).
• Dwell time sur compromissions découvertes en interne : 9 jours.
• Dwell time sur compromissions notifiées par un tiers : 26 jours.
• Environ 30 % des compromissions sont découvertes via threat hunting interne ou notification externe, pas via alertes SIEM/EDR.

Ces chiffres justifient l'investissement en hunting : sans programme dédié, un SOC reste dépendant de ce que ses outils savent détecter, et manque les attaques sophistiquées ou inédites.

2. Origine et contexte historique

2.1 Racines militaires

Le terme "hunt" vient de la communauté SIGINT militaire américaine, où des équipes recherchent activement des activités adverses dans les réseaux, en opposition au monitoring passif. Dans les années 2000-2010, la pratique migre vers le secteur privé via d'anciens opérateurs NSA, USCYBERCOM, et les grands DFIR shops (Mandiant, CrowdStrike, FireEye).

2.2 Formalisation côté industrie

• 2015-2016 : Sqrrl (startup rachetée par AWS) publie le premier framework grand public de hunting avec la Hunting Maturity Model et la Hunting Loop.
• 2015 : David Bianco publie la Pyramid of Pain, qui devient référence pour structurer la valeur des indicateurs.
• 2016 : SANS introduit un curriculum dédié (SEC550 - Cyber Deception; FOR572 - Network Forensics puis plus tard SEC595 dédié hunting).
• 2017 : MITRE ATT&CK devient le vocabulaire standard pour décrire les TTPs à chasser.
• 2020-2024 : démocratisation via les EDR modernes (CrowdStrike, SentinelOne, Defender) qui embarquent des interfaces de hunting accessibles aux L2.

3. Les trois grandes familles de hunts

Le threat hunting n'est pas monolithique. Trois approches coexistent, souvent complémentaires.

3.1 Hypothesis-driven hunting

Le hunter formule une hypothèse basée sur :

• Une TTP documentée dans ATT&CK.
• Un threat report d'un acteur récent (Mandiant, Unit 42, CrowdStrike).
• Une observation dans un autre environnement ou un collègue.
• Une intuition basée sur l'expérience du SI.

Exemple : "Je suspecte que des attaquants utilisent T1059.001 PowerShell avec encoded command + T1071 Web Protocols pour leurs C2 dans notre environnement. Cherchons-les."

Ensuite :

1. Identifier les data sources pertinentes (Sysmon Event 1, Windows Event 4688, proxy logs).
2. Construire une ou plusieurs requêtes (SPL, KQL, EQL, Sigma traduit).
3. Examiner les résultats, trier les faux positifs.
4. Documenter les findings et les actions (nouvelle règle, IOC ajouté, incident ouvert).

3.2 Intel-driven hunting

Démarre d'un input CTI concret :

• Nouveau rapport sur un acteur qui vise ton secteur.
• IOCs publiés par un CERT (CERT-FR, CISA, ANSSI alerts).
• Flux MISP, OpenCTI, commercial feed.

Exemple : CISA publie un advisory sur APT40 avec 50 IOCs et 8 techniques ATT&CK. Le hunter cherche ces IOCs dans ses logs historiques (60-90 jours) et teste les TTPs associées dans ses données actuelles.

3.3 Baseline / situational awareness hunting

Le hunter caractérise la normalité de son environnement et cherche ce qui dévie.

Exemples :

• Enumération des processus qui écrivent dans C:\Windows\System32 : identifier les binaires inhabituels.
• Analyse des connexions sortantes par service : détecter un service qui se met subitement à parler à un domaine externe.
• Volume de données uploaded par machine par jour : détecter les pics.

Cette approche est souvent sous-estimée mais très productive, surtout pour des environnements bien connus du hunter.

4. La Pyramid of Pain (David Bianco)

Framework fondamental qui classe les indicateurs par leur coût pour l'attaquant quand on les détecte et les bloque.

Lu du bas (facile pour l'attaquant à changer) vers le haut (difficile) :

Implication pour le hunter :

• Une détection basée sur des hashes ou IPs est fragile : l'attaquant la contourne vite.
• Une détection basée sur des TTPs (ex. "utilisation de WMI pour exec lateral movement") est durable : l'attaquant doit abandonner sa méthode ou être repéré.

Le hunting ambitieux cible le haut de la pyramide. Les outils SIEM/EDR modernes s'y sont largement déplacés, mais beaucoup d'équipes sont encore coincées en bas (listes d'IP, hashes, feeds IOC).

5. La Hunting Loop (Sqrrl)

Framework en 4 phases qui structure une mission de hunting.

5.1 Phase 1 - Create Hypothesis

Formuler l'hypothèse. Elle doit être :

• Testable : on peut la valider ou l'infirmer avec les données disponibles.
• Spécifique : pas "cherchons du malware", mais "cherchons des process powershell.exe démarrés par winword.exe ou excel.exe, comportement classique d'ouverture de pièce jointe malveillante".
• Bounded : périmètre et durée définis.

5.2 Phase 2 - Investigate via Tools and Techniques

Construire les requêtes. Exemples :

• Splunk SPL : index=endpoint sourcetype=Sysmon EventCode=1 ParentImage IN ("*\\WINWORD.EXE", "*\\EXCEL.EXE") Image IN ("*\\powershell.exe", "*\\cmd.exe")
• Elastic EQL : process where process.parent.name in ("WINWORD.EXE", "EXCEL.EXE") and process.name in ("powershell.exe", "cmd.exe")
• KQL (Sentinel) : DeviceProcessEvents | where InitiatingProcessFileName in ("WINWORD.EXE", "EXCEL.EXE") | where FileName in ("powershell.exe", "cmd.exe")

5.3 Phase 3 - Uncover New Patterns and TTPs

Examiner les résultats. Pour chaque hit :

• Est-ce un vrai positif ou un comportement légitime ?
• Quelles variantes pourrait utiliser un attaquant et que ma requête ne capture pas ?
• Quels autres comportements adjacents observer dans la même session ?

Cette phase est la plus créative et celle qui distingue un hunter mature d'un opérateur.

5.4 Phase 4 - Inform and Enrich Automated Analytics

Convertir les apprentissages en valeur durable :

• Nouvelle règle de détection si le pattern est généralisable.
• Nouveau playbook d'investigation si le cas nécessite action standardisée.
• IOC ajouté au threat intel interne.
• Documentation du hunt (hypothèse, méthode, résultats) pour réutilisation.

Sans cette phase, le hunting reste un exercice ponctuel sans capitalisation. C'est la différence entre un hunt utile et un hunt perdu.

6. Techniques de hunting concrètes

6.1 Stack counting (frequency analysis)

Principe : dans un dataset, quels sont les éléments rares ? L'hypothèse : la rareté est suspecte.

Exemples :

• Enumérer les parent-child process combinations et trier par fréquence. Les combinaisons rares (1 ou 2 occurrences sur 10 millions) sont à examiner.
• Lister les commandes net.exe exécutées et identifier celles utilisées une seule fois.
• Identifier les DLL chargées une fois sur un seul endpoint parmi des milliers.

Outil typique : | stats count by process, parent_process | sort count asc (Splunk).

6.2 Anomaly detection

Chercher les déviations par rapport à une baseline :

• Connexion réseau à des heures inhabituelles (2h du matin un dimanche pour un compte utilisateur standard).
• Volume de login échoués au-dessus de la normale pour un compte.
• Géolocalisation incohérente (connexion depuis 2 pays en 10 minutes).
• Usage de binaires LOLBAS (Living Off The Land Binaries) inhabituels.

6.3 Timeline analysis

Reconstituer la chronologie autour d'un événement suspect :

• Prendre un process suspect comme pivot.
• Lister tous les events du même host dans la fenêtre -15 min / +30 min.
• Chercher les patterns de lateral movement, persistence creation, download de secondaire.

6.4 Link analysis

Relier des éléments a priori indépendants :

• Quels comptes ont accédé à la même machine que ce process suspect ?
• Quelles machines partagent le même domaine C2 suspect ?
• Quels process parents ont lancé ce binaire sur l'ensemble du parc ?

6.5 Outlier detection

Chercher ce qui sort de l'ordinaire statistiquement :

• Process avec taille mémoire anormale.
• Connexions HTTP avec User-Agent unique (seul endpoint à utiliser cet UA).
• Sessions RDP plus longues que la médiane + 3 écarts-types.

6.6 Hunt autour des LOLBAS et living-off-the-land

Les attaquants modernes évitent de déposer des binaires custom et utilisent les outils du système : PowerShell, WMI, BITS, certutil, rundll32, regsvr32, mshta, bitsadmin. Liste maintenue sur lolbas-project.github.io (Windows) et gtfobins.github.io (Linux).

Hunt type : examiner chaque binaire LOLBAS, caractériser son usage légitime dans l'environnement, détecter les usages atypiques.

7. Data sources indispensables

Sans télémétrie riche, le hunting est impossible. Les sources critiques :

7.1 Endpoint

• Sysmon (Windows) : Process Creation (Event 1), Network Connection (Event 3), File Created (Event 11), Registry (Event 12-14), DNS Query (Event 22). Indispensable. Configuration via templates publics (SwiftOnSecurity, Olaf Hartong).
• Windows Security Event Log : 4624 (logon), 4625 (failed logon), 4688 (process creation), 4672 (special privileges), 4697 (service installation).
• Linux audit logs (auditd) : execve, open, connect.
• macOS Endpoint Security Framework (ESF) : events modernes via API.
• EDR télémétrie (CrowdStrike, SentinelOne, Defender) : agrégation + enrichissement.

7.2 Network

• NetFlow / IPFIX : métadonnées des connexions (source, dest, port, volume).
• DNS logs : requêtes et réponses (détection DGA, C2, exfil via DNS).
• Proxy / Web Gateway logs : HTTP/HTTPS (User-Agent, URL, méthode, status).
• Firewall logs : accept/deny par connexion.
• IDS/IPS signatures : Suricata, Snort, Zeek/Bro.

7.3 Identity

• Azure AD / Entra ID sign-in logs : contexte login (IP, device, risk score, conditional access).
• Active Directory events : 4768 (TGT request), 4769 (service ticket), 4776 (NTLM auth), 4662 (DCSync signature).
• Okta / Auth0 events : authentification SaaS.

7.4 Cloud

• AWS CloudTrail : toutes les API calls.
• GCP Cloud Audit Logs : Admin Activity, Data Access.
• Azure Activity Log + Resource Logs.
• VPC Flow Logs : trafic cloud inter-ressources.

7.5 Application

• Web server access logs (nginx, Apache, IIS).
• Database audit logs (Postgres, MySQL, SQL Server).
• SSH logs, SFTP logs.

8. Outils du threat hunter

8.1 SIEM

• Splunk : SPL puissant, Enterprise Security ESS, apps de hunting (SA-InvestigateURL, PEAK).
• Elastic Security : EQL + KQL + Lucene, Elastic ML.
• Microsoft Sentinel : KQL, intégration native Microsoft Defender.
• Chronicle (Google Security Operations) : retention longue, UDM schema.
• Sumo Logic, Exabeam, LogRhythm : alternatives.

8.2 EDR en mode hunting

Tous les EDR modernes exposent une interface de requête :

• CrowdStrike Falcon Real Time Response + Event Search (query en F-L-T).
• SentinelOne Deep Visibility (SQL-like).
• Microsoft Defender for Endpoint Advanced Hunting (KQL).
• Carbon Black Cloud (query language).
• Cortex XDR (Palo Alto).

8.3 Jupyter notebooks

Les hunters mûrs utilisent Jupyter pour les analyses complexes :

• msticpy (Microsoft Threat Intelligence Center) : bibliothèque Python dédiée.
• Pandas + Dataframes pour manipuler logs volumineux.
• NetworkX pour link analysis graphique.
• Matplotlib / Plotly pour visualisations.

Avantage : reproductibilité, partage facile, combinaison avec CTI, itération rapide.

8.4 Forensics-in-motion

• OSQuery : SQL-like sur endpoints, lancé à la demande.
• Velociraptor : framework forensics distribué, puissant pour hunts spécifiques sur des flottes.
• GRR Rapid Response (Google) : similar.

8.5 Threat intel platforms

• MISP : open source, standard.
• OpenCTI : open source, orienté STIX 2.1.
• ThreatConnect, ThreatQuotient, Anomali : commerciales.

8.6 ATT&CK et compagnons

• ATT&CK Navigator : visualisation coverage.
• CAR (Cyber Analytics Repository) : détections open source mappées.
• Sigma rules : format portable, communauté active.
• DeTT&CT : outil de mesure de couverture avancée.

9. Organisation de l'équipe hunting

9.1 Modèle intégré au SOC

Le hunting est une activité de L3 ou de praticiens dédiés au sein du SOC. Avantages : proximité avec les analystes, partage des données, feedback loop court.

9.2 Équipe dédiée hunt

Pour des organisations matures (plus de 100 analystes cyber), une équipe dédiée 3-8 personnes qui ne fait que du hunting. Autonomie, focus, profondeur. Risque : silo vs SOC si mal gouverné.

9.3 Hunt team externalisée (MDR)

Les services MDR (Managed Detection and Response) comme CrowdStrike OverWatch, SentinelOne Vigilance, Red Canary, Expel incluent un volet hunting. Utile pour les orgs qui n'ont pas l'expertise interne, mais coûteux et moins contextualisé sur le SI spécifique.

9.4 Purple team comme forme de hunting

Les exercices purple team (red + blue team en collaboration) sont une forme de hunting dirigé : le red team exécute des TTPs, le blue team les cherche en temps réel. Efficace pour valider la détection.

9.5 Profil du threat hunter

Compétences clés :

• Expertise SIEM/EDR : maîtrise des query languages SPL, KQL, EQL.
• Connaissance approfondie de Windows internals, Linux internals, AD, cloud.
• MITRE ATT&CK : parcouru et compris.
• CTI : lit des threat reports, suit des acteurs, comprend les TTPs.
• Scripting : Python notamment, pour automation et analyse.
• Curiosité et ténacité : un hunt productif peut prendre des heures avant de produire un résultat.

Ce profil est rare et cher. Typiquement : 5-10 ans d'expérience blue team avant de devenir hunter senior crédible.

10. Métriques de hunting

Les bonnes métriques mesurent la valeur produite, pas l'activité.

Métriques à éviter :

• "Nombre d'alertes générées" : trivial à truquer, peu corrélé à la valeur.
• "Nombre d'IOCs ingérés" : vanité, pas de sens sans contexte.

11. Erreurs courantes

11.1 Hunter sans data sources

Lancer un programme de hunting avant d'avoir Sysmon, logs AD, NetFlow = chasser dans le noir. Les 3 premiers mois d'un programme de hunting mature sont dédiés à la visibilité.

11.2 Confusion hunt vs triage

Un analyste qui traite des alertes SIEM classiques en l'appelant "hunting" dilue le terme. Si tu réponds à une alerte, tu fais du triage. Si tu en produis sans alerte préalable, tu fais du hunting.

11.3 Pas de capitalisation

Hunts réussis mais sans conversion en règles, playbooks, IOCs. Tout est à refaire au prochain cas similaire. Mitigation : phase 4 de la Hunting Loop systématiquement documentée.

11.4 Hunts trop larges

"Cherche des attaquants sur le réseau" → hunt impossible à exécuter. Chaque hunt doit être borné, testable, avec critère de succès/échec clair.

11.5 Dépendance aux IOCs externes

Consommer passivement des feeds IOC et chercher les hashes = base de la pyramide, peu durable. Le vrai hunt cible les TTPs.

11.6 Pas de purple team

Hunter sans purple team, c'est s'entraîner sans partenaire. Les sessions purple révèlent des angles morts que le hunter seul ne voit pas.

12. Maturité du programme de hunting (Sqrrl HMM)

Le Hunting Maturity Model de Sqrrl classe les programmes en 5 niveaux :

La majorité des SOC en 2026 sont entre HMM1 et HMM2. Atteindre HMM3 demande 2-3 ans d'investissement structuré.

13. Démarrer un programme de hunting en 90 jours

Semaines 1-4 - visibilité

• Audit des data sources existantes.
• Déploiement ou ajustement Sysmon (template SwiftOnSecurity ou Olaf Hartong).
• Vérification de la rétention SIEM (minimum 90 jours pour logs critiques).
• Formation des analystes à ATT&CK.

Semaines 5-8 - premier cycle

• Identifier 5 hypothèses testables sur des TTPs fréquentes (T1059.001 PowerShell encoded, T1003.001 LSASS access, T1053.005 Scheduled Tasks, T1021.001 RDP, T1071.001 Web Protocols).
• Exécuter chaque hunt, documenter hypothèse + query + résultats.
• Traiter les findings.

Semaines 9-12 - capitalisation

• Convertir les trouvailles en règles Sigma, nouvelles alertes SIEM, playbooks.
• Exécuter un purple team exercise avec scénario APT documenté.
• Mesurer les premières métriques (dwell time ajusté, nouvelles détections, coverage ATT&CK gagnée).
• Planifier la saison suivante (hunts trimestriels).

14. Formations et ressources pour hunters

14.1 Formations

• SANS SEC595 - Applied Threat Intel and Hunting : le cursus SANS dédié.
• SANS FOR572 - Network Forensics and Analysis : base réseau indispensable.
• MITRE ATT&CK Defender (MAD) : certifications dédiées (ATT&CK Fundamentals, Adversary Emulation, Purple Teaming).
• Applied Network Defense (Chris Sanders) : excellentes courses abordables.

14.2 Ressources gratuites

• Pyramid of Pain (David Bianco, blog).
• ThreatHunterPlaybook (Roberto Rodriguez, GitHub).
• PEAK framework (Splunk Surge) - open source, très récent et pratique.
• Atomic Red Team (Red Canary) : tests unitaires à exécuter en environnement contrôlé.
• LetsDefend, CyberDefenders : exercices pratiques online.
• Blog Red Canary Threat Detection Report : publication annuelle de référence.

14.3 Communautés

• Threat Hunter Community sur Slack et Discord.
• SANS Hunting Summit (conférence annuelle, présentations publiées).
• Objective by the Sea, DEF CON Blue Team Village : conférences orientées hunt.

15. Verdict et posture Zeroday

Le threat hunting distingue les SOC matures des SOC réactifs. C'est une discipline intellectuellement exigeante qui demande du temps, de l'expertise et de la patience. Les résultats sont parfois invisibles (pas d'incident trouvé sur un trimestre n'invalide pas le programme) mais la valeur est cumulative : chaque hunt alimente les détections, affine la connaissance du SI, nourrit la CTI interne.

Pour un analyste qui monte en grade : maîtriser le hunting est la compétence qui sépare un bon L2 d'un vrai L3. Investir dans cette discipline ouvre le chemin vers les rôles les mieux rémunérés de la blue team (threat hunter senior, detection engineer lead, head of SOC).

Pour une organisation : si ton SOC n'a pas encore formalisé de hunting, commence par une heure par semaine, dédié à un analyste expérimenté, avec une hypothèse simple et un rapport en fin de semaine. Tu verras la valeur apparaître plus vite que prévu.

Pour approfondir : MITRE ATT&CK expliqué pour le langage des TTPs, qu'est-ce qu'un analyste CTI pour l'amont renseignement, niveaux SOC L1/L2/L3 pour situer le threat hunting dans la progression métier.