Back to blog
Jun 10, 2024
5 min read

1er Home Lab : Active Directory & Splunk

Mise en place d'un laboratoire virtuel simulant un réseau d'entreprise avec Active Directory, Splunk et Kali Linux pour maîtriser la gestion des logs, la détection d'intrusions et la configuration d'un domaine AD.

Dans le cadre de mon apprentissage en administration système et cybersécurité, j’ai créé un laboratoire virtuel sous VirtualBox pour simuler un réseau d’entreprise avec Active Directory, une machine cible Windows 10, un serveur Splunk et une machine d’attaque Kali Linux. Ce projet m’a permis de maîtriser des concepts clés comme la gestion des logs, la détection d’intrusions et la configuration d’un domaine AD. Voici un récapitulatif détaillé de mes étapes, défis et solutions.

Screenshot - VM ADDC01 connectée

Étape 1 : Architecture du Projet

J’ai conçu un réseau virtuel avec 4 machines :

MachineRôleOSIP
ADDC01Contrôleur de domaine (AD)Windows Server 2022192.168.10.7
Target-PCMachine cibleWindows 10192.168.10.100
Splunk ServerSurveillance des logsUbuntu Server 22.04192.168.10.10
Kali LinuxAttaquant (penTests)Kali Linux192.168.10.250

Outils utilisés :

  • VirtualBox pour la virtualisation.
  • Sysmon (Microsoft) pour la journalisation des événements Windows.
  • Splunk pour l’analyse centralisée des logs.
  • Crowbar (Kali) pour les attaques Brute Force.
  • Atomic Red Team pour simuler des attaques MITRE ATT&CK.

Étape 2 : Configuration du Serveur Splunk

Problème : Adresse IP dynamique. Initialement, le serveur Splunk (Ubuntu) utilisait DHCP, causant des changements d’IP imprévisibles.

Solution : Configuration d’une IP statique via Netplan.

# Fichier : /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    enp0s3:
      dhcp: no
      addresses: [192.168.10.10/24]
      gateway4: 192.168.10.1
      nameservers:
        addresses: [8.8.8.8]

Erreur rencontrée : J’ai eu un conflit avec cloud-init qui réinitialisait constamment la configuration réseau.

Mon correctif : Désactiver cloud-init pour la configuration réseau :

# Créer un fichier de configuration pour désactiver la gestion réseau de cloud-init
sudo nano /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

# Ajouter la ligne suivante dans le fichier :
network: {config: disabled}

# Supprimer l'ancienne configuration de cloud-init et appliquer la nouvelle
sudo rm /etc/netplan/50-cloud-init.yaml
sudo netplan apply

Une fois ce problème résolu, j’ai installé Splunk :

  1. Téléchargement de Splunk Enterprise (.deb) depuis le site officiel.
  2. Montage d’un dossier partagé VirtualBox pour transférer l’installeur.
  3. Installation et démarrage du service :
sudo dpkg -i splunk-9*.deb
sudo /opt/splunk/bin/splunk start --accept-licence
sudo /opt/splunk/bin/splunk enable boot-start -user splunk

Étape 3 : Déploiement de Sysmon et Splunk Universal Forwarder

Sur la machine cible (Target-PC) :

Sysmon :

  • Téléchargement de Sysmon et d’une configuration personnalisée (sysmonconfig.xml).
  • Installation via PowerShell (en tant qu’administrateur) :
.\Sysmon64.exe -i sysmonconfig.xml -accepteula
  • Objectif : Journaliser les processus, connexions réseau et modifications de fichiers.

Splunk Universal Forwarder :

  • C’est un outil léger pour envoyer les logs au serveur Splunk.
  • Configuration du fichier inputs.conf pour écouter les logs Sysmon :
[WinEventLog://Microsoft-Windows-Sysmon/Operational]
index = endpoint
disabled = false
renderXml = true
  • Les logs sont ensuite redirigés vers l’IP du serveur Splunk : 192.168.10.10:9997.

Étape 4 : Configuration d’Active Directory

  • Promotion du serveur en contrôleur de domaine : Installation du rôle AD Domain Services via le Server Manager et création d’une nouvelle forêt : mydfir.local.
  • Ajout d’utilisateurs : jsmith (IT) et tsmith (HR) avec le mot de passe Password13.
  • Jonction de la machine cible au domaine : Modification des paramètres DNS de Target-PC pour pointer vers l’IP du contrôleur de domaine (192.168.10.7) et jonction au domaine.

Étape 5 : Simulation d’Attaques et Surveillance

Attaque Brute Force avec Crowbar (Kali Linux)

  • Outil : Crowbar, spécialisé dans les attaques RDP/SSH.
  • Préparation : Création d’une liste de mots de passe (passwords.txt) incluant Password13.
  • Commande d’attaque :
crowbar -b rdp -u tsmith -C passwords.txt -s 192.168.10.100
  • Résultat dans Splunk : Une recherche index=endpoint EventCode=4624 a permis d’identifier les connexions réussies et l’IP de l’attaquant (192.168.10.250).

Tests avec Atomic Red Team

  • Outil : Framework pour simuler des attaques alignées sur MITRE ATT&CK.
  • Exemple (Création d’un compte local T1136.001) :
Invoke-AtomicTest T1136.001
  • Problème : Aucun log détecté dans Splunk pour cette simulation.

Conclusion et Compétences Acquises

Ce projet a été une plongée intensive dans la gestion d’un environnement réseau, mêlant configuration système, sécurité et analyse de logs.

Compétences Maîtrisées :

  • Configuration d’Active Directory et résolution de problèmes DNS.
  • Déploiement de Splunk pour la collecte centralisée des logs.
  • Utilisation de Sysmon pour tracer les activités suspectes.
  • Simulation d’une attaque Brute Force et détection via Splunk.
  • Administration de base Linux (Netplan) et Windows (PowerShell).

Défi Non Résolu : Malgré mes efforts, les attaques simulées via Atomic Red Team n’ont pas généré de logs détectables dans Splunk. Le problème pourrait venir d’une incompatibilité de configuration entre Sysmon et les règles de parsing de Splunk, ou de filtres d’index mal définis. Après deux jours de tentatives, j’ai décidé de marquer une pause et de garder ce défi comme objectif d’apprentissage futur.

Bilan et Perspectives : Ce projet illustre ma capacité à structurer un environnement complexe, à diagnostiquer des problèmes avec méthode, et à accepter mes limites actuelles tout en planifiant des améliorations futures.

Prochaines Étapes :

  • Revoir la configuration des parsers Splunk pour les logs Sysmon.
  • Étudier les bonnes pratiques de détection MITRE ATT&CK.
  • Intégrer Suricata pour la détection d’intrusions réseau (NIDS).
  • Expérimenter avec des SIEM alternatifs (ELK, Graylog).
  • Ajouter un honeypot pour capturer des tentatives d’intrusion.