Threat hunting : comment traquer les menaces qui dorment dans votre SI depuis des mois ?

L’alerte n’est jamais tombée. Votre SIEM est au vert, votre EDR est silencieux, et pourtant, vous avez ce sentiment persistant que quelque chose ne tourne pas rond. Un sixième sens d’analyste sécurité, nourri par des années à observer les flux et les logs. Cette intuition, c’est le point de départ du véritable threat hunting. Car les adversaires les plus dangereux ne sont pas les plus bruyants ; ce sont ceux qui se sont installés discrètement il y a des mois, qui connaissent votre réseau mieux que certains administrateurs et qui attendent le moment opportun pour frapper.

La réponse classique, basée sur la réaction aux alertes et la recherche d’indicateurs de compromission (IoC) connus, est une course perdue d’avance. Les attaquants modernes sont polymorphes ; ils changent leurs outils, leurs adresses IP et les hachages de leurs malwares plus vite que nous ne mettons à jour nos listes noires. Ils savent que pour rester indétectés, leur meilleur camouflage est de ressembler à un utilisateur légitime. Leurs actions, prises individuellement, semblent anodines. C’est leur enchaînement, leur rythme et leur contexte qui trahissent leur intention malveillante.

Mais alors, si la véritable clé n’était pas de chercher l’outil de l’attaquant, mais de traquer son comportement ? Cet article est un guide pour l’analyste qui veut passer du statut de gardien à celui de chasseur. Nous n’allons pas lister des outils, mais forger une mentalité. Vous apprendrez à construire des scénarios de chasse basés non pas sur ce que les attaquants *sont*, mais sur ce qu’ils *font*. Nous verrons comment débusquer une exfiltration de données métronomique, comment un comportement anormal trahit un compte compromis, et comment organiser vos chasses pour qu’elles soient non seulement efficaces, mais aussi une source d’amélioration continue pour toute votre posture de sécurité.

Cet article vous guidera à travers les stratégies et les mentalités nécessaires pour devenir un chasseur de menaces proactif. Le sommaire ci-dessous vous donne un aperçu des zones de chasse que nous allons explorer ensemble.

Comment construire un scénario de recherche basé sur les dernières tactiques des groupes de ransomware ?

Pour chasser le prédateur, il faut penser comme lui. Un scénario de chasse ne part pas d’une alerte, mais d’une hypothèse construite sur les tactiques, techniques et procédures (TTPs) réelles des adversaires. Face à une menace en constante évolution, avec 46 nouveaux groupes de ransomware ayant émergé en 2024, se baser sur des signatures statiques est une stratégie de l’échec. La vraie question est : « Si le groupe X attaquait mon réseau aujourd’hui, par où commencerait-il et que ferait-il ensuite ? »

L’analyse des rapports de threat intelligence est votre terrain de chasse initial. Vous n’y cherchez pas des IoC, mais des modes opératoires. Par exemple, au lieu de chercher les hachages de fichiers du groupe RansomHub, vous devez comprendre sa méthode. Les rapports récents montrent que ces groupes privilégient l’exploitation de faiblesses simples et scalables plutôt que des vulnérabilités zero-day complexes.

À partir de ce TTP, votre hypothèse de chasse devient concrète : « Je suspecte qu’un attaquant pourrait utiliser un compte VPN compromis pour accéder au réseau et se déplacer latéralement. » Cette hypothèse génère des questions d’investigation précises :

• Existe-t-il des connexions VPN réussies en dehors des heures de travail habituelles ou depuis des géolocalisations inhabituelles pour certains utilisateurs ?
• Après une connexion VPN, observe-t-on une série d’authentifications échouées sur plusieurs serveurs, signe d’une tentative de mouvement latéral ?
• Y a-t-il des comptes VPN qui accèdent à des ressources (serveurs de fichiers, bases de données) pour la toute première fois ?

Cette approche transforme un rapport de renseignement passif en une série de requêtes actives dans vos logs. Vous ne cherchez plus un artefact, vous cherchez une histoire, une séquence d’événements qui, mis bout à bout, trahissent l’intention de l’attaquant.

Pourquoi chercher des comportements suspects est plus efficace que chercher des hachages de fichiers (IoC) ?

Se fier aux Indicateurs de Compromission (IoC) comme les hachages de fichiers ou les adresses IP, c’est comme essayer d’attraper un espion en se basant sur la couleur de son manteau. L’adversaire n’a qu’à changer de manteau pour disparaître. Un attaquant peut recompiler son malware pour en changer le hash en quelques secondes. Il peut changer d’adresse IP à volonté. Courir après les IoC est une course épuisante et fondamentalement réactive. La véritable révolution du threat hunting est le passage de la recherche d’artefacts à la traque de comportements.

Comme le montre cette illustration, la détection par signature est rigide, statique. Le comportement, lui, est un flux dynamique. Un comportement suspect est une série d’actions qui, bien que potentiellement légitimes si prises isolément, deviennent suspectes par leur enchaînement, leur timing ou leur contexte. Cette approche est d’autant plus cruciale que selon le rapport CrowdStrike 2025, près de 79% des détections en 2024 étaient sans malware, reposant sur l’abus d’outils légitimes (PowerShell, WMI, etc.). Ces attaques « living-off-the-land » ne laissent aucun IoC de fichier à chasser.

La chasse comportementale s’appuie sur une hiérarchie d’indicateurs, où chaque niveau est plus difficile et coûteux à modifier pour l’attaquant :

• Niveau 1 – Indicateurs atomiques : Adresses IP, domaines, hachages. Faciles à détecter, mais triviaux à changer pour l’attaquant. C’est le niveau le plus bas de la chasse.
• Niveau 2 – Artefacts réseau et hôte : Patterns de trafic, user-agents, noms de fichiers de configuration. Un peu plus stables, ils demandent un effort de reconfiguration à l’attaquant.
• Niveau 3 – TTPs et stratégies : L’objectif final de l’attaquant (ex: exfiltrer des données du CRM) et sa méthode pour y parvenir (ex: mouvement latéral via RDP, puis compression des données). C’est le Saint Graal de la détection. Changer de TTP est extrêmement coûteux pour un attaquant, car cela l’oblige à revoir toute sa chaîne d’attaque.

En vous concentrant sur le niveau 3, vous ne vous demandez plus « Est-ce que je vois le hash XYZ ? », mais « Est-ce que je vois une séquence d’actions qui ressemble à une reconnaissance interne suivie d’une préparation à l’exfiltration ? ». C’est un changement de perspective qui vous donne un avantage stratégique durable sur l’adversaire.

Comment repérer une exfiltration de données lente en analysant la régularité des connexions sortantes ?

L’exfiltration de données n’est pas toujours un « big bang ». Les attaquants les plus méthodiques préfèrent une approche « low and slow » pour rester sous le radar. Ils établissent un canal de communication discret et exfiltrent les données par petits morceaux, sur une longue période. Ce trafic se noie dans le bruit de fond des communications légitimes, le rendant invisible aux seuils d’alerte volumétriques. La clé pour le détecter n’est pas la taille, mais le rythme.

Le trafic généré par un humain est intrinsèquement chaotique : il se produit en rafales, avec des tailles de paquets variables, principalement pendant les heures de bureau. À l’inverse, un script d’exfiltration automatisé est souvent métronomique. Il génère des connexions à intervalles parfaitement réguliers (par exemple, toutes les 5 minutes, à la seconde près), avec des paquets de taille similaire. C’est cette régularité anormale, ce « battement de cœur » synthétique dans votre réseau, que vous devez chasser.

Cette approche est d’autant plus critique que les attaquants sont de plus en plus rapides une fois à l’intérieur. Une analyse de Vectra AI montre que le temps moyen entre l’accès initial et le premier mouvement latéral est tombé à seulement 48 minutes en 2024, ce qui signifie que le canal de persistance est établi très rapidement. Votre fenêtre de détection est courte.

Pour débusquer ce trafic, il faut comparer les caractéristiques des flux sortants. Voici une grille d’analyse simple :

L’hypothèse de chasse devient : « Je suspecte une exfiltration lente via un beacon C&C ». Vous pouvez alors chercher des flux sortants vers une même destination avec une faible variance dans l’intervalle de temps entre les connexions ou dans la taille des paquets. C’est en traquant cette régularité contre-nature que vous démasquerez l’attaquant qui se croyait invisible.

Le risque de passer 3 jours à enquêter sur un faux positif administratif non documenté

Le cauchemar de tout chasseur de menaces n’est pas l’attaquant sophistiqué, mais le script de sauvegarde non documenté lancé par un administrateur système il y a deux ans. Vous détectez un comportement anormal : un poste de travail qui se connecte à un serveur de fichiers à 3h du matin et transfère un volume de données inhabituel. Vous passez des heures, voire des jours, à remonter la piste, à analyser les processus, à corréler les logs, pour finalement découvrir qu’il s’agit d’un processus légitime mais obscur. Vous avez perdu un temps précieux, et votre crédibilité en a pris un coup.

Ce gaspillage de ressources est un risque majeur, surtout dans un contexte où chaque minute compte. Selon certaines statistiques, une interruption non planifiée peut coûter cher, soulignant l’importance d’allouer les ressources d’investigation de manière efficace. L’enjeu n’est pas seulement de trouver le mal, mais aussi de qualifier rapidement le bénin pour passer à la chasse suivante. Sans une méthodologie rigoureuse, chaque chasse recommence à zéro, et l’équipe risque de courir plusieurs fois après les mêmes « fantômes » légitimes.

La solution est de transformer chaque investigation, même celle qui se termine en faux positif, en une opportunité de capitalisation. Cela passe par la tenue d’un Journal de Chasse stratégique. Ce n’est pas une simple documentation, c’est la mémoire de votre SOC.

Un faux positif bien documenté n’est pas un échec, c’est une réussite. C’est une partie de votre réseau que vous comprenez mieux, une zone de bruit que vous saurez désormais ignorer pour vous concentrer sur les véritables signaux faibles.

Chasse continue ou sessions programmées : quelle organisation pour une petite équipe ?

L’idée d’une équipe de threat hunters dédiée à 100% à la chasse est un luxe que seules les très grandes organisations peuvent s’offrir. Pour une équipe de sécurité de petite ou moyenne taille, la réalité est un jonglage constant entre la gestion des alertes, les projets de fond et la chasse proactive. La question n’est pas « faut-il chasser ? » mais « comment intégrer la chasse de manière réaliste et durable ? ». Imposer un modèle de chasse continue à une petite équipe est la recette parfaite pour l’épuisement et l’inefficacité.

La clé est de choisir un modèle d’organisation adapté à vos ressources et à votre maturité. Plutôt que de viser la perfection, visez la consistance. Une chasse de 4 heures par semaine, bien menée et documentée, a plus de valeur qu’une tentative de chasse continue qui s’essouffle après un mois. Le framework PEAK, recommandé par des acteurs comme Splunk, propose une approche structurée : il s’agit d’établir des garde-fous (objectifs clairs, durée limitée) autour de chaque session de chasse pour garantir un résultat, même modeste.

Pour les petites équipes, il est crucial de commencer par des hypothèses simples et de limiter le temps d’investigation (« time-boxing »). Une tactique efficace consiste à noter les « bright shiny objects » – ces anomalies intéressantes mais hors du périmètre de la chasse actuelle – pour en faire les hypothèses des chasses futures. Cela crée un cycle vertueux d’amélioration continue.

Voici les modèles les plus courants, à adapter selon votre contexte :

Pour une petite équipe, le modèle du « Sprint de Chasse » ou du « Threat of the Week » est souvent le plus pertinent. Il sanctuarise un temps dédié, protège les analystes des interruptions et permet d’obtenir des victoires régulières qui maintiennent la motivation et démontrent la valeur de la démarche à la direction.

Comment l’analyse comportementale (UEBA) repère un collaborateur compromis avant le vol de données ?

Un attaquant a obtenu les identifiants d’un de vos collaborateurs. Pour vos systèmes de sécurité traditionnels, il est maintenant invisible. Il utilise un accès légitime, des outils légitimes, et se déplace sur le réseau avec des droits valides. C’est le scénario de la menace interne, qu’elle soit malveillante ou, plus souvent, le résultat d’un compte compromis. Un rapport de Cybersecurity Insiders révèle que près de 83% des organisations ont subi au moins une attaque interne en 2024. Face à cela, les défenses périmétriques sont inutiles.

La solution réside dans l’analyse du comportement des utilisateurs et des entités (UEBA). Le principe de l’UEBA est simple mais puissant : chaque utilisateur a un « rythme circadien numérique » unique. Il se connecte à certaines heures, accède à un ensemble défini de ressources, depuis des lieux habituels, et manipule un volume de données prévisible. L’UEBA établit cette ligne de base comportementale (« baseline ») pour chaque utilisateur et chaque machine, puis recherche les déviations significatives.

Ce n’est plus l’action elle-même qui déclenche l’alerte, mais sa rupture avec les habitudes. ManageEngine rapporte des cas où l’UEBA a permis de détecter des compromissions en identifiant des anomalies contextuelles : un comptable qui accède à un serveur de code source pour la première fois, un développeur qui se connecte depuis un pays où il n’a jamais été, ou un responsable marketing qui commence à créer des archives chiffrées de plusieurs gigaoctets à 2h du matin. Chaque action, prise isolément, pourrait être légitime. C’est leur combinaison et leur déviation par rapport à la norme qui constituent un signal fort.

Les indicateurs comportementaux clés d’une compromission de compte incluent :

• Anomalies temporelles et géographiques : Connexions à des heures inhabituelles (nuit, week-end) ou depuis des géolocalisations anormales.
• Anomalies d’accès aux ressources : Accès à des serveurs, applications ou fichiers jamais consultés auparavant par l’utilisateur.
• Anomalies de volume : Accès ou téléchargement d’un volume de données 10x ou 100x supérieur à la moyenne habituelle de l’utilisateur.
• Anomalies logicielles : Installation de logiciels non standards sur le poste (outils de scan réseau, clients torrent…).
• Anomalies de préparation de données : Création soudaine de nombreuses archives (ZIP, RAR) chiffrées, signe d’une préparation à l’exfiltration.

Une fois une déviation significative détectée, la réponse peut être graduée : forcer une ré-authentification multifacteur (MFA), isoler la session de l’utilisateur, ou bloquer l’accès à la ressource sensible tout en alertant le SOC avec un contexte enrichi. L’UEBA permet ainsi de reprendre l’avantage, en détectant l’attaquant non pas sur ce qu’il est, mais sur la manière dont il trahit les habitudes de sa victime.

Comment repérer un trafic C&C (Command & Control) dissimulé dans des requêtes HTTPS légitimes ?

Le trafic chiffré HTTPS représente aujourd’hui l’écrasante majorité du trafic web. C’est une excellente chose pour la confidentialité, mais c’est aussi une aubaine pour les attaquants. Ils peuvent y dissimuler leurs communications de commande et de contrôle (C&C) en toute impunité, car pour de nombreux outils de sécurité, un flux chiffré est une boîte noire. Le défi est immense : comment distinguer un appel légitime à une API Microsoft d’un beacon C&C qui utilise le même canal ? En moyenne, une intrusion avancée peut rester non détectée pendant 280 jours, un temps largement suffisant pour que l’attaquant établisse une persistance solide.

L’erreur est de penser que le chiffrement rend l’analyse impossible. Même sans déchiffrer le contenu, les métadonnées de la connexion sont une mine d’or pour le chasseur. La technique de l’attaquant consiste souvent à abuser des services dits « Too Big to Block » : Google Drive, Microsoft Graph API, Slack, etc. Bloquer ces destinations est impensable pour l’entreprise. L’attaquant le sait et y cache son trafic.

Votre chasse ne porte plus sur le contenu, mais sur le contenant. L’hypothèse est : « Je suspecte qu’un attaquant utilise un service cloud autorisé pour son C&C ». Les questions à se poser sont :

• Observe-t-on des connexions HTTPS vers des services cloud légitimes avec des User-Agents anormaux (scripts Python, Powershell, vieilles versions de navigateurs) ?
• Existe-t-il des connexions périodiques et régulières vers ces services, en particulier en dehors des heures de bureau ?
• La taille des requêtes et des réponses est-elle anormalement petite et constante, typique d’un « heartbeat » de C&C ?

En analysant ces signaux faibles, vous pouvez identifier le loup déguisé en agneau. Le chiffrement n’est plus un mur, mais une vitre teintée à travers laquelle vous pouvez encore distinguer les silhouettes suspectes.

Pourquoi le Red Teaming est le seul moyen de tester réellement la vigilance de votre SOC ?

Vous avez mis en place des scénarios de chasse, vous analysez les comportements, et votre équipe est organisée. Vos défenses semblent solides. Mais le sont-elles vraiment ? Les tableaux de bord et les taux de détection théoriques sont une chose ; la réalité du terrain en est une autre. La seule façon de savoir si votre piège fonctionne est de demander à un chasseur expert de tenter de l’éviter. C’est le rôle fondamental du Red Teaming : ce n’est pas un audit, c’est un test de stress grandeur nature pour vos capacités de détection et de réponse.

Un exercice de Red Team simule une attaque réelle, menée par des experts qui utilisent les mêmes TTPs que les adversaires que vous cherchez à contrer. Leur objectif n’est pas de « gagner » en atteignant leur but sans être vus, mais de tester chaque couche de votre défense. Chaque action qu’ils mènent est une question posée à votre SOC : « M’avez-vous vu faire ça ? ». Déjà en 2012, le président de la NSA déclarait que « l’analyse comportementale est la solution la plus plausible contre les APT », soulignant la nécessité de valider cette approche face à des menaces réelles.

L’analyse comportementale est la solution la plus plausible contre les APT (menaces persistantes avancées)

– Président de la NSA, Déclaration de 2012

Le plus grand bénéfice d’un Red Team n’est pas le rapport final, mais le processus collaboratif qui suit : le Purple Teaming. C’est une session de débriefing où le Red Team (les attaquants) et le Blue Team (vos analystes) confrontent leurs actions et leurs observations. Le Red Team explique : « À 14:32, j’ai utilisé cette technique de mouvement latéral. » Le Blue Team répond : « Nous n’avons rien vu », ou « Nous avons vu une alerte de bas niveau mais nous ne l’avons pas priorisée. »

Cette confrontation honnête est incroyablement précieuse. Elle révèle les angles morts de votre visibilité et les failles dans vos processus. Le protocole d’amélioration est alors simple et puissant :

1. Documentation : Documenter précisément chaque action du Red Team avec un horodatage.
2. Débriefing : Organiser un débrief immédiat Red/Blue Team après l’exercice pour confronter les actions aux détections.
3. Analyse des écarts : Identifier chaque action non détectée et analyser la cause racine (manque de logs, règle de détection trop permissive, alerte mal qualifiée).
4. Création collaborative : Créer ou affiner collaborativement les règles de détection manquantes pour couvrir ces angles morts.
5. Re-test : Retester les nouvelles règles de détection dans un délai court (ex: 30 jours) pour valider leur efficacité.

Votre prochaine étape n’est pas d’acheter un nouvel outil, mais d’appliquer ces méthodes. Prenez une des hypothèses de cet article, définissez un créneau de chasse pour votre équipe, et lancez votre première chasse structurée dès demain. C’est en forgeant que l’on devient forgeron ; c’est en chassant que l’on devient chasseur.