iam:PassRole: wie es funktioniert, wie Angreifer es missbrauchen und wie Sie es eingrenzen

Ian Austin · 3. November 2026 · 12 Min. Lesezeit

iam:PassRole ist die AWS-IAM-Berechtigung, die steuert, welche Rollen ein Principal einem AWS-Service übergeben kann, etwa die Ausführungsrolle einer Lambda-Funktion, das Instanzprofil einer EC2-Instanz oder die Service-Rolle eines CodeBuild-Projekts. Sie ist auch die Berechtigung, die in der Pathbreak Attack Map am häufigsten vorkommt: 55 Prozent der Privilege-Escalation-Pfade in der Map beruhen auf ihr, und diese Pfade erreichen 23 AWS-Services, weil jeder Service, der Workloads in Ihrem Auftrag ausführt, eine Rolle akzeptiert, die Sie ihm übergeben. Sie wird leicht zu weit gefasst vergeben, denn eine Wildcard-Ressource wirkt in einem Policy-Review harmlos, und die Übergabe selbst erscheint nie in CloudTrail. Dieser Beitrag erklärt, was die Berechtigung bewirkt, welche Prüfungen AWS vornimmt, wie ein Angreifer sie nutzt, was die Logs zeigen und wie Sie sie so eingrenzen, dass der Pfad geschlossen ist.

Was iam:PassRole ist

Viele AWS-Services handeln mit einer IAM-Rolle, die Sie ihnen beim Konfigurieren einer Ressource mitgeben. Eine Lambda-Funktion läuft unter ihrer Ausführungsrolle, eine EC2-Instanz erhält Zugangsdaten aus ihrem Instanzprofil, und ein CodeBuild-Projekt ruft AWS mit seiner Service-Rolle auf. Diese Rolle an den Service zu geben, nennt man Übergabe der Rolle, und AWS prüft, ob der Aufrufer das darf.

Diese Prüfung ist iam:PassRole. Die AWS-Dokumentation stellt ausdrücklich klar, dass PassRole eine Berechtigung ist und keinen API-Aufruf hat, daher gibt es im SDK keine PassRole-Operation. Der Rollen-ARN wird als Parameter eines anderen Aufrufs mitgegeben, etwa als Role-Parameter von Lambda CreateFunction, und der Service prüft die iam:PassRole-Berechtigung des Aufrufers, während er diesen Aufruf verarbeitet.

Die Berechtigung soll verhindern, dass ein Principal einem Service mehr Zugriff gibt, als er selbst hat. Könnte ein Entwickler ohne Amazon-S3-Berechtigungen eine Rolle übergeben, die S3 erlaubt, würde der Service diese S3-Aktionen in seinem Auftrag ausführen, und genau vor dieser Eskalation warnt AWS auf derselben Seite.

Die drei Prüfungen, die AWS bei einer Rollenübergabe vornimmt

Der Beitrag zu PassRole im AWS Security Blog nennt drei Bedingungen, die alle erfüllt sein müssen, bevor ein Service eine übergebene Rolle nutzen kann.

1. Der Aufrufer darf diese Rolle übergeben. Eine identitätsbasierte Policy des Aufrufers muss iam:PassRole mit der Rolle im Resource-Element erlauben, jede Bedingung in diesem Statement muss erfüllt sein, und nichts anderes darf die Übergabe verweigern, einschließlich Service Control Policies, Permissions Boundaries, Session Policies und VPC-Endpoint-Policies.
2. Die Rolle vertraut dem Ziel-Service. Die Trust Policy der Rolle muss den Service-Principal erlauben, zum Beispiel lambda.amazonaws.com für eine Lambda-Ausführungsrolle. AWS weist darauf hin, dass die Ressource in manchen Fällen trotzdem erstellt wird, wenn das Vertrauen fehlt, der Service die Rolle dann aber nicht nutzen kann.
3. Rolle und Aufrufer liegen im selben Konto. Laut IAM User Guide übergibt iam:PassRole eine Rolle nur an einen Service im selben AWS-Konto, daher braucht ein kontoübergreifendes Design eine Rolle im zweiten Konto, die die erste übernehmen kann.

Für einen Angreifer legt die zweite Bedingung die Zielliste fest. Jede Rolle im Konto, deren Trust Policy einen Service nennt, in dem der Angreifer Ressourcen erstellen kann, ist ein Kandidat, und die erste Bedingung entscheidet, ob der Angreifer sie nutzen darf.

Wo die PassRole-Prüfung stattfindet

Die Prüfung läuft immer dann, wenn eine Ressource mit einer Service-Rolle erstellt wird, und immer dann, wenn eine bestehende Ressource mit einer neuen Rolle aktualisiert wird. Die Ausführungsrolle einer Lambda-Funktion zu ändern, ist ein solches Update und erfordert daher dieselbe Berechtigung wie das Erstellen der Funktion.

Services, die Service-Linked Roles verwenden, erstellen und verwalten diese Rollen in der Regel selbst, sodass keine Übergabe stattfindet. Wo ein Service Sie eine Service-Linked Role auswählen lässt, etwa bei einer Amazon-EC2-Auto-Scaling-Gruppe, die mit einer namentlich angegebenen Rolle erstellt wird, prüft AWS iam:PassRole auf dieselbe Weise.

Die Tabelle listet einige gängige Aufrufe auf, die eine Rolle übergeben, und den Request-Parameter, der sie trägt. Genau diesen Parameter muss eine Erkennungsregel auslesen.

Die Map listet jede Übergabe auf, die Pathbreak erfasst, darunter Glue-Jobs, SageMaker-Trainingsjobs, ECS-Tasks, Step Functions und Bedrock AgentCore, und die Attack Map lässt sich nach iam:PassRole filtern, um sie zusammen zu sehen.

Wie Angreifer iam:PassRole missbrauchen

Der Missbrauch folgt denselben drei Schritten, egal welcher Service beteiligt ist.

Eine privilegierte Rolle finden, die einem Service vertraut. iam:ListRoles liefert die Trust Policy jeder Rolle im Feld AssumeRolePolicyDocument, sodass ein einziger Aufruf zeigt, welche Rollen Lambda, EC2, CodeBuild oder einem anderen Service vertrauen. Der Angreifer sucht eine Rolle mit weitreichenden Berechtigungen, deren Trust Policy einen Service nennt, in dem er Ressourcen erstellen kann.

Eine Ressource mit dieser Rolle erstellen. Mit iam:PassRole auf die Rolle und lambda:CreateFunction erstellt der Angreifer eine Funktion, deren Ausführungsrolle die privilegierte Rolle ist. AWS akzeptiert die Übergabe, weil die Policy des Aufrufers sie erlaubt und die Rolle lambda.amazonaws.com vertraut.

Code als die Rolle ausführen. Der Angreifer ruft die Funktion auf, und der Code, den er geschrieben hat, läuft mit den Berechtigungen der privilegierten Rolle. Ist die Rolle ein Administrator, gehört ihm das Konto nach einem einzigen Create und einem einzigen Invoke. Derselbe Zug funktioniert über EC2-User-Data, eine CodeBuild-Buildspec, ein CloudFormation-Template oder ein Glue-Job-Skript, weshalb eine einzige zu weit gefasste iam:PassRole-Berechtigung viele Pfade auf einmal öffnen kann.

Die Lambda-Variante dieser Kette, mit den CloudTrail-Events für jeden Schritt, behandelt der Beitrag Drei AWS-Privilege-Escalation-Angriffe, mit den CloudTrail-Belegen und dem Fix.

Warum iam:PassedToService allein nicht ausreicht

iam:PassedToService ist ein Condition Key, der begrenzt, an welchen Service eine Rolle übergeben werden darf. Er ist nützlich, und die Policy-Validierung von AWS selbst gibt für iam:PassRole mit einer Wildcard-Ressource eine Sicherheitswarnung aus und empfiehlt entweder konkrete Rollen-ARNs oder diese Bedingung. Die beiden Optionen sind allerdings alles andere als gleichwertig, denn die Bedingung grenzt den Service ein, während die Wildcard weiterhin jede Rolle im Konto abdeckt.

Die AWS Managed Policy AWSLambda_FullAccess zeigt die Lücke deutlich. Sie gewährt lambda:*, iam:ListRoles und iam:GetRole und erlaubt iam:PassRole auf "Resource": "*", mit iam:PassedToService gesetzt auf lambda.amazonaws.com. Ein Principal mit dieser Policy kann die Rollen im Konto auflisten, jede Rolle finden, deren Trust Policy Lambda erlaubt, damit eine Funktion erstellen und sie aufrufen. Vertraut eine privilegierte Rolle im Konto Lambda, hält die Bedingung die Eskalation nicht auf, denn die Übergabe geht tatsächlich an Lambda.

Ihren Nutzen entfaltet die Bedingung in Kombination mit einer konkreten Ressource. Ein konkreter Rollen-ARN legt fest, welche Rolle übergeben werden kann, und iam:PassedToService legt fest, an welchen Service sie übergeben werden kann, was wichtig ist, wenn eine Rolle mehr als einem Service vertraut.

So erkennen Sie iam:PassRole-Missbrauch in CloudTrail

AWS stellt fest, dass für PassRole keine CloudTrail-Logs erzeugt werden, daher ist der Beleg immer der Create- oder Update-Aufruf, der die Rolle erhalten hat.

• Den Parameter beobachten. Bei Lambda ist das das CreateFunction-Management-Event mit dem Rollen-ARN in den Request-Parametern. Die CloudTrail-Referenz für Lambda zeigt den Event-Namen als CreateFunction20150331, daher sollte eine Regel auf das Präfix des Event-Namens prüfen. Dieselbe Referenz weist darauf hin, dass die Parameter Environment und ZipFile nicht im Log erscheinen, sodass der Code, den der Angreifer hochgeladen hat, nicht im Event steht.
• Rolle und Aufrufer vergleichen. Das starke Signal ist ein Create-Aufruf, der eine Rolle mit mehr Berechtigungen anhängt, als der aufrufende Principal selbst hat, besonders von einem Principal, der diesen Ressourcentyp bisher nie erstellt hat.
• Die Folge-Events aktivieren. Lambda Invoke ist ein Data-Event, und CloudTrail protokolliert es standardmäßig nicht, wie AWS bestätigt. Mit aktivierten Lambda-Data-Events kann eine Regel den Create-Aufruf mit einem Invoke wenige Minuten später paaren.
• Die Fehlschläge lesen. CloudTrail zeichnet fehlgeschlagene Aufrufe mit Fehlercode und Fehlermeldung auf. Wird eine Übergabe abgelehnt, nennt der Fehler, den AWS zurückgibt, iam:PassRole und den Rollen-ARN, wie die Hinweise zur Fehlerbehebung von AWS zeigen. Eine Serie abgelehnter Create-Aufrufe, die jeweils eine andere Rolle nennen, ist genau das Bild eines Angreifers, der testet, welche Rollen er übergeben kann.

Nach einer erfolgreichen Übergabe bleibt als letzte Stelle die Aktivität der Rolle selbst. API-Aufrufe, die als übergebene Rolle aus einer Funktion oder Instanz kommen, die eine Stunde zuvor noch nicht existierte, verdienen einen genaueren Blick.

So grenzen Sie iam:PassRole ein

Ziel ist, dass jeder Principal nur die Rollen übergeben kann, die seine Aufgabe erfordert, und nur an die Services, die sie nutzen.

• Die Rollen benennen. Tragen Sie konkrete Rollen-ARNs in das Resource-Element ein. Wo häufig Rollen erstellt werden, verwenden Sie einen IAM-Pfad wie arn:aws:iam::111122223333:role/application_role/* oder ein Namenspräfix, damit neue Rollen in diesem Pfad ohne Policy-Änderung abgedeckt sind, wie es der AWS Security Blog empfiehlt.
• iam:PassedToService ergänzen. Nutzen Sie den Condition Key zusammen mit einer konkreten Ressource, damit eine Rolle, die mehreren Services vertraut, nur an den Service übergeben werden kann, den der Workload nutzt.
• iam:AssociatedResourceArn nutzen, wo es passt. Dieser Condition Key begrenzt, an welche Ressource eine Rolle angehängt werden kann. Weil sich manche Ressourcen-ARNs ändern, wenn eine Ressource neu erstellt wird, schränken laut AWS viele Organisationen stattdessen ein, wer die Ressource ändern darf.
• Tag-basierte Kontrolle vermeiden. AWS warnt, dass ResourceTag-Bedingungen auf iam:PassRole keine verlässlichen Ergebnisse liefern, daher sind Tags auf der Rolle die falsche Kontrolle für diese Berechtigung.
• Privilegierte Pfade mit einer SCP schützen. Eine Service Control Policy kann iam:PassRole auf einen geschützten Pfad verweigern, etwa auf die Rollen eines Security-Teams, sofern der Aufrufer nicht ein bestimmtes Tag trägt oder in einem freigegebenen Pfad liegt.
• Von Entwicklern erstellte Rollen begrenzen. Wenn Entwickler eigene Rollen erstellen können, verlangen Sie für diese Rollen eine Permissions Boundary und erlauben Sie den Entwicklern, nur Rollen in einem eigenen Pfad zu übergeben, damit eine Rolle, die sie erstellen und dann übergeben, die Boundary nicht überschreiten kann.

Jede dieser Änderungen erhält die Fähigkeit, auf die sich das Team verlässt, und schließt die Pfade, die über Rollen laufen, die es nie übergeben musste.

Was das Eingrenzen von PassRole nicht behebt

Das Eingrenzen von iam:PassRole schließt die Pfade, die mit einer neuen Ressource beginnen. Für Ressourcen, an die bereits eine privilegierte Rolle angehängt ist, bewirkt es nichts, denn wer ändert, was diese Ressourcen ausführen, übergibt dabei nie eine Rolle. Diese Pfade brauchen eigene Kontrollen auf den Änderungsberechtigungen.

• Lambda-Funktionscode. lambda:UpdateFunctionCode ersetzt den Code einer bestehenden Funktion und lässt deren Ausführungsrolle unverändert, sodass der Code des Angreifers beim nächsten Aufruf der Funktion unter dieser Rolle läuft.
• EC2-User-Data. Mit ec2:StopInstances, ec2:ModifyInstanceAttribute und ec2:StartInstances stoppt ein Angreifer eine Instanz, schreibt ihre User-Data um und startet sie wieder. User-Data läuft standardmäßig nur beim ersten Boot, daher liefert der Angreifer eine cloud-init-Konfiguration, die bei jedem Boot läuft, und das Skript läuft unter dem bestehenden Profil der Instanz.
• SSM-Befehle. ssm:SendCommand führt ein Skript auf einer verwalteten Instanz aus, das die Zugangsdaten der bereits angehängten Rolle lesen kann.
• CloudFormation-Stack-Rollen. AWS weist darauf hin, dass Benutzer, die Operationen auf einem Stack ausführen dürfen, eine einmal an den Stack angehängte Service-Rolle nutzen können, ob sie iam:PassRole haben oder nicht, sodass ein Principal, der den Stack aktualisieren oder ein Change Set ausführen kann, die Rolle erbt. Die Variante UpdateStack funktioniert genauso.
• CodeBuild-Projekte. Ein Build eines bestehenden Projekts, gestartet mit einer überschriebenen Buildspec, führt die Befehle des Angreifers unter der Service-Rolle des Projekts aus.

Ein Konto-Review, das bei iam:PassRole stehen bleibt, übersieht all diese Pfade, weshalb die Map sie als eigene Einträge führt.

So prüfen Sie, wer eine privilegierte Rolle übergeben kann

Für einen Principal und eine Rolle liefert der IAM Policy Simulator eine schnelle Antwort. Er wertet identitätsbasierte Policies und Service Control Policies einschließlich Bedingungen für den Principal aus, den Sie angeben.

Verwendet die Policy des Principals iam:PassedToService, ergänzen Sie ein Argument --context-entries, das den Key iam:PassedToService auf den Ziel-Service setzt, etwa lambda.amazonaws.com, denn ohne dieses Argument hat der Simulator keinen Wert für den Vergleich. Das Ergebnis beantwortet nur die erste der drei Prüfungen. Ob die Trust Policy der Rolle den Service erlaubt, ist eine eigene Frage, die das AssumeRolePolicyDocument der Rolle beantwortet, und der Aufrufer braucht weiterhin die Create-Berechtigung für diesen Service. AWS weist außerdem darauf hin, dass die Ergebnisse des Simulators von der Live-Umgebung abweichen können.

Für ein einzelnes Paar ist das machbar, über ein Konto mit Hunderten von Principals und Rollen hinweg nicht praktikabel. Das kostenlose Open-Source-Tool pathbreak-audit liest die IAM-Konfiguration eines Kontos und listet als Ausgangspunkt die Rollen und Benutzer auf, die ausnutzbare Berechtigungen und Kombinationen wie iam:PassRole mit einer Create-Aktion besitzen, jeweils mit dem Fix. Pathbreak geht weiter und löst jede Übergabe gegen die Policies des Aufrufers, Boundaries, SCPs und die Trust Policy der Rolle auf, sodass nur die Pfade gemeldet werden, die tatsächlich gelingen würden, sortiert danach, was die übergebene Rolle erreichen kann.

Häufig gestellte Fragen