Déploiement d'un SOC avec ELK Stack

Contexte du projet

Dans le cadre d’un cours de SOC, l’objectif était de concevoir et déployer un Security Operations Center opérationnel à partir d’une étude de cas réelle. Le projet couvrait l’ensemble de la chaîne : architecture réseau, choix et déploiement du SIEM, intégration de règles de détection, et démonstration live d’une attaque avec remédiation.

Sujet imposé : Décrire le processus de gestion des incidents, construire une infrastructure mixte Windows/Linux protégée par un firewall, implémenter des indicateurs de détection d’attaques APT, définir des KPI, et présenter une démonstration de détection en conditions réelles.

Choix technologique : pourquoi ELK ?

Étude de l’existant

Avant de choisir notre stack, nous avons comparé les principales solutions SIEM disponibles en open source :

Solution	Avantages	Inconvénients
ELK Stack	Très répandu, docs abondante, scalable, UI riche	Consommation RAM élevée
Splunk	Puissant, intuitif	Coût en production, limites gratuites
Wazuh	Clé en main, SIEM+EDR	Moins flexible pour customisation
Graylog	Léger, simple	Moins d’intégrations natives

Notre choix : ELK Stack (Elasticsearch + Logstash + Kibana) pour plusieurs raisons :

Standard de facto en entreprise — compétence directement valorisable
Écosystème de règles de détection open source très actif (Sigma, Elastic Detection Rules)
Déploiement Docker rapide, idéal pour l’environnement de cours
Interface Kibana permettant des tableaux de bord avancés sans développement supplémentaire

Déploiement via Docker

Pour gagner en rapidité et reproductibilité, nous avons opté pour le déploiement Docker officiel d’Elastic :

# Clonage du dépôt officiel
git clone https://github.com/deviantony/docker-elk.git
cd docker-elk

# Configuration des mots de passe et paramètres
cp .env.example .env
# Ajustement des variables : ELASTIC_VERSION, ELASTIC_PASSWORD, etc.

# Lancement de la stack complète
docker-compose up -d

# Vérification des conteneurs
docker-compose ps
# elasticsearch   Up   9200/tcp, 9300/tcp
# logstash        Up   5044/tcp, 9600/tcp
# kibana          Up   0.0.0.0:5601->5601/tcp

Les agents de collecte ont été déployés sur chaque machine de l’infrastructure :

Winlogbeat sur Windows 10 et Windows Server 2019 — collecte des Event Logs
Filebeat sur Debian — collecte des logs système et auth
OPNsense configuré pour exporter les logs syslog vers Logstash

Architecture réseau

L’infrastructure déployée reproduit un environnement d’entreprise réaliste composé de quatre machines interconnectées derrière un firewall OPNsense.

                        INTERNET
                            │
                     ┌──────────────┐
                     │   OPNsense   │  ← Firewall / Routeur
                     │  (pfSense)   │    IDS/IPS activé
                     └──────┬───────┘
                            │
              ┌─────────────┼─────────────┐
              │             │             │
     ┌────────────┐  ┌─────────────┐  ┌──────────────┐
     │ Windows 10 │  │  Win Server │  │  Debian GNU/ │
     │   Client   │  │    2019     │  │    Linux     │
     │            │  │  (AD, DNS)  │  │  (ELK Stack) │
     └────────────┘  └─────────────┘  └──────────────┘
          │                │                  │
          └────────────────┴──────────────────┘
                    LAN — 192.168.10.0/24

    Flux de logs : ──────────────────────────→ Logstash :5044

Machines de l’infrastructure

Machine	OS	Rôle	IP
Firewall	OPNsense	Filtrage, IDS/IPS, syslog	192.168.10.1
Client	Windows 10 Pro	Poste utilisateur (cible des attaques)	192.168.10.10
Serveur	Windows Server 2019	Active Directory, DNS, DHCP	192.168.10.20
SIEM	Debian 12	ELK Stack via Docker	192.168.10.30

Intégration des règles de détection open source

Pour maximiser la couverture de détection dès le déploiement, nous avons intégré les règles disponibles publiquement :

Sources utilisées

Elastic Detection Rules (dépôt officiel Elastic) — ~1 000+ règles couvrant MITRE ATT&CK
Sigma Rules (SigmaHQ) — règles converties au format Elastic via sigma-cli
Règles custom développées pendant le projet pour les techniques APT ciblées

# Conversion Sigma → Elastic Query Language (EQL)
pip install sigma-cli
sigma convert -t eql -p ecs_windows rules/windows/process_creation/ \
  -o elastic_rules.ndjson

# Import via API Elastic
curl -X POST "localhost:5601/api/detection_engine/rules/_import" \
  -H "kbn-xsrf: true" -H "Content-Type: multipart/form-data" \
  --form "file=@elastic_rules.ndjson"

Catégories de règles activées

Exécution de processus suspects (LOLBAS, PowerShell obfusqué)
Mouvements latéraux (Pass-the-Hash, Pass-the-Ticket)
Credential dumping (LSASS access, SAM dump)
Persistance (Run keys, tâches planifiées, services)
Élévation de privilèges (Token impersonation, UAC bypass)
Exfiltration réseau (beacon C2, DNS tunneling)

Processus de gestion des incidents

Notre processus s’articule autour du cycle Préparer → Détecter → Contenir → Éradiquer → Rétablir → Améliorer, inspiré du NIST SP 800-61.

┌─────────────┐    Alerte     ┌──────────────┐   Triage   ┌──────────────┐
│  Détection  │ ───────────→  │ Qualification │ ─────────→ │  Confinement │
│  (Kibana)   │               │  (Analyste)   │            │  (Isolation) │
└─────────────┘               └──────────────┘            └──────┬───────┘
                                                                  │
┌─────────────┐               ┌──────────────┐                   │
│  Clôture &  │ ←───────────  │  Éradication │ ←─────────────────┘
│  Rapport    │               │ & Rétabliss. │
└─────────────┘               └──────────────┘

Niveaux de priorité des alertes :

🔴 Critique — Réponse immédiate (< 15 min) : credential dumping, ransomware
🟠 Haute — Traitement sous 1h : élévation de privilèges, mouvements latéraux
🟡 Moyenne — Traitement sous 4h : scan réseau, tentatives de connexion
🟢 Basse — Revue quotidienne : anomalies comportementales mineures

Démonstration : Détection de Mimikatz

Mimikatz est l’outil de référence pour le vol de credentials Windows. Nous l’avons utilisé selon trois techniques différentes, chacune déclenchant des alertes spécifiques dans ELK, avec une remédiation adaptée.

Technique 1 — Exécution directe (sekurlsa::logonpasswords)

Principe : Mimikatz accède directement à la mémoire du processus LSASS pour extraire les hachages de mots de passe en clair.

# Attaquant sur Windows 10 (admin local)
.\mimikatz.exe
privilege::debug
sekurlsa::logonpasswords

Détection dans ELK :

L’alerte se déclenche sur deux événements combinés :

Event ID 4688 — Création du processus mimikatz.exe
Event ID 10 (Sysmon) — Accès à lsass.exe avec GrantedAccess 0x1010

{
  "rule": "Credential Dumping - LSASS Memory Access",
  "severity": "critical",
  "process.name": "mimikatz.exe",
  "target.process.name": "lsass.exe",
  "winlog.event_data.GrantedAccess": "0x1010"
}

Remédiation :

Activer LSA Protection (RunAsPPL) : HKLM\SYSTEM\CurrentControlSet\Control\Lsa → RunAsPPL = 1
Déployer Credential Guard via GPO (Windows 10/Server 2016+)
Isoler immédiatement la machine compromise
Réinitialiser tous les comptes dont les credentials ont été exposés (dont le compte krbtgt)

Technique 2 — Via un handle de processus (lsass handle)

Principe : Au lieu d’ouvrir LSASS directement, l’attaquant duplique un handle existant depuis un processus ayant déjà accès à LSASS — contournant certaines protections basiques.

# Identification du handle LSASS via un processus privilégié
.\mimikatz.exe
privilege::debug
sekurlsa::logonpasswords   # via handle dupliqué depuis un autre processus

Détection dans ELK :

Cette technique est détectée via Sysmon Event ID 10 avec des flags d’accès inhabituels sur LSASS depuis un processus inattendu, couplé à Event ID 4656 (demande d’handle sur un objet).

{
  "rule": "Suspicious Handle to LSASS Process",
  "severity": "critical",
  "event.code": "10",
  "winlog.event_data.TargetImage": "*lsass.exe",
  "winlog.event_data.GrantedAccess": ["0x1010", "0x1410", "0x147a"]
}

Remédiation :

Mettre en place des règles Sysmon restrictives bloquant les handles LSASS non autorisés
Utiliser Windows Defender Credential Guard pour virtualiser LSASS (vLSASS)
Surveiller les processus ayant des droits SeDebugPrivilege via les Event ID 4672
Déployer un EDR capable de bloquer les accès LSASS suspects en temps réel (ex: Microsoft Defender for Endpoint)

Technique 3 — Dump mémoire via comsvcs.dll (LOLBAS)

Principe : Technique dite “LOLBAS” (Living Off the Land Binaries) — utilise un binaire Windows légitime (comsvcs.dll) pour dumper la mémoire de LSASS sans toucher à mimikatz.exe directement.

# Dump de la mémoire LSASS via rundll32 (binaire Windows natif)
$lsass = Get-Process lsass
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump `
  $lsass.Id C:\Windows\Temp\lsass.dmp full

# Lecture du dump avec mimikatz sur une autre machine
.\mimikatz.exe
sekurlsa::minidump C:\lsass.dmp
sekurlsa::logonpasswords

Détection dans ELK :

Plus difficile à détecter car utilise rundll32.exe (binaire légitime). La détection repose sur la corrélation :

Event ID 4688 — rundll32.exe avec arguments comsvcs.dll + MiniDump
Event ID 11 (Sysmon) — Création d’un fichier .dmp dans un répertoire temp
Event ID 3 (Sysmon) — Connexion réseau éventuelle pour exfiltration du dump

{
  "rule": "LOLBAS - LSASS Dump via comsvcs.dll",
  "severity": "critical",
  "process.name": "rundll32.exe",
  "process.command_line": "*comsvcs*MiniDump*lsass*"
}

Remédiation :

Bloquer via AppLocker / WDAC l’exécution de rundll32.exe avec des arguments inhabituels
Surveiller la création de fichiers .dmp en dehors des répertoires d’application légitimes
Activer les règles ASR (Attack Surface Reduction) de Windows Defender
Restreindre l’accès en écriture aux répertoires C:\Windows\Temp pour les comptes non-administrateurs

Indicateurs de détection APT

Pour détecter les TTPs (Tactiques, Techniques et Procédures) des groupes APT, nous avons mis en place les indicateurs suivants, alignés sur le framework MITRE ATT&CK :

Technique MITRE	Indicateur	Seuil d’alerte
T1003.001 — LSASS Memory	Accès LSASS avec GrantedAccess ≥ 0x1010	1 occurrence
T1059.001 — PowerShell	Encodage Base64 dans les arguments PS	1 occurrence
T1021.002 — SMB/Windows Admin Shares	Connexions successives C$ ou ADMIN$	> 3 en 5 min
T1078 — Valid Accounts	Connexions en dehors des heures ouvrées	Hors 8h-20h
T1071.001 — C2 over HTTP	Beacon régulier vers IP externe (jitter < 10%)	Pattern détecté
T1136 — Create Account	Création de compte admin en dehors des processus RH	1 occurrence
T1110 — Brute Force	Échecs d’authentification répétés	> 10 en 1 min

KPI du SOC

#	KPI	Objectif	Méthode de mesure
1	MTTD (Mean Time To Detect)	< 5 min	Temps entre l’événement et l’alerte Kibana
2	MTTR (Mean Time To Respond)	< 30 min	Temps entre l’alerte et le confinement
3	Taux de faux positifs	< 10%	Alertes qualifiées bénignes / total alertes
4	Couverture MITRE ATT&CK	> 60% des techniques	Règles actives / techniques du framework
5	Disponibilité du SIEM	> 99,5%	Uptime Elasticsearch + Kibana

Axes d’amélioration

Suite au projet, plusieurs pistes ont été identifiées pour faire évoluer l’infrastructure :

Déploiement d’un SOAR (ex: TheHive + Cortex) pour automatiser la réponse aux incidents et réduire le MTTR
Ajout d’un honeypot (Cowrie, OpenCanary) pour la détection précoce des scans et mouvements latéraux
Enrichissement des alertes avec des flux CTI (MISP, OTX) pour qualifier automatiquement les IOC détectés
Intégration NDR via Zeek/Suricata pour la détection réseau en complément des logs endpoint
Mise en place d’un UEBA pour détecter les comportements anormaux basés sur des baselines utilisateurs
Automatisation des playbooks de réponse via Elastic SIEM’s case management + scripts Python

Outils utilisés

Catégorie	Outil	Usage
SIEM	Elasticsearch + Kibana	Indexation, recherche, dashboards
Collecte	Logstash, Winlogbeat, Filebeat	Ingestion des logs
Virtualisation	Docker + docker-compose	Déploiement simplifié
Réseau	OPNsense	Firewall, IDS, export syslog
Endpoint monitoring	Sysmon	Télémétrie avancée Windows
Attaque (démo)	Mimikatz	Credential dumping
Règles	Sigma, Elastic Detection Rules	Base de détection open source
Framework	MITRE ATT&CK	Référentiel TTPs

Ce projet a été réalisé dans un cadre pédagogique — l’environnement était isolé du réseau de production. Les techniques d’attaque présentées sont utilisées uniquement à des fins de démonstration et de validation des mécanismes de détection.