Environnement
Deux machines VirtualBox sur un réseau privé hôte (192.168.56.0/24) : un endpoint Windows 10 Pro 22H2 (DESKTOP-LIJD7CI, 192.168.56.20) exécutant Sysmon v15.21 avec la configuration SwiftOnSecurity et l'agent Wazuh, et un hôte Ubuntu 24.10 (192.168.56.103) hébergeant la pile Wazuh 4.12 complète en mode tout-en-un — Manager, Indexer et Dashboard. Les journaux d'événements Windows et la télémétrie Sysmon transitent via TCP 1514 authentifié jusqu'au manager, sont confrontés aux règles natives et personnalisées, puis indexés pour les requêtes Discover et les dashboards. Il s'agit délibérément d'un laboratoire à un hôte et un manager : il valide la logique de détection de bout en bout, et non la gestion multi-agents à grande échelle.
Y parvenir a exigé un véritable travail d'ingénierie, pas le simple suivi d'un guide d'installation : le fichier ossec.conf de référence documentait le bloc de transfert Sysmon, mais la configuration réellement déployée sur l'endpoint ne le contenait pas — un écart entre configuration documentée et configuration déployée qu'il a fallu détecter avec Select-String, plutôt que de le supposer. Le fileset archives de Filebeat est désactivé par défaut, ce qui bloque silencieusement les requêtes Discover sur les événements bruts, même lorsque les alertes sont correctement indexées. Une politique de rétention des index de 30 jours a dû être appliquée manuellement via une politique ISM OpenSearch — l'installation par défaut n'en prévoit aucune, et des index non gérés ont provoqué une véritable panne liée à la saturation du disque pendant ce déploiement (voir les notes d'incident ci-dessous).
Les captures d'écran prouvent qu'un état a existé à un instant donné ; elles ne prouvent pas que le pipeline fonctionne toujours. healthcheck.sh contrôle les 8 étapes par programme, à la demande — services, disque, syntaxe des règles, archives et authentification Filebeat, connectivité de l'agent, présence effective d'événements Sysmon dans l'index, déclenchement de chacune des 6 règles personnalisées sous son propre identifiant, et couverture par les règles natives pour le reste. Sur un déploiement vierge, les étapes 7-8 s'affichent à juste titre en FAIL tant que la simulation d'attaque n'a pas été exécutée au moins une fois — c'est le comportement attendu, pas un bug.
La kill chain : 6 techniques, une seule chaîne causale
scripts/attacks.bat n'est pas une succession de six démonstrations de techniques indépendantes : c'est une kill chain unique dans laquelle chaque phase est une conséquence réelle et vérifiée de la précédente. L'attaque par force brute de la phase 2 aboutit effectivement contre un véritable compte de test local membre du groupe Administrateurs (svcbackup), et le dump SAM de la phase 3 s'exécute sous ce même compte compromis, via une tâche planifiée, et non depuis un shell déjà élevé. Chaque technique ci-dessous s'appuie sur un véritable enregistrement Sysmon Event ID 1 (Process Create), transmis par l'agent et interrogé depuis l'index du manager — pas sur un exemple simulé.
Phases 1 & 6 — Découverte T1082, T1057
La chaîne s'ouvre et se referme sur de la reconnaissance : systeminfo, whoami /all, net user, net localgroup administrators et tasklist /v. La découverte n'a rien de spectaculaire, mais c'est l'étape par laquelle passe toute intrusion réelle avant de s'engager davantage — et c'est précisément le type d'activité discrète que la capture complète des lignes de commande par Sysmon permet de détecter, là où la journalisation native de Windows passerait totalement à côté.
Les deux passes de découverte sont détectées par le jeu de règles natif de Wazuh sans aucun développement spécifique : la règle 92031 (activité de découverte, T1087) et la famille 92036/92039 pour les commandes d'énumération de comptes via net.exe. Une règle personnalisée (100014) a également été écrite spécifiquement pour le motif générique des commandes de découverte ; son déclenchement a été vérifié de manière indépendante à 24 reprises dans l'indexer en production.
Phase 2 — Force brute T1110.001
Cinq véritables tentatives d'authentification IPC$ échouées contre le compte local svcbackup, membre du groupe Administrateurs, suivies d'une sixième avec son mot de passe réel — cette attaque par force brute aboutit réellement : un véritable événement Windows Security 4624 (ouverture de session réussie) suit cinq véritables événements 4625 (échec d'ouverture de session), et non une hypothèse présentée comme un fait. L'enseignement clé en matière de détection est que Sysmon Event ID 1 prouve uniquement que net.exe a été exécuté — il n'indique en rien si la tentative d'authentification a réussi ou échoué. Une détection T1110 fiable a donc nécessité une corrélation avec l'événement Windows Security 4625, l'événement réel d'échec d'authentification, plutôt qu'une simple correspondance de motif sur la ligne de commande.
La règle personnalisée 100016 répond à la question « un schéma de force brute s'est-il produit ? » en corrélant au moins 5 déclenchements de la règle native 60122 (4625) dans une fenêtre de 120 secondes sur le même agent. Elle n'indique pas si l'une des tentatives a abouti — et c'est précisément la distinction qu'un analyste doit établir. La règle 100017 automatise cette vérification : elle ne se déclenche que lorsqu'une véritable ouverture de session 4624 suit une alerte 100016 sur le même endpoint, confirmant que la force brute n'a pas seulement été tentée, mais qu'elle a réussi. Cette mise au point a révélé un véritable bug dans la simulation elle-même : une version antérieure remplaçait la 5e tentative échouée par la tentative réussie, ne laissant que 4 échecs réels — un de moins que le seuil de la règle — si bien qu'aucune des deux règles ne se déclenchait jusqu'à ce que le script soit corrigé pour envoyer d'abord les 5 échecs réels.
Phase 3 — Extraction d'identifiants (SAM) + détournement de tâche planifiée T1003.002, T1053.005
Les ruches SAM/SYSTEM sont exportées avec reg.exe save HKLM\SAM ... — mais l'élément qui mérite d'être documenté est la manière dont la commande est exécutée : sous svcbackup, le compte tout juste compromis en phase 2, via une tâche du Planificateur de tâches (schtasks /ru svcbackup /rp ... /rl highest), et non depuis le contexte déjà élevé du script. La première version de cette phase utilisait runas /savecred, et elle a réellement échoué : un compte administrateur local utilisé via une ouverture de session secondaire runas reçoit le jeton standard filtré par l'UAC de Windows, et non un jeton administrateur complet, si bien que reg save HKLM\SAM a échoué purement et simplement avec une erreur de privilège manquant — alors même que le compte est un véritable administrateur. Une tâche planifiée créée avec /rl highest obtient un jeton authentique, non filtré, sans invite UAC interactive, ce qui explique précisément pourquoi les intrusions réelles détournent le Planificateur de tâches pour les opérations privilégiées (T1053.005 à part entière).
L'effet de bord de ce contournement constitue lui-même une opportunité de détection : la création de la tâche planifiée fait apparaître en clair le mot de passe réel de svcbackup sur la ligne de commande (/rp Summer2026!), entièrement visible par Sysmon Event ID 1. La règle personnalisée 100018 transforme cet effet de bord en alerte — sévérité critique, déclenchement vérifié exactement une fois, une seconde après la confirmation de réussite de la force brute. Le dump SAM lui-même est détecté par le jeu de règles natif de Wazuh sans aucun développement spécifique : règle 92026, niveau 14 — un cran en dessous de la sévérité maximale de Wazuh, et l'alerte individuelle la plus forte de tout le laboratoire.
Phase 4 — Persistance via une clé de registre Run T1547.001
reg add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v WindowsUpdateHelper /t REG_SZ /d "C:\temp\evil.exe" /f — une entrée de clé Run dissimulée sous un nom (« WindowsUpdateHelper ») délibérément choisi pour se fondre dans le bruit habituel de Windows Update lors d'un examen rapide de la liste des clés Run. Il s'agit de l'un des mécanismes de persistance les plus courants dans les attaques réelles, précisément parce qu'il ne requiert aucun privilège particulier et survit à un simple redémarrage.
La télémétrie registre de Sysmon (Event IDs 12/13) est exactement la capacité qui fait défaut à la journalisation native de Windows sans un paramétrage poussé de la stratégie d'audit — la configuration SwiftOnSecurity conserve ce type d'événement en pleine fidélité tout en filtrant le bruit registre volumineux et peu significatif qui le noierait autrement.
Phase 5 — Évasion des défenses via PowerShell encodé T1059.001
powershell -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden -EncodedCommand aQBwAGMAbwBuAGYAaQBnAA== — fenêtre masquée, stratégie d'exécution contournée, charge utile encodée en Base64. C'est la technique qui justifie le plus directement le recours à Sysmon plutôt qu'à la journalisation native : sans capture complète des lignes de commande, il est impossible de distinguer un script d'automatisation PowerShell légitime d'un attaquant qui dissimule une charge utile derrière un encodage Base64 et une fenêtre masquée.
Le jeu de règles natif de Wazuh ne comporte aucune règle pour ce motif précis ; une détection personnalisée a donc été écrite : la règle 100012 détecte -EncodedCommand (insensible à la casse, tolérant l'extension .exe) directement dans le champ Sysmon commandLine, au niveau 13 — son déclenchement a été vérifié de manière indépendante à 8 reprises dans l'indexer en production.
Correspondance techniques / règles
| Technique | ID ATT&CK | Événement Sysmon | Règle(s) Wazuh | Occurrences vérifiées |
|---|---|---|---|---|
| Découverte du système / des comptes | T1082, T1087 | Event ID 1 | 92031, 92036, 92039, personnalisée 100014 | 100014 : 24 |
| Force brute (IPC$) | T1110.001 | Event ID 1 + Security 4625/4624 | personnalisées 100013, 100016, 100017 | 100013 : 5 · 100016 : 5 · 100017 : 11 |
| Extraction d'identifiants (SAM) | T1003.002 | Event ID 1 | native 92026 | 13 |
| Détournement de tâche planifiée | T1053.005 | Event ID 1 | personnalisée 100018 | 1 |
| Persistance via clé de registre Run | T1547.001 | Event ID 1, 13 | aucune livrée — couverte par la priorité des règles natives | — |
| PowerShell encodé | T1059.001 | Event ID 1 | personnalisée 100012 | 8 |
| Découverte des processus | T1057 | Event ID 1 | famille 92031 | — |
Trois règles supplémentaires portant sur la ligne de commande (dump de la ruche SAM, persistance via clé Run, tasklist en mode détaillé) ont été écrites, déployées, puis délibérément supprimées : Wazuh évalue les règles dans l'ordre et s'arrête à la première correspondance, et les règles natives détectaient déjà en premier ces mêmes événements Sysmon. Livrer des règles qui, par construction, ne peuvent jamais se déclencher relève du code mort, pas de la couverture — c'est donc la couverture par les règles natives qui est effectivement active pour ces trois techniques, confirmée à la fois par les captures d'écran ci-dessus et en continu par scripts/healthcheck.sh.
Conformité : Security Configuration Assessment
Le module Configuration Assessment a exécuté en continu, en arrière-plan, le CIS Microsoft Windows 10 Enterprise Benchmark v1.12.0 sur DESKTOP-LIJD7CI (<sca><scan_on_start>yes</scan_on_start><interval>12h</interval></sca>) — 394 contrôles, 127 réussis / 263 échoués, soit un score de 32 %. Chaque contrôle en échec correspond à une cible de remédiation précise : une clé de registre ou une commande à vérifier, et non un simple indicateur réussi/échoué sans suite possible. Fait notable, le scan CIS confirme de manière indépendante deux des failles exactes exploitées par la simulation d'attaque de ce laboratoire : « Seuil de verrouillage du compte » et « Durée de verrouillage du compte » sont tous deux en échec, ce qui signifie que l'endpoint ne dispose d'aucune protection de verrouillage automatique face à la force brute démontrée en phase 2 — un constat de conformité et un constat de détection qui pointent vers la même cause racine.
Constats notables
- Une force brute qui aboutit réellement, alimentant un dump SAM effectivement exécuté sous le compte compromis — la plupart des kill chains de laboratoire se contentent de raconter la causalité ; celle-ci la vérifie de bout en bout dans l'indexer en production, chaque étape étant rattachée au même nom d'utilisateur.
- Une frontière UAC découverte par l'expérimentation, et non lue dans la documentation —
runasproduit silencieusement un jeton filtré, même pour un véritable compte administrateur ; le contournement (les tâches planifiées) est lui-même une technique ATT&CK référencée et une opportunité de détection à part entière. - La télémétrie de création de processus ne suffit pas à détecter une force brute — Sysmon Event ID 1 prouve seulement qu'une tentative d'ouverture de session a eu lieu, pas qu'elle a réussi ; une détection T1110 fiable a nécessité une corrélation avec l'événement Windows Security réel indiquant l'issue de l'authentification.
- Les règles mortes ont été supprimées, pas conservées pour la forme — trois règles personnalisées qui, par construction, ne pouvaient jamais se déclencher (les règles natives l'emportant toujours en priorité d'évaluation) ont été retirées plutôt que laissées dans le jeu de règles pour l'apparence.
Les définitions complètes des règles, le script d'attaque intégral, l'outillage de contrôle de santé et 4 captures d'écran supplémentaires non présentées ci-dessus (les rapports de triage d'analyste SOC, le tableau de référence des empreintes de processus et les notes de dépannage de réponse à incident) sont disponibles dans le dépôt.