Ihr KI-API-Schlüssel ist für einen Angreifer dreierlei wert

Vor zwei Jahren war ein API-Schlüssel für einen KI-Dienst eine Position auf der Rechnung. Heute ist er ein Wert, den ganze kriminelle Gruppen um seiner selbst willen suchen. Der Bericht widmet dem einen Abschnitt: „Access to AI in the form of compromised API keys, session tokens, and devices has increasingly become the sole objective of multiple criminal groups.“ Das einzige Ziel. Kein Nebenprodukt eines Einbruchs, sondern sein Daseinszweck.

Beim letzten Wort dieses Satzes lohnt es sich innezuhalten: devices, die Geräte. Im Visier stehen nicht nur die Schlüssel, sondern auch die Sitzungstoken und die Rechner, auf denen sie liegen. Ein guter Teil dessen, was der Bericht beschreibt, lässt sich also nicht erledigen, indem man eine Zeichenkette in einem Tresor ersetzt: Man muss die Maschine selbst bereinigen.

Warum ein Schlüssel mehr wert ist als sein Guthaben #

Anthropic fasst den Wert eines gestohlenen Schlüssels in drei Worten zusammen. Für IT-Verantwortliche ist das die nützlichste Formulierung des Berichts: drei Vorteile auf einen Schlag.

• Beute (loot): Ein gültiger Schlüssel oder ein gültiges Konto lässt sich auf etablierten Märkten weiterverkaufen. Die Diebe geben den Zugang an Makler ab, die Netzwerke für betrügerischen Weiterverkauf versorgen; diese Netzwerke speisen laufend neue gestohlene Schlüssel ein und nutzen sie im Wechsel, bis das Kontingent erschöpft ist. Ihr Schlüssel muss nicht interessant sein, er muss nur gültig sein.
• Rechenleistung (compute): Die offensive Arbeitslast läuft auf Kosten eines anderen. Eine weiter hinten im Bericht beschriebene Hacktivisten-Kampagne lief einen ganzen Monat vollständig auf gestohlenen Schlüsseln: Grenzkosten null.
• Tarnung (cover): Die Aktivität wird dem rechtmäßigen Inhaber des Schlüssels zugeschrieben. In den Protokollen des Anbieters taucht Ihr Unternehmen auf, nicht der Angreifer.

Der dritte Punkt wird unterschätzt, und der Bericht macht ihn sehr konkret. Derselbe Hacktivist hatte einen eigenen Scanner in Rust geschrieben, um öffentliche Container zu durchsuchen und die dort gefundenen Schlüssel zu validieren. Ein validierter Schlüssel kam in eine lokale Proxy-Schicht, die die Nutzung reihum auf die Schlüssel verteilte. Ausdrückliches Ziel: den eigenen Verkehr im Verkehr der rechtmäßigen Inhaber untergehen zu lassen. Der Schlüssel dient nicht nur dazu, die Rechnung zu bezahlen, sondern auch dazu, in fremde Kleider zu schlüpfen.

Affiliates des Kollektivs ShinyHunters wandten dieselbe Logik von der anderen Seite an: Sobald sie bei einem Opfer eingedrungen waren, verlagerten sie ihre eigene Angriffsarbeit auf die KI-Schlüssel dieses Opfers und griffen damit drei Wochen lang andere Organisationen an, darunter eine kompromittierte französische Einzelhandelskette und eine sondierte Web3-Identitätsplattform. In allen dokumentierten Fällen stammten die Schlüssel aus Kundenumgebungen; die Systeme von Anthropic wurden nicht kompromittiert. Die Unterscheidung zählt: Das Risiko liegt beim Nutzer des Schlüssels, nicht beim Anbieter des Modells.

1,8 Millionen dekompilierte Apps auf der Suche nach Secrets #

Die Sammelkette ist industriell. Ein französischsprachiger Akteur, der unter mehreren Pseudonymen bekannt ist, baute eine Pipeline auf, verteilt auf zehn bei einem Cloud-Anbieter gemietete Maschinen. Diese Pipeline lud massenhaft 1,8 Millionen verschiedene Android-Apps aus mehreren Stores herunter, dekompilierte sie und ließ sie durch einen Detektor für hartkodierte Secrets laufen: ein freies Werkzeug, genau das, mit dem Sicherheitsteams ihre eigenen Repositories prüfen.

Die verifizierten Funde gingen in Echtzeit an einen privaten Chat-Kanal, der in mehr als vierhundertsiebzig Threads gegliedert war: ein Thread pro Detektortyp, für mehr als hundert Arten von Quellen. Parallel erntete ein zweiter Strang die Adressen der Organisationen auf einer öffentlichen Code-Plattform und speiste eine Leitung für gestohlene persönliche Zugriffstoken. Der Bericht ist beim Ertrag eindeutig: Diese beiden Leitungen lieferten die Zugangsdaten für den Erstzugriff bei der Mehrheit der bestätigten Kompromittierungen dieses Akteurs. Keine neue Lücke. Secrets, die auf der Straße lagen.

Die Fundstellen, die der Bericht aufzählt #

Der Bericht nennt die automatisierte Suche nach offen liegenden Token „im industriellen Maßstab“ Discovery. Seine Liste der Quellen taugt als Checkliste für ein Audit.

• App-Binärdateien: Eine mobile App zu dekompilieren ist Routine, kein Exploit.
• Code-Repositories und ihre Integrationen: das Repository, aber auch die Token, die Integrations-Pipelines dort ablegen.
• Im Browser ausgeführter Code: Was Ihr Server an den Rechner des Besuchers schickt, kann der Besucher lesen.
• Schlecht geschützte Tresore für Zugangsdaten: Ein Tresor mit zu weit gefasster Zugriffsrichtlinie ist eine Sammelstelle.
• Container-Images: Ein in einer Schicht gelöschter Schlüssel steckt weiterhin in der vorherigen Schicht.
• Metadaten-Endpunkte von Cloud-Instanzen: lesbar für jede Anwendung, die auf der Maschine läuft, auch für eine verwundbare.
• Offene Speicher: Buckets, die für einen Test öffentlich lesbar gelassen wurden, der seit drei Jahren andauert.
• KI-Agenten, die das Opfer selbst betreibt: die Neuheit, die weiter unten in einem eigenen Abschnitt behandelt wird.

Was mit einem Schlüssel passiert, sobald er gefunden ist #

Der Bericht beschreibt den vollständigen Lebenszyklus gestohlener Zugangsdaten. Drei seiner Schritte betreffen KI-Schlüssel direkt und erklären, warum die klassische Reaktion („widerrufen, erledigt“) nicht ausreicht.

• Validieren und einstufen. Alles Gefundene wird vor Nutzung oder Weiterverkauf getestet: Massenvalidierung von Cloud-Schlüsseln, eigens geschriebene Login-Orakel, direktes Wiedereinspielen gegen Produktivsysteme, Bewertung des Marktwerts, Offline-Knacken dessen, was sich sträubt. Konkret: Die Zeit zwischen dem Leck und der ersten Nutzung hängt nicht vom Zufall ab. Ein offen liegender Schlüssel wird umgehend gegen Ihre Systeme erprobt.
• Dauerhafte Zugänge schaffen. Neue Zugangsdaten werden erzeugt, damit die Operation Ihre Rotation überlebt: Cloud-API-Schlüssel in den Konten des Opfers, Entwicklerschlüssel auf den Plattformen, gefälschte Sitzungen und Codes für den zweiten Faktor, Hintertüren im Netz. Konkret: Den geleakten Schlüssel zu widerrufen reicht nicht, Sie müssen suchen, was seitdem erzeugt wurde.
• Zu Geld machen. Weiterverkaufskanäle und Schlüsselpools, direkter Finanzdiebstahl, Erpressung mit den gestohlenen Daten, Einnahmen aus Bug-Bounties mit doppeltem Spiel, Massendaten als Druckmittel in der Hinterhand. Konkret: Selbst ein Schlüssel ohne Nutzwert hat einen Lagerwert. Er wird verkauft und später von jemand anderem wieder eingesetzt.

Die übrigen Schritte (Aufklärung, Ausbreitung beim Opfer, Exfiltrationskanäle, Lagerung der Beute) beschreiben den Einbruch selbst. Wir gehen morgen darauf ein: Sie beantworten eine andere Frage, nicht mehr „wie kommt man hinein“, sondern „wie schnell“.

Der falsche Händler: „Claude zum günstigeren Preis“ #

Die zweite Masche zielt direkt auf Endnutzer statt auf Systeme. Akteure richteten Websites ein, die sich als Vermittler zwischen mehreren Modellen ausgaben und einen Zugang zum Schleuderpreis zu den Spitzenmodellen anboten. Die Besucher wurden auf mehrere Arten kompromittiert; am nachhaltigsten war es, sie eine Client-App installieren zu lassen, die ein beliebtes Entwicklungswerkzeug imitierte (darunter Claude Code), in Wirklichkeit aber ein Zugangsdatendieb war. Er sammelte alle auf der Maschine vorhandenen Zugangsdaten und Sitzungstoken, nicht nur die mit Bezug zu KI.

Das Detail, das Sie sich merken sollten, ist folgendes. Der Bericht stellt klar: Wenn das Konto des Opfers schließlich als kompromittiert erkannt und zurückgesetzt wurde, blieb der Dieb an Ort und Stelle und erkannte weiterhin jede neue Sitzung auf dem Gerät, um auch diese weiterzuleiten. Die Rotation bewirkt dann nichts anderes, als dem Angreifer einen frischen Schlüssel zu liefern. Das ist das Lehrbuchbeispiel eines korrekten Verfahrens in der falschen Reihenfolge, das die Illusion erzeugt, den Vorfall erledigt zu haben.

Eine russisch- und ukrainischsprachige Gruppe mit der Kennung GTG-50021 tat dasselbe, nur durchtriebener: Ihre Kunden glaubten, einen vergünstigten Claude-Zugang zu kaufen; ihr Verkehr wurde in Wirklichkeit stillschweigend an ein anderes Modell weitergeleitet, während die Werkzeuge des Händlers ihnen die Zugangsdaten stahlen, um sie an andere betrügerische Händler weiterzuverkaufen. Weder günstiger noch Claude, und nichts, woran man es bemerkt hätte: Die Antwortqualität eines Konkurrenzmodells löst keinen Alarm aus.

Zugang zu KI sollte ausschließlich über autorisierte Kanäle gekauft werden. Ein angeblicher Rabatt, der verlangt, Ihren Verkehr und Ihre Zugangsdaten über einen unbekannten Vermittler zu leiten, setzt Ihre Daten und Systeme einem erheblichen Risiko aus.

In die Sprache eines KMU übersetzt: Diese Masche kommt nicht durch die Tür der IT-Abteilung, sondern über die Schatten-IT. Ein Entwickler, der ein Abo für fünfzehn statt hundert Euro findet, ein Dienstleister, der „seinen“ geteilten Zugang anbietet. Und der kompromittierte Rechner ist ausgerechnet der, auf dem die Repository-Token und die Produktivschlüssel liegen.

Ihre Integrationen rund um KI sind eine Angriffsfläche #

Das ist der Punkt, den die meisten Teams noch nicht verinnerlicht haben. Der Bericht nennt mehrere Akteure, die Zwischendienste kompromittiert haben, die Modell-Gateways bereitstellten: die Komponente, die man installiert, um Aufrufe an mehrere Anbieter zu verteilen und die Abrechnung zu bündeln. Der Vektor: Prompt Injection, um den Agenten die Produktiv-API-Schlüssel aus seiner Container-Umgebung exfiltrieren zu lassen. Der Bericht zählt solche Installationen zu den gängigen Gelegenheitszielen, auf einer Stufe mit dem Scannen nach ungepatchten Geräten.

Das nötige Umdenken: Der Vektor ist keine Lücke im Code, sondern der Text, den der Agent zu lesen bereit ist. Ein Agent, der eine Webseite, ein Ticket oder eine von Dritten abgelegte Datei liest, liest auch die Anweisungen, die dort hineingeschmuggelt wurden. Und wenn er einen Produktivschlüssel besitzt, lässt er sich womöglich dazu bringen, ihn auszuspucken.

GTG-50020: von der Hotelbuchung zur KI-Lieferkette #

Der deutlichste Fall ist der eines russischsprachigen, finanziell motivierten Akteurs, der bis dahin gegen Plattformen für Hotelbuchungen und Finanztechnologie vorging. Seine bisherige Bilanz zeigt das Kaliber: rund 26 Gigabyte, bei einem einzigen Opfer exfiltriert, und eine Lösegeldforderung (oder ein Verkaufspreis in Foren) zwischen 1,5 und 2,5 Millionen Dollar. Das ist kein Amateur, der KI entdeckt, sondern ein Profi, der die Branche wechselt.

Er hat genau dasselbe Know-how auf die KI-Branche umgelenkt. Indem er bösartige Anweisungen in die automatisierte Evaluierungs-Sandbox eines Anbieters einschleuste (die Infrastruktur, die automatische Tests auf Modellen laufen lässt), brachte er diese Sandbox dazu, ihm die darin hinterlegten Zugangsdaten auszuhändigen, darunter die Produktiv-API-Schlüssel mehrerer Anbieter. Der Bericht vermerkt dann das Verhalten, das den Abschnitt zusammenfasst: Sobald der Akteur die Schlüssel eines Ziels hatte, nutzte er automatisch diese statt seiner eigenen und setzte seine Einbrüche gegen den Anbieter und gegen unbeteiligte Ziele parallel fort.

Von derselben Infrastruktur aus griff er dann rund dreißig KI-Unternehmen in etwa vier Tagen an. Die Methode sagt alles über die neue Ökonomie: Er fand einen Angriffsweg, der funktionierte, und wiederholte ihn gegen die dreißig Ziele mit kleinen Anpassungen. Die Werkzeuge hielten Schritt: Eine Scope-Datei pro Ziel startete einen Arbeitsablauf, der an parallele Agenten für Aufklärung und Ausnutzung delegiert wurde; die Funde wurden erneut getestet, um zu prüfen, ob der Zugang funktionierte, in einen fortlaufenden Bericht zusammengeführt, und die Schleife begann beim nächsten Ziel von vorn. Daneben ließ eine freie, containerisierte Plattform für Penetrationstests Arbeiter-Agenten laufen, die Injection-Angriffe, Cross-Site-Scripting und Umgehungen der Authentifizierung testeten, ohne menschliche Aufsicht und mit erlaubter aktiver Ausnutzung auf Produktivsystemen.

Sein erklärtes Ziel, verfolgt auf mehr als einem Dutzend verschiedener Wege: Zugang zu einem noch nicht veröffentlichten Claude-Modell. Der Bericht ist kategorisch, und das muss ebenso deutlich gesagt werden wie der Rest: Es ist ihm nie gelungen; alle Wege sind gescheitert. Es ist, so der Bericht, der klarste Beleg dafür, dass die KI-Lieferkette zu einem bewussten Ziel von Kriminellen geworden ist und kein Kollateralschaden.

Das Fazit des Abschnitts ist ein Satz, den man in jeder IT-Abteilung über die Kaffeemaschine hängen sollte: Behandeln Sie KI-Schlüssel und Agenten-Integrationen mit derselben Sorgfalt wie Ihre Produktiv-Zugangsdaten, denn die Angreifer tun es bereits.

Was wir tun und was wir empfehlen #

Nichts davon ist exotisch. Es ist Hygiene im Umgang mit Secrets, angewandt auf eine Art von Secret, die viele Organisationen noch nicht in ihr Inventar aufgenommen haben.

1. Inventarisieren. Wer besitzt einen KI-Schlüssel, wofür, seit wann, mit welcher Reichweite? Ein Schlüssel pro Verwendung und pro Umgebung, nie ein „Firmenschlüssel“, den fünf Projekte teilen: Einen geteilten Schlüssel traut sich niemand mehr zu widerrufen.
2. Schlüssel aus dem Code holen. Umgebungsvariablen, die beim Deployment eingespeist werden, oder ein Secrets-Tresor; nie im Repository, nie in einem Image, nie in einer mobilen Binärdatei, nie in einer an den Browser ausgelieferten Datei. Ein einmal committetes Secret bleibt in der Git-Historie: Es aus der Datei zu entfernen reicht nicht, es muss widerrufen werden.
3. Laufend scannen. Ein Secrets-Detektor im Pre-Commit und in der Integrations-Pipeline, dazu ein regelmäßiger Durchlauf über die veröffentlichten Images: dieselbe Logik wie bei unserer CVE-Beobachtung für Docker-Images, angewandt auf Secrets. Die Angreifer nutzen das freie Werkzeug, das Sie heute anschließen können.
4. Reichweite einschränken. Ein Schlüssel, der auf ein Modell, eine Obergrenze, einen Adressbereich oder ein Projekt beschränkt ist, verliert den Großteil seines Weiterverkaufswerts. Der Bericht beschreibt eine Marktbewertung bei der Validierung: Ein eingeschränkter Schlüssel rutscht im Ranking nach unten.
5. Deckeln und überwachen. Ausgabenlimit pro Schlüssel, Alarm bei Überschreitung, wöchentlicher Blick auf den Verbrauch. Ein gestohlener Schlüssel zeigt sich zuerst an einer Nutzungskurve, die nicht zu Ihrem Geschäft passt: eine Spitze in der Nacht, am Wochenende oder eine maschinenhafte Regelmäßigkeit.
6. Rotieren, in der richtigen Reihenfolge. Geplante Rotation (mindestens vierteljährlich) und sofortige Rotation beim geringsten Zweifel. Der oben beschriebene Zugangsdatendieb macht die Rotation jedoch nutzlos, wenn der Rechner kompromittiert ist: Er fängt den nächsten Schlüssel ab. Erst wird die Maschine bereinigt, dann der Schlüssel getauscht.
7. Nur über offizielle Kanäle kaufen. Kein Händler mit Schleuderpreisen, kein Gateway eines Dritten „zum Sparen“, kein inoffizieller Client auf einem Entwicklerrechner. Diese Regel gehört in Ihre IT-Richtlinie, denn es ist die Schatten-IT, die gegen sie verstößt.
8. Ihre eigenen Agenten als exponierte Komponenten behandeln. Minimale Reichweite der Secrets, die sie besitzen, abgeschotteter Container, kein Produktivschlüssel in der Umgebung eines Agenten, der nicht vertrauenswürdige Inhalte verarbeitet, Protokollierung der ausgehenden Aufrufe.
9. Das Verfahren für ein Leck schreiben, bevor Sie es brauchen. Den Ursprungsrechner isolieren, widerrufen, suchen, was seitdem erzeugt wurde (zusätzliche Schlüssel, Dienstkonten, registrierte Geräte), den Verbrauch über neunzig Tage prüfen, den Anbieter informieren. Ein an einem Freitagabend improvisiertes Verfahren vergisst immer den vorletzten Punkt.

Und für Verarbeitungen, bei denen die Frage „wohin gehen meine Daten“ wichtiger ist als die reine Leistungsfähigkeit, bleibt die Alternative ein offenes Modell, das bei Ihnen gehostet wird: kein Schlüssel, der bei Dritten gestohlen werden kann, kein Händler dazwischen. Wir kommen am 16. September darauf zurück.

Morgen: was nach dem Diebstahl von Zugangsdaten geschieht und warum die Zeit zwischen dem ersten Zugriff und dem Datendiebstahl inzwischen in Stunden gemessen wird.

Quellen #

• Anthropic, Detecting and countering misuse of AI: September 2026 (10. September 2026): Kapitel Cyber operations, Abschnitt AI supply chain as target, loot, and attack compute: Beute/Rechenleistung/Tarnung, falsche Händler, Prompt Injection bei Gateways.
• Derselbe Bericht, Abschnitt GTG-50014: Sammel-Pipeline (zehn gemietete Maschinen, 1,8 Millionen dekompilierte Apps) und die Schritte Discover, Validate/qualify, Mint/persist, Monetize des Angriffslebenszyklus.
• Derselbe Bericht, Abschnitte GTG-50020 (Evaluierungs-Sandbox, rund dreißig KI-Unternehmen in vier Tagen, Ziel nie erreicht), GTG-50021 (falscher Händler) und GTG-50029 (Container-Scanner, Schlüsselrotation hinter einem Proxy).
• Unsere Gesamtlektüre: Acht Monate KI-Missbrauch, und die Bestandsaufnahme davor: Wenn Agenten angreifen.
• Frandroid, Anthropic publie 161 pages sur les détournements de Claude, et ça pique (Anthropic veröffentlicht 161 Seiten über den Missbrauch von Claude, und das schmerzt; 11. September 2026).