Escalade de privilèges IAM AWS : comment se forment les chemins d'attaque et comment les briser

Par l'équipe Pathbreak · 11 août 2026 · 7 min de lecture

Presque tous les incidents AWS sérieux se déroulent de la même façon. Un attaquant atterrit sur une identité à faibles privilèges, une clé d'accès divulguée, un rôle CI compromis, un identifiant d'application, et en quelques étapes il est administrateur. Dans la plupart de ces cas, il n'y a pas de zero-day. L'attaquant utilise des permissions que le compte a distribuées à dessein, dans une combinaison que personne n'avait prévue.

Cette combinaison est un chemin d'escalade de privilèges IAM. Cet article explique comment ces chemins se forment dans AWS, les combinaisons de permissions qui les créent, pourquoi ils échappent à l'examen ordinaire, et comment les trouver et les briser.

Qu'est-ce que l'escalade de privilèges IAM ?

L'escalade de privilèges IAM, c'est quand une identité utilise l'accès qu'elle a déjà pour s'accorder, ou atteindre, plus d'accès qu'elle n'aurait dû avoir. Dans AWS, cela se produit presque toujours sur le control plane, la surface d'API qui gère les identités et les permissions, plutôt qu'en s'introduisant dans une charge de travail.

AWS fait exactement ce que vous lui avez dit de faire. Si une identité peut modifier une politique, transmettre un rôle ou créer une clé, AWS le lui permet. L'escalade vient généralement d'une permission accordée à dessein, avec un effet de second ordre que personne n'a retracé.

Comment se forment les chemins d'escalade de privilèges

La plupart des chemins d'escalade AWS relèvent d'une poignée de familles. Aucune d'elles ne requiert les droits admin. Chacune prend une permission d'écriture étroite et la transforme en pouvoir étendu.

Transmettre un rôle à un service que vous contrôlez

Le plus courant est iam:PassRole combiné à un service de calcul. Si une identité peut transmettre un rôle privilégié à une instance EC2, une fonction Lambda, une tâche ECS ou un job Glue, et qu'elle peut aussi lancer ce service, elle peut exécuter du code en tant que rôle privilégié et hériter de ses permissions. L'identité a emprunté un rôle qui possédait les permissions qui lui manquaient. C'est pourquoi iam:PassRole est la permission à surveiller de plus près, et pourquoi elle devrait toujours être contrainte par les rôles qui peuvent être transmis et à quel service.

Réécrire une politique que vous êtes autorisé à modifier

Si une identité possède iam:CreatePolicyVersion, elle peut publier une nouvelle version d'une politique gérée par le client avec les permissions qu'elle souhaite, puis définir cette version comme version par défaut. Une politique qui n'accordait l'accès en lecture qu'à un seul bucket devient une politique qui accorde tout. La même idée s'applique à iam:PutUserPolicy, iam:PutRolePolicy et iam:PutGroupPolicy pour les politiques en ligne. La permission se lit comme une maintenance de politique de routine, et elle peut réécrire tout ce que cette politique accorde.

Attacher une politique plus puissante

Des permissions comme iam:AttachUserPolicy, iam:AttachRolePolicy et iam:AttachGroupPolicy permettent à une identité d'attacher une politique gérée existante à elle-même ou à un principal qu'elle contrôle. Attachez AdministratorAccess et l'ascension est terminée en un seul appel. Cela fonctionne parce que la permission a été accordée de manière trop large.

Créer de nouveaux identifiants pour une identité plus puissante

Plusieurs permissions permettent à une identité de créer de nouveaux identifiants pour un principal qui dispose déjà de plus de privilèges. iam:CreateAccessKey sur un autre utilisateur délivre à cet utilisateur une nouvelle clé. iam:CreateLoginProfile définit un mot de passe de console pour un utilisateur qui n'en a pas. iam:UpdateLoginProfile en réinitialise un. Dans chaque cas, l'attaquant obtient une identité plus puissante pour s'authentifier, au lieu d'ajouter des permissions à celle qu'il possède déjà.

Relâcher une politique de confiance

La politique de confiance d'un rôle décide qui peut l'endosser. Si une identité possède iam:UpdateAssumeRolePolicy sur un rôle privilégié, elle peut réécrire cette politique de confiance pour s'autoriser elle-même, puis appeler sts:AssumeRole et devenir le rôle. Le risque connexe est un rôle qui fait déjà confiance de manière trop large, un principal avec joker ou un compte entier, de sorte que l'endosser n'a jamais nécessité de modifier quoi que ce soit.

Pourquoi les permissions isolées masquent le chemin

Examinez l'une quelconque de ces permissions dans une revue de politiques et elle paraît raisonnable. Une identité de déploiement a besoin de iam:PassRole. Une équipe plateforme a besoin de gérer des politiques. Un utilisateur d'automatisation a besoin de faire tourner les clés. Chaque octroi a une bonne justification.

L'escalade n'apparaît que lorsque vous reliez l'octroi à ce qu'il peut atteindre. iam:PassRole est inoffensif jusqu'à ce que vous demandiez quels rôles il peut transmettre et si l'identité peut aussi lancer le service qui les exécuterait. Une modification de politique gérée n'est pas un problème jusqu'à ce que vous remarquiez que la politique est attachée à un rôle admin. Le chemin n'apparaît que lorsque vous regardez le graphe entier, et un examen qui prend une politique à la fois ne le fait jamais. C'est pourquoi un examen peut renvoyer des centaines de résultats et manquer tout de même la chaîne qui atteint l'administrateur.

Les outils qui le cartographient

Vous n'avez pas à raisonner là-dessus à la main. AWS IAM Access Analyzer signale les accès externes et inutilisés et peut valider les politiques. Des outils open-source modélisent les relations : PMapper construit un graphe de qui peut atteindre qui, Cloudsplaining signale les politiques comportant des permissions propices à l'escalade, et des frameworks offensifs comme Pacu énumèrent les méthodes d'escalade connues. Ceux-ci sont précieux, et ils cartographient les candidats, les mouvements qui pourraient fonctionner.

La plupart des outils s'arrêtent avant la preuve. Savoir qu'une identité possède iam:PassRole n'est pas la même chose que savoir que, compte tenu de toutes les politiques, limites et service control policies en vigueur, cette identité peut atteindre un administrateur aujourd'hui. Vérifier cela est ce qui transforme un candidat en un chemin validé.

Comment les défenseurs brisent ces chemins

La bonne nouvelle au sujet des chaînes, c'est que vous n'avez qu'un seul lien à couper. Quelques mouvements durables ferment la plupart des chemins d'escalade :

Contraignez iam:PassRole pour qu'une identité ne puisse transmettre que des rôles spécifiques, et ajoutez une condition iam:PassedToService afin qu'un rôle destiné à Lambda ne puisse pas être transmis à EC2. Traitez les actions d'écriture iam:, en particulier les modifications de politiques, les attachements et la création d'identifiants, comme hautement privilégiées et accordez-les de façon restreinte. Posez une limite de permissions sur les identités qui doivent disposer de permissions d'écriture IAM afin qu'elles ne puissent pas dépasser un plafond. Utilisez des service control policies pour plafonner le privilège effectif à l'échelle de l'organisation, de sorte que même un compte mal configuré ne puisse pas atteindre les droits admin. Resserrez les politiques de confiance des rôles pour nommer des principaux exacts, jamais un compte nu ou un joker. Puis surveillez CloudTrail pour les appels révélateurs : CreatePolicyVersion, AttachRolePolicy, UpdateAssumeRolePolicy, CreateAccessKey sur une identité qui ne les effectue pas d'habitude.

Le plus difficile est de savoir quels chemins subsistent une fois que tous vos contrôles interagissent, et de garder cette réponse à jour alors que les politiques changent chaque jour.

Comment Pathbreak l'aborde

Pathbreak traite IAM comme le fait un attaquant, comme un graphe d'accessibilité plutôt qu'une liste de politiques. Il raisonne sur vos identités, rôles, politiques, limites et relations de confiance réels, puis résout l'autorisation pour confirmer quelles identités peuvent escalader jusqu'aux droits admin ou atteindre des données sensibles. Il le fait en lecture seule. Rien ne s'exécute contre votre compte, et rien n'est modifié.

Quand un chemin se résout, Pathbreak montre la chaîne complète et vous remet le seul changement qui le brise, l'octroi de PassRole à supprimer, la politique à resserrer, la relation de confiance à fermer. Vous corrigez ce lien au lieu de trier un millier de résultats non hiérarchisés. Vous pouvez voir les mécanismes sur la page comment ça marche, les chaînes que nous couvrons sur la page chemins d'attaque, et la manière dont nous gérons l'accès sur la page Confiance et sécurité.

Questions fréquentes