cyber / pentest-red-team
Méthodologie de pentest : cadre légal et cycle complet
Explication
Un peu d'histoire
Le concept de tester la sécurité d'un système informatique en l'attaquant délibérément remonte aux années 1960 : le Department of Defense américain et la RAND Corporation constituent alors des "tiger teams", des équipes chargées de s'introduire dans les premiers systèmes informatiques pour en révéler les failles, une démarche formalisée notamment dans le rapport Ware de 1967. Le terme "ethical hacking" se popularise ensuite dans les années 1990, quand IBM commence à documenter publiquement ce type de prestation pour ses clients. La discipline se structure véritablement avec la création de l'OWASP (Open Web Application Security Project) en 2001 par Mark Curphey, puis avec la publication du PTES (Penetration Testing Execution Standard) en 2009 par un collectif de professionnels de la sécurité, qui fixe pour la première fois une méthodologie de référence partagée par toute l'industrie.
Pourquoi apprendre le pentest et le red teaming aujourd'hui
La cybersécurité fait face à une pénurie mondiale de compétences estimée à plusieurs millions de postes non pourvus, et le pentest reste l'une des spécialisations les mieux rémunérées du secteur, tant en poste salarié qu'en freelance ou en bug bounty. Des réglementations comme le PCI-DSS (paiement par carte) ou certaines normes ISO imposent désormais des tests d'intrusion réguliers aux entreprises, ce qui garantit une demande structurelle et durable pour ces compétences, bien au-delà d'un simple effet de mode.
Ce que vous allez apprendre
- Identifier les documents légaux obligatoires avant tout test d'intrusion
- Distinguer les approches black box, grey box et white box
- Différencier un pentest classique d'un exercice de red team
- Suivre le cycle de vie complet d'une mission, de la reconnaissance au retest
- Reconnaître le cadre légal français applicable à l'intrusion non autorisée
Dans quel contexte ?
Un étudiant en cybersécurité vient de recevoir une proposition de "tester la sécurité" du site web d'une association locale, sans aucun document écrit, juste un accord oral du président. Cette situation, en apparence anodine, est en réalité un piège juridique : sans Rules of Engagement (RoE) signées ni périmètre précis, la moindre action technique constitue une infraction pénale, même avec les meilleures intentions du monde.
D'abord, il faut comprendre que le cadre légal précède TOUJOURS la technique
Avant même de lancer le premier outil, une mission de pentest exige quatre documents précis : un contrat définissant le périmètre et les dates, une autorisation écrite signée (parfois appelée "get-out-of-jail letter"), un scope détaillé listant explicitement ce qui est autorisé ET ce qui est exclu, et une clause de confidentialité. Sans ces documents, l'article 323-1 du Code pénal français (accès ou maintien frauduleux dans un système de traitement automatisé de données) s'applique pleinement, indépendamment de toute bonne intention.
Prérequis
Cette leçon d'introduction ne demande aucune compétence technique préalable : elle pose le cadre légal et méthodologique qui s'applique à absolument toutes les leçons suivantes de ce cours, exécutées uniquement sur des labs autorisés (VM locales, plateformes comme HackTheBox ou TryHackMe).
Une fois ce cadre posé, il faut comprendre les niveaux d'information donnés au testeur
| Approche | Information fournie | Simule |
|---|---|---|
| Black box | Aucune | Un attaquant externe sans connaissance préalable |
| Grey box | Partielle (ex: compte utilisateur standard) | Un attaquant ayant déjà un accès limité |
| White box | Complète (code source, architecture) | Un audit de sécurité approfondi |
Chaque approche répond à un objectif différent : le black box teste la résistance globale, tandis que le white box permet d'auditer en profondeur une application, y compris ses parties non exposées publiquement.
Il reste une distinction essentielle, développée en détail dans une leçon dédiée plus loin
Piège fréquent
Confondre "pentest" et "red team" est une erreur courante chez les débutants. Un pentest cherche à couvrir un maximum de vulnérabilités dans un temps limité ; un red team simule un scénario d'attaque réaliste et furtif vers un objectif précis, et teste en plus la capacité de détection de l'équipe défensive (la "blue team"). Ce cours y reviendra en détail à la leçon 16.
Le cycle complet à mémoriser dès maintenant
Bonne pratique
Retiens ce cycle en sept étapes, il structure l'intégralité de ce cours : pre-engagement (scope, autorisations), reconnaissance, analyse de vulnérabilités, exploitation, post-exploitation, reporting, puis retest. Chaque leçon suivante correspond précisément à l'une de ces étapes, dans cet ordre logique.
Maintenant que le cadre légal et méthodologique est posé, la prochaine leçon aborde la toute première étape technique réelle : la reconnaissance passive, qui ne touche jamais directement la cible.
Commandes & code
Méthodologie de pentest : cadre légal et cycle complet
Tout ce cours s'exécute contre des cibles explicitement autorisées (lab local, VM dédiées, plateformes type HTB/THM, ou périmètre couvert par un contrat écrit signé).
# Les 4 documents obligatoires avant tout test réel
1. Contrat / Rules of Engagement (RoE) : périmètre, dates, contacts d'urgence
2. Autorisation écrite signée (get-out-of-jail letter)
3. Scope précis : IP/domaines autorisés, IP/domaines EXCLUS explicitement
4. Clause de confidentialité (NDA)
# Sans ces documents : c'est illégal, même avec de "bonnes intentions"
# France : Code pénal art. 323-1 à 323-7 (accès/maintien frauduleux dans un STAD)# Cycle de vie standard (méthodologie PTES / OWASP Testing Guide)
1. Pre-engagement : scope, RoE, contacts, autorisations
2. Reconnaissance : OSINT (passive) puis scan actif (autorisé)
3. Analyse de vulnérabilités : scan automatisé + vérification manuelle
4. Exploitation : preuve d'exploitabilité, jamais de destruction
5. Post-exploitation : escalade, mouvement latéral, preuve d'impact
6. Reporting : rapport clair, priorisé, avec remédiation
7. Retest : vérifier l'efficacité des correctifs# Lab local avec Docker : cible volontairement vulnérable, testée uniquement en local
docker run -d -p 8080:80 --name juice-shop bkimminich/juice-shop
curl -sI http://127.0.0.1:8080/# Niveau de connaissance donné au testeur
Black box : aucune information -> simule un attaquant externe
Grey box : informations partielles (ex: compte utilisateur standard)
White box : accès complet (code source, architecture) -> audit approfondi
# Pentest classique vs Red team
Pentest : couvrir un maximum de vulnérabilités dans un périmètre, temps limité
Red team : simuler un scénario d'attaque réaliste et furtif, objectif précis,
teste aussi la capacité de détection/réponse de la blue team# Livrables attendus en fin de mission
- Rapport technique détaillé (vulnérabilités, preuves, score CVSS, remédiation)
- Executive summary (1-2 pages, langage non technique, pour la direction)
- Preuves d'exploitation (captures, logs, requêtes HTTP brutes)
- Recommandations priorisées (quick wins vs corrections structurelles)Résumé
- Aucune action offensive sans autorisation écrite et périmètre défini (RoE).
- Cycle : reconnaissance -> scan -> exploitation -> post-exploitation -> reporting -> retest.
- Ce cours utilise exclusivement des labs locaux ou des plateformes d'entraînement légales.
- Un pentest couvre large ; un red team simule un scénario ciblé et furtif.
Exercices pratiques
Mission : cadrer légalement un audit pour NordShield SARL
Objectif : Identifier les documents légaux manquants et structurer le cycle de mission avant toute action technique.
Contexte
NordShield SARL, une PME e-commerce, sollicite un test sur son portail RH interne suite à un simple email de son DSI, sans aucun document signé pour l'instant. Avant de lancer le moindre outil, tu dois évaluer ce qui manque légalement et poser le cadre correct de la mission.