English
Español
Français
Deutsch
日本語
한국어
العربيةCarte d'escalade de privilèges AWS
La carte d'attaque Pathbreak pour AWS
Sélectionné par Pathbreak Research · Mis à jour en octobre 2026
La carte publique la plus complète des permissions AWS qu'un attaquant peut enchaîner jusqu'à l'administrateur, aux données ou à la persistance : comment chacune est utilisée, les événements CloudTrail qui la détectent, la technique MITRE ATT&CK et le changement unique qui brise le chemin. Chaque chemin est vérifié par rapport à l'autorisation réelle avant que Pathbreak ne le signale.
Commencer ici
Combinaisons à connaître
De nombreuses permissions AWS n'atteignent l'accès admin que lorsqu'elles s'alignent avec d'autres. Ces combinaisons sont celles qu'un examen politique par politique a tendance à manquer. En voici quelques-unes. La carte complète est consultable ci-dessous.
Détourner le user-data EC2
Un principal peut arrêter l'instance, réécrire ses user-data avec ec2:ModifyInstanceAttribute, et la redémarrer ; au démarrage, l'instance exécute le script user-data de l'attaquant en tant que son rôle de profil d'instance déjà attaché, sans iam:PassRole. Un profil d'instance privilégié signifie une exécution de code arbitraire en tant que ce rôle : une escalade de privilèges complète contre une machine qui était déjà de confiance.
Détourner le rôle de stack CloudFormation via un change set
Un principal peut appeler cloudformation:CreateChangeSet et cloudformation:ExecuteChangeSet sur une stack CloudFormation existante qui porte déjà le rôle de service. En préparant un modèle modifié sous forme de change set et en l'exécutant, le principal fait appliquer par CloudFormation les modifications de l'attaquant en utilisant le rôle cible, sans iam:PassRole, car le rôle cible est déjà lié à la stack. Un rôle de service privilégié signifie que le modèle de l'attaquant peut provisionner des ressources admin : escalade de privilèges complète contre une stack qui était déjà de confiance.
Détourner le rôle d'instance via une commande SSM
Un principal peut appeler ssm:SendCommand pour exécuter un document AWS-RunShellScript sur une instance gérée par SSM qui porte déjà le rôle de profil d'instance, exécutant des commandes de l'attaquant qui lisent les identifiants actifs de l'instance depuis IMDS et les expédient, de manière non interactive, sans session shell, clé ni port ouvert. Comme l'instance est déjà liée à la machine, l'exécution de commandes sur celle-ci suffit à voler le rôle, sans iam:PassRole. Si l'instance est privilégiée, il s'agit d'une escalade de privilèges complète contre une instance qui était déjà de confiance, et c'est scriptable sur de nombreuses instances à la fois.
Vérifiez votre propre compte face à ces chemins. pathbreak-audit est notre outil en ligne de commande open source et gratuit pour les défenseurs : pointez-le vers un compte AWS, en lecture seule, et il vous montre les rôles et utilisateurs à risque, et exactement quoi couper.
pip install pathbreak-audit
Recherchez par permission, service ou technique MITRE. Plusieurs mots affinent les résultats.
Aucune permission ne correspond à ce filtre.
Chargement de la carte...
Ce que montrent les données
Des tendances à travers chaque chemin de la carte. Elles décrivent où l'escalade de privilèges AWS se concentre et où un défenseur obtient la meilleure couverture pour le moindre changement. Chaque pourcentage correspond à la part des entrées de cette carte qui présentent cette propriété, calculée à partir du catalogue de la carte : les chiffres décrivent les chemins documentés et ne disent rien d'un compte AWS en particulier.
des chemins d'escalade de privilèges de la carte reposent sur iam:PassRole. iam:PassRole est la permission la plus fréquemment réutilisée dans l'ensemble du jeu de données. Elle apparaît dans des chemins qui atteignent 23 services AWS, car tout service qui exécute des charges de travail pour vous accepte un rôle que vous lui transmettez. Restreindre iam:PassRole à des ARN de rôle spécifiques et épingler iam:PassedToService en supprime la plupart d'un coup.
ne nécessitent qu'une seule permission pour atteindre l'impact. La plupart des chemins de la carte ne requièrent qu'une seule action trop large. Le reste dépend d'une combinaison de deux permissions ou plus détenues ensemble. Un examen au moindre privilège des actions individuelles couvre la plus grande part.
des correctifs d'escalade de privilèges sont un changement de portée ou de condition, et non une suppression. Le changement recommandé consiste généralement à contraindre une permission (une portée de ressource, une condition iam:PassedToService ou un garde-fou d'organisation) plutôt qu'à la retirer, de sorte que l'équipe conserve la capacité tandis que le chemin se ferme.
des chemins sont observables à partir d'un seul événement CloudTrail. Chaque entrée liste les événements du plan de gestion qui enregistrent l'action. La plupart correspondent à un seul événement, les règles de détection peuvent donc être écrites par chemin sans corrélation lourde.
font aussi office de mécanisme de persistance. Une grande partie de ces actions permettent à un attaquant de conserver l'accès après la fermeture de l'entrée initiale (un identifiant permanent, une modification MFA, une modification d'approbation). Elles valent la peine qu'on alerte dessus même lorsqu'elles ressemblent à de l'administration de routine.
sont des manœuvres d'évasion de défense contre votre propre journalisation et vos garde-fous. Arrêter CloudTrail, désactiver GuardDuty ou Security Hub, supprimer des journaux de flux ou détacher une SCP apparaît chacun comme une entrée distincte. Ce sont des actions à appel unique, un refus sur l'outillage de sécurité est donc le contrôle le plus net.
Qui utilise ces chemins ? Les mêmes manœuvres apparaissent dans de vrais incidents cloud. Découvrez les groupes qui en sont à l'origine dans la Acteurs de menaces cloud reference.
Voyez lesquels de ces éléments existent dans votre compte
Pathbreak se connecte avec un rôle en lecture seule, trouve les chemins qui se résolvent face à votre autorisation réelle, et classe les rares changements qui coupent le plus. Un compte, une analyse, les premiers chemins validés en moins d'une heure.
Questions
Quelles sont les permissions AWS IAM les plus dangereuses ?
Les permissions qui permettent à un principal de changer qui peut faire quoi, ou d'exécuter du code en tant que rôle plus privilégié : iam:PutRolePolicy, iam:AttachRolePolicy, iam:CreatePolicyVersion, iam:UpdateAssumeRolePolicy et iam:PassRole associé à un service de calcul. Cette carte liste chacune de celles que Pathbreak suit, et le changement qui casse le chemin.
Pourquoi iam:PassRole est-il dangereux ?
iam:PassRole permet à un principal de transmettre un rôle IAM à un service AWS. Octroyé sur une ressource générique, un attaquant transmet un rôle privilégié à un service qu'il peut exécuter (EC2, Lambda, ECS et d'autres) et en hérite. Restreignez iam:PassRole à des ARN de rôle spécifiques et épinglez iam:PassedToService.
Comment prévenir l'escalade de privilèges AWS ?
Restreindre la portée de iam:PassRole, maintenir des limites d'autorisations sur les rôles, refuser les modifications de politique IAM et d'approbation en dehors d'un rôle de gestion des changements, et alerter sur les événements CloudTrail listés ici. Pathbreak valide quels chemins se concrétisent dans votre compte et classe les quelques changements qui en coupent le plus.
Est-ce que cela couvre plus que l'escalade de privilèges ?
Oui. Elle couvre aussi l'accès aux identifiants, l'évasion de défense, l'exposition de ressources, l'accès aux données et la persistance, car les vrais chemins d'attaque traversent ces catégories en chemin vers l'impact.
Qu'est-ce que la carte d'escalade de privilèges AWS ?
C'est une référence publique des permissions AWS qu'un attaquant peut enchaîner vers un accès administrateur, des données ou de la persistance. Chacune dispose de sa propre page présentant son mode d'utilisation, les événements CloudTrail qui la détectent, la technique MITRE ATT&CK et le contrôle qui supprimerait le chemin. C'est la version publique de ce sur quoi Pathbreak raisonne à l'intérieur d'un compte.
À qui cela s'adresse-t-il ?
Ingénieurs en sécurité cloud, ingénieurs en détection, équipes red team et toute personne rédigeant des politiques IAM. Utilisez-le pour comprendre ce qu'une permission ouvre avant de l'accorder, pour créer des règles de détection ou pour modéliser les menaces d'un compte.
Comment l'utiliser ?
Recherchez par permission, par service ou par combinaison de permissions. Ouvrez n'importe quelle entrée pour voir la chaîne d'attaque, les événements de détection sur lesquels vous pouvez alerter dès aujourd'hui, la technique MITRE et le changement qui briserait le chemin. Chaque page est une référence autonome vers laquelle vous pouvez créer un lien.
En quoi une permission unique diffère-t-elle d'une combinaison toxique ?
Certaines permissions accordent l'escalade à elles seules. Beaucoup ne le font que lorsqu'elles sont détenues conjointement avec d'autres, par exemple iam:PassRole avec une action de service. Ce sont ces combinaisons qu'un examen politique par politique a tendance à manquer, c'est pourquoi la carte étiquette chaque entrée et vous permet de filtrer sur les seules combinaisons.
Est-ce la liste complète des permissions AWS dangereuses ?
Elle couvre les chemins que Pathbreak suit aujourd'hui et nous la maintenons à jour à mesure qu'AWS lance de nouveaux services. Si vous pensez qu'un élément manque ou est erroné, écrivez à hello@pathbreak.io et nous l'examinerons.
Comment Pathbreak utilise-t-il ceci dans mon compte ?
Pathbreak se connecte en lecture seule, résout vos véritables politiques IAM, rôles et relations de confiance, et confirme lesquels de ces chemins existent réellement pour vos identités. Il les classe selon l'ampleur de ce que chacun ouvre et, avec votre modèle de menace et votre contexte métier, montre quels rares changements coupent le plus. Les premiers chemins validés reviennent en moins d'une heure.
Les glyphes de service sont basés sur le jeu AWS Architecture Icons, recolorés pour identifier chaque service. AWS et les noms de service sont des marques d'Amazon Web Services. Pathbreak n'est ni affilié à AWS ni approuvé par AWS.