Les journaux Windows de base répondent à une question simple : « que s’est-il passé ? ». Ils répondent mal à la question qui compte lors d’une enquête : « quel programme a lancé quoi, avec quels arguments, et vers quelle adresse a-t-il communiqué ? ». C’est précisément le rôle de Sysmon, un outil gratuit de la suite Sysinternals de Microsoft.
Cet article explique ce qu’est Sysmon, pourquoi l’ajouter aux logs par défaut, quels Event ID il produit, quel est son impact sur un SIEM classique et sur les SIEM de nouvelle génération, et comment le déployer sans noyer vos équipes sous les événements.
Sysmon, c’est quoi ? #
Sysmon (System Monitor) est, selon la documentation Microsoft Learn, un service et un pilote Windows qui reste actif après les redémarrages et enregistre l’activité du système dans le journal d’événements Windows. Il a été conçu par Mark Russinovich et Thomas Garnier.
Points essentiels à retenir :
- Il journalise la création de processus avec la ligne de commande complète, celle du processus et celle de son parent.
- Il calcule les empreintes (hash) des fichiers exécutés : SHA1, MD5, SHA256 ou IMPHASH.
- Il ajoute un identifiant unique de processus (ProcessGuid), ce qui permet de relier des événements même quand Windows réutilise un numéro de processus.
- Il journalise les connexions réseau, le chargement de pilotes et de bibliothèques, les accès entre processus, les modifications du registre, les requêtes DNS, etc.
- Il démarre très tôt au démarrage, pour capter l’activité de codes malveillants sophistiqués.
- Il est filtrable par un fichier de configuration XML.
Deux limites, que Microsoft rappelle : Sysmon n’analyse pas les événements qu’il génère et ne cherche pas à se cacher. C’est un capteur de télémétrie, pas un antivirus ni un outil de détection.
Les événements sont écrits dans Applications and Services Logs / Microsoft / Windows / Sysmon / Operational, avec des horodatages en UTC. D’après cette même documentation, Sysmon fonctionne sur Windows 11 et supérieur et Windows Server 2019 et supérieur ; il existe aussi une version Sysmon pour Linux.
Pourquoi l’ajouter aux logs Windows de base ? #
Ce que les journaux natifs ne donnent pas (ou mal) #
Windows produit déjà beaucoup d’événements de sécurité : ouvertures de session (4624, 4625), création de processus (4688), installation d’un service (7045), effacement du journal (1102), journalisation de scripts PowerShell (4104). Mais :
- L’événement 4688 (création de processus) ne contient pas la ligne de commande par défaut : il faut activer un paramètre de stratégie de groupe dédié. Même activé, il n’apporte ni empreinte de fichier, ni ligne de commande du parent, comme le résume NXLog.
- Il n’existe pas d’événement natif équivalent, aussi simple à exploiter, pour la connexion réseau par processus, la requête DNS par processus ou l'injection dans un processus.
- Les identifiants de processus sont réutilisables : difficile de suivre une chaîne d’exécution sur plusieurs heures.
Ce que Sysmon apporte #
| Besoin d’enquête | Logs Windows de base | Avec Sysmon |
|---|---|---|
| Qui a lancé ce programme, avec quels arguments ? | 4688, ligne de commande seulement si activée | Événement 1 : ligne de commande, parent, utilisateur, hash |
| Ce fichier est-il connu ? | Non | Hash SHA256, IMPHASH, signature |
| Vers quelle adresse ce processus a-t-il communiqué ? | Pare-feu ou proxy, sans le processus | Événement 3 : processus, adresses IP, ports |
| Quel domaine a-t-il résolu ? | Journal DNS serveur, sans le processus | Événement 22 : requête DNS par processus |
| Quelqu’un lit-il la mémoire de lsass.exe ? | Non | Événement 10 : accès à un processus |
| Un programme s’injecte-t-il dans un autre ? | Non | Événements 8 et 25 |
| Une persistance WMI a-t-elle été créée ? | Difficile | Événements 19, 20 et 21 |
| Qu’a-t-on déposé sur le disque ? | Audit de fichiers coûteux | Événements 11, 15 et 29 |
En résumé : Sysmon transforme des journaux qui disent qui s’est connecté en journaux qui décrivent ce que la machine a fait. C’est la matière première du threat hunting, de la détection et de l’investigation. Notre référentiel des Event IDs Windows présente les événements natifs ; Sysmon les complète.
Les Event ID de Sysmon #
La liste suivante suit la documentation Microsoft (à la date de sa dernière mise à jour, le 10 septembre 2026).
Processus et fichiers #
| ID | Nom | Ce qu’il enregistre | Intérêt |
|---|---|---|---|
| 1 | Process Create | Création de processus, ligne de commande, parent, hash | Le plus utile de tous |
| 2 | File creation time changed | Modification de la date de création d’un fichier | Détecte le « timestomping » (attention aux faux positifs) |
| 5 | Process terminated | Fin d’un processus | Durée de vie d’un processus |
| 11 | FileCreate | Création ou écrasement de fichier | Dossiers de démarrage, téléchargements, répertoires temporaires |
| 15 | FileCreateStreamHash | Flux de fichier nommé (marque du Web, Zone.Identifier) | Repère les fichiers téléchargés |
| 23 | FileDelete | Suppression, avec archivage du fichier | Récupération de preuves (espace disque à surveiller) |
| 26 | FileDeleteDetected | Suppression journalisée, sans archivage | Trace légère |
| 27 | FileBlockExecutable | Blocage de la création d’exécutables PE | Action de blocage |
| 28 | FileBlockShredding | Blocage de l’effacement sécurisé (ex. SDelete) | Action de blocage |
| 29 | FileExecutableDetected | Création d’un nouvel exécutable PE | Détection de dépôts |
Réseau, DNS et communication entre processus #
| ID | Nom | Ce qu’il enregistre |
|---|---|---|
| 3 | Network connection | Connexions TCP/UDP par processus (désactivé par défaut) |
| 22 | DNS query | Requête DNS, avec le processus à l’origine |
| 17 | Pipe Created | Création d’un canal nommé |
| 18 | Pipe Connected | Connexion à un canal nommé |
Mémoire, pilotes et modules #
| ID | Nom | Ce qu’il enregistre |
|---|---|---|
| 6 | Driver loaded | Chargement d’un pilote, avec signature et hash |
| 7 | Image loaded | Chargement d’un module dans un processus (désactivé par défaut, très volumineux) |
| 8 | CreateRemoteThread | Un processus crée un thread dans un autre (injection possible) |
| 9 | RawAccessRead | Lecture brute d’un disque |
| 10 | ProcessAccess | Un processus en ouvre un autre (par exemple lsass.exe) |
| 25 | ProcessTampering | Détournement d’image de processus (« hollowing », « herpaderping ») |
Registre, WMI et divers #
| ID | Nom | Ce qu’il enregistre |
|---|---|---|
| 12 | Registry object create/delete | Création ou suppression de clés |
| 13 | Registry value set | Modification de valeurs |
| 14 | Registry rename | Renommage de clés ou de valeurs |
| 19 | WmiEventFilter | Enregistrement d’un filtre WMI |
| 20 | WmiEventConsumer | Enregistrement d’un consommateur WMI |
| 21 | WmiEventConsumerToFilter | Liaison entre consommateur et filtre |
| 24 | Clipboard change | Changement du contenu du presse-papiers |
Événements de Sysmon lui-même #
| ID | Nom | Ce qu’il enregistre |
|---|---|---|
| 4 | Service state changed | Démarrage ou arrêt du service Sysmon |
| 16 | Configuration change | Modification de la configuration |
| 255 | Error | Erreur interne (charge, bogue, conditions d’intégrité) |
Les événements 4 et 16 ne se filtrent pas. Il faut les surveiller de près : l’arrêt ou la modification de Sysmon est un signal d’alerte.
Les cinq événements à activer en priorité #
Selon les guides de configuration, les identifiants 1 (processus), 3 (réseau), 10 (accès aux processus), 11 (fichiers) et 22 (DNS) couvrent la majorité des besoins de détection, à condition d’être filtrés avec soin.
Quelques correspondances avec MITRE ATT&CK #
Les règles de détection se rattachent souvent au référentiel MITRE ATT&CK :
| Comportement à détecter | Événement Sysmon | Technique ATT&CK |
|---|---|---|
| Accès à la mémoire de lsass.exe pour voler des identifiants | 10 | T1003 (OS Credential Dumping) |
| Injection dans un autre processus | 8, 25 | T1055 (Process Injection) |
| Persistance par clé de registre de démarrage | 12, 13 | T1547.001 |
| Persistance par abonnement WMI | 19, 20, 21 | T1546.003 |
| Modification des dates d’un fichier | 2 | T1070.006 (Timestomp) |
| Communication vers un domaine suspect | 22, 3 | T1071 |
Installer et configurer Sysmon #
D’après Microsoft, l’installation se fait en ligne de commande, sans redémarrage :
- Installation avec un fichier de configuration :
sysmon64 -accepteula -i config.xml - Mise à jour de la configuration :
sysmon64 -c config.xml - Affichage de la configuration actuelle :
sysmon64 -c
Un exemple minimal de fichier de configuration, tiré de la documentation, montre le principe du filtrage à la source : on inclut ou on exclut des événements selon des champs.
<Sysmon schemaversion="4.82">
<HashAlgorithms>*</HashAlgorithms>
<EventFiltering>
<NetworkConnect onmatch="include">
<DestinationPort>443</DestinationPort>
<DestinationPort>80</DestinationPort>
</NetworkConnect>
<NetworkConnect onmatch="exclude">
<Image condition="end with">iexplore.exe</Image>
</NetworkConnect>
</EventFiltering>
</Sysmon>
Règles à connaître : les règles qui portent sur le même champ s’additionnent (OU), celles de champs différents se combinent (ET), et l’exclusion l’emporte sur l’inclusion.
Ne partez pas d’une page blanche. Deux configurations communautaires sont largement utilisées comme base :
- sysmon-config de SwiftOnSecurity : un fichier unique, très commenté.
- sysmon-modular d’Olaf Hartong : une approche modulaire, dont les règles sont annotées avec les techniques ATT&CK.
Adaptez toujours ces bases à votre environnement et testez-les sur un groupe pilote avant de généraliser.
L’impact sur un SIEM classique #
Les bénéfices #
- Des détections plus précises : une règle peut cibler une ligne de commande ou un enchaînement parent-enfant précis, au lieu de se contenter d’un événement générique.
- Corrélation fiable grâce au ProcessGuid : on suit une chaîne d’exécution complète.
- Enquêtes plus rapides : hash, parent, réseau et DNS sont dans le même journal.
- Détections partageables : des règles au format Sigma existent pour de nombreux événements Sysmon, ce qui évite de tout réécrire.
Les coûts et les risques #
- Volume : un Sysmon mal réglé peut faire exploser le nombre d’événements ingérés, et donc la facture ou la charge de votre SIEM. Le filtrage se fait d’abord dans la configuration Sysmon, puis dans l’agent de collecte pour les cas spécifiques.
- Bruit : les événements 7 (chargement de modules) et 10 (accès aux processus) sont très verbeux. Microsoft recommande de les filtrer pour ne conserver que les accès inattendus.
- Normalisation : le SIEM doit savoir analyser les champs Sysmon (parseurs, modèles de données).
- Maintenance : la configuration évolue avec l’environnement ; il faut la versionner et la déployer de manière centralisée.
- Espace disque : l’archivage des fichiers supprimés (événement 23) peut consommer beaucoup de stockage.
Une méthode pour maîtriser le volume #
- Déployez sur un petit groupe de postes et de serveurs représentatifs.
- Mesurez le volume par Event ID après quelques semaines.
- Ajoutez des exclusions ciblées pour les événements les plus bruyants et les moins utiles.
- Conservez au niveau du SIEM uniquement ce qui alimente une détection, une enquête ou une obligation de conservation.
- Réévaluez régulièrement : les logiciels installés changent, le bruit aussi.
Sysmon et les SIEM de nouvelle génération #
L’expression « SIEM nouvelle génération » (next-gen SIEM) est en partie commerciale. Elle désigne généralement des plateformes cloud, dotées d’un stockage de type data lake, de capacités d’analyse comportementale, de corrélation avancée et d’automatisation des réponses. Voici ce que Sysmon change pour elles, sans promettre plus que ce que les technologies apportent.
| Caractéristique d’une plateforme moderne | Rôle de la télémétrie Sysmon |
|---|---|
| Analyse comportementale (UEBA, apprentissage automatique) | Des données détaillées (parent, ligne de commande, réseau) améliorent la qualité des modèles |
| Stockage à moindre coût (données chaudes et froides) | On peut conserver longtemps les événements de faible valeur sans payer le tarif d’une recherche immédiate |
| Détection en tant que code (Sigma, ATT&CK) | Les règles se versionnent, se testent et se partagent |
| Automatisation (SOAR) | Un événement riche permet de déclencher des actions précises : isoler un poste, bloquer un hash |
| Chasse aux menaces | Les requêtes croisent processus, réseau et DNS sur de gros volumes |
| Intégration XDR | Sysmon complète la télémétrie d’un EDR, surtout sur les systèmes qui n’en ont pas |
Sysmon face à un EDR ou un XDR #
Un EDR collecte déjà de la télémétrie et fournit des capacités de détection et de réponse (voir notre article sur les différences entre EDR, antivirus et XDR). Sysmon n’est pas un concurrent : il n’analyse pas et ne bloque presque rien. Il garde pourtant un intérêt :
- Sur les machines sans EDR : anciens serveurs, environnements de test, postes hors périmètre.
- Pour la transparence : la configuration et les données sont les vôtres, lisibles et indépendantes d’un éditeur.
- Pour l’investigation : une télémétrie stable sur le poste, exploitable même en dehors de la console de l’éditeur.
- Pour un budget limité : Sysmon est gratuit, même si son exploitation a un coût en temps.
Il ne remplace donc ni un EDR ni une équipe de détection : il alimente leurs enquêtes. Pour comprendre qui fait quoi dans un dispositif de sécurité, lisez aussi notre article sur les différences entre CERT, CSIRT, SOC et SecOps.
Les limites et les précautions #
- Il faut des règles de détection : sans elles, ce n’est qu’un journal de plus.
- Un administrateur local peut le désactiver si rien ne le protège. Surveillez les événements 4 et 16, l’état du service et la version du fichier de configuration.
- Rien ne remplace une bonne hygiène : correctifs, droits limités, authentification forte.
- Respectez le RGPD et le droit du travail : Sysmon enregistre des lignes de commande et des noms de domaine qui peuvent contenir des données personnelles. Définissez la finalité, informez les salariés et limitez la durée de conservation.
- Testez avant de déployer : des règles trop larges peuvent dégrader les performances ou saturer le stockage.
Par où commencer ? #
- Cartographiez vos besoins : quels systèmes, quelles menaces, quelle durée de conservation ?
- Choisissez une configuration de base (SwiftOnSecurity ou Olaf Hartong) et adaptez-la.
- Testez sur un groupe pilote et mesurez le volume par événement.
- Déployez de manière centralisée (stratégie de groupe, outil de gestion de postes).
- Transmettez les journaux vers le SIEM et vérifiez l’analyse des champs.
- Écrivez ou importez des règles de détection liées à ATT&CK, puis testez-les.
- Surveillez Sysmon lui-même : arrêts, changements de configuration, erreurs (événement 255).
- Documentez la configuration et révisez-la régulièrement.
Si vous menez une investigation sur un poste Windows, notre comparatif des logiciels de forensique Windows vous aidera à choisir les outils qui exploiteront ces journaux.
Points clés #
- Sysmon est un outil gratuit de Sysinternals qui enregistre dans le journal Windows la création de processus (avec ligne de commande et hash), les connexions réseau, les requêtes DNS, les accès mémoire, le registre, les fichiers et WMI.
- Il comble ce que les logs Windows de base ne fournissent pas : l’événement 4688 n’a pas la ligne de commande par défaut ni le hash.
- Les Event ID les plus utiles : 1, 3, 10, 11 et 22, complétés par 8, 12, 13, 19 à 21 et 25.
- Son impact sur un SIEM est double : des détections plus fines, mais un volume à maîtriser par le filtrage.
- Sur un SIEM nouvelle génération, il fournit une télémétrie riche pour l’analyse comportementale, la détection en tant que code et l’automatisation.
- Sysmon n’analyse pas et ne se cache pas : il ne remplace ni un EDR ni des règles de détection, et il faut surveiller son propre état.