Méthodologie transverse
Rédiger le rapport
Les 9 certifications HTB exigent un rapport professionnel en anglais, déposé une seule fois. On échoue souvent à cause de lui. Cette page couvre la prise de notes, la structure, la rédaction des constats, la notation de la sévérité et la relecture.
Toutes les certificationsRapport de pentestRapport d'incident
Prendre des notes pendant l'examen
Un bon rapport s'écrit pendant l'examen, pas après. Les notes sont sa matière première.
Organisation
- Un dossier par hôte : services, accès obtenus, identifiants, captures.
- Un fichier unique pour les identifiants trouvés et où ils fonctionnent.
- Une chronologie horodatée de chaque action importante.
- Une carte du réseau mise à jour au fil de l'eau.
Outils
- SysReptor : modèles HTB prêts à l'emploi, export PDF.
- Obsidian ou CherryTree : prise de notes hiérarchique.
- Journaliser son terminal (par exemple avec la commande
script) pour ne perdre aucune sortie. - Notes stockées hors de la Pwnbox, qui disparaît après 4 jours.
Règle des capturesUne capture utile montre la commande, le résultat et un élément qui identifie la machine (nom d'hôte, IP). Recadre, et surligne ce qui compte.
Structure d'un rapport de pentest
| Partie | Contenu | Lecteur |
|---|---|---|
| Executive Summary | Une à deux pages : contexte, risque global, constats majeurs, priorités d'action. | Direction |
| Scope & Methodology | Cibles, dates, type de test, méthode suivie, limites rencontrées. | Tous |
| Attack Narrative | Le déroulé pas à pas, de l'accès initial à l'objectif final. | Équipes techniques |
| Findings | Un constat par vulnérabilité, du plus grave au moins grave. | Équipes techniques |
| Remediation Summary | Actions classées : court, moyen et long terme. | Direction et technique |
| Appendices | Hôtes et comptes compromis, fichiers déposés et nettoyés, outils utilisés. | Équipes techniques |
Rédiger un constat
Un correcteur doit pouvoir reproduire chaque constat à partir du texte seul. Modèle en anglais, prêt à copier :
## [Severity] Finding title **CVSS v3.1:** 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) **Affected hosts:** 10.10.10.5 (WEB01) ### Description What the issue is, in two or three sentences. ### Impact What an attacker can achieve, in business terms. ### Evidence Screenshots and command output, each with a one-line caption. ### Steps to Reproduce 1. ... 2. ... ### Remediation Concrete fix first, then defence-in-depth measures. ### References Vendor advisory, CWE, OWASP or MITRE ATT&CK links.
Erreur fréquenteUne remédiation vague (« apply patches », « improve security ») ne vaut rien. Donne la correction précise : version à installer, paramètre à changer, droit à retirer.
Noter la sévérité
Deux approches, souvent combinées : le score technique CVSS, et le risque qui pondère par le contexte de l'entreprise.
CVSS v3.1
- Métriques de base : AV, AC, PR, UI, S, puis impact C, I, A.
- Toujours donner le vecteur complet, pas seulement le score.
- Calculateur officiel : site du FIRST.
- Échelle : voir la fiche Cadres de référence.
Risque = probabilité × impact
- Une faille critique sur une machine isolée peut être moins urgente qu'une faille moyenne exposée sur Internet.
- Expliquer le raisonnement en une phrase dans le constat.
- Rester cohérent d'un constat à l'autre.
Le rapport d'incident
Pour la partie défensive (CJCA, CDSA, CDEP), la structure change : on raconte une attaque subie, pas une attaque menée.
| Partie | Contenu |
|---|---|
| Executive Summary | Ce qui s'est passé, l'impact, l'état actuel. |
| Timeline | Chronologie horodatée (UTC) : premier accès, actions de l'attaquant, détection, réponse. |
| Scope | Hôtes, comptes et données touchés. |
| Technical Analysis | Preuves par étape : requêtes SIEM, événements, artefacts, avec la technique ATT&CK associée. |
| Root Cause | Comment l'attaquant est entré et pourquoi cela a été possible. |
| Indicators of Compromise | IP, domaines, hash, comptes, chemins de fichiers. |
| Recommendations | Confinement, éradication, nouvelles détections, durcissement. |
Classer une alertePour chaque alerte SIEM : verdict (vrai ou faux positif), preuves qui le justifient, et requête utilisée pour vérifier.
Écrire en anglais
Un anglais simple et précis vaut mieux qu'un anglais recherché. Phrases courtes, voix active, temps du passé pour le déroulé.
| Français | Formulation en anglais |
|---|---|
| Nous avons découvert… | During the assessment, the tester identified… |
| Cela permet à un attaquant de… | This allows an attacker to… |
| Sans authentification | Without authentication / unauthenticated |
| Nous recommandons de… | It is recommended to… / We recommend… |
| À court terme | In the short term |
| Ce constat a été confirmé par… | This finding was confirmed by… |
| Accès initial | Initial access / initial foothold |
| Élévation de privilèges | Privilege escalation |
| Faux positif | False positive |
| Mesure de contournement | Workaround / mitigation |
Particularités par certification
| Certification | À savoir |
|---|---|
| CJCA | Deux volets dans un même rapport : le test d'intrusion et l'analyse des alertes SIEM. |
| CDSA, CDEP | Rapport d'incident ou d'analyse : chronologie, preuves et détections priment. |
| CWEE | Rendu en fichiers Markdown (.md) dans une archive ZIP protégée par le mot de passe des consignes. |
| Autres | PDF ou ZIP non chiffré, 20 Mo maximum. |
Check-list avant le dépôt
- Synthèse managériale lisible par un non-technicien
- Chaque constat a une sévérité, un vecteur CVSS et une remédiation précise
- Chaque constat a des étapes de reproduction vérifiables
- Toutes les captures sont lisibles et légendées
- Constats triés du plus grave au moins grave
- Chronologie cohérente avec les preuves
- Aucune donnée inutilement sensible (mots de passe masqués si possible)
- Orthographe et grammaire anglaises relues
- Format, taille et nom de fichier conformes aux consignes
- Relecture complète à tête reposée, au moins quelques heures après la rédaction