Mon Premier Home Lab : De la VM à la Détection d'Attaque sur Active Directory

Pour mettre en pratique les concepts de cybersécurité, rien ne vaut un véritable terrain de jeu. J’ai donc décidé de construire un laboratoire virtuel (Home Lab) complet simulant un réseau d’entreprise. L’objectif : monter un domaine Active Directory, y connecter une machine cible, et mettre en place une surveillance avec Splunk pour observer en direct les effets d’une attaque lancée depuis une machine Kali Linux. Voici le récit de ce projet, avec ses défis et ses solutions.

Étape 1 : L’Architecture du Champ de Bataille

Avant toute chose, j’ai posé les bases sur un diagramme. Le labo est composé de quatre machines virtuelles sur VirtualBox, chacune avec un rôle précis :

Étape 2 : Le Défi du Réseau - Stabiliser le Serveur Splunk

Le premier obstacle est apparu sur le serveur Ubuntu destiné à Splunk. Pour qu’il soit une cible fiable, son adresse IP devait être statique. J’ai donc modifié le fichier de configuration Netplan.

Erreur n°1 : La syntaxe Netplan. Ma première tentative de configuration a échoué. Après quelques recherches, j’ai compris que la syntaxe gateway4 était devenue la norme, plus simple que l’ancienne directive routes.

Erreur n°2 : Le “sabotage” par cloud-init ! Malgré une configuration correcte, l’IP était réinitialisée à chaque redémarrage. Le coupable ? cloud-init, un outil qui reconfigure le réseau au démarrage. C’est un “piège” classique dans les environnements virtualisés.

La solution finale :

1. Désactiver la gestion réseau de cloud-init.

   # Créer un fichier pour dire à cloud-init de ne pas toucher au réseau
   sudo nano /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
   # Y ajouter : network: {config: disabled}
   

2. Créer mon propre fichier de configuration Netplan (01-netcfg.yaml) avec la bonne syntaxe, puis l’appliquer avec sudo netplan apply.

Une fois le réseau stable, l’installation de Splunk et sa configuration pour démarrer automatiquement se sont déroulées sans encombre.

Étape 3 : Armer la Cible avec Sysmon et un Forwarder

Sur la machine Target-PC, j’ai déployé deux outils essentiels :

1. Sysmon : Un outil de Microsoft qui fournit une journalisation système extrêmement détaillée (création de processus, connexions réseau, etc.). Je l’ai installé avec une configuration XML personnalisée pour filtrer le bruit et ne garder que les événements pertinents.
2. Splunk Universal Forwarder : Un agent léger qui collecte les logs générés par Sysmon et les envoie en temps réel à mon serveur Splunk (192.168.10.10) sur le port 9997.

Étape 4 : Construire le Domaine Active Directory

C’est le cœur de l’infrastructure “entreprise”.

1. Promotion du Serveur : Sur ADDC01, j’ai installé le rôle “Active Directory Domain Services” et l’ai promu en contrôleur de domaine pour une nouvelle “forêt” nommée mydfir.local.
2. Création des Utilisateurs : J’ai créé des unités organisationnelles (IT, HR) et des utilisateurs fictifs comme jsmith et tsmith.
3. Jonction de la Cible au Domaine : J’ai fait rejoindre Target-PC au domaine mydfir.local. Cela a nécessité un autre dépannage classique : j’ai dû configurer manuellement le serveur DNS de la machine cible pour qu’il pointe vers l’IP de mon contrôleur de domaine (192.168.10.7), sans quoi elle ne pouvait pas le trouver.

Une fois Target-PC redémarrée, j’ai pu me connecter en tant que mydfir\jsmith. Le domaine était fonctionnel !

Le contrôleur de domaine est prêt, affichant le domaine mydfir avant le nom d’utilisateur.

Étape 5 : L’Attaque et la Détection

Le moment tant attendu.

1. Préparation de l’Attaque : Sur Kali, j’ai installé Crowbar, un outil de brute force. J’ai préparé une petite liste de mots de passe contenant le mot de passe correct (Password13). J’ai aussi activé le Bureau à Distance (RDP) sur Target-PC pour les utilisateurs du domaine.
2. Lancement de l’Attaque Brute Force RDP :

   crowbar -b rdp -u tsmith -C passwords.txt -s 192.168.10.100/32
   

3. Observation dans Splunk : Immédiatement, je me suis connecté à l’interface web de Splunk. Avec une simple recherche, j’ai pu voir la télémétrie de l’attaque. La requête index=endpoint EventCode=4624 (connexion réussie) a clairement affiché une connexion de l’utilisateur tsmith provenant de l’IP de ma machine Kali (192.168.10.250). La preuve de la détection était là.

Bilan et Prochaines Étapes

Ce projet a été une expérience d’apprentissage intense et incroyablement gratifiante. J’ai non seulement acquis des compétences pratiques en configuration AD, Splunk et Sysmon, mais j’ai surtout appris à diagnostiquer et résoudre les problèmes de réseau et de configuration qui surviennent inévitablement dans un environnement complexe.

J’ai également testé le framework Atomic Red Team pour simuler des techniques d’attaque plus subtiles. Bien que je n’aie pas réussi à voir les traces de ces tests spécifiques dans Splunk (un défi pour une prochaine fois !), l’exercice m’a familiarisé avec la méthodologie MITRE ATT&CK.

Ce laboratoire est désormais une base solide pour de futures explorations : affiner les règles de détection, intégrer d’autres outils de sécurité, et continuer à explorer la mentalité de l’attaquant pour mieux devenir un défenseur.