Eine Datenplattform wird nicht mehr benötigt, das Projekt ist beendet, die Rechnung verschwindet aus dem Budget. Doch wer entfernt die Cloud-Berechtigungen? Genau an dieser Übergabe sollte ein Unternehmen nicht auf informelle Absprachen vertrauen. Der sinnvolle Kontrollpunkt ist nicht die letzte Nutzung einer Anwendung, sondern der nachgewiesene Entzug ihres technischen Zugriffs.
Eine am 9. November 2026 veröffentlichte Untersuchung macht dieses Problem konkret: Wiz beschreibt Angriffe über Qubole-Integrationen in mehreren AWS-Kundenumgebungen zwischen dem 14. und 26. Oktober. Die Veröffentlichung ist neu, nicht der Beginn der Angriffe. Gestohlene Zugangsdaten aus einem Qubole zugeordneten AWS-Konto ermöglichten die Übernahme kundenseitiger Integrationsrollen. Angreifer lasen Secrets und S3-Daten; viele Rollen waren ansonsten ungenutzt. [1]
Kein AWS-Exploit, sondern missbrauchtes Vertrauen
Die technische Grundlage ist ein reguläres Delegationsmodell. Ein Kunde legt eine IAM-Rolle an: Die Trust Policy bestimmt, wer sie übernehmen darf, die Berechtigungspolicy, welche Aktionen anschließend erlaubt sind. Über den Security Token Service und AssumeRole erhält die externe Identität temporäre Zugangsdaten. Dieses Modell vermeidet die Weitergabe langfristiger Kundenschlüssel an den Dienstleister. [2]
Der Sicherheitsentscheid lautet damit nicht allein: „Ist der Aufruf authentifiziert?“ Ebenso wichtig ist: „Wem vertrauen wir weiterhin, und wofür?“ Temporäre Zugangsdaten lösen die Lebensdauer einzelner Anmeldedaten. Sie ersetzen keine Entscheidung über die Lebensdauer der zugrunde liegenden Geschäftsbeziehung. Das ist die zentrale Architekturlektion dieses Vorfalls.
Nach Wiz enthielten sämtliche dem Angreifer zugeordneten Rollenübernahmen die erforderliche External ID und waren erfolgreich. [1] Das ist kein Beweis für einen Bruch des External-ID-Verfahrens: AWS beschreibt diese Kennung als Schutz gegen das Confused-Deputy-Problem, nicht als Geheimnis. Sie ordnet eine Dienstleisteranfrage dem richtigen Kunden zu; sie ersetzt keine Absicherung der Dienstleisteridentität. [2]
Was die Ermittler tatsächlich beobachteten
The Hacker News bestätigt die Veröffentlichung und beschreibt die Auswertung von Lambda-Umgebungsvariablen, Secrets Manager und SSM Parameter Store. Die gefundenen Zugangsdaten wurden anschließend mit TruffleHog auf Gültigkeit geprüft. Das illustriert, weshalb „Read-only“ nicht mit „geschäftlich ungefährlich“ gleichgesetzt werden sollte: Schon lesender Zugriff kann weitere Identitäten erschließen. [3]
Eine belastbare Gesamtzahl betroffener Organisationen ist damit nicht belegt. Laut The Hacker News blieb bei Veröffentlichung zudem offen, ob die missbrauchten Zugangsdaten bereits deaktiviert waren. Auch der ursprüngliche Diebstahl dieser Dienstleisterzugangsdaten ist öffentlich nicht erklärt. Deshalb wäre eine pauschale Entwarnung ebenso unangebracht wie eine hochgerechnete Opferzahl. [3]
Für die eigene Untersuchung ist ein konkreter Startpunkt verfügbar: Wiz empfiehlt CloudTrail-Prüfungen ab 1. Oktober 2026, insbesondere nach AssumeRole aus dem Konto 805246085872 von Nicht-AWS-Adressen. Die Konto-ID gehört auch zu legitimen Integrationen; sie allein beweist keinen Angriff. Die vollständigen Indikatoren stehen im Originalbericht. [1]
Die Loglücke liegt hinter der Anmeldung
Eine erfolgreiche Rollenübernahme beantwortet noch nicht, welche Dateien anschließend gelesen wurden. AWS unterscheidet Management-Ereignisse von S3-Datenereignissen. Objektzugriffe wie GetObject zählen zur zweiten Gruppe. CloudTrail protokolliert Datenereignisse standardmäßig nicht; auch die normale Ereignishistorie enthält sie nicht. Eine gesonderte Konfiguration ist erforderlich und verursacht zusätzliche Kosten. [4]
Daraus folgt eine praktische Budgetentscheidung: Unternehmen sollten für sensible Buckets bewusst festlegen, welche Lesezugriffe sie später belegen können müssen. Das gehört neben Aufbewahrungsfristen und Verantwortlichkeiten in die Betriebsabnahme. Eine nachträgliche Aktivierung hilft bei künftigen Vorgängen, rekonstruiert aber keine nie erfassten historischen Ereignisse.
Als Prüfmaßstab bietet sich ein ungefährlicher Test im eigenen Konto an: Eine freigegebene Testidentität liest ein Testobjekt, das SOC sucht anschließend genau diesen Zugriff. Entscheidend ist nicht der grüne Konfigurationsstatus, sondern der tatsächlich auffindbare Datensatz samt Identität, Zeitpunkt und Ressource. Dies ist eine empfohlene defensive Validierung, keine von AIFence durchgeführte Reproduktion.
Unternehmensmaßnahmen: Erst eingrenzen, dann belastbar abschließen
Aus dem Vorfall und den AWS-Kontrollmechanismen lässt sich folgendes Vorgehen ableiten:
1. Integration und Verantwortlichen zusammenführen. Für jede externe Rolle sollte ein Fachverantwortlicher bestätigen, welcher aktuelle Prozess sie benötigt. „Wurde irgendwann eingerichtet“ reicht nicht. Die Bestandsaufnahme sollte auch Testkonten, übernommene Projekte und vergessene Datenplattformen einschließen. Bei unklarer Nutzung empfiehlt sich eine abgestimmte Sperrentscheidung statt ungeprüfter Löschung produktiver Abhängigkeiten.
2. Neue Zugriffe und bestehende Sitzungen getrennt behandeln. Eine bereinigte Trust Policy ist nicht der Nachweis, dass bereits ausgestellte Sitzungen wirkungslos sind. AWS bietet einen gesonderten Rollen-Sitzungswiderruf: Eine zeitbezogene Deny-Policy entzieht älteren Sitzungen ihre Berechtigungen. Der Eingriff betrifft auch legitime Nutzer dieser Rolle. Deshalb müssen Betrieb und Incident Response ihn koordinieren. [5]
3. Erreichbare Geheimnisse systematisch erfassen. Nach bestätigter missbräuchlicher Rollenübernahme empfiehlt die veröffentlichte Anleitung, alle erreichbaren Secrets, Parameter und geheimen Lambda-Umgebungswerte auszutauschen, nicht nur nachweislich gelesene. [3] Ein Untersuchungsblatt sollte belegten Zugriff und bloße Erreichbarkeit unterscheiden sowie Folgesitzungen und abhängige Systeme erfassen. „Schlüssel rotiert“ reicht nicht, solange niemand die Ungültigkeit des alten Zugangs überprüft hat.
4. Rechte am tatsächlichen Auftrag messen. Die Kontrollfrage für eine Datenintegration lautet: Welche konkreten Daten und Verwaltungsfunktionen benötigt sie? Daraus sollte eine überprüfbare Positivliste entstehen. Ein Pilotlauf mit reduzierten Berechtigungen ist aussagekräftiger als die bloße Annahme, eine historisch gewachsene Policy sei weiterhin notwendig.
5. Offboarding technisch abnehmen. Vertragsende, entfernte Anwendung und widerrufener Cloud-Zugriff sollten getrennte Prüfpunkte sein. Der Abschlussnachweis sollte die betroffenen Konten und Rollen nennen sowie die technische Prüfung dokumentieren. So wird aus einer organisatorischen Absicht ein kontrollierbarer Sicherheitszustand.
Branchenkontext: Auch Agenten brauchen ein Ende ihrer Berechtigung
Der Fall handelt nicht von einem KI-Agentenangriff. Für Unternehmen, die Agenten an Cloud-Daten, Analyseplattformen oder Automatisierungen anschließen, ist er dennoch ein sinnvoller Architekturtest. Die eigene Kontrollfrage sollte lauten: Was passiert mit der maschinellen Identität, wenn der Pilot endet oder der Anbieter wechselt?
Als Gestaltungsprinzip empfiehlt sich deshalb ein Ablaufdatum für Freigabeentscheidungen: Nach einer festgelegten Frist bestätigt ein Verantwortlicher Zweck und Berechtigungsumfang erneut. Das ist eine organisatorisch-technische Empfehlung, keine Behauptung, AWS-Rollen würden automatisch mit einem Projektvertrag ablaufen. Sie soll verhindern, dass niemand mehr für einen weiterhin gültigen Zugang zuständig ist.
Grenzen und Fazit
Die veröffentlichten Befunde ersetzen keine Untersuchung der eigenen Umgebung. Weder fehlende Warnungen noch fehlende Objektlogs belegen Schadensfreiheit. Umgekehrt darf eine verdächtige Rollenübernahme nicht ohne weitere Belege als vollständiger Datenabfluss ausgewiesen werden. Die Untersuchung sollte gesicherte Befunde, Annahmen und offene Fragen sichtbar auseinanderhalten.
Die wichtigste Schlussfolgerung ist kein Wechsel weg von IAM-Rollen. Sie lautet: Delegiertes Vertrauen braucht einen überprüfbaren Lebenszyklus. Unternehmen sollten nicht nur fragen, ob eine Integration korrekt eingerichtet wurde. Sie müssen auch nachweisen können, dass ihr Zugriff heute noch erforderlich ist und nach ihrer Abschaltung tatsächlich endet.
Quellen
- Wiz: Trusted by Default: Qubole Cross-Account Access Abused in the Wild, 9. November 2026
- AWS IAM: Access to AWS accounts owned by third parties
- The Hacker News: Hackers Exploit Qubole's Trusted AWS Access to Breach Customer Accounts and Steal Data, 9. November 2026
- AWS S3: Amazon S3 CloudTrail events
- AWS IAM: Revoke IAM role temporary security credentials
