Déployer et ajuster Sysmon à grande échelle

Le socle stratégie d'audit et Sysmon explique ce que Sysmon enregistre et pourquoi vous en avez besoin. L'installer sur une machine prend une minute. Le faire tourner sur des milliers de machines, avec une configuration qui détecte les attaques sans ensevelir votre SIEM, est un tout autre travail. C'est l'objet de ce guide : choisir une configuration, l'ajuster à partir de données, la déployer et la mettre à jour à grande échelle, et s'assurer de remarquer quand elle cesse de fonctionner.

Avant de commencer : version autonome ou intégrée

Sysmon est désormais aussi intégré à Windows 11 et Windows Server 2025 en tant que fonctionnalité facultative, désactivée par défaut. Sur Windows 11 24H2 et 25H2, elle est arrivée avec la mise à jour d'évaluation du 24 février 2026 (KB5077241) et les mises à jour cumulatives suivantes. Vous l'activez avec Enable-WindowsOptionalFeature -Online -FeatureName Sysmon (ou Dism /Online /Enable-Feature /FeatureName:Sysmon), puis vous exécutez sysmon -i avec votre configuration. Elle utilise le même format de configuration XML et journalise dans le même canal Sysmon Operational, et ses binaires sont maintenus par Windows Update. Trois points pratiques :

• Sysmon autonome et la fonctionnalité intégrée ne peuvent pas coexister sur un même hôte. Désinstallez la version Sysinternals avant d'activer la version intégrée.
• La version intégrée localise le message rendu de l'événement. Analysez les champs XML de l'événement, pas le texte du message, sinon votre chaîne de traitement cassera sur les systèmes non anglophones.
• Tout ce qui suit sur la configuration, l'ajustement et la surveillance s'applique aux deux.

Étape 1 : choisir une stratégie de configuration

La plupart des équipes forkent sysmon-modular ou SwiftOnSecurity dans leur propre dépôt, gardent l'amont comme remote et appliquent leurs modifications locales sous forme de fine couche par-dessus. Si Defender for Endpoint est déployé, la variante de sysmon-modular conçue pour compléter MDE évite de collecter ce que MDE enregistre déjà bien. Voir mode blocage EDR et mode passif pour la place de MDE aux côtés d'autres outils.

Conservez une configuration de base unique et ajoutez des surcouches par rôle : postes de travail, serveurs membres, contrôleurs de domaine et serveurs exposés à Internet ont des comportements normaux différents. Un contrôleur de domaine ne devrait jamais lancer un navigateur ; un portable de développeur lance des compilateurs toute la journée.

Exemples de ce que modifient généralement les surcouches :

• Postes de travail : garder larges les événements de création de processus, réseau et DNS ; exclure précisément le bruit des navigateurs et des applications collaboratives.
• Contrôleurs de domaine : inclure en détail les accès aux processus visant lsass.exe, garder les événements réseau des processus inhabituels, et exclure le trafic LDAP et de réplication, lourd mais attendu, des processus système.
• Serveurs web et applicatifs : journaliser chaque processus enfant du service web ou de base de données, car ils ne lancent presque jamais de shell légitimement.
• Serveurs de rebond et PAW : plus verbeux que partout ailleurs, car leur activité est par définition de l'activité d'administration, qui mérite d'être examinée.

Vérifiez que le schemaversion du fichier correspond à ce que votre binaire prend en charge :

Sysmon64.exe -s | Select-Object -First 5   # affiche le schéma pris en charge par ce binaire

Étape 2 : comprendre le moteur de règles avant d'ajuster

Les erreurs d'ajustement viennent généralement d'une mauvaise lecture de la façon dont Sysmon évalue les règles :

• Chaque type d'événement a un filtre onmatch="include" ou onmatch="exclude". Un type d'événement avec un filtre include vide ne journalise rien ; un type avec un filtre exclude vide journalise tout.
• Dans un RuleGroup, groupRelation="or" signifie qu'une seule condition suffit ; groupRelation="and" signifie que toutes doivent correspondre. Utilisez les groupes and pour rendre les exclusions précises.
• Nommez vos règles. L'attribut name apparaît comme RuleName dans l'événement : c'est ainsi que les analystes voient pourquoi quelque chose a été journalisé (par exemple un ID de technique).

Une exclusion précise ressemble à ceci :

<RuleGroup name="Exclude agent update checks" groupRelation="and">
  <NetworkConnect onmatch="exclude">
    <Image condition="is">C:\Program Files\Contoso Agent\agent.exe</Image>
    <DestinationPort condition="is">443</DestinationPort>
  </NetworkConnect>
</RuleGroup>

Et une inclusion ciblée pour le vol d'identifiants :

<RuleGroup name="" groupRelation="or">
  <ProcessAccess onmatch="include">
    <TargetImage name="technique_id=T1003.001,technique_name=LSASS Memory" condition="is">C:\Windows\system32\lsass.exe</TargetImage>
  </ProcessAccess>
</RuleGroup>

Associez cette règle LSASS à la protection LSA et Credential Guard : la configuration vous dit que quelqu'un a essayé, la protection fait échouer la tentative.

Étape 3 : mesurer, puis réduire le bruit

Menez un pilote sur 20 à 50 machines par rôle pendant une semaine, avec un journal Sysmon nettement agrandi par rapport à sa petite taille par défaut :

wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:1073741824   # 1 Go

Identifiez ensuite d'où vient le volume :

$ev = Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -MaxEvents 50000

# Volume par ID d'événement
$ev | Group-Object Id | Sort-Object Count -Descending | Select-Object Count, Name

# Principaux processus pour les connexions réseau (événement 3)
$ev | Where-Object Id -eq 3 | ForEach-Object {
  ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq 'Image' | ForEach-Object '#text'
} | Group-Object | Sort-Object Count -Descending | Select-Object -First 15 Count, Name

Faites de même dans votre SIEM sur l'ensemble du pilote. Les principaux coupables habituels sont les événements 3 (réseau), 7 (chargement d'image), 10 (accès à un processus), 11 (création de fichier), 12/13 (registre) et 22 (DNS), alimentés par les navigateurs, les agents de sécurité, les logiciels de sauvegarde et les outils de mise à jour.

Règles pour réduire le bruit sans risque :

1. Excluez par chemin complet, jamais par nom. Image end with chrome.exe exclut n'importe quel fichier qu'un attaquant nommerait chrome.exe. Image is C:\Program Files\Google\Chrome\Application\chrome.exe, non.
2. N'excluez jamais d'emplacements accessibles en écriture aux utilisateurs, comme C:\Users\, C:\ProgramData\ ou %TEMP%. C'est là que les attaquants déposent leurs outils.
3. Combinez les champs. Excluez un processus et un port de destination, ou une image source et une image cible pour les accès aux processus, pas seulement le processus.
4. Privilégiez les signatures pour les chargements d'images. L'événement 7 contient Signed et Signature ; exclure les DLL signées par Microsoft chargées par des processus signés par Microsoft supprime l'essentiel du volume.
5. Faites passer la valeur sécurité en premier. Avant de supprimer un type d'événement, notez quelle détection en dépend. Les événements Sysmon 1, 3, 10, 11, 13 et 22 alimentent la majorité du contenu de détection.
6. Surveillez la suppression de fichiers. FileDelete (événement 23) avec un répertoire d'archive copie chaque fichier supprimé et peut remplir les disques. FileDeleteDetected (événement 26) journalise sans archiver et suffit généralement.

Étape 4 : déployer et mettre à jour à grande échelle

Sysmon installe un pilote et un service, et se copie dans %windir%. Déployez-le avec l'outil en qui vous avez déjà confiance pour les logiciels : Configuration Manager, une application Win32 Intune ou une tâche planifiée lancée par GPO. La logique est la même : installer s'il est absent, mettre à niveau si le binaire a changé, recharger la configuration si le fichier a changé.

$pkg    = 'C:\ProgramData\CorpSysmon'
$binary = Join-Path $pkg 'Sysmon64.exe'
$config = Join-Path $pkg 'sysmonconfig.xml'
$marker = Join-Path $pkg 'applied.sha256'

if (-not (Get-Service -Name Sysmon64 -ErrorAction SilentlyContinue)) {
    & $binary -accepteula -i $config
} elseif ((Get-Item "$env:windir\Sysmon64.exe").VersionInfo.FileVersion -ne
          (Get-Item $binary).VersionInfo.FileVersion) {
    & "$env:windir\Sysmon64.exe" -u force
    & $binary -accepteula -i $config
}

$hash = (Get-FileHash $config).Hash
if (-not (Test-Path $marker) -or (Get-Content $marker) -ne $hash) {
    & $binary -c $config
    Set-Content -Path $marker -Value $hash
}

Les changements de configuration via -c s'appliquent sans redémarrage ni interruption. Les mises à niveau du binaire par désinstallation puis réinstallation laissent une courte fenêtre sans surveillance ; consultez les notes de version de chaque version pour connaître le chemin de mise à niveau pris en charge, et planifiez les mises à niveau plutôt que de les laisser survenir au hasard.

Processus de publication :

• Configuration dans le contrôle de source, relue comme des règles de pare-feu.
• Validez le XML sur une machine de test avec -c avant publication ; un fichier invalide est rejeté et l'ancienne configuration reste active, ce qui peut masquer le fait que votre modification n'a jamais été appliquée.
• Déployez par anneaux : pilote, puis 10 %, puis tout le monde, en surveillant le volume d'événements à chaque étape.
• Évitez de placer la configuration sur un partage lisible par tous les utilisateurs. Elle indique précisément aux attaquants ce que vous ne journalisez pas.

Le commutateur -d installe le pilote sous un autre nom et renommer l'exécutable change le nom du service. Cela ne cache Sysmon qu'aux scripts les plus paresseux ; ce n'est pas un contrôle, et cela complique vos propres vérifications de santé.

Ce qui casse

• Les coûts d'ingestion SIEM explosent si la première configuration est trop verbeuse. Toujours un pilote avant le déploiement sur le parc.
• Les problèmes de performance sont rares mais réels avec des inclusions larges sur les chargements d'images ou le registre sur des serveurs chargés comme Exchange, SQL ou les serveurs de fichiers.
• La coexistence : certains produits de sécurité surveillent les mêmes callbacks du noyau. Testez avec vos agents EDR et de sauvegarde.
• Les configurations obsolètes : les hôtes qui ont manqué une mise à jour continuent silencieusement d'appliquer d'anciennes règles, sauf si vous le vérifiez.

Étape 5 : surveiller Sysmon lui-même

Un Sysmon arrêté depuis deux semaines ressemble exactement à un hôte calme. Détectez :

• Les événements Sysmon 4 (changement d'état du service), 16 (changement de configuration) et 255 (erreur).
• Les arrêts de service dans le journal System, émis par le Service Control Manager.
• Les hôtes sans aucun événement Sysmon depuis quelques heures alors qu'ils envoient toujours d'autres journaux.
• La dérive de configuration : ajoutez le hachage de la configuration à votre inventaire et comparez-le sur l'ensemble du parc.

Vérifier

Sur un hôte de test, contrôlez la configuration en cours et déclenchez des événements connus :

Sysmon64.exe -c                                   # affiche la configuration active et son hachage
Resolve-DnsName example.com                       # événement 22 attendu
Test-NetConnection example.com -Port 443          # événement 3 attendu s'il n'est pas exclu

Confirmez que ces événements arrivent dans le SIEM avec le bon RuleName, acheminés par Windows Event Forwarding ou par votre agent. Faites ensuite passer le même test par votre contenu de détection, par exemple la règle PowerShell non managé de détecter le PowerShell malveillant. Pour les ID d'événements que Windows journalise sans Sysmon, consultez la référence des ID d'événements de sécurité ; pour aller plus loin sur Sysmon et la journalisation, voir la page thématique audit et journalisation.

Liste de contrôle

• Choix entre Sysmon autonome et intégré arrêté pour chaque build d'OS
• Configuration forkée d'un projet maintenu, dans le contrôle de source, avec surcouches par rôle
• Pilote mesuré par ID d'événement et par processus avant le déploiement sur le parc
• Exclusions fondées sur des chemins complets et des champs combinés ; aucun dossier accessible en écriture aux utilisateurs
• Journal Sysmon dimensionné pour servir de tampon local ; événements transférés
• Installation, mise à niveau et rechargement de configuration automatisés, déployés par anneaux
• Santé de Sysmon (4, 16, 255, arrêts de service, hôtes silencieux, hachage de configuration) surveillée
• Ajustement revu chaque trimestre au regard du contenu de détection