Threat hunting blue team tutoriel : recherche proactive de compromission

Lecture : 16 minutes · Niveau : sécurité avancée · Mise à jour : avril 2026

Le threat hunting est l’activité par laquelle un analyste blue team cherche proactivement des indices de compromission qui n’ont pas (encore) déclenché d’alerte automatique. C’est la couche que beaucoup de PME oublient : SIEM + EDR détectent les attaques connues, le threat hunting cherche ce qui passe à travers les filets. Selon les standards mis à jour 2025 — notamment SANS FOR508 (printemps 2025) — les domaines critiques en 2026 sont : modern credential abuse (coercion, relays, delegation), lateral movement detection workflows, memory forensics tooling, et hybrid cloud visibility (notamment Entra ID). Ce tutoriel pratique couvre la méthodologie hypothesis-driven, le mapping MITRE ATT&CK, des queries Wazuh / KQL / SPL exécutables, et les cas concrets de hunting pour PME en 2026.

Pour le contexte stratégique global, voir le pillar Sécurité défensive SOC PME. Pour Wazuh, voir Wazuh SIEM tutoriel.

1. Pourquoi le threat hunting

Limite de la détection passive.
– SIEM + EDR détectent les attaques avec signatures connues et patterns fréquents.
– Attaquants modernes : techniques living-off-the-land (LOLBins), encryption, domain fronting, sleep agents → contournent souvent règles génériques.
– Compromise médiane détectée : 200+ jours sans hunting, 30-90 jours avec.

Threat hunting comble le gap.
– Cherche IOCs et TTPs spécifiques même sans alerte initiale.
– Anticipation d’attaques basée threat intelligence sectorielle.
– Validation hypothèses : « si attaquant est dans réseau, voici ce qu’on devrait voir ».

Avantages PME.
– Détecte compromissions silencieuses.
– Identifie gaps détection (transformer en règles).
– Familiarisation analyste avec environnement (utile en IR).
– Signal aux attaquants : environnement surveillé activement.

Pas seulement pour grands groupes.
– 1-2 sessions hunting/mois pour PME mature suffit.
– 2-4 heures par session.
– Petit investissement, gains majeurs.

2. Méthodologie hypothesis-driven

Étape 1 : formuler hypothèse.
– Basée sur threat intelligence (« acteur X cible secteur Y avec technique Z »).
– Basée sur scenarios (« si attaquant a obtenu credentials admin, il aurait fait… »).
– Basée sur lacunes détection (« notre SIEM n’a pas de règle pour cette technique »).

Exemples hypothèses.
– « Un attaquant utilise Mimikatz pour credential dumping → traces dans logs Sysmon ».
– « Lateral movement via PsExec ou WMI → événements Windows 4624 + 7045 dans courte fenêtre ».
– « Domain fronting pour C2 → connexions HTTPS vers CDN avec patterns SNI suspects ».

Étape 2 : définir détection.
– Quels logs, métriques, télémétries permettent de tester l’hypothèse ?
– Quelles queries spécifiques ?
– Sur quelle période ?

Étape 3 : exécuter et investiguer.
– Lancer queries.
– Analyser résultats.
– Investiguer chaque match potentiel.

Étape 4 : conclure.
– Compromission confirmée → activer plan IR.
– Faux positifs → documenter pour exclusion future.
– Gap détection identifié → créer règle SIEM permanente.

Étape 5 : améliorer.
– Documenter le hunt pour réutilisation.
– Ajouter règle si applicable.
– Mettre à jour playbooks.

3. MITRE ATT&CK comme guide

Structure ATT&CK.
– 14 tactics (objectifs adversaires) : Initial Access, Execution, Persistence, etc.
– 200+ techniques (comment ils l’atteignent) : Spearphishing, PowerShell execution, etc.
– Sub-techniques : variantes plus précises.

Utilisation pour hunting.

Coverage analysis.
– Mapper règles SIEM aux techniques détectées.
– Identifier gaps : techniques non couvertes.
– Prioriser hunts sur gaps critiques.

Hunt par tactic.
– Hunt focused sur une tactic à la fois.
– Multiple techniques couvertes par hunt.
– Scope clair, livrable défini.

Attaquants cibles.
– ATT&CK fournit profiles attaquants connus (APT groups) et leurs techniques.
– Utile : « si APT41 cible mon secteur, voici les 20 techniques principales à hunter ».

Outils MITRE.
– ATT&CK Navigator : visualisation coverage.
– Atomic Red Team : tests automatisés par technique.
– DETT&CT : framework de mapping détections.

Top 10 techniques à hunter en priorité 2026.
1. T1078 Valid Accounts (utilisation comptes légitimes compromis).
2. T1059 Command and Scripting Interpreter (PowerShell, bash).
3. T1003 OS Credential Dumping.
4. T1021 Remote Services (lateral movement).
5. T1547 Boot or Logon Autostart Execution (persistance).
6. T1486 Data Encrypted for Impact (ransomware).
7. T1567 Exfiltration Over Web Service.
8. T1566 Phishing.
9. T1190 Exploit Public-Facing Application.
10. T1136 Create Account.

4. Hunt 1 : Credential dumping (T1003)

Hypothèse. Un attaquant tente de dumper LSASS pour récupérer credentials.

Indicateurs.
– Process accédant à lsass.exe (Sysmon Event 10).
– Outils connus : Mimikatz, LaZagne, ProcDump avec lsass, comsvcs.dll MiniDump.
– Tools légitimes mal utilisés (LOLBins).

Query Wazuh / Sysmon.

event_id: 10 AND TargetImage: "*\\lsass.exe" AND NOT SourceImage: "C:\\Windows\\System32\\svchost.exe"

Query KQL Microsoft Sentinel / Defender.

DeviceProcessEvents
| where FileName has_any ("procdump.exe", "procdump64.exe")
| where ProcessCommandLine contains "lsass"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine

Indicators procdump.
– ProcDump.exe avec -ma lsass.exe ou -mp lsass.exe.
– ProcDump renommé (extension .pdf, .doc).

Indicators comsvcs.dll.
– rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump.

Indicators Mimikatz.
– Strings « mimikatz », « gentilkiwi » dans command lines.
– Modules : sekurlsa::logonpasswords, lsadump::sam.

Action si match.
– Investiguer process parent et chaîne complète.
– Vérifier user account associé.
– Memory dump endpoint pour forensique.
– Containment immédiat.
– Reset credentials largement.

5. Hunt 2 : Lateral movement (T1021)

Hypothèse. Un attaquant compromet un endpoint puis se propage via PsExec, WMI, RDP, SMB.

Indicateurs PsExec.
– Service PSEXESVC créé (Windows Event 7045).
– Fichier psexesvc.exe dans C:\Windows\ ou autres.
– Connexions SMB administratives \ADMIN$, \C$.

Query KQL Sentinel.

DeviceProcessEvents
| where FileName == "psexesvc.exe" or InitiatingProcessFileName == "psexec.exe"
| project Timestamp, DeviceName, FileName, InitiatingProcessFileName, ProcessCommandLine

Indicateurs WMI execution.
– wmic process call create dans command lines.
– Process créé avec parent wmiprvse.exe.
– Event 4688 avec lineage suspect.

Query Sysmon.

event_id: 1 AND ParentImage: "*\\WmiPrvSE.exe" AND NOT Image: "*\\Microsoft\\..."

Indicateurs RDP lateral.
– Event 4624 type 10 (RemoteInteractive) entre stations internes.
– Connections RDP entre endpoints (pas seulement admin → station).

Query.

EventID: 4624 AND LogonType: 10 AND IpAddress: 192.168.* AND TargetUserName: NOT helpdesk*

Indicateurs SMB.
– File copies en série vers $ shares.
– Volumes anormaux entre endpoints.

Indicateurs Pass-the-Hash / Pass-the-Ticket.
– Logon types anormaux (NTLM where Kerberos attendu).
– Tickets Kerberos avec lifetime suspect.
– Outils : Mimikatz sekurlsa::pth, Rubeus.

Action.
– Identifier source et destinations.
– Mapper lateral movement chain complète.
– Containment large (souvent infection > endpoint initial).
– Reset credentials all accounts traversés.

6. Hunt 3 : Persistence (T1547)

Hypothèse. Attaquant a installé persistance pour survivre reboot.

Indicateurs Windows.
– Run keys registry : HKLM\Software\Microsoft\Windows\CurrentVersion\Run, RunOnce.
– Scheduled Tasks : tâches créées avec triggers At Logon, At Boot.
– Services : nouveaux services Windows.
– Startup folder : exécutables déposés.
– WMI Subscription : event filters + consumers.

Query KQL.

DeviceRegistryEvents
| where RegistryKey has "Microsoft\\Windows\\CurrentVersion\\Run"
| where ActionType == "RegistryValueSet"
| where InitiatingProcessFileName != "explorer.exe"
| project Timestamp, DeviceName, RegistryValueName, RegistryValueData, InitiatingProcessFileName

Indicateurs Linux.
– systemd : nouveaux services dans /etc/systemd/system/.
– cron : tâches dans /etc/cron.*, crontab user.
– rc.local, .bashrc, .profile : modifications.
– SUID binaires anormaux.

Query Wazuh Linux.

location: "/etc/cron*" AND NOT (event.action: "modified" AND user: "root")

Indicateurs Active Directory.
– GoldenTicket / SilverTicket : tickets Kerberos avec validity longue.
– DCSync rights ajoutés à compte non admin (réplication AD).
– AdminSDHolder modification.

Action.
– Investigation chaîne complète (qui a installé, depuis quand).
– Recherche autres mécanismes persistance simultanés.
– Removal complet (souvent multiples persistances).

7. Hunt 4 : Command & Control (T1071, T1572)

Hypothèse. Endpoint compromis communique avec serveur C2 attaquant.

Indicateurs.
– Connexions HTTPS sortantes vers domaines/IPs non corporate.
– Pattern beaconing (intervalles réguliers).
– DNS queries vers domaines suspects (DGA, jeunes, low-rep).
– User-Agent inhabituels.
– Volumes outbound anormaux.

Query Wazuh / Suricata.
– Flux longue durée HTTPS vers même IP/domaine.
– DNS query rate anormal.

Threat intel feeds.
– Charger IOCs C2 connus.
– AlienVault OTX, MISP, vendor feeds.
– Match logs réseau contre IOCs.

Indicateurs domain fronting.
– SNI vs Host header mismatch.
– HTTPS vers CDN (Cloudflare, Fastly, Azure CDN) avec timings/patterns suspects.

Indicateurs DNS tunneling.
– TXT queries avec payload size anormal.
– Subdomain queries en grand volume vers même domain.

Outils.
– RITA (Real Intelligence Threat Analytics) : analyse beaconing.
– Zeek : protocol analysis.
– NetworkMiner : extraction artifacts.

Action.
– Bloquer C2 (firewall, DNS sinkhole).
– Forensique endpoint compromis.
– Identifier données potentiellement exfiltrées.

8. Hunt 5 : Cloud & Entra ID

Pourquoi 2026. Migration cloud massive. SANS FOR508 spring 2025 a ajouté hybrid cloud visibility et Entra ID comme priorité.

Indicateurs Microsoft 365 / Entra ID.

Login anormaux.
– Sign-ins depuis pays non habituels.
– Impossible travel (deux logins géographiquement incompatibles).
– Connexions hors heures normales.

Query KQL.

SigninLogs
| where ResultType == 0
| extend GeoCountry = tostring(LocationDetails.countryOrRegion)
| where GeoCountry !in ("Senegal", "France")
| project TimeGenerated, UserPrincipalName, GeoCountry, IPAddress

Persistance comptes.
– Création comptes admin non autorisés.
– Ajout external user à roles privileged.
– Application registrations suspectes.

Forwarding rules.
– Rules outlook créées pour forwarder all emails à external.
– Indicateur compromise compte.

Query Microsoft 365 Defender.

EmailEvents
| where DeliveryAction == "Delivered"
| join (EmailUrlInfo) on NetworkMessageId
| where Url contains "..."
| project Timestamp, RecipientEmailAddress, SenderFromAddress, Url

OAuth apps malicieuses.
– Applications avec consents aux scopes lourds (Mail.Read, Files.Read.All).
– Granted par utilisateur compromis.

AWS / Azure cloud.
– IAM users / roles créés.
– Policies attachées avec privileges excessifs.
– API calls anormaux (région nouvelle, services non utilisés).
– AWS GuardDuty / Azure Defender alertes.

Action.
– Désactiver compte / application compromise.
– Reset credentials.
– Audit complet activité 30-90 derniers jours.
– Notification users impactés.

9. Outils et frameworks

SIEM / EDR.
– Wazuh : queries via OpenSearch Discover.
– Microsoft Sentinel : KQL.
– Splunk : SPL.
– Elastic SIEM : KQL/Lucene.
– CrowdStrike : Falcon Insight queries.

Threat hunting frameworks.
– MITRE ATT&CK : référence techniques.
– Atomic Red Team : tests pour valider détections.
– DETT&CT : mapping coverage.
– Sigma : signatures détection portables (convertibles vers SIEM specific).

OSINT / threat intel.
– VirusTotal : reputation domains, IPs, hashes.
– AlienVault OTX : IOCs partagés.
– MISP : plateforme collaborative.
– Shodan : exposition externe.

Logs sources critiques.
– Sysmon (Windows) : enrichi process tree, network, files.
– Auditd (Linux) : commandes exécutées.
– PowerShell logging : ScriptBlock, Module, Transcription.
– Cloud audit logs : Office 365 Unified Audit, AWS CloudTrail, Azure Activity.

Documentation hunts.
– TheHive / Cortex : case management.
– Markdown notebooks : Jupyter, Obsidian.
– Hunt teams sharing : runbooks Git.

10. Programme threat hunting PME

Démarrage modeste.
– 1 session/mois × 4 heures.
– 1-2 hunts par session.
– Focus top 5 techniques MITRE prioritaires.

Roadmap 12 mois.
– Mois 1-3 : hunts authentication (login anormaux, brute-force).
– Mois 4-6 : credential access (LSASS, Kerberos).
– Mois 7-9 : lateral movement.
– Mois 10-12 : C2 et exfiltration.

Documentation.
– Hunt template (hypothèse, queries, résultats, actions).
– Bibliothèque hunts réutilisables.
– Dashboard métriques (hunts effectués, gaps trouvés, alertes créées).

Mesure succès.
– Nouvelles règles SIEM créées suite hunts.
– Compromissions détectées via hunting (vs non détectées passivement).
– Coverage MITRE ATT&CK augmenté.
– Compétence équipe.

Intégration équipe.
– Threat hunting partie du job analyste SOC senior.
– Pas activité séparée mais composante régulière.
– Pair sessions junior + senior pour transfert.

Externalisation possible.
– MDR avec composante threat hunting incluse.
– Engagement red team pour tests TTP avancées.
– Threat intel paid pour feeds ciblés.

11. Pièges fréquents

Hunting sans hypothèse. Random queries = noyade dans logs sans direction. Toujours partir d’hypothèse claire.

Pas de documentation. Hunt fait, oublié 3 mois plus tard, refait par autre analyste. Documenter et partager.

Hunting trop ambitieux. Couvrir 50 techniques en 1 session = surface, pas profondeur. 2-3 hunts/session ciblés.

Pas de validation par red team. Hunts non testés = peut-être faux sentiment de sécurité. Atomic Red Team ou exercices red team pour valider.

Coverage MITRE checkbox. Couvrir technique = écrire règle qui ne déclenche jamais. Vérifier qualité détection, pas juste présence.

Logs insuffisants. Sans Sysmon, PowerShell logging, Audit, beaucoup hunts impossibles. Logging avant hunting.

Burnout sur false positives. Premières semaines = beaucoup faux positifs. Tuner agressivement, ne pas s’épuiser.

Pas de transformation en règles. Hunt productif = doit générer règle SIEM ou alerting. Sinon connaissance perdue.

Threat intel non appliquée. Recevoir feeds IOCs sans intégration au SIEM = inutile. Automation injection IOCs.

Hunting cloisonné. Threat hunting team isolée du SOC = duplicate work, mauvaise communication. Intégration.

Pas de mesure ROI. « Beaucoup d’efforts, qu’est-ce que ça apporte ? » Métriques claires : compromissions détectées, gaps comblés.

FAQ

Combien de temps consacrer au threat hunting ?

Pour PME : 4-8 heures/mois minimum. SOC mature : 20 % temps des analystes seniors. Gros groupes : équipe dédiée full-time. Ne pas remplacer hunting par activités passives même si urgentes.

Faut-il être expert pour faire du threat hunting ?

Non, mais une base solide : Windows / Linux internals, networking, scripting, SIEM queries (KQL ou SPL), MITRE ATT&CK. 6-12 mois d’expérience SOC recommandés avant hunting sérieux. Hands-on avec TryHackMe et Splunk Bots forme bien.

Quels sont les hunts prioritaires pour une PME 2026 ?

Top 5 : 1) Sign-ins anormaux Microsoft 365 / Google Workspace, 2) Credential dumping endpoints, 3) Lateral movement (PsExec, WMI, RDP), 4) Persistence Windows (Run keys, Scheduled Tasks), 5) C2 communications HTTPS suspects.

Wazuh suffit-il pour le threat hunting ?

Oui, pour PME. Wazuh fournit logs Sysmon, Linux audit, network. Discover OpenSearch permet queries flexibles. MITRE mapping built-in. Plus avancé : compléter avec Velociraptor pour live response.

Threat hunting vs penetration testing ?

Pentest : trouve vulnérabilités exploitable. Threat hunting : cherche compromissions actives ou passées. Activités complémentaires. Pentest annuel + threat hunting mensuel = bonne combinaison.

Comment savoir si mon hunting fonctionne ?

Métriques : 1) Nouvelles règles SIEM créées, 2) Compromissions détectées via hunting (vs non), 3) Coverage MITRE augmenté, 4) Time-to-detect des incidents historiques. Atomic Red Team pour validation : si tests passent, hunting détecte vraiment.

Existe-t-il des hunts open-source à réutiliser ?

Oui. ThreatHunting sur GitHub : bibliothèque hunts. Sigma rules : signatures portables. MITRE Cyber Analytics Repository : détections officielles. Splunk Security Content : queries SPL. Microsoft Sentinel community queries : KQL.

Threat hunting et conformité (CDP/RGPD) ?

Threat hunting consulte logs activité, parfois données utilisateurs. Documenter dans politique sécurité. Logs archives avec durée appropriée (1-3 ans typique). Pas de chasse personnelle abusive (vie privée employés). Coordination DPO si questions sur scope.

Articles liés (cluster Sécurité défensive)

Voir aussi : Red teaming PME guide complet, Pentesting éthique PME guide complet, OSINT investigation numérique guide complet, Linux sécurité hardening production.

Article mis à jour le 26 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.