Exécuter un threat hunting à partir d’une hypothèse

Le threat hunting consiste à chercher un comportement hostile avant qu’une alerte ne le signale. La bonne unité de travail n’est pas une recherche libre dans des téraoctets de journaux, mais une hypothèse réfutable, liée à une technique observée et à des données réellement disponibles.

→ Lire l’explication complète de la marmotte

Préparer l’hypothèse de threat hunting

Le compromis central est brutal : une hypothèse étroite couvre moins de terrain, mais produit un résultat défendable et automatisable. Une chasse vague donne l’illusion de surveiller partout, puis livre un tableur de requêtes sans décision. La recommandation est de commencer par une technique unique, un périmètre limité et un critère de succès mesurable.

1. Choisir un renseignement exploitable

Partir d’un renseignement récent, daté, attribué à une source identifiable et applicable au secteur concerné. Une note de renseignement qui affirme qu’un groupe cible le secteur avec la technique T1110.003, Password Spraying, est exploitable. Un article annonçant que « les cyberattaques augmentent » mérite surtout d’être rangé loin des décisions techniques.

Consigner au minimum :

la date de publication du renseignement ;
la source et son identifiant documentaire ;
le groupe cité dans MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) ;
la technique, son identifiant et ses sous-techniques ;
les actifs ou identités visés ;
la fenêtre temporelle de recherche.

Pour l’exemple, retenir une information reliant le groupe APT29, référencé G0016 dans MITRE ATT&CK, à T1110.003, la pulvérisation de mots de passe. Le scénario vise les comptes de messagerie et les accès d’administration fédérés. Cette technique tente un petit nombre de mots de passe sur un grand nombre de comptes afin d’éviter les verrouillages. Elle laisse donc une signature différente du bourrage d’identifiants massif sur un seul compte.

2. Formuler une hypothèse falsifiable

Écrire l’hypothèse dans un format qui permet un verdict :

Entre le 1er et le 14 septembre, aucune adresse IP externe ne doit produire au moins 20 échecs d’authentification sur 10 comptes distincts en 30 minutes, suivis d’une authentification réussie sur l’un de ces comptes dans les 24 heures.

Cette phrase contient un comportement, des seuils, une période et une condition positive. Si les données ne confirment rien, le résultat est négatif. Si elles correspondent, une investigation démarre. Une hypothèse du type « rechercher une activité suspecte dans les identités » n’a aucun critère de réfutation. C’est un slogan, pas une méthode.

Les seuils doivent venir du comportement normal mesuré sur le périmètre. Un seuil de 20 essais peut être trop élevé pour un portail public, trop bas pour une population derrière une passerelle de sortie partagée. L’adresse IP n’est pas une identité : un réseau de traduction d’adresses, un service de sécurité web ou un accès mobile peut agréger des centaines de personnes. La gestion des identités doit fournir les plages de confiance, les accès d’administration et les comptes de service avant le début de la chasse.

Vérifier les sources de données avant la recherche

Une chasse sans données est une réunion de créativité avec des requêtes décoratives. Vérifier la collecte avant de chercher, pas après avoir interprété une absence de résultat comme une absence d’attaque.

3. Établir la matrice de couverture

Pour l’hypothèse de pulvérisation de mots de passe, trois sources sont nécessaires :

Source	Événements attendus	Vérification minimale
Journaux d’authentification	succès, échecs, adresse IP, compte, application, méthode d’authentification	présence continue sur la fenêtre étudiée
EDR (Endpoint Detection and Response)	processus, connexions réseau, identité de session sur le poste compromis	couverture des postes où les comptes se connectent
DNS (Domain Name System)	requêtes, réponse, poste ou résolveur source	horodatage cohérent et conservation suffisante

Contrôler la disponibilité réelle par échantillonnage. Une table présente dans un SIEM (Security Information and Event Management) ne prouve rien : elle peut contenir trois événements par jour, avoir perdu un champ après un changement de connecteur ou recevoir des horaires locaux sans indication de fuseau. Les horodatages doivent être convertis en UTC (temps universel coordonné) avant toute corrélation.

Documenter également les zones aveugles : authentification héritée, applications qui ne journalisent pas les échecs, postes hors gestion, résolveurs DNS externes et réseaux privés virtuels. L’absence de journal n’est pas une innocence cryptographique. C’est une absence de journal, ce qui se vend moins bien qu’une promesse de visibilité à 360 degrés.

4. Contrôler les accès et les dépendances

Le compte de chasse doit disposer d’un accès en lecture seule aux données, avec une identité de service dédiée. Éviter les jetons personnels copiés dans un script, même lorsque l’exercice semble ponctuel : un script ponctuel survit volontiers à l’exercice. Les secrets d’accès aux interfaces de programmation d’application (API) doivent résider dans le gestionnaire de secrets, être limités au périmètre de lecture et disposer d’une date de rotation.

Prévoir aussi les dépendances opérationnelles :

conservation des journaux supérieure à la fenêtre de recherche ;
synchronisation de temps sur les collecteurs, les postes et les fournisseurs d’identité ;
sauvegarde du dépôt de requêtes et des résultats ;
supervision du pipeline de collecte, avec alerte sur baisse de volume ou rupture de schéma ;
procédure d’escalade vers le centre opérationnel de sécurité, ou SOC (Security Operations Center).

Les mécanismes d’authentification multifacteur, ou MFA (Multi-Factor Authentication), réduisent la valeur d’un mot de passe trouvé, mais ne rendent pas la chasse inutile. Une session déjà ouverte, un jeton volé ou une approbation frauduleuse suivent d’autres chemins. La surface d’attaque des réseaux et celle des identités doivent donc être corrélées, pas rangées dans deux rapports qui ne se parlent jamais.

Exécuter la chasse et qualifier les résultats

5. Lancer une requête reproductible

L’exemple suivant utilise KQL (Kusto Query Language) dans un espace de travail compatible avec les tables SigninLogs. Adapter les noms de champs au schéma réel, puis enregistrer la version exécutée et son empreinte de révision.

// Recherche T1110.003 : une IP échoue sur plusieurs comptes,
// puis réussit sur au moins un des comptes ciblés dans les 24 heures.
let debut = datetime(2026-09-01T00:00:00Z);
let fin = datetime(2026-09-15T00:00:00Z);
let echecs =
    SigninLogs
    | where TimeGenerated between (debut .. fin)
    | where ResultType != "0"
    | where isnotempty(IPAddress) and isnotempty(UserPrincipalName)
    | summarize Echecs = count(),
                Comptes = dcount(UserPrincipalName),
                ListeComptes = make_set(UserPrincipalName, 100)
      by IPAddress, bin(TimeGenerated, 30m)
    | where Echecs >= 20 and Comptes >= 10;
let succes =
    SigninLogs
    | where TimeGenerated between (debut .. fin + 24h)
    | where ResultType == "0"
    | project IPAddress, UserPrincipalName, SuccesHoraire = TimeGenerated,
              Application = AppDisplayName;
echecs
| mv-expand Compte = ListeComptes
| join kind=inner (succes) on $left.IPAddress == $right.IPAddress,
                              $left.Compte == $right.UserPrincipalName
| where SuccesHoraire between (TimeGenerated .. TimeGenerated + 24h)
| project TimeGenerated, IPAddress, Echecs, Comptes, Compte,
          SuccesHoraire, Application
| order by SuccesHoraire desc

Cette requête ne démontre pas une compromission. Elle produit des candidats. Qualifier chaque résultat avec l’application visée, le pays ou le réseau source, le statut MFA, les appareils connus et les accès ultérieurs. Rechercher ensuite, dans l’EDR, des connexions depuis le poste du compte concerné et, dans les journaux DNS, des résolutions vers des domaines récemment créés ou inhabituels.

Une adresse IP appartenant à un fournisseur d’accès grand public n’est pas une preuve. Une réussite suivie d’un changement de méthode MFA, d’une inscription d’appareil et d’une consultation de messagerie à haut volume mérite en revanche une priorité élevée. L’attribution à APT29 reste hors de portée de cette chasse : la technique est partagée par beaucoup d’acteurs, y compris les scripts bricolés à 2 heures du matin.

6. Documenter aussi le résultat négatif

Créer un enregistrement de chasse comprenant l’hypothèse, les sources, les périodes couvertes, les requêtes exactes, les seuils, les exclusions, les résultats et la décision. Pour un résultat négatif, noter explicitement ce qui a été vérifié et les angles morts connus.

Un résultat négatif valide seulement cette proposition : aucun comportement correspondant n’a été observé dans les données disponibles, sur la période étudiée, avec les critères retenus. Il ne garantit ni l’absence d’attaque, ni la qualité de la collecte, ni la détection d’une variante lente. Cette nuance évite de transformer un trou de télémétrie en certificat d’immunité, objet rare mais très prisé dans les slides.

Transformer une découverte en règle de détection

7. Séparer recherche, alerte et réponse

Si la chasse produit un cas confirmé ou suffisamment suspect, convertir la logique en règle de détection. Garder la requête de chasse intacte : elle sert de référence exploratoire. La règle de production doit être plus déterministe, versionnée, testée et associée à une procédure de réponse.

Définir pour la règle :

les sources obligatoires et leur fraîcheur maximale ;
les seuils et la fenêtre glissante ;
les exclusions limitées dans le temps, avec propriétaire ;
la gravité selon succès, privilège du compte et contexte MFA ;
les champs nécessaires au triage ;
l’action attendue : validation, suspension de session, réinitialisation de secret ou escalade.

Une exclusion permanente pour une adresse IP « connue » devient rapidement une porte de service. Les infrastructures de confiance changent, sont compromises et se recyclent. Toute exception doit expirer et être revue.

8. Tester, déployer et exploiter la règle

Créer des jeux d’événements synthétiques représentant au moins un cas positif, un cas négatif et un cas limite sous le seuil. Tester la règle à chaque modification de schéma ou de connecteur. Les changements de noms de champs cassent les détections silencieusement, avec l’élégance d’un extincteur rempli de confettis.

Mesurer les faux positifs, le délai entre événement et alerte, la part des alertes qualifiables et les ruptures de collecte. Une règle qui génère du bruit sans contexte sera contournée par le SOC, puis oubliée. Une règle qui alerte peu mais fournit compte, adresse IP, application, statut MFA et chronologie est exploitable.

La détection ne remplace pas le durcissement : imposer MFA résistant à l’hameçonnage pour les comptes sensibles, désactiver les protocoles d’authentification hérités, appliquer des politiques de verrouillage cohérentes et surveiller les modifications d’identité. Les faiblesses des protocoles historiques, notamment NTLM, doivent être traitées à la source. La règle détecte une manifestation, elle ne répare pas l’architecture.

🐝 Ce qui arrive si on s’en passe

Sans chasse fondée sur une hypothèse, la détection se limite aux règles fournies par les éditeurs : une technique connue publiquement peut rester non recherchée pendant des mois, faute d’avoir été traduite en critères observables. Les zones aveugles ne sont découvertes qu’au moment d’un incident, quand la fenêtre de conservation a déjà expiré et que les journaux nécessaires n’existent plus. Sans mesure préalable du comportement normal, les seuils sont improvisés en urgence, ce qui produit soit du bruit, soit un silence rassurant. Sans enregistrement de chasse, aucune réponse défendable à la question posée après une publication de renseignement : les mêmes requêtes sont réécrites de zéro, avec des périmètres différents et des résultats non comparables. Une rupture de collecte ou un changement de schéma passe alors inaperçue, puisque rien n’exerce régulièrement le pipeline.

🦫 Explication de la marmotte 🍫

La chasse commence par une information précise sur une méthode utilisée par des attaquants. Cette information doit être datée et dire ce qui est recherché. Ensuite, une phrase vérifiable est écrite : elle précise quels événements chercher, pendant combien de temps et à partir de quel seuil le résultat devient suspect.

Avant la recherche, il faut vérifier que les systèmes enregistrent vraiment les connexions, les activités sur les postes et les demandes de noms sur le réseau. Si ces traces manquent, la recherche ne peut pas répondre correctement. Il faut aussi vérifier que les heures sont comparables et que les données ne sont pas supprimées trop tôt.

Une requête examine alors les traces pour trouver le comportement prévu. Dans cet exemple, elle cherche une même adresse réseau qui échoue sur beaucoup de comptes, puis réussit sur l’un d’eux. Chaque résultat est contrôlé avec d’autres traces pour éviter de confondre un attaquant avec un utilisateur légitime ou un service partagé.

Même sans découverte, le travail est enregistré : ce qui a été cherché, les données disponibles et les limites connues. Si un comportement hostile est confirmé, la recherche manuelle devient une règle automatique. Cette règle doit être testée, surveillée et corrigée quand les systèmes changent. Elle ne bloque pas à elle seule les attaques : les protections des comptes, les restrictions d’accès et la réaction humaine restent nécessaires.

Pages voisines

La citent

Exécuter un threat hunting à partir d'une hypothèse

Elle cite