Kontakt
Telefon & 24/7-Notfall-Hotline+49 2932 465265-0 E-Mailinfo@rootsektor.deMo–Fr 08:00–17:00 Uhr · außerhalb der Geschäftszeiten: 24/7-Notfall-Hotline
Pentest-Angebot anfordern Notfall meldenPenetration Testing
Angriffspfade erkennen, bevor Angreifer sie nutzen.
In der Cloud führt selten eine einzelne Lücke zum Sicherheitsvorfall – meist ist es die Kombination aus zu weit gefassten Berechtigungen, offenen Diensten und vergessenen Ressourcen. Mit einem Cloud-Penetrationstest prüfen wir Ihre Umgebung in AWS, Microsoft Azure oder Google Cloud aus Sicht eines Angreifers und zeigen, welche Angriffspfade tatsächlich ausnutzbar sind.
Definition
Ein Cloud-Penetrationstest ist ein autorisierter, kontrollierter Angriff auf Ihre Cloud-Umgebung. Wir untersuchen Konten, Subscriptions und Projekte, Identitäten und Rollen, Speicher, Workloads, Netzwerke und Verwaltungsschnittstellen – und beantworten die Frage, die für Ihr Risiko zählt: Wie weit kommt ein Angreifer, der einen realistischen Einstiegspunkt findet? Das kann ein versehentlich veröffentlichter Zugriffsschlüssel sein, ein kompromittiertes Entwicklerkonto oder eine verwundbare Webanwendung.
Ausgangspunkt jedes Cloud-Pentests ist das Modell der geteilten Verantwortung (Shared Responsibility): AWS, Microsoft und Google sichern Rechenzentren, Hardware und Virtualisierung ab. Für alles, was Sie in der Cloud selbst konfigurieren – Identitäten, Berechtigungen, Netzwerkregeln, Daten und Anwendungen –, tragen Sie die Verantwortung. Genau dort entstehen die Schwachstellen, die Angreifer in der Praxis ausnutzen.
Vom Konfigurationsreview unterscheidet sich der Cloud-Pentest im Ansatz. Ein Review gleicht Einstellungen systematisch mit Best Practices wie den CIS Benchmarks ab; der Penetrationstest zeigt, ob und wie sich einzelne Schwächen ausnutzen und zu einem Angriffspfad verketten lassen. Beides ergänzt sich – für die reine Konfigurationsanalyse bieten wir den Microsoft 365 & Azure Review und den AWS Security Review an.
Die Ergebnisse helfen Ihnen, Ihre Cloud-Umgebung gezielt zu härten, und liefern belastbare Nachweise für Anforderungen wie Art. 32 DSGVO, das Risikomanagement nach NIS2, DORA oder ISO/IEC 27001:2022 – verständlich aufbereitet für Ihr Management und mit handfesten technischen Details für Ihr Cloud-Team.
Unser Vorgehen
Wir kombinieren zwei Blickwinkel. Von außen prüfen wir, was aus dem Internet erreichbar ist: öffentliche Endpunkte, Speicher, APIs, Anmeldeseiten und Verwaltungszugänge. Von innen gehen wir von einem kompromittierten Konto aus („Assumed Breach“) und analysieren, wie sich die Rechte von dort aus erweitern lassen – über Rollen, Vertrauensstellungen und Dienstkonten bis in andere Konten, Subscriptions oder Projekte.
Werkzeuge wie Prowler, ScoutSuite, Pacu oder BloodHound beschleunigen die Analyse großer Umgebungen. Den Unterschied macht jedoch die manuelle Arbeit: Wir prüfen mögliche Angriffspfade praktisch nach, belegen sie mit Nachweisen und trennen ausnutzbare Schwachstellen von rein theoretischen Befunden.
Dabei halten wir uns an die Testrichtlinien der Anbieter. Für die meisten Prüfungen ist bei AWS, Azure und Google Cloud keine vorherige Genehmigung nötig. Denial-of-Service-Tests gehören nicht zu unserem Standardumfang, und die Infrastruktur der Anbieter selbst sowie Ressourcen anderer Kunden sind grundsätzlich tabu.
Typische Schwachstellen
Richtlinien, die per Wildcard sämtliche Aktionen erlauben, Dienstkonten mit Owner-Rechten oder Anwendungen mit weitreichenden Microsoft-Graph-Berechtigungen. Schon unscheinbare Kombinationen wie iam:PassRole und das Recht, Lambda-Funktionen anzulegen, ermöglichen oft eine vollständige Rechteausweitung.
S3-Buckets, Azure-Blob-Container oder Cloud-Storage-Buckets mit anonymem Zugriff, zu großzügig ausgestellte SAS-Token sowie öffentlich geteilte Snapshots und Backups legen Daten offen – häufig unbemerkt.
SSH, RDP, Datenbanken, die Kubernetes-API oder Admin-Oberflächen, die per Security Group oder Netzwerksicherheitsgruppe aus dem gesamten Internet erreichbar sind, bieten Angreifern einen direkten Einstieg.
Zugriffsschlüssel und Passwörter liegen in Code-Repositorys, CI/CD-Variablen, Umgebungsvariablen von Funktionen, Container-Images oder Terraform-State-Dateien – lesbar für alle, die dort Zugriff erlangen.
Eine Server-Side Request Forgery in einer Webanwendung genügt, um über den Metadatendienst temporäre Zugangsdaten der Instanzrolle abzugreifen – besonders leicht, wenn bei AWS noch IMDSv1 aktiv ist.
Privilegierte Pods, zu weit gefasste RBAC-Rollen, automatisch eingebundene Service-Account-Token und fehlende Network Policies ermöglichen den Ausbruch aus dem Container bis zur Übernahme des Clusters.
Flache VPC- oder VNet-Strukturen, großzügiges Peering, VPN-Verbindungen ins eigene Rechenzentrum und Synchronisationsdienste wie Microsoft Entra Connect verbinden Cloud und On-Premises – auch für Angreifer.
Sind CloudTrail, das Azure-Aktivitätsprotokoll oder die Cloud Audit Logs unvollständig konfiguriert oder wertet niemand die Warnungen aus, bleiben Angriffe lange unentdeckt.
Testperspektiven
Welche Perspektive sinnvoll ist, hängt von Ihrem Ziel ab – beim AWS-Pentest ebenso wie beim Azure-Pentest oder in der Google Cloud. Wir beraten Sie im Scoping und kombinieren die Ansätze bei Bedarf.
Black Box
Wir starten ohne Zugangsdaten und Vorwissen – wie ein Angreifer aus dem Internet.
Grey Box
Wir erhalten eine Identität mit typischen Rechten und prüfen, wie weit sich der Zugriff ausweiten lässt.
White Box
Mit Lesezugriff auf die gesamte Umgebung und Ihre IaC-Definitionen decken wir auch versteckte Pfade auf.
Ablauf
Von der ersten Abstimmung bis zur Prüfbescheinigung – transparent, in enger Zusammenarbeit mit Ihrem Cloud-Team und nach unserem bewährten Vorgehen im Penetration Testing.
Wir klären Anbieter, Konten, Subscriptions oder Projekte, relevante Dienste, Testperspektive und Ziele – etwa: „Kommt ein Angreifer von der Webanwendung an die Kundendaten?“
Innerhalb von 24 Stunden (an Werktagen) nach dem Scoping erhalten Sie ein Festpreisangebot ohne versteckte Kosten.
Sie richten Testidentitäten mit den vereinbarten Rechten ein. Gemeinsam legen wir Zeitfenster, Ansprechpersonen und Abbruchkriterien fest und gleichen den Testplan mit den Richtlinien der Anbieter ab.
Wir erfassen die erreichbaren Ressourcen, werten Berechtigungen und Konfigurationen aus und identifizieren mögliche Angriffspfade.
Wir verifizieren die Pfade praktisch – von der Rechteausweitung bis zum Zugriff auf vereinbarte Zielobjekte –, kontrolliert und lückenlos dokumentiert.
Sie erhalten den Bericht, auf Wunsch eine Abschlussbesprechung und eine Prüfbescheinigung. Behobene Schwachstellen prüfen wir kostenlos erneut.
Ergebnisbericht
Unser Bericht richtet sich an zwei Zielgruppen: Die Management Summary ordnet die Ergebnisse geschäftlich ein und zeigt, wo Handlungsbedarf besteht. Der technische Teil liefert Ihrem Cloud-Team alles, was es für die Behebung braucht – betroffene Ressourcen, nachvollziehbare Nachweise und konkrete Maßnahmen bis hin zur angepassten Richtlinie.
Schildern Sie uns Ihre Architektur und Ihre Ziele. Wir schlagen einen passenden Prüfumfang vor und senden Ihnen werktags innerhalb von 24 Stunden nach dem Scoping ein Festpreisangebot.
FAQ
Ihre Frage ist nicht dabei? Rufen Sie uns an: +49 2932 465265-0 oder schreiben Sie an info@rootsektor.de.
Für die meisten Prüfungen nicht. AWS, Microsoft Azure und Google Cloud erlauben Penetrationstests der eigenen Ressourcen grundsätzlich ohne vorherige Anmeldung, geben aber Regeln vor – etwa zu Denial-of-Service-Tests oder zur Infrastruktur des Anbieters. Wir stimmen den Testplan auf diese Richtlinien ab. Die Freigabe für Ihre Konten erteilen Sie uns schriftlich.
Ein Konfigurationsreview prüft Ihre Einstellungen systematisch und in der Breite gegen Best Practices. Der Penetrationstest geht in die Tiefe: Er zeigt, welche Schwächen sich tatsächlich ausnutzen und zu einem Angriff verketten lassen. Für einen reinen Konfigurationsabgleich empfehlen wir den Microsoft 365 & Azure Review oder den AWS Security Review – viele Unternehmen kombinieren beides.
Typische Anlässe sind eine Migration in die Cloud, der Go-live einer neuen Plattform, größere Architekturänderungen, neue Konten oder Subscriptions sowie Anforderungen von Kunden, Auditoren oder Versicherern. Weil sich Cloud-Umgebungen ständig verändern, empfehlen wir zusätzlich eine regelmäßige Wiederholung, mindestens einmal im Jahr.
Das hängt von der Testperspektive ab. Für einen externen Test genügt die Angabe der Zielsysteme. Für Grey- und White-Box-Tests reichen in der Regel Leserollen wie SecurityAudit bei AWS, Reader und Global Reader in Azure bzw. Entra ID oder Viewer in Google Cloud, ergänzt um eine Testidentität mit typischen Rechten. Wir empfehlen zeitlich befristete Zugänge, die nach dem Test wieder entfernt werden.
Das Risiko ist gering: Last- und Denial-of-Service-Tests gehören nicht zum Standardumfang, und wir einigen uns vorab auf Zeitfenster und Abbruchkriterien. Aktionen, die Daten oder Konfigurationen verändern könnten, erfolgen nur nach ausdrücklicher Absprache. Auf Wunsch testen wir in einer Staging-Umgebung, die der Produktion entspricht.
Ja – als technischer Nachweis. Bericht und Prüfbescheinigung belegen, dass Sie die Wirksamkeit Ihrer Sicherheitsmaßnahmen überprüfen lassen, wie es etwa Art. 32 DSGVO, NIS2 oder ISO/IEC 27001 verlangen. Ein Penetrationstest ersetzt jedoch weder ein Audit noch ein Testat.
Der Aufwand hängt vor allem von der Anzahl der Konten und Subscriptions, den eingesetzten Diensten, der Testperspektive und der gewünschten Prüftiefe ab. Nach dem Scoping erhalten Sie werktags innerhalb von 24 Stunden ein Festpreisangebot – ohne Nachforderungen für den vereinbarten Umfang.
Zugänge nutzen wir ausschließlich für den vereinbarten Test, Ergebnisse und Unterlagen behandeln wir streng vertraulich. Auf Wunsch unterzeichnen wir vor dem Scoping eine Vertraulichkeitsvereinbarung.
Beschreiben Sie kurz Ihre Umgebung – Anbieter, Anzahl der Konten oder Subscriptions und Ihre wichtigsten Ziele. Wir melden uns für ein unverbindliches Erstgespräch.
This page is also available in English.