🛡️ Projet d'Ingénierie de Détection : Création d'un mini-SOC avec Windows Event Forwarding & Sysmon

Ce projet présente la mise en place complète d'une infrastructure de collecte centralisée de logs de sécurité (SIEM-ready) et la création de règles de détection d'attaques au sein d'un domaine Active Directory.

L'objectif est de simuler le fonctionnement d'un SOC (Security Operations Center) en centralisant la télémétrie d'un poste de travail pour y détecter des comportements suspects en temps réel.

---

💡 Qu'est-ce que ce projet démontre à un recruteur SOC ?

Plutôt que d'utiliser des outils de détection "tout faits", ce lab prouve ma capacité à :

1. Comprendre et manipuler la télémétrie brute : Je n'attends pas qu'une alerte magique apparaisse, je sais comment configurer l'agent de sécurité (Sysmon) pour capturer les bons indicateurs de compromission (IoC).
2. Maîtriser l'ingestion des logs (Log Sources) : Utilisation des protocoles natifs de Windows (WinRM/Kerberos) et de l'architecture WEC/WEF pour acheminer les événements du client vers le collecteur sans agent tiers encombrant.
3. Faire du Troubleshooting Système & Réseau : Résolution de problèmes liés aux droits d'accès aux journaux, aux blocages de flux WinRM et au déchiffrement des structures XML.

---

🛠️ Architecture du Lab

• Hyperviseur : VMware Workstation / VirtualBox (Réseau privé NAT/LAN)
• Contrôleur de Domaine & Collecteur (Le "SOC" / WEC) :
  • OS : Windows Server
  • Rôles : AD DS, DNS, Windows Event Collector (WEC)
  • Nom d'hôte : AD-SERVER-1
  • Domaine : lab.local
• Poste Client Surveillé (La Source) :
  • OS : Windows 11 Enterprise (joint au domaine)
  • Nom d'hôte : eliot
  • Agent de détection : SwiftOnSecurity Sysmon v15+

---

🚀 Guide de Déploiement Étape par Étape

Étape 1 : Préparation de l'Infrastructure AD

1. Promotion du contrôleur de domaine : Installation du rôle AD DS sur le Windows Server et création de la forêt lab.local.
2. Jonction du client : Configuration de la carte réseau du Windows 11 (DNS pointant vers le DC) et intégration au domaine Active Directory.
3. Création du groupe de sécurité : Création d'un groupe de sécurité (ex: Domain Computers) contenant le compte de l'ordinateur client afin de l'autoriser à distance.

Étape 2 : Configuration et Déploiement de Sysmon (Client)

1. Téléchargement de l'utilitaire Sysmon (Sysinternals) sur le poste Windows 11.
2. Installation de l'agent en ligne de commande pour enregistrer le service de surveillance des processus : Commande : sysmon64.exe -i -n /accepteula

Étape 3 : Configuration du Flux WinRM & GPO (WEF)

Afin de permettre l'envoi sécurisé des logs via Kerberos du client vers le serveur :

1. Activation de WinRM sur le client : Configuration du service Windows Remote Management (WS-Management).
2. Création d'une GPO (Group Policy Object) :
   • Stratégie de transfert d'événements : Configuration de l'adresse du serveur collecteur via le paramètre Configure target Subscription Manager : Server=http://AD-SERVER-1.lab.local:5985/wsman/SubscriptionManager/Wec,Refresh=60
   • Accès aux journaux de sécurité : Ajout du compte de service Network Service au groupe local Event Log Readers sur le client pour lui permettre de lire et transférer les journaux Sysmon.

Étape 4 : Création de la Souscription (Serveur)

1. Démarrage du service de collecte sur le Windows Server : Commande : wecutil qc
2. Création d'une souscription Source-Initiated (initiée par le client) nommée Collecte-Sysmon ciblant le canal Microsoft-Windows-Sysmon/Operational.
3. Ajout du groupe d'ordinateurs autorisés à envoyer des logs (Domain Computers).

---

🛠️ Phase de Troubleshooting (Résolution de Problèmes)

Durant la mise en place, plusieurs obstacles techniques ont été identifiés et résolus :

• Problème de délai de transmission : Le client mettait trop de temps à transmettre. Forçage du vidage du cache de l'agent via la base de registre (SubscriptionManager configuré sur un Refresh=60 secondes) et redémarrage du service WinRM (net stop WinRM && net start WinRM).
• Erreur d'affichage XML du serveur : Le serveur n'arrivait pas à décoder les descriptions des ID d'événements Sysmon car le manifeste n'y était pas enregistré. Résolu en important la structure de Sysmon sur le serveur de collecte.

---

🛡️ Scénario d'Attaque & Détection SOC (Proof of Concept)

Pour valider notre chaîne de détection SOC, nous avons simulé une technique offensive couramment utilisée par les attaquants pour contourner les restrictions d'exécution de scripts.

1. Déclenchement de la menace (Simulation d'Attaque sur Windows 11)

Commande exécutée : powershell -NoProfile -ExecutionPolicy Bypass -Command "Write-Host 'ALERTE_SOC_DETECTED'"

Cette commande contourne la politique d'exécution de PowerShell (Bypass) et masque le profil utilisateur (NoProfile).

Preuve d'exécution locale :

---

2. Validation du pipeline de collecte (Windows Server)

Sur le serveur de collecte (notre concentrateur SOC), l'abonnement montre un statut parfaitement vert et actif. La liaison WinRM/Kerberos fonctionne.

Statut de la souscription WEC :

---

3. Analyse de l'alerte par l'Analyste SOC (Windows Server)

Le log Sysmon a bien été transféré en temps réel vers le serveur dans le journal Forwarded Events.

En tant qu'analyste SOC, l'ouverture de l'événement nous permet d'extraire des indicateurs clés (IoC) pour l'investigation :

• Processus suspect : powershell.exe (IntegrityLevel: High)
• Ligne de commande malveillante : powershell -NoProfile -ExecutionPolicy Bypass...
• Compte utilisateur compromis : LAB\Administrator
• Processus parent : cmd.exe (qui montre d'où l'attaque a été initiée)

Détails de l'alerte Sysmon (Vue XML) :

---

🎓 Compétences SOC & Administrateur Validées

• Ingénierie de Détection : Installation et filtrage de la télémétrie Sysmon.
• Architecture Réseau & Système Windows : GPO, WinRM, DNS, Active Directory et protocole Kerberos.
• Analyse de Logs (Blue Teaming) : Lecture et requêtage de structures d'événements complexes au format XML.