Cloud-Penetrationstests: Unsere Methodik für AWS, Azure und GCP

Geben Sie uns eine schreibgeschützte IAM-Rolle, die jemand zu großzügig ausgestattet hat, und die Chancen stehen gut, dass wir sie noch vor dem Ende Ihres Standups zur vollen Kontrolle über das Konto ausbauen. Der Cloud-Anbieter ist dabei nicht kaputt. Irgendjemand hat eine Policy mit einer Wildcard-Aktion angehängt, eine Rolle vom halben Internet annehmbar gelassen und irgendwann im letzten Quartal aufgehört, CloudTrail zu lesen. Die gesamte Methodik für Cloud-Penetrationstests in diesem Artikel spielt sich in genau dieser Lücke ab – jener zwischen “die Plattform ist sicher” und “unsere Konfiguration ist sicher.”

Was folgt, ist die Reihenfolge, die wir bei AWS-, Azure- und GCP-Projekten tatsächlich durchlaufen. Es ist keine als Fließtext umformatierte Compliance-Checkliste, sondern die Reihenfolge, in der wir testen, das Werkzeug, zu dem wir greifen, und die Fehlkonfigurationen, die sich Projekt für Projekt immer wieder auszahlen.

Eine Einordnung vorweg. Cloud-Tests sind zuerst ein Problem des Berechtigungsmodells und erst danach ein Netzwerkproblem. On-Prem kämpfen Sie gegen Firewalls und Segmentierung. Hier kämpfen Sie gegen IAM-Policies, Trust-Beziehungen und Metadata-Endpunkte. Ziehen Sie den Test wie einen klassischen externen Netzwerktest auf, dann segeln Sie schnurstracks an genau den Dingen vorbei, über die Konten tatsächlich übernommen werden.

Das Wichtigste in Kürze

• Eine Methodik für Cloud-Penetrationstests ist identitätszentriert: IAM-Policies und Trust-Beziehungen sind die primäre Angriffsfläche, weit vor allem auf der Netzwerkebene.
• Vier Befunde dominieren unsere Berichte: zu weit gefasste IAM-Policies, öffentlich zugänglicher Speicher (S3, Blob, GCS), SSRF, das den Instance-Metadata-Dienst erreicht, und Rechteausweitung über fehlkonfigurierte Policies oder Rollen.
• Scope und schriftliche Autorisierung wiegen hier schwerer als bei jedem anderen Test. Sie bewegen sich innerhalb der Grenze des Modells der geteilten Verantwortung, also brauchen Sie sowohl die Regeln des Anbieters als auch die Freigabe des Kontoinhabers, bevor Sie irgendetwas anfassen.
• IMDSv2, Least-Privilege-Policies, gesperrter öffentlicher Zugriff auf Speicher und überwachtes Logging (CloudTrail, Azure Monitor, Cloud Logging) schließen die meisten unserer Funde.
• CSPM-Scanner melden Fehlkonfigurationen einzeln. Sie verketten nicht drei davon zu einer Kontoübernahme. Genau diese Verkettung ist der ganze Sinn eines manuellen Tests.

Was ist ein Cloud-Penetrationstest, und was macht ihn anders?

Ein Cloud-Penetrationstest ist eine autorisierte Angriffssimulation gegen die Cloud-Umgebung, die Ihnen gehört: die Konten, Identitäten, Dienste und Konfigurationen innerhalb von AWS, Azure oder GCP. Der Anbieter sichert Hardware, Hypervisor und physische Ebene. Alles, was Sie darüber konfigurieren, gehört Ihnen: IAM, Speicherberechtigungen, Netzwerk-Sicherheitsgruppen, Schlüsselverwaltung, Logging. Diese Aufteilung ist das Modell der geteilten Verantwortung, und sie zieht die Grenze darum, was wir testen dürfen.

Der praktische Unterschied zu einem klassischen Pentest besteht darin, dass der Perimeter weich und die Identitätsebene riesig ist. Ein einziger geleakter Access Key, ein schlampiger OIDC-Trust für eine CI-Pipeline oder eine Lambda mit angehängter Admin-Rolle kann weit schwerer wiegen als jeder offene Port. Deshalb baut die Methodik auf Identität, Trust und Konfiguration auf und nicht auf dem Scannen eines CIDR-Bereichs.

Schritt 1: Scope, Autorisierung und Rules of Engagement

Bevor auch nur ein einziger Befehl läuft, legen wir drei Dinge fest. Welche Konten und Subscriptions im Scope sind. Um welche Art von Test es sich handelt – extern ohne Zugangsdaten oder authentifiziert als “Assumed Breach”, ausgehend von einer Identität mit geringen Rechten. Und was der Anbieter tatsächlich erlaubt. AWS, Azure und GCP veröffentlichen jeweils Nutzungsbedingungen für Sicherheitstests. Die meisten gängigen Dienste brauchen keine Vorabgenehmigung mehr, doch Denial-of-Service-Tests, dauerhaft hohe Last und bestimmte Managed Services unterliegen weiterhin Grenzen. Wir bleiben innerhalb dieser Grenzen.

Die nützlichsten Cloud-Tests, die wir durchführen, sind authentifiziert. Wir bitten um eine absichtlich schwache Identität: einen schreibgeschützten IAM-Benutzer, ein einfaches Entra-ID-Konto, ein GCP-Servicekonto mit minimalen Rollen. Dann sehen wir, wie weit man damit kommt. Das bildet die realistische Bedrohung ab – einen Mitarbeiter, der auf Phishing hereinfällt, einen in einem öffentlichen Repo geleakten Schlüssel oder eine kompromittierte Drittanbieter-Integration, nicht einen gesichtslosen Angreifer, der bei null anfängt. Externe, nicht authentifizierte Arbeit hat ihren Platz beim Kartieren der Angriffsfläche. Die interessante Eskalation spielt sich fast immer nach diesem ersten Zugang ab.

Schritt 2: Identitäten enumerieren, denn dort liegt die eigentliche Angriffsfläche

Mit einem ersten Zugang in der Hand besteht die erste Aufgabe darin, zwei Fragen zu beantworten: Wer sind wir, und was können wir werden? Auf AWS beginnt das ganz schlicht.

aws sts get-caller-identity
aws iam get-account-authorization-details   # if permitted
aws iam list-attached-user-policies --user-name svc-ci

Dann kartieren wir den Identitätsgraphen. Pacu und ScoutSuite verschaffen uns breite Abdeckung auf AWS, und PMapper verwandelt einen Haufen JSON-Policies in eine klare Antwort darauf, welcher Principal Admin-Rechte erreichen kann. Auf Azure setzen wir auf AzureHound und das weitere BloodHound-Ökosystem, um Verzeichnisrollen, verschachtelte Gruppen und berechtigte PIM-Zuweisungen zu graphen. Auf GCP gehen wir die Ressourcenhierarchie von Hand durch und lesen Role Bindings auf Organisations-, Ordner-, Projekt- und Ressourcenebene, weil eine von einer übergeordneten Ebene geerbte Bindung mit bloßem Auge kinderleicht zu übersehen ist.

Wonach wir in dieser Phase jagen: Wildcard-Aktionen wie "Action": "*" oder ein dienstweites iam:*, Rollen mit freizügigen sts:AssumeRole-Trust-Policies und jeder Pfad, über den sich eine schwache Identität selbst mehr Rechte verschaffen kann. Eine Policy, die iam:PassRole neben einer Berechtigung zum Erstellen von Compute-Ressourcen erlaubt, ist keine theoretische Sorge. Sie ist ein funktionierendes Eskalations-Primitiv.

Schritt 3: IAM-Rechteausweitung

Hier werden Cloud-Projekte gewonnen oder verloren. Die AWS-Eskalationspfade, die Rhino Security Labs vor Jahren dokumentiert hat, greifen noch immer in produktiven Konten, weil Teams weiterhin die einzelnen Zutaten-Berechtigungen vergeben, ohne zu bemerken, was sie in Summe ergeben. Ein paar, die wir jedes einzelne Mal prüfen:

• iam:PassRole plus Compute-Erstellung. Wenn wir eine Admin-Rolle an eine frische EC2-Instanz, eine Lambda-Funktion oder einen Glue-Job übergeben können, führen wir unter dieser Rolle unseren eigenen Code aus und lesen deren Zugangsdaten. Sofortige Eskalation.
• iam:CreatePolicyVersion oder AttachUserPolicy. Wenn unser Benutzer Policies bearbeiten oder anhängen kann, kann er sich selbst AdministratorAccess anhängen. Game over.
• Annehmbare Rollen mit lockerem Trust. Eine Rolle, die "Principal": {"AWS": "*"} oder einem weit gefassten Account-Root vertraut, ist eine offen stehen gelassene Tür.

Die Pendants auf Azure und GCP sind mindestens ebenso ergiebig. Auf Azure suchen wir nach benutzerdefinierten Rollen mit Microsoft.Authorization/roleAssignments/write, nach Service Principals mit übermäßigen Graph-Berechtigungen und nach Automation-Account-Runbooks oder Managed Identities, die wir kapern können. Auf GCP sind die verlässlichen Primitive iam.serviceAccounts.getAccessToken (ein Token für ein stärkeres Servicekonto erzeugen), iam.serviceAccountKeys.create und setIamPolicy auf Projektebene. Jedes Einzelne davon verwandelt einen bescheidenen Zugang in die Kontrolle über das gesamte Projekt.

Schritt 4: SSRF zum Instance-Metadata-Dienst

Die wertvollste Kette beim Cloud-Testing ist eine Server-Side-Request-Forgery-Schwachstelle in einer Anwendung, die den Metadata-Endpunkt erreichen kann. Richten Sie dieses SSRF auf die Link-Local-Metadata-Adresse und versuchen Sie, die temporären Zugangsdaten der angehängten Rolle auszulesen.

http://169.254.169.254/latest/meta-data/iam/security-credentials/
# then, with the role name that comes back:
http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

Auf einem veralteten IMDSv1-Host, der eine AccessKeyId, einen SecretAccessKey und ein Session-Token zurückgibt, exportieren wir sie und nutzen sie direkt. Das ist das Muster hinter einem der am gründlichsten untersuchten Cloud-Vorfälle überhaupt und der Grund, warum wir so nachdrücklich auf IMDSv2 drängen. Die entsprechenden Endpunkte gibt es auch anderswo: Azure unter 169.254.169.254/metadata/identity/oauth2/token mit einem Metadata: true-Header und GCP unter metadata.google.internal mit Metadata-Flavor: Google. Danach kartieren wir, wie weit diese Identität reicht. Diese Technik lässt sich sauber MITRE ATT&CK T1552.005 zuordnen, ungesicherte Zugangsdaten aus der Cloud-Instance-Metadata-API.

Schritt 5: Offener Speicher und öffentliche Daten

Öffentlich lesbarer Objektspeicher zählt noch immer zu den häufigsten schwerwiegenden Befunden, die wir dokumentieren. Wir enumerieren S3-Buckets, Azure-Blob-Container und GCS-Buckets, die mit dem Ziel verknüpft sind, lesen ihre ACLs und Bucket-Policies und testen auf öffentlichen List- und Lesezugriff. Dann testen wir auf öffentlichen Schreibzugriff – den, den alle vergessen. Öffentlicher Schreibzugriff auf einen Bucket, der Website-Assets oder Software-Updates ausliefert, ist kein Problem der Datenoffenlegung. Es ist ein Supply-Chain-Problem.

Speicher ist nur die halbe Miete. Wir durchkämmen auch offengelegte Secrets: Access Keys, die in öffentliche Repos committet wurden, Schlüssel, die in Mobile-App-Bundles eingebacken sind, Tokens im Frontend-JavaScript und zu freizügig lesbare Einträge im Secrets Manager oder Key Vault. Ein einziger gültiger, langlebiger Schlüssel kann den Verlauf des gesamten Projekts verändern.

Schritt 6: Netzwerk, Dienste und laterale Bewegung

Erst nach der Identität kümmern wir uns um das Netzwerk. Wir prüfen Security Groups und NSGs auf offene Ingress-Regeln, das übliche SSH und RDP offen gegenüber 0.0.0.0/0, Datenbanken, die am öffentlichen Internet hängen, und sehen uns dann öffentliche RDS- oder Managed-Database-Endpunkte an sowie das Verhalten der Segmentierung über VPCs, Subnetze und Peering hinweg. Von einer kompromittierten Identität oder einem kompromittierten Host aus testen wir Bewegung. Erreichen wir interne Dienste? Können wir Rollen in andere Konten annehmen? Von einer Dev-Subscription über eine gemeinsam genutzte Identität in die Produktion pivotieren? Trust-Grenzen über mehrere Konten und Subscriptions hinweg sind tendenziell weicher, als das Architekturdiagramm vermuten lässt.

Schritt 7: Hat uns jemand gesehen?

Hier ist ein Befund, der uns so viel bedeutet wie jeder Exploit: Hat die Umgebung es bemerkt? Wir vergewissern uns, dass CloudTrail in allen Regionen mit Log-File-Validation aktiv ist, dass Azure Monitor und Activity Logs sammeln und dass GCP Cloud Audit Logs aktiviert, zentralisiert sind und bei den soeben ausgeführten Aktionen Alarm schlagen. Ein Angreifer, der einen Access Key anlegt, das Logging deaktiviert und Daten exfiltriert, sollte irgendetwas auslösen. Bei etlichen Projekten schlägt gar nichts an. Das melden wir als Detection Gap, und wir beschönigen es nicht, denn Prävention versagt irgendwann, und Detection ist das Sicherheitsnetz.

Wie verhindert man das, was wir finden?

Least Privilege ist das ganze Spiel. Beschränken Sie IAM-Policies auf konkrete Aktionen und Ressourcen, löschen Sie die Wildcards und nutzen Sie Permission Boundaries und Service Control Policies, um zu deckeln, was eine Identität überhaupt erreichen kann. Erzwingen Sie IMDSv2 auf jeder Instanz, damit ein verirrtes SSRF keine Zugangsdaten erzeugen kann. Aktivieren Sie kontoweite Public-Access-Blocks für S3, halten Sie Blob und GCS standardmäßig privat und überprüfen Sie das, statt der Voreinstellung der Konsole zu vertrauen. Bevorzugen Sie kurzlebige föderierte Zugangsdaten gegenüber langlebigen Schlüsseln und rotieren Sie die Schlüssel, die sich wirklich nicht vermeiden lassen. Und machen Sie Logging ernst: zentralisiert, manipulationssicher und an Alarme angebunden, auf die ein Mensch oder ein SIEM reagiert. Ein Log, das niemand liest, ist Theater.

Wie CyberXplore hilft

Unser Service für Cloud-Penetrationstests fährt genau diese Methodik gegen Ihre AWS-, Azure- und GCP-Umgebungen. Identitätszentriert, manuell und darauf ausgerichtet, Fehlkonfigurationen zu der Wirkung zu verketten, die ein echter Angreifer erzielen würde, statt eine Liste von CSPM-Warnungen auszudrucken. Sie erhalten nach Ausnutzbarkeit priorisierte Befunde, Reproduktionsschritte, die Sie direkt an die Entwicklung geben können, und einen kostenlosen Retest, sobald Sie behoben haben. Wenn Sie einen gescopten Test Ihres Cloud-Footprints möchten, fordern Sie ein Angebot an, und wir richten das Projekt an Ihren Konten und den Rules of Engagement des Anbieters aus.

FAQ

Erlauben AWS, Azure und GCP Cloud-Penetrationstests?

Ja, innerhalb bestimmter Grenzen. Alle drei Anbieter erlauben das Testen Ihrer eigenen Ressourcen für die meisten gängigen Dienste ohne vorherige Genehmigung, und jeder schränkt Denial-of-Service-Tests und bestimmte Managed Services ein. Wir arbeiten innerhalb der aktuell veröffentlichten Nutzungsbedingungen des Anbieters für alles, was im Scope liegt, und verlangen vor Beginn eine schriftliche Autorisierung des Kontoinhabers.

Was ist der Unterschied zwischen einem CSPM-Scan und einem Cloud-Penetrationstest?

Ein Cloud-Security-Posture-Management-Tool meldet fortlaufend Fehlkonfigurationen gegen ein Regelwerk, was nützlich ist, aber es meldet jedes Problem isoliert. Ein Penetrationstest verkettet diese Probleme, sodass eine schreibgeschützte Rolle plus eine PassRole-Berechtigung plus ein SSRF zu einer nachgewiesenen Kontoübernahme wird. Wir nutzen Scanner für die Abdeckung und manuelles Testen für die Wirkung.

Brauchen Sie Zugangsdaten, oder können Sie von außen testen?

Beides ist legitim, und beides beantwortet unterschiedliche Fragen. Ein externer, nicht authentifizierter Test misst Ihre exponierte Angriffsfläche. Ein authentifizierter “Assumed Breach”-Test, ausgehend von einer Identität mit geringen Rechten, bringt tendenziell die Eskalations- und Lateral-Movement-Pfade zutage, die am meisten zählen. Für Cloud-Arbeit empfehlen wir in der Regel den authentifizierten Ansatz.

Wie lange dauert ein Cloud-Penetrationstest?

Das hängt von der Anzahl der Konten, der Breite der Dienste und davon ab, ob es sich um Single- oder Multi-Cloud handelt. Ein einzelnes, sauber gescoptes AWS-Konto ist schneller erledigt als eine Organisation mit mehreren Konten und Azure und GCP im Mix. Der Scope bestimmt den Zeitrahmen, und deshalb bemessen wir jeden Test individuell, statt eine Pauschalzahl zu nennen.

Welche Cloud-Befunde melden Sie am häufigsten?

Zu weit gefasste IAM-Policies und Pfade zur Rechteausweitung führen mit deutlichem Abstand, gefolgt von öffentlich zugänglichem Speicher, SSRF, das den Instance-Metadata-Dienst erreicht, und unzureichendem oder unüberwachtem Logging. Für sich genommen bewegen sie sich zwischen mittlerer und hoher Schwere. Miteinander verkettet werden sie regelmäßig zu kritischen Befunden.