Drei AWS-Privilege-Escalation-Angriffe, mit den CloudTrail-Belegen und dem Fix

Vom Pathbreak-Team · 23. Oktober 2026 · 8 Min. Lesezeit

Ein Privilege-Escalation-Angriff in AWS ist eine Abfolge von API-Aufrufen, die einen Principal von den Berechtigungen, die er besitzt, zu Berechtigungen bringt, die ihm nie erteilt wurden. Einen Exploit im üblichen Sinn gibt es nicht. Die Aufrufe sind dieselben, die Administratoren jeden Tag tätigen, und genau das macht sie schwer zu bemerken und leicht offen zu lassen. Die AWS Privilege Escalation Map listet jede Berechtigung auf, die sich auf diese Weise nutzen lässt. Dieser Beitrag greift drei der häufigsten Ketten heraus und zeigt für jede, wie sie funktioniert, was CloudTrail aufzeichnet und welche Änderung sie unterbricht.

Kette eins: eine Rolle an Lambda übergeben

Berechtigungen. iam:PassRole auf eine privilegierte Rolle, zusammen mit lambda:CreateFunction. Meist auch lambda:InvokeFunction, wobei sich eine Funktion auch über eine Event-Quelle auslösen lässt.

So funktioniert es. Der Angreifer erstellt eine neue Lambda-Funktion und übergibt die privilegierte Rolle als deren Ausführungsrolle. AWS akzeptiert die Übergabe, weil die Trust Policy der Rolle lambda.amazonaws.com erlaubt. Anschließend ruft der Angreifer die Funktion auf, und der Code, den er geschrieben hat, läuft mit den Berechtigungen der privilegierten Rolle. Ist diese Rolle ein Administrator, gehört ihm das Konto nach einem Create und einem Invoke. Dasselbe Muster funktioniert mit EC2, ECS, Glue, CloudFormation, CodeBuild und jedem anderen Service, der eine übergebene Rolle akzeptiert.

Was CloudTrail zeigt. Ein CreateFunction-Management-Event von lambda.amazonaws.com, dessen requestParameters.role der ARN einer privilegierten Rolle ist. Die iam:PassRole-Prüfung erzeugt kein eigenes Event; die Übergabe ist in den Parametern des Create-Aufrufs sichtbar. Das anschließende Invoke ist ein Lambda-Data-Event und erscheint daher nur, wenn im Trail Lambda-Data-Events aktiviert sind, was standardmäßig nicht der Fall ist und sich genau aus diesem Grund lohnt. Sind beide vorhanden, liegt das Signal in der Paarung: Ein Principal, der noch nie eine Funktion erstellt hat, erstellt eine mit einer hochwertigen Rolle und ruft sie innerhalb von Minuten auf. Ohne Data-Events ist das Signal der Create-Aufruf selbst sowie die API-Aktivität, die die übergebene Rolle danach ausführt.

Der Fix. Grenzen Sie die Übergabe ein. Ergänzen Sie die iam:PassRole-Berechtigung um eine iam:PassedToService-Bedingung, damit die Rolle nur an den Service übergeben werden kann, der sie benötigt, und ersetzen Sie jedes Wildcard im Ressourcen-ARN durch die konkrete Rolle. Wenn der Principal gar keine Rollen übergeben muss, entfernen Sie die Berechtigung. Ausführliche Beschreibung: Rolle an Lambda übergeben.

Kette zwei: die Trust Policy einer Rolle umschreiben und sie dann übernehmen

Berechtigungen. iam:UpdateAssumeRolePolicy auf eine privilegierte Rolle, dazu sts:AssumeRole.

So funktioniert es. Die Trust Policy einer Rolle legt fest, wer sie übernehmen darf. Ein Principal, der dieses Dokument umschreiben kann, trägt sich selbst als vertrauenswürdigen Principal ein, ruft dann sts:AssumeRole auf und erhält temporäre Zugangsdaten für die Rolle. Die ursprüngliche Vertrauensbeziehung spielt keine Rolle mehr, sobald sie überschrieben ist, daher übernimmt dieser Schritt jede Rolle im Konto, die der Principal mit dem Update-Aufruf erreichen kann. Die umgeschriebene Trust Policy bleibt bestehen, bis es jemandem auffällt, was diesen Schritt zugleich zu einer Eskalation und zu einem Persistenzmechanismus macht.

Was CloudTrail zeigt. Ein UpdateAssumeRolePolicy-Event von iam.amazonaws.com mit dem neuen Policy-Dokument in requestParameters.policyDocument, gefolgt von einem AssumeRole-Event von sts.amazonaws.com für dieselbe Rolle, ausgelöst von dem gerade hinzugefügten Principal. In einem gesunden Konto ändern sich Trust Policies selten, daher lohnt sich bei jedem UpdateAssumeRolePolicy-Event außerhalb einer Deployment-Pipeline ein Blick, und eines, das einen Principal aus dem eigenen Konto hinzufügt, ist ein starkes Signal.

Der Fix. Entfernen Sie iam:UpdateAssumeRolePolicy von jedem Principal, der nicht zum IAM-Administrationspfad gehört, und setzen Sie für die privilegierten Rollen im Konto ein explizites Deny darauf, mit der Deployment-Rolle als einziger Ausnahme. Ausführliche Beschreibung: Rollenvertrauen umschreiben, dann übernehmen.

Kette drei: einen Access Key für einen anderen Benutzer erstellen

Berechtigungen. iam:CreateAccessKey auf einen anderen Benutzer als den Aufrufer.

So funktioniert es. Der Angreifer ruft iam:CreateAccessKey mit dem Namen eines anderen Benutzers auf und erhält einen brandneuen, langlebigen Access Key für diesen Benutzer. Er braucht weder dessen Passwort noch dessen vorhandene Keys. Von da an kann er die API als dieser Benutzer aufrufen, und der neue Key übersteht ein Zurücksetzen des Passworts ebenso wie eine Rotation des anderen Keys des Benutzers. Diese Kette ist von den dreien am schwersten zu bemerken, weil ein einziger Aufruf dauerhafte Zugangsdaten erzeugt und der Benutzer, dessen Identität übernommen wurde, nichts davon sieht.

Was CloudTrail zeigt. Ein CreateAccessKey-Event von iam.amazonaws.com, bei dem requestParameters.userName von der Identität in userIdentity abweicht. Diese Abweichung ist das Signal. Dass Benutzer Keys für sich selbst erstellen, ist normal. Dass ein Principal Keys für einen anderen erstellt, ist außerhalb eines Onboarding-Skripts selten, und die Rolle des Skripts lässt sich leicht auf eine Allowlist setzen. Die anschließende Nutzung zeigt sich als API-Aufrufe des betroffenen Benutzers von einer neuen Quell-IP und mit einem neuen User-Agent.

Der Fix. Entfernen Sie iam:CreateAccessKey von jedem Principal, der nicht zum Identitätsadministrationspfad gehört, und dort, wo Benutzer ihre eigenen Keys verwalten müssen, grenzen Sie die Berechtigung auf ${aws:username} ein, damit ein Benutzer nur Keys für sich selbst erstellen kann. Ausführliche Beschreibung: Access Key für Benutzer erstellen.

So erkennen Sie Privilege Escalation in AWS

Die drei Ketten oben teilen ein Muster, das sich verallgemeinern lässt. Privilege Escalation hinterlässt gewöhnliche Events mit ungewöhnlichen Parametern, ausgelöst von Principals, die so etwas noch nie getan haben. Die Erkennung in CloudTrail beruht auf vier Dingen.

Erstens muss CloudTrail in jedem Konto und jeder Region aktiv sein, und der Trail muss in ein zentrales Konto geliefert werden, in das die Workloads nicht schreiben können. Ein Angreifer, der den Trail deaktivieren oder löschen kann, beseitigt die Beweise, und StopLogging sowie DeleteTrail gehören auf dieselbe Beobachtungsliste wie die Eskalations-Events.

Zweitens: Achten Sie auf die Parameter und nicht nur auf die Event-Namen. CreateFunction allein ist Routine, während CreateFunction mit einer Administratorrolle in den Parametern einen Alarm verdient. Dasselbe gilt für CreateAccessKey, wenn der Zielbenutzer vom Aufrufer abweicht.

Drittens: Bilden Sie eine Baseline pro Principal. Eine CI-Rolle, die jede Stunde eine Funktion erstellt, und ein Entwickler, der in einem Jahr nie IAM aufgerufen hat, sind verschiedene Quellen, und dasselbe Event bedeutet bei jedem von beiden etwas anderes.

Viertens: Paaren Sie die Events. Eskalation ist eine Abfolge: erstellen und dann aufrufen, Vertrauen ändern und dann übernehmen, Key erstellen und ihn dann von einem neuen Ort aus nutzen. Eine Regel, die das erste Event innerhalb eines kurzen Zeitfensters mit dem zweiten verknüpft, erzeugt weit weniger Fehlalarme als jedes Event für sich. Aktivitäten in Lambda, S3 und DynamoDB sind Data-Events und müssen im Trail aktiviert werden, bevor sie sich paaren lassen.

Erkennung ist die zweite Verteidigungslinie

CloudTrail informiert Sie, nachdem der Aufruf getätigt wurde. Die erste Linie besteht darin, vor jedem Aufruf zu wissen, welche Principals ihn tätigen könnten. Das heißt, jede Kette auf der Map gegen die reale Autorisierung im Konto aufzulösen: Identity Policies, Boundaries, SCPs, Trust Policies und Bedingungen. Eine Kette, die sich für einen Principal zu Allow auflöst, ist ein bewiesener Pfad, und der Fix ist die oben beschriebene Änderung, angewendet, bevor es jemand versucht. Pathbreak führt diese Auflösung read-only über alle Konten hinweg durch, ordnet die bewiesenen Pfade danach, was sie erreichen, und bestätigt jeden Fix, nachdem er ausgerollt ist. Das kostenlose Tool pathbreak-audit listet als Ausgangspunkt auf, welche Principals in einem einzelnen Konto diese Berechtigungen besitzen.

Häufig gestellte Fragen