Adversarial Exposure Validation für AWS

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

Adversarial Exposure Validation, meist zu AEV abgekürzt, bezeichnet die Praxis, Exposures so zu testen, wie ein Angreifer es tun würde, damit das Security-Team weiß, welche Findings sich nutzen lassen und welche nicht. Gartner verwendet den Begriff für eine Tool-Kategorie, die aus Breach and Attack Simulation und automatisierten Penetrationstests hervorgegangen ist. Der gemeinsame Gedanke ist, dass die Validierung das, was ein Scanner meldet, um Beweise ergänzt, damit das Team an den Findings arbeiten kann, die nachweislich funktionieren.

In diesem Beitrag geht es darum, was das speziell in AWS bedeutet, denn die Control Plane der Cloud verändert sowohl die Methode als auch das Ergebnis.

Warum AWS eine eigene Art der Validierung braucht

In einem Netzwerk bedeutet die Validierung einer Exposure, Traffic zu senden: Erreicht das Tool den Host, kann es sich authentifizieren, kann es sich weiterbewegen. Der Beleg ist eine erfolgreiche Verbindung oder ein erbeutetes Credential. In der AWS Control Plane gibt es keine Hosts, die man erreichen könnte. Jeder Zug des Angreifers ist ein API-Aufruf, und ob ein Aufruf gelingt, entscheidet ein Satz von Policy-Dokumenten, die AWS gemeinsam auswertet: die Identity Policies des Aufrufers, eine etwaige Permission Boundary, die Service Control Policies auf der Organisationseinheit des Kontos, die Trust oder Resource Policy auf dem Ziel und die Condition Keys auf jedem Statement.

Das hat zwei Konsequenzen. Erstens lässt sich ein Pfad validieren, ohne ihn auszuführen, denn diese Dokumente schreibgeschützt aufzulösen ergibt dasselbe Allow oder Deny wie der Aufruf selbst. Zweitens überschätzt ein Tool, das nur Identity Policies liest, die Angriffsfläche, weil SCPs und Boundaries einen großen Teil dessen entfernen, was Identity Policies scheinbar gewähren.

Was in AWS validiert werden sollte

Vier Arten von Exposure machen den Großteil der bewiesenen Pfade aus, die wir in realen Konten sehen.

IAM Privilege Escalation. Ein Principal mit einer Berechtigung oder Kombination, die ihn eine höher privilegierte Rolle erreichen lässt: iam:PassRole zusammen mit einer Compute-Create-Aktion, das Anhängen von Policies und das Schreiben von Inline Policies, das Umschreiben von Trust Policies, das Erstellen von Access Keys. Die AWS Privilege Escalation Map führt sie mit dem CloudTrail-Event und der Änderung auf, die jede einzelne unterbricht.

Kontoübergreifendes Vertrauen. Rollen, die einem anderen Konto, einem Anbieter oder einem Wildcard vertrauen, wobei die vertrauende Seite privilegiert ist und die Seite, der vertraut wird, schwächer, als alle angenommen haben. Eine Kette aus zwei oder drei sts:AssumeRole-Hops kann eine Sandbox mit der Produktion verbinden.

In der Konfiguration offengelegte Credentials. Access Keys und Tokens in EC2 User Data, Lambda-Umgebungsvariablen, CloudFormation-Outputs und Container-Definitionen. Ein einziger offengelegter Schlüssel wird zum Einstiegspunkt für alles, was der Principal des Schlüssels erreichen kann.

Öffentliche Einstiegspunkte. Function URLs, öffentliche Buckets mit Schreibzugriff, aus dem Internet erreichbare Instanzen mit einem Instance Profile und API Gateways, die eine privilegierte Rolle aufrufen. Die Exposure ist nur dann ernst, wenn die Rolle dahinter irgendwohin führt, und genau das stellt die Validierung fest.

Was ein AEV-Tool für AWS leisten sollte

Den Graphen aus einer schreibgeschützten Verbindung aufbauen, sodass kein Agent ausgerollt und keine Schreibberechtigung vergeben werden muss. Über den Graphen Kandidatenketten ableiten, einschließlich Multi-Hop- und kontoübergreifender Ketten. Jede Kette validieren, indem für jeden Schritt jede Autorisierungsebene ausgewertet und das Ergebnis als Beleg festgehalten wird. Die bewiesenen Pfade danach sortieren, was sie erreichen, damit das Team zuerst den Blast Radius sieht. Für jeden Pfad die konkrete Änderung benennen, die ihn unterbricht, und nach dem Ausrollen der Änderung den Pfad erneut auswerten und bestätigen, dass er verschwunden ist. Nach Zeitplan laufen, weil Konten driften.

Zwei Dinge muss es nicht sein. Es muss nichts im Konto ausführen, um Beweise zu liefern, denn in der Control Plane ist der Beweis das Ergebnis der Autorisierung. Und es muss nicht das führende System für jedes Finding sein; das hält bereits ein CSPM oder CNAPP, und die Aufgabe des Validierungstools ist, Ihnen zu sagen, welche dieser Findings auf einem bewiesenen Pfad liegen.

Wie die wichtigsten AEV-Anbieter an AWS herangehen

Die mit der Kategorie verbundenen Anbieter sind von unterschiedlichen Ausgangspunkten dorthin gekommen, und jeder hat darauf aufgebaut. Die Übersicht unten beschreibt jeden in den Begriffen, die seine eigenen öffentlichen Materialien verwenden. Klären Sie die Details mit dem Anbieter, bevor Sie auf dieser Grundlage etwas entscheiden.

Die nützliche Unterscheidung ist die zwischen Beweis durch Emulation von Techniken und Beweis durch Auflösen der Autorisierung. Emulation passt dort, wo der Exploit Code gegen einen Host ist. Die Auflösung der Autorisierung greift dort, wo der Exploit eine Berechtigung ist, was in AWS den Großteil der Control Plane ausmacht, und weil sie schreibgeschützt ist, kann sie täglich nach Zeitplan laufen.

Wo AEV in einem CTEM-Programm steht

Continuous Threat Exposure Management hat fünf Stufen: Scoping, Discovery, Priorisierung, Validierung und Mobilisierung. AEV ist die Validierungsstufe. Ihre Eingabe ist die priorisierte Liste aus der Discovery, ihre Ausgabe die kleine Menge an Exposures, die bewiesen sind, jede mit einem Verantwortlichen und einer Änderung. Der Beitrag zur CTEM-Validierung zeigt mit realen Zahlen, wie das in einem AWS-Konto aussieht, und der Beitrag AEV vs. BAS behandelt den Unterschied zum Testen von Kontrollen.

Häufig gestellte Fragen