Pentest cloud AWS et Azure : IAM, mouvement latéral, metadata et exfiltration
Un pentest cloud n'est pas un pentest applicatif déporté. Les chaînes d'attaque qui comptent sur AWS et Azure passent par l'IAM, les metadata endpoints, les trust relationships cross-account, les secrets mal exposés et les services managés mal configurés. Ce guide détaille la méthodologie Laucked, les points de bascule les plus fréquents et ce qui distingue un pentest cloud sérieux d'un simple scan automatisé.
Pentest web & API, audit IA, Toulouse, méthodologie OWASP/PTES
Pourquoi le cloud a ses propres chaînes d'attaque
Un cloud public n'est pas un datacenter virtualisé. Les principes de sécurité fondamentaux changent : l'IAM devient la nouvelle couche de sécurité réseau, les metadata endpoints exposent des credentials éphémères, les relations de confiance entre comptes créent des chemins latéraux invisibles, et les services managés (Lambda, Azure Functions, RDS, Storage) ont chacun leurs misconfigurations spécifiques. Les attaques les plus fréquentes observées par Laucked sur missions cloud mobilisent moins de vulnérabilités logicielles (CVE) et plus d'erreurs de configuration. Le périmètre de test n'est pas l'infrastructure au sens classique mais la combinaison IAM + données + compute + secrets + réseau virtuel. Un pentest applicatif classique ne couvre pas ce périmètre, d'où la nécessité de missions cloud dédiées.
AWS : les 5 points de bascule les plus fréquents
(1) IMDSv1 encore actif sur des EC2 historiques, alors qu'IMDSv2 avec hop-limit=1 protège efficacement contre le SSRF metadata — Laucked le détecte sur 40%+ des missions AWS. (2) s3:GetObject accordé par policy bucket trop permissive (Principal '*' ou account-wide), exposant des backups, logs ou dumps. (3) iam:PassRole trop large dans une policy de développeur, permettant un privilege escalation via lambda ou Glue. (4) Trust policies cross-account mal verrouillées (absence de condition sts:ExternalId ou aws:SourceAccount), exploitable si on compromet un compte amont. (5) Secrets Manager ou Parameter Store accédé largement par des rôles non-nécessaires. Chaque mission Laucked énumère ces points de bascule en priorité et produit un rapport aligné sur les 50 TTP ATT&CK Cloud Matrix pertinents.
Azure : les spécificités à tester
Azure introduit ses propres chaînes : Managed Identity récupérable via SSRF sur le même endpoint 169.254.169.254 mais avec des permissions typiquement plus larges qu'AWS; Entra ID (anciennement Azure AD) avec des patterns d'attaque spécifiques (password spraying sur les endpoints legacy, abus des application permissions vs delegated permissions, privilege escalation via consent); Service Principals mal verrouillés avec credentials exportables; Key Vault accessible largement via les policies d'accès (modèle historique) ou RBAC mal configuré (modèle moderne); Storage Accounts avec SAS tokens long-lived; VNets peerings permettant un mouvement latéral vers des abonnements sensibles. Laucked mobilise ROADrecon et MicroBurst en première passe puis investigue manuellement les relations d'identité et les consents applicatifs.
Kubernetes managé (EKS, AKS, GKE) : le niveau au-dessus
Les clusters Kubernetes managés concentrent un niveau de complexité supplémentaire. Les chemins d'attaque typiques observés en mission Laucked : (1) ServiceAccount avec permissions trop larges montées dans un pod compromis; (2) IRSA (IAM Roles for Service Accounts) sur EKS ou Workload Identity sur GKE/AKS exposant des credentials AWS/GCP/Azure via un simple file read dans le pod; (3) images de conteneurs non signées ou exécutées avec privileged=true; (4) accès au kubelet API non authentifié (port 10250); (5) Secrets Kubernetes stockés en clair dans etcd. La mission combine un volet Kubernetes natif (kube-hunter, peirates, kubiscan) et un volet cloud (énumération du rôle IAM monté dans les pods). Les deux sont indispensables.
La méthodologie Laucked pour un pentest cloud
Phase 1 — cadrage technique (0,5 jour) : énumération non-intrusive de la surface cible, validation des comptes et tenants dans le périmètre, définition des fenêtres d'intervention et des opérations interdites, signature des règles d'engagement. Phase 2 — énumération (1-2 jours) : listing IAM, mapping des trust relationships, identification des services actifs et des endpoints exposés. Phase 3 — tests actifs (3-8 jours) : tentative d'exploitation des misconfigurations détectées, chaînes d'attaque complètes documentées étape par étape, validation non-destructive des impacts. Phase 4 — restitution (1-2 jours) : rapport technique avec CVSS et ATT&CK Cloud Matrix, priorisation par impact business, plan de remédiation actionnable, session de clarification avec l'équipe DevOps. Re-test de validation inclus selon le format.
Ce qui distingue un bon pentest cloud d'un scan automatisé
Un scan automatisé (Prowler, ScoutSuite) produit une liste exhaustive de misconfigurations connues. Un pentest cloud va plus loin sur trois axes : (1) la chain d'attaque — prouver qu'une misconfiguration isolée, combinée à une autre, produit une compromission réelle; (2) le contexte métier — la même misconfiguration IAM n'a pas le même impact si elle touche le compte de production ou un compte de dev; (3) l'évasion — tester les contrôles de détection (GuardDuty, Defender for Cloud) et la capacité du SOC à voir une attaque en cours. Le rapport Laucked superpose les deux lectures : une annexe scan pour la couverture exhaustive, le corps du rapport pour les chaînes d'attaque prouvées. C'est cette superposition qui rend le livrable défendable en audit et exploitable par les équipes plateforme.
Cadrer un pentest cloud avec Laucked
Pentest AWS, Azure ou GCP, missions multi-comptes, Kubernetes managé. Méthodologie alignée MITRE ATT&CK Cloud Matrix, rapport sous 48-72h, re-test de validation inclus.
Cadrer un pentest cloud sur devis