9.308 öffentlich zugängliche AWS-Schlüssel funktionierten weiterhin

Die Untersuchung von Truffle Security zeichnet ein Bild von Cloud-Zugangsdaten, die nach ihrer öffentlichen Veröffentlichung oft jahrelang weiter funktionieren. Zwischen August 2022 und August 2026 fanden die Forschenden in öffentlichen Repositories, Git-Verläufen, Datensätzen, Docker-Images, Container-Registries und Continuous-Integration-Logs insgesamt 431.875 AWS-Secret-Funde. Nach der Bereinigung von Duplikaten blieben 64.024 einzigartige AWS-Schlüssel übrig. 145

Besonders kritisch: Von 10.616 vollständigen Zugangsdatenpaaren, die am 10. August 2026 erneut getestet wurden, konnten sich 9.308 erfolgreich authentifizieren – etwa 88 Prozent. Dieser Wert gilt nur für die vollständigen, erneut geprüften Paare und nicht für jede teilweise gefundene Information. 145

Hohe Berechtigungen machten viele Schlüssel besonders gefährlich

Die verifizierte Schlüsselsammlung umfasste 10.625 Root-Zugangsdaten, 48.744 Schlüssel von IAM-Nutzern und 4.655 nicht eindeutig klassifizierbare Schlüssel. Root-Zugangsdaten machten damit 16,6 Prozent der eindeutigen Schlüssel aus. 1

Truffle Security ordnete 817 aktive Schlüssel Unternehmen zu. Darunter waren:

• 526 Root-Schlüssel, die mit den höchsten Berechtigungen eines AWS-Kontos verbunden sind.
• 242 Schlüssel von IAM-Nutzern mit AdministratorAccess, einer Richtlinie, die vollständige Kontrolle über ein Konto ermöglichen kann.
• 768 aktive Zugangsdaten insgesamt, mit denen ein Angreifer vollständige Kontrolle über ein Unternehmenskonto erlangen könnte.
• 130 aktive Root-Schlüssel von AWS-Organizations-Verwaltungskonten. Eine Übernahme könnte potenziell auch verbundene Mitgliedskonten betreffen. 13

In einer kleineren Gruppe von IAM-Nutzern, deren Richtlinien ausgelesen werden konnten, verfügten 976 von 1.157 Nutzern – 84 Prozent – über AdministratorAccess. Weitere 144 hatten IAMFullAccess. Truffle Security weist darauf hin, dass diese Quote nur eine Tendenz beschreibt: Nutzer, deren Richtlinien sich auslesen ließen, müssen nicht repräsentativ für alle geleakten IAM-Nutzer sein. 1

Wie viele AWS-Konten waren betroffen?

In den bereitgestellten Unterlagen finden sich zwei unterschiedliche Angaben zur Zahl der AWS-Konten. Eine Zusammenfassung ordnet die 64.024 Schlüssel 9.945 verschiedenen AWS-Konten zu, während die Zusammenfassung des zugrunde liegenden Berichts 50.654 verschiedene AWS-Konten nennt. Die verfügbaren Materialien erklären nicht, warum diese Werte voneinander abweichen. Sie sollten daher nicht als austauschbare Angaben behandelt werden. 1

Klarer ist die Risikoeinschätzung auf Ebene der Berechtigungen: Hunderte aktive Schlüssel waren Unternehmen zugeordnet, und 768 davon konnten vollständige Kontrolle über ein Firmenkonto ermöglichen. 13

Hugging Face war die größte einzelne Quelle

Auf Hugging Face fanden die Forschenden 8.482 einzigartige, noch aktive AWS-Schlüssel in 3.394 öffentlichen Datensätzen. Damit war die Plattform die größte einzelne Quelle der Untersuchung. 17,9 Prozent dieser Schlüssel waren Root-Zugangsdaten – der höchste Root-Anteil unter den erfassten Quellen. 125

Ein Grund für die anhaltende Verbreitung ist die Wiederverwendung öffentlicher Daten. Code-Snapshots mit Geheimnissen können in Trainingsdatensätze übernommen und anschließend in mehrere nachgelagerte Datensätze kopiert werden. Wird ein Schlüssel aus dem ursprünglichen Repository entfernt, bedeutet das daher nicht automatisch, dass alle Kopien verschwunden sind. 1

Diese AWS-Zahlen stehen im Zusammenhang mit einer größeren Untersuchung von Hugging Face. Nach Angaben von Truffle Security wurden 7,6 Petabyte Daten und 187 Millionen Dateien geprüft. Dabei entdeckte das Unternehmen 221.303 aktive, einzigartige Zugangsdaten in 6.003 Datensätzen. Diese Gesamtzahl umfasst alle Arten von Zugangsdaten, nicht nur AWS-Schlüssel. 6

Viele Schlüssel waren Jahre alt und nie ersetzt worden

Bei 2.903 aktiven Schlüsseln ließ sich das Erstellungsdatum auslesen. Ihr mittleres Alter betrug 1.831 Tage – ungefähr fünf Jahre. Die Hälfte war älter als fünf Jahre, der älteste Schlüssel 17,4 Jahre. Nur 25 Schlüssel, also 0,9 Prozent, waren in den vorangegangenen 30 Tagen erstellt worden. 1

Lediglich 398 dieser 2.903 Schlüssel – 13,7 Prozent – hatten einen neueren Ersatzschlüssel. Das deutet darauf hin, dass die meisten Zugangsdaten nach ihrer Veröffentlichung weder rotiert noch ersetzt oder vollständig bereinigt worden waren. 1

Die praktische Konsequenz ist eindeutig: Ein Geheimnis, das einmal öffentlich sichtbar war, sollte als dauerhaft kompromittiert gelten. Das Löschen aus einer Datei oder einem Repository reicht nicht aus, wenn der Schlüssel noch in der Git-Historie, einem Container-Image, einem Paketartefakt oder einem öffentlichen Datensatz enthalten ist. 1

Fehlende Budgetwarnungen erhöhten das Risiko von Cryptomining

Auch Kostenkontrollen waren selten eingerichtet. Von 2.754 Konten, deren Budget-Einstellungen ausgelesen werden konnten, verfügten nur 262 – 9,5 Prozent – über mindestens eine Budgetwarnung. Der mittlere Schwellenwert lag bei 8 US-Dollar. 12

Bei 90,5 Prozent der auslesbaren Konten war keine erkennbare Budgetwarnung vorhanden. Angreifer könnten gültige Zugangsdaten dadurch nutzen, um beispielsweise Cryptomining oder andere rechenintensive Workloads zu starten, bevor das Unternehmen die ungewöhnlichen Kosten bemerkt. 12

Die untersuchten Konten mit auslesbaren Abrechnungsdaten verursachten im Juli 2026 zusammen Kosten von 420.631 US-Dollar. 50 Konten überschritten in diesem Monat 1.000 US-Dollar, neun sogar 10.000 US-Dollar. Diese Werte beschreiben die beobachteten Konten, belegen aber nicht, dass die Ausgaben durch den Missbrauch geleakter Zugangsdaten entstanden. 1

Quarantäne-Richtlinie von AWS bedeutete nicht zwingend eine sofortige Sperre

Truffle Security beobachtete, dass AWS bei erkannten geleakten IAM-Schlüsseln die Richtlinie AWSCompromisedKeyQuarantine anwendete. Sie schränkt die möglichen Aktionen eines Schlüssels ein, deaktiviert die Authentifizierung aber nicht zwingend sofort. 1

Von den untersuchten aktiven IAM-Schlüsseln trugen 929 von 7.590 – 12 Prozent – diese Richtlinie. Weitere 112 waren mit einer älteren Version versehen, die AWS seit 2023 nicht mehr anwendet. Nach Einschätzung von Truffle Security blieben damit einige Schlüssel trotz lang zurückliegender Hinweise auf eine Veröffentlichung nutzbar. 1

Eine Quarantäne-Richtlinie sollte deshalb als Warnsignal und nicht als Beleg dafür verstanden werden, dass ein Geheimnis sicher außer Betrieb ist. Unternehmen sollten den Schlüssel untersuchen, seinen Besitzer und seine Berechtigungen feststellen und ihn anschließend widerrufen oder rotieren. 1

So wurden die Zugangsdaten geprüft

Nach eigenen Angaben testete Truffle Security nur Zugangsdatenpaare, für die das vollständige Material vorlag. Für die Analyse von Konto- und Berechtigungsdaten wurden schreibgeschützte IAM-Aufrufe eingesetzt – jeweils mit einem einzelnen Schlüssel. Das Unternehmen veröffentlichte die Schlüssel nicht und informierte jeden identifizierbaren Besitzer. 15

Diese Vorgehensweise ist für die Einordnung der 88-Prozent-Zahl entscheidend: Sie beschreibt die erfolgreich getestete Teilmenge vollständiger Zugangsdaten, nicht sämtliche öffentlichen Funde und nicht alle während des Scans entdeckten Teilinformationen. 14

Was Unternehmen jetzt tun sollten

Aus den Ergebnissen lässt sich eine kompakte Maßnahmenliste ableiten:

1. Root-Zugangsschlüssel löschen. Truffle Security zufolge gibt es für Root-Schlüssel keinen legitimen operativen Einsatz. 1
2. Alle IAM-Zugangsschlüssel erfassen – einschließlich solcher in Repositories, Git-Verläufen, CI-Logs, Images, Registries und veröffentlichten Datensätzen. 1
3. Öffentlich gewordene Zugangsdaten sofort widerrufen oder rotieren. Das Entfernen einer sichtbaren Kopie genügt nicht, wenn das Geheimnis in historischen oder nachgelagerten Artefakten fortbesteht. 1
4. Ein maximales Schlüsselalter festlegen und Rotation erzwingen. Alte und ungenutzte Zugangsdaten sollten entfernt werden, statt unbegrenzt aktiv zu bleiben. 1
5. Budgetwarnungen einrichten. Selbst ein niedriger Schwellenwert – etwa 10 US-Dollar – kann ungewöhnliche Ausgaben früh sichtbar machen. 1
6. Nach AWSCompromisedKeyQuarantine suchen und die Richtlinie als Hinweis auf eine mögliche Veröffentlichung untersuchen. 1
7. Kontinuierliches Secret-Scanning einsetzen – für Quellcode, Historien, Build-Systeme, Container-Artefakte, Registries und veröffentlichte Datensätze. 1

Die zentrale Warnung der Untersuchung lautet: Eine öffentliche Veröffentlichung ist kein einmaliges Leck, das mit dem Löschen einer Datei erledigt ist. Ohne Widerruf, Rotation und laufende Überwachung kann ein AWS-Schlüssel über Jahre hinweg einen funktionierenden Zugang zu Cloud-Infrastruktur bieten.