Comment formuler une hypothèse de threat hunting

Le threat hunting consiste à chercher un comportement hostile avant qu’une règle automatisée ne le signale. La démarche part d’une hypothèse falsifiable, fondée sur un mode opératoire connu, puis vérifie si les traces attendues existent dans les journaux disponibles. Ce n’est pas de la détection avec un tableur plus triste, c’est une enquête orientée par une question précise.

→ Lire l’explication complète de la marmotte

Hypothèse de chasse et renseignement sur la menace

Une hypothèse de chasse relie trois éléments : un adversaire ou une famille d’adversaires plausible, une technique observée chez cet adversaire, et des traces vérifiables dans le système d’information. Une formulation exploitable ressemble à ceci : « Des opérateurs visant le secteur utilisent PowerShell pour exécuter des charges encodées ; cette activité doit produire des événements de création de processus contenant -EncodedCommand sur les postes administrés. »

Le renseignement sur la menace, ou threat intelligence, ne vaut pas par l’accumulation d’indicateurs de compromission. Une adresse IP ou une empreinte de fichier expire vite, est partagée avec des infrastructures légitimes ou n’a jamais concerné l’environnement étudié. Les comportements résistent mieux : création de tâche planifiée, extraction de tickets Kerberos, modification de règles de messagerie, usage d’un compte de service hors de ses horaires attendus.

MITRE ATT&CK est une base de connaissances qui classe ces comportements en techniques et sous-techniques. Elle sert à nommer une hypothèse et à éviter les formulations vagues du genre « chercher du ransomware ». Une technique ATT&CK n’est toutefois pas une requête prête à l’emploi. Elle décrit un comportement, pas la télémétrie réellement disponible ni le contexte métier qui distingue un administrateur d’un intrus.

Le compromis central est net : une hypothèse étroite produit peu de bruit mais couvre une fraction limitée de l’attaque ; une hypothèse large augmente la couverture mais noie l’analyse dans les usages normaux. Il faut privilégier des hypothèses étroites, liées à une technique précise et à une source de données confirmée. Chercher « toute activité anormale » est une stratégie de présentation commerciale, pas une méthode d’investigation.

Le point de départ peut venir des menaces documentées, d’un rapport sectoriel ou d’une exposition locale connue. Une authentification NTLM (NT LAN Manager) observée depuis un réseau non administré, par exemple, justifie une chasse dédiée si l’environnement conserve ce protocole. La page sur le durcissement NTLM complète alors la chasse par une mesure de réduction de surface.

Données de chasse et prérequis de plateforme

Une chasse ne compense jamais une télémétrie absente. Avant de retenir une hypothèse, il faut établir la matrice technique -> trace attendue -> source -> durée de rétention -> propriétaire. Si la création de processus n’est pas journalisée avec la ligne de commande, une chasse sur les commandes encodées devient une séance de divination avec des index Elasticsearch.

Les prérequis minimaux sont les suivants :

des journaux de création de processus, avec parent, utilisateur, hôte, ligne de commande et intégrité du processus ;
des événements d’authentification, incluant source, destination, type de connexion et résultat ;
des journaux DNS (Domain Name System), proxy et pare-feu horodatés de façon cohérente ;
une synchronisation NTP (Network Time Protocol) vérifiée sur les collecteurs et les sources ;
une rétention alignée sur le délai de découverte réaliste, généralement au moins 90 jours pour les journaux d’investigation ;
un inventaire des hôtes, comptes de service, administrateurs et applications exposées.

Un SIEM (Security Information and Event Management) centralise et interroge les événements. Un EDR (Endpoint Detection and Response) apporte la visibilité sur les postes et serveurs. Aucun des deux ne remplace l’autre : le SIEM corrèle des sources différentes, l’EDR donne le détail local. Une chasse sur un mouvement latéral sans événements d’authentification centralisés rate précisément les machines qui intéressent l’attaquant.

La qualité des champs compte davantage que le volume brut. Une adresse source sans zone réseau, un nom d’utilisateur sans identifiant stable ou un horodatage sans fuseau horaire empêchent des corrélations élémentaires. Les pipelines qui normalisent les données doivent conserver l’événement brut, sinon une erreur de parseur devient une vérité officielle. Les données transformées sont pratiques ; les données brutes servent quand elles cessent de l’être.

Exemple de chasse sur PowerShell encodé

L’hypothèse suivante cible la sous-technique ATT&CK T1059.001, exécution via PowerShell : un attaquant peut employer l’option -EncodedCommand pour masquer une commande dans la ligne de commande. Cette option peut aussi être légitime, notamment dans certains outils d’administration. La chasse doit donc sortir les occurrences, puis les enrichir avec le compte, le processus parent et le rôle de l’hôte.

L’exemple ci-dessous interroge un fichier JSON Lines, un objet JSON par ligne, exporté depuis une collecte de processus. Il est reproductible avec jq 1.6 ou version ultérieure.

# Chercher les exécutions PowerShell contenant une commande encodée.
# Le filtre accepte powershell.exe et pwsh.exe, sans dépendre de la casse.
jq -c '
  select(
    (.process.name | ascii_downcase | test("^(powershell|pwsh)(\\.exe)?$"))
    and
    (.process.command_line | test("(^|[[:space:]])-[Ee](ncoded[Cc]ommand)?[[:space:]]"))
  )
  | {
      timestamp: "@timestamp",
      host: .host.name,
      user: .user.name,
      parent: .process.parent.name,
      command_line: .process.command_line
    }
' process-events.jsonl

Le résultat ne constitue pas une compromission. Il faut vérifier si le compte est attendu sur cet hôte, si le parent est un outil de déploiement connu, si la commande décodée contacte un domaine inédit et si la même séquence apparaît sur plusieurs postes. Décoder la charge est nécessaire, mais exécuter la charge pour « voir ce qu’elle fait » transforme une investigation en concours de mauvaises idées.

Une requête productive inclut une période définie, des exclusions justifiées et une limite de résultat explicite. Les exclusions doivent être attachées à un propriétaire et à une date de révision. Une exclusion permanente pour un outil d’administration est souvent la porte de service préférée d’un attaquant : les outils d’administration sont faits pour administrer, ce qui est leur défaut de caractère.

Résultats négatifs, qualification et preuves

Un résultat négatif signifie seulement qu’aucune trace correspondant à la requête n’a été trouvée dans les données interrogées. Il ne prouve ni l’absence de l’attaquant ni l’absence du comportement. Une collecte incomplète, une période trop courte, un champ mal normalisé ou une requête trop restrictive produisent le même résultat vide.

Chaque chasse doit être consignée dans un registre durable avec :

l’hypothèse, la technique ATT&CK et les sources de renseignement ;
la requête exacte, sa version et la fenêtre temporelle ;
les jeux de données interrogés, leur rétention et leurs angles morts ;
les exclusions appliquées et leur justification ;
les résultats, positifs ou négatifs ;
la décision prise : clôture, investigation, enrichissement de données ou détection à créer.

Pour un résultat positif, la qualification suit une chaîne de preuves. Partir de l’événement initial, retrouver l’arbre des processus, les authentifications associées, les requêtes DNS, les connexions sortantes et les modifications d’identité. Les fondations de l’architecture cyber rappellent une règle souvent oubliée : une preuve technique doit être reliée à un actif, un propriétaire et une décision de réponse. Un nom de machine sans responsable est juste un problème avec une adresse IP.

La chasse ne garantit pas l’attribution d’une attaque à un groupe. ATT&CK décrit des techniques réutilisables ; plusieurs acteurs, administrateurs et logiciels légitimes peuvent produire la même trace. Elle ne garantit pas non plus l’exhaustivité : un adversaire peut désactiver la journalisation, contourner l’agent local ou opérer dans une zone non collectée. La réponse à ces limites vient du durcissement, du cloisonnement réseau, de la surveillance de l’intégrité et de la conservation des journaux hors de l’hôte surveillé.

Détection pérenne, exploitation et reprise

Une chasse fructueuse doit devenir une détection automatisée lorsque le comportement est récurrent, observable de manière stable et suffisamment discriminant. L’objectif est de ne pas refaire chaque semaine la même requête manuelle en espérant que l’ennemi respecte le calendrier. Une règle de détection reprend la logique validée, ajoute un seuil, des exclusions contrôlées et un routage vers une procédure de triage.

Il ne faut pas automatiser un résultat ambigu. Si la chasse révèle cinquante usages légitimes pour une occurrence hostile, la priorité est d’ajouter du contexte, pas de déclencher cinquante alertes. Les règles qui alertent sur tout finissent par alerter sur rien : le silence d’un centre opérationnel débordé est une contre-mesure assez médiocre.

L’exploitation impose aussi de protéger les données de chasse. Les jetons d’accès au SIEM, les clés d’API (Application Programming Interface) de l’EDR et les comptes de collecte doivent être séparés des comptes d’administration courante, limités en lecture lorsque possible et stockés dans un gestionnaire de secrets. Une compromission du compte de chasse donne à l’attaquant une carte des angles morts, parfois avec fonction recherche.

La rotation des secrets doit être testée avec les connecteurs de collecte, pas seulement déclarée dans une politique. Sauvegarder les règles, requêtes, tableaux d’exclusion et dictionnaires d’actifs dans un dépôt versionné est indispensable. En reprise après incident, restaurer le SIEM sans restaurer les règles de détection et leurs justifications revient à reconstruire un poste de pilotage avec des boutons sans étiquettes.

La supervision doit couvrir le taux d’ingestion, les retards d’horodatage, les échecs d’agents, les modifications de règles et les volumes anormalement bas. Une baisse brutale de journaux est elle-même un signal de sécurité. L’attaquant patient préfère souvent faire taire le thermomètre avant de monter la fièvre.

🐝 Ce qui arrive si on s’en passe

Sans chasse par hypothèses, la détection se limite à ce que les règles existantes savaient déjà décrire au moment de leur écriture : un comportement qui n’a jamais été modélisé ne produit aucun signal, et son absence de signal passe pour une absence de menace. Les angles morts de collecte ne sont alors jamais découverts, puisque rien ne vient interroger la télémétrie pour constater qu’un champ manque, qu’une rétention est trop courte ou qu’un agent a cessé de remonter. Les exclusions héritées ne sont plus relues et se transforment en couloirs permanents. Faute de registre de chasse, une investigation ultérieure repart de zéro : impossible de savoir quelles périodes ont déjà été examinées, avec quelle requête et sur quelles sources, ce qui allonge la reconstitution d’incident et empêche de justifier une conclusion négative.

🦫 Explication de la marmotte 🍫

Le threat hunting commence par une idée vérifiable sur une action possible d’un attaquant. Cette idée vient de rapports décrivant des attaques déjà observées contre des organisations semblables, par exemple l’usage inhabituel d’un programme d’administration ou la création d’un accès caché. Il faut ensuite vérifier que les machines, serveurs et équipements réseau enregistrent bien les informations nécessaires : qui a lancé une action, depuis quel poste, à quel moment et avec quelle commande.

Les analystes écrivent alors une recherche qui examine les enregistrements conservés. Ils ne cherchent pas seulement un nom de fichier connu, car ce nom peut changer. Ils cherchent plutôt une manière d’agir. Chaque recherche doit être conservée avec sa date, les données examinées et le résultat obtenu. Si aucun indice n’apparaît, cela ne prouve pas qu’aucune intrusion n’existe : les informations peuvent manquer, avoir été effacées ou ne pas couvrir la bonne période.

Quand une recherche révèle une activité suspecte, il faut vérifier d’autres traces pour déterminer si elle est légitime ou hostile. Si le même comportement peut être reconnu de façon fiable, il devient une alerte automatique. Les accès aux journaux, les comptes utilisés pour les consulter et les règles d’alerte doivent être protégés, surveillés, sauvegardés et restaurables après une panne ou une attaque.