AWS IAM Privilege Escalation: Wie Angriffspfade entstehen und wie man sie unterbricht

Vom Pathbreak-Team · 11. August 2026 · 7 Min. Lesezeit

Fast jeder ernsthafte AWS-Vorfall verläuft auf dieselbe Weise. Ein Angreifer landet auf einer Identität mit geringen Rechten, einem geleakten Access Key, einer kompromittierten CI-Rolle, einer App-Zugangsberechtigung, und innerhalb weniger Schritte ist er Administrator. In den meisten dieser Fälle gibt es keinen Zero-Day. Der Angreifer nutzt Berechtigungen, die das Konto absichtlich vergeben hat, in einer Kombination, die niemand beabsichtigt hat.

Diese Kombination ist ein IAM-Privilege-Escalation-Pfad. Dieser Beitrag führt durch, wie solche Pfade in AWS entstehen, welche Berechtigungskombinationen sie erzeugen, warum sie sich einer gewöhnlichen Prüfung entziehen und wie man sie findet und unterbricht.

Was ist IAM Privilege Escalation?

IAM Privilege Escalation liegt vor, wenn eine Identität den Zugriff, den sie bereits hat, nutzt, um sich mehr Zugriff zu gewähren oder zu erreichen, als sie haben sollte. In AWS passiert das fast immer in der Control Plane, der API-Oberfläche, die Identitäten und Berechtigungen verwaltet, und nicht durch das Eindringen in eine Workload.

AWS tut genau das, was Sie ihm gesagt haben. Wenn eine Identität eine Policy bearbeiten, eine Rolle übergeben oder einen Schlüssel erstellen kann, lässt AWS das zu. Eskalation entsteht meist aus einer Berechtigung, die absichtlich vergeben wurde, mit einem Zweitrundeneffekt, den niemand nachverfolgt hat.

Wie Privilege-Escalation-Pfade entstehen

Die meisten AWS-Eskalationspfade fallen in eine Handvoll Familien. Keine davon erfordert Admin. Jede nimmt eine eng gefasste Schreibberechtigung und verwandelt sie in breite Macht.

Eine Rolle an einen Service übergeben, den Sie kontrollieren

Am häufigsten ist iam:PassRole in Kombination mit einem Compute-Service. Wenn eine Identität eine privilegierte Rolle an eine EC2-Instanz, eine Lambda-Funktion, eine ECS-Task oder einen Glue-Job übergeben kann und diesen Service auch starten kann, kann sie Code als die privilegierte Rolle ausführen und deren Berechtigungen erben. Die Identität hat sich eine Rolle geborgt, die die Berechtigungen hatte, die ihr fehlten. Deshalb ist iam:PassRole die Berechtigung, die man am genauesten im Auge behalten sollte, und deshalb sollte sie stets dadurch eingeschränkt sein, welche Rollen an welchen Service übergeben werden können.

Eine Policy neu schreiben, die Sie bearbeiten dürfen

Wenn eine Identität iam:CreatePolicyVersion hat, kann sie eine neue Version einer customer-managed Policy mit beliebigen Berechtigungen veröffentlichen und diese Version dann als Standard festlegen. Aus einer Policy, die Lesezugriff auf einen Bucket gewährte, wird eine Policy, die alles gewährt. Dieselbe Idee gilt für iam:PutUserPolicy, iam:PutRolePolicy und iam:PutGroupPolicy bei Inline-Policies. Die Berechtigung liest sich wie routinemäßige Policy-Pflege, und sie kann neu schreiben, was auch immer diese Policy gewährt.

Eine stärkere Policy anhängen

Berechtigungen wie iam:AttachUserPolicy, iam:AttachRolePolicy und iam:AttachGroupPolicy erlauben es einer Identität, eine bestehende Managed Policy an sich selbst oder an einen von ihr kontrollierten Principal anzuhängen. Hängen Sie AdministratorAccess an, und der Aufstieg ist mit einem einzigen Aufruf vorbei. Das funktioniert, weil die Berechtigung zu breit gefasst war.

Neue Zugangsdaten für eine stärkere Identität erstellen

Mehrere Berechtigungen erlauben es einer Identität, frische Zugangsdaten für einen Principal zu erstellen, der bereits mehr Privilegien hat. iam:CreateAccessKey bei einem anderen Benutzer stellt diesem Benutzer einen neuen Schlüssel aus. iam:CreateLoginProfile setzt ein Konsolenpasswort für einen Benutzer, der keines hat. iam:UpdateLoginProfile setzt eines zurück. In jedem Fall gewinnt der Angreifer eine stärkere Identität, als die er sich authentifizieren kann, statt der Identität, die er bereits hat, Berechtigungen hinzuzufügen.

Eine Trust-Policy lockern

Die Trust-Policy einer Rolle entscheidet, wer sie übernehmen darf. Wenn eine Identität iam:UpdateAssumeRolePolicy auf einer privilegierten Rolle hat, kann sie diese Trust-Policy so umschreiben, dass sie sich selbst zulässt, dann sts:AssumeRole aufrufen und zur Rolle werden. Das verwandte Risiko ist eine Rolle, die bereits zu breit vertraut, ein Wildcard-Principal oder ein ganzes Konto, sodass das Übernehmen nie das Bearbeiten von irgendetwas erfordert hat.

Warum isolierte Berechtigungen den Pfad verbergen

Betrachten Sie eine dieser Berechtigungen einzeln in einer Policy-Prüfung, und sie liest sich als vernünftig. Eine Deployment-Identität braucht iam:PassRole. Ein Plattform-Team muss Policies verwalten. Ein Automatisierungsbenutzer muss Schlüssel rotieren. Jede Vergabe hat eine gute Geschichte.

Die Eskalation taucht erst auf, wenn Sie die Vergabe mit dem verbinden, was sie erreichen kann. iam:PassRole ist harmlos, bis Sie fragen, welche Rollen sie übergeben kann und ob die Identität auch den Service starten kann, der sie ausführen würde. Eine Bearbeitung einer Managed Policy ist in Ordnung, bis Sie bemerken, dass die Policy an eine Admin-Rolle angehängt ist. Der Pfad zeigt sich erst, wenn Sie den gesamten Graphen betrachten, und eine Prüfung, die eine Policy nach der anderen vornimmt, tut das nie. Deshalb kann eine Prüfung Hunderte von Findings zurückgeben und trotzdem die Kette übersehen, die den Admin erreicht.

Tools, die ihn kartieren

Sie müssen das nicht von Hand durchdenken. AWS IAM Access Analyzer meldet externen und ungenutzten Zugriff und kann Policies validieren. Open-Source-Tools modellieren die Beziehungen: PMapper baut einen Graphen, wer wen erreichen kann, Cloudsplaining markiert Policies mit eskalationsanfälligen Berechtigungen, und offensive Frameworks wie Pacu zählen bekannte Eskalationsmethoden auf. Diese sind wertvoll, und sie kartieren Kandidaten, die Schritte, die funktionieren könnten.

Die meisten Tools kommen nicht bis zum Beweis. Zu wissen, dass eine Identität iam:PassRole hat, ist nicht dasselbe wie zu wissen, dass diese Identität, gegeben jede Policy, jede Boundary und jede Service Control Policy in Kraft, heute einen Administrator erreichen kann. Das zu prüfen ist das, was aus einem Kandidaten einen validierten Pfad macht.

Wie Verteidiger diese Pfade unterbrechen

Das Gute an Ketten ist, dass Sie nur eine Kante durchtrennen müssen. Ein paar dauerhafte Schritte schließen die meisten Eskalationspfade:

Schränken Sie iam:PassRole so ein, dass eine Identität nur bestimmte Rollen übergeben kann, und fügen Sie eine iam:PassedToService-Bedingung hinzu, damit eine für Lambda gedachte Rolle nicht an EC2 übergeben werden kann. Behandeln Sie iam:-Schreibaktionen, insbesondere Policy-Bearbeitungen, Anhänge und die Erstellung von Zugangsdaten, als hochprivilegiert und vergeben Sie sie eng. Setzen Sie eine Permissions Boundary auf Identitäten, die IAM-Schreibberechtigungen haben müssen, damit sie eine Obergrenze nicht überschreiten können. Nutzen Sie Service Control Policies, um das effektive Privileg über die Organisation hinweg zu begrenzen, sodass selbst ein fehlkonfiguriertes Konto den Admin nicht erreichen kann. Verschärfen Sie Trust-Policies von Rollen, sodass sie exakte Principals benennen, nie ein nacktes Konto oder einen Wildcard. Überwachen Sie dann CloudTrail auf die verräterischen Aufrufe: CreatePolicyVersion, AttachRolePolicy, UpdateAssumeRolePolicy, CreateAccessKey bei einer Identität, die sie normalerweise nicht vornimmt.

Der schwierige Teil ist zu wissen, welche Pfade bestehen bleiben, nachdem alle Ihre Kontrollen zusammenwirken, und diese Antwort aktuell zu halten, während sich Policies jeden Tag ändern.

Wie Pathbreak es angeht

Pathbreak behandelt IAM so, wie ein Angreifer es tut, als einen Graphen von Erreichbarkeit statt als eine Liste von Policies. Es schlussfolgert über Ihre realen Identitäten, Rollen, Policies, Boundaries und Vertrauensbeziehungen und löst dann die Autorisierung auf, um zu bestätigen, welche Identitäten zum Admin eskalieren oder sensible Daten erreichen können. Es tut dies read-only. Nichts wird gegen Ihr Konto ausgeführt, und nichts wird verändert.

Wenn sich ein Pfad auflöst, zeigt Pathbreak die vollständige Kette und gibt Ihnen die eine Änderung, die ihn unterbricht, die zu entfernende PassRole-Berechtigung, die zu verschärfende Policy, die zu schließende Vertrauensbeziehung. Sie beheben diese Kante, statt tausend unpriorisierte Findings zu triagieren. Die Mechanik sehen Sie auf der Seite So funktioniert es, die Ketten, die wir abdecken, auf der Seite Angriffspfade, und wie wir mit Zugriff umgehen, auf der Seite Trust und Sicherheit.

Häufig gestellte Fragen