Pentest Cloud AWS Avancé 2026 : IMDSv1 + IAM PrivEsc

Le pentest cloud AWS avancé en 2026 va bien au-delà du scan de buckets S3 publics ou de l'énumération de groupes IAM. Avec l'explosion des architectures serverless, multi-comptes Organisations, EKS workloads et IaC Terraform/CDK, la surface d'attaque s'est densifiée — et les techniques d'élévation de privilèges aussi. Cet article documente la méthodologie avancée d'un pentest AWS 2026 : exploitation IMDSv1 résiduel, chaînes IAM privilege escalation, abus Lambda et EKS, exfiltration via SSM et CloudWatch Logs, persistence via roles cross-account. Issu de 30+ missions sur infrastructures AWS de 50 à 1 200 comptes (Organizations) chez des clients FinTech, SaaS et industriels. Stack outils détaillée, scénarios concrets, et défenses CIS / AWS Well-Architected.

1. La surface d'attaque AWS en 2026

L'environnement AWS moderne est rarement un seul compte plat — c'est un assemblage : AWS Organizations avec dizaines à milliers de comptes, Control Tower ou Landing Zone, IAM Identity Center (ex-SSO) fédéré, charges serverless (Lambda, Step Functions, Fargate), conteneurs EKS et ECS, bases RDS Aurora et DynamoDB, stockage S3 avec policies cross-account, messaging SNS/SQS/EventBridge, automation Systems Manager et CloudFormation. Chaque service introduit ses propres modèles de menace. Les 5 surfaces critiques 2026 : (1) IAM — policies trop permissives, trust policies risquées, conditions manquantes ; (2) EC2 et IMDS — IMDSv1 actif, security groups ouverts, accès SSM-Manager non restreint ; (3) S3 — bucket policies cross-account, public access, replication non chiffrée ; (4) Lambda — environment variables en clair, execution role over-privileged, runtime injection ; (5) EKS — service account abuse, IRSA misconfig, pod identity, kubelet exposition.

2. IMDSv1 — la porte ouverte la plus rentable

L'Instance Metadata Service (IMDS) est le service local http://169.254.169.254 que toute instance EC2 peut interroger pour obtenir ses credentials role IAM temporaires. La version IMDSv1, historique, accepte les requêtes HTTP simples sans token — donc vulnérable au SSRF (Server-Side Request Forgery) depuis n'importe quelle application web hébergée sur l'instance. La version IMDSv2, introduite en 2019 par AWS, exige un token X-aws-ec2-metadata-token obtenu via PUT préalable, ce qui bloque le SSRF basique. Pourtant, en 2026, 17 % des instances EC2 que nous auditons ont encore IMDSv1 activé (mesure sur 12 missions, 4 800 instances cumulées). Scénario typique : application web (PHP, Node.js, Python) vulnérable au SSRF → requête curl http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2Role → récupération AccessKey + SecretKey + Token temporaires → assumption du role EC2 → accès aux ressources que ce role peut manipuler. Détection : CloudTrail event GetInstanceMetadataServiceConfiguration + monitoring VPC Flow Logs sur 169.254.169.254. Remédiation : forcer IMDSv2 obligatoire via aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1, ou via Organization SCP. Voir Escalades de privilèges AWS : Guide Expert 2026.

3. Top 5 chaînes IAM privilege escalation

Les chaînes IAM privilege escalation publiées par Spencer Gietzen (Rhino Security) en 2018 restent largement exploitables en 2026 sur des comptes AWS mal audités. Top 5 chaînes observées en mission. (1) iam:PassRole + ec2:RunInstances : créer une instance EC2 attachée à un role privilégié et exécuter du code arbitraire dessus via user-data, accéder aux credentials du role via IMDS. (2) iam:AttachUserPolicy : attacher AdministratorAccess à son propre user. (3) iam:CreateAccessKey sur un autre user privilégié : créer une access key sur ce user, l'utiliser pour assumer son identité. (4) iam:UpdateAssumeRolePolicy : modifier la trust policy d'un role admin pour s'y autoriser, puis assumer. (5) lambda:InvokeFunction + iam:PassRole : créer/modifier une Lambda attachée à un role privilégié, l'invoquer, récupérer les credentials. Pmapper (NCC Group) automatise la détection de ces chaînes. Voir AWS Pentesting 2026 : Pacu, ScoutSuite, Prowler.

4. Exploitation S3 — au-delà du bucket public

Les attaques S3 en 2026 dépassent largement le bucket en accès public. Cinq vecteurs réels : (1) bucket policy cross-account avec Principal: "*" sous condition aws:SourceAccount incorrectement formulée — bypass possible via comptes attaquants ; (2) ACL legacy AllUsers ou AuthenticatedUsers encore présent malgré Block Public Access au niveau bucket — édition d'objet par n'importe qui ; (3) S3 replication vers un bucket cross-account compromis — exfiltration silencieuse ; (4) pre-signed URL leak dans logs ou Git public ; (5) S3 Object Lambda avec policy permissive — modification de la réponse à la volée. Outils : aws s3api get-bucket-policy, aws s3api get-bucket-acl, S3Scanner, CloudFox module s3, Bucket Stream pour découvrir buckets via certificats Certificate Transparency. Configuration recommandée : Block Public Access au niveau account, MFA delete sur buckets sensibles, S3 Object Lock pour rétention immuable.

5. Lambda — variables d'environnement et runtime injection

AWS Lambda stocke fréquemment des secrets en clair dans les environment variables de la fonction : tokens API tiers, DB credentials, clés de chiffrement. Toute personne avec lambda:GetFunctionConfiguration sur la fonction lit ces secrets. Recommandation : stockage dans AWS Secrets Manager ou Parameter Store SecureString, lecture runtime. Second vecteur : runtime injection — modifier le code Lambda (lambda:UpdateFunctionCode) pour ajouter un backdoor exfiltrant les credentials du role d'exécution via webhook attaquant. Troisième vecteur : Lambda layers publics ou cross-account compromis — une layer malveillante intercepte les invocations. Quatrième vecteur : function URL exposée sans IAM auth, devenant point d'entrée Internet pour des invocations non autorisées. Voir AWS Lambda Security : Attaques et Défenses.

6. EKS et conteneurs — pod identity, IRSA et kubelet

Les clusters EKS introduisent une couche d'attaque hybride AWS + Kubernetes. Vecteurs principaux : (1) IRSA misconfig (IAM Roles for Service Accounts) — un service account trop permissif est assumable par n'importe quel pod du namespace, permettant pivot AWS ; (2) EKS Pod Identity (nouveau 2024) — équivalent IRSA mais avec autres erreurs de configuration possibles ; (3) kubelet exposé sans authentification sur port 10250 (rare mais récurrent en self-managed) ; (4) RBAC Kubernetes trop permissif — cluster-admin attribué largement ; (5) privileged pod permettant escape sur node host, accès IMDS et credentials node ; (6) image registries ECR publics ou non scannés, ouvrant la voie à supply chain. Outils : kube-hunter, kubectl-who-can, peirates, kdigger, Trivy pour scan images.

7. Stack outils — Pacu, CloudFox, ScoutSuite, Prowler

8. Méthodologie en 6 phases

Un pentest cloud AWS avancé suit six phases. Phase 1 — Cadrage : périmètre comptes (1 compte vs Organisation entière), services scope, fenêtre temporelle, runbook incident en cas d'auto-déclenchement GuardDuty/Security Hub, autorisation écrite, NDA. Phase 2 — Énumération initiale : compte assumé pour test (read-only initial, parfois compte standard fourni), inventaire via aws sts get-caller-identity, aws iam list-users/roles/policies, aws ec2 describe-instances. Phase 3 — Identification surfaces : cartographie via CloudFox inventory, ScoutSuite, Prowler scan complet. Phase 4 — Exploitation : chaînes priv esc identifiées via Pmapper, exploitation IMDSv1 si trouvée, accès Lambda env vars, pivot EKS, accès cross-account si applicable. Phase 5 — Persistence et exfiltration simulée : création access key sur user identifié, exfiltration vers bucket attaquant simulé. Phase 6 — Reporting + restitution : rapport par compte, scoring CVSS, plan de remédiation phasé.

9. Scénarios réalistes 2026 — 3 chaînes complètes

Scénario A — SSRF → IMDSv1 → Domain Admin AWS : application Spring Boot vulnérable au SSRF dans paramètre imageURL. Attaquant requête http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2WebRole, récupère credentials, l'EC2WebRole a s3:* + iam:PassRole + lambda:*. L'attaquant liste les Lambda, identifie une fonction BackupOrchestrator avec role BackupAdminRole (iam:*). Il modifie le code de cette fonction (lambda:UpdateFunctionCode) pour insérer un payload exfiltrant les credentials BackupAdminRole. Il invoque la fonction, récupère les nouvelles credentials, attache AdministratorAccess à son propre user via iam:AttachUserPolicy. Game over en 6 commandes. Scénario B — Compte développement avec accès cross-account vers production : compte dev a un role assumable depuis production via trust policy mal restreinte (condition aws:PrincipalAccount oubliée). Attaquant compromise un user dev, assume le role cross-account, accède à la prod en read-only S3 + Lambda. Scénario C — IRSA EKS abuse : pod déployé via Helm chart open-source intègre un service account avec annotation IRSA pointant vers role S3FullAccessRole. Tout pod du namespace assume ce role. L'attaquant déploie un pod malveillant dans le namespace, lit tous les buckets de l'account.

10. Détection — CloudTrail, GuardDuty, Security Hub

Les détections AWS pour les chaînes d'attaque ci-dessus reposent sur trois services. CloudTrail : journalisation de toutes les API calls (lecture, écriture, modification). GuardDuty : détection ML-based des anomalies (UnauthorizedAccess, Pentest:IAMUser, CredentialAccess, Persistence). Security Hub : agrégation des findings GuardDuty + Inspector + Macie + Config + custom. Findings clés à monitorer : UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS, UnauthorizedAccess:IAMUser/MaliciousIPCaller, Persistence:IAMUser/AnomalousBehavior, PrivilegeEscalation:IAMUser/AnomalousBehavior. Compléter par règles EventBridge custom : alerte sur UpdateAssumeRolePolicy, CreateAccessKey sur user privilégié, UpdateFunctionCode sur Lambda critique, RunInstances avec user-data, PutBucketPolicy avec Principal "*".

11. Défense — CIS AWS Benchmark v3.0 et Well-Architected

Les contrôles défensifs s'alignent sur le CIS AWS Benchmark v3.0 (2024) et le AWS Well-Architected Security Pillar. Top 15 contrôles : (1) IMDSv2 obligatoire via SCP ; (2) MFA sur root + 100 % users console ; (3) password policy minimum 14 caractères ; (4) rotation access keys 90 jours max ; (5) CloudTrail activé sur toutes régions avec log file validation ; (6) GuardDuty activé sur tous comptes ; (7) Block Public Access S3 au niveau account ; (8) chiffrement par défaut S3 + RDS + EBS ; (9) Security Hub activé avec CIS + Foundational + PCI standards ; (10) Config Aggregator multi-comptes ; (11) Access Analyzer pour IAM externe et S3 ; (12) SCP empêchant les actions interdites au niveau Organization ; (13) VPC Flow Logs activés ; (14) AWS Backup configuré avec backup vaults locks ; (15) GuardDuty Malware Protection on EC2 et S3. Voir Sécurité AWS : Guide Complet Hardening Compte et Services.

12. Fréquence, coût et structure marché

Le marché du pentest cloud AWS en France représente environ 95 M€ en 2026, avec une croissance de 22 % CAGR — bien au-dessus du pentest interne classique. Tarifs typiques : (1) 1 compte AWS simple (5-30 services, jusqu'à 100 ressources) : 8 000 à 14 000 € HT, 5-7 jours ; (2) 1 compte AWS mature (multi-services, 200-500 ressources) : 14 000 à 28 000 € HT, 8-12 jours ; (3) Organization 5-20 comptes : 28 000 à 70 000 € HT, 15-25 jours ; (4) Organization 100+ comptes (fintech, plateformes SaaS) : 70 000 à 180 000 € HT, 25-60 jours, équipe 2-4 pentesteurs. Fréquence recommandée : pentest cloud AWS annuel à minimum, complété par continuous attack surface management via Wiz, Orca Security, Lacework, ou Prowler quotidien.

Sources : AWS Security Best Practices ; CIS AWS Foundations Benchmark v3.0 ; NCC Group Pmapper documentation ; Rhino Security Pacu publication ; Bishop Fox CloudFox release notes 2025.

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

Le sujet du pentest cloud aws 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 à pentest cloud AWS avancé et les chaînes d'exploitation 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 pentest cloud aws 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 pentest cloud aws. 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 pentest cloud aws 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 pentest cloud aws. (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

Quelle est la différence entre IMDSv1 et IMDSv2 en pentest AWS ?

IMDSv1 répond aux requêtes HTTP sans token — vulnérable au SSRF basique. IMDSv2 exige un token PUT préalable avec TTL et hop limit, ce qui bloque les SSRF classiques (le SSRF ne peut pas faire un PUT). Forcer IMDSv2 via aws ec2 modify-instance-metadata-options --http-tokens required, ou via Organization SCP : aws:RequestedRegion condition + ec2:MetadataHttpTokens=required.

Pacu est-il toujours maintenu en 2026 ?

Oui, Pacu (Rhino Security Labs) est toujours maintenu avec releases trimestrielles. La v1.7+ (2025) a ajouté modules EKS, Lambda function URL, Cost Explorer abuse, et IAM Identity Center. Pour les opérations grand format, beaucoup d'équipes combinent Pacu (offensif) avec CloudFox (énumération) et Pmapper (analyse statique de chaînes priv esc). Voir Cloud Pentest AWS avec Pacu et CloudFox.

Faut-il une autorisation AWS pour faire un pentest sur son propre compte ?

Depuis 2018, AWS n'exige plus d'autorisation préalable pour la plupart des pentests sur ses propres comptes (politique Customer Service Penetration Testing). Restrictions : pas de DoS, pas de port flooding, pas de tests sur services partagés (CloudFront, ELB load balancers managés en pool). En revanche, les outils de brute-force peuvent déclencher AWS Shield / WAF / GuardDuty. Communiquer en amont avec son TAM AWS si pentest agressif programmé.

Combien de temps prend un pentest AWS sur une Organisation 50 comptes ?

Pour une Organisation 50 comptes (mix dev/staging/prod avec SCP et IAM Identity Center) : 15 à 25 jours ouvrés répartis en cadrage (1 jour), énumération automatisée Prowler + ScoutSuite sur tous comptes (2 jours), focus exploitation sur 5-10 comptes critiques (8-12 jours), pivot et cross-account testing (2-3 jours), rapport + restitution (2-3 jours). Budget : 35 000 à 65 000 € HT selon profondeur.

Quels sont les pièges les plus fréquents en pentest AWS en 2026 ?

Cinq pièges récurrents : (1) IMDSv1 encore actif sur instances anciennes ; (2) trust policies cross-account avec conditions trop laxistes ; (3) Lambda env vars en clair contenant secrets ; (4) EKS service accounts IRSA over-privileged ; (5) S3 bucket replication cross-account vers buckets non audités. Bonus : SSM PortForwarding/AWS-StartPortForwardingSession permettant un pivot réseau silencieux sans VPN ni bastion.

Pour aller plus loin

• AWS Pentesting 2026 : Pacu, ScoutSuite, Prowler
• Escalades de privilèges AWS : Guide Expert 2026
• Cloud Pentest AWS avec Pacu et CloudFox : Le Guide
• AWS Lambda Security : Attaques et Défenses
• Sécurité AWS : Guide Complet Hardening Compte
• Notre service Pentest Cloud AWS