← Alle Beiträge Referenz

Die AWS Privilege Escalation Map

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

Wichtigste Erkenntnisse

Wir haben eine Referenz der AWS-Berechtigungen erstellt, die ein Angreifer zu Administrator, Daten oder Persistenz verketten kann, mit einer Seite für jede einzelne.
Jeder Eintrag enthält dieselben vier Dinge: wie die Berechtigung genutzt wird, die CloudTrail-Ereignisse, die sie erkennen, die MITRE ATT&CK-Technik und das Control, das den Pfad entfernen würde.
Über die Hälfte der Privilege-Escalation-Einträge laufen durch iam:PassRole. Es ist die eine Berechtigung, die die meisten Services berührt.
Manche Berechtigungen eskalieren von sich aus. Viele eskalieren nur in einer Kombination, zusammen mit anderen gehalten. Diese toxischen Kombinationen sind die, die eine Prüfung Policy für Policy übersieht.
Zu wissen, dass eine Berechtigung gefährlich ist, ist nicht dasselbe wie zu wissen, dass sie in Ihrem Konto gefährlich ist. Das erfordert eine Validierung gegen Ihre reale Autorisierung und eine Entscheidung im Geschäftskontext, ob die Berechtigung tragend ist.

Fragen Sie zehn AWS-Ingenieure, welche Berechtigungen gefährlich sind, und Sie bekommen zehn kurze Listen. Alle nennen iam:PassRole. Die meisten nennen die Policy-Änderungen. Danach wird es vage, denn die echte Antwort ist lang, sie ändert sich, sobald AWS neue Services ausliefert, und der größte Teil der Gefahr liegt in Kombinationen statt in einzelnen Aktionen.

Also haben wir es aufgeschrieben. Die AWS Privilege Escalation Map ist eine Seite für jede Berechtigung, die ein Angreifer zu Administratorzugriff, Daten oder einem Weg zurück hinein verketten kann. Sie können sie nach Service, nach Technik oder nach einer Kombination von Berechtigungen durchsuchen, und jeder Eintrag liest sich gleich.

Was auf jeder Seite steht

Jeder Eintrag beantwortet vier Fragen. Wie wird die Berechtigung genutzt, allein oder nur zusammen mit anderen. Wie sehen Sie sie, als die CloudTrail-Ereignisse, die den Aufruf aufzeichnen. Wo steht sie im Playbook des Angreifers, als die MITRE ATT&CK-Technik. Und was würde den Pfad entfernen, als das Control, das ein Verteidiger anwenden könnte. Die Seite zeichnet den Zug als Kette, vom Angreifer-Principal zu allem, was die Berechtigung erreicht, mit der realen API-Aktion auf jedem Schritt.

Eine toxische Kombination aus der Map. Mit lambda:CreateFunction und iam:PassRole zusammen gehalten erstellt ein Principal eine Function, übergibt ihr eine privilegierte Rolle, und die Function läuft als diese Rolle. Keine der beiden Berechtigungen ist für sich allein alarmierend.

Ein Pfad, Schritt für Schritt

Nehmen Sie den Zug von oben, den, auf den sich mehr als die Hälfte der Privilege-Escalation-Einträge stützt. Als zwei getrennte Policy-Statements gelesen, sieht keines gefährlich aus. Verkettet führen sie Angreifer-Code als eine Rolle aus, die dem Principal nie gewährt wurde.

Schritt 1. Starten Sie als gewöhnlicher Principal. Eine Entwickler- oder CI-Rolle, die lambda:CreateFunction und iam:PassRole hält, reicht aus. Nichts hiervon ist bislang Administrator.
Schritt 2. Erstellen Sie eine Function mit Angreifer-Code (lambda:CreateFunction). Der Function-Body ist, was auch immer der Angreifer ausführen will.
Schritt 3. Übergeben Sie ihr eine privilegierte Rolle (iam:PassRole). Richten Sie die Function auf eine Rolle mit mehr Zugriff, als der Principal hält, etwa eine, die jeden Bucket lesen oder Policies anhängen kann.
Schritt 4. Rufen Sie sie auf, und der Code läuft als diese Rolle. Der Principal hat sich Zugriff geliehen, der ihm nie gewährt wurde, und das ist die ganze Eskalation.
Schritt 5. Der Schnitt: Scopen Sie iam:PassRole auf bestimmte Rollen-ARNs und pinnen Sie iam:PassedToService. Diese eine Änderung schließt diesen Pfad und einen großen Teil des restlichen Maps, denn jeder Service, der Code für Sie ausführt, akzeptiert eine übergebene Rolle auf dieselbe Weise.

Das ist ein Eintrag. Die Map zeichnet dieselbe Kette für jede Berechtigung, die sie abdeckt, sodass Sie den Zug sehen, bevor Sie entscheiden, ob die Berechtigung in Ihrem eigenen Konto tragend ist.

iam:PassRole ist der rote Faden

Von den Privilege-Escalation-Einträgen in der Map stützen sich mehr als die Hälfte auf iam:PassRole. Es taucht in Pfaden auf, die zwei Dutzend verschiedene Services erreichen, denn jeder Service, der Code für Sie ausführt, akzeptiert eine Rolle, die Sie ihm übergeben. Lambda, EC2, ECS, Glue, SageMaker, CodeBuild, Step Functions und der Rest nehmen alle eine übergebene Rolle und laufen als diese. Deshalb ist eine einzige iam:PassRole-Gewährung auf einer Wildcard-Ressource für einen Angreifer mehr wert als fast jede andere Berechtigung. Scopen Sie sie auf bestimmte Rollen-ARNs und pinnen Sie iam:PassedToService, und ein großer Teil der Map schließt sich auf einen Schlag.

Einzelne Berechtigungen und toxische Kombinationen

Manche Berechtigungen eskalieren von sich aus. iam:AttachUserPolicy mit einer ausreichend weiten Ressource eskaliert von sich aus. Doch viele der gefährlichsten Pfade brauchen zwei oder mehr zusammen gehaltene Berechtigungen, und keine davon sieht für sich allein alarmierend aus. iam:PassRole ist harmlos ohne eine Service-Aktion, die es nutzt. lambda:CreateFunction ist harmlos ohne eine Rolle zum Übergeben. Halten Sie beide, und Sie haben beliebigen Code, der als privilegierte Rolle läuft.

Diese toxischen Kombinationen sind die, die durch die Prüfung rutschen, denn ein Policy-Audit, das ein Statement nach dem anderen betrachtet, sieht das Paar nie. Die Map kennzeichnet jeden Eintrag als direkt ausnutzbar oder als toxische Kombination, und Sie können auf nur die Kombinationen filtern.

Warum eine Liste von Berechtigungen nicht die ganze Geschichte ist

Eine Referenz wie diese sagt Ihnen, welche Berechtigungen gefährlich sein können. Sie kann Ihnen nicht sagen, welche in Ihrem Konto gefährlich sind. Das hängt davon ab, wer die Berechtigung tatsächlich hält, ob die Trust-Policies und Bedingungen zusammenpassen, ob ein SCP sie bereits blockiert und ob die Rolle, die sie erreicht, privilegiert ist. Dieselbe Berechtigung kann in einem Konto tragend und in einem anderen reines Risiko sein.

Deshalb geht die Map bewusst vorsichtig mit dem Fix um. Jede Seite zeigt das Control, das den Pfad entfernen würde, und sagt dann klar, dass die Entscheidung, es anzuwenden, eine Geschäftsentscheidung ist, keine automatische Änderung. Eine Berechtigung zu entziehen, von der eine Pipeline abhängt, ist eine eigene Art von Ausfall.

So nutzen Sie sie

Beginnen Sie bei einem Service, den Sie betreiben, und lesen Sie seine Einträge. Suchen Sie eine Berechtigung, die Sie gleich gewähren wollen, und sehen Sie, was sie öffnet. Geben Sie zwei Berechtigungen ein, um zu prüfen, ob sie zusammen einen Pfad bilden. Jede Seite verlinkt die Detection-Ereignisse, auf die Sie heute alerten können, und die MITRE-Technik für Ihr eigenes Mapping, sodass die Map nützlich ist, ob Sie härten, erkennen oder Threat Modelling betreiben.

Wie Pathbreak sie nutzt

Die Map ist die öffentliche Version dessen, worüber Pathbreak innerhalb Ihres Kontos schlussfolgert. Wir verbinden uns read-only, lösen Ihre realen IAM-Policies, Rollen und Vertrauensbeziehungen auf und bestätigen, welche dieser Pfade für Ihre Identitäten tatsächlich existieren. Dann ordnen wir sie danach, wie viel jeder einzelne öffnet, und zeigen mit Ihrem Threat Model und Geschäftskontext, welche wenigen Änderungen am meisten durchtrennen. Die ersten validierten Pfade kommen innerhalb einer Stunde zurück.

Häufig gestellte Fragen

Was ist die gefährlichste AWS-IAM-Berechtigung?

iam:PassRole ist die am häufigsten wiederverwendete Berechtigung in Privilege-Escalation-Pfaden. Auf einer Wildcard-Ressource gewährt, erlaubt sie einem Principal, einem Service, den er ausführen kann, etwa Lambda oder EC2, eine privilegierte Rolle zu übergeben und diese Rolle zu erben. Sie ist in Kombination mit einer Service-Aktion gefährlich, nicht für sich allein, was ein Grund dafür ist, dass sie so oft zu weit gefasst bleibt. Die AWS Privilege Escalation Map von Pathbreak zeigt jede Kombination, die sie zu einem Pfad macht.

Was ist eine toxische Kombination von Berechtigungen?

Es ist eine Gruppe von zwei oder mehr Berechtigungen, die einzeln sicher sind, aber Eskalation gewähren, wenn ein Principal sie zusammen hält. iam:PassRole plus lambda:CreateFunction ist ein klassisches Beispiel. Prüfungen, die ein Policy-Statement nach dem anderen kontrollieren, übersehen diese, denn das Risiko liegt in der Paarung, nicht in einer der beiden Berechtigungen allein. Die Map von Pathbreak kennzeichnet diese als toxische Kombinationen.

Woher weiß ich, welche dieser Berechtigungen in meinem Konto tatsächlich gefährlich sind?

Sie validieren sie gegen Ihre reale Autorisierung. Eine Berechtigung bildet nur dann einen Pfad, wenn ein Principal sie tatsächlich hält, die Trust-Policies und Bedingungen es erlauben, kein Guardrail sie blockiert und die Rolle, die sie erreicht, privilegiert ist. Pathbreak löst dies read-only auf und meldet nur die Pfade, die sich auflösen, statt jeder Berechtigung, die theoretisch riskant sein könnte.

Sollte ich einfach jede Berechtigung auf der Map entfernen?

Nein. Viele dieser Berechtigungen leisten legitime Arbeit. Die Map zeigt das Control, das jeden Pfad entfernen würde, aber ob man es anwendet, ist eine Geschäftsentscheidung. Der richtige Ansatz ist, zu validieren, welche Pfade existieren, sie danach zu ordnen, wie viel sie öffnen, und die wenigen zu durchtrennen, die am wichtigsten sind, ohne das zu brechen, was von ihnen abhängt. Pathbreak validiert, welche davon in Ihren Konten einen echten Pfad bilden, damit Sie diese zuerst beheben.

Deckt die Map mehr als Privilege Escalation ab?

Ja. Neben Privilege Escalation deckt sie Credential Access ab, Defense Evasion gegen Ihr eigenes Logging und Ihre Guardrails, Ressourcenoffenlegung gegenüber externen oder öffentlichen Principals, Datenzugriff und Persistenz, denn echte Angriffspfade überqueren diese Kategorien auf dem Weg zur Wirkung. Pathbreak pflegt die Map und validiert dieselben Techniken in seiner Plattform.