Skip to main content

Playbook d'exécution

Ce document fournit les commandes concrètes, organisées par phase PTES. À dérouler une fois la machine d'attaque (Kali) en place. Horodater chaque test pour la corrélation Wazuh.

Avant de commencer
  • Tester uniquement sur l'infrastructure du projet.
  • Sauvegarder les bases avant les tests à risque.
  • Les tests offensifs lourds (brute force, fuzzing) restent cantonnés au Cyber Range.
  • Adapter toutes les IP aux valeurs réelles de l'infrastructure.

Préparation​

# Arborescence de campagne
mkdir -p ~/pentest_supersoc/{recon,scan,exploit,evidences}
cd ~/pentest_supersoc

# Journal horodaté
echo "=== Campagne pentest SuperSOC — début $(date) ===" > journal.md

# Variables (À ADAPTER)
export DOCKER_HOST_IP="10.0.20.10"
export RANGE_LAN="10.0.20.0/24"
export RANGE_CR="10.0.100.0/24"
export WAN_IP="192.168.1.28"      # IP WAN de pfSense

Phase 1 — Reconnaissance​

Objectif : découvrir les hôtes et services, sans exploitation.

# Découverte d'hôtes vivants (ping scan)
nmap -sn $RANGE_LAN -oA recon/hosts_lan

# Depuis l'extérieur : que voit-on de pfSense (WAN) ?
nmap -Pn -sV --top-ports 1000 $WAN_IP -oA recon/wan_pfsense
#  -Pn = ne pas pinguer d'abord (pfSense peut bloquer l'ICMP)
#  attendu : très peu de ports, idéalement seul WireGuard (UDP 51820)

# Scan UDP ciblé pour WireGuard
nmap -sU -p 51820 $WAN_IP -oA recon/wan_wireguard
Prédiction = scénario de test

Avant de lancer : note ce que tu t'attends à trouver. Sur le WAN, l'attendu est « rien sauf WireGuard ». Si c'est confirmé → preuve de bon durcissement. Si d'autres ports répondent → finding.

Phase 2 — Énumération / Scan​

Réseau interne (position « pied dans la place », depuis le Cyber Range)​

# Scan complet de l'hôte Docker (tous les ports + versions)
nmap -sV -sC -p- $DOCKER_HOST_IP -oA scan/dockerhost_full

# Test spécifique d'exposition des bases (NE DOIVENT PAS répondre)
nmap -p 3306,27017 $DOCKER_HOST_IP -oA scan/db_exposure
#  attendu : closed/filtered — les bases sont en réseau Docker internal

# Test de la segmentation : depuis le Cyber Range, atteint-on le VLAN admin ?
nmap -sn 10.0.10.0/24 -oA scan/segmentation_admin
#  attendu : bloqué par pfSense

Application web​

# Énumération serveur web + en-têtes de sécurité
nikto -h https://$DOCKER_HOST_IP -o scan/nikto_web.txt

# En-têtes de sécurité (CSP, HSTS, X-Frame-Options)
curl -sI https://$DOCKER_HOST_IP | tee scan/headers_web.txt

# Énumération de chemins/endpoints
gobuster dir -u https://$DOCKER_HOST_IP -w /usr/share/wordlists/dirb/common.txt \
  -k -o scan/gobuster_web.txt

Phase 3 — Exploitation (web/API)​

Outils principaux : Burp Suite et OWASP ZAP (proxy d'interception). À utiliser en mode manuel guidé.

Tests d'authentification / autorisation (API)​

# Endpoint protégé SANS token (doit échouer en 401)
curl -i https://$DOCKER_HOST_IP/api/tickets

# Avec un token expiré/invalide (doit échouer en 401)
curl -i -H "Authorization: Bearer faketoken" https://$DOCKER_HOST_IP/api/tickets

# Test RBAC : token d'un rôle faible sur une action d'admin (doit échouer en 403)
curl -i -H "Authorization: Bearer $TOKEN_JUNIOR" \
  -X DELETE https://$DOCKER_HOST_IP/api/users/1

Test anti-bruteforce​

# Tentatives de login répétées (sur Cyber Range / environnement de test)
for i in $(seq 1 10); do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST https://$DOCKER_HOST_IP/api/auth/login \
    -d '{"username":"admin","password":"wrong'$i'"}' \
    -H "Content-Type: application/json"
done
#  attendu : verrouillage du compte après N tentatives (passage en 423/429)

Scan OWASP ZAP automatisé​

# Scan baseline ZAP (passif + actif léger)
docker run --rm -v $(pwd):/zap/wrk/:rw \
  -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://$DOCKER_HOST_IP -r exploit/zap_report.html

Phase 4 — Validation défensive (Cyber Range)​

C'est la phase signature de ta soutenance : attaquer DVWA et vérifier la détection.

# Noter l'heure AVANT l'attaque pour corréler avec Wazuh
echo "Attaque SQLi DVWA — $(date)" >> journal.md

# Exemple : SQLi automatisée sur DVWA (cible volontairement vulnérable)
sqlmap -u "http://$RANGE_CR_DVWA/vulnerabilities/sqli/?id=1" \
  --cookie="PHPSESSID=...; security=low" --batch --dbs

# Brute force SSH sur une cible du range
hydra -l admin -P /usr/share/wordlists/rockyou.txt \
  ssh://10.0.100.20

Puis, côté défense :

  1. Ouvrir le dashboard Wazuh → vérifier que les alertes sont remontées.
  2. Ouvrir le SOAR → vérifier qu'un ticket a été créé, enrichi, et qu'un playbook s'est déclenché.
  3. Capturer les preuves (alerte + ticket) avec leur horodatage.
Le moment fort de l'oral

« J'ai lancé une injection SQL à 14h32 sur le Cyber Range. À 14h32, Wazuh a généré l'alerte X, mon SOAR a créé le ticket Y, enrichi l'IP via AbuseIPDB et déclenché le playbook de blocage. » — C'est la démonstration de bout en bout de ta solution.

Phase 5 — Reporting​

Pour chaque finding : remplir une fiche selon le modèle (voir « Modèle de fiche de vulnérabilité »), scorer en CVSS v3.1, recommander une correction, puis documenter la correction appliquée.

Compiler enfin :

  • la liste des findings classés par criticité ;
  • le tableau de corrélation attaques ↔ détections Wazuh ;
  • la synthèse des corrections.