Gestohlene LLM-Zugänge werden zum Kostenrisiko
Google Mandiant und die Google Threat Intelligence Group warnen vor einer deutlichen Zunahme des sogenannten LLMJacking. Dabei übernehmen Angreifer API-Schlüssel oder Cloud-Zugänge von Unternehmen und nutzen deren Kontingente für rechenintensive Anfragen an kommerzielle Sprachmodelle.
Die Folgen sind nicht nur technischer Natur. Bei dynamisch abgerechneten Cloud-APIs können innerhalb weniger Stunden erhebliche Kosten entstehen. Dokumentierte Fälle erreichten mehr als 100.000 US-Dollar pro Tag und kumulierte Rechnungen von bis zu 1 Million US-Dollar, bevor der Zugriff gesperrt wurde.
| Kennzahl | Dokumentierter Wert |
|---|---|
| Schaden pro Tag | Mehr als 100.000 US-Dollar |
| Kumulierte Kosten bei einzelnen Opfern | Bis zu 1.000.000 US-Dollar |
| Extremfall bei API-Anfragen | Rund 200.000 Anfragen in zwei Minuten |
| Aufrufe über einen Weiterverkaufsdienst | Mehr als 500.000 in weniger als acht Stunden |
Wie LLMJacking in der Praxis funktioniert
Die Angreifer nutzen gestohlene Inferenzleistung entweder selbst oder verkaufen den Zugang weiter. Inferenz bezeichnet die eigentliche Ausführung eines bereits trainierten KI-Modells. Besonders attraktiv ist dieser Missbrauch bei leistungsfähigen Modellen, deren Nutzung nach Token oder Anfrage abgerechnet wird.
Die beobachtete Gruppe UNC6993 verschaffte sich unter anderem über einen fehlkonfigurierten Service-Account-Schlüssel Zugang zu Cloud-Instanzen. Anschließend erstellten die Täter weitere API-Schlüssel und aktivierten zusätzliche Modell-Dienste innerhalb der kompromittierten Cloud-Projekte.
Eine weitere Methode ist das sogenannte Burn and Rotate. Dabei werden kurzlebige Service-Accounts fortlaufend erstellt und wieder gelöscht, um Rate-Limits zu umgehen. Gleichzeitig kontrollieren die Täter die Abrechnungsschnittstelle des Opfers, um den verursachten Verbrauch zu überwachen.
Bedrohungsakteure wollen mit agentenbasierten Werkzeugen und gestohlenen Tokens einen Skalierungsvorteil gegenüber Verteidigern erreichen, erklärte John Hultquist von der Google Threat Intelligence Group sinngemäß aus dem Englischen.
Schatten-Dienste verkaufen gestohlene Rechenleistung
Rund um LLMJacking entsteht eine arbeitsteilige kriminelle Infrastruktur. Einige Gruppen beschaffen den ersten Zugang, andere betreiben sogenannte LLM Mixers. Diese Dienste bündeln fremde API-Zugänge und verkaufen sie zu Preisen weiter, die regulär kaum wirtschaftlich wären.
Ein Dienst namens Jet Night nutzte gestohlene Schlüssel für mehr als 500.000 API-Aufrufe in weniger als acht Stunden. Angeboten wurde ein angeblich unbegrenzter Zugang zu Frontier-Modellen für rund 60 US-Dollar pro Monat. Vergleichbare reguläre Angebote kosten laut Bericht üblicherweise zwischen 100 und 250 US-Dollar pro Monat.
Die ungewöhnlich niedrigen Kosten pro Token sprechen nach Einschätzung der Google Threat Intelligence Group dafür, dass Jet Night nur mithilfe gestohlener Schlüssel profitabel arbeiten konnte, sinngemäß aus dem Englischen übersetzt.
Welche konkreten Modellanbieter betroffen waren, wurde nicht aufgeschlüsselt. Auch die Namen und Branchen der geschädigten Unternehmen sind nicht bekannt. Offen bleibt zudem, ob Anbieter betrügerisch verursachte Rechnungen aus Kulanz reduzieren oder vollständig erlassen.
Passwort und MFA reichen nicht immer aus
In einem Fall setzten die Täter eine präparierte Anmeldeseite ein. Nutzer sollten dort die JSON-Nutzlast eines aktiven Access-Tokens einfügen. Mit diesem Token konnten die Angreifer bestehende Sitzungen übernehmen und damit Passwort sowie Mehrfaktor-Authentifizierung umgehen.
Das Risiko liegt deshalb nicht nur in versehentlich veröffentlichten API-Schlüsseln. Auch aktive Sitzungstokens, Umgebungsvariablen und überprivilegierte Service-Accounts müssen wie Zugangsdaten behandelt werden. Wie schnell gestohlene Schlüssel hohe Kosten verursachen können, zeigt auch der Fall von OpenCode mit entwendeten API-Schlüsseln.
Zusätzlich bleibt die Software-Lieferkette relevant. Beim Supply-Chain-Angriff auf LiteLLM standen ebenfalls API- und Cloud-Schlüssel im Zentrum. Zentral verwaltete Geheimnisse helfen wenig, wenn Anwendungen oder Abhängigkeiten unkontrolliert darauf zugreifen können.
Schutzmaßnahmen gegen unkontrollierte API-Kosten
Die wichtigste technische Grundlage ist das Least-Privilege-Prinzip. Nutzer und Service-Accounts erhalten dabei nur die Berechtigungen, die sie für ihre konkrete Aufgabe benötigen. Ein Schlüssel für eine einzelne Anwendung sollte weder neue Konten anlegen noch zusätzliche Cloud-Dienste aktivieren können.
Prioritäten für Unternehmen
- API-Schlüssel und andere Geheimnisse zentral verwalten und automatisiert rotieren.
- Quellcode und Build-Pipelines automatisch nach versehentlich hinterlegten Schlüsseln durchsuchen.
- Service-Accounts auf minimale Rechte und klar definierte Modellzugriffe beschränken.
- Abrechnungsdaten, neue Schlüssel und ungewöhnliche Anfragevolumen in Echtzeit überwachen.
- Harte Ausgabenobergrenzen setzen, sofern der jeweilige Anbieter diese unterstützt.
- Budgetwarnungen nicht mit Ausgabenobergrenzen verwechseln, da Warnungen den Verbrauch nicht automatisch stoppen.
Transparente Verbrauchsdaten erleichtern zumindest die Erkennung. Ein Beispiel dafür ist das Kosten-Reporting für Claude Code. Solche Berichte ersetzen jedoch keine technischen Limits und keine automatisierte Sperre bei ungewöhnlichem Verbrauch.
Besondere Relevanz für DACH-Unternehmen
Für Unternehmen im DACH-Raum verbindet LLMJacking drei Risiken. Neben der finanziellen Belastung können unkontrollierte Datenverarbeitung und kompromittierte Firmenkonten Datenschutz- sowie Compliance-Fragen auslösen. Besonders kritisch sind Pay-as-you-go-Verträge ohne harte Budgetgrenze.
Selbst gehostete Open-Source-Modelle beseitigen das Sicherheitsproblem nicht, begrenzen aber den möglichen Verbrauch durch die vorhandene Hardware. Ein kompromittierter Zugang kann dann weiterhin Systeme belasten oder Daten gefährden, erzeugt jedoch nicht automatisch eine nach oben offene Rechnung eines externen API-Anbieters.
Für sensible oder dauerhaft hohe Arbeitslasten kann Self-Hosting deshalb eine kalkulierbarere Alternative sein. Cloud-APIs bleiben für viele Anwendungsfälle praktisch, sollten aber wie produktive Zahlungsinfrastruktur abgesichert werden. Jeder Schlüssel braucht einen klaren Besitzer, minimale Rechte, ein überprüfbares Kostenlimit und einen automatisierten Sperrmechanismus.