Über 9.300 weiterhin aktive AWS-Schlüssel online offengelegt: Hunderte ermöglichen vollständige Kontokontrolle

Vier Jahre Überwachung zeigen Tausende gültige Zugangsdaten

Eine Analyse von Truffle Security hat mehr als 9.300 AWS-Zugriffsschlüssel identifiziert, die zwischen August 2022 und August 2026 online veröffentlicht wurden und weiterhin gültig waren. Die Ergebnisse wurden am 21. August 2026 nach einer vierjährigen Überwachung bekannt gegeben.

Das Problem liegt nicht in einer Schwachstelle der AWS-Software, sondern in der versehentlichen Veröffentlichung von Zugangsdaten, die eine Authentifizierung bei Cloud-Konten ermöglichen. Die Schlüssel tauchten in Code-Repositories, Git-Verläufen, Datensätzen, Docker-Images, Registries und von Continuous-Integration-Systemen erzeugten Logs auf.

Insgesamt fanden die Forschenden 431.875 AWS-Secrets. Nach der Entfernung von Duplikaten umfasste die Stichprobe 64.024 eindeutige Schlüssel, die 50.654 AWS-Konten zugeordnet waren.

Die untersuchte Teilmenge mit vollständigen Zugangsdaten, deren Gültigkeit durch eine erneute Authentifizierung überprüft werden konnte, umfasste 10.616 Schlüssel. Davon konnten sich am 10. August noch 88 % erfolgreich authentifizieren. Das deutet darauf hin, dass ein erheblicher Teil der veröffentlichten Zugangsdaten weder widerrufen noch ersetzt worden war.

Root- und AdministratorAccess-Rechte können aus einem Leak eine Kontoübernahme machen

Unter den weiterhin aktiven Schlüsseln waren 817 Unternehmen zuzuordnen. Davon gehörten 526 zu AWS-Root-Benutzern, während 242 IAM-Benutzern mit der Policy AdministratorAccess zugeordnet waren.

Diese beiden Kategorien bündeln die riskantesten Berechtigungen. Die Root-Identität stellt die höchste administrative Ebene eines Kontos dar und unterliegt nicht den Einschränkungen, die üblicherweise für IAM-Benutzer gelten. AdministratorAccess ermöglicht dagegen, praktisch alle Ressourcen und Services eines Kontos zu erstellen, zu ändern, zu löschen und einzusehen.

Nach Angaben der Forschenden ermöglichten 768 aktive Schlüssel aus diesen beiden privilegierten Gruppen die vollständige Kontrolle über ein AWS-Unternehmenskonto. Das bedeutet nicht, dass jeder Schlüssel von einem Angreifer verwendet wurde. Eine öffentlich zugängliche und funktionierende Zugangsinformation konnte jedoch einen äußerst weitreichenden Einstiegspunkt bieten.

Mit einem solchen Zugriff kann ein Angreifer:

• in der Cloud gespeicherte Daten lesen, kopieren oder löschen;
• Server, Anwendungen, Datenbanken und Konfigurationen manipulieren;
• vorhandene Ressourcen ändern oder neue erstellen;
• betrügerische Administratorkonten anlegen, um den Zugriff aufrechtzuerhalten;
• Mining-Software installieren und dadurch die Kosten schnell in die Höhe treiben;
• Services und Komponenten der Online-Infrastruktur verändern.

Das Risiko beschränkt sich daher nicht auf den Diebstahl des Schlüssels. Ein Angreifer kann damit die AWS-Umgebung verändern und es erschweren, bösartige Aktivitäten von normalen administrativen Vorgängen zu unterscheiden.

Hugging Face ist die wichtigste einzelne Quelle der offengelegten Schlüssel

Die Plattform mit der höchsten Zahl an Expositionen ist Hugging Face, die zum Teilen von KI-Modellen, Datensätzen und Anwendungen genutzt wird. Die Forschenden ordneten ihr 8.482 Fälle mit eindeutigen Schlüsseln zu.

Davon waren 17,9 % Root-Schlüssel. AWS-Zugangsdaten in veröffentlichten Inhalten einer KI-Plattform können aus Beispielcode, Notebooks, Datensätzen, Konfigurationsdateien oder während der Entwicklung hochgeladenem Material stammen.

Ein Schlüssel, der in einem öffentlichen Projekt veröffentlicht wurde, muss als kompromittiert gelten, selbst wenn das Repository später auf privat gestellt oder die betreffende Datei gelöscht wird. Kopien können im Git-Verlauf, in Forks, Caches, heruntergeladenen Datensätzen oder Indexierungssystemen erhalten bleiben.

Die betroffenen Organisationen können je nach den in ihren Konten vorhandenen Ressourcen unterschiedliche Folgen erleiden: Datenexposition, Ausfälle von Anwendungen, Manipulationen der Infrastruktur oder unvorhersehbare Kosten durch missbräuchlich erstellte Services.

Alte Zugangsdaten und unzureichende Kostenkontrollen verschärfen das Risiko

Die Altersanalyse, die für 2.903 Schlüssel möglich war, ergab ein Medianalter von 1.831 Tagen, also etwa fünf Jahren. Der älteste Schlüssel bestand seit 17,4 Jahren.

Nur 398 Einträge beziehungsweise 13,7 % verfügten über einen neueren Zugriffsschlüssel für denselben Benutzer. Nach Einschätzung von Truffle Security deutet dies darauf hin, dass viele Zugangsdaten wahrscheinlich nie rotiert wurden.

Ein jahrelang aktiver Schlüssel vergrößert das Zeitfenster, in dem er abgegriffen und wiederverwendet werden kann. Auch das Vorhandensein eines neueren Schlüssels beweist nicht automatisch, dass der alte widerrufen wurde: Dies muss direkt in den Kontoeinstellungen überprüft werden.

Zusätzlich verschärft das Kostenmanagement die Lage. Nur 262 von 2.754 Konten, für die entsprechende Daten ausgelesen werden konnten, verfügten über einen Budget-Alarm. Ohne Warnmeldungen kann ein Angreifer Cloud-Ressourcen erstellen oder rechenintensive Aktivitäten starten, ohne dass der Kontoinhaber schnell ein ungewöhnliches Verhalten bemerkt.

Die operative Situation bleibt auch dann schwierig, wenn eine Organisation über Schutzmechanismen verfügt. Der Blue Report 2026, der auf 338 Millionen Simulationen in Produktionsumgebungen von Kunden basiert, zeigt, dass bei der Nutzung gültiger Zugangsdaten nur 37 % der Aktionen des Angreifers blockiert werden. Ein korrekter Schlüssel kann somit zahlreiche Kontrollen umgehen, die unbefugte Zugriffe erkennen sollen.

Was AWS-Kontoinhaber tun sollten

Oberste Priorität hat der Widerruf jedes Schlüssels, der in einer öffentlichen Quelle auftauchte, sowie dessen Ersatz durch neue Zugangsdaten. Es reicht nicht aus, lediglich die Datei mit dem Schlüssel zu entfernen. Die Rotation sollte durch eine Log-Analyse ergänzt werden, um verdächtige Authentifizierungen oder Änderungen zu erkennen.

Die wichtigsten Maßnahmen:

1. Root-Zugriffsschlüssel löschen;
2. IAM-Zugangsdaten nach Alter und letzter Verwendung inventarisieren;
3. offengelegte Schlüssel umgehend widerrufen oder rotieren;
4. kürzlich angelegte Benutzer, Rollen, Policies und Administratorkonten überprüfen;
5. Budget-Alarme und Ausgabenschwellen konfigurieren;
6. in Repositories, Git-Verläufen, Docker-Images, Datensätzen und Logs nach Schlüsseln suchen;
7. jede veröffentlichte Zugangsinformation als kompromittiert betrachten, auch wenn kein Missbrauch festgestellt wurde.

Für die künftige Überwachung empfiehlt sich der Einsatz von IAM-Rollen und temporären Zugangsdaten, um die Verwendung statischer Schlüssel zu reduzieren. Secrets sollten nicht in Code oder Datensätze aufgenommen, sondern in spezialisierten Systemen gespeichert und vor jeder Veröffentlichung automatisch gescannt werden.

Truffle Security zufolge beschränkten sich die Tests auf das Auslesen von Metadaten; alle identifizierbaren Eigentümer wurden benachrichtigt. Wie viele Konten tatsächlich kompromittiert wurden oder wie viele Angriffe die gefundenen Schlüssel ausnutzten, ist nicht bekannt. Die gesicherten Erkenntnisse reichen jedoch aus, um jede offengelegte Zugangsinformation als nicht mehr vertrauenswürdig zu behandeln.