Test d’intrusion cloud : notre méthodologie pour AWS, Azure et GCP

Confiez-nous un rôle IAM en lecture seule que quelqu’un a sur-provisionné, et il y a de bonnes chances que nous le fassions grimper jusqu’au contrôle total du compte avant la fin de votre stand-up. Le fournisseur cloud n’est pas en cause quand cela se produit. Quelqu’un a attaché une policy dotée d’une action en wildcard, laissé un rôle assumable par la moitié d’Internet et cessé de lire CloudTrail quelque part au trimestre dernier. Toute la méthodologie de test d’intrusion cloud décrite dans cet article vit dans cet écart, celui qui sépare “la plateforme est sécurisée” de “notre configuration est sécurisée.”

Ce qui suit est la séquence que nous déroulons réellement sur les missions AWS, Azure et GCP. Ce n’est pas une checklist de conformité reformatée en prose, mais l’ordre dans lequel nous testons, l’outillage vers lequel nous nous tournons et les erreurs de configuration qui continuent de payer mission après mission.

Une remarque de cadrage. Le test cloud est un problème de modèle de permissions avant d’être un problème réseau. En on-prem, vous combattez les pare-feu et la segmentation. Ici, vous combattez les policies IAM, les relations de confiance et les endpoints de métadonnées. Menez-le comme un test réseau externe classique et vous passerez tout droit à côté des choses qui font réellement compromettre des comptes.

À retenir

• Une méthodologie de test d’intrusion cloud est centrée sur l’identité : les policies IAM et les relations de confiance sont la principale surface d’attaque, bien avant quoi que ce soit au niveau réseau.
• Quatre constats dominent nos rapports : des policies IAM trop permissives, du stockage exposé publiquement (S3, Blob, GCS), une SSRF qui atteint le service de métadonnées d’instance et l’élévation de privilèges via une policy ou un rôle mal configuré.
• Le périmètre et l’autorisation écrite comptent ici plus que dans n’importe quel autre test. Vous travaillez à l’intérieur d’une frontière de responsabilité partagée : il vous faut donc à la fois les règles du fournisseur et l’accord du propriétaire du compte avant de toucher à quoi que ce soit.
• IMDSv2, des policies de moindre privilège, le blocage de l’accès public au stockage et une journalisation surveillée (CloudTrail, Azure Monitor, Cloud Logging) referment la plupart de ce que nous trouvons.
• Les scanners CSPM signalent les erreurs de configuration une par une. Ils n’en enchaînent pas trois pour aboutir à une prise de contrôle de compte. Cet enchaînement est tout l’intérêt d’un test manuel.

Qu’est-ce qu’un test d’intrusion cloud, et en quoi diffère-t-il ?

Un test d’intrusion cloud est une simulation d’attaque autorisée contre l’environnement cloud qui vous appartient : les comptes, les identités, les services et les configurations installés dans AWS, Azure ou GCP. Le fournisseur sécurise le matériel, l’hyperviseur et la couche physique. Vous êtes responsable de tout ce que vous configurez par-dessus : IAM, permissions de stockage, groupes de sécurité réseau, gestion des clés, journalisation. Ce partage, c’est le modèle de responsabilité partagée, et il trace la limite de ce que nous sommes autorisés à tester.

La différence pratique avec un pentest traditionnel, c’est que le périmètre est mou et que le plan d’identité est immense. Une seule clé d’accès fuitée, une relation de confiance OIDC bâclée pour un pipeline CI ou une Lambda portant un rôle admin attaché peuvent peser bien plus lourd que n’importe quel port ouvert. La méthodologie est donc bâtie autour de l’identité, de la confiance et de la configuration, et non autour du scan d’une plage CIDR.

Étape 1 : périmètre, autorisation et règles d’engagement

Avant qu’une seule commande ne s’exécute, nous fixons trois choses. Quels comptes et quelles subscriptions sont dans le périmètre. De quel type de test il s’agit : externe sans identifiants, ou authentifié en “assumed breach” à partir d’une identité à faibles privilèges. Et ce que le fournisseur autorise réellement. AWS, Azure et GCP publient chacun des conditions d’utilisation pour les tests de sécurité. La plupart des services courants ne nécessitent plus d’approbation préalable, mais les tests de déni de service, la charge lourde et soutenue et certains services managés restent soumis à des limites. Nous restons à l’intérieur de celles-ci.

Les tests cloud les plus utiles que nous menons sont authentifiés. Nous demandons une identité délibérément faible : un utilisateur IAM en lecture seule, un compte Entra ID basique, un compte de service GCP aux rôles minimaux. Puis nous regardons jusqu’où cela mène. Cela modélise la menace réaliste, à savoir un employé hameçonné, une clé fuitée dans un dépôt public ou une intégration tierce compromise, et non un attaquant sans visage qui part de rien. Le travail externe non authentifié a sa place pour cartographier la surface d’attaque. L’élévation intéressante se situe presque toujours après ce premier point d’ancrage.

Étape 2 : énumérer l’identité, car c’est là la véritable surface d’attaque

Un point d’ancrage en main, la première tâche consiste à répondre à deux questions : qui sommes-nous, et que pouvons-nous devenir ? Sur AWS, cela commence tout simplement.

aws sts get-caller-identity
aws iam get-account-authorization-details   # if permitted
aws iam list-attached-user-policies --user-name svc-ci

Ensuite, nous cartographions le graphe d’identités. Pacu et ScoutSuite nous offrent une large couverture d’AWS, et PMapper transforme un amas de policies JSON en une réponse claire sur le principal capable d’atteindre les droits admin. Sur Azure, nous nous appuyons sur AzureHound et l’écosystème BloodHound plus large pour représenter en graphe les rôles d’annuaire, l’imbrication des groupes et les attributions PIM éligibles. Sur GCP, nous parcourons la hiérarchie des ressources à la main et lisons les role bindings aux niveaux organisation, dossier, projet et ressource, car une liaison héritée d’un parent est d’une facilité déconcertante à manquer à l’oeil nu.

Ce que nous traquons à ce stade : des actions en wildcard comme "Action": "*" ou un iam:* à l’échelle d’un service, des rôles dotés de policies de confiance sts:AssumeRole permissives, et tout chemin permettant à une identité faible de s’octroyer davantage. Une policy qui autorise iam:PassRole à côté d’une permission de création de compute n’est pas une préoccupation théorique. C’est une primitive d’élévation qui fonctionne.

Étape 3 : élévation de privilèges IAM

C’est là que se gagnent ou se perdent les missions cloud. Les chemins d’élévation AWS que Rhino Security Labs a documentés il y a des années fonctionnent toujours dans des comptes en production, parce que les équipes continuent d’accorder les permissions ingrédients sans remarquer ce qu’elles totalisent. Quelques-uns que nous vérifions à chaque fois :

• iam:PassRole plus création de compute. Si nous pouvons passer un rôle admin à une nouvelle instance EC2, une fonction Lambda ou un job Glue, nous exécutons notre propre code sous ce rôle et lisons ses identifiants. Élévation instantanée.
• iam:CreatePolicyVersion ou AttachUserPolicy. Si notre utilisateur peut modifier ou attacher des policies, il peut s’attacher AdministratorAccess à lui-même. Fin de partie.
• Des rôles assumables avec une confiance trop lâche. Un rôle qui fait confiance à "Principal": {"AWS": "*"}, ou à une racine de compte trop large, est une porte laissée grande ouverte.

Les équivalents Azure et GCP sont tout aussi productifs. Sur Azure, nous cherchons des rôles personnalisés portant Microsoft.Authorization/roleAssignments/write, des service principals aux permissions Graph excessives, et des runbooks d’Automation Account ou des identités managées que nous pouvons détourner. Sur GCP, les primitives fiables sont iam.serviceAccounts.getAccessToken (générer un token pour un compte de service plus puissant), iam.serviceAccountKeys.create et setIamPolicy au niveau du projet. N’importe laquelle transforme un modeste point d’ancrage en propriété du projet.

Étape 4 : SSRF vers le service de métadonnées d’instance

La chaîne la plus rentable en test cloud est une faille de server-side request forgery dans une application capable d’atteindre l’endpoint de métadonnées. Pointez cette SSRF vers l’adresse de métadonnées link-local et tentez de lire les identifiants temporaires du rôle attaché.

http://169.254.169.254/latest/meta-data/iam/security-credentials/
# then, with the role name that comes back:
http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

Sur un hôte hérité en IMDSv1 qui renvoie un AccessKeyId, un SecretAccessKey et un token de session, nous les exportons et les utilisons directement. C’est le schéma derrière l’une des compromissions cloud les plus étudiées à ce jour, et la raison pour laquelle nous insistons autant sur IMDSv2. Les endpoints équivalents existent ailleurs : Azure sur 169.254.169.254/metadata/identity/oauth2/token avec un en-tête Metadata: true, et GCP sur metadata.google.internal avec Metadata-Flavor: Google. Ensuite, nous cartographions jusqu’où cette identité porte. Cette technique correspond exactement à MITRE ATT&CK T1552.005, identifiants non sécurisés issus de l’API de métadonnées d’instance cloud.

Étape 5 : stockage exposé et données publiques

Le stockage d’objets lisible publiquement reste l’un des constats sérieux les plus fréquents que nous rédigeons. Nous énumérons les buckets S3, les conteneurs Azure Blob et les buckets GCS liés à la cible, lisons leurs ACL et leurs bucket policies, et testons l’accès public en liste et en lecture. Puis nous testons l’écriture publique, celle que tout le monde oublie. Une écriture publique sur un bucket qui sert des assets de site ou des mises à jour logicielles n’est pas un problème d’exposition de données. C’est un problème de chaîne d’approvisionnement.

Le stockage n’est que la moitié de l’affaire. Nous ratissons aussi les secrets exposés : des clés d’accès commitées dans des dépôts publics, des clés incrustées dans des bundles d’applications mobiles, des tokens traînant dans le JavaScript front-end, et des entrées Secrets Manager ou Key Vault trop lisibles. Une seule clé valide et à longue durée de vie peut changer la forme de toute la mission.

Étape 6 : réseau, services et déplacement latéral

Ce n’est qu’après l’identité que le réseau nous intéresse. Nous examinons les security groups et les NSG à la recherche d’entrées ouvertes, du classique SSH et RDP exposés à 0.0.0.0/0, de bases de données pendues à l’Internet public, puis nous vérifions les endpoints RDS publics ou de bases managées et le comportement de la segmentation entre VPC, sous-réseaux et peering. Depuis une identité ou un hôte compromis, nous testons le déplacement. Pouvons-nous atteindre des services internes ? Assumer des rôles vers d’autres comptes ? Rebondir d’une subscription de dev vers la prod via une identité partagée ? Les frontières de confiance multi-comptes et multi-subscriptions tendent à être plus molles que ne le suggère le schéma d’architecture.

Étape 7 : quelqu’un nous a-t-il vus ?

Voici un constat qui nous importe autant que n’importe quel exploit : l’environnement s’en est-il aperçu ? Nous confirmons que CloudTrail est actif dans toutes les régions avec validation des fichiers de log, qu’Azure Monitor et les Activity Logs collectent, et que les GCP Cloud Audit Logs sont activés, centralisés et déclenchent des alertes sur les actions que nous venons de mener. Un attaquant qui crée une clé d’accès, désactive la journalisation et exfiltre des données devrait déclencher quelque chose. Sur bon nombre de missions, rien ne se déclenche du tout. Nous le signalons comme une lacune de détection, et nous ne l’édulcorons pas, car la prévention finit par échouer et la détection est le filet de sécurité.

Comment prévenir ce que nous trouvons ?

Le moindre privilège est tout le jeu. Restreignez les policies IAM à des actions et des ressources précises, supprimez les wildcards, et utilisez des permission boundaries et des service control policies pour plafonner ce qu’une identité peut atteindre. Imposez IMDSv2 sur chaque instance afin qu’une SSRF égarée ne puisse pas générer d’identifiants. Activez le blocage de l’accès public à l’échelle du compte pour S3, gardez Blob et GCS privés par défaut, et vérifiez-le au lieu de vous fier au réglage par défaut de la console. Préférez des identifiants fédérés à courte durée de vie aux clés à longue durée de vie, et faites tourner les clés que vous ne pouvez vraiment pas éviter. Et rendez la journalisation réelle : centralisée, inviolable et reliée à des alertes sur lesquelles un humain ou un SIEM agira. Un log que personne ne lit, c’est du théâtre.

Comment CyberXplore vous aide

Notre service de test d’intrusion cloud déroule exactement cette méthodologie contre vos environnements AWS, Azure et GCP. Centré sur l’identité, manuel, et concentré sur l’enchaînement des erreurs de configuration jusqu’à l’impact qu’atteindrait un véritable attaquant, plutôt que sur l’impression d’une liste d’alertes CSPM. Vous obtenez des constats classés par exploitabilité, des étapes de reproduction que vous pouvez remettre à l’ingénierie, et un nouveau test gratuit une fois la correction faite. Si vous voulez un test cadré de votre empreinte cloud, demandez un devis et nous adapterons la mission à vos comptes et aux règles d’engagement du fournisseur.

FAQ

AWS, Azure et GCP autorisent-ils le test d’intrusion cloud ?

Oui, dans certaines limites. Les trois fournisseurs autorisent le test de vos propres ressources pour la plupart des services courants sans approbation préalable, et chacun restreint les tests de déni de service et certains services managés. Nous travaillons dans le cadre de la politique d’utilisation acceptable actuellement publiée par le fournisseur pour tout ce qui est dans le périmètre, et nous exigeons une autorisation écrite du propriétaire du compte avant de commencer.

Quelle est la différence entre un scan CSPM et un test d’intrusion cloud ?

Un outil de cloud security posture management signale en continu les erreurs de configuration au regard d’un ensemble de règles, ce qui est utile, mais il rapporte chaque problème isolément. Un test d’intrusion enchaîne ces problèmes, si bien qu’un rôle en lecture seule plus une permission PassRole plus une SSRF devient une prise de contrôle de compte démontrée. Nous utilisons les scanners pour la couverture et le test manuel pour l’impact.

Avez-vous besoin d’identifiants, ou pouvez-vous tester depuis l’extérieur ?

Les deux sont valables et répondent à des questions différentes. Un test externe, non authentifié, mesure votre surface d’attaque exposée. Un test authentifié en “assumed breach”, partant d’une identité à faibles privilèges, tend à faire remonter les chemins d’élévation et de déplacement latéral qui comptent le plus. Pour le travail cloud, nous recommandons généralement l’approche authentifiée.

Combien de temps prend un test d’intrusion cloud ?

Cela dépend du nombre de comptes, de l’étendue des services et du caractère mono ou multi-cloud. Un unique compte AWS bien cadré prend moins de temps qu’une organisation multi-comptes avec Azure et GCP dans le lot. Le périmètre dicte le calendrier, et c’est pourquoi nous dimensionnons chaque test individuellement au lieu d’annoncer un chiffre forfaitaire.

Quels sont les constats cloud les plus fréquents que vous rapportez ?

Les policies IAM trop permissives et les chemins d’élévation de privilèges dominent de loin, suivis du stockage exposé publiquement, de la SSRF qui atteint le service de métadonnées d’instance, et d’une journalisation insuffisante ou non surveillée. Pris isolément, ils vont d’une gravité moyenne à élevée. Enchaînés, ils deviennent régulièrement critiques.