Journaux DNS : relier une requête au contexte du poste
Analysez les requêtes DNS avec leur contexte : processus, poste, résultat et activité réseau, sans confondre anomalie et compromission.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Un domaine inconnu dans un journal DNS attire facilement l’attention. Pourtant, la nouveauté d’un nom ne dit pas pourquoi il a été demandé.
Un navigateur, une mise à jour, une application métier et un processus inattendu peuvent produire des traces qui se ressemblent dans une vue trop simplifiée.
Le fait confirmé
Microsoft documente l’événement DNS 22 de Sysmon : il concerne les requêtes DNS effectuées par un processus, avec des résultats qui peuvent réussir ou échouer et provenir ou non du cache. Source : documentation officielle Sysmon.
La méthode proposée par Seculogik
Définissez d’abord la question à laquelle chaque source permet de répondre. Un journal de résolveur peut montrer une demande reçue par ce résolveur. Une source endpoint peut apporter un contexte de processus.
Une trace réseau peut aider à examiner les communications qui suivent.
Ne supposez pas que ces vues couvrent exactement le même périmètre. Les chemins de résolution, les configurations applicatives et les équipements intermédiaires peuvent modifier ce que chaque point d’observation voit.
Pour un événement suspect, rassemblez le poste, le processus quand il est disponible, le nom demandé, la réponse, l’heure et les activités voisines. Vérifiez ensuite si la requête correspond à un logiciel attendu ou à un changement récent.
Construire une hypothèse proportionnée
Nous recommandons de traiter les caractéristiques inhabituelles comme des pistes : répétition, échecs fréquents, noms rarement observés ou apparition sur une machine sensible. La valeur vient de leur combinaison avec le contexte de l’actif et du processus.
Une requête DNS n’établit pas à elle seule qu’une session réseau a abouti. Une réponse positive n’établit pas non plus qu’un contenu a été téléchargé. Pour conclure, recherchez les éléments complémentaires disponibles et notez ceux qui manquent.
Évitez les exclusions générales fondées uniquement sur une marque connue ou un grand fournisseur d’hébergement. Un service partagé peut héberger des usages différents ; une exception doit conserver un périmètre et une justification.
Tester la visibilité
Sur un poste autorisé, effectuez quelques résolutions bénignes connues. Vérifiez ce qui apparaît dans chaque source, puis observez la manière dont le contexte arrive dans le SIEM, qu’il s’agisse de Wazuh ou d’un autre outil.
Documentez les angles morts sans chercher à les masquer par un score. Le meilleur premier livrable est une carte simple des questions auxquelles vos journaux DNS répondent réellement.
Elle permet au SOC d’investiguer avec davantage de précision et moins de conclusions prématurées.
Sources
- Microsoft Sysinternals, Sysmon : https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon