Rétrochasse d’IOC : enquêter dans les logs historiques

La rétrochasse d’IOC, ou retrohunting, recherche dans les logs historiques les traces d’un indicateur découvert plus tard. Elle permet de rouvrir une enquête à partir d’un domaine, d’une IP ou d’un hash nouvellement associé à une menace. Sa difficulté principale est temporelle : ce que nous savons aujourd’hui ne décrit pas forcément ce qui était vrai, visible ou connu au moment de l’événement.

Le 10 septembre 2026, une discussion sur r/Splunk consacrée au passage du renseignement aux détections testées interroge notamment la télémétrie disponible et la réévaluation des détections. La rétrochasse est un prolongement pratique de cette question, développé ici comme méthode d’enquête. Ce fil ne fournit ni benchmark ni preuve de l’efficacité d’un produit.

Une rétrochasse utile doit répondre à deux questions distinctes : retrouve-t-on aujourd’hui une activité qui mérite investigation, et aurait-on pu la détecter avec les informations réellement disponibles à l’époque ? Les confondre crée des faux positifs historiques et des évaluations injustes du SOC.

Partir d’une hypothèse bornée

Écrivez ce que la recherche doit vérifier avant d’importer une liste. Par exemple : « Des postes administrés ont-ils contacté les domaines attribués à cette campagne pendant la période documentée ? » Précisez les sources de logs, les environnements, les dates et les observables retenus.

Pour un besoin de chasse récurrent, le modèle PIR aide à préciser le responsable de la décision, les preuves nécessaires et les conditions d’arrêt ou de réouverture de la collecte.

Une recherche de contact n’est pas une recherche de compromission. Une requête DNS peut provenir d’un outil de sécurité ; une connexion bloquée n’a pas le même sens qu’un téléchargement réussi. Le type d’événement détermine ce que vous pourrez conclure.

Choisissez également un point d’arrêt. Une campagne peut fournir des milliers d’indicateurs, mais votre première hypothèse peut ne concerner que les domaines associés à un mode d’accès utilisé dans l’entreprise. Ce découpage rend la recherche explicable et permet d’élargir ensuite sur la base des résultats.

Pour le traitement initial des données, notre guide des pipelines d’IOC décrit la normalisation et la provenance. Ici, l’objectif est de préserver leur signification dans le temps.

Conserver plusieurs horloges dans le dossier

Le temps de l’événement décrit quand l’action a eu lieu selon sa source. Le temps d’ingestion décrit quand le collecteur ou le SIEM l’a reçue. Un retard de transfert, une restauration d’archives ou une erreur de fuseau peuvent les éloigner.

Dans Splunk, les modificateurs temporels distinguent la recherche sur le temps de l’événement et celle sur le temps d’indexation. La documentation précise qu’un filtre d’indexation nécessite aussi une fenêtre d’événements adaptée. Pour une archive réingérée aujourd’hui, une fenêtre limitée aux événements d’aujourd’hui peut donc manquer les traces anciennes.

Le renseignement possède ses propres dates : observation de la source, publication, modification et réception locale. Enregistrez leur définition, leur origine et les éventuelles valeurs absentes. Un champ simplement nommé date n’est pas suffisant.

Enfin, notez l’heure d’exécution de la chasse et la version de ses entrées. Vous pourrez ainsi expliquer pourquoi une recherche relancée une semaine plus tard donne un autre résultat, même si les logs n’ont pas changé.

Ne pas transformer first_seen en date de compromission

Une première observation indique une limite de connaissance de la source. Elle ne garantit pas que l’activité a commencé à cet instant. À l’inverse, la création administrative d’un objet CTI ne date pas nécessairement l’activité qu’il décrit.

Le standard STIX 2.1 d’OASIS sépare l’observation (first_observed, last_observed) de la validité d’un Indicator (valid_from, valid_until, optionnel). Une borne supérieure absente ne prouve pas qu’une infrastructure restera malveillante indéfiniment.

Dans votre modèle d’enquête, gardez séparément les bornes déclarées par la source et les bornes que vous déduisez des preuves. Si vous élargissez la recherche avant la première observation connue, marquez cette extension comme exploratoire.

Une adresse IP réattribuée illustre le risque : le même texte peut désigner des usages différents à plusieurs dates. La réputation d’une IP apporte un contexte ; une affirmation sur le passé exige des éléments compatibles avec cette période.

Lire une chronologie fictive sans réécrire le passé

Prenons facture-support.example, un domaine réservé à cet exemple fictif. Les dates ci-dessous servent uniquement à illustrer le raisonnement.

28 août, 14 h 00 : requête DNS du poste A
28 août, 14 h 02 : événement reçu par le SIEM
29 août, 07 h 00 : première observation malveillante documentée
30 août, 11 h 00 : connexion du poste B
3 septembre, 08 h 00 : publication du renseignement
3 septembre, 08 h 10 : renseignement disponible localement
4 septembre, 09 h 00 : connexion du poste C
17 septembre : exécution de la rétrochasse

Le poste A mérite un examen, mais son événement précède la première preuve malveillante disponible. On ne peut ni le déclarer compromis ni le déclarer sain à partir de cette seule chronologie. Il faut chercher d’autres éléments : contenu reçu, processus, redirections ou observations historiques supplémentaires.

L’événement du poste B se situe après l’observation malveillante et avant la publication. La rétrochasse peut le retrouver aujourd’hui. Elle ne permet pas d’affirmer que le SOC aurait dû déclencher une alerte fondée sur ce flux le 30 août.

Le poste C a communiqué après réception locale du renseignement. Si les logs étaient disponibles, le mapping correct et une règle active, l’absence d’alerte devient une question opérationnelle légitime. Elle nécessite encore de vérifier la configuration effective à cette date.

Construire deux recherches complémentaires

La première recherche vise la découverte rétrospective avec le renseignement disponible aujourd’hui. Elle retrouve les candidats sur une période choisie et annote leur relation avec la fenêtre documentée. Elle peut conserver des résultats antérieurs à cette fenêtre pour investigation, sans les qualifier automatiquement.

La seconde rejoue une capacité de détection passée. Pour chaque instant d’évaluation, elle doit utiliser seulement les versions de renseignement et les événements alors disponibles. Une publication antérieure n’aide pas un système qui ne l’a ingérée qu’après l’évaluation.

Ce pseudocode décrit la logique, sans imposer de schéma SIEM :

Découverte rétrospective :
  événements conservés dans le périmètre
  + indicateurs du jeu de renseignement figé aujourd’hui
  + annotation de compatibilité temporelle
  => candidats à investiguer

Rejeu d’une détection à l’instant T :
  événements disponibles localement à T
  + version du renseignement disponible localement à T
  + paramètres de la règle et fenêtre de recherche à T
  => résultats que cette configuration aurait pu produire

Pour ce second usage, gardez aussi les délais de collecte et la cadence d’exécution. Un événement reçu à 10 h 07 ne pouvait pas apparaître dans la recherche lancée à 10 h 05, même si son horodatage indique 10 h 01.

Archiver les versions, pas seulement la valeur actuelle

Une simple table « domaine, verdict actuel » écrase les changements d’avis. Elle ne permet pas de reconstituer le renseignement connu au moment d’une décision. Conservez l’identifiant de la source, la version reçue, sa date de réception et les mises à jour ou retraits.

La documentation du cycle de vie CTI de Microsoft Sentinel indique notamment que les créations, mises à jour et suppressions produisent de nouvelles entrées, tandis que l’interface affiche l’indicateur le plus récent. Ce comportement rappelle qu’une vue courante et l’historique des données répondent à des besoins différents. Vérifiez la rétention et le schéma effectifs de votre déploiement.

N’écrasez pas une qualification historique lorsque la source révoque un indicateur. Enregistrez la correction et réévaluez les dossiers concernés. Il faut pouvoir montrer à la fois pourquoi l’alerte a été produite et pourquoi son interprétation a changé.

Les champs de STIX et TAXII dans les pipelines aident à transporter ces informations. Leur présence dans un format ne dispense pas de vérifier que le connecteur les conserve.

Contrôler la couverture avant de lancer une recherche coûteuse

Dressez une fiche de couverture par source : période réellement consultable, environnements couverts, interruptions connues, champs disponibles et niveau d’agrégation. Un index de 90 jours n’implique pas 90 jours complets pour tous les postes.

Vérifiez que l’observable recherché peut apparaître dans le champ choisi. Des logs proxy peuvent conserver le domaine sans chemin ; des journaux réseau peuvent ne donner que l’IP distante ; les caches DNS peuvent réduire le nombre d’événements observés. Ces limites changent la portée du résultat.

Testez le parsing sur des événements connus. Un domaine avec point terminal, une URL encodée ou une forme différente d’IPv6 peut échapper à une égalité textuelle. La normalisation doit préserver l’information utile : retirer le chemin d’une URL peut supprimer ce qui distingue un service partagé de la ressource malveillante.

Interrogez d’abord une petite tranche pour vérifier le plan et les champs. Étendez ensuite par périodes ou sources, en enregistrant les lots terminés. Un échantillon partiel ou une requête interrompue ne doit pas être présenté comme un examen complet.

Valider la logique avec des cas temporels explicites

Avant de parcourir les archives, préparez quelques événements synthétiques dans un jeu isolé. Il n’est pas nécessaire de contacter une infrastructure malveillante. L’objectif est de tester votre corrélation, pas de reproduire une attaque.

Les cas doivent couvrir les limites qui changent l’interprétation : un événement avant la validité déclarée, un autre dans cette fenêtre, un renseignement reçu tardivement, une révocation et deux versions contradictoires. Ajoutez un événement arrivé après l’instant de rejeu malgré un horodatage ancien.

Pour chaque cas, écrivez le résultat attendu dans les deux modes. Un événement peut être candidat en découverte rétrospective et absent du rejeu historique. Cette différence est correcte si elle découle des dates disponibles.

Un contrôle supplémentaire doit vérifier les doublons. Le même événement peut exister dans une archive réingérée et dans l’index d’origine. Compter deux occurrences comme deux actions distinctes fausse les chronologies et les mesures de fréquence.

Transformer une correspondance en preuve exploitable

Pour chaque résultat pertinent, conservez l’événement brut ou sa référence durable, le collecteur, les deux horodatages, l’actif et l’indicateur qui a correspondu. Joignez la version du renseignement et la raison exacte de l’association.

Recherchez ensuite des preuves adaptées à l’hypothèse. Pour un domaine, la requête DNS peut être reliée à une connexion et à un processus si la télémétrie le permet. Pour un hash, distinguez présence sur disque, téléchargement, quarantaine et exécution. Notre méthode pour corréler une alerte IOC avec IP, DNS et processus détaille ce passage.

Évitez l’attribution automatique. Une association à une campagne renseigne sur un contexte publié ; elle ne démontre pas l’identité de l’opérateur qui a provoqué votre événement. Le dossier doit conserver cette différence, surtout lorsqu’il sera lu hors du SOC.

Rédiger un résultat négatif avec ses limites

« Aucun signe de compromission » est trop large pour une simple recherche d’indicateurs. Préférez une formulation qui décrit réellement le travail accompli :

Aucune correspondance retrouvée pour les 42 domaines du jeu CTI version X
dans les logs DNS des postes administrés du siège,
du 20 août au 10 septembre inclus.

Limites : absence de collecte sur les mobiles ; interruption du collecteur
le 27 août ; chemins URL non disponibles ; les comportements sans ces
domaines n’étaient pas couverts par cette recherche.

Ces chiffres sont illustratifs. Le modèle reste utile parce qu’il permet au destinataire de décider si une collecte complémentaire est nécessaire. Documenter un angle mort ne retire pas sa valeur à la recherche ; cela empêche de lui faire dire davantage que ses données.

Fermer la chasse en conservant sa reproductibilité

Archivez la requête, ses paramètres, les versions d’IOC, le périmètre et les lots réellement exécutés. Notez les résultats ouverts, écartés et confirmés, ainsi que les actions créées. Une date de réexamen peut être utile si une source doit compléter la fenêtre d’activité.

Pour un indicateur partageable, une recherche IsMalicious peut apporter un contexte de réputation à joindre au dossier. Datez cette consultation et ne la transformez pas en preuve de réputation historique si le résultat ne documente pas cette période.

La conclusion de la chasse doit rester une affirmation vérifiable : quelles traces ont été trouvées, à quelles dates, avec quelles preuves et quelles données manquantes. C’est cette précision qui permet de relancer l’enquête après une mise à jour du renseignement, sans refaire le raisonnement depuis le début.