Sysmon: rendre Windows bavard

Oui, tu as bien lu : aujourd’hui on parle de Windows. Si tu bosses en Blue Team, tu n’as pas le luxe d’ignorer l’OS qui équipe l’écrasante majorité des postes de travail que tu es censé défendre. Et sur Windows, il y a un outil gratuit qui transforme un système quasi muet en une source de télémétrie digne de ce nom: Sysmon.

Dans cet article, on va voir pourquoi les journaux Windows natifs ne suffisent pas, comment installer et configurer Sysmon proprement, quels événements surveiller en priorité, et comment brancher tout ça sur Wazuh.

Pourquoi les journaux Windows natifs ne suffisent pas

Windows journalise des choses, c’est vrai. Le journal Sécurité contient par exemple l’événement 4688 (création de processus). Sauf que par défaut, il n’est même pas activé, il ne contient pas la ligne de commande complète (il faut une GPO pour ça), et il ne te donne ni le hash du binaire, ni la relation parent/enfant détaillée, ni la moindre info sur les connexions réseau du processus.

Concrètement : un attaquant lance powershell.exe -nop -w hidden -enc SQBFAFgA... depuis un document Word piégé. Avec les journaux natifs mal configurés, tu vois… rien. Ou au mieux « un processus a été créé », sans la ligne de commande. Autant lire dans le marc de café.

Sysmon (System Monitor), de la suite Sysinternals rachetée par Microsoft, comble exactement ce trou. C’est un service Windows accompagné d’un pilote en mode noyau qui, une fois installé, survit aux redémarrages et journalise en détail : créations de processus avec ligne de commande complète et hash du binaire, connexions réseau attribuées au processus émetteur, chargements de DLL, requêtes DNS, modifications du registre, créations de fichiers, injections de threads distants… Bref, tout ce dont on a besoin pour comprendre ce qui se passe réellement sur une machine.

Deux points importants à garder en tête : Sysmon journalise mais n’analyse pas et ne bloque rien. Ce n’est ni un antivirus ni un EDR. C’est une paire de lunettes, pas un bouclier. L’analyse, c’est ton boulot, ou celui de ton SIEM, on y revient plus bas 😉

Les événements Sysmon qui comptent vraiment

Sysmon génère une trentaine de types d’événements, chacun avec son Event ID. Tu n’as pas besoin de tous les connaître par cœur, mais voici ceux que tu croiseras dans 95 % des investigations :

Event ID	Nom	Intérêt
1	Process creation	La star. Ligne de commande complète, processus parent, hash, utilisateur. Détecte les LOLBins, PowerShell encodé, chaînes d’exécution suspectes (Word qui lance cmd.exe…).
3	Network connection	Quelle appli parle à quelle IP sur quel port. Indispensable pour repérer un beacon C2.
7	Image loaded	Chargement de DLL. Détecte le DLL hijacking et les DLL non signées dans des processus légitimes. Très verbeux, à filtrer sérieusement.
8	CreateRemoteThread	Injection de thread dans un autre processus. Classique de l’injection de code malveillant.
10	ProcessAccess	Un processus ouvre la mémoire d’un autre. Le pattern typique : quelque chose qui lit la mémoire de `lsass.exe` pour voler des credentials (coucou Mimikatz).
11	FileCreate	Création de fichiers dans des emplacements sensibles (dossiers de démarrage, tâches planifiées…).
12, 13, 14	Registry events	Créations et modifications de clés de registre. Persistance via les clés Run, détournement de services…
22	DNS query	Chaque résolution DNS avec le processus qui l’a demandée. Redoutable contre les domaines DGA et l’exfiltration DNS.
15	FileCreateStreamHash	Création de flux ADS, notamment le « mark of the web » ajouté aux fichiers téléchargés par les navigateurs.
25	ProcessTampering	Techniques de type process hollowing ou herpaderping. Si ça sonne, c’est rarement pour une bonne raison.

La liste complète est sur la page officielle Sysmon. Garde ce tableau sous le coude : c’est ta grille de lecture pour la suite.

Installation

Petite parenthèse historique. Si le nom Sysinternals te dit quelque chose, c’est normal : depuis 1996, ces outils créés par Mark Russinovich et Bryce Cogswell sont la boîte à outils officieuse de tous ceux qui veulent savoir ce que Windows fait vraiment, derrière les jolies fenêtres. Leur recette du succès n’a jamais changé : des exécutables minuscules, sans installation, sans dépendances, gratuits, qui exposent des entrailles du système que Microsoft lui-même ne montrait nulle part. Process Explorer, Autoruns, Procmon, PsExec… des outils si indispensables que Microsoft a fini par racheter la boutique en 2006 et Russinovich avec, devenu depuis CTO d’Azure. Vingt ans plus tard, la philosophie n’a pas bougé d’un octet : un ZIP, un exécutable, zéro friction. Sysmon est le digne héritier de cette lignée.

Télécharger Sysmon

Sysmon se télécharge depuis le site Sysinternals de Microsoft. Au moment où j’écris ces lignes, on est en version 15.2. Pas d’installeur MSI, pas d’assistant en douze étapes : une archive ZIP contenant trois exécutables (Sysmon.exe 32 bits, Sysmon64.exe et Sysmon64a.exe pour ARM64).

# Depuis un PowerShell en administrateur
# Télécharger et extraire Sysmon
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" -OutFile "$env:TEMP\Sysmon.zip"
Expand-Archive -Path "$env:TEMP\Sysmon.zip" -DestinationPath "C:\Tools\Sysmon" -Force

Ne l’installe PAS sans fichier de configuration!!!

Techniquement, sysmon64 -accepteula -i tout court fonctionne. Sysmon s’installe avec sa configuration par défaut, qui ne journalise presque rien d’utile (créations de processus, changements d’horodatage de fichiers, chargements de pilotes, et c’est à peu près tout). Installer Sysmon sans config, c’est comme acheter une caméra de surveillance et la laisser dans son carton.

À l’inverse, tout journaliser sans filtre noierait tes disques et ton SIEM sous des gigaoctets de bruit. Toute la valeur de Sysmon est dans son fichier de configuration XML, qui définit précisément quoi inclure et quoi exclure. Et bonne nouvelle : la communauté a déjà fait 90 % du travail. Deux références :

sysmon-config de SwiftOnSecurity : la config historique, abondamment commentée, pensée pour un excellent rapport signal/bruit. Parfaite pour débuter et comprendre la logique de filtrage.
sysmon-modular d’Olaf Hartong : une approche modulaire mappée sur MITRE ATT&CK, plus maintenue et plus complète. Mon choix pour un déploiement sérieux.

# Récupérer la config sysmon-modular (version pré-assemblée)
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/olafhartong/sysmon-modular/master/sysmonconfig.xml" -OutFile "C:\Tools\Sysmon\sysmonconfig.xml"

Installer le service

# Toujours depuis un PowerShell/cmd en administrateur
cd C:\Tools\Sysmon
.\Sysmon64.exe -accepteula -i sysmonconfig.xml

Décortiquons : -accepteula accepte la licence sans afficher la boîte de dialogue (indispensable pour un déploiement scripté), et -i installe le service et le pilote en appliquant le fichier de configuration passé en argument. Vérifie que tout tourne :

# Le service doit être RUNNING
sc query Sysmon64

# Afficher la configuration active
.\Sysmon64.exe -c

Et voilà. Sysmon journalise déjà. Le service redémarre tout seul avec la machine, la config est stockée dans le registre : tu n’as plus besoin des fichiers d’origine pour qu’il fonctionne.

Comprendre le fichier de configuration

Même si tu pars d’une config communautaire, et tu devrais, il faut comprendre ce que tu déploies. Un fichier de configuration Sysmon minimal ressemble à ça :

<Sysmon schemaversion="4.90">
  <!-- Algorithmes de hash calculés pour chaque binaire exécuté -->
  <HashAlgorithms>sha256,IMPHASH</HashAlgorithms>

  <EventFiltering>
    <!-- Event ID 1 : tout journaliser SAUF les exclusions listées -->
    <RuleGroup name="" groupRelation="or">
      <ProcessCreate onmatch="exclude">
        <Image condition="is">C:\Windows\System32\svchost.exe</Image>
      </ProcessCreate>
    </RuleGroup>

    <!-- Event ID 22 : ne journaliser QUE ce qui matche (ici : tout sauf rien) -->
    <RuleGroup name="" groupRelation="or">
      <DnsQuery onmatch="exclude">
        <QueryName condition="end with">.microsoft.com</QueryName>
      </DnsQuery>
    </RuleGroup>

    <!-- Event ID 3 : uniquement les connexions des processus sensibles -->
    <RuleGroup name="" groupRelation="or">
      <NetworkConnect onmatch="include">
        <Image condition="image">powershell.exe</Image>
        <Image condition="image">cmd.exe</Image>
        <Image condition="image">mshta.exe</Image>
      </NetworkConnect>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

Deux logiques de filtrage, et il faut les avoir bien en tête parce qu’elles sont contre-intuitives au premier abord :

onmatch="exclude" : tout est journalisé, sauf ce qui correspond aux règles. C’est l’approche « liste noire » adaptée aux événements à forte valeur comme les créations de processus.
onmatch="include" : rien n’est journalisé, sauf ce qui correspond aux règles. Approche « liste blanche » indispensable pour les événements très verbeux comme les chargements de DLL ou le registre.

Attention au piège classique : une section onmatch="exclude" vide journalise tout, tandis qu’une section onmatch="include" vide ne journalise rien. Un attribut mal choisi et tu passes de « je vois tout » à « je ne vois rien », pense à valider ta config avec Sysmon64.exe -c après chaque modification. La version du schéma se vérifie avec Sysmon64.exe -? config, et elle est indépendante de la version du binaire.

Consulter les journaux

Dans l’Observateur d’événements

Les événements Sysmon atterrissent dans un canal dédié de l’Observateur d’événements (eventvwr.msc) :

Journaux des applications et des services
  └── Microsoft
      └── Windows
          └── Sysmon
              └── Operational

Chaque événement contient des champs structurés : Image (le binaire), CommandLine, ParentImage, ParentCommandLine, Hashes, User, ProcessGuid… Ce dernier est précieux : c’est un identifiant unique qui permet de corréler tous les événements d’un même processus, là où le PID est recyclé par l’OS.

En PowerShell, parce qu’on n’est pas des animaux

Cliquer dans l’Observateur d’événements, ça va cinq minutes. Pour investiguer sérieusement, Get-WinEvent est ton ami :

# Les 20 derniers événements Sysmon
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 20

# Uniquement les créations de processus (Event ID 1)
Get-WinEvent -FilterHashtable @{
    LogName = "Microsoft-Windows-Sysmon/Operational"
    Id      = 1
} -MaxEvents 50 | Format-List TimeCreated, Message

# Chasse au PowerShell encodé (l'équivalent Windows du grep qui fait mal)
Get-WinEvent -FilterHashtable @{
    LogName = "Microsoft-Windows-Sysmon/Operational"
    Id      = 1
} | Where-Object { $_.Message -match "-enc|-EncodedCommand" } |
    Select-Object TimeCreated, @{n="CommandLine";e={($_.Message -split "`n" | Select-String "CommandLine").ToString()}}

# Toutes les requêtes DNS (Event ID 22) des dernières 24 h
Get-WinEvent -FilterHashtable @{
    LogName   = "Microsoft-Windows-Sysmon/Operational"
    Id        = 22
    StartTime = (Get-Date).AddDays(-1)
}

Dimensionner le journal

Par défaut, le canal Sysmon fait 64 Mo et écrase les événements les plus anciens. Sur une machine active, ça peut représenter quelques heures d’historique à peine, autant dire que le jour où tu investigues un incident détecté avec 48 h de retard, tu vas pleurer. Augmente la taille :

# Passer le journal Sysmon à 1 Go
wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:1073741824

Test grandeur nature : voir un pattern d’attaque dans les journaux

Rien de tel qu’un petit test inoffensif pour vérifier que la mécanique tourne. Simule le comportement typique d’un dropper: un processus qui télécharge quelque chose puis résout un domaine.

# Génère un Event ID 1 (process create), un Event ID 22 (DNS query)
# et un Event ID 3 (network connect) d'un coup
powershell.exe -Command "Invoke-WebRequest -Uri 'https://example.com' -UseBasicParsing"

Retourne dans le journal : tu dois voir la création du processus PowerShell avec sa ligne de commande complète, la requête DNS vers example.com attribuée à ce processus, et la connexion réseau sortante en 443. Trois événements, un fil d’Ariane complet. C’est exactement ce fil que tu remonteras le jour où ce ne sera pas un test.

Mettre à jour, mettre à jour la config, désinstaller

# Recharger une nouvelle configuration (sans réinstaller)
.\Sysmon64.exe -c nouvelle-config.xml

# Afficher la configuration en cours
.\Sysmon64.exe -c

# Mettre à jour le binaire : désinstaller puis réinstaller
.\Sysmon64.exe -u
.\Sysmon64_nouveau.exe -accepteula -i sysmonconfig.xml

Point de vigilance : toute modification de configuration génère un Event ID 16 (config change) et l’arrêt/démarrage du service un Event ID 4. Surveille-les dans ton SIEM : un attaquant un peu réveillé qui obtient les droits admin commencera par neutraliser ou aveugler Sysmon. Le service tourne en processus protégé, mais rien n’empêche un admin de le désinstaller, la disparition soudaine des événements Sysmon d’une machine est en soi un signal d’alerte!

Petite note d’actualité au passage : Microsoft a annoncé fin 2025 l’intégration native des fonctionnalités Sysmon dans Windows 11 et Windows Server 2025, activable comme une fonctionnalité Windows et maintenue via Windows Update. De quoi simplifier le déploiement à grande échelle à terme, mais le fonctionnement, les Event IDs et les fichiers de configuration restent les mêmes.

En bonus: brancher Sysmon sur Wazuh

Des journaux détaillés sur chaque machine, c’est bien. Des journaux centralisés, corrélés et alertés, c’est un SOC. Si tu as suivi l’article sur le déploiement de Wazuh, la suite est d’une simplicité désarmante : l’agent Wazuh Windows sait lire les canaux d’événements modernes. Ajoute ce bloc dans le ossec.conf de l’agent (C:\Program Files (x86)\ossec-agent\ossec.conf) :

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Redémarre le service agent :

Restart-Service -Name wazuh

Wazuh embarque déjà des règles de décodage et de détection pour Sysmon (groupe de règles sysmon). Refais le test Invoke-WebRequest ci-dessus et regarde les événements remonter dans le dashboard. À partir de là, tout l’arsenal Wazuh s’applique : niveaux d’alerte, corrélation, mapping MITRE ATT&CK, notifications.

Les pièges à éviter

Déployer sans config: on l’a dit, mais ça mérite d’être répété. La config par défaut, c’est de la figuration.
Prendre une config communautaire sans jamais la tuner: SwiftOnSecurity et sysmon-modular sont d’excellents points de départ, pas des vérités révélées. Ton parc a ses propres logiciels métier bavards : observe une semaine, identifie le bruit, ajoute tes exclusions.
Activer l’Event ID 7 (Image loaded) sans filtrage strict: c’est le plus verbeux de tous. Sans liste blanche sérieuse, tu génères des millions d’événements par jour et par machine.
Oublier la gestion de version de la config: ton fichier XML est du code : mets-le dans un dépôt Git, trace les modifications. Le jour où une exclusion trop large masque une attaque, tu voudras savoir qui l’a ajoutée et quand.
Laisser la taille de journal par défaut: 64 Mo, c’est une session de navigation sur un poste moderne. 1 Go minimum si tu ne centralises pas immédiatement.

Conclusion

Sysmon, c’est le rapport qualité/prix imbattable de la visibilité Windows : un binaire de 2 Mo, un fichier XML, et tu passes d’un système opaque à une télémétrie de niveau EDR, la détection et la réponse en moins, certes, mais la matière première est là. Installé avec une config sérieuse et branché sur Wazuh, chaque poste Windows devient un capteur de ton SOC.

Et justement : maintenant que les événements Sysmon remontent dans Wazuh, il serait dommage de se contenter des règles par défaut. Dans le prochain article, on écrira nos propres règles Wazuh personnalisées pour détecter les patterns d’attaque qui nous intéressent vraiment: PowerShell encodé, accès à la mémoire de LSASS, persistance par clé Run. Reste dans le coin.