1) Pourquoi faire un pentest ?
- Mesurer le risque réel (exploitabilité + impact business), au-delà d’un simple scan automatique.
- Prioriser la remédiation sur ce qui compte : données sensibles, disponibilité, réputation.
- Valider vos contrôles (WAF, EDR, segmentation, IAM) et vos processus d’alerte.
- Répondre aux obligations contractuelles et réglementaires (clients grands comptes, RGPD, NIS2, ISO 27001, etc.).
2) Les grandes familles de tests
Par contexte d’information
- Black-box : le testeur ne connaît rien ou presque (vision « attaquant externe »).
- Grey-box : accès limités (comptes, doc), plus réaliste et efficace.
- White-box : forte transparence (code/archi) pour une couverture maximale.
Par objectif
- Pentest « classique » : périmètre défini, exploitation, preuves, rapport.
- Red Team : simulation d’adversaire avancé, objectif business (exfiltrer X, accéder à Y), durée de plusieurs semaines, discrétion.
- Purple Team : travail main dans la main avec le Blue Team/SOC pour améliorer la détection/réaction.
Par surface
- Externe Internet (périmètre publiquement exposé).
- Interne (LAN/WAN, AD, postes, serveurs).
- Web & API, Mobile, Cloud & Conteneurs, Wi-Fi, IoT/OT, VoIP, Social Engineering/physique.
3) Pentest Web & API (applicatif)
Cibles typiques
- Sites & apps web (CMS, e-commerce, portails, back-offices, SSO).
- API REST/GraphQL/gRPC, micro-services, services B2B.
- Authent/OAuth/OIDC/SSO, gestion de session, RBAC/ABAC.
- Chaîne CI/CD (build/deploy), secrets & dépendances.
Failles majeures recherchées (exemples)
- Contrôles d’accès (BOLA/IDOR, escalade horizontale/verticale).
- Injection (SQL/NoSQL/LDAP/OS/Template), désérialisation, SSRF.
- XSS/CSRF, SSTI, XXE, RCE via upload/transformations.
- Logique métier (abus de workflow, contournement de plafonds, taux).
- Exposition de secrets, mauvaise configuration (headers, TLS, CORS, rate limiting).
- API : schémas non conformes, verbes trop permissifs, pagination/bulk, erreurs bavardes.
Méthodo en bref
- Pré-engagement (périmètre, règles).
- Cartographie & découverte (fonctionnalités, rôles).
- Tests manuels guidés par OWASP (Testing Guide, Top 10, API Top 10) + outils de support (proxy, fuzzing ciblé, analyse des réponses).
- Exploitation contrôlée, preuve par preuve (sans dégrader la prod).
- Recommandations concrètes (correctifs + durcissement + tests automatisés de régression).
4) Pentest Infrastructure (réseaux, systèmes, AD)
Périmètre externe (depuis Internet)
- DNS, mail, VPN, reverse proxy, portails d’admin, baies S3/objets, CI/CD exposés.
- Objectif : porte d’entrée (vulnérabilité logicielle, faiblesse d’authent, défaut MFA, configuration).
- Vérifications : TLS, bannières, versions, défauts de durcissement, exposition de données (bucket public, sauvegarde oubliée).
Périmètre interne (LAN/WAN, AD)
- Active Directory : Kerberoasting/AS-REP, délégations, trusts, GPO, LAPS/MSS, relai NTLM, signature SMB, LLMNR/NBT-NS, PSExec/WMI, chemin d’attaque vers Domain Admin.
- Windows/Linux : élévations locales, partages ouverts, secrets en clair, agents mal configurés.
- Segmentation : franchissement de VLAN/ACL, chemins inattendus vers SI sensibles (ERP, sauvegardes, hyperviseurs, OT).
- Post-exploitation : preuve contrôlée d’accès aux couronnes (ex. coffre d’identifiants, fichiers paie), sans exfiltration réelle.
Wi-Fi
- Sécurité WPA2/WPA3-Enterprise, EAP-TLS/PEAP, evil twin, segmentation Wi-Fi/filaires, portails invités.
5) Cloud, Conteneurs & CI/CD
Cloud (IaaS/PaaS/SaaS)
- IAM (droits trop larges), clés & tokens, partage de ressources, stockage public, règles réseau, IMDS, journaux/alertes.
- Contrôle de la posture (CSPM) + pentest d’abus d’identités/ressources.
Kubernetes & Docker
- RBAC, secrets, images, admission policies, kubelet/kube-api, etcd, réseaux/PSP/PodSecurity, exposition du docker socket, nœuds.
- Tests de latéralisation entre pods/namespaces et sortie vers le SI.
Chaîne CI/CD
- Runners/agents avec droits élevés, secrets en clair, artefacts publics, triggers sur PR, supply-chain (dépendances, typosquatting).
6) Mobile, IoT/OT, VoIP
- Mobile (iOS/Android) : stockage local, crypto, jailbreak/root, API, MDM, attestation.
- IoT/OT : segmentation forte, versions industrielles, sécurité protocolaire (Modbus, DNP3…), prudence maximale (tests souvent en environnement de pré-prod/jumeau).
- VoIP/ToIP : interception, fraude, configuration SBC, annuaires/ENUM.
7) Social Engineering & Physique (optionnel, très cadré)
- Phishing/vishing/smishing (campagnes mesurées, scénarios réalistes, accompagnement anti-phishing).
- Physique : badge, tailgating, lock-picking uniquement avec autorisations formelles, souvent dans un cadre Red Team.
8) Méthodologie & cadre (ce qui fait la différence)
Avant le test
- Périmètre clair (systèmes, domaines, sous-domaines, adresses IP, sites).
- Règles d’engagement : fenêtres horaires, seuils de charge, données à ne pas toucher, comptes fournis, environnements autorisés, contacts d’urgence, conditions d’arrêt.
- Aspects légaux : autorisation écrite, confidentialité, traitement RGPD des PII recueillies.
- Sécurité opérationnelle : sauvegardes récentes, monitoring prévenu, plan de rollback.
Pendant
- Journalisation des actions, respect des limites, communication régulière, no-harm.
Après
- Rapport exécutif (risques business clairs), rapport technique (preuves, reproduction, correctifs), atelier de remédiation, re-test ciblé pour fermer les constats.
- Alimentation du plan d’amélioration (durcissement, patch, déploiement MFA, micro-segmentation, revues d’accès, SAST/DAST/IAST/SCA dans le SDLC).
9) Livrables attendus
- Synthèse dirigeant : 1–2 pages, score de risque, scénarios d’impact, priorités.
- Tableau de bord : criticité (CVSS/EPSS + contexte), propriétaire, due date.
- Preuves : captures contrôlées, POC limités, sans divulgation excessive de données.
- Recommandations : correctifs précis, compensations, checklists de validation.
- Attestation (souvent demandée par des clients).
10) Choisir les bons tests (par maturité & menaces)
Minimum annuel pour la plupart des entreprises
- Externe (Internet) + Web/API critique + revue IAM/MFA.
- Interne/AD si vous avez un AD (beaucoup d’attaques commencent par là).
- Cloud/K8s si vous y êtes (droits, secrets, exposition).
Déclencheurs additionnels
- Lancement d’un nouveau produit, migration cloud, ouverture d’un VPN/portail, exposition d’une API, rachat/fusion, incident de sécu.
Fréquence
- Périmètres critiques : 1–2 fois/an + re-test après correctifs.
- Surfaces très changeantes (API, cloud, CI/CD) : tests plus courts mais réguliers.
11) Pentest ≠ Scan
- Un scan inventorie des vulnérabilités connues.
- Un pentest valide l’enchaînement exploitable, mesure l’impact, teste la détection et priorise réellement.
12) Matrice de priorisation simple
- Impact métier (confidentialité, intégrité, disponibilité, conformité).
- Exploitabilité (EPSS/exploits publics, complexité, prérequis).
- Exposition (Internet vs interne), latéralité possible, données touchées.
→ Classes P1 critique, P2 élevée, P3 moyenne, P4 faible, avec délais cibles (ex. 15/30/60/90 jours).
13) Modèle de périmètre & règles (extrait réutilisable)
Périmètre : app.example.com
, api.example.com
, vpn.example.com
, IPs 203.0.113.0/25, AD interne corp.local
.
Autorisé : tests non destructifs, élévation locale, mouvements latéraux contrôlés, extractions minimales pour preuve.
Interdit : déni de service, crypto-mining, accès systèmes de paie/ santé en prod, volumétrie > X req/s, données clients réelles (utiliser des comptes de test).
Fenêtres : lun-ven 20h–7h + weekend, gel des périodes critiques.
Contacts d’urgence : SOC, Exploitation, DPO.
Stop : dégradation détectée, alerte SOC rouge, condition d’arrêt activée.
14) Bonnes pratiques de remédiation
- Corriger + empêcher le retour : patch + durcissement (WAF/rate limit/headers/segmentation).
- MFA partout (VPN, RDP, portals, admins).
- Gestion des secrets (vault, rotation), principe du moindre privilège.
- Micro-segmentation et journalisation utile (corrélation SOC).
- Automatiser les régressions (tests de sécurité dans CI/CD).
- Former (développeurs, Ops, support, métiers sensibles).