cyber / pentest-red-team
Rédaction d'un rapport de pentest professionnel
Explication
Ce que vous allez apprendre
- Structurer un rapport de pentest professionnel de l'Executive Summary aux annexes techniques
- Rédiger une fiche de vulnérabilité complète, reproductible et actionnable
- Appliquer une grille de sévérité cohérente sur l'ensemble d'un rapport
- Comprendre pourquoi le cycle d'un pentest ne s'arrête pas à la remise du document
- Distinguer ce qui fait la valeur réelle d'un rapport pour un client non technique comme technique
Dans quel contexte ?
Un pentester talentueux vient de terminer un audit technique impeccable, ayant identifié plusieurs vulnérabilités critiques en exploitant des techniques vues tout au long de ce parcours — injection SQL, escalade de privilèges, mouvement latéral. Pourtant, si le rapport final est confus, mal structuré ou incompréhensible pour la direction de l'entreprise cliente, ce travail technique remarquable ne débouchera sur aucune correction réelle. Le rapport est, in fine, le seul livrable que le client retient et sur lequel il agit.
D'abord, comprendre à qui s'adresse chaque partie du rapport
Un rapport professionnel s'adresse simultanément à deux publics très différents : la direction, qui lit presque exclusivement l'Executive Summary rédigé en langage non technique et orienté risque métier, et les équipes techniques, qui exploitent le détail complet de chaque vulnérabilité avec preuve de concept et remédiation précise.
Prérequis
Cette leçon s'appuie sur l'ensemble des techniques vues dans ce parcours : chaque vulnérabilité mentionnée dans un rapport doit pouvoir être expliquée avec la même rigueur méthodologique que celle démontrée en lab tout au long des leçons précédentes.
| Section du rapport | Public visé | Contenu |
|---|---|---|
| Executive Summary | Direction | Risque métier en langage non technique |
| Contexte et périmètre | Les deux | Dates, scope exact, méthodologie (PTES, OWASP) |
| Synthèse des résultats | Les deux | Tableau des vulnérabilités par sévérité |
| Détail technique par faille | Équipes techniques | Preuve, impact, CVSS, remédiation, référence CWE/CVE |
Une fois la structure posée, chaque fiche de vulnérabilité doit suivre un format rigoureux
Une fiche complète comprend systématiquement une description précise, une preuve de concept reproductible étape par étape par un tiers, un impact exprimé en termes métier concrets (pas seulement "faille XSS" mais "un attaquant non authentifié peut se connecter à n'importe quel compte"), et une remédiation concrète — idéalement accompagnée d'un exemple de code corrigé plutôt que d'une simple recommandation générique.
Piège courant
Prioriser les vulnérabilités uniquement par leur score CVSS brut, sans tenir compte du contexte métier réel du client, est une erreur fréquente. Une faille avec un score CVSS modéré mais touchant un système critique pour l'activité de l'entreprise peut mériter une priorité plus élevée qu'une faille théoriquement plus grave mais sur un système secondaire.
Il reste une distinction essentielle à toujours respecter dans la rédaction
Chaque vulnérabilité doit être clairement identifiée comme "confirmée" (exploitée avec succès et démontrée) ou "suspectée" (identifiée mais non exploitée, par exemple pour des raisons de prudence sur un système de production) — mélanger ces deux catégories nuit gravement à la crédibilité du rapport entier.
Bonne pratique
Ne considère jamais la remise du rapport comme la fin de la mission. Propose systématiquement une réunion de restitution orale, un plan de remédiation avec des délais réalistes par sévérité, et un retest ciblé une fois les correctifs appliqués — souvent formalisé par une attestation exigée pour des besoins de conformité ou d'assurance cyber.
Ce parcours de sécurité offensive et défensive touche ici à sa fin. De la reconnaissance initiale jusqu'à la rédaction d'un rapport professionnel, en passant par l'escalade de privilèges, le mouvement latéral, Active Directory et le cloud, tu disposes maintenant d'une vision méthodologique complète, toujours ancrée dans un cadre légal, éthique et strictement autorisé.
Commandes & code
Rédaction d'un rapport de pentest professionnel
Un pentest sans rapport clair et actionnable n'a quasiment aucune valeur pour le client : c'est le livrable qui compte le plus.
# Structure standard d'un rapport professionnel
1. Executive Summary : 1-2 pages, langage non technique, orienté risque métier
2. Contexte et périmètre : dates, scope exact, méthodologie utilisée (PTES, OWASP...)
3. Synthèse des résultats : tableau des vulnérabilités par sévérité
4. Détail technique par faille : preuve, impact, CVSS, remédiation, référence CWE/CVE
5. Annexes : logs bruts, captures, scripts utilisés<!-- Exemple de fiche de vulnérabilité individuelle dans le rapport -->
## [CRITIQUE] Injection SQL sur le endpoint /api/login
**CVSS 3.1** : 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
**CWE** : CWE-89 (SQL Injection)
### Description
Le paramètre `email` du endpoint `/api/login` n'est pas correctement échappé avant
son insertion dans la requête SQL, permettant un bypass complet de l'authentification.
### Preuve de concept
\`\`\`http
POST /api/login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
email=admin' OR '1'='1'--&password=anything
\`\`\`
### Impact
Un attaquant non authentifié peut se connecter à n'importe quel compte, y compris administrateur.
### Remédiation
Utiliser exclusivement des requêtes préparées (paramétrées). Ne jamais concaténer
une entrée utilisateur dans une requête SQL, même après un "échappement" manuel.# Bonnes pratiques rédactionnelles
- Chaque vulnérabilité doit être reproductible par le client à partir des seules étapes fournies
- Distinguer clairement "vulnérabilité confirmée" de "vulnérabilité suspectée / non exploitée"
- Prioriser par impact métier réel, pas seulement par score CVSS brut
- Fournir un exemple de code corrigé quand c'est pertinent, pas seulement une recommandation générique
- Toujours proposer une réunion de restitution orale en complément du document écrit# Grille de sévérité à utiliser de façon cohérente sur tout le rapport
Critique : exploitation triviale, impact total (RCE, prise de contrôle admin, fuite massive de données)
Élevé : exploitation nécessitant des conditions modérées, impact significatif
Moyen : exploitation complexe ou impact limité (ex: fuite d'information mineure)
Faible : risque théorique, defense-in-depth, bonne pratique non appliquée
Info : observation sans risque direct mais utile (ex: version logicielle divulguée)# Après remise du rapport : le cycle ne s'arrête pas là
1. Réunion de restitution (debrief) avec les équipes technique et direction
2. Plan de remédiation avec délais réalistes par niveau de sévérité
3. Retest ciblé sur les vulnérabilités critiques/élevées une fois corrigées
4. Attestation de retest, souvent exigée pour la conformité (audits, assurances cyber)Résumé
- L'Executive Summary est souvent la seule partie lue par la direction : elle doit être irréprochable.
- Chaque vulnérabilité documentée doit être reproductible, priorisée par impact réel, et actionnable.
- Un rapport sans remédiation concrète et sans retest planifié n'apporte pas de valeur durable.
- La qualité du rapport, plus que la technique pure, distingue un pentester junior d'un expert reconnu.
Exercices pratiques
Mission : rédiger la fiche de vulnérabilité critique du rapport NordShield
Objectif : Structurer une fiche de vulnérabilité complète et prioriser correctement l'ensemble des résultats de la mission NordShield pour le rapport final.
Contexte
La mission NordShield touche à sa fin. Tu dois transformer les résultats techniques accumulés (SQLi, IDOR, Kerberoasting) en un rapport que la direction ET les équipes techniques pourront exploiter.