Centraliser les journaux Sysmon des postes Windows

Centraliser les journaux Sysmon des postes Windows

Sysmon enrichit fortement la télémétrie native de Windows, mais il ne remplace ni une politique d’audit cohérente ni une plateforme de détection. Le compromis est net : gagner une visibilité exploitable sur les processus, connexions et modifications sensibles, au prix d’un volume d’événements, d’une configuration à maintenir et d’une surface de fuite de données à assumer.

Explication de la marmotte

Un parc informatique sans journal centralisé ressemble à un immeuble où chaque appartement garde ses propres carnets d’incidents dans un tiroir fermé. Regrouper ces traces permet de comprendre qu’un même problème se répète partout, avant que quelqu’un annonce qu’il s’agissait seulement d’une coïncidence cosmique.

→ Lire l’explication complète de la marmotte

Architecture Sysmon, collecte Windows et prérequis

Sysmon (System Monitor) est un pilote et un service Microsoft Sysinternals qui ajoutent des événements détaillés au journal Microsoft-Windows-Sysmon/Operational. Il observe notamment la création de processus, les connexions réseau, les requêtes DNS (Domain Name System), les chargements de modules et certaines écritures dans le registre Windows.

La recommandation est de séparer trois fonctions :

1. Sysmon produit les événements sur chaque poste.
2. WEF (Windows Event Forwarding) transmet les événements vers un ou plusieurs collecteurs Windows.
3. Un agent de collecte installé sur les collecteurs expédie les journaux vers le SIEM (Security Information and Event Management), ou vers une plateforme de stockage et de détection équivalente.

Faire envoyer chaque poste directement vers le SIEM paraît moderne sur une slide. En réalité, cela multiplie les identifiants, les règles réseau, les versions d’agents et les pannes silencieuses. WEF réduit ce plan de contrôle : les postes parlent à une infrastructure Windows déjà authentifiée, les collecteurs portent la sortie vers l’outil central.

Prévoir avant le déploiement :

• Des postes Windows pris en charge par la version de Sysmon retenue, avec architecture x64 ou ARM64 vérifiée.
• Un domaine Active Directory, avec résolution DNS fonctionnelle et synchronisation horaire. Kerberos refuse les fantaisies temporelles, même quand le reste de l’infrastructure les tolère avec une résignation administrative.
• Un ou plusieurs serveurs collecteurs, membres du domaine, dimensionnés et redondés selon la disponibilité recherchée.
• Une unité d’organisation dédiée aux postes concernés et des objets de stratégie de groupe séparés pour Sysmon, WinRM (Windows Remote Management) et WEF.
• Un stockage central dont la rétention découle des besoins de détection et d’investigation, pas du disque libre un mardi matin.
• Une autorité de certification si WEF doit traverser des segments non approuvés avec HTTPS (Hypertext Transfer Protocol Secure). En domaine interne, Kerberos sur HTTP via WinRM reste acceptable : les messages sont protégés au niveau du protocole WS-Management, mais le réseau doit rester maîtrisé.

Ne pas confondre journalisation et prévention. Sysmon enregistre un processus powershell.exe lancé avec une commande encodée, il ne l’empêche pas. Le blocage relève de Microsoft Defender, AppLocker, Windows Defender Application Control ou d’un autre contrôle préventif. La gestion des identités et le durcissement de l’authentification restent également hors de son périmètre.

Déployer Sysmon par stratégie de groupe

Distribuer le binaire Sysmon signé par Microsoft depuis un partage en lecture seule accessible aux comptes ordinateurs. Vérifier la signature Authenticode avant de le publier. Une chaîne de déploiement qui exécute un binaire téléchargé depuis un partage modifiable transforme la politique de groupe en distributeur de malwares avec logo institutionnel, ce qui est un service rarement demandé.

Utiliser une tâche planifiée de démarrage, exécutée sous SYSTEM, ou un paquet de déploiement géré. La tâche doit distinguer l’installation initiale de la mise à jour de configuration. Réinstaller Sysmon à chaque démarrage n’améliore rien et rend le diagnostic pénible.

Conserver le fichier XML (Extensible Markup Language) de configuration dans un dépôt versionné. Chaque version doit porter un identifiant, une date et un responsable technique. Sysmon accepte le rechargement de configuration sans redémarrage avec /c, ce qui permet de corriger un filtre trop large sans toucher au pilote.

La politique de base doit privilégier les événements à fort rendement :

• Événement 1 : création de processus, avec ligne de commande, parent, hachages et intégrité.
• Événement 3 : connexions réseau, filtrées pour éviter le bruit des services attendus.
• Événement 11 : création de fichier, concentrée sur les répertoires de démarrage, les dossiers temporaires et les emplacements de scripts.
• Événements 12, 13 et 14 : créations, valeurs et renommages de clés de registre.
• Événement 22 : requêtes DNS.
• Événement 23 : suppression de fichier avec archivage éventuel, à activer seulement après validation de la capacité de stockage et des contraintes de confidentialité.
• Événement 25 : altération de processus, utile contre certaines techniques d’injection.

Éviter d’activer sans filtre les événements 7 (chargement d’image) et 10 (accès à un processus). Ils sont précieux pour une enquête ciblée, mais leur coût opérationnel devient vite délirant sur un parc bureautique. Capturer tout n’est pas une stratégie de détection, c’est une manière onéreuse de reporter le tri à une équipe déjà occupée.

Configuration Sysmon recommandée et exemple reproductible

La configuration suivante constitue un socle volontairement restrictif. Elle ne prétend pas détecter chaque technique ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge), ce catalogue ne remplace pas une analyse de risque. Elle collecte des signaux dont les champs permettent une corrélation réaliste.

<!-- sysmon-base.xml : installer avec Sysmon64.exe /accepteula /i sysmon-base.xml -->
<Sysmon schemaversion="4.90">
  <HashAlgorithms>SHA256,IMPHASH</HashAlgorithms>
  <EventFiltering>

    <!-- Processus : conserver le parent et la ligne de commande -->
    <ProcessCreate onmatch="include" />

    <!-- Réseau : exclure seulement les boucles locales, jamais les flux internes entiers -->
    <NetworkConnect onmatch="exclude">
      <DestinationIp condition="is">127.0.0.1</DestinationIp>
      <DestinationIp condition="is">::1</DestinationIp>
    </NetworkConnect>

    <!-- DNS : source majeure pour domaines nouvellement employés ou typosquattés -->
    <DnsQuery onmatch="include" />

    <!-- Persistance : dossiers de démarrage et emplacements utilisateur -->
    <FileCreate onmatch="include">
      <TargetFilename condition="begin with">C:\Users\</TargetFilename>
      <TargetFilename condition="contains">\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\</TargetFilename>
    </FileCreate>

    <!-- Registre : surveiller les emplacements d'exécution automatique -->
    <RegistryEvent onmatch="include">
      <TargetObject condition="contains">\CurrentVersion\Run</TargetObject>
      <TargetObject condition="contains">\CurrentVersion\RunOnce</TargetObject>
    </RegistryEvent>

    <!-- Détecter les manipulations de processus connues -->
    <ProcessTampering onmatch="include" />
  </EventFiltering>
</Sysmon>

Le filtre FileCreate ci-dessus doit être adapté : des règles include combinées à plusieurs conditions peuvent produire plus d’événements que prévu selon la logique du schéma Sysmon. Tester chaque règle avec sysmon64.exe -s sysmon-base.xml, puis vérifier les événements générés sur un poste représentatif. La syntaxe XML valide ne garantit pas une sémantique de filtrage correcte. Cette confusion survit depuis longtemps, probablement parce que les accolades ont l’air rassurantes.

Ajouter des exclusions uniquement après avoir identifié le processus, le chemin, l’éditeur et la raison du bruit. Exclure C:\Windows\* ou tous les processus signés Microsoft supprime aussi une grande partie des abus réalistes de binaires légitimes.

Windows Event Forwarding et règles de détection initiales

Sur chaque collecteur, activer le service Windows Event Collector avec wecutil qc. Créer ensuite une souscription WEF initiée par la source : les postes découvrent le collecteur par stratégie de groupe et s’y connectent eux-mêmes. Cette topologie évite au collecteur d’ouvrir une session vers chaque poste, ce qui réduit les droits, les flux entrants et le nombre d’échecs dus aux pare-feu.

Configurer dans la stratégie de groupe le gestionnaire de souscription :

Server=http://wec01.exemple.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

Configurer également le service WinRM en démarrage automatique différé. Le compte NETWORK SERVICE, utilisé par le transfert d’événements, doit pouvoir lire le canal Sysmon. Ajouter ce compte au groupe local Event Log Readers par stratégie de groupe si les tests montrent un refus d’accès. Ne pas modifier directement les descripteurs de sécurité du journal sans nécessité : un SDDL (Security Descriptor Definition Language) mal formé transforme l’observabilité en exercice d’archéologie.

La souscription doit viser le canal suivant :

Path=Microsoft-Windows-Sysmon/Operational

Choisir le mode de livraison MinLatency pour les événements Sysmon destinés à l’alerte. Il augmente les connexions et la charge par rapport à Normal, mais une alerte sur une persistance créée trois heures plus tôt a souvent la valeur opérationnelle d’un parapluie dans une cave inondée. Réserver Normal aux événements volumineux ou moins urgents.

Commencer avec quatre détections corrélées :

1. powershell.exe, wscript.exe, cscript.exe, mshta.exe ou rundll32.exe lancé depuis un répertoire utilisateur, temporaire ou de téléchargement.
2. Modification des clés Run ou RunOnce, suivie d’une création de processus correspondant à la valeur écrite.
3. Processus parent Office (winword.exe, excel.exe, outlook.exe) lançant un interpréteur de scripts ou une commande système.
4. Requête DNS vers un domaine, suivie d’une connexion réseau du même processus vers une adresse externe inconnue de la politique réseau.

Une règle isolée est un signal, pas un verdict. La création de powershell.exe est banale ; winword.exe qui lance PowerShell avec une commande encodée, écrit une clé de démarrage puis contacte un domaine nouvellement observé mérite une investigation. La cartographie des menaces aide à relier ces chaînes à des scénarios, mais la détection doit rester fondée sur des comportements vérifiables.

Exploitation, rétention et limites de sécurité

Superviser trois états distincts : le service Sysmon actif, la fraîcheur du dernier événement reçu par poste, et la santé de la souscription WEF. Un poste peut avoir Sysmon installé tout en étant coupé du collecteur ; le tableau de conformité qui ne contrôle que l’installation est alors décoratif.

Déclencher une alerte quand un poste cesse d’émettre au-delà d’un délai adapté à son profil de connexion. Distinguer les portables hors réseau, les machines désactivées et les sources silencieuses sans raison. Conserver les journaux locaux assez longtemps pour absorber une indisponibilité temporaire du collecteur, avec une taille maximale explicitement configurée sur le canal Sysmon.

Protéger les collecteurs comme des actifs de sécurité : accès administrateur restreint, journaux Windows Security séparés, sauvegarde des configurations de souscription, export régulier des fichiers EVTX (Windows Event Log) et copie immuable des événements envoyés au stockage central. Un administrateur local compromis peut arrêter Sysmon, modifier sa configuration ou effacer des journaux locaux. Le mécanisme ne garantit donc ni l’intégrité face à un attaquant administrateur, ni l’exhaustivité après compromission.

L’intégrité forte exige une collecte rapide, des alertes sur l’arrêt du service et des traces exportées hors du poste. Pour les accès d’administration, compléter avec le durcissement de NTLM et une séparation des comptes. Sysmon voit beaucoup de choses ; il ne répare pas une identité privilégiée déjà volée.

🐝 Ce qui arrive si on s’en passe

Sans Sysmon ni collecte centralisée, la télémétrie native de Windows n’enregistre pas par défaut la ligne de commande des processus, ni leur hachage, ni le lien entre un processus et ses requêtes DNS. Une recherche d’indicateur (hachage d’un binaire, domaine contacté) ne peut donc pas être lancée sur tout le parc : il faut interroger chaque poste un par un. Cette collecte manuelle impose d’ouvrir des sessions d’administration sur des machines possiblement compromises, ce qui expose les identifiants privilégiés précisément là où l’attaquant se trouve. Le journal local tourne en écrasant les événements les plus anciens : si l’accès initial est plus ancien que la profondeur du canal, le point d’entrée n’est plus reconstituable, et le périmètre réel de l’incident reste une estimation.

🦫 Explication de la marmotte 🍫

Sysmon est un programme installé sur chaque ordinateur Windows. Il observe des actions précises : lancement d’un programme, connexion vers un autre ordinateur, recherche d’un nom de site, création d’un fichier ou modification d’un réglage qui peut relancer un programme automatiquement. Il écrit ces informations dans un journal local avec l’heure, le nom du programme, son parent et parfois sa ligne de commande.

Un service Windows envoie ensuite une copie de ces journaux vers un serveur collecteur. Les ordinateurs trouvent ce serveur grâce aux règles du domaine informatique et s’authentifient avec leurs comptes machine. Le collecteur regroupe les événements, puis un outil de sécurité les stocke et cherche des combinaisons suspectes.

La configuration décide ce qui est enregistré. Enregistrer trop peu masque des attaques. Enregistrer tout produit beaucoup de données, ralentit les recherches et peut conserver des informations personnelles. Il faut donc cibler les actions qui servent souvent à rester installé, exécuter des scripts ou contacter des destinations inconnues.

Si le programme d’observation est arrêté, si le poste ne peut plus joindre le collecteur ou si le journal local est plein, des événements peuvent manquer. Le système doit surveiller ces absences, conserver temporairement les journaux sur le poste et protéger le serveur collecteur. Même ainsi, un attaquant ayant les droits d’administration sur un poste peut essayer d’effacer des traces : la copie rapide vers un serveur séparé limite ce risque sans le supprimer entièrement.

À lire aussi

• Exécuter un threat hunting à partir d'une hypothèseGuide pas-à-pas pour préparer, exécuter et pérenniser un exercice de threat hunting fondé sur une hypothèse vérifiable.
• Comment exploiter le Global Risks Report du Forum économique mondialLe Forum économique mondial publie le Global Risks Report, un signal de gouvernance qui influence les priorités cyber sans constituer un référentiel technique.
• Configurer Windows Hello for Business sans mot de passeGuide pratique de déploiement de l’authentification sans mot de passe sur Active Directory avec Windows Hello for Business.
• Registre Windows, GPO et services, fonctionnement et attaquesComment le registre Windows, les GPO et les services s'articulent, où se logent la persistance et l'élévation de privilèges, et ce qu'il faut verrouiller en premier.

Pages voisines

La citent

• Installer WSL 2 sous Windows 10 et 11, configuration et sécurité
• Registre Windows, GPO et services, fonctionnement et attaques

Centraliser les journaux Sysmon des postes Windows

Elle cite

• Configurer une détection open source avec Wazuh
• Détecter la persistance d’un attaquant après incident
• IoC ou TTP pour détecter une compromission
• NTLM : protocole authentification LAN Manager New Technology Microsoft