Logs de sécurité Windows effacés : enquêter sur l’événement 1102

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.

Une alerte indique que les logs de sécurité d’un poste Windows ont été effacés. Deux réactions peuvent fragiliser l’enquête : attribuer immédiatement l’action à la personne dont le compte apparaît, ou redémarrer et reconfigurer la collecte avant de préserver les éléments encore disponibles.

Microsoft documente l’événement 1102 comme le signal d’un effacement du journal d’audit de sécurité Windows. Il contient notamment le compte sujet, son domaine, son SID et un identifiant de session. L’éditeur recommande d’en rechercher la raison. Cela ne prouve pas, à lui seul, une intention malveillante ni la disparition de toutes les copies. Source : Microsoft, événement 1102

La méthode ci-dessous est une recommandation d’investigation indépendante du SIEM utilisé. Elle sépare l’effacement établi, l’activité qui peut lui être reliée et les limites de visibilité. Elle ne décrit aucun incident client ni aucune intégration Seculogik disponible.

1. Vérifier le signal avant de lui donner une portée

Conservez l’événement d’origine, avec l’hôte, le canal, le fournisseur, l’heure de création, l’heure de réception et la référence de collecte. Un numéro d’événement isolé dans une alerte normalisée ne suffit pas à identifier son origine et son périmètre.

Notre recommandation : comparer les champs affichés par l’outil avec le contenu source. L’exemple Microsoft place les informations du sujet dans une structure UserData. Vérifiez que la normalisation a conservé le compte, le SID et l’identifiant de session, plutôt que de considérer un champ vide comme une absence d’information dans l’événement original.

Décrivez le fait au bon niveau : les logs de sécurité de cet hôte ont été effacés. Ne transformez pas ce constat en « tous les logs de l’organisation ont disparu ». Vérifiez séparément les autres canaux, la collecte centrale et les sources indépendantes.

Ouvrez aussi une vérification auprès du responsable technique : une opération approuvée peut-elle expliquer l’action ? Demandez sa référence, son périmètre et son auteur déclaré. Une justification orale ou un compte d’administration habituel ne remplace pas la comparaison avec les observations.

2. Préserver les copies avant de tenter une reconstruction

Microsoft décrit Windows Event Forwarding comme un mécanisme de transfert d’événements sélectionnés vers un collecteur. Il reste passif : il ne crée pas les événements absents et ne configure pas lui-même la politique d’audit du poste. Un abonnement existant n’est donc pas une garantie d’historique complet. Source : Microsoft, fonctionnement de Windows Event Forwarding

Nous recommandons d’inventorier ce qui existe réellement : copies déjà reçues par le collecteur, données interrogeables dans le SIEM, archives autorisées et télémétrie de protection du poste lorsqu’elle est disponible. Notez pour chaque source la période couverte, les filtres connus et le délai de réception. Ne présumez pas qu’un effacement local a supprimé ces copies ; vérifiez-les.

Préservez les éléments utiles dans un emplacement autorisé, avec leur origine et les paramètres d’export. Travaillez sur des copies identifiées. Une empreinte peut contrôler la stabilité d’un export ; elle ne démontre ni son exhaustivité ni la fiabilité passée du poste source.

Évitez de lancer une collecte générale de données personnelles sans besoin défini. La priorité est de conserver les traces qui permettent d’expliquer l’action et son contexte, sans retarder un confinement urgent autorisé pour obtenir une collecte parfaite.

3. Relier le compte à une session, puis aux activités

L’événement 4624 documente la création d’une session sur l’ordinateur auquel l’accès a eu lieu. Microsoft décrit un identifiant de connexion utile pour rapprocher des événements. Notre recommandation : limiter cette recherche au même hôte et au contexte temporel pertinent, sans traiter cet identifiant comme une clé universelle à travers le parc. Source : Microsoft, événement 4624

Notre recommandation : partir du compte et de la session présents dans 1102, puis rechercher les connexions et activités disponibles autour de cette période. Distinguez identité technique enregistrée et personne qui contrôlait réellement l’accès. Un compte partagé, une automatisation ou une session compromise demandent des éléments supplémentaires pour attribuer l’action.

Si l’audit et la collecte le permettent, 4688 apporte du contexte sur les créations de processus. Sa documentation distingue le créateur, le contexte cible et le processus parent ; la ligne de commande dépend d’une configuration supplémentaire et peut être vide. Source : Microsoft, événement 4688

Confrontez ces éléments aux traces d’administration distante et aux opérations approuvées disponibles. Un programme observé à proximité constitue une piste, pas automatiquement la cause de l’effacement. À l’inverse, l’absence de 4688 ou d’arguments ne démontre pas qu’aucun processus n’a exécuté l’action.

4. Distinguer effacement, changement d’audit et panne de collecte

Microsoft associe l’événement 4719 à un changement de politique d’audit, avec les sous-catégories et les modifications concernées. Il décrit une autre action que l’effacement signalé par 1102. Leur proximité peut justifier une enquête commune, mais l’un ne remplace pas la preuve de l’autre. Source : Microsoft, événement 4719

Nous recommandons de construire une chronologie comportant trois pistes distinctes : actions sur les logs, changements de politique et fonctionnement de la collecte. Pour chacune, séparez ce qui est observé de ce qui reste supposé. Conservez les dates d’origine et de réception : une arrivée tardive ne doit pas devenir une action tardive.

Une période vide dans le SIEM peut aussi résulter d’un problème de transport, d’un filtre ou d’une conservation insuffisante. Recherchez les éléments qui distinguent ces hypothèses avant de compter des événements « supprimés ». Un volume attendu n’est pas un inventaire des preuves perdues.

Pour chaque intervalle, formulez la limite précisément : traces présentes dans une copie centrale, événements non collectés, ou période dont la couverture reste inconnue. N’annoncez pas la récupération d’un historique complet sur la seule base du retour de nouvelles données.

5. Répondre sans détruire le contexte restant

La décision de confinement dépend des indices associés et du rôle du système. Notre recommandation : faire autoriser une mesure ciblée, avec un responsable et une conséquence opérationnelle connue. Un effacement inexpliqué sur un système sensible mérite une prise en charge rapide ; une alerte seule ne justifie pas de désactiver indistinctement les comptes d’administration.

Ne reproduisez pas l’effacement en production pour vérifier la détection. Pour un exercice, utilisez un environnement isolé et autorisé. Sur le système examiné, privilégiez un signal bénin compatible avec la procédure locale pour contrôler la génération, la transmission et l’arrivée des événements, sans retirer les traces restantes.

Vérifiez aussi les réglages d’audit et la couverture réellement attendue après intervention. Voir de nouveaux événements arriver valide une partie de la chaîne ; cela ne démontre pas que toutes les catégories utiles sont produites, reçues et conservées.

Si des indices font suspecter une compromission, poursuivez l’enquête correspondante. Le rétablissement de la collecte ne rend pas automatiquement le poste fiable et ne résout pas, à lui seul, la question de l’accès qui a permis l’action.

6. Clore avec des conclusions que l’on peut vérifier

Exemple entièrement fictif : un 1102 correspond à une opération de maintenance confirmée, mais la revue montre que certaines copies centrales attendues sont absentes. L’action peut être expliquée sans que la couverture de collecte soit satisfaisante. Documentez ces deux conclusions séparément, avec un responsable pour l’écart de visibilité.

Nous recommandons de conserver cinq réponses dans le dossier final :

1. Quel hôte et quel canal ont subi un effacement établi ?
2. Quel compte et quelle session sont enregistrés, avec quelle limite d’attribution ?
3. Quelles activités connexes sont confirmées ou seulement envisagées ?
4. Quelles copies et périodes restent disponibles ou hors visibilité ?
5. Quelle mesure a été prise et quel contrôle en confirme le résultat ?

Une explication légitime doit être étayée ; une hypothèse malveillante doit rester une hypothèse tant que les éléments ne permettent pas davantage. La qualité du dossier tient autant à ses preuves qu’à la précision de ses réserves.

Nos ressources gratuites d’investigation peuvent aider à organiser les observations, les décisions et les actions restantes. L’objectif est de permettre à un autre intervenant de retrouver le cheminement de l’enquête sans confondre retour de visibilité, attribution et résolution de l’incident.