LLMjacking: Gekaperte Cloud-KI kostet einzelne Opfer bis zu eine Million Dollar
Google Threat Intelligence und Mandiant beschreiben am 2. November 2026 Angriffe, bei denen gestohlene Cloud- und API-Schlüssel für fremde KI-Nutzung missbraucht werden. Bei einzelnen Opfern fielen über 100.000 US-Dollar an einem Tag an, bei manchen bis zu einer Million. Admins sollten Ausgabengrenzen, Rechte und Protokolle prüfen.
Die Google Threat Intelligence Group und Mandiant haben am 2. November 2026 einen Bericht zu LLMjacking veröffentlicht. Gemeint ist das Kapern von Unternehmenszugängen zu großen Sprachmodellen in der Cloud. In einzelnen Vorfällen lagen die betrügerischen Kosten bei über 100.000 US-Dollar an einem Tag, bei manchen Organisationen summierten sie sich auf eine Million US-Dollar, bevor der Zugriff gesperrt war.
Betroffen sind Unternehmen, die KI-Dienste wie AWS Bedrock, Azure Cognitive Services oder die Gemini-API nutzen oder eigene Gateways wie LiteLLM und Ollama betreiben. Wer keine Cloud-KI gebucht hat, ist nicht automatisch sicher: Angreifer schalten die Dienste mit gestohlenen Zugängen selbst frei. Budgetgrenzen und Protokollierung lassen sich heute prüfen, ohne Wartungsfenster.
Was ist passiert?
Mandiant hat laut Bericht 2026 mehrere solcher Vorfälle bei Firmen aus Finanzwesen, Handel, Technik und Transport in Nord- und Südamerika sowie im asiatisch-pazifischen Raum untersucht. Google beschreibt eine Arbeitsteilung: Eine Gruppe verschafft sich Zugang, eine andere verkauft ihn weiter. Dafür nutzen die Täter sogenannte LLM-Mixer, Weiterleitungsdienste, die gestohlene Zugänge bündeln und an Abonnenten im Untergrund vermieten.
Ein Beispiel ist der Dienst Jet Night. Ein Akteur setzte laut Google mit gestohlenen API-Schlüsseln in weniger als acht Stunden über 500.000 Anfragen ab, die Kosten von fast einer Million US-Dollar landeten beim Opfer. Die Gruppe UNC6993 übernahm Mitte 2026 eine Cloud-Instanz über einen falsch konfigurierten Dienstkontoschlüssel und häufte über 100.000 US-Dollar an Gebühren an.
Wie kommen die Angreifer hinein?
Der häufigste Weg sind laut Google offengelegte oder gestohlene Cloud-Zugänge: IAM-Schlüssel, Dienstkontoschlüssel, persönliche GitHub-Token und aktive Sitzungstoken. API-Schlüssel sammelte ein Akteur auch aus öffentlichen GitHub-Repositories und testen sie mit Anfragen von nur einem Token, die in Volumen-Alarmen untergehen. Offen erreichbare Ollama-Server nutzten Angreifer, um dort eigene Modelle anzulegen und zu betreiben.
Nach dem Einstieg suchen die Täter in Repositories, Logs und Secret-Managern nach weiteren Zugangsdaten. Für dauerhaften Zugriff legen sie Dienstkonten an, die sich teils als interne Abrechnungswerkzeuge tarnen, oder hinterlegen SSH-Schlüssel in den Metadaten von Instanzen.
In einem Fall nutzte ein Akteur eine Lücke in einem LiteLLM-Gateway, um einfache Schlüssel zu vollen Administratorrechten auszubauen. Google nennt dafür CVE-2026-40217 und einen Fehler im Endpunkt /key/regenerate. Das GitHub-Advisory unter dieser Nummer beschreibt dagegen einen Ausbruch aus der Sandbox für eigene Guardrail-Prüfungen Es führt 1.83.10 als erste korrigierte Version, im Beschreibungstext ist von 1.83.11 die Rede, und für den Endpunkt sind dort bereits Proxy-Admin-Rechte nötig. Die beiden Beschreibungen passen nicht zusammen. Sicher ist, dass ungepatchte Gateways ein Ziel sind und LiteLLM mindestens auf 1.83.11 gehört.
Was sollten Admins jetzt tun?
- Inventar: alle Cloud-Konten, Projekte und selbst betriebenen Gateways mit KI-Zugriff erfassen, auch Testumgebungen und vergessene Ollama-Instanzen.
- Kosten begrenzen: Quoten je Modell und Ausgabengrenzen setzen, Budgetwarnungen an ein überwachtes Postfach schicken.
- Rechte: KI-Dienste nur für Konten erlauben, die sie brauchen. Google empfiehlt, alles zu verweigern, was nicht ausdrücklich nötig ist.
- Protokolle: das Freischalten von KI-Diensten als kritisches Ereignis alarmieren, bei AWS etwa PutUseCaseForModelAccess und CreateFoundationModelAgreement. Versuche, die Modellprotokollierung außerhalb der Infrastructure-as-Code-Konten abzuschalten, sollen laut Google mit hoher Priorität behandelt werden. Bei Google Cloud sind die Data-Access-Logs für Inferenz standardmäßig aus und müssen eingeschaltet werden.
- Schlüssel: Secret-Scanning in Repositories einrichten, Schlüssel zentral verwalten und regelmäßig erneuern, Gateways wie LiteLLM aktuell halten.
- Anmeldung: phishingresistente MFA für Cloud-Konsolen, Identitätsanbieter und Entwicklerplattformen erzwingen.
Einordnung für Unternehmen
Der sichtbarste Schaden beim LLMjacking ist die Rechnung, laut Google greifen die Täter aber auch Zugangsdaten und Daten ab. Weil die Anfragen über echte Zugänge laufen, verbucht der Cloud-Anbieter sie als normalen Verbrauch. Für kleinere Firmen mit einem einzelnen Cloud-Konto ohne Ausgabengrenze kann schon ein Wochenende teuer werden. Budgetalarme sind deshalb die wichtigste Sofortmaßnahme, auch wenn sie den Angriff nicht verhindern.
Passende Anleitungen auf S-EDV
- LiteLLM mit Docker installieren: Selbstgehosteter KI-Gateway für 100+ LLM-Provider
- LiteLLM-Gateways offen im Netz: Fast jedes zehnte akzeptiert sk-1234
