Tu n’as pas un SOC. Pas de budget pour Splunk. Et pourtant, tu as quand même besoin de répondre à cette question un peu flippante, mais très concrète : « Est ce qu’on est déjà compromis, là, maintenant ? »
Ce que je te propose ici, c’est un SIEM léger. Pas un SIEM parfait. Pas un SIEM « compliance ready ». Juste un truc réaliste, montable vite, avec des sources de logs qui font vraiment la différence, et un plan d’enquête qui tient en 1 heure.
Le but est simple : en 60 minutes, tu dois pouvoir dire :
- soit « je n’ai rien vu de clair, mais j’ai vérifié les points chauds »
- soit « j’ai des signaux sérieux, je déclenche l’incident »
Et si tu es en BTS SIO option SISR, c’est exactement le genre de démarche que tu peux transformer en mini lab, en compte rendu E4 ou en routine perso. D’ailleurs, sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), ce genre de posts et de labs, ça rentre pile dans l’esprit du site : apprendre vite, tester, documenter, et repartir avec une méthode.
Ce que j’appelle « SIEM léger »
Un SIEM classique fait plein de choses : collecte, normalisation, corrélation, alerting, tableaux de bord, rétention longue, intégrations, etc.
Un SIEM léger, pour nous, c’est plutôt :
- collecte centralisée minimale
- quelques détections à fort rendement
- une façon simple de chercher : filtrer, pivoter, retrouver une chronologie
- une méthode pour conclure rapidement
Tu peux le faire avec plusieurs stacks. Deux options que j’aime bien selon le temps et le niveau :
- Wazuh (qui apporte déjà beaucoup de règles et une console)
- Elastic + agents (plus flexible, mais plus de réglages)
Pour tenir la promesse « en 1 heure », je pars sur une base simple, orientée enquête : Windows Event Logs + Sysmon + authentification + DNS. Et côté Linux, au minimum : auth.log + sudo + journald si tu peux.
Schéma express du lab
Voici une version « 1 VM + 1 poste » très réaliste :
- 1 VM Linux (Debian/Ubuntu) : serveur de collecte et tableau de bord
- 1 poste Windows (ou VM) : cible à monitorer
- Optionnel : une VM Linux serveur (SSH) pour varier
Oui l’image est symbolique, mais garde l’idée : centraliser, même petit.
Les prérequis qui changent tout (et qu’on oublie trop souvent)
1) Avoir Sysmon sur Windows
Sans Sysmon, tu vois des choses. Avec Sysmon, tu vois les choses utiles.
- création de processus
- connexions réseau par processus
- création de services
- tâches planifiées
- modifications de registre sensibles
Installe Sysmon avec une config standard comme SwiftOnSecurity (ou une config Wazuh recommandée). Pas besoin de la config parfaite aujourd’hui.
2) Centraliser les logs au moins sur 24 h
Même si tu ne gardes pas un mois. Pour une compromission, 24 h te donnent déjà la majorité des indices exploitables.
3) Avoir l’heure correcte partout
NTP. Toujours NTP. Une timeline fausse, c’est l’enquête qui devient bancale.
Plan d’enquête en 1 heure (minute par minute)
Je te donne une méthode qui marche même si tu es stressé. Tu suis la check list, tu notes tout, tu pivotes quand tu vois un truc.
Minute 0 à 5 : cadrage et collecte rapide
Avant de « chercher des menaces », tu clarifies :
- quel périmètre : un poste, un serveur, un sous réseau
- quel symptôme : alerte AV, compte bloqué, trafic sortant, lenteur, ransom note
- fenêtre de temps : « depuis ce matin », « depuis hier soir », etc.
Tu ouvres un fichier de notes et tu écris : heure, machine, utilisateur, IP, symptôme. Basique, mais ça évite de te perdre.
Minute 5 à 20 : authentification et accès (le gros rendement)
Sur Windows : événements de logon
Tu cherches d’abord les connexions. Parce que dans la vraie vie, beaucoup de compromissions commencent par ça.
- 4624 : logon réussi
- 4625 : échec de logon
- 4672 : privilèges admin attribués
- 4648 : logon avec identifiants explicites (très utile)
Ce que tu veux repérer :
- un compte admin qui se connecte à des heures anormales
- des logons de type RDP (type 10) inattendus
- une rafale de 4625 suivie d’un 4624 (brute force réussi)
- un même compte qui se connecte depuis plusieurs postes
Questions simples à te poser :
- ce compte devait il se connecter ici ?
- l’IP source est elle interne ou externe ?
- le poste source est il connu ?
Sur Linux : SSH et sudo
Cherche :
Accepted passwordouAccepted publickeydans/var/log/auth.logsudo:avec des commandes suspectes- connexions depuis des IP externes inattendues
Même logique : qui, quand, depuis où.
Minute 20 à 40 : exécution de code et persistance (là où ça se confirme)
Windows : processus suspects (Sysmon + Security)
Si tu as Sysmon :
- Sysmon Event ID 1 : Process Create
- Sysmon Event ID 3 : Network Connection
- Sysmon Event ID 7 : Image Loaded (selon config)
- Sysmon Event ID 13 : Registry value set
- Sysmon Event ID 19/20/21 : WMI (persistance)
- Sysmon Event ID 6/7045 : service installé (7045 côté System)
Ce que tu cherches en priorité :
1) LOLBins (outils Windows détournés)
Exemples typiques :
powershell.exeavec-encouFromBase64Stringcmd.exe /cqui lance un script depuisAppDataouTemprundll32.exeavec une DLL dans un chemin bizarremshta.exequi charge une URLcertutil.exeutilisé pour télécharger
Tu n’as pas besoin de reconnaître 200 techniques. Tu repères juste ce qui ne colle pas au poste.
2) Exécution depuis les dossiers à risque
C:\Users\...\AppData\Roaming\C:\Users\...\AppData\Local\Temp\C:\ProgramData\C:\Windows\Temp\
Un binaire lancé depuis Temp, ça mérite presque toujours un pivot.
3) Persistances rapides à vérifier
- tâches planifiées
- services
- clés Run/RunOnce
- WMI event filters (si tu peux)
À ce stade, tu veux une réponse : « Est ce qu’un code non attendu s’exécute et se relance ? »
Minute 40 à 55 : réseau, DNS et exfiltration (sans devenir analyste NetFlow)
Même avec un SIEM léger, tu peux faire beaucoup en regardant :
- connexions sortantes vers IP publiques inconnues
- DNS vers des domaines bizarres, récents, ou générés
- connexions répétitives toutes les X minutes (beaconing)
Ce qui marche bien
- filtrer sur les processus qui font du réseau : navigateur ok, mais
powershell.exequi parle vers Internet, non - repérer des ports atypiques sortants : 4444, 8081, 1337, etc. Bon ce n’est pas une science exacte. Mais ça aide.
Si tu as Sysmon Event ID 3, tu peux lier :
processus → IP destination → port → fréquence
Et là, tu commences à tenir quelque chose de concret.
Minute 55 à 60 : conclusion rapide et décision
Tu termines en classant ce que tu as trouvé en 3 niveaux. J’aime bien cette grille, simple :
Niveau 0 : rien de notable
- pas d’auth anormale
- pas de nouveaux services / tâches
- pas de processus suspects
- pas de trafic sortant étrange
Tu notes quand même ce que tu as vérifié. Parce que c’est ça qui a de la valeur.
Niveau 1 : signaux faibles
- quelques échecs de logon
- une exécution PowerShell un peu louche mais pas certaine
- un domaine DNS inconnu sans preuve
Tu planifies : approfondir, augmenter la collecte, activer plus de logs, isoler si besoin.
Niveau 2 : compromission probable
- logon admin inhabituel + exécution suspecte
- persistance confirmée (service, tâche)
- beaconing réseau identifié
- création de compte, ajout groupe admin, etc.
Là tu déclenches. Même sans certitude absolue, tu passes en mode incident : isolement, collecte mémoire si possible, sauvegarde des artefacts, changement des mots de passe, etc.
Les 12 détections « à fort rendement » pour un SIEM léger
Tu peux en faire une check list dans ton SIEM, ou même juste des requêtes sauvegardées.
- rafale de 4625 suivie d’un 4624 sur le même compte
- 4672 sur un compte qui n’est pas censé être admin
- logon RDP type 10 depuis une machine non attendue
powershell.exeavec-encouIEXmshta.exequi touche Internetrundll32.exedepuis AppData/Temp- création de service (7045) récent
- tâche planifiée créée récemment
- binaire exécuté depuis
C:\Users\...\AppData\Local\Temp\ - connexion sortante par
powershell.exe,wscript.exe,cscript.exe - DNS vers un domaine aléatoire ou très long, répété
- ajout d’un utilisateur à un groupe admin local
Si tu n’en actives que 5 ou 6, prends : 1, 4, 7, 8, 10, 12. C’est déjà énorme.
Stack conseillée (simple, et réaliste en BTS)
Si tu veux un chemin « pas trop long » :
- Wazuh Manager + Dashboard sur une VM Linux
- agent Wazuh sur Windows
- Sysmon + config de base
- logs Windows Security + System + Sysmon
Ensuite, tu fais évoluer.
Et si tu documentes ton installation, tes règles, et 2 ou 3 scénarios d’attaque simulés (brute force RDP, création de service, PowerShell encodé), tu tiens un contenu très publiable sur BTS SIO2 SISR Tech Lab. Le site est parfait pour ça, c’est littéralement sa mission : labs, retours d’expérience, et apprentissage en conditions quasi réelles.
Images et supports à ajouter dans ton article ou ton lab
Si tu veux enrichir ta publication WordPress, ajoute des captures :
- dashboard Wazuh (agents connectés, alertes)
- filtre Kibana sur 4624/4625
- exemple Sysmon Event ID 1 (process creation)
- exemple 7045 (service installé)
- graphe des connexions sortantes
Tu peux aussi insérer un schéma réseau de ton lab fait sur draw.io. Même simple. Ça aide beaucoup le lecteur.
Conclusion
Un SIEM léger, ce n’est pas un « mini Splunk ». C’est une routine de survie. Tu centralises les bons logs, tu sais où regarder, et tu suis un plan d’enquête qui ne part pas dans tous les sens.
En 1 heure, tu ne vas pas tout prouver. Mais tu peux détecter une compromission crédible, ou au minimum dire : « j’ai vérifié les zones critiques, voilà ce que j’ai, voilà ce qui manque ».
Si tu veux, je peux te proposer une version lab complète avec : Wazuh, Sysmon, règles prêtes à l’emploi, et un scénario d’attaque simulé avec les requêtes de recherche déjà préparées. Un truc que tu pourrais publier ensuite sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) comme un TP clé en main.
Questions fréquemment posées
Qu'est-ce qu'un SIEM léger et en quoi diffère-t-il d'un SIEM classique ?
Un SIEM léger est une solution de gestion des événements et informations de sécurité simplifiée, centrée sur la collecte minimale des logs essentiels, quelques détections à fort rendement, une méthode simple pour chercher et analyser les données, ainsi qu'un plan d'enquête rapide. Contrairement à un SIEM classique qui inclut la normalisation, la corrélation avancée, l'alerting complexe, des tableaux de bord sophistiqués et une rétention longue des données, le SIEM léger est montable rapidement et adapté aux petites structures ou aux situations où le budget est limité.
Quels sont les prérequis indispensables pour mettre en place un SIEM léger efficace ?
Les prérequis clés incluent : 1) Installer Sysmon sur les postes Windows pour collecter des événements utiles comme la création de processus ou les connexions réseau par processus ; 2) Centraliser les logs au moins sur 24 heures afin d'avoir suffisamment d'indices exploitables en cas de compromission ; 3) S'assurer que l'heure soit correcte partout grâce au protocole NTP pour garantir une chronologie fiable lors de l'enquête.
Comment réaliser un plan d'enquête en 1 heure avec un SIEM léger ?
Le plan d'enquête se déroule en plusieurs étapes : De 0 à 5 minutes, cadrage et collecte rapide des informations (périmètre, symptôme, fenêtre temporelle) ; De 5 à 20 minutes, analyse des événements d'authentification et accès (notamment les logs Windows comme 4624, 4625, 4672) pour détecter des connexions suspectes ; Le reste du temps est consacré à pivoter dans les données selon les indices trouvés pour conclure si la machine est compromise ou non.
Quels outils recommandes-tu pour déployer un SIEM léger rapidement ?
Deux options sont particulièrement recommandées : Wazuh, qui offre déjà beaucoup de règles intégrées et une console prête à l'emploi facilitant le déploiement rapide ; Elastic Stack avec agents (Elastic + Beats), plus flexible mais nécessitant davantage de réglages. Le choix dépend du temps disponible et du niveau technique.
Quels types de logs sont essentiels à collecter dans un SIEM léger ?
Pour Windows, il est recommandé de collecter les logs d'événements Windows classiques (notamment ceux liés aux authentifications), Sysmon pour avoir des détails précis sur les processus et connexions réseau par processus, ainsi que les logs d'authentification et DNS. Pour Linux, au minimum il faut collecter auth.log, sudo et journald afin d'avoir une vision complète des accès et actions système.
Comment ce type de démarche s'intègre-t-il dans le cadre d'une formation BTS SIO option SISR ?
Cette démarche correspond parfaitement à un mini lab réalisable en BTS SIO option SISR. Elle permet d'apprendre vite en testant concrètement la collecte centralisée de logs, l'analyse rapide via un SIEM léger et la rédaction d'un compte rendu. C'est idéal pour préparer l'épreuve E4 ou développer une routine personnelle en sécurité informatique.
0 Commentaires