Alerte IOC : corréler IP, DNS et processus

Une alerte IOC indique qu’un événement correspond à un indicateur de compromission connu : IP, domaine, URL ou empreinte de fichier. Elle ne dit pas, à elle seule, qu’un poste est compromis. Pour établir ce qui s’est passé, il faut relier la réputation externe à une activité locale précise.

La méthode ci-dessous part d’une alerte réseau et rapproche trois familles de journaux : DNS, connexions et processus. Son objectif est de produire une conclusion vérifiable, avec les preuves présentes et les étapes encore inconnues.

Revenir à l’événement qui a déclenché l’alerte

Ouvrez le journal brut, pas uniquement le résumé du SIEM. Notez l’indicateur exact, la règle, la source de renseignement, l’heure de l’événement et celle de son ingestion. Vérifiez aussi si la règle s’est appliquée en direct ou lors d’une recherche rétrospective.

Un domaine signalé aujourd’hui peut apparaître dans un événement ancien. Inversement, un événement récent peut correspondre à un indicateur historique devenu peu pertinent. Le renseignement et l’activité doivent être comparés à leur date, sans transformer une association actuelle en preuve valable à toute époque.

Identifiez enfin l’actif réel. Une IP de sortie partagée peut appartenir à un proxy, un résolveur ou une passerelle. Tant que ce rôle n’est pas établi, la ligne ne désigne pas nécessairement le poste d’un utilisateur.

Réunir les trois pièces de la corrélation

• DNS : réunissez l’hôte client, le nom demandé, la réponse, le statut et l’heure. Quel nom a été recherché, et quelle réponse a été reçue ?
• Réseau ou proxy : relevez l’actif, la destination, le port, l’action, le résultat et l’heure. Une connexion a-t-elle été tentée, bloquée ou établie ?
• Processus : conservez l’actif, l’identifiant stable, l’exécutable, le parent, le compte et l’heure. Quel programme est à l’origine de l’activité ?

Sous Windows, Sysmon propose les événements 22 pour les requêtes DNS, 3 pour les connexions réseau et 1 pour les créations de processus. ProcessGuid aide à corréler malgré la réutilisation des PID. L’événement 3 est désactivé par défaut : confirmez sa collecte avant d’interpréter une absence. Ces caractéristiques figurent dans la documentation Microsoft de Sysmon.

Ces journaux n’ont pas à provenir du même outil. En revanche, il faut comprendre leurs identifiants. Une connexion vue depuis un proxy et une requête DNS vue depuis un résolveur ne se rejoignent pas simplement parce qu’elles se produisent dans la même minute.

Vérifier chaque lien, plutôt que déduire une chaîne

Exemple fictif. Les flèches représentent des liens à vérifier pendant l’enquête, pas la preuve automatique d’un téléchargement ou d’une exécution.

Sur un poste nommé POSTE-17, les événements normalisés suivants apparaissent. Le domaine et l’adresse sont réservés à l’illustration ; A7 abrège ici un identifiant de processus fictif.

10:14:01Z  processus  POSTE-17  identifiant=A7  parent=à examiner
10:14:03Z  DNS        POSTE-17  updates.example → 192.0.2.44
10:14:04Z  réseau     POSTE-17  processus=A7  destination=192.0.2.44:443

Le processus existe avant les observations réseau. L’analyste remonte depuis l’alerte vers ce processus ; l’ordre des recherches ne doit pas être confondu avec l’ordre des événements.

Commencez par la réponse DNS observée au moment de l’activité. Une résolution effectuée maintenant peut renvoyer une autre adresse. Puis comparez l’identité du poste, l’heure et l’adresse de destination. S’il manque l’identifiant du processus dans la télémétrie DNS, marquez ce lien comme probable ou non établi, selon les autres preuves.

La ligne réseau suivante indique une destination sur le port 443. Ce numéro ne prouve ni le protocole applicatif, ni le contenu échangé. Consultez le résultat de connexion et les informations du proxy ou de l’EDR disponibles. Une décision « autorisé » du pare-feu ne suffit pas à démontrer un téléchargement réussi.

Chercher une preuve d’exécution adaptée à l’hypothèse

L’événement de création confirme le lancement d’un processus. Pour déterminer si ce lancement est suspect, examinez son chemin, son parent, sa ligne de commande, le compte utilisé et l’origine du fichier quand elle est connue.

Si l’hypothèse est « ce site a livré un programme ensuite exécuté », il manque encore un lien : rapprochez le fichier créé ou téléchargé de l’image exécutée, avec son chemin et son empreinte lorsque la collecte le permet. La seule présence d’un navigateur dans les journaux ne démontre pas cette chaîne.

À l’inverse, un programme déjà installé peut émettre une connexion sans téléchargement préalable. Ajustez l’hypothèse aux traces observées. Ajouter mécaniquement une étape de téléchargement inventerait un événement absent du dossier.

L’enrichissement IOC dans le SOC apporte le contexte externe utile à ces vérifications. La preuve d’exécution, elle, vient de la télémétrie du système concerné.

Deux issues possibles avec le même indicateur

Exécution inattendue corroborée. Le processus provient d’un emplacement inhabituel, son parent n’explique pas son lancement et des traces complémentaires établissent une activité non autorisée. L’IOC renforce l’enquête. L’équipe applique alors son processus de réponse, en préservant les preuves et en évaluant le périmètre touché avant de choisir les mesures adaptées.

Robot de sécurité identifié. L’actif correspond à un service d’analyse de liens. Le compte, le processus et la tâche planifiée concordent avec un scan autorisé. La correspondance IOC peut être exacte, alors que l’hypothèse d’une compromission de poste est incorrecte. La clôture documente cette explication précise, sans déclarer le domaine sûr ni exclure globalement son indicateur.

Ces conclusions reposent sur les faits de l’exemple. L’absence d’un signal supplémentaire ne constitue pas, par défaut, une troisième conclusion « aucun problème ».

Décrire les trous de collecte avant de clôturer

Vérifiez la synchronisation des horloges, la période de rétention et les filtres actifs. Un décalage peut inverser l’ordre apparent des événements ; une source manquante peut faire disparaître une étape entière. Les recommandations conjointes sur la journalisation et la détection insistent sur une référence horaire fiable et cohérente pour relier les journaux.

Conservez une conclusion courte : actif concerné, période examinée, activité démontrée, éléments non observables et prochaine décision. Par exemple : « requête DNS confirmée ; connexion non vérifiable car cette collecte était inactive ; propriétaire du poste sollicité ». Ce résultat incomplet reste exploitable parce qu’il n’efface pas sa limite.

Conservez ces pièces dans le dossier d’incident ou l’outil d’enquête de votre équipe. L’historique des rapports permet de retrouver les indicateurs consultés. Pour vérifier le contexte externe du premier indicateur, ouvrez un rapport IP ou domaine, puis consignez son résultat daté avec les événements locaux qui motivent votre conclusion.