Audit Windows et Sysmon : un socle de journalisation

Lorsqu'un incident survient sur un réseau Windows, les premières questions sont toujours les mêmes : quel compte s'est connecté où, qu'est-ce qui a été exécuté, qu'est-ce qui a changé, et vers où les connexions sont-elles parties ? Avec les paramètres par défaut, Windows ne répond qu'à peu d'entre elles. La création de processus n'est pas journalisée, les lignes de commande ne sont pas capturées, le journal Sécurité boucle en quelques heures sur un serveur chargé, et rien ne quitte l'hôte.

Ce guide construit un socle de journalisation en quatre couches : stratégie d'audit avancée, quelques paramètres complémentaires, Sysmon et transfert des événements.

Couche 1 : la stratégie d'audit avancée

Commencez par rendre la stratégie d'audit avancée prioritaire. Sous Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options, activez Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings (forcer les paramètres de sous-catégorie à remplacer ceux des catégories).

Configurez ensuite les sous-catégories sous Security Settings > Advanced Audit Policy Configuration > Audit Policies. Un bon point de départ, globalement aligné sur les recommandations de référence de Microsoft :

Vérifiez la stratégie effective sur un hôte :

auditpol /get /category:*
auditpol /get /subcategory:"Process Creation"

En laboratoire, vous pouvez définir directement des sous-catégories individuelles (en production, la GPO reste la source de vérité) :

auditpol /set /subcategory:"Process Creation" /success:enable

Couche 2 : les paramètres qui rendent les événements exploitables

Les lignes de commande peuvent contenir des secrets (mots de passe passés en paramètres). C'est une raison de restreindre qui lit les journaux et de corriger ces scripts, pas de laisser la journalisation des lignes de commande désactivée.

Surveillez aussi la destruction de preuves : 1102 (journal Sécurité effacé) et 104 (autre journal effacé, dans System) doivent toujours déclencher une alerte.

Couche 3 : Sysmon

Sysmon (System Monitor, issu de Microsoft Sysinternals) est un pilote et un service gratuits qui enregistrent l'activité détaillée des processus, du réseau, des fichiers et du registre dans Applications and Services Logs > Microsoft > Windows > Sysmon > Operational. Depuis 2026, c'est aussi une fonctionnalité facultative intégrée à Windows 11 et Windows Server 2025, désactivée par défaut et configurée avec le même XML ; le guide de déploiement de Sysmon explique comment choisir entre les deux. Ses événements les plus utiles :

Sysmon ne vaut que par sa configuration : une configuration vide journalise très peu, une configuration naïve inonde votre SIEM. Partez d'une configuration communautaire maintenue, comme sysmon-config de SwiftOnSecurity ou sysmon-modular d'Olaf Hartong, puis ajustez-la à votre environnement.

# Installer avec une configuration
Sysmon64.exe -accepteula -i sysmonconfig.xml
# Mettre à jour la configuration ultérieurement
Sysmon64.exe -c sysmonconfig.xml
# Afficher la configuration active
Sysmon64.exe -c

Déployez Sysmon via votre outil de distribution logicielle, figez la version et vérifiez que le service Sysmon64 tourne : l'arrêter est un réflexe évident pour un attaquant (Sysmon journalise l'événement 4 pour les changements d'état du service et 16 pour les changements de configuration).

Couche 4 : sortir les événements de l'hôte

Les journaux locaux peuvent être effacés par n'importe qui disposant de droits d'administration. Transférez-les.

Windows Event Forwarding (WEF) est intégré et ne nécessite aucun agent :

1. Sur un serveur collecteur : wecutil qc pour configurer le service Windows Event Collector.
2. Créez des abonnements initiés par la source (requêtes XPath sélectionnant les ID d'événements ci-dessus).
3. Par GPO sur les sources : Administrative Templates > Windows Components > Event Forwarding > Configure target Subscription Manager = Server=http://wec01.corp.example:5985/wsman/SubscriptionManager/WEC,Refresh=60.
4. Donnez au compte Network Service l'accès en lecture au journal Sécurité sur les sources, en l'ajoutant au groupe Event Log Readers via les groupes restreints ou les préférences de stratégie de groupe.

Depuis le collecteur, envoyez ForwardedEvents vers votre SIEM. Si vous exploitez déjà un agent SIEM ou EDR, pointez-le plutôt sur les mêmes ID d'événements ; l'essentiel est que les événements quittent l'hôte en quelques minutes.

À quoi ressemble un bon résultat

Une façon rapide de tester le socle consiste à poser les questions d'un incident imaginaire et à vérifier que vos journaux y répondent :

• Qui s'est connecté au serveur X mardi dernier, et depuis où ? 4624 avec type d'ouverture de session et IP source, transféré.
• Qu'a exécuté cette session ? 4688 avec lignes de commande, Sysmon 1, PowerShell 4104.
• Quelque chose a-t-il touché LSASS ? Sysmon 10 filtré sur lsass.exe.
• Une persistance a-t-elle été ajoutée ? 4697 / 7045 (service), 4698 (tâche planifiée), Sysmon 13 sur les clés Run.
• Vers où s'est-il connecté ? Sysmon 3 et 22.
• Quelqu'un a-t-il tenté de le masquer ? 1102, 104, Sysmon 4/16, Defender 5001/5007.

Liste de contrôle

• Stratégie d'audit avancée forcée à prévaloir ; sous-catégories définies comme ci-dessus
• Capture de la ligne de commande dans le 4688 activée
• Journal Sécurité dimensionné pour des jours, pas des heures ; alertes sur l'effacement des journaux
• Sysmon déployé avec une configuration maintenue et ajustée
• Événements transférés (WEF ou agent) et conservés de façon centralisée
• Questions d'incident traitées de bout en bout lors d'un exercice sur table

La journalisation n'empêche rien, mais chaque autre contrôle de cette cartographie devient plus fiable lorsque vous pouvez le voir fonctionner, et voir le moment où il cesse de fonctionner.