Geleakte AWS-Keys: 768 Firmenzugänge mit vollen Adminrechten

Geleakte AWS-Keys sind kein theoretisches Risiko: Eine neue Auswertung von Truffle Security zeigt, dass 768 öffentlich aufgetauchte Schlüssel zum Stichtag 10. August 2026 noch immer die volle Kontrolle über ein Firmen-AWS-Konto gaben. Auffällig ist dabei weniger die Menge als das Alter der Funde.

Was Truffle Security gemessen hat

Die Sicherheitsfirma sammelt nach eigenen Angaben seit vier Jahren öffentlich auffindbare AWS-Zugangsdaten – aus Git-Historien, Datensätzen auf Hugging Face, Docker-Images, Paket-Registries und CI-Logs. Aus 431.875 Einzelfunden blieben nach Deduplizierung 64.024 eindeutige Schlüsselpaare übrig, verteilt auf 50.654 Konten.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

Für 10.616 dieser Paare lagen vollständige Zugangsdaten vor. Diese Teilmenge wurde am 10. August 2026 erneut getestet. Ergebnis: 88 Prozent authentifizierten sich weiterhin erfolgreich. Von den noch aktiven Schlüsseln ließen sich 817 einer Firma zuordnen. Davon sind 526 Root-Schlüssel und weitere 242 IAM-Nutzer mit der Richtlinie AdministratorAccess. Beide Gruppen überschneiden sich nicht – macht 768 lebende Schlüssel mit voller Kontrolle über ein Unternehmenskonto.

• Jeder sechste Schlüssel gehört zum Root-Konto: 10.625 der 64.024 Funde, also 16,6 Prozent. Bei einem Root-Key hilft keine Rechteeinschränkung – er hat per Definition alles, bis hin zur Kontoschließung.
• Alt statt frisch: Bei den 2.903 Schlüsseln mit auslesbarem Erstelldatum lag der Median bei 1.831 Tagen, gut fünf Jahren. Der älteste war 17,4 Jahre alt. Nur 398 davon (13,7 Prozent) hatten überhaupt einen neueren Schlüssel daneben.
• Hugging Face als größte Quelle: 8.482 eindeutige Schlüssel stammen von der KI-Plattform, 17,9 Prozent davon Root – der höchste Root-Anteil aller untersuchten Fundorte.
• Kaum Kostenbremse: Bei 2.754 Schlüsseln waren die Budget-Einstellungen lesbar. Nur 262 Konten (9,5 Prozent) hatten überhaupt eine Budget-Warnung, das median gesetzte Limit lag bei 8 US-Dollar.
• 130 Root-Keys auf Organisations-Verwaltungskonten: Diese Konten steuern sämtliche Mitgliedskonten einer AWS-Organisation. Ein einziger davon öffnet alles darunter.

Amazon erklärte gegenüber BleepingComputer, man benachrichtige betroffene Kunden bei bekannt gewordenen Schlüsseln und wende gegebenenfalls Quarantäne-Richtlinien an. Genau das lässt sich in den Daten nachvollziehen: 929 der aktiven IAM-Nutzer trugen bereits AWS’ Richtlinie AWSCompromisedKeyQuarantine, 112 davon in einer Fassung, die AWS seit 2023 nicht mehr vergibt. AWS hatte die Offenlegung also erkannt und gemeldet – die Eigentümer haben trotzdem nicht reagiert.

Was das für dich bedeutet

Aus 25 Jahren IT und mit CISO-Brille betrachtet ist an dieser Auswertung nicht die Schlagzeile das Bemerkenswerte, sondern der Zeitverlauf. Von den 2.903 Schlüsseln mit bekanntem Erstelldatum stammten nur 25 aus den letzten 30 Tagen, also 0,9 Prozent. Das hier ist kein Vorfall, den man mit einem Incident-Prozess einfängt. Es ist ein Altbestand, der über Jahre gewachsen ist.

Wer aus dem Active-Directory-Umfeld kommt, kennt das Muster sofort: Es ist dieselbe Krankheit wie das Servicekonto, dessen Passwort nie abläuft, dessen Ersteller die Firma längst verlassen hat und das niemand anzurühren wagt, weil unklar ist, was daran hängt. Cloud-Zugangsschlüssel sind Servicekonten – nur schneller angelegt und schlechter dokumentiert. Der Unterschied ist, dass ein AD-Servicekonto hinter der Firewall sitzt und ein AWS-Key im Internet.

Ökonomisch ist das für Angreifer attraktiv, weil die Erkennungswahrscheinlichkeit gegen null geht. Ein Admin-Zugang erlaubt das Auslesen und Löschen von Daten, das Anlegen dauerhafter Schatten-Identitäten und, als schnellstes Geld, das Starten von Kryptominern auf fremde Rechnung. Ohne Kostenwarnung fällt das erst mit der Monatsrechnung auf. Und wo die betroffenen Konten kaum etwas verbrauchen, fällt es womöglich gar nicht auf.

Ein zweiter Punkt wird selten mitgedacht: Über den Weg Hugging Face landen Secrets in Trainingsdaten. Ein Schlüssel, der einmal in einem öffentlichen Repository stand, wandert in Datensätze, die weltweit heruntergeladen werden. Die Datei später zu löschen ändert daran nichts mehr. Wie eng Cloud-Zugangsdaten und KI-Infrastruktur inzwischen verwoben sind, war zuletzt auch bei der MLflow-Sicherheitslücke CVE-2026-64849 zu sehen.

Was du jetzt konkret tun solltest

Die folgenden Schritte lassen sich mit der AWS CLI in wenigen Minuten abarbeiten. Sie decken genau das Muster ab, das in der Auswertung dominiert.

• Root-Schlüssel aufspüren – ein Befehl genügt. aws iam get-account-summary liefert im Feld AccountAccessKeysPresent eine 1, wenn das Root-Konto einen Zugangsschlüssel besitzt. Steht dort eine 1, gehört der Schlüssel gelöscht, nicht rotiert. Das gilt auch für Testkonten und den privaten Account, den du vor Jahren für ein Wochenendprojekt angelegt hast.
• Credential-Report ziehen statt manuell klicken. aws iam generate-credential-report, danach aws iam get-credential-report – das Ergebnis ist eine CSV über alle Nutzer mit Erstell- und Nutzungsdatum jedes Schlüssels. Sortiert nach access_key_1_last_used_date siehst du in einer Minute, welche Schlüssel seit Monaten nur noch existieren, aber nichts mehr tun. Genau die sind die Kandidaten.
• Eine Altersgrenze festlegen und durchsetzen. Ohne harte Regel passiert nichts. Setze eine Obergrenze (etwa 180 oder 365 Tage), lass sie automatisiert melden und behandle die Ausnahmen einzeln. Wichtig ist nicht der exakte Wert, sondern dass es überhaupt ein Ablaufdatum gibt.
• Kostenwarnung als Frühwarnsystem einrichten. Ein Budget-Alert bei 10 Euro kostet nichts und ist in der Praxis der schnellste Kryptomining-Detektor für ein Cloud-Konto. Über 90 Prozent der auslesbaren Konten in der Auswertung hatten keinen.
• Statische Schlüssel mittelfristig ersetzen. Wo es geht, gehören dauerhafte Keys durch temporäre Anmeldedaten ersetzt: IAM-Rollen für alles, was in AWS läuft, IAM Identity Center oder OIDC-Verbund für Menschen und Build-Pipelines. Ein Zugang, der nach einer Stunde abläuft, kann auch fünf Jahre später in keinem Datensatz mehr schaden.
• Einmal öffentlich heißt kompromittiert. Einen Schlüssel aus einer Datei zu entfernen ist keine Reaktion – er muss deaktiviert und ersetzt werden. Und wenn AWS an einem deiner Nutzer die Quarantäne-Richtlinie hängen hat, ist das keine Warnung, sondern eine Bestätigung.

Wer den Zugang zur AWS-Konsole zusätzlich absichern will, kommt an einer phishing-resistenten zweiten Stufe nicht vorbei – gerade beim Root-Konto, das kein Passwort-Reset über eine kompromittierte Mailbox erlauben sollte. Welche Geräte dafür taugen, habe ich im Ratgeber zu Hardware-Security-Keys mit FIDO2 zusammengestellt.

Einordnung zum Schluss

Die Auswertung ist Herstellerforschung. Truffle Security verkauft Secret-Scanning und hat sie zeitgleich mit einem neuen Produkt veröffentlicht. Das Interesse liegt offen, die Methodik ist beschrieben – ausschließlich lesende Metadaten-Abfragen, keine Policy-Dokumente, kein veröffentlichtes Schlüsselmaterial –, und die Zahlen sind gezählt statt hochgerechnet. Die Prozentangaben zu den Berechtigungen sollte man trotzdem als Richtungswert lesen, was Truffle selbst anmerkt: Auslesbar waren bevorzugt Konten, die IAM lesen dürfen, und das sind überdurchschnittlich oft Admin-Konten.

An der Kernaussage ändert das wenig. Sie lautet nicht „AWS ist unsicher”, sondern: Zugangsdaten haben in vielen Organisationen keinen Besitzer, kein Ablaufdatum und keine Inventur. Das ist ein Prozessproblem, kein Plattformproblem – und damit lösbar, wenn jemand die Verantwortung übernimmt.

Quellen

• Truffle Security: 768 Leaked Corporate AWS Keys Held Full Admin Rights (19.08.2026)
• BleepingComputer: Hundreds of leaked AWS keys give full control over corporate accounts (21.08.2026)