Ihr gestohlener API Key muss nur zehn Minuten funktionieren

Der Satz aus dem Black October, der mir hängen geblieben ist, hatte nichts mit PHP zu tun. Er kam von Railway, der Hosting-Plattform, die am 21. Oktober bekannt gab, dass ein Eindringling möglicherweise die verschlüsselten Umgebungsvariablen ihrer Kunden gelesen und bei einigen davon den Inhalt entschlüsselt hatte. Railway beschrieb den Vorfall als Teil einer Serie von Angriffen auf Plattformanbieter, die darauf abzielen, KI-Inferenzanbieter zu kompromittieren.

Am selben Vormittag kaperte jemand die Release-Pipeline von LiteLLM und schob einen Build mit eingebautem Credential Stealer auf PyPI. LiteLLM ist die Gateway-Bibliothek zwischen Anwendungen und Modellanbietern, sie verwaltet also die Keys für alle. Eine Woche davor hatte Zeabur 3,2 Millionen Datensätze mit Umgebungsvariablen verloren und seine Schließung angekündigt.

Die Angreifer waren also hinter Keys her. Aber warum? Ein geleakter Key wird gesperrt, sobald es jemand bemerkt. Warum baut man eine ganze Operation um etwas, das ein paar Stunden hält?

Der Missbrauch beginnt nach Minuten, die Erkennung wartet auf die Rechnung

Der Einwand geht davon aus, dass die Uhr mit dem Leak zu laufen beginnt. In der Praxis beginnt sie aber erst, wenn es jemand bemerkt, und in der Lücke zwischen diesen beiden Momenten wird das Geld verdient.

Honeypot-Experimente beziffern das erste Intervall in Minuten. Comparitech legte AWS-Zugangsdaten auf GitHub aus und zählte innerhalb einer Minute mehr als 1.000 API-Aufrufe damit; der gesamte Angriff war in weniger als vier Minuten vorbei. In einem anderen Experiment kam der erste Missbrauch nach 11 Minuten. Beide Tests verwendeten Cloud-Zugangsdaten statt LLM-Keys, aber den Scannern ist das egal. Sie probieren alles, was sie finden, bei jedem Anbieter aus, den sie kennen.

Die Sperre dagegen wartet auf die Erkennung, und die meisten Teams entdecken einen gestohlenen Key, wenn die Rechnung kommt. Sysdig, das 2024 den Begriff LLMjacking geprägt hat, hat berechnet, dass ein einziger gekaperter Account, der ein Frontier-Modell mit voller Quota betreibt, seinen Besitzer mehr als 46.000 Dollar pro Tag kosten kann (Herstellerstudie; die Zahl skaliert mit den Modellpreisen). Einen Key ein paar Stunden nach der Entdeckung zu sperren, gilt in den meisten Organisationen als schnell. Bei diesem Tempo kostet es trotzdem Tausende.

Für den Weiterverkauf reichen ein paar Stunden

Der Wiederverkaufsmarkt hat die kurze Lebensdauer eingepreist. Ein gestohlener Key ist so lange etwas wert, wie man ihn prüfen, einsortieren und verkaufen kann, bevor sein Besitzer nachsieht, und das dauert weit weniger lang, als die meisten Besitzer zum Nachsehen brauchen.

Die Werkzeuge dafür sind alt. Im ersten dokumentierten Fall fand Sysdig ein Skript, das gestohlene Zugangsdaten gegen zehn KI-Dienste testete. Es tastete gerade so viel ab, dass klar war, welche Modelle mit den jeweiligen Zugangsdaten erreichbar waren und wie viel Quota zur Verfügung stand, ohne einen einzigen echten Prompt auszuführen. Die Angreifer prüften außerdem, ob Prompt Logging aktiviert war, und der Reverse Proxy, über den sie den Zugang weiterverkauften, überspringt jeden Key, bei dem das der Fall ist.

Heuer hat das Geschäft eine eigene Lieferkette. Die Honeypots von Pillar Security protokollierten zwischen Dezember 2025 und Jänner 2026 35.000 Angriffssessions einer einzigen Kampagne, die Pillar Operation Bizarre Bazaar taufte. Scanner finden offene KI-Endpunkte, ein Validator testet sie zwei bis acht Stunden, nachdem sie in öffentlichen Scan-Ergebnissen auftauchen, und ein Shop verkauft Zugang zu mehr als 30 LLM-Anbietern um 40 bis 60 Prozent unter Listenpreis weiter (Herstellerstudie). Einzelne Keys werden angeblich schon um 30 Dollar verkauft (einzelne Quelle). Bei solchen Margen hat sich ein Key, der zwei Stunden funktioniert, um ein Vielfaches bezahlt gemacht.

Gestohlene Inferenz betreibt jetzt die Angriffe

Mehr Sorgen macht mir die neuere Entwicklung. Am 12. Juni ertappte Sysdig einen Angreifer, der einen Ollama-Server ohne Authentifizierung nicht zum Weiterverkauf nutzte, sondern als Reasoning-Engine einer mehrstufigen Angriffspipeline. Die Pipeline betrieb Aufklärung, ordnete Dienste bekannten Schwachstellen zu, schrieb Proof-of-Concept-Exploits und versuchte, sie auszuführen, wobei das Modell jeden nächsten Schritt selbst wählte. Im Beobachtungszeitraum traf sie nur private Adressen und Penetration-Testing-Labs, das Werkzeug war also noch in Entwicklung. Das Design war aber fertig.

Cairn vermittelt einen Eindruck davon, was eine fertige Version im Betrieb kostet. Ein Forscher von NorForge beobachtete, wie ein chinesischsprachiger Akteur eine Einbruchskampagne an KI-Agenten auf Cairn übergab, einer Open-Source-Agent-Plattform, und damit in mehr als 100 Unternehmenswebsites eindrang, um rund 50 Dollar an Token pro Erfolg. Nichts in der Berichterstattung deutet darauf hin, dass diese Token gestohlen waren, und das Argument braucht das auch nicht. Sobald Einbrüche als Inferenz-Workload laufen, wird Inferenz zum größten Kostenfaktor im Betrieb, und gestohlene Keys drücken diese Kosten auf null.

Gestohlene Keys verschieben auch die Folgen. Läuft ein Angriff über fremden Zugang, sieht der Anbieter das Konto des Opfers bei der Arbeit. Die Rechnung und eine etwaige Sperre landen also beim Besitzer des Keys.

Ein Key öffnet mehr als Token

Das Inferenzbudget ist das offensichtliche Beutegut, aber ein Anbieter-Key reicht auch an alles heran, was im Account liegt: hochgeladene Dateien, feinabgestimmte Modelle, Batch-Ergebnisse, Gesprächsverläufe. Pillar zählt Exfiltration aus Kontextfenstern und Gesprächsverläufen zu den Zielen der Kampagnen, die es beobachtet hat. Schon die Usage-Seite zeigt, welche Modelle ein Unternehmen wie intensiv nutzt, und das verrät einiges darüber, woran es arbeitet.

Trainingsdaten sind ein weiteres Motiv. Sysdig nannte schon im ersten Bericht das Extrahieren von LLM-Trainingsdaten als möglichen Grund, und diesen Monat beschrieben Forscher einen Einbruch bei OpenCode als Credential-Diebstahl für Distillation. Distillation braucht einen synthetischen Korpus, der mit Frontier-Modellen erzeugt wird, und das bedeutet enorme Token-Mengen. Die Last auf Tausende gestohlene Keys zu verteilen, ist billiger, als dafür zu bezahlen, und schwerer zu entdecken als eine Flotte gefälschter Accounts. Ein plausibles Motiv, auch wenn es noch niemand in großem Maßstab dokumentiert hat.

Zwei weitere Verwendungen ergeben sich aus der Funktionsweise der Accounts, auch wenn ich keinen Fall gefunden habe, in dem eine davon das Hauptmotiv war. Sysdig wies darauf hin, dass das Ausreizen der Quota eines gestohlenen Accounts den Besitzer von den Modellen aussperrt. Key-Diebstahl kann also als Denial-of-Service-Angriff auf jedes Produkt funktionieren, das auf diesem Key aufbaut. Und weil Anbieter ihre Nutzungsrichtlinien pro Organisation durchsetzen, könnten verbotene Inhalte, die über den Key eines Opfers laufen, dazu führen, dass diese Organisation gesperrt wird.

Agenten erhöhen den Einsatz. Ein Agent mit eigenem Key ist selbst ein Ziel, und mit einem gestohlenen Agent-Key kann man sich als der Agent ausgeben, mit allen Berechtigungen, die der Agent hat.

Keys leaken heute über Abhängigkeiten und Plattformen

Die bekannte Geschichte ist die vom Entwickler, der einen Key in ein öffentliches Repository committet. Das passiert immer noch, aber die Vorfälle dieses Jahres kamen großteils von woanders.

Ein Weg ist die Supply Chain. LiteLLM wurde innerhalb von sieben Monaten zweimal vergiftet: Im März veröffentlichte eine kriminelle Gruppe zwei bösartige Releases, die etwa 40 Minuten online blieben, und im Oktober lieferte die projekteigene Release-Pipeline den Stealer aus. Eine Gateway-Bibliothek sammelt Zugangsdaten per Design, also übergibt eine einzige verseuchte Installation jeden Anbieter-Key, den eine Organisation verwendet. Entwicklerwerkzeuge sind ein weiterer Weg. Mindestens 15 Plugins im JetBrains Marketplace taten, was sie versprachen, und schickten nebenbei still und leise die eingegebenen KI-Keys an einen Angreifer.

Hosting-Plattformen sind der dritte. Railway und Zeabur verwahrten Kunden-Secrets aus Bequemlichkeit und verloren sie gleich massenweise; Zeaburs Angreifer kam über ein nie ablaufendes Admin-Token, das im Klartext gespeichert war, hinein. Eigene Modelle zu betreiben, hilft da auch nicht. Rund 175.000 Ollama-Instanzen antworten ohne Authentifizierung im offenen Internet, und eine im Mai veröffentlichte Schwachstelle erlaubt einem nicht authentifizierten Angreifer, mit drei API-Aufrufen API Keys und Gesprächsdaten aus dem Speicher eines ungepatchten Servers auszulesen.

Messen Sie jeden Key an seiner eigenen Geschichte

Wenn der Missbrauch Minuten nach einem Leak beginnt, wird Prävention manchmal versagen, und dann zählt, wie schnell Sie merken, dass Ihr Key für jemand anderen arbeitet. Die Anbieter stellen die Daten bereits zur Verfügung. Die Admin API von Anthropic liefert den Token-Verbrauch nach API Key und Modell gruppiert in stündlichen Intervallen, und die Usage API für Organisationen von OpenAI schlüsselt den Verbrauch nach Key, Projekt und Modell auf. Die meisten Teams sehen sich diese Zahlen erst an, wenn die Rechnung sie dazu zwingt.

Die Warnsignale sind konkret. Ein Key, der monatelang gleichmäßig gelaufen ist, verdreifacht plötzlich seinen Verbrauch. Ein Key, der immer nur ein kleines Modell aufgerufen hat, ruft auf einmal das teuerste auf, oder ein Key hinter einem internen Tool, das während der Bürozeiten genutzt wird, schickt um drei Uhr früh Traffic. Ein Detail aus Sysdigs erstem Bericht taugt auch als Ratschlag: Der dort gefundene Reverse Proxy lehnt AWS-Keys ab, bei denen Bedrock Prompt Logging aktiviert ist. Wer Logging einschaltet, bekommt Material für die Forensik und macht den Key für Diebe weniger attraktiv.

Was ich diese Woche umsetzen würde:

1. Ein Key pro Anwendung und Umgebung, damit jede Baseline zu genau einem Workload gehört.
2. Ein hartes Ausgabenlimit und ein Rate Limit für jeden Key oder jedes Projekt, knapp über der legitimen Spitzenlast.
3. Key-Monitoring: Volumen im Vergleich zur Baseline, erstmals genutzte Modelle, Traffic außerhalb der üblichen Zeiten.
4. Prompt Logging einschalten, wo immer der Anbieter es anbietet.
5. Ein Gateway, das den echten Anbieter-Key hält, damit Anwendungen stattdessen nur kurzlebige Token mitführen.
6. Canary Keys in Repositories, CI-Konfiguration und Container-Images, bei denen jeder Aufruf ein Sicherheitsvorfall ist.
7. Eine geprobte Rotation mit Zeitmessung, damit Sie wissen, wie lange eine Sperre dauert, bevor Sie sie brauchen.
8. Fixierte Versionen für jede Abhängigkeit, die mit Keys zu tun hat, und ein Audit der IDE-Plugins.

Inferenz hat keine Obergrenze, außer Sie bauen eine ein

Ich rechne damit, dass das schwieriger wird. Vor einem Jahr war ein LLM-Key vor allem ein Zugang zur Abrechnung. Immer öfter ist er die Identität eines Agenten, der entscheidet, Tools aufruft und mit den Berechtigungen, die man ihm gegeben hat, auf Systeme zugreift. Wer diesen Key stiehlt, bekommt die Token und dazu einen funktionierenden Kollegen, der jetzt seine Anweisungen befolgt.

Ein gestohlenes Datenbankpasswort ist durch den Inhalt der Datenbank begrenzt. Ein gestohlener Inferenz-Key nur durch seine Quota und das Ausgabenlimit, das sein Besitzer gesetzt hat, und in den meisten Accounts hat niemand eines gesetzt. Angreifer betreiben bereits Pipelines, die aus zehn Minuten Zugang Profit machen, während die meisten von uns es immer noch über die Rechnung erfahren.

Aus dem Englischen übersetzt: zum Originalbeitrag