Qubole: Angreifer missbrauchen Vertrauensrollen und stehlen Daten aus AWS-Konten

Ein Angreifer ist vom 14. bis 26. Oktober 2026 über ein AWS-Konto, das die Datenplattform Qubole nutzt, in die AWS-Umgebungen mehrerer Qubole-Kunden eingedrungen. Das hat der Cloud-Sicherheitsanbieter Wiz am 9. November veröffentlicht. Untersucht hat Wiz den Fall mit Sentra und Mandiant, Sentra hatte die Aktivität bei eigenen Kunden entdeckt. Der Angreifer nutzte die IAM-Rollen, mit denen Kunden Qubole Zugriff gewährt hatten, las Geheimnisse aus und lud Daten aus S3 herunter.

Betroffen sein können alle Firmen, die Qubole jemals an AWS angebunden haben, per IAM-Rolle oder mit Zugangsschlüsseln, auch wenn sie die Plattform nicht mehr nutzen. Diese Firmen sollten heute ihre CloudTrail-Protokolle ab dem 1. Oktober prüfen. Wer Qubole nie eingesetzt hat, ist von diesem Angriff nicht betroffen, sollte aber die eigenen Rollen für Fremdanbieter nach demselben Muster prüfen.

Was ist passiert?

Qubole, eine Data-Lake-Plattform des Herstellers Idera, arbeitet in den AWS-Konten ihrer Kunden. Dafür legt der Kunde eine IAM-Rolle an, deren Vertrauensrichtlinie dem AWS-Konto von Qubole erlaubt, die Rolle zu übernehmen. In der Regel muss jede Anfrage eine passende External ID enthalten. Laut Wiz verwendete der Angreifer Zugangsdaten aus dem AWS-Konto 805246085872, das die Qubole-Plattform für diese Zugriffe nutzt. Jede AssumeRole-Anfrage, die Wiz dem Angreifer zuordnet, enthielt eine External ID, und jede war erfolgreich. Die meisten übernommenen Rollen waren sonst ungenutzt.

Wie der Angreifer an die Zugangsdaten kam, hat Wiz nicht offengelegt. Auf ihren Websites hatten weder Qubole noch Idera am 9. November eine Stellungnahme veröffentlicht, berichtet The Hacker News. Wiz beschreibt zudem einen getrennten Fall vom 8. bis 11. Oktober, bei dem jemand kundeneigene AWS-Zugangsschlüssel missbrauchte, die nach Einschätzung von Wiz für Qubole angelegt worden waren. In wenigen Fällen drang er weiter in die Cloud-Umgebung ein. Eine Verbindung zum Rollenmissbrauch hat Wiz nicht festgestellt.

Wer ist betroffen?

Gefährdet sind AWS-Konten mit einer Rolle, die dem Qubole-Konto vertraut. In den von Wiz untersuchten Umgebungen las der Angreifer Umgebungsvariablen von Lambda-Funktionen, Werte aus Secrets Manager und dem SSM Parameter Store. Gefundene Zugangsdaten prüfte er mit dem Werkzeug TruffleHog: eigene AWS-Zugangsschlüssel der Opfer, Client Secrets von Entra-ID-Dienstprinzipalen und Okta-Client-Zugangsdaten. Damit reicht die Gefahr über AWS hinaus bis in Entra ID und Okta.

Wie kritisch ist das?

In den von Wiz untersuchten Umgebungen sind Daten nachweislich abgeflossen. Der Angreifer ging laut Wiz offenbar wahllos vor und las aus den Buckets, die die jeweilige Rolle erreichte, teils ganze Buckets in einer Sitzung. Welche Objekte gelesen wurden, zeigen die normalen CloudTrail-Ereignisse nicht. Dafür braucht es S3-Data-Events oder Server-Zugriffsprotokolle, die bei mehreren Opfern fehlten. Ob die Zugangsdaten inzwischen gesperrt sind und der Angriff beendet ist, sagt Wiz nicht.

Was sollten Admins jetzt tun?

• Alle AWS-Konten nach Rollen durchsuchen, deren Vertrauensrichtlinie das Konto 805246085872 oder andere fremde Konten enthält.
• In CloudTrail ab 1. Oktober AssumeRole-Ereignisse aus diesem Konto suchen, deren Quelladresse nicht zu AWS gehört, dazu die Principal-ID AIDA3W7DIFLYOLTK63SFS, die Principal-ID AIDAJYRRH5Y3A7AAJM2HW bei Anfragen von außerhalb AWS (diese nutzt auch Qubole selbst) und Sitzungsnamen mit dem Präfix quiam-.
• Die Adressen 57.129.54.120 und 2001:41d0:70d:7800:: (OVH) sowie die Mullvad-Adressen 45.83.220.211, 185.209.199.73 und 89.37.63.175 prüfen. Treffer auf die Mullvad-Adressen allein beweisen nichts, weil viele VPN-Nutzer sie teilen.
• Bei einem Treffer alle Geheimnisse, Parameter und Lambda-Variablen rotieren, die die Rolle lesen konnte, und die aktiven Sitzungen der Rolle widerrufen. Das Rotieren allein beendet laufende Sitzungen nicht.
• Anmeldeprotokolle von Entra ID und Okta auf den Benutzeragenten TruffleHog prüfen. Verdächtig ist das nur zusammen mit einer der genannten Adressen, denn auch eigene Sicherheitsteams nutzen das Werkzeug.
• Ungenutzte Rollen löschen und Vertrauensrichtlinien mit einer Bedingung auf aws:SourceIp oder aws:SourceVpce auf die dokumentierten Netzbereiche des Anbieters einschränken. Laut Wiz hätte schon eine Bedingung auf die Quell-IP jede beobachtete Übernahme blockiert.

Einordnung für Unternehmen

Qubole selbst dürfte im Mittelstand nur wenige Kunden haben. Das Muster dahinter betrifft dagegen jede Firma, die einem SaaS-Anbieter Zugriff auf ihr Cloud-Konto gibt: Die Rolle bleibt oft bestehen, auch wenn der Dienst längst abgeschaltet ist, und die External ID taugt nicht als alleiniger Schutz, weil sie kein Geheimnis ist. Wer Fremdzugriffe nicht inventarisiert, merkt einen Missbrauch womöglich erst, wenn ein Dritter warnt, wie hier Sentra. Ein jährlicher Abgleich aller Vertrauensstellungen gegen die tatsächlich genutzten Dienste ist wenig Aufwand.

Passende Anleitungen auf S-EDV

• Mittwald: Angreifer erbeuten Tokens über MCP-Server, mStudio und SSH gesperrt
• WorkOS: KI-Pentest-Agent griff über versehentlich ausgerollten Entwicklerzugang Daten ab

Quellen

• Wiz: Analyse des Missbrauchs der Qubole-Kontozugriffe
• The Hacker News: Angreifer missbrauchen Qubole-Zugriff auf AWS-Konten