36 modules, 191 briques et 322 labos, organisés par domaine. La brique est une unité d’apprentissage autonome : un apprenant peut la commander et la suivre seule, avec son ou ses labos pratiques. Chaque composant se commande à l’unité — de la brique au module jusqu’au parcours métier. Chaque module est détaillé par son syllabus.
Choisissez votre niveau de granularité — cliquez sur Brique ou Module.
Introduction aux concepts fondamentaux de la cyberdéfense et prise en main pratique des techniques de base sur le cyber-range.
Un rançongiciel chiffre les serveurs d'une PME un vendredi soir : que s'est-il passé, et qu'est-ce qui était réellement en jeu ? Pour répondre proprement, il faut un vocabulaire précis, celui que pose cette brique. Vous reliez actif, menace et vulnérabilité, puis le risque — un scénario potentiel pondéré par sa vraisemblance et son impact. Vous apprenez surtout à ne pas confondre le risque, qui s'anticipe, avec l'incident, qui en est la matérialisation, et à décrire un incident par les propriétés de sécurité qu'il atteint (confidentialité, intégrité, disponibilité). Vous commencez ainsi à parler le langage commun de la gestion du risque, celui qui rend une décision de sécurité défendable.
Objectif : Qualifier un incident selon CIA et les notions actif/menace/vulnérabilité/risque.
Notions : Confidentialité, Intégrité, Disponibilité, authenticité, non-répudiation · Actif, menace, vulnérabilité, risque · Panorama des menaces 2026
Défi : Classer un incident fourni (note de rançon+logs) par propriétés CIA violées.
Attendus : Validé si le classement CIA est correct, la matrice actif×menace cohérente et la cotation justifiée ; le flag atteste la bonne lecture de l'incident du défi.
Ouvrir une capture réseau pour la première fois, c'est faire face à des milliers de lignes en apparence indéchiffrables. Cette brique vous apprend à y mettre de l'ordre avec Wireshark : suivre une communication couche par couche (du modèle OSI au handshake TCP) et reconnaître ce qui sort de l'ordinaire — en gardant à l'esprit qu'une partie du trafic est chiffrée et ne livre que ses métadonnées (adresses, ports, volumétrie). Vous vous exercez sur une capture où se cache un balayage de ports (un scan qui teste les services ouverts), que vous devez isoler. Lire le trafic est l'un des gestes de base que vous réutiliserez aussi bien en défense qu'en analyse offensive.
Objectif : Lire une communication couche par couche et repérer un échange anormal.
Notions : 7 couches OSI / 4 TCP-IP · Encapsulation, ports, handshake TCP · DNS/DHCP
Défi : Retrouver l'IP qui scanne et le port ciblé dans la capture.
Attendus : Validé si le handshake est correctement annoté et si l'IP source du scan et le port ciblé sont retrouvés dans la capture (flag à l'appui).
Tester une technique de sécurité sur sa machine de travail, c'est risquer d'y faire des dégâts irréversibles ; on opère donc dans un environnement jetable, qu'on peut compromettre puis remettre à zéro. Avec Proxmox, vous déployez une machine virtuelle sur un réseau cloisonné et lui appliquez un premier durcissement. Vous manipulez trois notions qui reviendront partout : l'hyperviseur, le snapshot (un état sauvegardé auquel on peut revenir) et la segmentation réseau. Le défi tient en une preuve : montrer qu'aucun flux ne sort de la machine, sinon vers le serveur du laboratoire — la condition d'un banc d'essai réellement sûr.
Objectif : Créer une VM sur réseau isolé et appliquer un durcissement minimal.
Notions : Hyperviseur type 1/2, snapshots · Réseaux NAT/host-only/isolé · Durcissement de base
Défi : Prouver qu'aucune sortie réseau n'est possible sauf vers le serveur labo.
Attendus : Validé si la VM ne joint aucune destination hors du serveur labo et si l'instantané de référence existe ; la preuve d'isolement est attendue.
Combien de services une organisation laisse-t-elle visibles sur Internet sans le savoir ? Souvent bien plus qu'elle ne l'imagine. Avec Shodan et Censys, vous apprenez à dresser cette surface d'attaque externe à partir de données déjà collectées, sans émettre la moindre requête vers la cible : c'est de la reconnaissance passive. Vous lisez des bannières de service, affinez vos filtres et repérez ce qui ne devrait pas être accessible. Cette compétence sert d'abord à un défenseur pour auditer son propre périmètre — et elle éclaire, du même geste, ce qu'un attaquant verrait en premier.
Objectif : Découvrir l'exposition externe d'une organisation en sources ouvertes.
Notions : Empreinte externe, bannières · Filtres Shodan/Censys · Risque des plans d'admin exposés
Défi : Trouver le service d'administration exposé le plus critique.
Attendus : Validé si l'inventaire des services exposés est complet et si le service d'administration le plus critique est correctement désigné.
Une organisation peut disposer d'un pare-feu, d'un antivirus et de sauvegardes, et se faire paralyser malgré tout : des protections juxtaposées ne forment pas une défense si elles laissent des angles morts et se recouvrent ailleurs. Cette brique vous fait relier des mesures concrètes aux six fonctions du NIST CSF 2.0 — Gouverner, Identifier, Protéger, Détecter, Répondre, Rétablir — un référentiel répandu parmi d'autres (ISO 27001, cadres nationaux). Vous classez des contrôles selon leur rôle (préventif, détectif, correctif) et repérez la fonction la moins bien couverte. Vous repartez avec une grille de lecture réutilisable pour structurer une posture de sécurité.
Objectif : Relier des contrôles concrets aux 6 fonctions du NIST CSF 2.0.
Notions : Couches de défense · 6 fonctions CSF 2.0 (Govern…Recover) · Préventif/détectif/correctif
Défi : Classer 12 contrôles et nommer la fonction la plus faible.
Attendus : Validé si les douze contrôles sont bien rattachés aux six fonctions et si la fonction la plus faible est correctement identifiée.
Chiffrer un fichier, vérifier qu'il n'a pas été altéré, exiger un second facteur à la connexion : trois gestes du quotidien qui reposent tous sur la cryptographie appliquée. Vous chiffrez d'abord un fichier et contrôlez son intégrité par hachage avec OpenSSL, puis mettez en place une authentification forte. Vous clarifiez au passage deux distinctions souvent brouillées : chiffrement symétrique contre asymétrique, et hachage contre chiffrement. Point important : toutes les secondes authentifications ne se valent pas — vous déployez un facteur réellement résistant au phishing (FIDO2/passkeys), là où un simple code à usage unique peut être intercepté.
Objectif : Protéger un fichier et vérifier son intégrité.
Notions : Symétrique vs asymétrique · Hachage et intégrité · Bonnes pratiques de mots de passe
Défi : Donner le SHA-256 du fichier témoin et prouver l'altération.
Attendus : Validé si le fichier est chiffré et déchiffré sans perte, et si l'empreinte fournie prouve l'altération d'un octet.
Objectif : Mettre en place MFA et une politique de mots de passe robuste.
Notions : MFA, FIDO2/passkeys · Gestionnaire de mots de passe · Phishing d'identifiants
Défi : Prouver que la connexion exige un second facteur résistant au phishing.
Attendus : Validé si la reconnexion exige un second facteur résistant à l'hameçonnage, preuve à l'appui.
Un opérateur d'oléoduc américain interrompt sa distribution de carburant après une intrusion par rançongiciel entrée via un compte VPN dépourvu de double authentification.
Mission : Situer les grandes familles de menaces et expliquer comment un simple accès mal protégé devient la matérialisation d'un risque majeur pour une organisation et ses usagers.
Des centaines de milliers d'objets connectés laissés sous mot de passe d'usine sont enrôlés dans un réseau de machines compromises qui paralyse de grands services en ligne.
Mission : Découvrir la surface d'attaque grand public et mesurer l'effet d'échelle d'une hygiène faible sur la disponibilité de services tiers.
Exploration approfondie de Linux, de la ligne de commande au scripting Bash et au packaging Docker, socle technique du praticien.
Sur la plupart des serveurs et des conteneurs, il n'y a pas d'interface graphique : tout passe par la ligne de commande. Cette brique vous y rend autonome — système de fichiers, droits (lecture, écriture, exécution, et le bit SUID qui fait tourner un programme avec les privilèges de son propriétaire), comptes et groupes — puis vous fait traiter du texte avec grep, awk et sed. Vous inspectez une machine, débusquez un binaire SUID anormal (un chemin classique d'élévation de privilèges) et tirez l'information utile d'un journal volumineux. La ligne de commande devient alors un outil que vous dirigez, plutôt qu'une barrière.
Objectif : Inspecter un système Linux et ses droits en CLI.
Notions : FHS, rwx/SUID · Utilisateurs/groupes
Défi : Trouver le binaire SUID inhabituel.
Attendus : Validé si l'audit des binaires SUID est mené à terme et si le binaire anormal est correctement isolé.
Objectif : Manipuler des données avec grep/awk/sed.
Notions : Redirections, tubes · grep/awk/sed
Défi : Donner l'IP la plus fréquente du log fourni.
Attendus : Validé si la chaîne de filtres produit le bon comptage et si l'IP la plus fréquente est exacte.
Automatiser une tâche fait gagner du temps — jusqu'au jour où un script mal écrit efface ce qu'il devait sauvegarder. Cette brique vous apprend à écrire du Bash qui échoue proprement et se relance sans casse (l'idempotence), avec journalisation, puis à planifier des tâches récurrentes via cron et les timers systemd. Vous produisez un script de sauvegarde dont on peut vérifier le résultat, et prouvez qu'une tâche planifiée s'est bien déclenchée. Vous gagnez de quoi fiabiliser des opérations répétitives, de la sauvegarde à la collecte de traces.
Objectif : Écrire un script de sauvegarde fiable et idempotent.
Notions : set -euo pipefail · Journalisation, idempotence
Défi : Fournir un script produisant une archive vérifiable.
Attendus : Validé si le script produit une archive horodatée vérifiable par son empreinte, et s'exécute sans erreur en étant relancé.
Objectif : Planifier et superviser des tâches récurrentes.
Notions : Cron vs timers · Journaux d'exécution
Défi : Prouver le déclenchement du timer et sa journalisation.
Attendus : Validé si le minuteur se déclenche aux échéances prévues et si son exécution (et son échec) sont journalisés.
Deux questions d'administration en disent long sur la sécurité d'une machine : qu'est-ce qui s'y exécute, et d'où vient ce qu'on y a installé ? Cette brique vous fait diagnostiquer processus et services avec systemd et journalctl, puis gérer paquets et dépôts (APT/dpkg) en vérifiant leurs signatures. Vous repérez un service activé à votre insu — une forme de persistance d'un attaquant — et un paquet non signé, porte d'entrée possible d'une compromission par la chaîne d'approvisionnement. Vous savez dès lors établir l'état réel d'un système et tracer la provenance de ses logiciels.
Objectif : Diagnostiquer processus et services.
Notions : Processus, signaux · systemd/journalctl
Défi : Donner le service malveillant activé sur la VM.
Attendus : Validé si le diagnostic distingue le service malveillant du reste et le nomme correctement.
Objectif : Empaqueter et gérer des dépendances proprement.
Notions : APT/dpkg · Dépôts et signatures
Défi : Donner le paquet non signé détecté.
Attendus : Validé si la vérification de signature est menée et si le paquet non signé est correctement identifié.
Une machine fraîchement installée écoute souvent sur plus de ports qu'il n'en faut, et chaque port ouvert est une porte de plus. Cette brique vous fait configurer l'adressage et le routage sous Linux (Netplan), puis restreindre les connexions entrantes avec UFW, au-dessus de nftables. L'objectif est net : ne laisser que SSH accessible depuis le sous-réseau du laboratoire, et le prouver. Vous savez alors ramener l'exposition réseau d'une machine au strict nécessaire.
Objectif : Configurer adressage, routage et UFW.
Notions : Netplan/ip, routes · nftables/UFW deny
Défi : N'exposer que SSH au sous-réseau labo et le prouver.
Attendus : Validé si seul SSH est joignable depuis le sous-réseau labo, la vérification par ss/tcpdump faisant foi.
On croit souvent qu'un conteneur est étanche par nature ; en réalité, sa sécurité dépend de la façon dont on construit son image et dont on l'exécute. Cette brique vous fait bâtir une image Docker durcie — qui ne tourne pas en administrateur (non-root) et dont le système de fichiers est en lecture seule — en comprenant ses couches successives et les mécanismes d'isolation du noyau (namespaces, cgroups). Vous l'analysez avec Trivy et la livrez sans vulnérabilité critique connue. Vous savez produire un conteneur qui resserre la surface d'attaque au lieu de l'élargir.
Objectif : Construire une image non-root, lecture seule.
Notions : Images/couches, Dockerfile · Namespaces/cgroups, limites
Défi : Livrer une image sans CVE haute (rapport Trivy).
Attendus : Validé si l'image tourne en non-root, en lecture seule, et si le rapport Trivy ne montre aucune vulnérabilité de criticité haute.
Une porte dérobée est introduite par un contributeur dans une bibliothèque de compression présente sur la plupart des distributions Linux, visant le démon SSH.
Mission : Comprendre l'écosystème des paquets et des dépendances open source, et lire un arbre de processus pour repérer un comportement anormal au démarrage d'un service.
Un acteur étatique se maintient dans des réseaux d'infrastructure en n'utilisant que des outils système légitimes, sans déposer de logiciel malveillant détectable.
Mission : Identifier des commandes système courantes détournées de leur usage et acquérir les premiers réflexes de lecture de journaux sous Linux.
Une banque voit plus de cent millions de dossiers exfiltrés après l'abus d'un rôle technique trop permissif sur une instance hébergée.
Mission : Se familiariser avec l'isolation, les comptes de service et la séparation des privilèges entre instances et conteneurs.
Bases techniques de la cybersécurité par l'exploration des réseaux ; pose les fondations d'une spécialisation en forensique, défense avancée et tests d'intrusion.
Avant toute action sur un réseau, il faut savoir ce qu'on y trouve : quelles machines, quels ports, quels services. Cette brique vous fait dresser cette carte avec Nmap — en réglant les types de balayage, leur rythme et la détection de versions — puis énumérer des services Windows (partages SMB, annuaire LDAP) depuis Linux. Vous reliez la version d'un service à une vulnérabilité connue (CVE) et repérez un partage ouvert en accès anonyme (sans authentification). C'est l'inventaire que dresse un testeur d'intrusion comme un défenseur soucieux de connaître son propre périmètre.
Objectif : Cartographier hôtes, ports et services.
Notions : Scans SYN/connect/UDP, timing · Détection OS/versions
Défi : Identifier le service vulnérable par sa version et son CVE.
Attendus : Validé si la cartographie est complète et si le service vulnérable est relié à la bonne version et au bon CVE.
Objectif : Énumérer des services Windows depuis Linux.
Notions : Partages SMB, sessions nulles · LDAP/annuaire
Défi : Donner le partage SMB accessible en lecture anonyme.
Attendus : Validé si l'énumération SMB/LDAP est menée et si le partage lisible en anonyme est correctement identifié.
La même capture réseau peut rester illisible ou tout révéler, selon qu'on la garde brute ou qu'on la transforme en journaux structurés. Cette brique vous fait franchir ce pas avec Zeek, qui convertit un trafic en logs exploitables (connexions, DNS, HTTP, TLS) que l'on compare à une activité de référence. Vous y détectez un serveur de commande-et-contrôle à son trafic régulier et répétitif (le beaconing), et extrayez un identifiant transitant en clair. Vous apprenez à séparer le signal du bruit — un geste central en détection comme en investigation réseau.
Objectif : Transformer une capture en journaux exploitables.
Notions : Logs conn/dns/http/ssl · Baseline vs écart
Défi : Donner le domaine de C2 identifié par beaconing.
Attendus : Validé si les journaux Zeek sont produits et si le domaine de commande et contrôle est isolé par son beaconing.
Objectif : Décoder des protocoles applicatifs courants.
Notions : HTTP/FTP/DNS en clair · Extraction d'identifiants
Défi : Donner l'identifiant FTP capturé en clair.
Attendus : Validé si la session FTP est isolée dans la capture et si l'identifiant transmis en clair est correctement extrait.
Pour détecter une attaque réseau, encore faut-il savoir à quoi elle ressemble de l'intérieur. Cette brique vous fait pratiquer, en environnement contrôlé, l'empoisonnement du cache ARP — qui permet de s'intercaler dans une communication (l'attaque de l'intercepteur, ou homme-du-milieu) — puis des techniques d'évasion qui cherchent à passer sous le radar d'une sonde de détection (fragmentation, leurres, jeu sur le rythme). À chaque fois, l'objectif reste la détection : retrouver l'adresse de l'attaquant, identifier la technique qui a échappé à la sonde. Vous mesurez ce que les défenses de périmètre arrêtent, et ce qui les contourne.
Objectif : Comprendre et détecter l'empoisonnement ARP.
Notions : ARP, spoofing, MiTM · Détection par table ARP
Défi : Donner la MAC de l'attaquant détecté.
Attendus : Validé si l'attaque de l'homme du milieu est mise en place et détectée, et si la MAC de l'attaquant est correctement relevée.
Objectif : Comprendre les techniques d'évasion de détection.
Notions : Fragmentation, leurres, timing · Empreinte IDS
Défi : Donner la technique d'évasion qui a échappé à l'IDS.
Attendus : Validé si la comparaison des techniques est documentée et si celle ayant échappé à l'IDS est correctement nommée.
Lancer un scanner de vulnérabilités est facile ; en tirer des décisions justes l'est moins, car il signale aussi des problèmes qui n'en sont pas (les faux positifs). Cette brique vous fait conduire une évaluation avec OpenVAS, hiérarchiser par le score de gravité CVSS, valider ce qui est réellement exploitable, puis enclencher la boucle de durcissement : corriger, re-scanner, mesurer l'écart. Vous isolez la vulnérabilité avérée la plus critique et réduisez la surface d'attaque jusqu'à un seul port, preuve à l'appui. Vous bouclez ainsi le cycle qui structure tout travail de remédiation : évaluer, corriger, vérifier.
Objectif : Identifier et trier des vulnérabilités réseau.
Notions : CVSS, faux positifs · Validation
Défi : Donner la vulnérabilité validée la plus critique.
Attendus : Validé si les faux positifs sont écartés et si la vulnérabilité validée la plus critique est correctement désignée.
Objectif : Corriger les faiblesses trouvées et re-scanner.
Notions : Surface d'attaque · Boucle scan→corrige→re-scan
Défi : Réduire la surface à un seul port et fournir le diff.
Attendus : Validé si la surface est réduite à un seul port et si le différentiel avant/après est fourni.
Un opérateur télécom australien voit les données de près de dix millions de clients extraites via une interface applicative accessible sans authentification, aux identifiants incrémentaux.
Mission : Découvrir le balayage, l'énumération et le risque des identifiants prévisibles, à un niveau d'initiation.
Une faille critique dans une bibliothèque de journalisation très répandue déclenche un balayage massif d'Internet à la recherche de cibles vulnérables.
Mission : Comprendre la cartographie de la surface exposée et l'urgence d'un inventaire à jour des composants logiciels.
Plusieurs fournisseurs d'énergie sont visés le même jour via des pare-feux exposés sur Internet, avec un risque direct sur la fourniture d'électricité.
Mission : Relier l'exposition réseau d'un équipement périmétrique à une conséquence concrète pour des usagers.
Une passerelle VPN d'entreprise très déployée est exploitée par l'enchaînement de deux failles, ouvrant un accès à distance.
Mission : Saisir la notion de service de périmètre exposé et le principe d'un enchaînement de vulnérabilités.
Des routeurs de petits bureaux et de particuliers, arrivés en fin de vie et non mis à jour, sont compromis pour masquer une activité d'espionnage.
Mission : Apprendre à recenser les équipements réseau oubliés (informatique fantôme) et à comprendre le risque qu'ils portent.
Mise en œuvre correcte du chiffrement, des signatures et de TLS/SSH, et anticipation de l'enjeu post-quantique.
Chiffrer une donnée ne suffit pas si l'on choisit mal le mode de chiffrement : une image chiffrée en mode ECB laisse encore deviner son contenu. Cette brique vous fait manipuler le chiffrement symétrique avec OpenSSL — modes ECB, CBC, GCM, vecteur d'initialisation (IV), remplissage (padding) — et démontrer concrètement la fuite du mode ECB. Vous garantissez ensuite l'intégrité et l'authenticité d'un message par hachage et HMAC (un code d'authentification de message fondé sur une clé secrète). Vous savez désormais non seulement chiffrer, mais le faire correctement, et prouver qu'un message n'a pas été modifié.
Objectif : Chiffrer correctement en symétrique et démontrer la fuite ECB.
Notions : Modes ECB/CBC/GCM, IV · Padding
Défi : Expliquer la fuite ECB et donner le mode correct.
Attendus : Validé si la fuite ECB est démontrée visuellement et si le mode sûr (GCM) est correctement justifié.
Objectif : Garantir l'intégrité et l'authenticité d'un message.
Notions : SHA-2/3, collisions · HMAC, sel
Défi : Donner le HMAC du fichier témoin.
Attendus : Validé si l'altération est détectée et si le HMAC du fichier témoin est exact.
Comment deux machines qui ne se sont jamais parlé établissent-elles un secret commun sur un réseau ouvert ? C'est tout l'objet de la cryptographie asymétrique. Cette brique vous fait manipuler les couples de clés RSA et à courbes elliptiques (ECC) ainsi que l'échange Diffie-Hellman, puis émettre un certificat et signer un document via une infrastructure à clés publiques (PKI). Vous reliez signature numérique et non-répudiation — la garantie qu'un signataire ne peut nier son acte. Vous comprenez ce qui fait fonctionner, sous le capot, le cadenas de votre navigateur comme la signature d'un contrat.
Objectif : Manipuler clés asymétriques et Diffie-Hellman.
Notions : RSA/ECC · Diffie-Hellman
Défi : Donner l'empreinte de la clé publique générée.
Attendus : Validé si l'échange DH aboutit au même secret des deux côtés et si l'empreinte de la clé publique est correcte.
Objectif : Émettre un certificat et signer un document.
Notions : PKI, CA, révocation · Signature/non-répudiation
Défi : Fournir le certificat signé et l'empreinte de signature.
Attendus : Validé si le certificat est émis par la CA du labo et si la signature se vérifie via la chaîne de confiance.
Un service chiffré peut rester vulnérable s'il accepte encore de vieilles options : le chiffrement ne vaut que par sa configuration. Cette brique vous fait déployer et auditer TLS 1.3 — suites cryptographiques, en-tête HSTS qui force le HTTPS — avec testssl.sh, puis durcir un accès SSH selon l'état de l'art. Vous débusquez une suite cryptographique obsolète sur un service piège et prouvez qu'un accès SSH par mot de passe est bien refusé au profit des clés. Vous savez auditer et resserrer la configuration des deux protocoles qui sécurisent l'essentiel des accès distants.
Objectif : Configurer et auditer TLS.
Notions : Handshake TLS 1.3, suites · HSTS
Défi : Donner la suite obsolète détectée sur le service piège.
Attendus : Validé si l'audit est mené et si la suite ou version obsolète du service piège est correctement identifiée.
Objectif : Sécuriser un accès SSH selon l'état de l'art.
Notions : Clés vs mot de passe · Algorithmes modernes
Défi : Prouver que l'auth par mot de passe est refusée.
Attendus : Validé si l'accès par clé fonctionne et si l'authentification par mot de passe est effectivement refusée.
La cryptographie se casse rarement en attaquant les algorithmes eux-mêmes, mais en exploitant la façon dont on les emploie. Cette brique vous fait d'abord retrouver un mot de passe protégé par un hachage faible (non salé) et tirer parti d'une réutilisation de vecteur d'initialisation — les erreurs de mise en œuvre les plus courantes. Elle vous fait ensuite anticiper la menace quantique et la stratégie « récolter maintenant, déchiffrer plus tard » (HNDL), en identifiant les usages à migrer vers les algorithmes post-quantiques (ML-KEM, ML-DSA). Vous repartez capable de repérer une crypto mal employée et de préparer une transition qui concerne déjà les données à longue durée de vie.
Objectif : Repérer et exploiter une crypto mal employée.
Notions : Réutilisation d'IV · Hachage non salé
Défi : Récupérer le mot de passe protégé par hash faible.
Attendus : Validé si le mot de passe est récupéré et si la faiblesse (hachage non salé ou IV réutilisé) est expliquée.
Objectif : Anticiper la migration PQC et gérer les clés.
Notions : Menace quantique, HNDL · ML-KEM/ML-DSA
Défi : Lister les 2 usages prioritaires à migrer et l'algo cible.
Attendus : Validé si l'inventaire est priorisé et si les deux usages à migrer et l'algorithme cible sont correctement désignés.
Une faiblesse de conception du protocole SSH permet, par troncature de préfixe, d'affaiblir la négociation chiffrée d'une session sans alerter les parties.
Mission : Analyser un défaut au niveau d'un protocole cryptographique et raisonner sur l'intégrité de la négociation de session plutôt que sur la seule robustesse de l'algorithme.
Un acteur obtient une clé de signature de comptes Microsoft et forgé des jetons d'authentification pour accéder à des messageries, dont celles d'administrations.
Mission : Comprendre les enjeux de gestion des clés et mesurer l'effet d'une compromission de clé de signature sur toute une chaîne d'authentification.
Conception d'un réseau segmenté et durci, déploiement d'IDS/IPS et introduction au Zero Trust.
Un réseau à plat laisse un intrus se déplacer librement une fois entré ; le segmenter, c'est compartimenter pour contenir. Cette brique vous fait découper un réseau (VLAN, zone démilitarisée — DMZ, micro-segmentation) et appliquer un filtrage par liste blanche — tout est refusé par défaut, on n'autorise que le nécessaire — avec pfSense. Le défi est concret : prouver que la zone d'administration est isolée du reste. Vous savez concevoir un cloisonnement qui limite la propagation d'une compromission au lieu de la faciliter.
Objectif : Segmenter un réseau et filtrer par liste blanche.
Notions : VLAN, DMZ, micro-segmentation · Deny par défaut
Défi : Prouver l'isolation de la zone de gestion.
Attendus : Validé si les flux inter-zones sont en liste blanche et si l'isolation de la zone de gestion est prouvée.
Un système livré « par défaut » est rarement un système sûr : il expose des services et des réglages dont on n'a pas besoin. Cette brique vous fait appliquer des référentiels de durcissement reconnus — les benchmarks CIS sous Linux, les stratégies de groupe (GPO) sous Windows — et mesurer l'écart avant/après. Vous faites progresser un score CIS au-dessus d'un seuil et identifiez le réglage GPO qui bloque une attaque témoin. Vous savez réduire méthodiquement la surface d'exposition d'un parc, en vous appuyant sur des standards plutôt que sur l'intuition.
Objectif : Appliquer un benchmark CIS et mesurer l'écart.
Notions : Benchmarks CIS · Surface de services
Défi : Faire passer le score CIS au-dessus du seuil.
Attendus : Validé si cinq écarts sont corrigés et si le score CIS dépasse le seuil après re-mesure.
Objectif : Sécuriser des postes Windows via stratégies.
Notions : GPO, baselines · Comptes/services
Défi : Donner le paramètre GPO bloquant l'attaque témoin.
Attendus : Validé si la baseline est appliquée et si le paramètre GPO bloquant l'attaque est correctement identifié.
Détecter une intrusion suppose une sonde qui sait quoi chercher — et qui ne crie pas au loup à tout bout de champ. Cette brique vous fait déployer un système de détection et de prévention d'intrusion (IDS/IPS) avec Suricata, en distinguant détection par signature et par anomalie, et en composant avec les faux positifs. Vous écrivez une règle qui repère un user-agent piège dans le trafic. Vous savez mettre en place une détection réseau utile, dont le bruit reste contenu.
Objectif : Déployer une détection et écrire une règle.
Notions : Signature vs anomalie · Faux positifs
Défi : Fournir la règle détectant le user-agent piège.
Attendus : Validé si la règle personnalisée se déclenche sur le user-agent piège sans faux positif évident.
Et si, plutôt que d'attendre l'alerte, on tendait un piège qui ne se déclenche que pour un intrus ? C'est le principe des leurres. Cette brique vous fait déployer un honeypot (un faux service destiné à appâter l'attaquant) avec Cowrie et des honeytokens (des appâts — fichier, identifiant — dont tout accès est par nature suspect). Le défi : capturer l'accès à un honeytoken, horodatage et adresse à l'appui. Vous ajoutez à votre dispositif une détection précoce et peu bruyante, là où un accès illégitime se trahit de lui-même.
Objectif : Détecter par leurres.
Notions : Honeypots, canaris · Détection précoce
Défi : Capturer l'accès au honeytoken (horodatage+IP).
Attendus : Validé si l'accès au honeytoken est capturé avec son horodatage et l'IP source.
« Ne jamais faire confiance, toujours vérifier » : le modèle Zero Trust renverse l'idée d'un réseau interne sûr par nature. Cette brique en pose les bases à partir du cadre NIST 800-207 — points de décision et d'application des politiques (PDP/PEP), identité érigée en périmètre — et vous fait esquisser une politique d'accès. Le défi : démontrer un refus d'accès conforme lorsqu'une requête sort de son contexte autorisé. Vous saisissez le déplacement de fond qu'opère le Zero Trust, dont vous approfondirez la mise en œuvre côté identité plus loin dans le cursus.
Objectif : Esquisser une politique d'accès Zero Trust.
Notions : NIST 800-207, PEP/PDP · Identité comme périmètre
Défi : Prouver un refus d'accès hors contexte conforme.
Attendus : Validé si la politique autorise l'accès en contexte et refuse l'accès hors contexte, trace à l'appui.
Le sans-fil étend le réseau au-delà des murs — et avec lui, la surface d'attaque. Cette brique vous fait évaluer la sécurité d'un accès Wi-Fi (WPA2/3, authentification EAP) et repérer un point d'accès pirate (rogue AP) avec aircrack-ng, puis contrôler les flux sortants via un proxy filtrant (Squid). Vous identifiez le SSID d'un faux point d'accès et prouvez le blocage d'un domaine de commande-et-contrôle connu. Vous couvrez les deux faces d'un accès : l'entrée sans fil et la sortie vers Internet.
Objectif : Évaluer la sécurité d'un accès sans fil.
Notions : WPA2/3, EAP · Rogue AP
Défi : Donner le SSID du point d'accès pirate détecté.
Attendus : Validé si la robustesse est évaluée et si le SSID du point d'accès pirate est correctement identifié.
Objectif : Contrôler les flux sortants par proxy.
Notions : Proxy, filtrage URL · Inspection
Défi : Prouver le blocage d'un domaine de C2 connu.
Attendus : Validé si le proxy journalise les accès et si le domaine de C2 est effectivement bloqué.
Des énergéticiens danois sont compromis via une exécution de code à distance sur des pare-feux exposés, sur le service de négociation IKE.
Mission : Durcir des pare-feux de périmètre, fermer les services exposés inutiles et segmenter pour contenir une intrusion.
Une fuite de mémoire sur des passerelles d'accès permet de récupérer des jetons de session et de contourner l'authentification multifacteur.
Mission : Mettre en place le durcissement des passerelles, la gestion des sessions et une politique de correctifs sur les équipements exposés.
Une chaîne de deux failles sur des appliances VPN très déployées ouvre un accès distant persistant.
Mission : Segmenter et surveiller les appliances de périmètre, et anticiper le scénario d'une appliance de confiance compromise.
Des routeurs de petits bureaux non maintenus servent de relais à un acteur étatique.
Mission : Gérer le cycle de vie des équipements réseau, retirer les matériels obsolètes et durcir les configurations par défaut.
Un acteur progresse dans des réseaux d'infrastructure en s'appuyant sur des outils légitimes, sans logiciel malveillant.
Mission : Concevoir une segmentation interne qui limite le déplacement latéral et réduit la portée d'une compromission initiale.
Opérer un SOC de niveau 1 : collecte, corrélation, alerte, triage et premières réponses automatisées.
Un SOC ne vaut que par les journaux qu'il reçoit : sans la bonne source, l'attaque reste invisible. Cette brique vous fait concevoir la collecte de logs d'un centre opérationnel de sécurité (SOC) — sources endpoint, réseau, cloud, et les rôles N1/N2/N3 — puis normaliser des journaux hétérogènes vers un schéma commun (ECS). Vous identifiez la source manquante qui empêche de voir une exfiltration et retrouvez un champ normalisé après traitement. Vous posez les fondations sans lesquelles toute détection ultérieure serait aveugle.
Objectif : Concevoir la collecte de journaux.
Notions : Rôles N1/N2/N3, MTTD/MTTR · Sources endpoint/réseau/cloud
Défi : Lister la source absente empêchant de détecter une exfiltration.
Attendus : Validé si l'ingestion fonctionne et si la source manquante critique est correctement identifiée.
Objectif : Normaliser des logs hétérogènes (ECS).
Notions : Parsing, ECS · Horodatage/fuseaux
Défi : Donner le champ ECS de l'IP source après normalisation.
Attendus : Validé si le journal est mappé sur ECS et si le champ ECS de l'IP source est correct.
Des millions d'événements ne servent à rien si l'on ne sait pas les interroger et les recouper. Cette brique vous fait pivoter dans un SIEM (le système central qui agrège et analyse les journaux) avec le langage de requête KQL, corréler des événements sur une fenêtre temporelle, puis bâtir tableaux de bord et règles d'alerte. Vous démasquez le compte visé par une attaque en pulvérisation de mots de passe (password spraying) et rédigez une alerte sur dix échecs d'authentification en une minute. Vous transformez une masse de logs en signaux exploitables par un analyste.
Objectif : Interroger le SIEM et corréler des événements.
Notions : KQL/EQL, pivots · Fenêtre temporelle
Défi : Identifier le compte victime de password spraying et l'IP.
Attendus : Validé si la corrélation établit le password spraying et si le compte victime et l'IP sont corrects.
Objectif : Construire dashboards et règles d'alerte.
Notions : Indicateurs SOC · Seuils d'alerte
Défi : Fournir la règle d'alerte sur 10 échecs en 1 min.
Attendus : Validé si le tableau de bord est opérationnel et si la règle d'alerte dix échecs/minute se déclenche correctement.
Le réseau ne montre pas tout ; ce qui s'exécute sur la machine, lui, ne ment pas. Cette brique vous fait exploiter la télémétrie d'un poste via Sysmon et la logique d'un EDR (la solution de détection et de réponse sur les terminaux) : arbre de processus, créations de fichiers, connexions (événements Sysmon 1, 3, 11). Vous remontez la filiation d'un processus jusqu'au parent qui a lancé la charge malveillante, empreinte à l'appui. Vous savez lire l'histoire d'une compromission telle que la raconte la machine elle-même.
Objectif : Comprendre la télémétrie endpoint.
Notions : Arbre de processus · Sysmon 1/3/11
Défi : Donner le parent qui a lancé la charge et son hash.
Attendus : Validé si l'arbre de processus est reconstitué et si le parent et le hachage de la charge sont corrects.
Un analyste de SOC reçoit plus d'alertes qu'il ne peut en traiter : savoir lesquelles méritent une réaction est le cœur du métier. Cette brique vous fait trier des alertes selon un playbook (une procédure de décision documentée) avec TheHive — évaluer la sévérité, écarter les faux positifs, décider d'escalader ou non. Le défi : prononcer une décision de triage et l'action de confinement associée. Vous gagnez la méthode qui distingue un SOC efficace d'un SOC noyé sous le bruit.
Objectif : Trier selon un playbook et décider l'escalade.
Notions : Sévérité, FP · Critères d'escalade
Défi : Donner la décision de triage et l'action de confinement.
Attendus : Validé si le playbook est suivi et si la décision de triage et l'action de confinement sont justifiées.
Le hameçonnage (phishing) reste l'une des principales portes d'entrée des attaques — et il laisse des traces, dans le courriel comme sur le réseau. Cette brique vous fait disséquer un e-mail malveillant : en-têtes, mécanismes anti-usurpation SPF/DKIM/DMARC, URL et pièces jointes, pour démasquer l'expéditeur usurpé et l'adresse de hameçonnage. Elle vous fait ensuite repérer, côté trafic, le domaine de commande-et-contrôle contacté après l'ouverture. Vous reliez ainsi les deux bouts d'une attaque par courriel : le leurre reçu et l'activité réseau qu'il déclenche.
Objectif : Analyser un e-mail malveillant.
Notions : En-têtes, SPF/DKIM/DMARC · URL/pièce jointe
Défi : Donner l'expéditeur usurpé et l'URL de phishing.
Attendus : Validé si l'usurpation est démontrée par les en-têtes et si l'expéditeur usurpé et l'URL sont corrects.
Objectif : Exploiter la télémétrie réseau dans le SIEM.
Notions : Logs Zeek · Beaconing/exfiltration
Défi : Donner le domaine de C2 détecté côté SOC.
Attendus : Validé si le beaconing est isolé et si le domaine de C2 est correctement identifié dans le SIEM.
À mesure que les alertes se multiplient, l'humain ne peut plus tout traiter à la main : il faut automatiser ce qui peut l'être. Cette brique vous fait construire une réponse automatisée avec un outil SOAR (orchestration, automatisation et réponse de sécurité) — Shuffle — qui enrichit puis isole sur la base d'un indicateur de compromission (IOC). Elle vous fait ensuite mesurer la performance du SOC (délais de détection et de réaction, taux de faux positifs) et la réduire par réglage fin. Vous reliez automatisation et amélioration continue, deux leviers pour tenir la charge sans sacrifier la qualité.
Objectif : Automatiser une action de réponse simple.
Notions : Playbooks SOAR · Enrichissement auto
Défi : Fournir le playbook qui enrichit et isole sur IOC.
Attendus : Validé si le playbook enrichit l'IP et déclenche l'isolement sur indicateur.
Objectif : Mesurer la performance et réduire le bruit.
Notions : MTTD/MTTR, FP rate · Tuning
Défi : Donner la réduction de FP obtenue après tuning.
Attendus : Validé si la règle est affinée sans perte de détection et si la réduction de faux positifs est chiffrée.
L'exploitation d'une bibliothèque de journalisation génère des requêtes sortantes vers des serveurs contrôles par l'attaquant.
Mission : Écrire des règles de détection pour l'exploitation JNDI/LDAP et trier le bruit d'un balayage massif.
Une injection SQL inédite sur un outil de transfert de fichiers permet de déposer un webshell et d'exfiltrer des données chez des milliers d'organisations.
Mission : Détecter la trace d'un webshell dans les journaux d'un serveur web et bâtir l'alerte associée.
Un accès au système de support d'un fournisseur d'identité exposé des fichiers de session de clients.
Mission : Corréler des connexions anormales et exploiter les journaux d'authentification pour repérer un abus de session.
Des espaces clients d'une plateforme de données sont pillés via des identifiants dérobés par logiciels voleurs, en l'absence d'authentification multifacteur.
Mission : Construire des détections sur les connexions improbables (voyage impossible, géographie, horaires) au-dessus d'un SIEM.
Des accès à des messageries cloud sont obtenus à l'aide de jetons d'authentification forgés.
Mission : Analyser des journaux d'accès cloud pour repérer l'usage de jetons illégitimes et instrumenter l'alerte.
Chasse proactive aux menaces, réponse à incident et amélioration continue de la détection.
Au-delà de la détection de base, l'analyste expert assemble sa propre plateforme et traque des persistances que les outils standards laissent passer. Cette brique vous fait déployer une chaîne de détection complète avec Security Onion (Wazuh, Sysmon, Elastic) puis chasser une persistance par abonnement d'événements WMI — un mécanisme Windows légitime détourné pour survivre aux redémarrages. Vous désignez l'hôte le plus suspect et le nom de l'abonnement WMI malveillant. Vous montez d'un cran : de la détection outillée à la chasse fondée sur une télémétrie riche.
Objectif : Déployer une stack de détection complète.
Notions : Security Onion · Sysmon avancé
Défi : Donner l'hôte le plus suspect et la raison.
Attendus : Validé si la stack ingère la télémétrie et si l'hôte le plus suspect est correctement désigné avec sa raison.
Objectif : Chasser une persistance avancée.
Notions : WMI event subscription · Télémétrie riche
Défi : Donner le nom de l'abonnement WMI malveillant.
Attendus : Validé si les abonnements WMI sont énumérés et si l'abonnement malveillant est correctement nommé.
Chasser au hasard épuise sans rien trouver ; partir des techniques connues des attaquants change tout. Cette brique vous fait pratiquer la défense informée par la menace : traduire une technique du référentiel MITRE ATT&CK en requête de recherche, formuler une hypothèse, puis la confirmer ou l'infirmer par les données. Vous documentez une boucle de chasse complète et apportez la preuve d'une technique ATT&CK avérée. Vous adoptez la démarche structurée qui distingue le threat hunting d'une simple exploration.
Objectif : Tester des hypothèses mappées ATT&CK.
Notions : Threat-informed defense · TTP→requête
Défi : Donner la technique ATT&CK confirmée et sa preuve.
Attendus : Validé si les hypothèses sont traduites en requêtes et si la technique ATT&CK confirmée est étayée par une preuve.
Objectif : Mener une chasse structurée de bout en bout.
Notions : Boucle de chasse · Documentation
Défi : Donner le résultat de la chasse (confirmé/infirmé) et la preuve.
Attendus : Validé si la chasse est documentée et conclut clairement (confirmé/infirmé) avec preuve.
Un attaquant entré sur un poste cherche aussitôt à rebondir vers d'autres machines : repérer ce mouvement latéral, c'est l'arrêter avant qu'il n'atteigne ses cibles. Cette brique vous fait détecter les techniques de rebond — réutilisation d'empreinte d'authentification (pass-the-hash), exécution à distance via WMI/WinRM, usage de comptes privilégiés — dans la télémétrie Sysmon. Vous reliez les deux hôtes qu'un même mouvement latéral connecte. Vous savez suivre, pas à pas, la progression d'un intrus à travers un parc.
Objectif : Détecter pass-the-hash et usage d'admin.
Notions : PtH, WMI/WinRM · Comptes privilégiés
Défi : Donner les 2 hôtes reliés par le mouvement latéral.
Attendus : Validé si l'usage anormal est détecté et si les deux hôtes reliés par le mouvement latéral sont corrects.
Une règle de détection écrite pour un seul outil disparaît avec lui ; exprimée dans un format portable et versionnée, elle se partage et se maintient. Cette brique vous fait écrire des règles au format Sigma — un standard ouvert traduisible vers différents moteurs (backends) — et les gérer comme du code, sous Git. Le défi : produire une règle Sigma dont le taux de faux positifs reste sous 5 %. Vous appliquez à la détection les pratiques de l'ingénierie logicielle : portabilité, versionnement, revue.
Objectif : Écrire des règles portables versionnées.
Notions : Sigma, backends · FP, Git
Défi : Fournir la règle Sigma avec FP<5%.
Attendus : Validé si la règle Sigma est versionnée, convertie et testée avec un taux de faux positifs inférieur à 5 %.
Quand l'incident est là, l'improvisation coûte cher : la réponse suit un cycle éprouvé. Cette brique vous fait conduire les phases d'une réponse à incident selon le cadre NIST 800-61 — de la préservation des preuves au confinement — puis investiguer à l'échelle d'un parc entier avec Velociraptor. Vous identifiez le point d'entrée et la première action de confinement, puis dénombrez les hôtes touchés par un indicateur que vous chassez sur toute la flotte. Vous savez mener une réponse méthodique, du premier signal à la mesure de l'étendue.
Objectif : Conduire les phases d'un incident NIST 800-61.
Notions : Cycle IR · Préservation preuves
Défi : Donner le point d'entrée et la 1re action de confinement.
Attendus : Validé si le cycle IR est suivi et si le point d'entrée et la première action de confinement sont corrects.
Objectif : Collecter et chasser à l'échelle de la flotte.
Notions : Artefacts, hunts · Collecte à distance
Défi : Donner le nombre d'hôtes touchés par l'IOC chassé.
Attendus : Validé si le hunt couvre la flotte et si le nombre d'hôtes touchés par l'IOC est exact.
Les canaux de commande-et-contrôle modernes se cachent : ils espacent et brouillent leurs communications pour se fondre dans le trafic normal. Cette brique vous fait détecter ces C2 malgré leurs ruses — variation des intervalles (jitter), empreintes de poignée de main TLS (JA3) — avec Zeek et RITA, puis valider votre couverture par une approche purple : on rejoue des techniques d'attaque atomiques et l'on mesure ce qui passe inaperçu. Vous démasquez un C2 malgré son jitter et identifiez une technique exécutée mais non détectée. Vous bouclez le cercle vertueux détection → validation → correction.
Objectif : Détecter des C2 modernes (JA3, jitter).
Notions : JA3/JA3S · Jitter, sleep
Défi : Donner le C2 détecté malgré le jitter.
Attendus : Validé si le beaconing est isolé malgré le jitter et si le C2 est correctement identifié.
Objectif : Mesurer la couverture par émulation.
Notions : Émulation atomique · Couverture/lacune
Défi : Donner la technique exécutée non détectée.
Attendus : Validé si la couverture est cartographiée et si la technique non détectée est correctement désignée.
Un acteur étatique persiste dans des infrastructures critiques en n'utilisant que des outils système, échappant aux antivirus.
Mission : Formuler des hypothèses de chasse sur des techniques de vie sur le terrain et les vérifier dans la télémétrie.
Un acteur obtient un accès administrateur en se faisant passer, par téléphone, pour un employé auprès d'un centre d'assistance, puis contourne l'authentification multifacteur.
Mission : Traquer les abus d'identité et le déplacement latéral consécutifs à une compromission de compte privilégié.
L'exploitation de l'outil de transfert touche des milliers d'organisations en quelques jours.
Mission : Mener une chasse sur indicateurs de compromission à l'échelle d'un parc et prioriser les hôtes affectés.
Des jetons de session volés permettent de rejouer des sessions authentifiées après l'exploitation des passerelles.
Mission : Chasser les signes de détournement de session post-exploitation et reconstruire la fenêtre d'accès.
Un acteur reste plusieurs jours dans le réseau d'un acteur de la santé avant de déclencher le rançongiciel, après une entrée sur un accès sans double authentification.
Mission : Détecter la fenêtre de déplacement latéral entre l'accès initial et l'impact, avant la matérialisation du risque.
Collecte de renseignement en sources ouvertes de façon sûre et son opérationnalisation pour la défense.
Enquêter sur une cible en sources ouvertes peut, par maladresse, prévenir cette cible qu'on l'observe. Cette brique vous apprend à collecter sans vous exposer ni laisser de traces : identités d'enquête cloisonnées (sock puppets), routage par Tor et VPN, et surtout la traque des fuites qui trahissent votre vraie adresse (DNS, WebRTC). Le défi : prouver votre adresse de sortie et l'absence de fuite. Vous posez l'hygiène de base sans laquelle une investigation OSINT se retourne contre l'enquêteur.
Objectif : Collecter sans s'exposer ni alerter la cible.
Notions : Sock puppets, cloisonnement · Fuites DNS/WebRTC
Défi : Donner l'IP de sortie et prouver l'absence de fuite.
Attendus : Validé si la collecte ne fuit pas (DNS/WebRTC) et si l'IP de sortie est correctement relevée.
Avant d'attaquer ou de défendre, on dessine la carte : quels domaines, serveurs, adresses et personnes une organisation laisse-t-elle visibles ? Cette brique vous fait construire cette empreinte numérique sous forme de graphe d'entités avec Maltego et SpiderFoot, puis cartographier l'infrastructure technique (DNS, certificats, numéros de systèmes autonomes — ASN, sous-domaines). Vous débusquez un sous-domaine d'administration oublié, une adresse exposée, un environnement de pré-production accessible. C'est l'inventaire externe qu'un défenseur doit dresser avant qu'un attaquant ne le fasse à sa place.
Objectif : Cartographier l'empreinte numérique d'une cible.
Notions : Graphes d'entités, transforms · Fiabilité des sources
Défi : Donner le sous-domaine d'admin oublié et l'e-mail exposé.
Attendus : Validé si l'empreinte est cartographiée et si le sous-domaine d'admin et l'e-mail exposé sont corrects.
Objectif : Cartographier l'infra technique d'une cible.
Notions : DNS, certificats · ASN, sous-domaines
Défi : Donner le sous-domaine de pré-production exposé.
Attendus : Validé si l'infrastructure est cartographiée et si le sous-domaine de pré-production exposé est correct.
Une personne laisse, sans y penser, une traînée d'indices à travers ses comptes, ses photos et ses publications. Cette brique vous fait profiler une cible humaine — légalement et de façon documentée — en recoupant son empreinte sociale avec Sherlock, puis en exploitant les métadonnées d'images (données EXIF) et les indices visuels pour la géolocaliser. Vous retrouvez un pseudonyme réutilisé sur trois plateformes et extrayez les coordonnées GPS d'une photo. Côté défense, c'est mesurer ce qu'un attaquant peut apprendre de vos collaborateurs avant une attaque ciblée.
Objectif : Profiler une cible humaine légalement.
Notions : Empreinte sociale · Recoupement
Défi : Donner le pseudo réutilisé sur 3 plateformes.
Attendus : Validé si les comptes sont recoupés et si le pseudo réutilisé sur trois plateformes est correct.
Objectif : Exploiter métadonnées et indices visuels.
Notions : EXIF · Géo-indices
Défi : Donner les coordonnées GPS extraites de l'image.
Attendus : Validé si les métadonnées sont exploitées et si les coordonnées GPS extraites sont correctes.
Quand des identifiants fuitent, ils circulent souvent sur des forums et des marchés avant que la victime ne s'en aperçoive. Cette brique vous apprend à surveiller cette exposition — fuites de données, places de marché clandestines — et à comprendre le risque qu'elle alimente : le bourrage d'identifiants (credential stuffing), où des mots de passe volés ailleurs sont rejoués chez vous. Le défi : dénombrer les comptes fuités d'une organisation et identifier le plus sensible. Vous transformez une rumeur de fuite en évaluation concrète du risque pour les comptes concernés.
Objectif : Surveiller l'exposition sur fuites/darknet.
Notions : Marchés/forums · Credential stuffing
Défi : Donner le nombre de comptes fuités et le plus sensible.
Attendus : Validé si l'exposition est mesurée et si le nombre de comptes fuités et le plus sensible sont corrects.
Une collecte manuelle prend une photo à un instant donné ; ce qui compte en surveillance, c'est de voir ce qui change. Cette brique vous fait scripter une collecte OSINT récurrente — gestion des API et de leur débit, déduplication des résultats — puis outiller une collecte spécifique en Bash. Vous produisez un script qui signale l'apparition d'un nouveau sous-domaine et consolidez un résultat exploitable. Vous passez de l'enquête ponctuelle à une veille continue de la surface exposée.
Objectif : Scripter une collecte récurrente.
Notions : API, débit · Déduplication
Défi : Fournir le script détectant un nouveau sous-domaine.
Attendus : Validé si le script collecte, dédoublonne et détecte un nouveau sous-domaine.
Objectif : Outiller une collecte spécifique.
Notions : Scraping léger · Parsing
Défi : Fournir l'outil et le résultat consolidé.
Attendus : Validé si l'outil Bash collecte, parse et exporte un résultat consolidé.
Collecter du renseignement ne sert à rien s'il ne débouche pas sur une décision : la valeur est dans l'action qu'il déclenche. Cette brique vous fait transformer une collecte OSINT en mesures défensives concrètes — distinguer le renseignement actionnable du simple bruit, et prioriser. Le défi : désigner, parmi les expositions découvertes, celle qu'il faut corriger en premier. Vous bouclez la chaîne qui va de l'information brute à la réduction effective du risque.
Objectif : Transformer l'OSINT en actions défensives.
Notions : Renseignement actionnable · Priorisation
Défi : Donner l'exposition prioritaire à corriger.
Attendus : Validé si les trouvailles sont priorisées et si l'exposition prioritaire à corriger est correctement désignée.
Les accès aux espaces clients proviennent d'identifiants captés par des logiciels voleurs et diffusés sur des marchés clandestins.
Mission : Pister en sources ouvertes la circulation d'identifiants volés liés à une organisation et en évaluer l'exposition.
L'acteur identifie un employé via un réseau professionnel pour usurper son identité auprès du support.
Mission : Cartographier l'empreinte publique d'une organisation et les informations exploitables en ingénierie sociale.
Un vol de crypto-actifs de très grande ampleur est attribué à un groupe étatique, via la compromission d'un poste de développement.
Mission : Profiler un acteur à partir de sources ouvertes et d'indicateurs publics, et documenter ses modes opératoires.
Une opération internationale démantèle l'infrastructure d'un des groupes de rançongiciel les plus actifs.
Mission : Collecter du renseignement en sources ouvertes sur un écosystème criminel (affiliés, infrastructure, fuites).
Les données de millions de clients sont mises en vente après l'exploitation d'une API exposée.
Mission : Évaluer l'exposition d'identités en sources ouvertes à la suite d'une fuite et en mesurer les conséquences pour les personnes.
Investigation d'une intrusion à partir du trafic réseau et reconstitution de l'activité de l'attaquant.
Une capture réseau contient parfois, dispersés en milliers de paquets, des fichiers entiers qu'il suffit de recoller. Cette brique vous fait reconstituer des échanges à partir d'une capture — réassemblage des flux TCP, extraction des fichiers transitant sur le réseau (carving réseau) — avec NetworkMiner. Le défi : extraire le fichier exfiltré et en donner le nom et l'empreinte. Vous savez faire parler une capture pour retrouver, concrètement, ce qui est sorti du réseau.
Objectif : Reconstituer des échanges depuis une capture.
Notions : Reassemblage TCP · Carving réseau
Défi : Extraire le fichier exfiltré (nom + hash).
Attendus : Validé si le flux est réassemblé et si le fichier exfiltré (nom et empreinte) est correctement extrait.
Beaucoup pensent qu'un trafic chiffré est opaque à l'analyse : c'est faux, ses métadonnées en disent beaucoup. Cette brique vous fait détecter sans déchiffrer — empreintes de poignée de main TLS (JA3), exfiltration cachée dans des requêtes DNS — avec Zeek, puis investiguer via les journaux de pare-feu et de proxy. Vous identifiez un domaine d'exfiltration DNS et l'adresse interne qui contacte un serveur de commande-et-contrôle. Vous apprenez à lire ce que le chiffrement ne masque pas.
Objectif : Détecter sans déchiffrer.
Notions : Métadonnées TLS, JA3 · Exfiltration DNS
Défi : Donner le domaine d'exfiltration DNS.
Attendus : Validé si le beaconing TLS est repéré sans déchiffrement et si le domaine d'exfiltration DNS est correct.
Objectif : Investiguer via les journaux réseau.
Notions : Logs proxy/firewall · Corrélation
Défi : Donner l'IP interne contactant le C2.
Attendus : Validé si les journaux sont corrélés et si l'IP interne contactant le C2 est correcte.
Une investigation ne s'arrête pas au constat : ce qu'on découvre sur une attaque doit devenir une détection pour la prochaine. Cette brique vous fait franchir ce pas — partir d'un cas observé pour en tirer un indicateur Zeek, puis écrire une signature Snort ciblée. Le défi : produire l'indicateur qui caractérise l'attaque et la règle qui détecte son C2. Vous transformez le travail d'enquête en capacité de détection durable, du cas particulier à la règle réutilisable.
Objectif : Transformer une capture en détections.
Notions : Logs Zeek, scripts · Du cas à la règle
Défi : Donner l'indicateur Zeek caractérisant l'attaque.
Attendus : Validé si les journaux Zeek sont produits et si l'indicateur caractéristique est correctement isolé.
Objectif : Écrire des signatures réseau.
Notions : Règles Snort · Test
Défi : Fournir la règle Snort détectant le C2.
Attendus : Validé si la règle Snort détecte le C2 sans faux positif évident.
Un réseau ne charrie pas que des fichiers : il porte aussi des conversations et des canaux de fuite discrets. Cette brique vous fait reconstituer des communications applicatives, dont la voix sur IP (VoIP), à partir d'une capture, puis caractériser une exfiltration de données — par quel canal, quel volume, avec quelle discrétion. Vous restituez le contenu d'une communication et quantifiez le volume sorti par un canal détourné. Vous mesurez ce qu'une fuite emporte réellement, au-delà du simple constat qu'elle a eu lieu.
Objectif : Reconstituer des communications applicatives.
Notions : VoIP/HTTP · Reconstruction
Défi : Donner le contenu reconstitué de la communication.
Attendus : Validé si la communication applicative est reconstituée et si le contenu est correct.
Objectif : Quantifier et caractériser une exfiltration.
Notions : Volume, canaux · Discrétion
Défi : Donner le canal et le volume exfiltré.
Attendus : Validé si le canal d'exfiltration est identifié et si le volume estimé est cohérent.
Une preuve isolée se conteste ; recoupée avec d'autres sources, elle devient une démonstration. Cette brique vous fait croiser réseau, poste de travail et journaux pour établir une chronologie solide, puis restituer l'investigation pour deux publics distincts — le SOC et la direction. Vous datez l'heure de compromission par recoupement et livrez une liste d'indicateurs réseau (adresses, domaines, empreintes JA3). Vous transformez des traces éparses en un récit d'incident étayé et communicable.
Objectif : Croiser réseau, endpoint et logs.
Notions : Corrélation · Frise
Défi : Donner l'heure de compromission corrélée.
Attendus : Validé si réseau et endpoint sont corrélés et si l'heure de compromission est correcte.
Objectif : Restituer pour SOC et management.
Notions : Preuves réseau · IOC
Défi : Livrer la liste d'IOC réseau (IP/domaine/JA3).
Attendus : Validé si la chaîne est synthétisée et si la liste d'IOC réseau (IP, domaine, JA3) est exploitable.
L'exploitation de pare-feux passe par le service IKE, observable dans les flux réseau.
Mission : Analyser des captures réseau pour caractériser une exploitation de périmètre et ses suites.
L'acteur tunnelise son activité à travers des équipements légitimes pour se fondre dans le trafic.
Mission : Détecter, dans les flux, des tunnels et des comportements de vie sur le terrain difficiles à distinguer du trafic normal.
L'exploitation déclenche une connexion sortante LDAP/JNDI vers l'attaquant.
Mission : Repérer dans une capture le rappel sortant caractéristique de l'exploitation et le qualifier.
Les données sont extraites au travers de l'application web de transfert compromise.
Mission : Tracer l'exfiltration de données dans les flux applicatifs et en estimer le volume.
Des routeurs compromis échangent avec une infrastructure de commande masquée.
Mission : Analyser le trafic de commande d'équipements de périphérie compromis pour les isoler.
Production de renseignement cyber structuré et son opérationnalisation pour la détection et la décision.
Un programme de renseignement qui collecte sans cap se noie dans la donnée : tout part des questions que l'on cherche à éclairer. Cette brique vous fait cadrer un programme de Cyber Threat Intelligence (CTI) par ses besoins prioritaires de renseignement (PIR) — ces questions décisionnelles qui orientent toute la collecte — et distinguer les niveaux stratégique, opérationnel et tactique. Le défi : formuler des PIR priorisés et identifier la source du plus critique. Vous ancrez la production de renseignement dans la décision qu'elle doit servir, plutôt que dans l'accumulation.
Objectif : Cadrer un programme CTI par les besoins.
Notions : Cycle CTI · Niveaux strat/op/tac
Défi : Fournir les PIR priorisés et la source du plus critique.
Attendus : Validé si trois PIR sont priorisés et si la source du PIR le plus critique est correctement associée.
Analyser une intrusion à l'instinct mène aux conclusions hâtives ; des modèles éprouvés disciplinent le raisonnement. Cette brique vous fait structurer l'analyse avec le modèle du Diamant — adversaire, capacité, infrastructure, victime, et les pivots qui les relient — en confrontant des hypothèses concurrentes, puis replacer l'attaque sur la Cyber Kill Chain pour décider où l'interrompre. Vous identifiez un pivot d'infrastructure partagé entre intrusions et l'étape de la chaîne où stopper l'attaque au moindre coût. Vous gagnez des cadres qui rendent une analyse reproductible et défendable.
Objectif : Structurer l'analyse d'une intrusion.
Notions : Diamant, pivots · Hypothèses concurrentes
Défi : Donner le pivot d'infrastructure partagé.
Attendus : Validé si l'intrusion est modélisée et si le pivot d'infrastructure partagé est correctement identifié.
Objectif : Replacer une attaque sur la Kill Chain.
Notions : Kill Chain · Mapping TTP
Défi : Donner l'étape de la Kill Chain où stopper l'attaque.
Attendus : Validé si l'attaque est replacée sur la Kill Chain et si l'étape d'arrêt optimale est justifiée.
Un renseignement gardé pour soi protège une seule organisation ; partagé dans un format commun, il défend toute une communauté. Cette brique vous fait normaliser et échanger du renseignement avec les standards STIX 2.1 (la structure des objets) et TAXII (leur transport), puis enrichir et qualifier des indicateurs par un score de fiabilité. Vous produisez un paquet STIX décrivant cinq techniques d'attaque et désignez l'indicateur le plus fiable. Vous inscrivez votre travail dans l'écosystème de partage qui fait la force du renseignement cyber.
Objectif : Normaliser et partager le renseignement.
Notions : STIX 2.1, objets · TAXII
Défi : Fournir le bundle STIX avec 5 TTP mappées.
Attendus : Validé si le bundle STIX est partagé via MISP avec cinq TTP correctement mappées.
Objectif : Enrichir et qualifier des indicateurs.
Notions : IOC, scoring · Faux positifs
Défi : Donner l'IOC le plus fiable et son score.
Attendus : Validé si les IOC sont enrichis et si l'IOC le plus fiable et son score sont corrects.
Désigner un coupable est tentant, mais une attribution mal conduite oriente toute la réponse dans la mauvaise direction. Cette brique vous fait analyser des acteurs par leurs techniques caractéristiques tout en mesurant les limites de l'attribution — un acteur peut en imiter un autre — et exprimer un niveau de confiance. Elle vous fait surtout opérationnaliser le renseignement : traduire une technique d'attaquant en règle de détection Sigma. Vous donnez l'acteur le plus probable assorti de sa confiance, et transformez une technique en détection concrète. La valeur du renseignement se mesure à ce qu'il change dans la défense.
Objectif : Analyser et attribuer prudemment.
Notions : Acteurs, TTP signatures · Limites d'attribution
Défi : Donner l'acteur le plus probable et le niveau de confiance.
Attendus : Validé si l'attribution est pondérée et si l'acteur le plus probable et le niveau de confiance sont justifiés.
Objectif : Transformer le renseignement en détections.
Notions : TTP→règle · Procedural semantics gap
Défi : Fournir la TTP transformée en règle Sigma.
Attendus : Validé si une TTP est transformée en règle Sigma testée.
Un renseignement juste mais mal restitué ne déclenche aucune décision : le rapport est l'endroit où la valeur se concrétise. Cette brique vous fait rédiger un rapport CTI réellement actionnable, calibré selon son audience — du décideur qui veut trois priorités à l'analyste qui veut les détails techniques. Le défi : produire un rapport assorti de trois recommandations priorisées. Vous apprenez à faire atterrir le renseignement là où il sera utilisé, dans la langue de celui qui décide.
Objectif : Rédiger un rapport actionnable par audience.
Notions : Niveaux de rapport · Recommandations
Défi : Fournir le rapport avec 3 recommandations priorisées.
Attendus : Validé si le rapport est adapté aux audiences et propose trois recommandations priorisées.
Un acteur lié à un État se pre-positionne dans des infrastructures critiques pour une éventuelle perturbation future.
Mission : Rédiger un rapport de renseignement stratégique et cartographier les techniques observées sur une matrice ATT&CK.
Le démantèlement révèle l'organisation interne, les affiliés et l'infrastructure d'un groupe de rançongiciel.
Mission : Analyser un écosystème de rançongiciel comme service, travailler l'attribution et le suivi d'infrastructure.
Un vol majeur de crypto-actifs est rattaché à un groupe étatique par un avis officiel.
Mission : Produire une note d'attribution étayée et suivre les pivots d'infrastructure et de blanchiment.
Une campagne d'extorsion de masse exploité une faille inédite d'un outil de transfert.
Mission : Produire du renseignement opérationnel et des indicateurs de compromission exploitables par un SOC.
Conduite d'une investigation sur un système Windows : acquisition, artefacts, mémoire, timeline et rapport.
En investigation, une preuve mal collectée est une preuve perdue — voire irrecevable. Cette brique vous fait acquérir une image disque et mémoire d'un système Windows en préservant son intégrité : respect de l'ordre de volatilité (capturer le plus fugace d'abord), blocage en écriture (write-blocker), empreinte de vérification. Le défi : fournir le SHA-256 de l'image et prouver qu'elle n'a pas été altérée. Vous posez le premier geste, décisif, d'une investigation numérique recevable.
Objectif : Acquérir image disque/mémoire en préservant l'intégrité.
Notions : Ordre de volatilité · Write-blocker, hash
Défi : Fournir le SHA-256 de l'image et prouver l'intégrité.
Attendus : Validé si l'ordre de volatilité est respecté et si le SHA-256 de l'image prouve l'intégrité.
Même quand un attaquant efface ses fichiers, Windows garde la trace de ce qui a tourné. Cette brique vous fait reconstituer l'activité d'exécution à partir d'artefacts méconnus (Prefetch, Amcache, ShimCache) et débusquer les mécanismes par lesquels un programme survit aux redémarrages — clés de démarrage, services, tâches planifiées. Vous désignez le binaire malveillant exécuté et le mécanisme de persistance installé. Vous apprenez à lire les empreintes que le système conserve à l'insu de l'intrus.
Objectif : Reconstituer ce qui a été exécuté.
Notions : Prefetch, Amcache · ShimCache
Défi : Donner le binaire malveillant exécuté.
Attendus : Validé si les artefacts d'exécution sont extraits et si le binaire malveillant exécuté est correct.
Objectif : Trouver les mécanismes de persistance.
Notions : Run keys, services · Tâches planifiées
Défi : Donner le mécanisme de persistance trouvé.
Attendus : Validé si les points de persistance sont énumérés et si le mécanisme malveillant est correctement identifié.
La base de registre et les traces de navigation racontent, heure par heure, ce qu'un utilisateur a fait sur sa machine. Cette brique vous fait extraire des preuves du registre Windows — ruches, périphériques USB branchés, comptes et accès — puis reconstituer l'activité du navigateur et de la messagerie. Vous retrouvez le numéro de série de la clé USB connectée et l'URL depuis laquelle un logiciel malveillant a été téléchargé. Vous reconstruisez le fil des actions d'un utilisateur, légitime ou compromis.
Objectif : Extraire des preuves du registre.
Notions : Ruches, USB · Comptes/accès
Défi : Donner le numéro de série de la clé USB branchée.
Attendus : Validé si les ruches sont analysées et si le numéro de série de la clé USB est correct.
Objectif : Reconstituer l'activité utilisateur.
Notions : Historique, cache · Téléchargements
Défi : Donner l'URL de téléchargement du malware.
Attendus : Validé si l'activité navigateur est reconstituée et si l'URL de téléchargement du malware est correcte.
Certaines menaces ne touchent jamais le disque : elles ne vivent que dans la mémoire vive. Cette brique vous fait analyser une capture de mémoire avec Volatility pour révéler ce qui s'y cache — processus, bibliothèques chargées (DLL), et surtout code injecté dans un processus légitime. Le défi : identifier le processus injecté et l'adresse de commande-et-contrôle qu'il contacte. Vous accédez à la couche où se réfugient les attaques les plus furtives, invisibles à l'analyse de disque.
Objectif : Révéler processus et injections.
Notions : Processus, DLL · Injections
Défi : Donner le PID injecté et l'IP de C2.
Attendus : Validé si l'injection est détectée et si le PID injecté et l'IP de C2 sont corrects.
Un système de fichiers NTFS tient une comptabilité minutieuse — que l'enquêteur peut exploiter, et que l'attaquant cherche à fausser. Cette brique vous fait analyser la table de fichiers maîtresse (MFT) et le journal des modifications ($UsnJrnl) pour retrouver un fichier supprimé, puis repérer les traces d'anti-forensique : falsification d'horodatages (timestomping), effacement de journaux. Vous identifiez le fichier supprimé par l'attaquant et celui dont les dates ont été manipulées. Vous apprenez à débusquer non seulement les traces, mais aussi les tentatives de les effacer.
Objectif : Exploiter MFT et journaux NTFS.
Notions : MFT, $UsnJrnl · Horodatages
Défi : Donner le fichier supprimé par l'attaquant.
Attendus : Validé si la MFT et le journal NTFS sont exploités et si le fichier supprimé est correctement identifié.
Objectif : Repérer les traces d'effacement.
Notions : Timestomping · Effacement de logs
Défi : Donner le fichier dont les dates ont été falsifiées.
Attendus : Validé si l'anti-forensique est détecté et si le fichier aux dates falsifiées est correct.
À la fin d'une investigation, des dizaines d'artefacts isolés ne valent que reliés en une chronologie cohérente. Cette brique vous fait construire une super-timeline avec Plaso — l'assemblage de toutes les sources horodatées en une frise unique — puis produire un rapport recevable, distinguant clairement hypothèses et preuves. Vous datez l'accès initial et son vecteur, et livrez un rapport portant la chronologie complète. Vous bouclez l'investigation par sa restitution : un récit daté, étayé, et exploitable au-delà du cercle technique.
Objectif : Construire une chronologie cohérente.
Notions : Super-timeline · Corrélation
Défi : Donner l'heure et le vecteur d'accès initial.
Attendus : Validé si la super-timeline est cohérente et si l'heure et le vecteur d'accès initial sont corrects.
Objectif : Produire un rapport recevable.
Notions : Hypothèses/preuves · Clarté juridique
Défi : Livrer le rapport avec la chronologie complète.
Attendus : Validé si le rapport distingue faits et hypothèses et présente une chronologie complète.
Après une usurpation auprès du support, l'acteur prend la main sur l'environnement d'identité et progresse vers le domaine.
Mission : Investiguer une compromission Windows/Active Directory consécutive à une attaque d'ingénierie sociale.
L'acteur circule plusieurs jours dans le réseau avant de déployer le rançongiciel.
Mission : Reconstituer le déplacement latéral et le vol d'identifiants à partir des artefacts Windows.
Des jetons de session volés permettent d'accéder à des hôtes Windows sans authentification.
Mission : Tracer un détournement de session sur les hôtes Windows et dater la fenêtre d'accès.
Un rançongiciel chiffre des systèmes après une entrée par VPN sans double authentification.
Mission : Identifier les artefacts d'un rançongiciel sur des postes Windows et établir la chronologie d'exécution.
Des accès cloud illégitimes via jetons forgés coexistent avec une activité sur des postes.
Mission : Corréler les artefacts d'authentification cloud avec la télémétrie des hôtes Windows.
Investigation d'un système Linux compromis : traces, persistance, mémoire et post-mortem.
Quand un serveur Linux est suspecté de compromission, le débrancher trop vite peut détruire des preuves volatiles. Cette brique vous fait collecter dans le bon ordre : un triage à chaud sur le système vivant, puis une capture de la mémoire vive (avec LiME) et une image disque hors-ligne. Le défi : repérer le processus suspect dès le triage live. Vous savez intervenir sur une machine en production sans effacer ce que la mémoire vive est seule à détenir.
Objectif : Collecter preuves live et hors-ligne.
Notions : Triage live · Mémoire LiME
Défi : Donner le processus suspect du triage live.
Attendus : Validé si le triage live et les acquisitions préservent l'intégrité et si le processus suspect est correct.
Sous Linux, ce qu'un attaquant a fait et comment il compte revenir se lit dans les journaux et la configuration du système. Cette brique vous fait reconstituer l'activité via les journaux (auth.log, journald) et débusquer les mécanismes de persistance (cron, services systemd), puis retrouver les commandes exécutées dans l'historique du shell. Vous identifiez le mécanisme de persistance et le compte impliqué, ainsi que la commande qui a téléchargé le code malveillant. Vous lisez l'empreinte qu'un intrus laisse, malgré lui, dans la mémoire administrative du système.
Objectif : Reconstituer l'activité et la persistance.
Notions : auth.log, journald · Cron/systemd
Défi : Donner le mécanisme de persistance et le compte.
Attendus : Validé si les journaux sont analysés et si le mécanisme de persistance et le compte compromis sont corrects.
Objectif : Reconstituer les commandes exécutées.
Notions : bash_history · Horodatages
Défi : Donner la commande de téléchargement du malware.
Attendus : Validé si l'historique shell est exploité et si la commande de téléchargement du malware est correcte.
Supprimer un fichier ne l'efface pas vraiment : ses données restent sur le disque jusqu'à réécriture. Cette brique vous fait récupérer des fichiers effacés par sculpture de données (carving) — reconstruction à partir des signatures de fichiers, avec Foremost — et via le journal du système de fichiers ext4. Le défi : récupérer un script malveillant que l'attaquant croyait avoir détruit. Vous savez ressusciter une preuve que l'on a tenté de faire disparaître.
Objectif : Récupérer des fichiers supprimés.
Notions : Carving · Journal ext4
Défi : Récupérer le script malveillant effacé.
Attendus : Validé si le carving aboutit et si le script malveillant effacé est correctement récupéré.
Les compromissions les plus avancées sous Linux se cachent là où l'on regarde le moins : dans la mémoire du noyau et dans les conteneurs. Cette brique vous fait analyser une capture mémoire avec Volatility pour démasquer un rootkit ou un module noyau malveillant, puis investiguer un conteneur Docker compromis — ses couches, ses points de montage, ses journaux. Vous identifiez le module noyau injecté et l'altération introduite dans le conteneur. Vous portez l'investigation jusqu'aux recoins où se réfugient les menaces furtives.
Objectif : Détecter rootkits et processus cachés.
Notions : Profils Linux · Modules/rootkits
Défi : Donner le module noyau malveillant chargé.
Attendus : Validé si le dump est analysé et si le module noyau malveillant est correctement identifié.
Objectif : Investiguer un conteneur compromis.
Notions : Couches, montages · Logs conteneur
Défi : Donner l'altération introduite dans le conteneur.
Attendus : Validé si les couches du conteneur sont inspectées et si l'altération introduite est correctement identifiée.
Un attaquant compétent ne se contente pas d'agir : il efface ses traces. Cette brique vous fait d'abord repérer ces manœuvres d'anti-forensique sous Linux — journaux effacés, dates falsifiées (timestomping) — puis reconstruire une chronologie fiable malgré elles. Vous identifiez le journal effacé et la méthode employée, puis datez le vecteur d'accès initial. Vous apprenez à enquêter contre quelqu'un qui cherche activement à vous égarer.
Objectif : Repérer l'effacement de traces.
Notions : Effacement de logs · Timestomping
Défi : Donner le log effacé et la méthode.
Attendus : Validé si l'anti-forensique est détecté et si le log effacé et la méthode sont corrects.
Objectif : Construire une chronologie.
Notions : Super-timeline · Corrélation
Défi : Donner le vecteur d'accès initial.
Attendus : Validé si la timeline Linux est construite et si le vecteur d'accès initial est correct.
Une investigation qui ne se conclut pas par un rapport clair reste sans effet : c'est le document qui transforme l'analyse en décision et, parfois, en preuve. Cette brique vous fait rédiger un rapport forensique Linux structuré — distinguant les faits établis des hypothèses, assorti des indicateurs de compromission et de la chronologie. Le défi : livrer un rapport portant les IOC et la frise des événements. Vous bouclez l'enquête par sa restitution, lisible autant par un pair que par un décideur.
Objectif : Conclure l'investigation.
Notions : Preuves · IOC
Défi : Livrer le rapport avec IOC et chronologie.
Attendus : Validé si le rapport compile les IOC et présente une chronologie complète.
Une porte dérobée greffée sur une bibliothèque de compression se déclenche dans le processus du démon SSH.
Mission : Investiguer une bibliothèque compromise et l'arbre de processus associé sur un hôte Linux.
L'activité ne laisse que des traces d'outils système légitimes.
Mission : Reconstituer une intrusion à partir d'historiques shell, de binaires détournés et de journaux sous Linux.
Des identifiants sont captés sur des postes par des logiciels voleurs avant d'être réutilisés.
Mission : Rechercher sur un hôte Linux les traces d'un logiciel voleur et la collecte d'identifiants.
Une instance hébergée est détournée pour interroger le service de métadonnées et voler des jetons.
Mission : Analyser les artefacts d'une instance Linux exploitée et la requête vers les métadonnées.
Des appareils Linux embarqués sont enrôlés via des identifiants par défaut.
Mission : Analyser un hôte Linux/embarqué enrôlé dans un botnet et caractériser la persistance.
Automatisation de la collecte et de l'analyse forensique avec Python pour gagner en vitesse et reproductibilité.
Quand les preuves se comptent en gigaoctets, l'analyse à la main ne tient plus : il faut programmer son outillage. Cette brique vous fait écrire en Python des extracteurs d'indicateurs sur de grands volumes, puis décoder vous-même des artefacts Windows (Prefetch, registre) à l'aide de bibliothèques forensiques. Vous désignez l'adresse la plus active et la plus suspecte, et le binaire exécuté décodé par votre script. Vous passez du statut d'utilisateur d'outils à celui d'auteur de vos propres outils d'investigation.
Objectif : Automatiser l'extraction d'indicateurs.
Notions : os/struct · Parsing de masse
Défi : Donner l'IP la plus active et la plus suspecte.
Attendus : Validé si le journal est parsé et si l'IP la plus active et la plus suspecte sont correctes.
Objectif : Décoder des artefacts en Python.
Notions : Prefetch/registre · Bibliothèques forensiques
Défi : Donner le binaire exécuté décodé par le script.
Attendus : Validé si l'artefact Windows est décodé et si le binaire exécuté est correctement extrait.
Rejouer la même analyse de capture à la main, à chaque incident, fait perdre un temps précieux. Cette brique vous fait automatiser l'analyse de trafic avec Scapy et DSHELL — détecter programmatiquement ce qu'un œil chercherait manuellement. Le défi : que votre script identifie de lui-même l'adresse qui balaie le réseau. Vous transformez une compétence d'analyse en détection reproductible, applicable à la prochaine capture sans repartir de zéro.
Objectif : Automatiser l'analyse de captures.
Notions : Scapy/DSHELL · Détection programmatique
Défi : Donner l'IP scanneuse détectée par le script.
Attendus : Validé si le script lit la capture et si l'IP scanneuse est correctement détectée.
Lors d'un incident touchant des dizaines de machines, collecter à la main est trop lent et difficilement reproductible. Cette brique vous fait construire en Python un collecteur de triage déployable sur plusieurs hôtes, qui horodate et empreinte ce qu'il récupère (manifeste vérifiable). Le défi : livrer le collecteur et son manifeste. Vous gagnez un outil qui rend la collecte rapide, homogène et défendable face à la contestation.
Objectif : Construire un collecteur reproductible.
Notions : Triage multi-hôtes · Hash/manifeste
Défi : Fournir le collecteur et le manifeste.
Attendus : Validé si le collecteur est reproductible et si le manifeste horodaté avec empreintes est fourni.
Un indicateur de compromission ne vaut que si l'on peut le chercher partout, vite, et le qualifier. Cette brique vous fait rechercher des IOC à l'échelle d'un parc avec des règles YARA exécutées par script, puis enrichir automatiquement ces indicateurs via des API de renseignement. Vous dénombrez les hôtes correspondant à un IOC et désignez l'indicateur enrichi le plus critique. Vous reliez détection de masse et qualification, les deux conditions d'une réponse à l'échelle.
Objectif : Rechercher des IOC sur un parc.
Notions : Scan YARA scripté · Reporting
Défi : Donner le nombre d'hôtes avec match IOC.
Attendus : Validé si le scan YARA est scripté et si le nombre d'hôtes avec correspondance est exact.
Objectif : Enrichir des IOC via API.
Notions : API threat intel · Corrélation
Défi : Donner l'IOC enrichi le plus critique.
Attendus : Validé si l'enrichissement par API fonctionne et si l'IOC enrichi le plus critique est correct.
Sur des volumes massifs, l'anomalie ne se voit pas à l'œil : elle ressort d'un traitement statistique. Cette brique vous fait analyser de grands ensembles de journaux par agrégation et détection d'écarts statistiques, puis chaîner collecte, analyse et restitution dans un pipeline automatisé. Vous faites ressortir l'anomalie statistique cachée et produisez un rapport généré de bout en bout. Vous industrialisez l'investigation, là où le volume rend l'approche manuelle inopérante.
Objectif : Traiter des volumes massifs de logs.
Notions : Agrégation · Anomalies statistiques
Défi : Donner l'anomalie statistique détectée.
Attendus : Validé si les volumes sont agrégés et si l'anomalie statistique est correctement détectée.
Objectif : Chaîner collecte→analyse→rapport.
Notions : Orchestration · Rapport auto
Défi : Exécuter le pipeline et fournir le rapport auto.
Attendus : Validé si le pipeline s'exécute de bout en bout et produit un rapport automatique cohérent.
La campagne touche des milliers d'organisations en quelques jours, générant un volume massif d'indicateurs.
Mission : Automatiser en Python le tri et l'enrichissement d'indicateurs à l'échelle d'un grand parc.
Le composant vulnérable est enfoui dans d'innombrables dépendances applicatives.
Mission : Scripter la recherche d'instances vulnérables ou compromises sur un parc hétérogène.
Les accès illégitimes se répartissent sur de nombreux espaces clients.
Mission : Corréler en Python des connexions suspectes entre plusieurs espaces et en sortir une chronologie.
L'abus de comptes privilégiés laisse des traces dans les journaux d'identité.
Mission : Automatiser l'extraction des journaux d'identité et la construction d'une frise chronologique.
Les techniques de vie sur le terrain imposent une recherche sur de nombreux hôtes.
Mission : Bâtir un script de chasse aux comportements de vie sur le terrain déployable sur tout un parc.
Analyse d'un logiciel malveillant en statique et dynamique pour en extraire le comportement et les IOC.
Avant d'exécuter un échantillon suspect — geste à risque — on l'examine au repos, et il en révèle déjà beaucoup. Cette brique vous fait caractériser un binaire sans le lancer : structure du format PE (l'exécutable Windows), chaînes de caractères, entropie qui trahit un contenu compressé ou chiffré. Le défi : avancer une famille de malware probable et l'indice décisif qui l'étaye. Vous posez le premier filtre de l'analyse de malware, celui qui oriente tout le reste sans prise de risque.
Objectif : Caractériser un échantillon sans l'exécuter.
Notions : Format PE · Chaînes, entropie
Défi : Donner la famille probable et l'indice décisif.
Attendus : Validé si l'analyse statique est menée et si la famille probable et l'indice décisif sont corrects.
Ce qu'un malware fait vraiment ne se devine pas toujours du code : il faut parfois le laisser s'exécuter — mais sous cloche. Cette brique vous fait observer un échantillon en détonation contrôlée dans un bac à sable (sandbox) isolé, en surveillant ses actions sur le système et le réseau (avec Procmon et un faux Internet, INetSim). Vous relevez la clé de persistance qu'il installe et l'hôte de commande-et-contrôle qu'il contacte. Vous lisez le comportement réel d'une menace, sans exposer d'environnement de production.
Objectif : Observer le comportement en isolation.
Notions : Sandbox isolé · Surveillance
Défi : Donner la clé de persistance et l'hôte C2.
Attendus : Validé si le comportement est capturé en isolation et si la clé de persistance et l'hôte C2 sont corrects.
Les malwares modernes se présentent emballés et brouillés pour résister à l'analyse : avant de comprendre, il faut déballer. Cette brique vous fait contourner ces protections — déballage en mémoire d'un binaire compressé (packé), désobfuscation des données — avec x64dbg et CyberChef. Le défi : extraire l'URL de commande-et-contrôle dissimulée dans la configuration. Vous franchissez la première barrière que pose un malware sérieux, celle qui décourage l'analyse superficielle.
Objectif : Contourner l'obfuscation.
Notions : Packing · Unpacking mémoire
Défi : Extraire l'URL de C2 de la configuration.
Attendus : Validé si la charge est déballée et si l'URL de C2 est correctement extraite de la configuration.
La porte d'entrée d'une attaque est souvent un document ou un script en apparence anodin. Cette brique vous fait disséquer un document piégé (maldoc) et ses macros VBA pour remonter la chaîne d'infection, puis décortiquer des charges scriptées en PowerShell ou JavaScript obfusquées. Vous retrouvez l'URL de téléchargement de la charge et l'action finale du script une fois décodé. Vous apprenez à neutraliser les vecteurs les plus courants des compromissions actuelles.
Objectif : Analyser un document piégé.
Notions : Macros VBA · Chaîne d'infection
Défi : Donner l'URL de téléchargement de la charge.
Attendus : Validé si la macro est désobfusquée et si l'URL de téléchargement de la charge est correcte.
Objectif : Analyser des charges scriptées.
Notions : PowerShell/JS obfusqué · Décodage
Défi : Donner l'action finale du script décodé.
Attendus : Validé si la charge scriptée est décodée et si son action finale est correctement identifiée.
Quand l'analyse comportementale atteint ses limites, il faut descendre au niveau de l'instruction machine. Cette brique vous fait lire la logique d'un malware en désassemblé (assembleur x86) avec IDA et Ghidra pour en isoler les fonctions clés, puis écrire un décodeur reproduisant sa routine de configuration. Vous localisez la fonction de communication avec le C2 et extrayez la configuration complète décodée. Vous atteignez le niveau d'analyse qui permet de comprendre un malware de fond en comble, pas seulement de l'observer.
Objectif : Comprendre la logique en désassemblé.
Notions : Assembly x86 · Fonctions clés
Défi : Donner la fonction de communication C2.
Attendus : Validé si les fonctions clés sont analysées et si la fonction de communication C2 est correcte.
Objectif : Extraire les paramètres du malware.
Notions : Config encodée · Décodeurs
Défi : Fournir la configuration décodée complète.
Attendus : Validé si un décodeur est écrit et si la configuration décodée complète est correcte.
Un malware en cours d'exécution se trahit dans la mémoire, même s'il s'est dissous sur le disque. Cette brique vous fait débusquer ces menaces en mémoire — injection dans un processus légitime, évidement de processus (process hollowing) — avec Volatility, puis écrire des règles YARA discriminantes pour les reconnaître ailleurs. Vous identifiez le processus hôte de l'injection et produisez une règle YARA sans faux positif. Vous reliez l'analyse au repérage à l'échelle : trouver une fois, détecter partout.
Objectif : Trouver le malware en mémoire.
Notions : Injection mémoire · Process hollowing
Défi : Donner le PID hôte de l'injection.
Attendus : Validé si l'injection est détectée en mémoire et si le PID hôte de l'injection est correct.
Objectif : Écrire des signatures discriminantes.
Notions : YARA · FP
Défi : Fournir la règle YARA sans faux positif.
Attendus : Validé si la règle YARA discrimine l'échantillon sans faux positif sur le bénin.
L'analyse d'un malware n'a de valeur défensive que si elle se diffuse sous une forme directement exploitable. Cette brique vous fait synthétiser comportement et indicateurs d'un échantillon, en cartographiant ses techniques sur MITRE ATT&CK et en préparant la diffusion des IOC. Le défi : livrer un rapport portant les techniques ATT&CK et les indicateurs. Vous transformez une analyse pointue en munition défensive partageable, qui profite à toute l'organisation.
Objectif : Restituer comportement et IOC.
Notions : Synthèse ATT&CK · Diffusion IOC
Défi : Livrer le rapport avec les TTP ATT&CK et IOC.
Attendus : Validé si le rapport mappe les TTP sur ATT&CK et diffuse les IOC.
Un maliciel écrit en Go s'adresse directement à des contrôleurs industriels via Modbus et coupe le chauffage de centaines d'immeubles.
Mission : Mener l'analyse statique et dynamique d'un maliciel ciblant des systèmes industriels.
Un maliciel vise les automates de sûreté d'un site industriel, au risque de neutraliser les protections.
Mission : Décortiquer un maliciel s'attaquant à un système instrumenté de sécurité et à son protocole propriétaire.
La charge malveillante est dissimulée dans des données de test d'une bibliothèque de compression.
Mission : Analyser une charge de porte dérobée enfouie dans une bibliothèque et son mécanisme de déclenchement.
L'opération de démantèlement met à disposition des échantillons et des clés.
Mission : Analyser un échantillon de rançongiciel issu d'un modèle as à service et son chiffreur.
Le code source du botnet, publié, mêle composants en C et en Go.
Mission : Étudier le code source d'un botnet d'objets connectés et ses mécanismes de propagation.
Analyse de binaires au niveau assembleur pour comprendre leur logique et identifier des vulnérabilités.
La rétro-ingénierie commence par savoir se repérer dans un programme dépouillé de son code source. Cette brique vous fait naviguer un binaire au niveau de l'assembleur — formats d'exécutables PE et ELF, graphe de flux de contrôle — avec Ghidra et radare2. Le défi : localiser l'adresse de la fonction qui vérifie une condition (un contrôle de mot de passe, par exemple). Vous acquérez l'orientation de base sans laquelle tout le reste de la rétro-ingénierie reste illisible.
Objectif : Naviguer un binaire au niveau asm.
Notions : Formats PE/ELF · Flux de contrôle
Défi : Donner l'adresse de la fonction de vérification.
Attendus : Validé si le binaire est navigué au niveau asm et si l'adresse de la fonction de vérification est correcte.
Lire un programme à l'arrêt ne suffit pas toujours : certaines logiques ne se révèlent qu'en cours d'exécution. Cette brique vous fait suivre un binaire pas à pas avec un débogueur (GDB) — points d'arrêt, inspection des registres et de la mémoire, modification à chaud (patch). Le défi : faire avouer au binaire le mot de passe qu'il attend. Vous apprenez à observer un programme en train de s'exécuter, et à infléchir son déroulement pour comprendre ce qu'il cache.
Objectif : Suivre une logique masquée.
Notions : Points d'arrêt · Patch à chaud
Défi : Donner le mot de passe attendu par le binaire.
Attendus : Validé si la logique est suivie au débogueur et si le mot de passe attendu est correct.
Avant d'exploiter une faille, encore faut-il la trouver dans le binaire : c'est le travail du chercheur en vulnérabilités. Cette brique vous fait repérer les faiblesses exploitables d'un programme par l'analyse — fonctions dangereuses, validation d'entrée défaillante — avec Ghidra et GDB. Le défi : désigner la fonction non sûre et son emplacement exact (offset). Vous adoptez l'œil qui distingue, dans du code compilé, ce qui tiendra de ce qui cédera sous la pression.
Objectif : Repérer des faiblesses exploitables.
Notions : Fonctions dangereuses · Validation d'entrée
Défi : Donner la fonction non sûre et l'offset.
Attendus : Validé si la faiblesse est tracée et si la fonction non sûre et l'offset sont corrects.
Un logiciel malveillant parle souvent un langage propriétaire et chiffre ses échanges avec sa propre recette : pour l'écouter, il faut d'abord le déchiffrer. Cette brique vous fait reconstituer un protocole de communication inconnu — structure des messages, champs, sommes de contrôle — puis retrouver une routine de chiffrement maison et sa clé codée en dur. Vous décrivez la structure d'un message et extrayez la clé dissimulée dans le binaire. Vous ouvrez la boîte noire des communications qu'un malware croyait illisibles.
Objectif : Comprendre un protocole propriétaire.
Notions : Format de messages · Champs/checksums
Défi : Donner la structure du message décodée.
Attendus : Validé si le protocole est analysé et si la structure du message décodée est correcte.
Objectif : Retrouver une routine de chiffrement.
Notions : Algorithme custom · Clés en dur
Défi : Donner la clé de chiffrement en dur.
Attendus : Validé si la routine crypto est identifiée et si la clé en dur est correctement extraite.
Les binaires qui ne veulent pas être analysés se défendent : ils détectent le débogueur et brouillent leur logique. Cette brique vous fait contourner ces protections d'anti-rétro-ingénierie, puis automatiser l'analyse en scriptant votre outil de désassemblage (Ghidra) — car à grande échelle, l'analyse à la main ne suit plus. Vous identifiez la technique anti-débogage déjouée et dénombrez les appels dangereux repérés par votre script. Vous reliez la ruse manuelle et l'automatisation, les deux faces de la rétro-ingénierie avancée.
Objectif : Contourner les protections.
Notions : Anti-debug · Obfuscation de flux
Défi : Donner la technique anti-debug contournée.
Attendus : Validé si les protections sont contournées et si la technique anti-debug est correctement nommée.
Objectif : Automatiser l'analyse.
Notions : Scripting Ghidra · Automatisation
Défi : Donner le nombre d'appels dangereux détectés.
Attendus : Validé si le script Ghidra s'exécute et si le nombre d'appels dangereux détectés est exact.
Au sommet de la chaîne d'analyse, le reverse engineer affronte des malwares conçus pour résister à tout examen — et doit restituer ses conclusions de façon utile. Cette brique vous fait analyser un binaire malveillant complexe, packé et doté de logique d'évasion, avec Ghidra et Volatility, puis documenter votre démarche. Vous identifiez la technique d'évasion du malware et livrez un rapport reconstituant sa logique. Vous bouclez l'analyse experte par la transmission, condition pour qu'un savoir individuel devienne une capacité collective.
Objectif : Analyser un binaire malveillant complexe.
Notions : Malware packé · Logique d'évasion
Défi : Donner la technique d'évasion du malware.
Attendus : Validé si le binaire est déballé/analysé et si la technique d'évasion est correctement identifiée.
Objectif : Documenter l'analyse.
Notions : Synthèse technique · Recommandations
Défi : Livrer le rapport avec la logique reconstituée.
Attendus : Validé si le rapport reconstitue la logique du binaire de façon claire.
Un exploit sans interaction abuse d'un décodeur d'images (JBIG2) pour provoquer un dépassement d'entier et bâtir un calcul arbitraire.
Mission : Rétro-concevoir une primitive d'exploitation avancée à partir d'un format de fichier, à un niveau conceptuel maîtrisé.
L'implant se greffe via un mécanisme de résolution de fonctions au chargement du démon SSH.
Mission : Faire le reverse de l'implant et de son déclencheur, et comprendre son intégration furtive.
Le maliciel communique avec les automates via un protocole propriétaire non documenté.
Mission : Rétro-concevoir un protocole propriétaire et la logique d'un automate de sûreté.
Le maliciel est un binaire Go pilotant des équipements par Modbus.
Mission : Faire le reverse d'un binaire Go et reconstituer sa logique de commande industrielle.
L'analyse du chiffreur à permis de produire des outils de déchiffrement.
Mission : Faire le reverse d'un chiffreur et en chercher les faiblesses d'implémentation.
Pilotage de la réponse à incident et de la gestion de crise de bout en bout, du playbook ransomware à la continuité.
La qualité d'une réponse à incident se joue avant l'incident : dans la préparation. Cette brique vous fait outiller cette préparation selon le cycle NIST 800-61 — rôles et responsabilités clarifiés (matrice RACI), procédures de décision écrites (playbooks). Le défi : produire un playbook assorti de trois actions de confinement. Vous mettez en place ce qui fera la différence le jour venu : non l'improvisation, mais des réflexes préparés et partagés.
Objectif : Préparer l'organisation à répondre.
Notions : Cycle IR 800-61 · RACI
Défi : Fournir le playbook avec 3 actions de confinement.
Attendus : Validé si les rôles sont définis et si le playbook fournit trois actions de confinement.
Face à un incident, deux erreurs symétriques guettent : surréagir à une fausse alerte, ou sous-estimer une compromission majeure. Cette brique vous fait d'abord qualifier un incident — sévérité justifiée, périmètre touché — puis le confiner sans détruire les preuves nécessaires à l'investigation. Vous établissez la sévérité et le périmètre, identifiez le point d'entrée et appliquez le bon confinement. Vous apprenez à agir vite et juste, en gardant la tête froide sous pression.
Objectif : Qualifier un incident majeur.
Notions : Sévérité, périmètre · Critères
Défi : Donner la sévérité justifiée et le périmètre.
Attendus : Validé si la sévérité est justifiée et si le périmètre de l'incident est correctement délimité.
Objectif : Confiner en préservant les preuves.
Notions : Confinement · Préservation preuves
Défi : Donner le point d'entrée et le confinement appliqué.
Attendus : Validé si les preuves sont préservées et si le point d'entrée et le confinement appliqué sont corrects.
Confiner ne suffit pas : tant que la persistance de l'attaquant subsiste, il peut revenir. Cette brique vous fait éradiquer ces points d'ancrage et durcir dans la foulée, tout en menant une investigation rapide qui ne ralentit pas la réponse. Vous identifiez les mécanismes de persistance éliminés et dénombrez les hôtes réellement touchés — souvent plus nombreux que les premiers suspects. Vous tenez les deux exigences en tension : reprendre la main vite, sans rien laisser derrière.
Objectif : Éradiquer la persistance et durcir.
Notions : Éradication · Durcissement
Défi : Donner les mécanismes de persistance éradiqués.
Attendus : Validé si la persistance est éradiquée et si les mécanismes éradiqués sont correctement listés.
Objectif : Investiguer sans ralentir la réponse.
Notions : Forensique rapide · Hunts
Défi : Donner le nombre d'hôtes réellement touchés.
Attendus : Validé si le hunt établit l'étendue et si le nombre d'hôtes réellement touchés est exact.
Restaurer trop vite, c'est risquer de réinjecter la compromission avec la sauvegarde ; restaurer trop lentement, c'est aggraver la perte. Cette brique vous fait piloter la reprise dans le cadre d'un plan de continuité et de reprise d'activité (PCA/PRA) — vérifier que les sauvegardes sont saines, ordonner la restauration, mesurer le temps de reprise visé (RTO) et la perte de données acceptable (RPO). Le défi : définir l'ordre de restauration et atteindre l'objectif de reprise. Vous reliez la réponse technique à l'enjeu de continuité, qui est celui du métier.
Objectif : Restaurer en sécurité.
Notions : Sauvegardes saines · RTO/RPO
Défi : Donner l'ordre de restauration et le RTO atteint.
Attendus : Validé si les sauvegardes sont vérifiées et si l'ordre de restauration et le RTO atteint sont cohérents.
Un incident majeur déborde vite la sphère technique : il devient une crise, où décisions et communication pèsent autant que la réponse sur le terrain. Cette brique vous fait animer une cellule de crise — arbitrages, communication interne et externe — puis concevoir et conduire un exercice sur table (tabletop) pour entraîner l'organisation à froid, en vous appuyant sur des trames reconnues (CISA CTEP, ENISA). Vous prononcez une décision critique justifiée et bâtissez un scénario d'exercice avec ses péripéties injectées. Vous reliez la cyberdéfense à la gouvernance de crise, là où se joue la résilience réelle.
Objectif : Animer la cellule de crise.
Notions : Cellule de crise · Communication
Défi : Donner la décision critique et sa justification.
Attendus : Validé si la cellule est animée et si la décision critique et sa justification sont pertinentes.
Objectif : Concevoir et animer un cyber-drill.
Notions : Tabletop · Injects
Défi : Fournir le scénario avec 4 injects et l'objectif.
Attendus : Validé si l'exercice est conçu avec quatre injects et un objectif clair.
Un incident traité mais non analysé est une leçon perdue — et souvent une rechute annoncée. Cette brique vous fait conduire le bilan d'après-crise (revue après action, ou AAR) : reconstituer ce qui s'est passé sans chercher de coupable, en tirer des enseignements et un plan d'amélioration concret. Le défi : produire une revue assortie de cinq actions priorisées. Vous transformez l'épreuve en progrès durable, ce qui distingue une organisation qui apprend d'une organisation qui répète ses erreurs.
Objectif : Capitaliser et améliorer.
Notions : AAR · Plan d'amélioration
Défi : Fournir l'AAR avec 5 actions priorisées.
Attendus : Validé si l'AAR est mené et si cinq actions d'amélioration sont priorisées.
Le chiffrement des systèmes d'un acteur central de la santé perturbe le remboursement des soins à l'échelle d'un pays.
Mission : Piloter une crise de rançongiciel à fort impact sectoriel : cellule de crise, priorités, parties prenantes.
L'exploitant arrête sa distribution par précaution et fait face à une crise publique.
Mission : Conduire la décision d'arrêt, la communication de crise et la continuité d'activité.
Une grande chaîne hôtelière voit réservations, clés et machines paralysées plusieurs jours.
Mission : Gérer une crise opérationnelle prolongée et la pression médiatique qui l'accompagne.
Un fournisseur et ses milliers de clients doivent répondre simultanément et notifier les personnes touchées.
Mission : Coordonner une réponse impliquant fournisseur, clients et obligations de notification.
Conduite d'un test d'intrusion complet et reproductible, de la reconnaissance au rapport.
Un test d'intrusion sans cadre clair n'est pas un test : c'est une intrusion. Cette brique vous fait d'abord poser les règles d'engagement d'une mission — périmètre, autorisation écrite, confidentialité, selon une méthodologie reconnue (PTES) — avant tout geste technique. Vous menez ensuite la reconnaissance active pour cartographier la surface d'attaque et désigner la cible la plus prometteuse, justification à l'appui. Vous apprenez que la rigueur du cadrage est ce qui sépare un professionnel de la sécurité offensive d'un attaquant.
Objectif : Cadrer légalement une mission de pentest.
Notions : Périmètre, autorisation, PTES · Preuves/confidentialité
Défi : Fournir les règles d'engagement validées.
Attendus : Validé si les règles d'engagement couvrent périmètre, autorisation et preuves, et sont validées.
Objectif : Cartographier la surface d'attaque.
Notions : Recon passive/active · Priorisation
Défi : Donner la cible la plus prometteuse justifiée.
Attendus : Validé si la surface est cartographiée et si la cible la plus prometteuse est justifiée.
Un rapport de scanner brut mêle vraies failles et fausses alertes : le travail commence là où l'outil s'arrête. Cette brique vous fait identifier des vulnérabilités, les hiérarchiser par leur score de gravité (CVSS), et surtout les valider manuellement — car seule une faille confirmée justifie une action. Le défi : désigner la vulnérabilité avérée la plus critique et son identifiant (CVE). Vous adoptez la discipline qui distingue un résultat exploitable d'un simple bruit de scanner.
Objectif : Identifier et valider sans faux positifs.
Notions : Scanners, CVSS · Validation manuelle
Défi : Donner la vuln validée la plus critique (CVE).
Attendus : Validé si deux vulnérabilités sont validées et si la plus critique (CVE) est correctement désignée.
Obtenir un premier pied dans le système est le moment-clé d'un test d'intrusion — et le plus délicat à mener proprement. Cette brique vous fait exploiter une faille pour gagner un accès initial stable avec Metasploit (charges, gestionnaires de connexion), puis compromettre des identifiants faibles par attaque en ligne et cassage hors-ligne. Vous fournissez une preuve d'accès (machine et compte obtenus) et un identifiant valide. Vous franchissez, de façon contrôlée et documentée, la frontière qu'un attaquant cherche à passer en silence.
Objectif : Obtenir un accès initial maîtrisé.
Notions : Payloads, handlers · Stabilité
Défi : Fournir la preuve d'accès (hostname+utilisateur).
Attendus : Validé si une session stable est obtenue et si la preuve d'accès (hôte+utilisateur) est fournie.
Objectif : Compromettre des identifiants faibles.
Notions : Brute-force, spraying · Cassage hors-ligne
Défi : Donner l'identifiant valide obtenu.
Attendus : Validé si l'identifiant valide est obtenu par l'attaque maîtrisée.
Un accès initial est rarement un accès administrateur : entre les deux, il y a l'escalade de privilèges. Cette brique vous fait élever vos droits sur une cible Linux puis Windows en exploitant des défauts de configuration — binaires SUID, règles sudo, tâches planifiées, services mal protégés, jetons d'accès — repérés avec linPEAS et winPEAS. Vous désignez le vecteur d'escalade utilisé et le service vulnérable exploité. Côté défense, c'est comprendre exactement ce qu'un attaquant cherchera une fois entré, pour le lui fermer.
Objectif : Élever ses privilèges sur la cible.
Notions : SUID, sudo, cron · Noyau
Défi : Donner le vecteur d'escalade utilisé.
Attendus : Validé si root est obtenu et si le vecteur d'escalade utilisé est correctement identifié.
Objectif : Élever ses privilèges sous Windows.
Notions : Services, jetons · Misconfig
Défi : Donner le service vulnérable exploité.
Attendus : Validé si SYSTEM est obtenu et si le service vulnérable exploité est correct.
La valeur d'un test d'intrusion ne tient pas à l'exploit réussi, mais à ce qu'on en démontre et à ce qu'on recommande. Cette brique vous fait mener une post-exploitation propre — persistance contrôlée, collecte de la preuve d'impact métier, nettoyage — puis rédiger un rapport actionnable, du résumé exécutif au détail technique. Vous établissez la preuve d'un impact réel pour l'organisation et livrez un rapport reliant la chaîne d'attaque à trois remédiations priorisées. Vous bouclez la mission par ce qui la rend utile : aider la cible à se corriger.
Objectif : Persister proprement et collecter l'impact.
Notions : Persistance contrôlée · Collecte/nettoyage
Défi : Fournir la preuve d'impact métier.
Attendus : Validé si une preuve d'impact métier est produite et la persistance nettoyée.
Objectif : Produire un rapport actionnable.
Notions : Résumé exécutif/technique · Remédiation priorisée
Défi : Livrer le rapport avec chaîne + 3 remédiations.
Attendus : Validé si le rapport présente la chaîne et trois remédiations priorisées.
Un portail public reste vulnérable à une faille connue d'un cadre applicatif, faute de correctif applique partout.
Mission : Dérouler une méthodologie de test (reconnaissance, identification d'une vulnérabilité connue, preuve) et restituer un rapport priorisé.
Une API exposée renvoie les données clients sans contrôle d'accès, par identifiants incrémentaux.
Mission : Conduire l'énumération et le test d'autorisation au niveau objet (référence directe non sécurisée).
Une falsification de requête côté serveur permet d'atteindre le service de métadonnées d'une instance.
Mission : Identifier et démontrer une falsification de requête côté serveur, puis la chaîner vers les métadonnées.
Un outil de transfert présente une injection SQL inédite menant à exécution de code.
Mission : Tester une injection SQL sur un applicatif et en documenter l'impact dans un cadre autorisé.
Deux vulnérabilités enchaînées sur une appliance VPN mènent à une exécution de code à distance.
Mission : Enchaîner deux vulnérabilités pour une exécution à distance et documenter le chemin d'attaque.
Développement de ses propres outils offensifs en Python : réseau, exploitation et automatisation.
Les outils tout faits s'arrêtent là où commencent les besoins spécifiques : pour aller plus loin, on programme les siens. Cette brique vous fait écrire en Python un scanner de ports (sockets TCP/UDP, parallélisme) puis forger et analyser des paquets sur mesure avec Scapy. Vous livrez votre propre scanner et son résultat, et faites répondre un hôte à un scan personnalisé. Vous comprenez de l'intérieur ce que les outils automatisent, et gagnez l'autonomie de construire ce qu'aucun outil ne fait.
Objectif : Programmer un scanner de ports.
Notions : Sockets TCP/UDP, threads · Timeouts
Défi : Fournir le scanner et les ports ouverts détectés.
Attendus : Validé si le scanner multithread fonctionne et reporte correctement les ports ouverts.
Objectif : Forger et analyser des paquets.
Notions : Forge, sniff · Scans personnalisés
Défi : Donner l'hôte répondant au scan personnalisé.
Attendus : Validé si le paquet personnalisé est forgé et si l'hôte répondant est correctement identifié.
Comprendre comment un attaquant prend la main suppose de l'avoir codé soi-même. Cette brique vous fait scripter en Python une attaque de mots de passe contrôlée (gestion du débit, reprise sur incident) puis écrire un shell distant — la connexion par laquelle on pilote une machine compromise — en distinguant les variantes inversée (reverse) et liée (bind). Vous trouvez un identifiant valide et prouvez l'exécution d'une commande à distance. Vous démystifiez deux briques élémentaires de bien des intrusions, ce qui aide aussi à les détecter.
Objectif : Scripter une attaque de mots de passe.
Notions : Brute-force, débit · Reprise d'état
Défi : Donner l'identifiant valide trouvé.
Attendus : Validé si le script trouve l'identifiant valide en restant fiable.
Objectif : Écrire un shell distant en Python.
Notions : Reverse vs bind · Chiffrement basique
Défi : Prouver l'exécution d'une commande à distance.
Attendus : Validé si le reverse shell exécute une commande à distance.
Répéter à la main les mêmes vérifications d'exploitation, mission après mission, est une perte de temps et une source d'oublis. Cette brique vous fait automatiser ces tâches en Python : vérifier les voies d'escalade de privilèges, puis piloter Metasploit par son interface programmable (RPC) pour orchestrer l'exploitation. Vous faites détecter le vecteur d'escalade par votre script et obtenez une session via code. Vous industrialisez le geste offensif, gain de fiabilité autant que de rapidité.
Objectif : Vérifier l'escalade automatiquement.
Notions : Checks privesc · Reporting
Défi : Donner le vecteur d'escalade détecté par le script.
Attendus : Validé si le script détecte correctement le vecteur d'escalade.
Objectif : Automatiser l'exploitation.
Notions : RPC MSF · Orchestration
Défi : Prouver l'obtention d'une session via script.
Attendus : Validé si une session est obtenue par pilotage scripté de Metasploit.
Au-delà des outils publics, le praticien avancé façonne son propre arsenal, adapté à ses missions. Cette brique vous fait construire en Python des outils réutilisables — un module de reconnaissance produisant un rapport structuré (JSON), puis un outil offensif empaqueté en ligne de commande — et comprendre les concepts d'évasion antivirus (obfuscation, encodage de charges) en mesurant la baisse de détection. Le travail inclut des garde-fous éthiques explicites, car un outil offensif engage la responsabilité de son auteur. Vous gagnez l'autonomie de l'outillage, avec la rigueur qu'elle exige.
Objectif : Construire un outil de recon réutilisable.
Notions : Modularité · Sorties exploitables
Défi : Fournir l'outil et son rapport JSON.
Attendus : Validé si l'outil produit un rapport JSON exploitable de la reconnaissance.
Objectif : Comprendre l'obfuscation de charges.
Notions : Obfuscation · Encodage
Défi : Donner la baisse de détection mesurée.
Attendus : Validé si la baisse de détection est mesurée dans un cadre éthique.
Objectif : Empaqueter un outil CLI documenté.
Notions : CLI, config · Éthique/garde-fous
Défi : Livrer l'outil CLI exécutant recon→exploit.
Attendus : Validé si l'outil CLI documenté exécute la chaîne recon→exploit.
Les enregistrements clients sont récupérables en incrémentant un identifiant numérique.
Mission : Écrire en Python un énumérateur d'identifiants d'API, dans un cadre de test autorisé.
Le botnet se propage en testant des identifiants d'usine sur des objets connectés.
Mission : Comprendre et coder, en laboratoire isolé, un scanner d'identifiants par défaut.
La faille est difficile à inventorier à la main sur un grand parc.
Mission : Automatiser en Python la détection d'instances vulnérables à l'échelle.
L'exploitation laisse des traces nombreuses dans les journaux applicatifs.
Mission : Scripter en Python l'extraction et la mise en forme de preuves d'exploitation.
De grands volumes d'identifiants volés circulent et doivent être testés sans nuire.
Mission : Automatiser, dans un cadre éthique strict, la validation d'identifiants exposés.
Identification et exploitation des vulnérabilités web (OWASP) et apprentissage d'un processus d'audit reproductible.
Cartographier une application web, c'est en dresser le plan complet — y compris les pages que son menu ne montre pas. Cette brique vous fait cartographier une application avec Burp Suite (proxy d'interception, exploration automatique) puis attaquer son authentification et sa gestion de session. Vous débusquez un point d'accès sensible non référencé et le paramètre qui permet d'usurper une session. Vous posez les deux gestes d'ouverture de tout test applicatif : voir toute la surface, et éprouver la porte d'entrée.
Objectif : Cartographier une application web.
Notions : Spidering, proxy · Surface web
Défi : Donner l'endpoint sensible non lié dans le menu.
Attendus : Validé si l'application est cartographiée et si l'endpoint sensible non lié est trouvé.
Objectif : Attaquer l'authentification et les sessions.
Notions : Auth, session · Cookies/jetons
Défi : Donner le paramètre permettant l'usurpation.
Attendus : Validé si le paramètre permettant l'usurpation de session est correctement identifié.
L'injection SQL reste, des décennies après sa découverte, l'une des failles web les plus répandues et les plus graves. Cette brique vous fait détecter et exploiter une injection SQL — variantes par union, à l'aveugle (blind), par erreur — avec SQLmap, puis comprendre comment la corriger. Le défi : extraire l'empreinte du mot de passe administrateur par l'injection. Vous saisissez à la fois le mécanisme de l'attaque et la requête paramétrée qui l'aurait empêchée.
Objectif : Détecter et exploiter une injection SQL.
Notions : Union/blind/error · Remédiation
Défi : Extraire le hash admin via l'injection.
Attendus : Validé si l'injection est exploitée et si le hachage admin est correctement extrait.
Une application qui fait confiance aux données qu'elle reçoit s'expose à les voir détournées contre elle. Cette brique vous fait exploiter le cross-site scripting (XSS) — l'injection de code dans une page vue par d'autres utilisateurs, dans ses variantes stockée, réfléchie et DOM — puis les injections de fichiers (téléversement piégé, inclusion de fichiers, entités XML externes — XXE). Vous exfiltrez un cookie de session via XSS et lisez un fichier système via une XXE. Vous comprenez comment une entrée non contrôlée devient une exécution non prévue.
Objectif : Exploiter un XSS stocké.
Notions : XSS stocké/réfléchi/DOM · Encodage
Défi : Exfiltrer le cookie de session via XSS.
Attendus : Validé si le XSS stocké exfiltre le cookie de session.
Objectif : Exploiter upload, LFI et XXE.
Notions : Upload, LFI/RFI · XXE
Défi : Lire /etc/passwd via l'XXE.
Attendus : Validé si l'XXE permet de lire /etc/passwd.
Beaucoup d'applications vérifient qui vous êtes, mais oublient de vérifier ce à quoi vous avez droit. Cette brique vous fait exploiter ces défauts d'autorisation — accès direct à l'objet d'un autre utilisateur (IDOR), élévation de privilèges — puis des entrées non validées menant à l'exécution (désérialisation, injection de commande). Vous accédez à la commande d'un autre utilisateur en changeant un identifiant, et trouvez le paramètre qui mène à l'exécution de code. Vous touchez aux failles de logique d'accès, parmi les plus fréquentes et les plus sous-estimées.
Objectif : Exploiter des défauts d'autorisation.
Notions : IDOR, BOLA · Privilèges
Défi : Accéder à la commande d'un autre utilisateur (ID).
Attendus : Validé si l'IDOR donne accès à la commande d'un autre utilisateur.
Objectif : Exploiter des entrées non validées.
Notions : Désérialisation · Injection de commande
Défi : Donner le paramètre menant à l'exécution.
Attendus : Validé si le paramètre menant à l'exécution est correctement identifié.
Le jeton qui vous identifie après connexion est aussi ce qu'un attaquant cherche à falsifier. Cette brique vous fait attaquer la gestion de session moderne, en particulier les jetons JWT (JSON Web Tokens) : compréhension de leur signature, fixation de session, et forge d'un jeton valide avec jwt_tool. Le défi : fabriquer un JWT d'administrateur que l'application accepte. Vous comprenez où se brise la confiance dans un jeton, et donc comment la garantir.
Objectif : Attaquer la gestion de session moderne.
Notions : JWT, signatures · Fixation
Défi : Forger un JWT admin valide.
Attendus : Validé si un JWT admin valide est forgé.
Tester une application à la main ne passe pas à l'échelle ; l'automatiser sans tri produit du bruit. Cette brique vous fait industrialiser l'évaluation web avec des scanners (Nikto, ZAP) tout en triant leurs résultats, puis corriger durablement les failles et vérifier la correction par analyse de code (SAST avec Semgrep). Vous livrez trois vulnérabilités confirmées avec leur criticité et prouvez une correction validée. Vous reliez les deux bouts du cycle : trouver vite, et réparer pour de bon.
Objectif : Industrialiser et fiabiliser l'évaluation.
Notions : Scanners, limites · Faux positifs
Défi : Livrer le rapport des 3 vulns confirmées (CVSS).
Attendus : Validé si trois vulnérabilités sont confirmées et cotées (CVSS) dans le rapport.
Objectif : Corriger durablement les failles web.
Notions : Requêtes paramétrées · Validation/encodage
Défi : Prouver la correction validée par SAST.
Attendus : Validé si la SQLi et le XSS sont corrigés et la correction validée par SAST.
Un en-tête HTTP malformé déclenche une exécution de code dans un cadre applicatif vulnérable.
Mission : Comprendre et tester une injection menant à exécution de code à distance.
Une falsification de requête côté serveur atteint le service de métadonnées de l'instance.
Mission : Exploiter une falsification de requête côté serveur jusqu'aux métadonnées cloud.
L'injection permet de déposer un webshell sur le serveur de transfert.
Mission : Chaîner une injection SQL et le dépôt d'un webshell dans un cadre autorisé.
L'API ne vérifie pas que l'objet demande appartient à l'appelant.
Mission : Tester les contrôles d'autorisation au niveau objet (référence directe non sécurisée).
Une chaîne consignée déclenche une résolution de ressource distante.
Mission : Exploiter une interpolation non maîtrisée menant à exécution de code.
Exploitation de vulnérabilités web avancées et sécurité des API modernes.
L'exécution de code à distance est le Graal de l'attaquant web : elle transforme une faille en contrôle de la machine. Cette brique vous fait l'obtenir par deux voies — téléversement non sécurisé chaîné à d'autres faiblesses, puis désérialisation exploitée via des chaînes d'objets (gadgets) construites avec ysoserial. Le défi : décrocher une exécution de code prouvée (la sortie d'une commande système). Vous reliez des failles isolées en une chaîne aboutissant au contrôle, ce qui révèle pourquoi la défense en profondeur compte.
Objectif : Obtenir une exécution de code à distance.
Notions : Upload non sécurisé · Chaînage
Défi : Obtenir une RCE (sortie de `id`).
Attendus : Validé si une RCE est obtenue (sortie de `id`).
Objectif : Exploiter une désérialisation pour RCE.
Notions : Gadgets · Chaînes d'exécution
Défi : Obtenir une RCE via désérialisation.
Attendus : Validé si une RCE est obtenue via désérialisation.
Quand les outils automatiques échouent et qu'un pare-feu applicatif veille, l'injection SQL devient un travail d'orfèvre. Cette brique vous fait exploiter manuellement les cas difficiles — injection à l'aveugle, par réponse booléenne ou par mesure du temps — puis contourner un pare-feu applicatif (WAF) par encodages et mutations de charge. Vous extrayez une donnée par injection temporelle et trouvez la mutation qui passe le WAF. Vous atteignez le niveau où l'attaque se fait à la main, là où la protection croyait avoir gagné.
Objectif : Exploiter là où les outils échouent.
Notions : Blind boolean/temporelle · WAF bypass
Défi : Extraire le drapeau via blind temporelle.
Attendus : Validé si le drapeau est extrait via une injection en aveugle temporelle.
Objectif : Échapper aux protections applicatives.
Notions : Encodages · Mutations de charge
Défi : Donner la mutation qui contourne le WAF.
Attendus : Validé si la mutation contournant le WAF est correctement identifiée.
Les applications modernes exposent l'essentiel de leur logique par des API — autant de portes souvent moins surveillées que l'interface web. Cette brique vous fait tester la sécurité d'API GraphQL (introspection du schéma, défauts d'autorisation par objet ou par fonction — BOLA/BFLA) et REST, à la lumière du Top 10 des risques d'API de l'OWASP. Vous accédez à la ressource d'un autre utilisateur et à une fonction d'administration sans en avoir le droit. Vous éprouvez la surface qui concentre aujourd'hui le plus de failles d'autorisation.
Objectif : Tester une API GraphQL.
Notions : Introspection · BOLA/BFLA
Défi : Accéder à la ressource d'un autre utilisateur (ID).
Attendus : Validé si le BOLA GraphQL donne accès à la ressource d'un autre utilisateur.
Objectif : Attaquer une API REST moderne.
Notions : OWASP API Top 10 · Rate limiting
Défi : Donner la fonction admin accessible sans droit.
Attendus : Validé si la fonction admin accessible sans droit est correctement identifiée.
Certaines fonctionnalités vont chercher une ressource à votre place — et peuvent être détournées pour atteindre ce qui vous est interdit. Cette brique vous fait exploiter la falsification de requête côté serveur (SSRF) — pousser le serveur à interroger des cibles internes — jusqu'à atteindre un service sensible. Le défi : lire les métadonnées d'un environnement cloud via la SSRF, voie classique vers la prise de contrôle d'une infrastructure. Vous comprenez comment une fonctionnalité anodine ouvre un pont vers le réseau interne.
Objectif : Exploiter une SSRF pour atteindre l'interne.
Notions : SSRF · Métadonnées cloud
Défi : Lire les métadonnées cloud via SSRF.
Attendus : Validé si la SSRF permet de lire les métadonnées cloud.
Toutes les failles ne sont pas techniques : certaines tiennent à la logique même de l'application, ou à la confiance qu'elle accorde au navigateur. Cette brique vous fait exploiter le côté client (JavaScript offensif, CSRF, vol de session avec BeEF) puis détourner la logique métier — failles de raisonnement, situations de concurrence (race conditions) — pour obtenir un gain indu. Vous exfiltrez le cookie d'une victime simulée et trouvez l'abus de logique qui accorde un avantage non prévu. Vous explorez des failles que les scanners ne voient pas, parce qu'elles relèvent du sens et non de la syntaxe.
Objectif : Exploiter la confiance côté client.
Notions : XSS avancé, CSRF · Vol de session
Défi : Exfiltrer le cookie de la victime simulée.
Attendus : Validé si le cookie de la victime simulée est exfiltré.
Objectif : Détourner la logique applicative.
Notions : Failles de logique · Race conditions
Défi : Donner l'abus de logique permettant un gain indu.
Attendus : Validé si l'abus de logique permettant un gain indu est démontré.
Un audit expert ne se résume pas à une liste de failles : il raconte comment leur enchaînement mène à un impact majeur. Cette brique vous fait restituer un audit web avancé en construisant la chaîne critique — comment des faiblesses combinées aboutissent à la compromission — et en formulant des remédiations à la hauteur. Le défi : livrer un rapport portant la chaîne d'impact complète. Vous transformez une expertise technique en démonstration compréhensible par ceux qui décident des correctifs.
Objectif : Restituer un audit web expert.
Notions : Chaînage d'impact · Remédiation
Défi : Livrer le rapport avec la chaîne critique complète.
Attendus : Validé si le rapport présente la chaîne critique complète et priorisée.
Une API exposée délivre des données sans authentification.
Mission : Auditer une API, ses défauts d'authentification et d'autorisation, et l'énumération massive.
Une requête forgée provoque une fuite de mémoire contenant des jetons.
Mission : Exploiter une lecture hors limites côté appliance et en extraire des secrets.
Une appliance combine un contournement d'authentification et une injection.
Mission : Chaîner contournement d'authentification et exécution sur une appliance.
La falsification de requête mène aux métadonnées puis aux jetons de rôle.
Mission : Pousser une falsification de requête vers la post-exploitation d'API cloud.
L'outil exposé une surface d'API et de téléversement exploitable.
Mission : Exploiter un applicatif de transfert via son API et sa surface de téléversement.
Compréhension des internes Windows et exploitation des faiblesses d'un environnement Active Directory.
Attaquer un domaine Active Directory commence par le connaître mieux que son administrateur. Cette brique vous fait énumérer un système et un domaine Windows — processus, jetons, contrôle de compte (UAC), services SMB/LDAP/Kerberos — avec PowerView et Impacket. Le défi : repérer un compte de service exposant un identifiant de service (SPN) exploitable. Vous dressez la carte interne qui rend toutes les attaques suivantes possibles — celle que le défenseur devrait connaître en premier.
Objectif : Énumérer un système et un domaine Windows.
Notions : Processus, jetons, UAC · SMB/LDAP/Kerberos
Défi : Donner le compte de service avec SPN exploitable.
Attendus : Validé si le compte de service à SPN exploitable est correctement identifié.
Kerberos, le protocole d'authentification d'Active Directory, recèle des faiblesses dans la façon dont il est souvent configuré. Cette brique vous fait exploiter deux d'entre elles avec Rubeus : le kerberoasting — demander des tickets de service pour casser hors-ligne les mots de passe des comptes associés — et l'AS-REP roasting, qui vise les comptes dont la pré-authentification a été désactivée. Vous récupérez un mot de passe kerberoasté et un compte AS-REP cassé. Vous comprenez pourquoi ces attaques restent si efficaces — et ce qui les neutralise.
Objectif : Compromettre des comptes de service Kerberos.
Notions : SPN, tickets · Cassage
Défi : Donner le mot de passe kerberoasté.
Attendus : Validé si le mot de passe kerberoasté est correct.
Objectif : Exploiter les comptes sans pré-auth.
Notions : AS-REP · Pré-auth désactivée
Défi : Donner le compte AS-REP cassé.
Attendus : Validé si le compte AS-REP est cassé et correctement identifié.
Sous Windows, on n'a pas toujours besoin du mot de passe en clair : son empreinte suffit parfois à se déplacer. Cette brique vous fait latéraliser par réutilisation d'empreinte d'authentification (pass-the-hash), via WMI et WinRM avec CrackMapExec, puis exécuter du code en mémoire en contournant les défenses intégrées de Windows (AMSI, journalisation ETW). Vous prouvez l'exécution sur un second hôte et réussissez une technique d'évasion. Vous touchez aux gestes qui font qu'une compromission d'un poste devient celle de tout un parc.
Objectif : Latéraliser sans mot de passe.
Notions : PtH · WMI/WinRM
Défi : Prouver l'exécution sur un second hôte.
Attendus : Validé si l'exécution sur un second hôte par pass-the-hash est prouvée.
Objectif : Exécuter du code en mémoire discrètement.
Notions : PS offensif · AMSI/ETW
Défi : Donner la technique d'évasion réussie.
Attendus : Validé si la charge s'exécute en mémoire et si la technique d'évasion réussie est nommée.
Dans Active Directory, des droits accordés trop largement et des délégations mal configurées ouvrent des chemins d'attaque invisibles à l'œil nu. Cette brique vous fait exploiter les délégations Kerberos (contrainte, non contrainte, basée sur les ressources — RBCD) et les abus de droits d'accès (ACL) — un GenericAll ou un WriteDACL mal placé. Vous identifiez le type de délégation exploité et l'ACL qui mène à votre cible. Vous révélez la classe de failles que des outils comme BloodHound rendent cartographiables, et que les administrateurs sous-estiment.
Objectif : Abuser des délégations mal configurées.
Notions : Délégation contrainte/non contrainte · RBCD
Défi : Donner le type de délégation exploité.
Attendus : Validé si la délégation est exploitée et si son type est correctement identifié.
Objectif : Exploiter des droits excessifs.
Notions : ACE, GenericAll/WriteDACL · Chemins
Défi : Donner l'ACL exploitée et la cible atteinte.
Attendus : Validé si l'ACL est exploitée et si l'ACL et la cible atteinte sont correctes.
Une fois entré, un attaquant cherche à le rester — discrètement — et à transformer une authentification volée en accès. Cette brique vous fait installer une persistance Windows furtive (tâches, services, clés de registre) puis monter une attaque par coercition et relais NTLM : forcer une machine à s'authentifier, puis rejouer cette authentification ailleurs (avec ntlmrelayx et Coercer). Vous désignez le mécanisme de persistance le plus furtif et prouvez un relais réussi et son impact. Vous comprenez deux techniques que les équipes de défense peinent encore à détecter.
Objectif : Maintenir un accès discret.
Notions : Tâches/services · Clés de registre
Défi : Donner le mécanisme de persistance le plus furtif.
Attendus : Validé si deux persistances sont établies et si la plus furtive est correctement désignée.
Objectif : Forcer une authentification et la relayer.
Notions : Coercition · Relais NTLM
Défi : Prouver le relais réussi et son impact.
Attendus : Validé si le relais NTLM réussit et si son impact est prouvé.
Tout le travail offensif sur Active Directory n'a de sens, ici, que pour mieux le défendre. Cette brique relie l'attaque à la parade : modèle en niveaux (tiering) qui cloisonne les privilèges, gestion automatique des mots de passe administrateurs locaux (LAPS), comptes de service gérés (gMSA), et détections associées. Le défi : nommer les trois mesures qui briseraient la chaîne d'attaque construite dans les briques précédentes. Vous bouclez le module en attaquant pour défendre, ce qui est la raison d'être d'une équipe rouge.
Objectif : Relier offensive et défense.
Notions : Tiering, LAPS, gMSA · Détections
Défi : Donner les 3 mesures qui briseraient la chaîne.
Attendus : Validé si les trois mesures brisant la chaîne d'attaque sont correctement identifiées.
L'acteur prend la main sur l'environnement d'identité puis sur le domaine.
Mission : Conduire une élévation de privilèges dans un environnement Active Directory hybride.
L'acteur collecte des identifiants pour circuler vers les actifs critiques.
Mission : Mettre en œuvre le déplacement latéral Windows et le vol d'identifiants.
Des jetons forgés ouvrent l'accès à des ressources cloud.
Mission : Abuser de jetons et d'authentification dans un contexte cloud-hybride.
Le détournement de session fournit un premier accès interne.
Mission : Prendre un appui par détournement de session puis progresser sous Windows.
L'acteur abuse d'outils intégrés (gestion, copie de bases d'annuaire) pour rester furtif.
Mission : Employer des techniques de persistance et de collecte furtives propres à Windows.
Conduite d'une opération offensive réaliste contre un domaine Active Directory : intrusion, latéralisation, domination, persistance.
Une opération de red team ressemble à une attaque réelle : elle commence loin de la cible et progresse en restant invisible. Cette brique vous fait, sur un environnement d'entraînement représentatif (GOAD), reconnaître une entreprise puis obtenir et stabiliser un premier point d'appui — en gérant un canal de commande (C2) et la discrétion opérationnelle (OPSEC). Vous désignez le service d'accès initial visé et le point d'appui obtenu. Vous adoptez la posture d'un adversaire patient et méthodique, celle que les défenses doivent apprendre à détecter.
Objectif : Cartographier la cible avant intrusion.
Notions : Recon externe/interne · Surface AD
Défi : Donner le service d'accès initial visé.
Attendus : Validé si la surface AD est reconnue et si le service d'accès initial visé est pertinent.
Objectif : Obtenir et stabiliser un premier accès.
Notions : Vecteurs d'accès · C2, OPSEC
Défi : Donner le point d'appui (hôte+utilisateur).
Attendus : Validé si l'agent C2 est déployé et si le point d'appui (hôte+utilisateur) est fourni.
Dans un grand domaine, le chemin qui mène d'un simple compte au contrôle total existe presque toujours — encore faut-il le voir. Cette brique vous fait cartographier ces chemins d'attaque avec BloodHound et SharpHound, qui représentent objets, droits et relations d'Active Directory sous forme de graphe. Le défi : trouver le chemin le plus court vers l'administrateur du domaine et l'arête (relation) décisive. Vous adoptez l'outil qui a transformé l'attaque comme la défense d'Active Directory en analyse de graphe.
Objectif : Cartographier les chemins vers Domain Admin.
Notions : Objets AD, ACL · Chemins courts
Défi : Donner le chemin le plus court vers DA et l'arête clé.
Attendus : Validé si le chemin le plus court vers DA et l'arête clé sont correctement identifiés.
Sur une machine compromise, les identifiants des utilisateurs connectés sont souvent récupérables — directement en mémoire. Cette brique vous fait extraire ces secrets (empreintes, tickets Kerberos) depuis le processus LSASS avec Mimikatz, en composant avec les protections mémoire modernes, puis compromettre des comptes de service par kerberoasting. Vous récupérez l'empreinte NTLM d'un compte privilégié et le mot de passe d'un compte de service. Vous comprenez pourquoi protéger les identifiants en mémoire est devenu un enjeu central de la défense Windows.
Objectif : Extraire des secrets d'un hôte compromis.
Notions : LSASS, tickets · Protection mémoire
Défi : Donner le hash NTLM d'un compte privilégié extrait.
Attendus : Validé si les secrets mémoire sont extraits et si le hachage NTLM d'un compte privilégié est correct.
Objectif : Compromettre des comptes de service.
Notions : SPN, tickets de service · Cassage
Défi : Donner le compte de service et le mot de passe.
Attendus : Validé si le ticket est cassé et si le compte de service et son mot de passe sont corrects.
Entre le premier poste compromis et le contrôle du domaine, il y a une succession de rebonds et d'élévations. Cette brique vous fait enchaîner mouvement latéral — par réutilisation d'empreinte ou de ticket (pass-the-hash, pass-the-ticket), via WMI/WinRM — et élévation vers l'administrateur du domaine en abusant droits et délégations, avec Impacket et Rubeus. Vous prouvez l'exécution sur un second hôte puis l'obtention des droits d'administrateur du domaine. Vous reconstituez la progression complète qu'une équipe de défense doit pouvoir retracer après coup.
Objectif : Latéraliser via PtH/PtT.
Notions : Pass-the-hash/ticket · WMI/WinRM
Défi : Prouver l'exécution sur un second hôte.
Attendus : Validé si l'exécution sur un second hôte est prouvée.
Objectif : Atteindre le contrôle du domaine.
Notions : ACL abuse · Délégation
Défi : Prouver l'obtention des droits Domain Admin.
Attendus : Validé si les droits Domain Admin sont obtenus et la chaîne documentée.
Le contrôle total d'un domaine ne se mesure pas à un accès, mais à la capacité d'en extraire tous les secrets et d'y revenir à volonté. Cette brique vous fait exécuter une attaque DCSync — se faire passer pour un contrôleur de domaine afin d'en répliquer les secrets, dont l'empreinte du compte krbtgt — puis forger une persistance furtive (Golden Ticket). Vous récupérez l'empreinte du compte krbtgt et, surtout, identifiez la détection recommandée d'un Golden Ticket. Vous atteignez le sommet de l'attaque AD, où comprendre l'offensive est la seule façon de bâtir la détection.
Objectif : Extraire les secrets du domaine.
Notions : DCSync, krbtgt · Réplication
Défi : Donner le hash du compte krbtgt.
Attendus : Validé si le DCSync aboutit et si le hachage du compte krbtgt est correct.
Objectif : Conserver le contrôle (Golden Ticket).
Notions : Golden/Silver Ticket · Persistance furtive
Défi : Donner la détection recommandée du Golden Ticket.
Attendus : Validé si le Golden Ticket est démontré et si la détection recommandée est pertinente.
Atteindre un réseau segmenté depuis un poste compromis suppose de creuser un tunnel — et de le faire sans se faire repérer. Cette brique vous fait pivoter à travers les segments (redirection de ports, proxy SOCKS avec Chisel) puis affiner votre discrétion opérationnelle face aux défenses modernes (contournement d'AMSI et de la journalisation ETW, furtivité du canal de commande). Vous atteignez un hôte d'un réseau segmenté et réussissez une technique d'évasion. Vous reliez accès et invisibilité, les deux exigences d'une opération offensive réaliste — donc d'un test qui prépare vraiment la défense.
Objectif : Atteindre des réseaux segmentés.
Notions : Pivot, port forwarding · SOCKS
Défi : Donner l'hôte du réseau segmenté atteint.
Attendus : Validé si le pivot est établi et si l'hôte du réseau segmenté atteint est correct.
Objectif : Échapper aux défenses modernes.
Notions : AMSI/ETW bypass · Discrétion C2
Défi : Donner la technique d'évasion qui a réussi.
Attendus : Validé si la protection est contournée et si la technique d'évasion réussie est nommée.
L'intrusion part d'un appel au support et aboutit au contrôle de l'environnement d'identité et du domaine.
Mission : Simuler une opération Red Team partant de l'ingénierie sociale jusqu'au contrôleur de domaine.
Après une entrée par accès distant sans double authentification, l'acteur progresse vers les actifs critiques.
Mission : Rejouer un scénario de déplacement latéral et d'élévation de privilèges en environnement Active Directory.
L'acteur n'emploie que des outils système pour rester indétecté.
Mission : Conduire une opération Red Team furtive fondée sur la vie sur le terrain.
Des jetons forgés donnent accès à des ressources cloud d'organisations.
Mission : Exploiter l'abus de jetons et d'identité dans un environnement Active Directory hybride.
Le détournement de session fournit un point d'entrée vers le réseau interne.
Mission : Prendre un appui initial par détournement de session puis progresser dans l'annuaire.
Compréhension de l'exécution bas niveau et écriture de shellcodes et d'exploits simples.
Le développement d'exploits commence là où l'abstraction s'arrête : dans la mémoire et les registres du processeur. Cette brique vous fait comprendre l'organisation de la mémoire d'un programme (pile, tas, registres) et les débordements qui s'y produisent, puis lire et écrire de l'assembleur x86. Le défi : trouver le décalage (offset) exact qui permet d'écraser l'adresse de retour, et identifier un appel système. Vous posez les fondations sans lesquelles aucune exploitation bas niveau n'est compréhensible.
Objectif : Maîtriser la mémoire pour l'exploitation.
Notions : Pile/tas, registres · Débordements
Défi : Donner l'offset pour écraser l'adresse de retour.
Attendus : Validé si le débordement est maîtrisé et si l'offset de l'adresse de retour est correct.
Objectif : Lire et écrire de l'assembleur.
Notions : Registres, instructions · Syscalls
Défi : Donner le numéro de l'appel système exécuté.
Attendus : Validé si l'assembleur est lu/écrit et si le numéro d'appel système est correct.
Prendre le contrôle d'un programme ne sert à rien sans une charge à exécuter : c'est le rôle du shellcode, un fragment de code machine autonome. Cette brique vous fait écrire un shellcode fonctionnel en assembleur (NASM), en respectant des contraintes strictes — notamment l'absence d'octets nuls qui interromprait sa copie. Le défi : fournir un shellcode sans octet nul et donner sa taille. Vous apprenez à fabriquer, octet par octet, la charge utile que livrera votre exploit.
Objectif : Écrire un shellcode null-free.
Notions : Shellcode execve · Contraintes null-free
Défi : Fournir un shellcode null-free et sa taille.
Attendus : Validé si le shellcode /bin/sh s'exécute, sans octet nul, et sa taille fournie.
Deux des vulnérabilités fondatrices de l'exploitation logicielle se travaillent ici de bout en bout. Cette brique vous fait assembler un exploit complet de débordement de pile — prise de contrôle du pointeur d'instruction, glissière de NOP — puis exploiter une vulnérabilité de chaîne de format, qui offre une lecture et une écriture arbitraires en mémoire. Vous obtenez un shell sur un binaire vulnérable et écrasez une adresse choisie via la chaîne de format. Vous transformez une faiblesse mémoire en contrôle d'exécution, le cœur du métier.
Objectif : Assembler un exploit complet.
Notions : Contrôle d'EIP · NOP sled
Défi : Obtenir un shell sur le binaire vulnérable.
Attendus : Validé si un shell est obtenu sur le binaire vulnérable.
Objectif : Exploiter une vulnérabilité de format string.
Notions : Format string · Lecture/écriture arbitraire
Défi : Donner l'adresse écrasée via format string.
Attendus : Validé si l'adresse écrasée via format string est correcte.
Trouver une faille dans un binaire dont on n'a pas le code source demande deux approches complémentaires : l'analyser, et le bombarder d'entrées. Cette brique vous fait d'abord rétro-concevoir un binaire inconnu pour en comprendre la logique, puis construire un fuzzer simple — un outil qui génère des entrées aléatoires jusqu'à provoquer un plantage révélateur. Vous localisez une fonction de vérification et trouvez l'entrée qui fait planter le programme. Vous reliez compréhension et découverte, les deux voies vers une vulnérabilité exploitable.
Objectif : Analyser un binaire inconnu.
Notions : Flux de contrôle · Identification de logique
Défi : Donner l'adresse de la fonction de vérification.
Attendus : Validé si l'adresse de la fonction de vérification est correcte.
Objectif : Trouver des plantages automatiquement.
Notions : Fuzzing · Détection de crash
Défi : Donner l'entrée provoquant le crash.
Attendus : Validé si le fuzzer trouve l'entrée provoquant le crash.
Développer un exploit à la main est instructif ; le fiabiliser et le rejouer exige un outillage. Cette brique vous fait outiller la création d'exploits avec pwntools, qui automatise l'interaction avec le binaire cible, puis identifier les protections modernes qu'un exploit devra contourner : canari de pile, mémoire non exécutable (NX), aléa d'adresses (ASLR/PIE). Vous livrez un exploit pwntools fonctionnel et dressez la liste des mitigations actives. Vous reliez la fabrication de l'exploit à la connaissance des défenses qui se dressent en face.
Objectif : Outiller la création d'exploits.
Notions : pwntools · Automatisation
Défi : Fournir l'exploit pwntools fonctionnel.
Attendus : Validé si l'exploit pwntools est fiable et fonctionnel.
Objectif : Comprendre les protections à contourner.
Notions : Stack canary, NX · ASLR/PIE
Défi : Lister les mitigations actives du binaire.
Attendus : Validé si les mitigations actives du binaire sont correctement listées.
Une interpolation non maîtrisée mène à une exécution de code applicative.
Mission : Construire un démonstrateur d'exploitation applicative à partir de la primitive.
Une injection SQL inédite ouvre la voie à l'exécution de code.
Mission : Développer un exploit d'injection menant à l'exécution de code.
Une lecture hors limites révèle le contenu de la mémoire de l'appliance.
Mission : Écrire un exploit de divulgation mémoire (lecture hors limites) et fiabiliser l'extraction.
Deux primitives distinctes se combinent en une exécution à distance.
Mission : Assembler une chaîne d'exploitation à partir de deux primitives.
L'avis de sécurité décrit la faille avant qu'elle ne soit exploitée en masse.
Mission : Rétro-concevoir une exécution de code à partir d'un avis de sécurité et écrire le déclencheur.
Contournement des mitigations modernes et exploitation de la pile et du tas sous protections.
Après la pile, le tas : la zone de mémoire allouée dynamiquement, dont la corruption ouvre des exploitations plus subtiles. Cette brique vous fait exploiter la corruption du tas en comprenant le fonctionnement de l'allocateur (les blocs, ou chunks) et les bugs classiques — usage après libération (use-after-free), double libération. Le défi : exécuter une fonction cachée en corrompant le tas. Vous franchissez un palier de difficulté, là où l'exploitation devient une partie d'échecs contre la gestion de la mémoire.
Objectif : Exploiter la corruption du tas.
Notions : Allocateur, chunks · UAF/double free
Défi : Exécuter la fonction cachée via corruption de tas.
Attendus : Validé si la corruption de tas exécute la fonction cachée.
Quand la mémoire de données ne peut plus être exécutée (protection DEP/NX), on n'injecte plus de code : on réutilise celui qui est déjà là. Cette brique vous fait construire une chaîne de programmation orientée retour (ROP) — un assemblage de fragments de code existants (gadgets) qui, mis bout à bout, réalisent l'action voulue, comme rendre une zone exécutable via mprotect. Le défi : fournir la chaîne ROP qui ouvre un shell. Vous apprenez la technique qui a redonné vie à l'exploitation face à une protection majeure.
Objectif : Construire une chaîne ROP.
Notions : DEP/NX, gadgets · mprotect
Défi : Fournir la chaîne ROP ouvrant un shell.
Attendus : Validé si la chaîne ROP ouvre un shell.
L'aléa d'adresses (ASLR) empêche de savoir où se trouve le code à réutiliser — sauf si une fuite d'information le révèle. Cette brique vous fait vaincre l'ASLR en exploitant une fuite pour retrouver l'adresse de la bibliothèque C (technique du retour-vers-libc), puis détourner la table des fonctions importées (GOT) via une chaîne de format. Vous calculez la base de la libc pour obtenir un shell et redirigez la GOT vers votre code. Vous combinez plusieurs primitives pour défaire une protection que l'on croyait suffisante.
Objectif : Vaincre l'ASLR par fuite.
Notions : ASLR/PIE · ret2libc
Défi : Donner la base libc et obtenir un shell.
Attendus : Validé si la base libc est trouvée et un shell obtenu (ret2libc).
Objectif : Obtenir lecture/écriture arbitraire.
Notions : Format string · GOT overwrite
Défi : Détourner la GOT et exécuter du code.
Attendus : Validé si la GOT est détournée et du code exécuté.
Certaines failles n'existent qu'un instant : entre le moment où un programme vérifie une condition et celui où il agit. Cette brique vous fait exploiter une telle situation de concurrence (TOCTOU — vérifier puis utiliser) sur un binaire privilégié, puis aborder l'exploitation du noyau Linux et ses primitives. Le défi : obtenir les droits root via la course, et décrire la primitive noyau obtenue. Vous touchez à deux frontières avancées de l'exploitation, là où le temps et le cœur du système deviennent le terrain de jeu.
Objectif : Exploiter une race condition.
Notions : TOCTOU · SUID
Défi : Obtenir root via la race SUID.
Attendus : Validé si root est obtenu via l'exploitation de la race condition SUID.
Objectif : Comprendre l'exploitation kernel Linux.
Notions : Espaces user/kernel · Primitives kernel
Défi : Donner la primitive kernel obtenue.
Attendus : Validé si la primitive kernel obtenue est correctement décrite.
Windows a empilé, au fil des versions, des protections qui rendent l'exploitation bien plus ardue qu'autrefois. Cette brique vous fait étudier et contourner ces mitigations modernes — intégrité du flux de contrôle (CFG), pile renforcée par le matériel (CET), gestion des exceptions (SEH) — avec le débogueur WinDbg. Le défi : identifier la mitigation contournée dans le scénario. Vous mesurez l'état réel de l'art côté Windows, où chaque protection appelle une parade de plus en plus sophistiquée.
Objectif : Contourner les mitigations Windows.
Notions : CFG, CET · SEH
Défi : Donner la mitigation contournée.
Attendus : Validé si la mitigation Windows contournée est correctement nommée.
Un exploit qui marche une fois sur dix n'est pas une arme, c'est une curiosité de laboratoire. Cette brique vous fait fiabiliser un exploit pour un usage réel — taux de réussite stable, nettoyage des traces — puis assembler une chaîne complète, du bug initial jusqu'aux droits root. Vous mesurez le taux de réussite obtenu et démontrez une compromission de bout en bout. Vous atteignez l'aboutissement du développement d'exploits : une démonstration fiable et reproductible, qui établit sans ambiguïté la réalité d'un risque.
Objectif : Fiabiliser un exploit pour usage réel.
Notions : Fiabilité multi-essais · Nettoyage
Défi : Donner le taux de réussite mesuré.
Attendus : Validé si le taux de réussite de l'exploit fiabilisé est mesuré.
Objectif : Assembler une chaîne de bout en bout.
Notions : Chaînage · Du bug au root
Défi : Obtenir root via la chaîne complète.
Attendus : Validé si root est obtenu via la chaîne d'exploitation complète.
Un dépassement d'entier dans un décodeur d'images sert de base à une exploitation sans interaction.
Mission : Étudier une primitive avancée (dépassement d'entier vers calcul arbitraire) à un niveau conceptuel rigoureux.
L'implant se déclenche au chargement du démon SSH via un mécanisme détourné.
Mission : Analyser une porte dérobée avancée et son déclenchement, et reconstituer son intégration.
Une troncature de préfixe affaiblit la session après l'échange de clés.
Mission : Concevoir, en laboratoire, une attaque au niveau protocole et en mesurer les conditions.
Le maliciel reprogramme des automates de sécurité via un protocole propriétaire.
Mission : Étudier l'exploitation d'un automate de sûreté à un niveau avancé, en laboratoire.
La divulgation mémoire fournit des jetons réutilisables.
Mission : Pousser une exploitation mémoire jusqu'à la reconstitution d'une session complète.
Émulation d'adversaire, écriture de détections et validation continue de la couverture (purple teaming).
Pour savoir si une défense fonctionne, rien ne vaut de la confronter à de vraies techniques d'attaque — sous contrôle. Cette brique vous fait émuler un adversaire : rejouer des techniques ATT&CK atomiques avec Atomic Red Team, puis jouer une chaîne d'attaque automatisée et confinée avec Caldera. Vous identifiez une technique exécutée mais non détectée et obtenez le rapport situant l'étape de détection. Vous mesurez la défense par l'épreuve plutôt que par hypothèse — le principe fondateur du purple teaming.
Objectif : Rejouer des techniques ATT&CK contrôlées.
Notions : Émulation vs simulation · Tests atomiques
Défi : Donner la technique exécutée non détectée.
Attendus : Validé si la couverture est cartographiée et si la technique non détectée est correctement désignée.
Objectif : Jouer une chaîne d'attaque automatisée.
Notions : Abilities, adversary profiles · Confinement
Défi : Fournir le rapport Caldera et l'étape de détection.
Attendus : Validé si l'opération Caldera est jouée et si le rapport et l'étape de détection sont fournis.
Découvrir une lacune de détection ne sert à rien si l'on ne la comble pas et n'en garde pas la trace. Cette brique vous fait écrire des détections pour les angles morts révélés par l'émulation — gérées comme du code, testées en intégration continue — puis suivre l'avancement d'une campagne purple avec VECTR. Vous mesurez le gain de couverture après ajout d'une détection et le score final de la campagne. Vous bouclez le cycle vertueux du purple : attaquer, mesurer le manque, le combler, vérifier.
Objectif : Écrire des détections pour les lacunes.
Notions : Cycle purple · CI de détection
Défi : Donner le gain de couverture après ajout.
Attendus : Validé si une détection est écrite par lacune et si le gain de couverture est mesuré.
Objectif : Suivre les campagnes purple.
Notions : Scoring de détection · Campagnes
Défi : Donner le score de détection final de la campagne.
Attendus : Validé si la campagne est suivie et si le score de détection final est correct.
Émuler une technique isolée est utile ; reproduire le mode opératoire complet d'un acteur réel l'est davantage. Cette brique vous fait construire un plan d'émulation fidèle à un acteur de menace documenté, puis valider l'efficacité réelle de vos contrôles de sécurité par une simulation continue (BAS — validation automatisée de la défense). Vous donnez les trois techniques signatures de l'acteur émulé et identifiez le contrôle qui s'avère inefficace. Vous éprouvez votre défense face à un adversaire crédible, pas face à une menace abstraite.
Objectif : Reproduire le mode opératoire d'un acteur.
Notions : Threat-informed · Plan d'émulation
Défi : Donner les 3 TTP signatures de l'acteur émulé.
Attendus : Validé si l'acteur est émulé et si ses trois TTP signatures sont correctement identifiées.
Objectif : Tester l'efficacité réelle des contrôles.
Notions : BAS · Contrôles préventifs/détectifs
Défi : Donner le contrôle inefficace identifié.
Attendus : Validé si l'efficacité est mesurée et si le contrôle inefficace est correctement identifié.
Le purple teaming atteint son sommet quand équipes offensive et défensive travaillent ensemble, en temps réel, plutôt que chacune de son côté. Cette brique vous fait conduire un exercice purple conjoint — l'attaque et la détection se répondent en direct — puis en tirer une revue après action (AAR) actionnable. Vous identifiez l'angle mort le plus critique observé et produisez un AAR assorti de trois améliorations et de leurs responsables. Vous transformez une confrontation en progrès partagé, ce qui est toute la valeur de la démarche.
Objectif : Conduire un exercice red/blue temps réel.
Notions : Coordination temps réel · Injects
Défi : Donner l'angle mort le plus critique observé.
Attendus : Validé si l'exercice conjoint est joué et si l'angle mort le plus critique est identifié.
Objectif : Produire un AAR actionnable.
Notions : AAR · Plan d'amélioration
Défi : Fournir l'AAR avec 3 améliorations et propriétaires.
Attendus : Validé si l'AAR fournit trois améliorations avec leurs propriétaires.
Produire des détections à la main ne tient pas le rythme des menaces : il faut industrialiser. Cette brique vous fait construire un pipeline d'ingénierie de détection — où chaque règle est testée automatiquement à chaque modification, comme du code logiciel. Le défi : livrer le pipeline qui valide les règles à chaque commit. Vous appliquez à la détection les pratiques d'ingénierie qui en garantissent la qualité et la pérennité, au-delà du coup par coup.
Objectif : Industrialiser la production de détections.
Notions : Pipeline détection · Tests automatisés
Défi : Fournir le pipeline validant les règles à chaque commit.
Attendus : Validé si le pipeline valide les règles à chaque commit.
L'exploitation des passerelles aboutit au vol de jetons de session.
Mission : Émuler l'exploitation en laboratoire puis écrire et valider la détection correspondante.
L'exploit JNDI est simple à rejouer en environnement contrôle.
Mission : Rejouer l'exploit en laboratoire et mesurer la couverture de détection existante.
Les techniques reposent sur l'ingénierie sociale et l'abus de comptes.
Mission : Émuler les techniques d'abus d'identité et combler les angles morts de détection.
Les techniques de vie sur le terrain échappent aux signatures classiques.
Mission : Tester la détection des comportements de vie sur le terrain et affiner les règles.
Compréhension des systèmes industriels, de leurs protocoles et de leurs enjeux de sécurité.
En informatique de gestion, on protège d'abord la confidentialité ; dans l'industrie, c'est la sûreté des personnes et la disponibilité du procédé qui priment — une inversion qui change tout. Cette brique vous fait situer les composants d'un système industriel (automate programmable — PLC, supervision SCADA, interface opérateur — IHM) dans le modèle de Purdue, qui hiérarchise les niveaux d'un réseau industriel. Le défi : placer un automate au bon niveau de Purdue. Vous adoptez la grille de lecture qui structure toute la sécurité des systèmes industriels.
Objectif : Situer les composants ICS et leurs priorités.
Notions : Priorités sûreté/dispo · DCS/SCADA, IHM/RTU/PLC
Défi : Donner le niveau Purdue du PLC.
Attendus : Validé si la chaîne est cartographiée selon Purdue et si le niveau du PLC est correct.
Les protocoles qui pilotent usines et réseaux électriques ont été conçus pour la fiabilité, à une époque où la sécurité n'était pas un sujet : beaucoup n'authentifient rien. Cette brique vous fait analyser Modbus — et constater qu'une commande y est acceptée sans aucune vérification d'identité — puis les protocoles de l'énergie (DNP3, IEC-104). Vous lisez la valeur d'un registre de niveau de cuve et identifiez une commande de contrôle observée. Vous comprenez pourquoi la sécurité industrielle se joue d'abord sur des protocoles intrinsèquement vulnérables.
Objectif : Analyser Modbus et son absence de sécurité.
Notions : Modbus, fonctions · Pas d'authentification
Défi : Donner la valeur du registre de niveau de cuve.
Attendus : Validé si Modbus est analysé et si la valeur du registre de niveau de cuve est correcte.
Objectif : Comprendre les protocoles d'énergie.
Notions : DNP3, IEC-104 · Télémétrie/commandes
Défi : Donner la commande de contrôle observée.
Attendus : Validé si la commande de contrôle DNP3 observée est correctement identifiée.
En milieu industriel, on ne peut pas tout corriger ni tout arrêter : la première défense est de cloisonner. Cette brique vous fait segmenter un environnement OT selon les zones et conduits du référentiel IEC 62443 — la norme de sécurité des systèmes industriels — puis déployer un leurre industriel (honeypot, avec Conpot) pour détecter une sonde. Vous désignez la zone à isoler en priorité et l'adresse qui a sondé le leurre. Vous appliquez les deux parades qui protègent un procédé qu'on ne peut ni corriger ni interrompre librement.
Objectif : Segmenter un environnement OT.
Notions : Zones/conduits · Segmentation OT
Défi : Donner la zone à isoler en priorité.
Attendus : Validé si zones et conduits sont définis et si la zone à isoler en priorité est justifiée.
Objectif : Détecter par leurre industriel.
Notions : Honeypot OT · Détection de sonde
Défi : Donner l'IP ayant sondé le honeypot OT.
Attendus : Validé si le honeypot est déployé et si l'IP l'ayant sondé est correctement relevée.
En sécurité industrielle, un risque ne se mesure pas en données perdues mais en conséquences physiques : une fuite, un arrêt de production, un danger pour des vies. Cette brique vous fait conduire une évaluation de risque OT avec l'outil CSET, en raisonnant d'abord sur l'impact physique des scénarios. Le défi : désigner le scénario au plus fort impact physique. Vous apprenez à hiérarchiser les risques industriels selon ce qui compte vraiment dans ce monde : la sûreté avant tout.
Objectif : Évaluer le risque avec impact physique.
Notions : Conséquences physiques · Méthodologie
Défi : Donner le scénario à plus fort impact physique.
Attendus : Validé si l'évaluation est menée et si le scénario à plus fort impact physique est correct.
On ne défend pas un parc industriel qu'on ne connaît pas — mais l'inventorier ne doit jamais perturber le procédé. Cette brique vous fait découvrir passivement les actifs d'un réseau OT, c'est-à-dire les identifier sans émettre de trafic risqué, puis durcir un automate et son accès opérateur. Vous identifiez le modèle d'un automate découvert et la mesure de durcissement à appliquer en priorité. Vous intégrez la contrainte fondatrice de l'OT : agir sans jamais mettre la production en danger.
Objectif : Inventorier sans perturber le procédé.
Notions : Découverte passive · Identification d'équipements
Défi : Donner le modèle de PLC découvert.
Attendus : Validé si la découverte passive aboutit et si le modèle de PLC est correct.
Objectif : Sécuriser un PLC et son accès.
Notions : Durcissement PLC · Accès IHM
Défi : Donner la mesure de durcissement prioritaire.
Attendus : Validé si le durcissement est appliqué et si la mesure prioritaire est correctement désignée.
Une intrusion partie de la bureautique atteint les postes de conduite et coupe l'électricité de quelque 230 000 foyers.
Mission : Comprendre l'architecture d'un système industriel et la manière dont une attaque informatique atteint l'opérationnel.
L'exploitant arrête la distribution par précaution alors que l'attaque touche la partie informatique.
Mission : Distinguer l'impact informatique de l'arrêt opérationnel décidé par précaution, et saisir les enjeux de continuité.
Investigation et réponse à incident dans un environnement industriel sous contrainte de sûreté.
Investiguer un incident industriel impose une règle que la forensique classique ignore : ne jamais compromettre la sûreté du procédé pour collecter une preuve. Cette brique vous fait acquérir des preuves en OT dans cet ordre contraint, puis analyser le trafic pour détecter une manipulation du procédé par rapport à une activité de référence. Vous désignez la source de preuve à privilégier d'abord et la commande Modbus malveillante. Vous adaptez l'investigation à un environnement où une fausse manœuvre peut avoir des conséquences physiques.
Objectif : Collecter sans perturber le procédé.
Notions : Contraintes de sûreté · Ordre de volatilité OT
Défi : Donner la source de preuve à privilégier d'abord.
Attendus : Validé si le plan est non intrusif et si la source de preuve à privilégier est correcte.
Objectif : Détecter une manipulation de procédé.
Notions : Baseline OT · Commandes anormales
Défi : Donner la commande Modbus malveillante.
Attendus : Validé si l'anomalie est détectée et si la commande Modbus malveillante est correcte.
Les attaques industrielles les plus graves ne volent pas des données : elles modifient le programme d'un automate pour agir sur le monde physique. Cette brique vous fait investiguer un automate compromis — repérer une modification de sa logique de programme — puis caractériser un malware spécialisé dans l'OT. Vous identifiez la modification du programme de l'automate et le protocole industriel ciblé par le malware, avec l'effet visé. Vous touchez au cœur de ce qui distingue une cyberattaque industrielle : son but est physique.
Objectif : Investiguer un automate compromis.
Notions : Logique d'automate · Modification de programme
Défi : Donner la modification du programme PLC détectée.
Attendus : Validé si la comparaison aboutit et si la modification du programme PLC est correctement identifiée.
Objectif : Caractériser un malware OT.
Notions : Familles ICS · Indicateurs OT
Défi : Donner le protocole OT ciblé et l'effet visé.
Attendus : Validé si le protocole OT ciblé et l'effet visé sont corrects.
Reconstituer un incident industriel, c'est croiser deux mondes : les traces informatiques et les valeurs physiques du procédé. Cette brique vous fait reconstruire la chronologie d'un incident OT puis détecter un écart physique anormal — une valeur de capteur falsifiée pour masquer une manipulation, comme dans les attaques les plus marquantes contre l'industrie. Vous datez le vecteur d'accès initial et identifiez le capteur dont la valeur a été truquée. Vous apprenez à lire un incident là où le numérique et le physique se rencontrent.
Objectif : Reconstituer la séquence d'un incident.
Notions : Corrélation multi-sources · Timeline
Défi : Donner l'heure et le vecteur d'accès initial.
Attendus : Validé si la chronologie est cohérente et si l'heure et le vecteur d'accès initial sont corrects.
Objectif : Repérer un écart physique anormal.
Notions : Valeurs de procédé · Seuils de sûreté
Défi : Donner le capteur dont la valeur a été falsifiée.
Attendus : Validé si le dépassement est détecté et si le capteur falsifié est correctement identifié.
En réponse à incident industrielle, l'action la plus évidente — couper, isoler — peut être la plus dangereuse si elle déstabilise un procédé physique. Cette brique vous fait confiner un incident OT d'une manière compatible avec la sûreté, en coordination IT/OT, puis ramener le procédé à un état sûr avant toute remise en service. Vous choisissez le confinement qui n'introduit pas de risque et l'ordre de reprise sécurisé. Vous intégrez la priorité absolue de l'OT : protéger les personnes et le procédé avant la donnée.
Objectif : Confiner sans risque physique.
Notions : Confinement compatible sûreté · Coordination IT/OT
Défi : Donner le confinement n'introduisant pas de risque.
Attendus : Validé si le confinement appliqué n'introduit pas de risque physique.
Objectif : Restaurer le procédé en sécurité.
Notions : État sûr · Validation avant remise
Défi : Donner l'ordre de reprise sécurisé.
Attendus : Validé si la reprise est planifiée et si l'ordre de reprise sécurisé est correct.
Un retour d'expérience industriel ne se juge pas à sa technicité, mais à sa capacité à éviter le prochain incident — et le prochain danger. Cette brique vous fait restituer un incident OT dans un rapport orienté sûreté, puis en tirer des leçons concrètes. Le défi : livrer un rapport assorti de trois améliorations priorisées. Vous transformez un incident industriel en progrès de sécurité, dans un secteur où chaque leçon non apprise peut coûter cher au sens propre.
Objectif : Restituer et améliorer.
Notions : Rapport orienté sûreté · Leçons
Défi : Fournir le rapport avec 3 améliorations priorisées.
Attendus : Validé si le rapport orienté sûreté présente trois améliorations priorisées.
Un maliciel s'adresse directement à des contrôleurs via Modbus et coupe le chauffage de centaines d'immeubles.
Mission : Analyser un maliciel industriel et les traces qu'il laisse sur le protocole Modbus.
Le maliciel vise les automates de sûreté d'un site, au risque de neutraliser les protections.
Mission : Investiguer une attaque sur un système instrumenté de sécurité et son protocole TriStation.
L'intrusion combine maliciel, prise de contrôle des postes et effacement des traces.
Mission : Reconstituer la chronologie d'une intrusion sur un réseau opérationnel.
Vingt-deux énergéticiens sont touchés via des équipements de périmètre, parfois le même jour.
Mission : Conduire une réponse à incident coordonnée sur plusieurs victimes d'un même secteur.
Un acteur étatique se pre-positionne durablement dans des réseaux d'infrastructure.
Mission : Mener chasse et réponse face à une persistance furtive en environnement critique.
Analyse et exploitation de la sécurité des objets connectés : firmware, matériel et protocoles.
Le logiciel embarqué d'un objet connecté — son firmware — recèle souvent des secrets que ses concepteurs croyaient inaccessibles. Cette brique vous fait extraire et analyser un firmware (systèmes de fichiers compressés, entropie révélatrice), l'émuler pour l'analyser en marche (architectures MIPS/ARM), puis le rétro-concevoir. Vous y trouvez un identifiant codé en dur, un service vulnérable exposé, et jusqu'à une porte dérobée (backdoor). Vous accédez aux entrailles des objets connectés, là où se logent quantité de failles invisibles de l'extérieur.
Objectif : Extraire et analyser un firmware IoT.
Notions : Formats, SquashFS · Entropie
Défi : Donner l'identifiant en dur trouvé.
Attendus : Validé si le firmware est extrait et si l'identifiant en dur est correct.
Objectif : Analyser dynamiquement un firmware.
Notions : Émulation MIPS/ARM · Surface réseau
Défi : Donner le service vulnérable exposé.
Attendus : Validé si le firmware est émulé et si le service vulnérable exposé est correct.
Objectif : Analyser le binaire embarqué.
Notions : Binaire embarqué · Logique d'auth
Défi : Donner l'identifiant de la backdoor trouvée.
Attendus : Validé si la porte dérobée est trouvée et si son identifiant est correct.
La sécurité d'un objet ne s'arrête pas à son logiciel : sur sa carte électronique, des ports de débogage offrent parfois un accès direct. Cette brique vous fait accéder à un équipement par ses interfaces matérielles — la console série UART, et ses cousines JTAG et SPI — souvent laissées actives en production. Le défi : obtenir un interpréteur de commandes (shell) via l'UART, à partir de la bannière du chargeur d'amorçage. Vous comprenez que l'accès physique à un objet connecté ouvre une voie que nulle protection logicielle ne ferme.
Objectif : Accéder via le débogage matériel.
Notions : UART/JTAG/SPI · Console série
Défi : Obtenir un shell via UART (bannière bootloader).
Attendus : Validé si un shell est obtenu via UART (bannière du bootloader).
Les objets connectés dialoguent par des protocoles légers — pratiques, mais souvent dépourvus de contrôle d'accès. Cette brique vous fait exploiter ces protocoles (MQTT, CoAP, UPnP) puis une vulnérabilité réseau d'un équipement IoT. Le défi parle de lui-même : publier sur le canal (topic) qui pilote un actionneur, et prouver l'accès obtenu sur l'équipement. Vous mesurez à quel point un objet connecté mal protégé devient un point de contrôle pour qui sait lui parler.
Objectif : Exploiter un protocole IoT faible.
Notions : MQTT/CoAP/UPnP · Faiblesses
Défi : Publier sur le topic contrôlant l'actionneur.
Attendus : Validé si la publication sur le topic contrôlant l'actionneur réussit.
Objectif : Exploiter une faille réseau IoT.
Notions : Vulns IoT · Exploitation
Défi : Prouver l'accès obtenu sur l'équipement.
Attendus : Validé si l'accès à l'équipement est obtenu et prouvé.
Beaucoup d'objets ne communiquent par aucun câble : leur sécurité se joue dans les ondes. Cette brique vous initie aux surfaces radio (Bluetooth basse consommation — BLE, Zigbee) avec la radio logicielle, puis vous fait enchaîner une attaque complète — du firmware au réseau jusqu'au contrôle physique. Vous identifiez un type de message radio et prenez le contrôle d'un actionneur de bout en bout. Vous reliez toutes les surfaces d'un objet connecté en une seule démonstration, celle qui révèle l'ampleur réelle du risque.
Objectif : Comprendre les surfaces radio.
Notions : BLE/Zigbee · Capture radio
Défi : Donner le type de message radio identifié.
Attendus : Validé si le type de message radio identifié est correct.
Objectif : Enchaîner firmware→réseau→contrôle.
Notions : Chaînage · Du firmware au contrôle
Défi : Prendre le contrôle de l'actionneur de bout en bout.
Attendus : Validé si le contrôle de l'actionneur est obtenu de bout en bout.
Après avoir vu par où un objet connecté cède, on inverse la perspective : comment le rendre sûr, du déploiement à la fin de vie. Cette brique vous fait formuler des recommandations de durcissement IoT couvrant tout le cycle de vie de l'équipement. Le défi : désigner les trois mesures de durcissement prioritaires. Vous bouclez l'approche IoT par sa finalité défensive : transformer la connaissance des failles en protection concrète.
Objectif : Recommander un durcissement.
Notions : Cycle de vie · Bonnes pratiques
Défi : Donner les 3 mesures de durcissement prioritaires.
Attendus : Validé si les trois mesures de durcissement prioritaires sont pertinentes.
Des objets connectés sous identifiants d'usine forment un botnet de grande ampleur.
Mission : Analyser un botnet d'objets connectés : identifiants par défaut, propagation, effet d'échelle.
Des routeurs de petits bureaux non maintenus sont enrôlés pour masquer une activité étatique.
Mission : Étudier la compromission d'équipements de périphérie en fin de vie et les mesures de durcissement.
Des pare-feux exposés sont exploités sur leur service de négociation.
Mission : Exploiter en laboratoire puis durcir des pare-feux d'usage industriel.
Le maliciel manipule des contrôleurs et prive de chauffage des centaines d'immeubles.
Mission : Relier l'objet industriel connecté à un impact physique via le protocole Modbus.
L'acteur s'installe sur des équipements réseau de périphérie pour durer.
Mission : Étudier la persistance sur des équipements de périphérie et les moyens de l'en déloger.
Test de la sécurité d'un environnement industriel sans compromettre la sûreté du procédé.
Mené comme en informatique de gestion, un test d'intrusion peut, en milieu industriel, provoquer un arrêt de production — voire un accident. Cette brique vous fait adapter le pentest aux contraintes de l'OT : une méthodologie où le passif précède toujours l'actif, et où la sûreté prime sur l'objectif. Vous énoncez la règle d'or du pentest OT et cartographiez passivement un automate, jusqu'à mesurer son exposition sur Internet. Vous intégrez ce qui rend le test offensif industriel si particulier : on n'éprouve jamais un procédé au prix de sa sûreté.
Objectif : Adapter le pentest aux contraintes OT.
Notions : Risques physiques · Passif d'abord
Défi : Donner la règle d'or du pentest OT.
Attendus : Validé si la méthodologie OT-safe est définie et si la règle d'or est correctement formulée.
Objectif : Cartographier sans émettre de trafic risqué.
Notions : Découverte passive · Exposition externe
Défi : Donner le PLC découvert et son exposition Internet.
Attendus : Validé si le PLC est découvert sans bruit et si son exposition Internet est vérifiée.
Sur un protocole industriel sans authentification, prouver l'impact d'une attaque consiste à injecter une commande que rien ne distingue d'une commande légitime. Cette brique vous fait démontrer — en environnement simulé et contrôlé — l'injection et le rejeu sur Modbus, puis sur les protocoles de l'énergie (DNP3, IEC-104). Vous modifiez l'état d'une sortie d'un automate simulé et injectez une commande de contrôle. Vous établissez la réalité d'un risque que les exploitants peinent souvent à croire, tout en restant dans un cadre sans danger.
Objectif : Démontrer l'impact d'une injection Modbus.
Notions : Injection/rejeu · Impact maîtrisé
Défi : Modifier l'état d'une sortie du PLC simulé.
Attendus : Validé si l'état d'une sortie du PLC simulé est modifié de façon maîtrisée.
Objectif : Cibler les protocoles d'énergie.
Notions : DNP3/IEC-104 · Commandes de contrôle
Défi : Donner la commande de contrôle injectée.
Attendus : Validé si la commande de contrôle injectée est correctement décrite.
Chercher des failles dans un équipement industriel par fuzzing — le bombarder d'entrées malformées — exige une prudence extrême : un plantage peut arrêter une ligne de production. Cette brique vous fait pratiquer un fuzzing OT prudent avec boofuzz puis attaquer une interface de supervision (IHM/SCADA), souvent une simple application web mal protégée. Vous trouvez l'entrée qui provoque l'instabilité et obtenez un accès sur l'IHM. Vous éprouvez deux surfaces critiques, en mesurant à chaque pas le risque physique que d'autres ignorent.
Objectif : Trouver des faiblesses par fuzzing prudent.
Notions : Fuzzing OT prudent · Détection de plantage
Défi : Donner l'entrée provoquant l'instabilité.
Attendus : Validé si le fuzzing prudent isole l'entrée provoquant l'instabilité.
Objectif : Compromettre une interface de supervision.
Notions : IHM/SCADA web · Faiblesses applicatives
Défi : Donner l'accès obtenu sur l'IHM.
Attendus : Validé si une faiblesse de l'IHM est exploitée et l'accès obtenu.
La plupart des attaques industrielles n'arrivent pas directement : elles passent par le réseau bureautique avant de franchir la frontière vers l'OT. Cette brique vous fait démontrer ce passage IT→OT — pivoter depuis l'informatique de gestion jusqu'à un équipement industriel — puis montrer un impact sur le procédé sans danger réel, dans un cadre de sûreté strict. Vous atteignez un équipement OT depuis l'IT et démontrez un effet de procédé encadré. Vous établissez le scénario que redoutent le plus les exploitants, en prouvant qu'il est réel sans jamais le rendre dangereux.
Objectif : Démontrer le passage IT→OT.
Notions : Frontière IT/OT · Pivot
Défi : Atteindre un équipement OT depuis l'IT.
Attendus : Validé si un équipement OT est atteint depuis l'IT via le pivot.
Objectif : Montrer l'impact sans danger réel.
Notions : Impact simulé · Cadre de sûreté
Défi : Donner l'effet de procédé démontré.
Attendus : Validé si l'effet de procédé est démontré sur le jumeau, sans danger réel.
Un rapport d'audit industriel qui recommande d'« arrêter et corriger » est un rapport inapplicable : en OT, l'arrêt n'est pas une option par défaut. Cette brique vous fait restituer un audit OT aligné sur le référentiel IEC 62443, en raisonnant en termes de risque physique et de remédiations réalisables sans interruption de production. Le défi : proposer trois remédiations compatibles avec l'OT, priorisées. Vous apprenez à formuler des recommandations qu'un exploitant industriel peut réellement appliquer.
Objectif : Restituer aligné sur IEC 62443.
Notions : Rapport orienté risque physique · Remédiations sans arrêt
Défi : Fournir 3 remédiations OT-compatibles priorisées.
Attendus : Validé si trois remédiations OT-compatibles priorisées sont fournies et mappées 62443.
L'attaque chemine de la bureautique vers les postes de conduite.
Mission : Cartographier un réseau opérationnel et ses points d'entrée informatique vers l'opérationnel, en laboratoire.
Les automates de sûreté communiquent par un protocole propriétaire mal protégé.
Mission : Évaluer la sécurité d'un système instrumenté de sécurité et de ses protocoles propriétaires.
Le maliciel exploité l'accessibilité de contrôleurs par Modbus.
Mission : Tester en laboratoire isolé l'exposition de contrôleurs sur Modbus/TCP.
Les pare-feux de périmètre des sites énergétiques sont exposés à Internet.
Mission : Auditer l'exposition périmétrique d'un réseau opérationnel.
L'incident informatique se répercute sur la décision opérationnelle.
Mission : Évaluer la frontière informatique/opérationnel et la qualité de la segmentation.
Construction d'un programme de sécurité OT structuré selon IEC 62443 et le contexte des infrastructures critiques.
La sécurité industrielle dispose de son propre corpus normatif, structurant et internationalement reconnu : la série IEC 62443. Cette brique vous en fait comprendre l'architecture — ses familles de normes, ses rôles (exploitant, intégrateur, fournisseur), ses zones et ses niveaux de sécurité (SL) — puis conduire une évaluation de risque par zone selon la partie 3-2. Vous déterminez le niveau de sécurité cible d'une zone critique et l'écart le plus important à combler. Vous vous appropriez le cadre qui fait référence pour gouverner la cybersécurité d'un site industriel.
Objectif : Maîtriser la structure 62443 et les responsabilités.
Notions : Familles 1/2/3/4 · Rôles, zones, SL
Défi : Donner le SL cible de la zone de contrôle critique.
Attendus : Validé si zones/conduits et SL sont définis et si le SL cible de la zone critique est correct.
Objectif : Conduire une évaluation par zone.
Notions : Évaluation par zone · SL-Target
Défi : Donner l'écart SL le plus critique.
Attendus : Validé si l'évaluation par zone aboutit et si l'écart SL le plus critique est correct.
Surveiller un réseau industriel ne se fait pas comme un réseau bureautique : la détection doit être passive et adaptée aux protocoles du terrain. Cette brique vous fait concevoir une architecture de surveillance OT puis bâtir un plan de réponse à incident industriel où la sûreté prime toujours. Vous désignez le point de collecte prioritaire et livrez un playbook dont les trois premières actions sont sûres pour le procédé. Vous reliez détection et réponse dans le seul cadre acceptable en OT : celui qui ne met jamais le procédé en péril.
Objectif : Concevoir la détection adaptée à l'OT.
Notions : Surveillance OT passive · Détection adaptée
Défi : Donner le point de collecte prioritaire.
Attendus : Validé si l'architecture de surveillance est passive et si le point de collecte prioritaire est correct.
Objectif : Construire un playbook IR industriel.
Notions : IR OT · Sûreté d'abord
Défi : Fournir le playbook avec les 3 premières actions sûres.
Attendus : Validé si le playbook OT place la sûreté d'abord et fournit les trois premières actions sûres.
Deux fragilités récurrentes des sites industriels : une organisation non entraînée à la crise, et des accès de télémaintenance mal sécurisés. Cette brique vous fait concevoir et animer un exercice sur table (tabletop) propre à l'OT, en vous appuyant sur des trames reconnues (CISA CTEP), puis sécuriser les accès distants des prestataires (rebond par jump host, authentification forte). Vous bâtissez le scénario d'exercice et son objectif mesurable, et retenez une architecture d'accès distant sûre. Vous traitez deux portes d'entrée majeures que les attaques industrielles récentes ont largement empruntées.
Objectif : Préparer et animer un cyber-drill.
Notions : Tabletop · Injects
Défi : Donner l'inject principal et l'objectif mesuré.
Attendus : Validé si l'exercice est conçu avec quatre injects et un objectif mesurable.
Objectif : Sécuriser la télémaintenance.
Notions : Accès distant · Jump host/MFA
Défi : Donner l'architecture d'accès distant retenue.
Attendus : Validé si l'accès distant impose jump host, MFA et journalisation.
Sécuriser un site industriel dans la durée suppose de répondre à des exigences réglementaires — souvent renforcées pour les infrastructures critiques et la souveraineté régionale — et de mesurer ses progrès. Cette brique vous fait aligner un programme OT sur les réglementations critiques pertinentes, y compris dans le contexte SWANA, puis évaluer sa maturité et l'améliorer en continu (démarche PDCA, modèle C2M2). Vous identifiez l'exigence réglementaire la plus structurante et le domaine de maturité le plus faible. Vous reliez la cybersécurité industrielle à la conformité et à la gouvernance, l'horizon d'un responsable de la sécurité OT.
Objectif : Aligner sur les exigences critiques régionales.
Notions : Réglementations critiques · Souveraineté
Défi : Donner l'exigence réglementaire la plus structurante.
Attendus : Validé si l'exigence réglementaire la plus structurante est correctement identifiée et mappée.
Objectif : Piloter le programme OT dans la durée.
Notions : Maturité OT · PDCA
Défi : Donner le domaine de maturité le plus faible.
Attendus : Validé si la maturité est mesurée et si le domaine le plus faible est correctement désigné.
L'attaque révèle un cloisonnement insuffisant entre bureautique et conduite.
Mission : Tirer d'un incident réel des exigences de gouvernance (zones et conduits) selon l'esprit d'IEC 62443.
L'arrêt de précaution interroge la gouvernance de la continuité.
Mission : Définir la continuité d'activité et la gouvernance de crise côté opérationnel.
Un CERT sectoriel coordonne la réponse de multiples énergéticiens.
Mission : Penser la gouvernance sectorielle, la coordination par CERT et la mutualisation des moyens.
L'attaque vise précisément la fonction de sûreté du site.
Mission : Articuler exigences de sûreté et de sécurité, et situer les niveaux de sécurité d'IEC 62443.
Sécurisation d'un environnement cloud : responsabilité partagée, IAM, journalisation, posture et réponse à incident.
Dans le cloud, la première faille n'est pas un exploit : c'est une permission accordée trop largement. Cette brique vous fait gérer les identités et les accès (IAM) au plus juste — le principe du moindre privilège — et comprendre le modèle de responsabilité partagée, qui répartit la sécurité entre le fournisseur et le client. Vous repérez une politique IAM trop permissive et son risque, et imposez une authentification fédérée avec second facteur. Vous posez le socle de la sécurité cloud, là où se concentrent la majorité des incidents réels.
Objectif : Maîtriser l'IAM cloud et le moindre privilège.
Notions : Responsabilité partagée · Rôles, politiques
Défi : Donner la politique IAM sur-permissive et le risque.
Attendus : Validé si un rôle minimal est créé et si la politique sur-permissive et son risque sont corrects.
Objectif : Sécuriser l'accès aux comptes cloud.
Notions : Fédération SSO · MFA
Défi : Prouver l'accès fédéré avec MFA obligatoire.
Attendus : Validé si l'accès fédéré est prouvé avec MFA obligatoire.
Toute action dans le cloud laisse une trace dans les journaux d'activité — encore faut-il les activer et savoir les lire. Cette brique vous fait centraliser la journalisation cloud (CloudTrail, journaux d'activité) puis détecter une compromission, manuellement et via une détection managée. Vous repérez l'événement révélant la création d'une clé d'accès non autorisée et l'alerte de compromission générée. Vous bâtissez la visibilité sans laquelle un environnement cloud reste un angle mort.
Objectif : Activer la traçabilité et détecter.
Notions : CloudTrail/Activity Logs · Centralisation
Défi : Donner l'événement révélant la création de clé non autorisée.
Attendus : Validé si la journalisation est active et si l'événement de création de clé non autorisée est détecté.
Objectif : Détecter une compromission cloud.
Notions : Détection managée · Comportement anormal
Défi : Donner l'alerte de compromission générée.
Attendus : Validé si la détection managée génère l'alerte de compromission.
Une grande part des fuites de données dans le cloud ne vient pas d'un piratage, mais d'un espace de stockage laissé ouvert par erreur. Cette brique vous fait évaluer et corriger la posture de sécurité d'un compte cloud avec des outils de gestion de posture (CSPM) — Prowler, ScoutSuite — et mesurer la conformité aux référentiels (benchmarks CIS). Vous identifiez un stockage exposé et sa correction, puis l'écart de conformité le plus critique. Vous traquez la classe d'erreurs la plus banale et la plus coûteuse du cloud : la mauvaise configuration.
Objectif : Évaluer et corriger la configuration.
Notions : Mauvaises configs · CSPM
Défi : Donner le stockage exposé et la correction.
Attendus : Validé si le stockage exposé est identifié et corrigé.
Objectif : Évaluer la conformité d'un compte.
Notions : Benchmarks CIS cloud · Conformité
Défi : Donner l'écart de conformité le plus critique.
Attendus : Validé si l'écart de conformité le plus critique est correctement désigné.
Trois leviers protègent les données dans le cloud : les chiffrer, gérer leurs secrets, et contrôler les flux réseau. Cette brique vous fait chiffrer des données et gérer leurs clés et secrets avec un service de gestion de clés (KMS) et un coffre, puis restreindre le réseau avec les groupes de sécurité. Vous prouvez le chiffrement et la bonne gestion d'un secret, et qu'aucun port d'administration n'est ouvert au public. Vous réunissez les trois protections de base que tout déploiement cloud devrait avoir.
Objectif : Protéger données et secrets.
Notions : KMS · Coffres
Défi : Prouver le chiffrement et la gestion du secret.
Attendus : Validé si le chiffrement et la gestion du secret sont prouvés.
Objectif : Restreindre les flux cloud.
Notions : Groupes de sécurité · Segmentation
Défi : Prouver qu'aucun port admin n'est ouvert au public.
Attendus : Validé si aucun port d'administration n'est ouvert au public, preuve à l'appui.
Enquêter sur un incident cloud diffère d'une investigation classique : les preuves y sont éphémères et l'infrastructure, programmable. Cette brique vous fait mener une réponse à incident cloud — exploiter les journaux, figer une ressource par instantané (snapshot) pour l'analyser. Le défi : identifier l'action malveillante et la ressource touchée. Vous adaptez les réflexes de réponse à un environnement où tout se crée et s'efface en quelques secondes.
Objectif : Investiguer un incident cloud.
Notions : Forensique cloud · Snapshots
Défi : Donner l'action malveillante et la ressource touchée.
Attendus : Validé si l'action malveillante et la ressource compromise sont correctement identifiées.
Une falsification de requête atteint les métadonnées d'instance et récupère des jetons d'un rôle trop large.
Mission : Comprendre la gestion des identités et des accès, les métadonnées d'instance et le durcissement (version 2 du service de métadonnées).
Des espaces clients sont pillés via des identifiants volés, faute d'authentification multifacteur.
Mission : Mettre en place l'authentification multifacteur, gérer les identités cloud et le partage de données.
Une base de données d'un service d'IA est laissée accessible sans authentification, exposant clés et historiques.
Mission : Prévenir l'exposition de stockages et de services managés mal configurés.
Une clé de signature volée permet de forger des jetons d'accès.
Mission : Gérer les clés et les jetons dans le cloud et instaurer une défense en profondeur sur l'authentification.
Sécurisation des conteneurs et de Kubernetes : durcissement, contrôle d'admission, runtime et chaîne d'images.
Kubernetes orchestre des milliers de conteneurs — et multiplie d'autant la surface d'attaque si on en ignore le fonctionnement. Cette brique vous fait comprendre l'architecture d'un cluster (plan de contrôle, base etcd, espaces de noms) et son modèle d'autorisation (RBAC). Le défi : repérer le compte de service sur-privilégié, faille la plus courante des clusters. Vous acquérez la carte mentale sans laquelle aucune sécurisation de Kubernetes n'est possible.
Objectif : Comprendre Kubernetes et ses risques.
Notions : Control plane, etcd · RBAC, namespaces
Défi : Donner le service account sur-privilégié.
Attendus : Validé si le cluster est cartographié et si le service account sur-privilégié est correct.
Sécuriser Kubernetes, c'est durcir le cluster et contrôler ce qu'on y déploie avant que cela ne tourne. Cette brique vous fait appliquer les benchmarks CIS au cluster avec kube-bench, puis mettre en place un contrôle d'admission (avec Kyverno ou OPA) qui filtre les déploiements. Vous corrigez l'écart CIS le plus critique et prouvez le blocage d'un conteneur privilégié. Vous combinez durcissement de l'existant et garde à l'entrée, les deux temps d'une défense Kubernetes.
Objectif : Appliquer les benchmarks.
Notions : CIS K8s · Pod Security
Défi : Donner l'écart CIS le plus critique corrigé.
Attendus : Validé si trois écarts CIS sont corrigés et si le plus critique est correctement désigné.
Objectif : Contrôler ce qui est déployé.
Notions : Admission control · Politiques
Défi : Prouver le blocage d'un pod privilégié.
Attendus : Validé si la politique d'admission bloque un pod privilégié.
Un conteneur peut passer tous les contrôles à la construction et se comporter anormalement une fois en marche : il faut le surveiller à l'exécution. Cette brique vous fait détecter ces comportements à l'exécution avec Falco (qui observe les appels système) et segmenter le réseau interne du cluster avec des politiques réseau (Cilium). Vous déclenchez et lisez une alerte Falco et prouvez l'isolation est-ouest entre conteneurs. Vous couvrez la sécurité du cluster en fonctionnement, là où les attaques se manifestent réellement.
Objectif : Détecter les comportements anormaux.
Notions : Runtime, syscalls · Détection
Défi : Donner l'alerte Falco déclenchée.
Attendus : Validé si l'alerte Falco est déclenchée par le comportement anormal.
Objectif : Segmenter le réseau du cluster.
Notions : Network policies · Est-ouest
Défi : Prouver l'isolation est-ouest entre pods.
Attendus : Validé si l'isolation est-ouest entre pods est prouvée.
Un cluster n'est sûr que si les images qu'il exécute le sont — et qu'on peut prouver d'où elles viennent. Cette brique vous fait sécuriser la fabrication des images (analyse de vulnérabilités avec Trivy, inventaire des composants — SBOM) puis garantir leur provenance par signature, avec un contrôle d'admission qui rejette les images non signées. Vous corrigez une vulnérabilité critique dans une image et prouvez le rejet d'une image non signée. Vous établissez la confiance dans la chaîne qui mène du code au conteneur en production.
Objectif : Sécuriser la fabrication des images.
Notions : Scan, signature · SBOM
Défi : Donner la CVE critique corrigée dans l'image.
Attendus : Validé si l'image est scannée et signée et si la CVE critique corrigée est correcte.
Objectif : Imposer des images de confiance.
Notions : Provenance · Admission par signature
Défi : Prouver le rejet d'une image non signée.
Attendus : Validé si une image non signée est rejetée à l'admission.
Deux faiblesses récurrentes des plateformes conteneurisées : des secrets stockés en clair, et des conteneurs d'où l'on peut s'échapper vers l'hôte. Cette brique vous fait gérer les secrets de Kubernetes en sécurité (chiffrement, coffre Vault) puis étudier une évasion de conteneur — comprendre comment un attaquant sort du conteneur vers la machine — pour mieux la prévenir. Vous prouvez qu'aucun secret n'est en clair dans le dépôt et identifiez un vecteur d'évasion et sa correction. Vous traitez deux risques qui transforment une faille de conteneur en compromission de l'ensemble de l'infrastructure.
Objectif : Gérer les secrets en sécurité.
Notions : Secrets K8s · Chiffrement/coffre
Défi : Prouver qu'aucun secret n'est en clair dans le dépôt.
Attendus : Validé si aucun secret n'est en clair dans le dépôt, preuve à l'appui.
Objectif : Comprendre les évasions pour mieux défendre.
Notions : Évasion conteneur · Privilèges
Défi : Donner le vecteur d'évasion et sa correction.
Attendus : Validé si le vecteur d'évasion et sa correction sont corrects.
Une faille d'un outil d'administration à distance propage un rançongiciel via des prestataires vers leurs clients.
Mission : Sécuriser une chaîne de déploiement et l'accès dans un contexte multi-locataires.
Un service de base de données est exposé sans authentification sur Internet.
Mission : Durcir des services conteneurisés exposés : ports, authentification, segmentation.
Les accès illégitimes traversent de nombreux espaces clients.
Mission : Renforcer le cloisonnement multi-locataires et la gestion des identités machine.
Une bibliothèque piégée peut se retrouver dans des images de conteneurs.
Mission : Sécuriser les images et les dépendances dans une chaîne cloud-native.
Intégration de la sécurité dans tout le cycle logiciel : CI/CD, SAST/DAST/SCA, secrets et chaîne d'approvisionnement.
La chaîne qui construit et déploie le logiciel est devenue une cible — et un point de contrôle idéal pour la sécurité. Cette brique vous fait intégrer des contrôles dans un pipeline d'intégration et de déploiement continus (CI/CD), avec des barrières (gates) qui arrêtent la livraison en cas de problème, et des permissions de pipeline restreintes. Le défi : faire échouer le pipeline sur une dépendance porteuse d'une vulnérabilité critique. Vous transformez la chaîne de livraison en première ligne de défense, plutôt qu'en porte ouverte.
Objectif : Intégrer des contrôles dans le pipeline.
Notions : Gates de sécurité · Permissions pipeline
Défi : Prouver l'échec sur une dépendance à CVE critique.
Attendus : Validé si le pipeline échoue sur une dépendance à CVE critique.
Trouver les failles d'une application tôt et automatiquement coûte bien moins cher que de les corriger en production. Cette brique vous fait combiner les trois familles de tests applicatifs : analyse du code (SAST), analyse des dépendances (SCA) et test de l'application en marche (DAST). Vous corrigez une vulnérabilité repérée dans le code, mettez à jour une dépendance vulnérable et détectez une faille sur l'application déployée. Vous outillez le « décalage vers la gauche » (shift-left) : sécuriser au plus tôt dans le cycle de développement.
Objectif : Analyser le code statiquement.
Notions : SAST · Faux positifs
Défi : Donner la vulnérabilité SAST corrigée.
Attendus : Validé si la vulnérabilité SAST corrigée est correcte.
Objectif : Sécuriser les dépendances.
Notions : SCA · Mises à jour
Défi : Donner la dépendance vulnérable mise à jour.
Attendus : Validé si la dépendance vulnérable est mise à jour et l'alerte levée.
Objectif : Tester l'application déployée.
Notions : DAST · Intégration CI
Défi : Donner la vulnérabilité DAST détectée.
Attendus : Validé si la vulnérabilité DAST détectée est correcte et le DAST intégré en CI.
Un mot de passe oublié dans le code ou une infrastructure mal déclarée suffit à compromettre tout un environnement. Cette brique vous fait traquer les secrets en clair, y compris dans l'historique d'un dépôt Git (avec gitleaks), puis sécuriser l'infrastructure décrite sous forme de code (IaC) en détectant ses mauvaises configurations (Checkov, tfsec). Vous identifiez un secret enfoui dans l'historique Git et corrigez une mauvaise configuration d'infrastructure. Vous fermez deux fuites discrètes mais fréquentes des chaînes DevOps.
Objectif : Éliminer les secrets en clair.
Notions : Détection de secrets · Coffres
Défi : Donner le secret détecté dans l'historique Git.
Attendus : Validé si le secret détecté dans l'historique Git est correct et révoqué.
Objectif : Sécuriser l'infrastructure-as-code.
Notions : Scan IaC · Mauvaises configs
Défi : Donner la mauvaise config IaC corrigée.
Attendus : Validé si la mauvaise config IaC corrigée est correcte.
Un logiciel moderne est fait en grande partie de composants tiers : sa sécurité dépend de celle d'une chaîne d'approvisionnement qu'on ne contrôle pas entièrement. Cette brique vous fait tracer ces composants par un inventaire logiciel (SBOM, avec Syft) et appliquer les principes d'intégrité de la chaîne (SLSA), puis scanner les images de conteneurs dans le pipeline. Vous produisez un SBOM révélant un composant à risque et prouvez le blocage d'une image vulnérable en intégration continue. Vous traitez la surface d'attaque qui a causé des compromissions retentissantes (SolarWinds, XZ Utils).
Objectif : Tracer et sécuriser les composants.
Notions : Supply chain · SBOM, SLSA
Défi : Fournir le SBOM et le composant à risque.
Attendus : Validé si le SBOM est généré et si le composant à risque est correctement identifié.
Objectif : Scanner les images dans le pipeline.
Notions : Scan d'image CI · Gate
Défi : Prouver le blocage d'une image vulnérable en CI.
Attendus : Validé si une image vulnérable est bloquée en CI.
Les outils de sécurité ne servent à rien si les équipes les contournent : le DevSecOps est d'abord une culture. Cette brique vous fait ancrer la sécurité dans le cycle de développement — déplacer les contrôles au plus tôt (shift-left), définir des barrières (gates) acceptées par les équipes, et mesurer pour piloter. Le défi : désigner les trois barrières de sécurité prioritaires. Vous reliez l'outillage technique à l'adhésion humaine, sans laquelle aucun programme DevSecOps ne tient.
Objectif : Ancrer la sécurité dans le cycle.
Notions : Shift-left · Métriques
Défi : Donner les 3 gates de sécurité prioritaires.
Attendus : Validé si les trois portes de sécurité prioritaires sont pertinentes.
Un mainteneur malveillant introduit une porte dérobée dans une dépendance très répandue.
Mission : Sécuriser la chaîne d'approvisionnement open source : inventaire logiciel, revue, signaux faibles.
Un outil de déploiement compromis diffuse une charge malveillante à grande échelle.
Mission : Garantir l'intégrité de la chaîne de construction et de déploiement.
Le composant vulnérable est tiré indirectement par d'innombrables applications.
Mission : Mettre en place la gestion des dépendances et l'analyse de composition logicielle dans le pipeline.
Un correctif disponible n'est pas déployé partout, laissant un portail exposé.
Mission : Outiller la gestion des vulnérabilités et l'automatisation des correctifs.
Conception d'une gestion des identités moderne et d'une architecture Zero Trust de bout en bout.
L'identité est devenue le véritable périmètre de la sécurité : c'est elle qu'on attaque pour entrer. Cette brique vous fait mettre en place une authentification fédérée moderne (protocoles OIDC, SAML) et gérer le cycle de vie des comptes avec Keycloak, puis imposer une authentification multifacteur résistante au phishing (FIDO2, passkeys). Vous prouvez une connexion fédérée fonctionnelle et l'exigence d'un second facteur réellement résistant. Vous sécurisez la porte que visent en premier la plupart des attaques actuelles.
Objectif : Mettre en place une authentification fédérée.
Notions : OIDC/SAML · Cycle de vie
Défi : Prouver la connexion fédérée fonctionnelle.
Attendus : Validé si la connexion fédérée OIDC est fonctionnelle.
Objectif : Imposer une authentification forte.
Notions : MFA, FIDO2/passkeys · Résistance phishing
Défi : Prouver l'exigence d'un second facteur résistant.
Attendus : Validé si l'exigence d'un second facteur résistant à l'hameçonnage est prouvée.
Authentifier un utilisateur ne dit rien de ce à quoi il devrait avoir droit : c'est le rôle de l'autorisation. Cette brique vous fait concevoir des autorisations fines — par rôle (RBAC) ou par attribut (ABAC) — en respectant la séparation des tâches, puis encadrer les comptes à privilèges (PAM) avec des accès accordés juste à temps et pour une durée limitée. Vous repérez un compte en sur-accumulation de droits et prouvez un accès administrateur temporaire et tracé. Vous luttez contre la dérive des privilèges, principale cause d'aggravation d'une compromission.
Objectif : Concevoir des autorisations fines.
Notions : RBAC/ABAC · Séparation des tâches
Défi : Donner le compte en sur-accumulation détecté.
Attendus : Validé si le compte en sur-accumulation de droits est correctement détecté.
Objectif : Limiter les privilèges dans le temps.
Notions : PAM · JIT
Défi : Prouver l'accès admin temporaire et tracé.
Attendus : Validé si l'accès administrateur est temporaire, tracé et expirant.
Le Zero Trust déplace la décision de sécurité du périmètre réseau vers chaque requête : on vérifie à chaque accès, en fonction du contexte. Cette brique vous fait appliquer une politique Zero Trust (points de décision et d'application — PDP/PEP) puis exprimer ces règles comme du code versionné et testable (policy-as-code, avec OPA et le langage Rego). Vous prouvez un refus d'accès conforme hors contexte et écrivez la politique qui le réalise. Vous opérationnalisez un principe souvent invoqué mais rarement mis en œuvre concrètement.
Objectif : Appliquer une politique Zero Trust.
Notions : PDP/PEP · Vérif par requête
Défi : Prouver un refus d'accès hors contexte conforme.
Attendus : Validé si l'accès hors contexte est refusé conformément à la politique.
Objectif : Gérer les politiques d'accès en code.
Notions : Policy-as-code · Tests de politique
Défi : Fournir la politique refusant un accès non conforme.
Attendus : Validé si la politique Rego refuse un accès non conforme.
Une fois une identité compromise, l'attaquant agit « légitimement » : le détecter demande de repérer l'anormal dans le normal. Cette brique vous fait détecter les abus d'identité — connexion depuis deux lieux incompatibles (voyage impossible), élévation de privilèges anormale — via le SIEM, puis durcir le fournisseur d'identité (IdP), dont la défaillance paralyserait tous les accès (point unique de défaillance — SPOF). Vous identifiez l'événement signalant la compromission et la mesure réduisant le risque de SPOF. Vous protégez l'infrastructure d'identité, devenue une cible de très haute valeur.
Objectif : Repérer les compromissions d'identité.
Notions : Voyage impossible · Élévation anormale
Défi : Donner l'événement signalant la compromission.
Attendus : Validé si l'événement signalant la compromission d'identité est correctement identifié.
Objectif : Sécuriser le fournisseur d'identité.
Notions : IdP comme SPOF · Résilience
Défi : Donner la mesure réduisant le risque de SPOF.
Attendus : Validé si la mesure réduisant le risque de point unique de défaillance est pertinente.
Quand une identité est compromise, chaque minute compte : tant que les sessions restent ouvertes, l'attaquant garde la main. Cette brique vous fait réagir à un vol d'identité — révoquer les sessions actives, faire tourner les secrets, rétablir un état de confiance. Le défi : déterminer la première réponse à apporter. Vous acquérez les réflexes d'urgence d'un incident d'identité, parmi les plus fréquents et les plus rapides à se propager.
Objectif : Réagir à un vol d'identité.
Notions : Révocation de sessions · Rotation
Défi : Donner la première réponse à la compromission.
Attendus : Validé si les sessions sont révoquées et si la première réponse à la compromission est correcte.
Un accès au système de support d'un fournisseur d'identité exposé des fichiers de session de clients.
Mission : Sécuriser un fournisseur d'identité et les sessions, dans une logique Zero Trust.
Les comptes pillés ne sont pas protégés par une seconde authentification.
Mission : Imposer l'authentification multifacteur et des accès conditionnels.
Un acteur obtient un accès en manipulant la procédure de réinitialisation par téléphone.
Mission : Durcir les processus de réinitialisation et de vérification d'identité.
Des jetons forgés passent une validation insuffisamment stricte.
Mission : Renforcer la validation des jetons, la gestion des clés et la défense en profondeur.
Sécurisation des systèmes d'IA et des LLM : ML adverse, injection de prompt, abus et usage défensif.
L'intelligence artificielle introduit des vulnérabilités d'un genre nouveau, qui ne ressemblent à rien de ce que la sécurité classique connaît. Cette brique vous fait explorer la surface d'attaque propre au machine learning, structurée par les taxonomies MITRE ATLAS et OWASP ML : tromper un modèle par des exemples adverses (perturbations imperceptibles) et corrompre son apprentissage par empoisonnement de données, jusqu'à y implanter une porte dérobée. Vous faites mal classer une entrée, mesurez le taux d'erreur induit et déclenchez la porte dérobée d'un modèle. Vous prenez la mesure d'un risque encore mal compris, à l'heure où l'IA s'installe partout.
Objectif : Comprendre les menaces propres au ML.
Notions : Taxonomie ATLAS/OWASP ML · Évasion/empoisonnement
Défi : Faire mal classer une entrée et donner la technique ATLAS.
Attendus : Validé si une entrée est mal classée et si la technique ATLAS correspondante est correcte.
Objectif : Tromper un modèle de classification.
Notions : Perturbations adverses · Robustesse
Défi : Donner le taux d'erreur induit sur le modèle.
Attendus : Validé si les exemples adverses induisent le taux d'erreur mesuré annoncé.
Objectif : Corrompre l'apprentissage.
Notions : Poisoning · Backdoor de modèle
Défi : Donner le déclencheur de la backdoor implantée.
Attendus : Validé si la backdoor s'active et si son déclencheur est correct.
Un grand modèle de langage suit les instructions qu'on lui donne — y compris celles qu'un attaquant glisse dans une donnée qu'il traite. Cette brique vous fait exploiter l'injection de prompt (référencée au Top 10 OWASP des risques LLM), directe et indirecte, jusqu'à faire révéler l'instruction système protégée, puis détourner un agent LLM doté d'outils pour exfiltrer une donnée. Vous démasquez la consigne cachée et l'outil détourné. Vous comprenez la faille structurelle des applications fondées sur les LLM, dont l'usage explose.
Objectif : Exploiter les LLM par injection.
Notions : OWASP LLM Top 10 · Directe/indirecte
Défi : Faire révéler l'instruction système protégée.
Attendus : Validé si l'instruction système protégée est révélée par injection.
Objectif : Détourner un agent LLM.
Notions : Agents/outils · Abus de capacités
Défi : Donner l'outil détourné et la donnée exfiltrée.
Attendus : Validé si l'outil détourné et la donnée exfiltrée sont corrects.
Une fois comprises les attaques contre un LLM, on inverse la perspective : comment bâtir une application qui y résiste. Cette brique vous fait concevoir une application LLM robuste — frontière de confiance claire, validation des sorties — puis sécuriser une architecture qui interroge des documents (RAG, génération augmentée par récupération), vulnérable à l'injection via les documents eux-mêmes. Vous prouvez le blocage d'une sortie malveillante et le filtrage d'un document piégé. Vous portez la sécurité de l'IA du côté du constructeur, là où elle doit s'intégrer dès la conception.
Objectif : Concevoir une app LLM robuste.
Notions : Frontière de confiance · Validation des sorties
Défi : Prouver le blocage d'une sortie malveillante.
Attendus : Validé si une sortie malveillante est bloquée par les garde-fous.
Objectif : Sécuriser une architecture RAG.
Notions : RAG · Injection via documents
Défi : Prouver le filtrage d'un document malveillant.
Attendus : Validé si un document malveillant est filtré par le RAG.
L'IA n'est pas qu'une cible : c'est aussi un outil de défense — à condition de garder l'humain dans la boucle. Cette brique vous fait employer l'IA pour épauler la défense (triage assisté, avec une garde humaine — human-in-the-loop) puis encadrer son usage selon un cadre de gestion des risques (NIST AI RMF), en tenant compte des biais et des enjeux de souveraineté. Vous mesurez le gain de triage tout en plaçant la garde humaine, et désignez le risque IA prioritaire et sa mesure. Vous reliez l'IA à sa gouvernance, condition d'un usage à la fois utile et responsable.
Objectif : Utiliser l'IA pour défendre (HITL).
Notions : Triage assisté · Human-in-the-loop
Défi : Donner le gain de triage et la garde humaine.
Attendus : Validé si le gain de triage est mesuré et si la garde humaine est maintenue.
Objectif : Encadrer l'usage de l'IA.
Notions : NIST AI RMF · Biais, souveraineté
Défi : Donner le risque IA prioritaire et la mesure.
Attendus : Validé si le risque IA prioritaire et la mesure de gouvernance sont pertinents.
Un tribunal juge une compagnie aérienne responsable d'une information erronée donnée par son agent conversationnel.
Mission : Penser la gouvernance et la responsabilité d'un assistant fondé sur un modèle de langage en production.
La base d'un service d'IA est laissée ouverte, exposant clés et historiques de conversations.
Mission : Sécuriser l'infrastructure et les données d'un service d'IA (stockage, clés, journaux).
Un défaut dans une bibliothèque de cache exposé brièvement des titres de conversations et des données d'abonnés.
Mission : Comprendre les risques d'infrastructure (cache, session) propres aux services de modèles grand public.
Des plateformes de données servant à l'analytique et à l'IA sont pillées via des identifiants volés.
Mission : Protéger les jeux de données et les identités machine qui alimentent les chaînes d'IA.
Pilotage d'un programme de cybersécurité par le risque et la conformité (CSF 2.0, ISO 27001, NIS2, SWANA).
Faute d'un pilotage d'ensemble, une organisation peut multiplier les moyens et rester vulnérable : c'est précisément le rôle de la gouvernance. Cette brique vous fait structurer cette gouvernance avec le cadre NIST CSF 2.0 et sa fonction « Gouverner » récemment ajoutée, en situant la maturité par niveaux et profils. Le défi : désigner la fonction la moins mature et la priorité qui en découle. Vous adoptez un langage commun qui permet à une direction de piloter sa cybersécurité comme ses autres risques — le NIST CSF étant l'un des cadres de référence, aux côtés de l'ISO 27001.
Objectif : Structurer la gouvernance par les 6 fonctions.
Notions : Fonction Govern · Tiers et profils
Défi : Donner la fonction la plus immature et la priorité.
Attendus : Validé si la maturité est évaluée et si la fonction la plus immature et la priorité sont correctes.
La sécurité absolue n'existe pas : gouverner, c'est décider quels risques traiter, transférer ou accepter. Cette brique vous fait conduire une analyse de risque structurée avec une méthode reconnue (EBIOS Risk Manager, alignée sur l'ISO 27005), jusqu'au risque résiduel — ce qui subsiste après les mesures. Le défi : désigner le risque résiduel le plus élevé et la décision à prendre. Vous reliez la technique à la décision de direction, car c'est elle qui assume, in fine, le risque accepté.
Objectif : Conduire une analyse de risque.
Notions : ISO 27005/EBIOS RM · Risque résiduel
Défi : Donner le risque résiduel le plus élevé et la décision.
Attendus : Validé si le registre est coté et si le risque résiduel le plus élevé et la décision sont corrects.
La conformité n'est pas une fin mais un socle : elle structure la sécurité et, de plus en plus, elle s'impose par la loi. Cette brique vous fait préparer un système de management de la sécurité de l'information (SMSI) selon l'ISO 27001 et son annexe de mesures, puis cartographier les exigences réglementaires applicables — la directive européenne NIS2 et les cadres de la région SWANA (ECC saoudien, SAMA, ANCS, NCA). Vous identifiez l'écart de conformité le plus critique et l'obligation réglementaire la plus structurante. Vous reliez la sécurité aux obligations qui engagent juridiquement l'organisation, contexte régional inclus.
Objectif : Préparer un SMSI et un audit.
Notions : SMSI, Annexe A · Preuves
Défi : Donner l'écart de conformité le plus critique.
Attendus : Validé si les contrôles sont mappés ISO et si l'écart le plus critique est correct.
Objectif : Cartographier les exigences régionales.
Notions : NIS2 · ECC/SAMA/ANCS/NCA
Défi : Donner l'obligation réglementaire la plus structurante.
Attendus : Validé si les obligations sont mappées et si la plus structurante est correctement identifiée.
Des règles non écrites ne s'appliquent pas, et des règles écrites mais non vérifiées ne valent guère mieux. Cette brique vous fait déployer un corpus documentaire cohérent — politiques et procédures assorties d'indicateurs mesurables — puis piloter son amélioration continue par l'audit interne (démarche PDCA : planifier, faire, vérifier, ajuster). Vous rédigez une politique dotée de son indicateur et construisez un plan d'audit identifiant une non-conformité majeure. Vous donnez à la sécurité l'ossature documentaire et le contrôle sans lesquels elle reste déclarative.
Objectif : Déployer le cadre documentaire.
Notions : Politiques/procédures · Cohérence
Défi : Fournir la politique avec son indicateur mesurable.
Attendus : Validé si la politique est rédigée avec un indicateur mesurable.
Objectif : Piloter l'amélioration continue.
Notions : Audit interne · PDCA
Défi : Donner le plan d'audit et la non-conformité majeure.
Attendus : Validé si le plan d'audit est défini et si la non-conformité majeure est identifiée.
La technique ne protège qu'une part du risque : l'autre dépend des comportements humains et de l'attention de la direction. Cette brique vous fait construire une culture de sécurité (sensibilisation mesurée par des indicateurs humains) puis piloter et rendre compte au plus haut niveau, en traduisant la sécurité dans le langage du comité exécutif (COMEX). Vous concevez une campagne de sensibilisation avec ses indicateurs et sélectionnez les trois indicateurs-clés les plus pertinents pour les dirigeants. Vous reliez la cybersécurité aux deux leviers qui décident de sa réussite : les personnes et la gouvernance.
Objectif : Construire une culture de sécurité.
Notions : Sensibilisation · Métriques humaines
Défi : Fournir la campagne avec ses indicateurs.
Attendus : Validé si la campagne de sensibilisation est conçue avec ses indicateurs.
Objectif : Piloter et rapporter aux dirigeants.
Notions : Indicateurs stratégiques · Reporting COMEX
Défi : Donner les 3 KPI les plus pertinents pour le COMEX.
Attendus : Validé si les trois KPI les plus pertinents pour le COMEX sont correctement choisis.
Le régulateur des marchés met en cause l'entreprise et son responsable sécurité pour la communication faite aux investisseurs.
Mission : Situer la gouvernance, la redevabilité de la direction et la transparence vis-à-vis des parties prenantes.
Une sanction record est prononcée pour des transferts de données personnelles non conformes.
Mission : Traiter la conformité des transferts de données, le cadre RGPD et le régime des sanctions.
Un rapport public d'audit relie l'ampleur de l'incident à des défaillances de gestion.
Mission : Conduire la gestion du risque et la redevabilité, et relier défaut de correctif et conséquences réglementaires.
La paralysie d'un acteur central perturbe tout un secteur et déclenche des obligations de notification.
Mission : Gérer le risque lié aux tiers, la continuité et les obligations de notification.
Les 36 modules se combinent en 8 parcours métiers alignés ECSF / NICE.
