AWS Pentesting 2026 : Pacu, ScoutSuite, Prowler v4

L'AWS pentesting en 2026 repose sur un écosystème mature d'outils open source. Quatre projets dominent : Pacu (Rhino Security Labs, framework offensif modulaire), CloudFox (Bishop Fox, énumération offensive multi-service), ScoutSuite (NCC Group, audit configuration multi-cloud), et Prowler v4 (Toni de la Fuente, plus de 500 contrôles compliance). Cet article documente chaque outil avec son installation, ses commandes clés, ses modules, et la combinaison gagnante en mission. Issu de 30+ pentests AWS menés en 2024-2026 chez clients FinTech, SaaS et industriels. À la fin : un workflow type J1-J5 sur un compte AWS de taille moyenne (50-200 ressources).

1. Écosystème des outils — vue d'ensemble

Le marché des outils d'AWS pentesting open source s'est consolidé autour de quatre projets principaux + une dizaine d'outils spécialisés. Vision d'ensemble : Pacu est le seul framework offensif générique avec exploit modules ; CloudFox est l'énumérateur offensif le plus rapide ; ScoutSuite et Prowler sont des auditeurs de configuration (defensive-oriented mais utilisables en pentest pour cartographie). Outils complémentaires : Cloudsplaining (Salesforce) pour analyse statique IAM policies ; Pmapper (NCC) pour graph privilege escalation ; Stratus Red Team (DataDog) pour émulation TTPs granulaires ; S3Scanner pour buckets publics ; kube-hunter et peirates pour EKS. La majorité supporte aussi Azure et GCP — multi-cloud devient le standard 2026.

2. Pacu — installation et premier compte

Pacu (Python 3.7+, BSD-3) s'installe via pip ou Docker : pip install pacu ou docker pull rhinosecuritylabs/pacu. Lancement : pacu ouvre la CLI interactive. Création d'une session : set_keys --key-alias my_target --access-key AKIA... --secret-key .... Pacu chiffre les keys localement dans SQLite. Première commande : whoami qui appelle aws sts get-caller-identity. Pour explorer les modules : list liste les 50+ modules par catégorie (recon, exploit, persist, escalate, exfil). Recherche par mot-clé : search lambda affiche tous les modules touchant à Lambda. Exécution d'un module : run iam__enum_users_roles_policies_groups. Pacu génère automatiquement un session log avec toutes les commandes pour reproduction et reporting. La commande data affiche les données collectées en JSON pour exploitation manuelle ou export.

3. Pacu — modules essentiels par phase

L'enchaînement classique : aws__enum_account → iam__enum_users_roles_policies_groups → iam__privesc_scan → exploitation manuelle ou via module dédié → persist → exfil simulée. Pacu permet aussi d'écrire ses propres modules en Python — utile pour adapter à un contexte client spécifique.

4. CloudFox — énumération offensive ultra rapide

CloudFox (Bishop Fox, Go, MIT) se distingue par sa vitesse et son orientation pentesteur. Installation : brew install cloudfox ou téléchargement binaire GitHub releases. Workflow type sur un compte AWS : cloudfox aws --profile my_target --command all exécute toutes les vérifications en parallèle (35+ checks), produit rapport TXT + CSV + Loot directory avec credentials, secrets et résultats. Modules clés : inventory, endpoints (toutes URL publiques), permissions (résolution IAM permissions par principal), iam-simulator (test d'action), role-trusts (analyse trust policies), secrets (recherche dans Secrets Manager, SSM, env vars), buckets, ecr (registries de conteneurs), lambda, codebuild, environment-vars, workloads. Le format de sortie est conçu pour le grepping : cloudfox aws --command secrets | grep "api_key". Avantage majeur sur Pacu : pas de stockage local des keys, lecture directe via AWS CLI profiles, vitesse 5-10x supérieure sur grandes surfaces.

5. ScoutSuite — audit configuration multi-cloud

ScoutSuite (NCC Group, Python, GPL-2) génère un rapport HTML statique self-contained ultra exploitable en restitution client. Installation : pip install ScoutSuite. Lancement : scout aws --profile my_target --report-dir /tmp/scout. Durée typique 5-30 minutes selon taille account. Le rapport HTML contient navigation par service (IAM, EC2, S3, RDS, Lambda, EKS, ECS, CloudTrail, GuardDuty, KMS, etc.), avec findings classés par criticité (danger/warning/info), filtrage par règle, détails par ressource. ScoutSuite supporte aussi Azure, GCP, OCI, Aliyun — utile en multi-cloud. Limites : c'est un audit configuration, pas un outil offensif, donc pas de privilege escalation chains automatiques (utiliser Pmapper pour ça). Pour un client peu technique, le rapport HTML ScoutSuite est souvent plus parlant que le rapport Prowler (plus orienté ingénieur sécurité).

6. Prowler v4 — 500+ contrôles compliance

Prowler v4 (Toni de la Fuente, Python, Apache 2.0) est devenu en 2024-2026 l'outil de compliance cloud par excellence. Plus de 500 contrôles mappés sur 25+ référentiels : CIS AWS 1.4/2.0/3.0, CIS Azure 1.5/2.0, CIS GCP 1.3/2.0, NIST CSF, NIST 800-53, PCI DSS v4, HIPAA, SOC2, FedRAMP, GDPR, ENS, ISO 27001, ISO 27017, ISO 27018, MITRE ATT&CK Cloud, AWS Foundational Security Best Practices, AWS Well-Architected Security Pillar. Installation : pip install prowler. Scan complet AWS : prowler aws --profile my_target (35-60 min selon taille). Scan ciblé compliance : prowler aws --compliance cis_3.0_aws ou --compliance nist_800_53_revision_5. Output : JSON, CSV, HTML, JSON-ASFF (pour AWS Security Hub), JSON-OCSF (nouveau standard ouvert). Prowler v4 supporte aussi Azure, GCP, et Kubernetes. Pour un pentest, Prowler est l'outil idéal pour produire un rapport compliance synthétique aligné CIS — typiquement annexé au rapport de pentest.

7. Combinaison gagnante — workflow J1 à J5

Sur un pentest AWS d'un compte multi-services (50-200 ressources), le workflow optimal sur 5 jours : J1 — Baseline et inventaire : Prowler scan complet pour baseline compliance (1h) + ScoutSuite scan pour rapport HTML (30 min) + CloudFox all command pour énumération offensive (30 min). Analyse des outputs : top 20 findings dangereux, liste IAM principals, surface réseau (security groups, public endpoints, S3 publics). J2 — Énumération approfondie : Pacu setup, iam__enum + ec2__enum + lambda__enum + s3__enum + eks__enum. Recherche secrets dans Lambda env vars, SSM Parameter Store, Secrets Manager. J3 — Priv esc et chaînage : iam__privesc_scan Pacu + Pmapper graph analysis. Identification de 3-5 chaînes exploitables. Exploitation de la plus impactante. J4 — Pivot et persistence : EKS cluster si présent (kube-hunter + peirates), Lambda backdoor simulé, accès cross-account si OrgUnit. Exfil simulée vers bucket attaquant lab. J5 — Rapport et restitution : compilation findings, scoring CVSS, rédaction rapport exécutif + technique, restitution orale 2h.

8. Outils complémentaires — Cloudsplaining et Pmapper

Cloudsplaining (Salesforce, Python, BSD-3) analyse statiquement les policies IAM pour identifier les permissions risquées : data exfiltration (s3:GetObject sur *), privilege escalation (iam:PassRole avec wildcard), resource exposure (s3:PutBucketPolicy sur *), wildcard actions, sans condition restrictive. Utilisation : cloudsplaining download --profile my_target puis cloudsplaining scan --input account.json. Output HTML détaillé. Pmapper (NCC Group, Python, AGPL-3) calcule un graphe IAM (chaque principal = nœud, chaque action assumable = arête) pour identifier les chaînes de privilege escalation. Commande : pmapper graph create puis pmapper visualize (GraphML pour Gephi/Cytoscape). Pmapper est l'outil le plus avancé pour comprendre les chemins indirects de privilege escalation. Combiner Pmapper avec Pacu iam__privesc_scan donne une couverture quasi exhaustive.

9. Stratus Red Team — émulation TTPs granulaire

Stratus Red Team (DataDog, Go, Apache 2.0) est un outil plus récent (2022, en GA mature en 2024) qui émule des TTPs cloud granulaires alignées MITRE ATT&CK Cloud. Plus de 50 techniques couvertes : aws.credential-access.ec2-get-password-data, aws.persistence.iam-create-admin-user, aws.persistence.iam-create-backdoor-role, aws.exfiltration.ec2-share-ami, aws.exfiltration.rds-share-snapshot, aws.defense-evasion.cloudtrail-stop, aws.lateral-movement.ec2-instance-connect. Utilisation pour : (1) tester les détections SOC client (le rouge déclenche, le bleu détecte ?) ; (2) générer des artefacts CloudTrail pour entraînement règles SIEM ; (3) émuler progressivement TTPs pour validation EDR cloud (Wiz, Orca, Lacework, Stream Security). Très utile en complément d'un pentest classique pour mesurer la maturité détection / réponse du SOC client.

10. Dockerisation et isolation des outils

Pour éviter de polluer le poste pentesteur et garantir des environnements reproductibles, conteneuriser : Docker Compose avec services Pacu, CloudFox, ScoutSuite, Prowler, Pmapper, Cloudsplaining. Volumes partagés pour rapports et loot, network isolé. Image Kali Linux kalilinux/kali-rolling avec installation post-build des outils Python via pip et binaires Go. Configurer un profile AWS dédié pentest avec least privilege strict (lecture seule en J1-J2, montée en privilèges contrôlée J3+). Logging CloudTrail Insights activé côté client pour traçabilité de toutes les actions du pentesteur — protection juridique mutuelle.

11. Tableau comparatif final

12. Aspects légaux — autorisation et logging

Avant toute opération d'AWS pentesting sur un compte client : (1) autorisation écrite du dirigeant / RSSI (article 323-1 Code pénal) ; (2) NDA et engagement de confidentialité ; (3) ROE (Rules of Engagement) écrites : périmètre, services exclus, fenêtre temporelle, actions interdites (DoS, modification configuration tier production, exfiltration réelle vs simulée) ; (4) journalisation côté client : CloudTrail Insights + access logging activés pour traçabilité ; (5) compte pentest dédié si possible avec policy IAM scoped — préférable à l'utilisation d'un compte admin existant ; (6) destruction des données collectées en fin de mission, attestation signée. Pour les missions OIV/OSE, qualification PASSI Audit Cloud quasi obligatoire.

Sources : Pacu GitHub repository (Rhino Security Labs) ; CloudFox release notes (Bishop Fox) ; ScoutSuite documentation (NCC Group) ; Prowler v4 documentation (Toni de la Fuente / Prowler Cloud) ; MITRE ATT&CK Cloud matrix ; CIS AWS Foundations Benchmark v3.0.

13. Articulation avec NIS2, DORA et ISO 27001 — comprendre les obligations 2026

Le sujet du aws pentesting s'inscrit en 2026 dans un cadre réglementaire européen et français dense qui structure les obligations des organisations. Trois textes majeurs encadrent désormais la posture cyber. (1) Directive NIS2 (UE 2022/2555) transposée en droit français par la loi de novembre 2024 — élargit considérablement le périmètre par rapport à NIS1 : passage de ~300 à ~10 000 entités françaises classées soit Entités Essentielles (EE), soit Entités Importantes (EI). Les obligations centrales (article 21.2) incluent l'analyse de risques annuelle, la gestion des incidents avec notification ANSSI < 24h, la continuité d'activité, la sécurité de la chaîne d'approvisionnement, la sécurité de l'acquisition/développement/maintenance, l'évaluation de l'efficacité, la formation cyber, les politiques cryptographie et contrôle d'accès, l'authentification multifacteur. Les pratiques liées à AWS pentesting et les outils offensifs cloud touchent directement plusieurs de ces obligations. (2) Règlement DORA (UE 2022/2554) applicable depuis janvier 2025 — concerne les entités financières (banques, assurances, sociétés de gestion, fintechs). Cinq piliers : gestion des risques ICT, gestion des incidents, tests de résilience opérationnelle (TLPT triennal pour entités critiques), gestion des risques tiers ICT, échange d'informations. (3) ISO 27001:2022 — norme internationale du SMSI avec 10 clauses de management et 93 contrôles Annexe A organisés en 4 thèmes : organisationnel, personnel, physique, technologique. La certification ISO 27001 fournit un cadre robuste qui couvre l'essentiel des exigences NIS2 et DORA, avec mapping documenté. Voir ISO 27001:2022 Guide Complet Certification Expert et NIS2, DORA et RGPD : Cartographie des Exigences Croisées.

14. KPI et indicateurs de pilotage — mesurer l'efficacité

Au-delà de la mise en œuvre initiale, le pilotage des sujets relatifs au aws pentesting exige des indicateurs mesurables et révisés mensuellement ou trimestriellement. Cinq familles d'indicateurs structurent un tableau de bord cyber moderne 2026. (1) Couverture : pourcentage d'actifs couverts par la mesure (endpoints sous EDR, comptes en MFA, applications avec WAF, etc.) avec cible >= 95 % pour les mesures critiques. (2) Performance opérationnelle : MTTD (Mean Time To Detect) cible < 4h pour incident critique, MTTR (Mean Time To Respond) cible < 24h, taux de remédiation des vulnérabilités critiques dans le SLA (cible > 90 % patchés J+15 du Patch Tuesday). (3) Conformité : score d'audit interne ou externe (cible > 75/100), nombre de non-conformités majeures (cible 0 par trimestre), avancement plan d'action (cible > 80 % à 6 mois). (4) Maturité : score CMMI par domaine (Initial / Managed / Defined / Quantitatively Managed / Optimizing), évolution annuelle attendue +1 niveau par domaine prioritaire. (5) Risque résiduel : nombre de risques résiduels élevés non traités, valeur en € des risques résiduels selon analyse EBIOS RM, vraisemblance / gravité moyennes. Ces KPIs alimentent les revues de direction trimestrielles (ISO 27001 clause 9.3) et les rapports COMEX trimestriels. Voir Tableau de Bord KPI ISMS ISO 27004 : Excel.

15. Retour d'expérience terrain — 3 missions anonymisées

Trois cas concrets observés sur missions 2024-2026 illustrent les enjeux pratiques autour du aws pentesting. Cas A — ETI industrielle 1 800 postes multi-sites (anonymisée) : initiative de modernisation de la posture cyber lancée en 2024 à la demande du COMEX après tentative de ransomware (chiffrement partiel évité grâce à EDR). Périmètre : 5 sites France + 2 Allemagne, AD complexe avec 3 forêts, mix Windows/Linux/OT. Démarche : audit complet (12 jours), pentest externe + interne (15 jours), pentest applicatif sur 2 apps métier critiques (10 jours), plan d'action 18 mois. Investissement total accompagnement : 380 000 € HT sur 18 mois (audits + remédiation + formation). Résultats à 18 mois : score posture cyber passé de 48/100 à 84/100, certification ISO 27001 obtenue, posture NIS2 conforme, 0 incident critique post-remédiation. Cas B — PME services 220 salariés (anonymisée) : remplacement d'un ancien prestataire d'audit jugé trop superficiel, demande pour audit complet en première intention. Périmètre : 1 site principal + 3 antennes commerciales, M365 + AD basique, 1 application web SaaS interne. Démarche : audit cybersécurité PME 15 contrôles (8 jours), pentest externe léger (4 jours), accompagnement remédiation 60 jours. Investissement : 22 000 € HT total. Résultats : MFA déployée 100 %, EDR en place sur 100 %, sauvegardes 3-2-1 testées trimestriellement, conformité cyber-assurance obtenue avec réduction de prime 18 %. Cas C — Collectivité 8 000 agents (anonymisée) : préparation à homologation RGS renforcée d'une plateforme de téléservices avec 1,2 M usagers. Périmètre : portail web, back-office, base de données, intégrations multiples (FranceConnect, INSEE, ANTAI). Démarche : analyse EBIOS RM (3 mois), audit PASSI architecture + configuration + tests d'intrusion (6 semaines), constitution dossier d'homologation, commission, signature. Investissement : 145 000 € HT. Résultats : homologation niveau renforcé délivrée fin 2025, validité 3 ans avec revue annuelle, intégration smooth avec FranceConnect+, fréquentation usagers en croissance +27 %.

16. Erreurs fréquentes et bonnes pratiques 2026

Six erreurs récurrentes observées sur les sujets liés au aws pentesting en 2024-2026, et leurs contournements. Erreur 1 — démarrage sans cadrage : se lancer dans la mise en œuvre sans phase préalable d'analyse de contexte, d'inventaire et de cartographie. Conséquence : périmètre mal défini, budget dérapant, livrable inadapté. Bonne pratique : 5-10 % du temps total en cadrage, ateliers contradictoires avec parties prenantes, RACI clair. Erreur 2 — copier-coller des bonnes pratiques sans adaptation : appliquer une checklist générique sans contextualiser à la taille, secteur, contraintes de l'organisation. Conséquence : surinvestissement ou sous-investissement, démotivation équipe. Bonne pratique : référentiel proportionné au profil (CIS Implementation Group 1 pour PME, IG2 pour ETI, IG3 pour grands comptes). Erreur 3 — focus sur l'outil au détriment du processus : acheter une solution technique (EDR, SIEM, IAM) sans définir au préalable les processus opérationnels et les rôles. Conséquence : outil sous-exploité, alertes ignorées, ROI faible. Bonne pratique : processus avant outil, formation équipes, runbooks documentés. Erreur 4 — absence de plan post-projet : finaliser la mise en œuvre sans plan de continuité opérationnelle, de revue périodique, de mise à jour. Conséquence : dérive lente de la posture, retour à l'état initial en 12-24 mois. Bonne pratique : plan annuel de mise à jour, revue trimestrielle KPI, audit annuel externe. Erreur 5 — sous-estimation de la conduite du changement : déployer techniquement sans accompagner les utilisateurs et opérationnels. Conséquence : résistance, contournements (post-it mots de passe, désactivation MFA, etc.). Bonne pratique : 15-25 % du budget projet en communication, formation, support. Erreur 6 — pas d'évaluation indépendante : s'auto-évaluer sans regard externe critique. Conséquence : angle mort persistants, biais de confirmation. Bonne pratique : audit externe annuel par prestataire différent de l'intégrateur, alternance des auditeurs tous les 2-3 ans.

17. Écosystème des acteurs cyber français 2026

L'écosystème cyber français en 2026 comporte plusieurs catégories d'acteurs complémentaires à mobiliser selon les besoins liés au aws pentesting. (1) Cabinets de conseil cyber généralistes : Big 4 (Deloitte, EY, KPMG, PwC), Capgemini, Sopra Steria, Atos Eviden, Wavestone, Mazars, Beijaflore. Forces : couverture globale, références grands comptes, méthodologies normalisées. Limites : prix élevés, parfois trop pyramidal. (2) Cabinets cyber spécialisés : Synacktiv, Wallix, Stormshield Audit, Almond, Devoteam Cyber Trust, Wavestone Cybersecurity, Algosecure, Itrust, HarfangLab Services, et acteurs régionaux. Forces : expertise technique pointue, agilité, prix compétitifs. Limites : ressources limitées sur très gros projets. (3) Cabinets d'expertise pure-players souvent < 30 consultants, spécialisés (AD, cloud, OT, IA security) — typiquement ce que nous représentons. Forces : profondeur d'expertise, contact direct expert, flexibilité. Limites : capacité limitée projet très grande taille. (4) MSSP et MDR managés : Orange Cyberdefense, Thales Cyber Solutions, Atos Big Fish, Sopra Steria CyberSecurity Services. Forces : opérations 24/7, SLA, mutualisation. (5) Solutions software éditeurs : Wallix (PAM), Stormshield (UTM), Tehtris (XDR), HarfangLab (EDR), Datadog (observability), Snyk (DevSecOps). (6) Acteurs publics : ANSSI (autorité nationale), CERT-FR, Cybermalveillance.gouv.fr, France 2030 / Plan France Relance cyber, BPI France Diag Cyber, régions (BoosterCyber Île-de-France). (7) Communautés et écosystème : Clusif, Hexatrust, FIC (Forum International de la Cybersécurité, devenu InCyber Forum), Le Hack, BSides Paris, OSSIR, Cesin. Construire un écosystème de prestataires complémentaires plutôt que dépendre d'un acteur unique réduit le risque et améliore la couverture expertise.

FAQ

Quel outil choisir si je débute en AWS pentesting ?

Commencer par Prowler v4 pour comprendre la baseline compliance d'un compte (scan complet automatique, output lisible). Puis ScoutSuite pour générer un premier rapport HTML synthétique. Ensuite seulement Pacu pour la dimension offensive, en démarrant par les modules recon (iam__enum, ec2__enum) avant les modules privesc et exploit. Lab : compte AWS personnel free tier.

Pacu peut-il détecter automatiquement toutes les chaînes IAM privesc ?

Pacu détecte les 25+ chaînes classiques publiées par Rhino Security (iam:PassRole + ec2:RunInstances, iam:CreateAccessKey, etc.). Pour une couverture exhaustive incluant les chaînes complexes multi-étapes ou inter-services (Lambda → Step Functions → SSM, par exemple), compléter avec Pmapper qui construit le graphe complet IAM et trouve des chemins indirects que Pacu ne voit pas.

Comment éviter de déclencher GuardDuty pendant un pentest AWS ?

Trois options : (1) communiquer en amont avec le SOC client pour whitelist temporaire de l'IP pentesteur (recommandé en mission officielle) ; (2) utiliser le module Pacu detection__disruption qui désactive temporairement GuardDuty et CloudTrail (TTPs malveillants reconnus) — uniquement en mode red team avec autorisation explicite ; (3) opérer à très bas bruit avec actions espacées, comportements légitimes mimétisés. Recommandation : préférer l'option 1 pour préserver le ROI mission.

Quelle est la différence entre Prowler v3 et Prowler v4 ?

Prowler v3 (Bash) était l'outil historique. Prowler v4 (2024+, Python) est une réécriture complète : architecture modulaire, multi-cloud (AWS + Azure + GCP + Kubernetes), 500+ contrôles vs 200 en v3, sortie JSON-OCSF standard ouvert, intégration native Security Hub, support GitHub Actions et Jenkins pour CI/CD compliance. Migrer obligatoirement vers v4 — la v3 n'est plus maintenue depuis 2024.

Faut-il installer ces outils sur Kali ou sur une distribution dédiée ?

Kali Linux ou ParrotOS conviennent (pré-équipées Python, Go, AWS CLI). Alternative : VM Ubuntu 24.04 minimale + conteneurs Docker dédiés par outil — plus propre, plus reproductible. Pour les missions sensibles : isolation forte (VM kvm/Proxmox dédiée par mission, snapshots avant/après, suppression complète post-mission). Stockage rapports : volume chiffré LUKS + sauvegarde sur stockage qualifié si client OIV/OSE.

Pour aller plus loin

• Pentest Cloud AWS Avancé 2026 : IMDSv1 + IAM Esc
• Cloud Pentest AWS avec Pacu et CloudFox : Le Guide
• Escalades de privilèges AWS : Guide Expert 2026
• AWS Lambda Security : Attaques et Défenses
• Audit de Sécurité Cloud : Checklist Conformité 2026
• Notre service Pentest Cloud AWS