cyber / cybersecurite-fondamentale
Méthodologie de pentest : scanning, exploitation en lab et reporting
Explication
Ce que vous allez apprendre
- Croiser des versions de logiciels découvertes en scanning avec des bases de vulnérabilités connues (CVE)
- Comprendre pourquoi l'exploitation en lab vise la preuve minimale, jamais la destruction
- Évaluer l'impact réel d'un accès obtenu en post-exploitation sans causer de dommage
- Structurer un rapport de pentest avec un résumé exécutif et des constats techniques détaillés
- Prioriser les remédiations par impact métier réel, pas seulement par score CVSS brut
Dans quel contexte ?
Un pentester découvre, en scanning, qu'un serveur expose Apache 2.4.49, une version connue pour une faille critique de path traversal (CVE-2021-41773). Plutôt que d'exploiter cette faille pour tout compromettre, il se contente de prouver l'accès à un fichier non sensible, documente précisément sa démarche, puis rédige un rapport clair recommandant la mise à jour immédiate d'Apache. C'est exactement la différence entre un pentest professionnel et une intrusion malveillante : la preuve suffit, la destruction est inutile.
Trois phases, un seul objectif : prouver un risque, pas causer un dommage
Après la reconnaissance, le scanning consiste à croiser systématiquement les versions de logiciels découvertes avec les bases de vulnérabilités connues (les CVE vues en leçon 1). C'est un travail de recoupement méthodique, pas de la magie : on identifie ce qui tourne, puis on vérifie si des failles documentées existent pour cette version précise.
L'exploitation en lab : la preuve minimale, jamais la destruction
Piège fréquent
Une idée reçue chez les débutants est de penser qu'un bon pentest "casse tout" pour impressionner. C'est l'inverse : l'objectif professionnel est d'apporter la PREUVE minimale suffisante qu'une vulnérabilité est réellement exploitable, sans causer de dommage inutile ni s'approprier plus d'accès que nécessaire pour la démonstration.
| Phase | Question posée | Piège à éviter |
|---|---|---|
| Scanning | Quelles versions tournent, et sont-elles vulnérables ? | Confondre "vulnérable en théorie" et "exploitable ici" |
| Exploitation | Peut-on prouver l'exploitabilité sans dommage ? | Exploiter au-delà de la preuve nécessaire |
| Post-exploitation | Quel serait l'impact réel pour un attaquant malveillant ? | Confondre évaluation de risque et démonstration de force |
La post-exploitation : mesurer l'impact réel, pas jouer
Une fois un accès obtenu, la question n'est pas "jusqu'où puis-je aller" mais "quel est l'impact RÉEL si un attaquant malveillant obtenait cet accès" : quel niveau de privilège, quelles données seraient exposées, un pivot vers d'autres systèmes serait-il possible. C'est une évaluation de risque, pas une démonstration de force.
Pourquoi le rapport est souvent la partie la plus sous-estimée
Un test technique brillant sans rapport clair et actionnable ne sert à rien à l'entreprise cliente. Un bon rapport s'adresse à deux publics différents en même temps : un résumé exécutif compréhensible sans jargon technique pour la direction, et un détail technique reproductible pour l'équipe qui doit corriger. Chaque constat doit être accompagné d'une preuve reproductible et d'une remédiation concrète — pas seulement "voici le problème", mais "voici comment le résoudre", priorisé par impact métier réel plutôt que par le seul score CVSS brut.
Le geste final systématique
Bonne pratique
Nettoyer après soi (supprimer tout fichier de test déposé) fait partie intégrante de la méthodologie, pas une option — un pentest professionnel ne laisse jamais de trace exploitable derrière lui.
Commandes & code
Méthodologie de pentest : scanning, exploitation en lab et reporting
Rappel : toute action de cette leçon suppose un environnement de lab autorisé (VM d'entraînement, plateforme dédiée, ou mandat écrit explicite).
# Scanning de ports et services (voir aussi la leçon dédiée nmap pour le détail des options)
nmap -sV -sC -p- -T4 192.168.56.10 -oN scan-full.txt
# -sV : détection de version, -sC : scripts par défaut, -p- : tous les ports, -T4 : timing agressif (lab uniquement)# Croiser les versions découvertes avec des bases de vulnérabilités connues
Service découvert : Apache 2.4.49
-> recherche CVE : CVE-2021-41773 (path traversal / RCE sur cette version précise)
-> vérifier si le correctif est appliqué avant toute tentative d'exploitation# searchsploit : recherche locale d'exploits publics référencés (Exploit-DB), utile pour la reconnaissance
searchsploit apache 2.4.49
searchsploit -m 50383 # copie l'exploit localement pour analyse avant tout usage en lab# Exploitation contrôlée en lab : principes à respecter STRICTEMENT
1. Ne jamais exécuter un exploit "en aveugle" sans en comprendre le fonctionnement
2. Toujours tester d'abord sur une copie/VM isolée, jamais directement sur un système de production
3. Préférer la preuve d'exploitabilité (PoC minimal, ex: lecture d'un fichier témoin) à l'exploitation destructive
4. Documenter précisément la commande utilisée, l'heure, et le résultat obtenu
5. Ne jamais persister d'accès au-delà du strict nécessaire à la démonstration (pas de backdoor oubliée)# Exemple pédagogique : validation d'un path traversal connu (CVE-2021-41773) sur une VM de lab dédiée
# Objectif : PROUVER l'accès à un fichier non sensible, pas exfiltrer de données réelles
curl -s --path-as-is "http://192.168.56.10/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd"
# Si la réponse contient le contenu de /etc/passwd -> vulnérabilité confirmée, à corriger immédiatement (patch Apache)# Post-exploitation : évaluer l'impact SANS causer de dommage
- Quel niveau de privilège est obtenu (utilisateur standard, root/admin) ?
- Quelles données seraient exposées en cas d'exploitation réelle par un attaquant malveillant ?
- Un pivot vers d'autres systèmes du réseau segmenté est-il possible ?
- Toujours nettoyer après soi : supprimer tout fichier de test déposé sur la cible# Structure type d'un rapport de pentest professionnel
## 1. Résumé exécutif
Synthèse non technique pour la direction : risques majeurs, impact métier, priorités.
## 2. Périmètre et méthodologie
Systèmes testés, dates, règles d'engagement, méthodologie suivie (PTES/OWASP).
## 3. Constats détaillés (par vulnérabilité)
| Champ | Exemple |
|-----------------|-------------------------------------------------------|
| Titre | Path Traversal sur endpoint /cgi-bin (Apache 2.4.49) |
| Sévérité (CVSS) | 9.8 (Critique) |
| Preuve (PoC) | Requête curl + capture de la réponse |
| Impact | Lecture de fichiers arbitraires, RCE potentiel |
| Remédiation | Mettre à jour Apache vers 2.4.51+, WAF en complément |
## 4. Recommandations priorisées
Classées par sévérité et facilité de remédiation (quick wins d'abord).
## 5. Annexes techniques
Logs bruts, sorties d'outils complètes, captures d'écran horodatées.# Bonnes pratiques de reporting
- Écrire pour deux audiences : le résumé exécutif (non technique) et le détail technique (équipe DevOps/sécurité)
- Toujours fournir une preuve reproductible, jamais une simple affirmation
- Prioriser par IMPACT MÉTIER réel, pas seulement par score CVSS brut
- Proposer une remédiation concrète pour chaque constat, pas seulement le problèmeRésumé
- Le scanning croise les versions découvertes avec des CVE connues avant toute tentative d'exploitation.
- L'exploitation en lab vise la preuve minimale d'impact, jamais la destruction ou la persistance inutile.
- La post-exploitation évalue l'impact réel sans causer de dommage sur l'environnement testé.
- Un bon rapport combine résumé exécutif, preuves reproductibles et remédiations priorisées par impact métier.
Exercices pratiques
Mission : prouver sans détruire sur un Apache vulnérable
Objectif : Mener une exploitation de preuve minimale sur une CVE connue et rédiger le constat correspondant pour un rapport de pentest.
Contexte
Sur un serveur de lab dédié couvert par un mandat écrit, ton scan révèle un Apache en version 2.4.49 sur le port 80. Tu sais que cette version précise est concernée par CVE-2021-41773, une faille de path traversal permettant potentiellement de lire des fichiers arbitraires. Ton objectif est de PROUVER l'exploitabilité, pas de compromettre le serveur.