Googles LLM-Jacking-Warnung legt einen Schwarzmarkt für gestohlenen KI-Zugang offen
Google hat gewarnt, dass LLM-Jacking-Angriffe stark zunehmen, da Kriminelle immer häufiger KI-Konten, API-Zugangsdaten und Cloud-Kapazitäten von Unternehmen stehlen.
Untergrundanbieter werben Berichten zufolge mit unautorisiertem Zugang zu Modellen von Google, Anthropic und OpenAI zu Rabatten von bis zu 97 %. Diese Zahl beschreibt beobachtete Marktangebote, nicht einen unabhängig bestätigten durchschnittlichen Transaktionspreis.
Die wichtigere Erkenntnis liegt hinter der Schlagzeile. KI-Zugang ist zu einem handelbaren kriminellen Gut geworden, ähnlich wie gestohlene Zahlungskarten, Cloud-Konten und Residential-Proxy-Verbindungen.
Die Google Threat Intelligence Group erklärt, sie habe 2026 mehr Käufer und Verkäufer von KI-Konten beobachtet. Die Nachfrage konzentrierte sich auf Zugangsdaten für Claude und Gemini sowie auf KI-Programmierprodukte wie Cursor Pro und Devin.
Dabei handelt es sich nicht einfach um Abonnementbetrug. Angreifer können einen API-Schlüssel oder eine Cloud-Identität stehlen, Anfragen über das Konto eines anderen Unternehmens leiten und das Opfer für die Aktivitäten verantwortlich zurücklassen.
Die daraus entstehende Gefährdung umfasst unerwarteten Verbrauch, Datenabfluss, Dienstunterbrechungen und die kriminelle Nutzung vertrauenswürdiger Infrastruktur. Sie stellt außerdem Sicherheitsprogramme infrage, die KI-Ausgaben weiterhin als Softwarebudget statt als kontrollierte Rechenressource behandeln.
Frühere Kampagnen zur Entführung von Ressourcen zielten meist auf Kryptowährungs-Mining oder Proxy-Kapazitäten. LLM-Jacking überträgt dieselbe ökonomische Logik auf Modellinferenz, Entwickler-Agenten und die Infrastruktur, die für ihren Betrieb erforderlich ist.
Der Konflikt ist daher größer als Kriminelle gegen KI-Anbieter. Es geht um gestohlenen Zugang gegen Unternehmenskontrolle, wobei jeder nicht nachverfolgte Schlüssel oder überprivilegierte Workload das Angebot des Marktes erweitert.
Was Googles LLM-Jacking-Warnung tatsächlich aussagt
Googles Belege zeigen, dass Kriminelle eine Lieferkette rund um kompromittierten KI-Zugang aufbauen und nicht lediglich mit einzelnen gestohlenen Konten experimentieren.
Der KI-Bedrohungstracker des Unternehmens vom September 2026 beschreibt zunehmenden Diebstahl, die Exfiltration und den Verkauf von KI-Konten in Cybercrime-Communities.
Google zufolge suchten 2026 mehr Untergrund-Personas nach KI-bezogenen Konten. Im Vergleich zum Vorjahr beobachtete das Unternehmen zudem mehr Verkäufer, die solche Konten anboten.
Die durchschnittlichen Marktplatzpreise pro Konto haben sich 2026 laut den von Google verfolgten Beiträgen mehr als verdoppelt. Dieser Anstieg deutet auf wachsende Nachfrage hin, obwohl einzelne Angebote extreme Rabatte versprachen.
Der scheinbare Widerspruch ergibt in einem illegalen Markt Sinn. Käufer schätzen den Zugang, weil legitime Inferenz und Hochleistungsrechnen knappe, kostenpflichtige Ressourcen erfordern.
Ein gestohlenes Konto kann diese Kosten auf das Opfer verlagern. Ein Verkäufer kann legitimen Zugang daher unterbieten, ohne vergleichbare Infrastruktur betreiben zu müssen.
Berichte über Rabatte von bis zu 97 % scheinen die günstigsten Untergrundangebote zu beschreiben. Googles öffentlicher Bericht belegt diesen Prozentsatz nicht als marktweiten Durchschnitt.
Er nennt außerdem weder eine Gesamtzahl der Opfer noch aggregierte finanzielle Schäden oder ein verifiziertes Transaktionsvolumen. Diese Lücken erschweren jeden Versuch, die vollständige Größe des Marktes zu messen.
Die zugrunde liegenden Aktivitäten sind jedoch besser dokumentiert als die Schlagzeilenzahl. Google beobachtete steigende Nachfrage, gezielten Diebstahl von Zugangsdaten und Cloud-Kompromittierungen zur Unterstützung unautorisierter KI-Workloads.
Das Unternehmen bezeichnet die Infrastrukturvariante als „LLMJacking“. Der Begriff umfasst die Entführung von Cloud-Ressourcen eines Unternehmens, um KI-Modelle auszuführen oder gehostete Modelldienste ohne Genehmigung zu nutzen.
Google identifiziert zudem Methoden zur Beschaffung von Konten jenseits des direkten Diebstahls. Bedrohungsakteure nutzen automatisierte Registrierungen, Konto-Pooling, Proxy-Relays und Middleware, die mehrere Schlüssel bündelt.
Diese Systeme können Anfragen über Konten verteilen und ihren Ursprung verschleiern. Sie können auch deaktivierte Zugangsdaten ersetzen, ohne die Schnittstelle für den Käufer zu verändern.
Diese Struktur macht kompromittierten Zugang zu einem Dienst. Käufer müssen nicht verstehen, welche Organisation die zugrunde liegende Rechnung bezahlt.
Der Markt umfasst Berichten zufolge Zugangsdaten für verbraucherorientierte KI-Konten, Programmierassistenten und Modell-APIs. Diese Ressourcen unterscheiden sich erheblich darin, was sie offenlegen.
Ein gestohlenes Chat-Konto kann Gesprächsverläufe und hochgeladene Dokumente offenlegen. API-Zugangsdaten können programmierbaren Zugriff auf ein Kontingent, ein Modell oder ein verbundenes Cloud-Projekt ermöglichen.
Eine kompromittierte Cloud-Identität stellt das größte Risiko dar. Sie kann einem Eindringling ermöglichen, Infrastruktur bereitzustellen, gespeicherte Zugangsdaten zu entdecken oder angrenzende Unternehmensdienste zu erreichen.
Googles Warnung verknüpft diese Ebenen zu einer Wirtschaft. Gestohlene Konten ermöglichen sofortigen Zugang, während kompromittierte Infrastruktur dauerhafte Rechenkapazität liefert.
Diese Kombination erklärt, warum die Bedrohung über einen einzelnen Anbieter hinausgeht. Google, Anthropic und OpenAI konkurrieren um legitime Kunden, doch Kriminelle können Zugang zu allen drei als austauschbaren Bestand handeln.
Warum KI-Zugang zu wertvollem kriminellem Handelsgut wurde
Der Aufstieg von LLM-Jacking spiegelt einen grundlegenden wirtschaftlichen Wandel wider: Modellzugang liefert heute nützliche, skalierbare Rechenkapazität, die Kriminelle nicht selbst finanzieren wollen.
Kriminelle Gruppen stehlen seit Langem Infrastruktur, wenn die gestohlene Ressource Einnahmen erzeugen kann. Kryptowährungs-Mining machte kompromittierte Prozessoren wertvoll, weil Rechenleistung direkt in digitale Vermögenswerte umgesetzt werden konnte.
Proxyjacking schuf einen weiteren Markt, indem Datenverkehr über die Systeme von Opfern geleitet wurde. Angreifer konnten Bandbreite und vertrauenswürdig wirkende private oder unternehmerische Adressen verkaufen.
LLM-Jacking erweitert dieses Modell auf die Inferenz. Die gestohlene Ressource ist die Fähigkeit, Prompts zu senden, Ausgaben zu erzeugen, Agenten zu betreiben oder Modelle auf übernommener Hardware auszuführen.
MITRE klassifiziert dieses umfassendere Verhalten als Resource Hijacking. Das Framework umfasst Missbrauch von Rechenleistung, Bandbreite, Messaging und Cloud-Diensten.
KI macht die Gelegenheit vielseitiger. Eine einzelne Zugangsinformation kann Codegenerierung, Aufklärung, Content-Produktion, Übersetzung, Phishing-Vorbereitung oder einen automatisierten offensiven Workflow unterstützen.
Dieselbe Zugangsinformation kann außerdem Zugang zu höheren Limits oder Fähigkeiten ermöglichen, die über ein anonymes kostenloses Konto nicht verfügbar sind. Dieser Unterschied ist wichtig, wenn eine Operation von nachhaltiger Automatisierung abhängt.
Google zufolge bleiben Premium-Zugang und Hochleistungsrechenkapazität wichtige Hürden für Angreifer. Der Diebstahl dieser Ressourcen senkt die Hürde, ohne dass Kriminelle eine KI-Plattform aufbauen müssen.
Der Markt kann verschiedene Käufertypen bedienen. Einige wünschen günstigen allgemeinen Modellzugang, während andere Konten suchen, die hohem Volumen oder richtlinienwidriger Nutzung standhalten.
Leistungsfähigere Gruppen können gestohlenen Zugang mit Orchestrierungssystemen verbinden. Diese Systeme wählen Konten automatisch aus, rotieren Endpunkte, wiederholen fehlgeschlagene Anfragen und verteilen Arbeit.
Googles Bedrohungsforschung vom Mai 2026 dokumentierte Proxy-Relays und automatisierte Registrierungspipelines, die zur Industrialisierung des Zugangs zu kommerziellen Modellen eingesetzt werden.
Der Bericht beschrieb Anti-Detect-Browser, Kontopools und maßgeschneiderte Middleware, die darauf ausgelegt sind, Abrechnungsbeschränkungen oder die Durchsetzung durch Plattformen zu umgehen. Diese Mechanismen verringern die Abhängigkeit von einzelnen Zugangsdaten.
Sie erschweren auch die Attribution. Datenverkehr, der einen Anbieter erreicht, kann Relays und kompromittierte Projekte durchlaufen, bevor an anderer Stelle ein bösartiges Ergebnis entsteht.
Für ein Unternehmensopfer könnte das erste offensichtliche Signal ein ungewöhnlicher Modellverbrauch sein. Der Angreifer könnte jedoch bereits Tage zuvor über ein Entwicklergerät eingedrungen sein.
Ein Infostealer, also Schadsoftware zum Sammeln von Zugangsdaten und Sitzungsdaten, kann lokale Dateien nach KI-Konfigurationsinformationen durchsuchen. Anschließend kann er alles Nützliche an seinen Controller exportieren.
Google beobachtete, dass Controller von ACRSTEALER auf Konfigurationsspeicher zielten, die mit Cline und Continue AI verbunden sind. Diese Dateien können API-Schlüssel im Klartext oder benutzerdefinierte Routing-Endpunkte enthalten.
Dieses Detail macht KI-Entwicklungsumgebungen besonders wichtig. Programmierassistenten befinden sich häufig in der Nähe von Quellcode-Repositories, Paketregistern, Terminals und Cloud-Tools.
Eine gestohlene Zugangsinformation aus dieser Umgebung kann mehr als Modellzugang ermöglichen. Sie kann Angreifern helfen, den Entwicklungs-Stack zu kartieren oder einen Weg in Produktionssysteme zu identifizieren.
Der wachsende Markt setzt daher Sicherheitsverantwortliche, Engineering-Manager und Cloud-Finanzteams zugleich unter Druck. Jede Gruppe sieht ein anderes Fragment des Vorfalls.
Die Sicherheit sieht eine kompromittierte Identität. Das Engineering sieht fehlgeschlagene Anfragen oder ausgeschöpfte Kontingente. Die Finanzabteilung sieht unerklärlichen Verbrauch, nachdem der Zugang bereits monetarisiert wurde.
Ohne gemeinsame Überwachung werden diese Fragmente möglicherweise nie zu einem einzigen Vorfall. Der Schwarzmarkt profitiert von dieser organisatorischen Verzögerung.
Googles LLM-Jacking-Warnung setzt Identitätskontrollen unter Druck
Das zentrale Problem besteht nicht darin, dass Modelle plötzlich leicht zu hacken wären. Angreifer stehlen die Identitäten und die Infrastruktur, die sie umgeben.
Googles Forschung unterscheidet Angriffe auf KI-Ressourcen von erfolgreichen Kompromittierungen hochentwickelter Modelle selbst. Die beobachtete Aktivität konzentriert sich stark auf Zugangsdaten, Konnektoren, Entwicklerkonfigurationen, Cloud-Projekte und Orchestrierungsebenen.
Diese Unterscheidung ist wichtig, weil Modellsicherheitskontrollen einen offengelegten Unternehmensschlüssel nicht widerrufen können. Sie können auch keine Identitätsrolle korrigieren, die unnötige Berechtigungen in einer Cloud-Umgebung gewährt.
Eine Bearer-Zugangsinformation erlaubt ihrem Inhaber, mit den ihr zugewiesenen Berechtigungen zu handeln. Das System erkennt möglicherweise nicht, ob die Anfrage vom Eigentümer oder einem Dieb stammt.
Langlebige API-Schlüssel erschweren die Verwaltung dieser Schwachstelle. Sie überdauern oft Personalwechsel, aufgegebene Prototypen und Migrationen zwischen KI-Anbietern.
Entwickler können sie aus Bequemlichkeit in lokale Konfigurationsdateien kopieren. Automatisierte Tools können zudem Schlüssel erzeugen, ohne sie in ein etabliertes Sicherheitsinventar aufzunehmen.
Das Ergebnis ist ein Wildwuchs an Zugangsdaten. Unternehmen wissen, welche KI-Tools sie genehmigt haben, aber nicht unbedingt, welche Identitäten, Schlüssel, Erweiterungen und lokalen Agenten darauf zugreifen können.
LLM-Jacking macht diese Governance-Lücke zu Inventar für Kriminelle. Jede wiederverwendbare Zugangsinformation wird zu einem potenziellen Produkt.
Die Sicherheitsherausforderung wächst, wenn Unternehmen Modelle mit internen Daten verbinden. Ein KI-Assistent kann Zugriff auf Quellcode, technische Dokumente, Support-Aufzeichnungen oder Projektdiskussionen haben.
Wenn ein Eindringling die Sitzung des Assistenten stiehlt, könnte der Vorfall gespeicherte Gespräche oder verbundene Ressourcen offenlegen. Wenn der Angreifer nur einen API-Schlüssel stiehlt, hängt die direkte Datenoffenlegung von dessen Berechtigungen ab.
Diese Szenarien sollten nicht zu einer einzigen Behauptung zusammengezogen werden. Ein kompromittierter Schlüssel gewährt nicht automatisch Zugriff auf jeden Prompt oder jedes interne System.
Teams sollten jedoch auch nicht davon ausgehen, dass unautorisierte Nutzung nur ein Abrechnungsproblem verursacht. Protokolle, Modellausgaben, verbundene Tools und Anwendungskontext können allesamt sensible Informationen enthalten.
Mit Agenten wird das Risiko größer. Ein Agent kann Tools aufrufen, Dokumente abrufen, genehmigte Aktionen ausführen und operativen Kontext über einen Workflow hinweg bewahren.
Diese Fähigkeiten sind nützlich, weil sie manuelle Arbeit reduzieren. Sie sind gefährlich, wenn der zugrunde liegenden Identität eng begrenzte Berechtigungen und zuverlässige Prüfprotokolle fehlen.
Google berichtete, dass Angreifer sich auf agentische Operationen mit weniger menschlicher Verzögerung zubewegen. In einem Fall aus dem zweiten Quartal unterstützte eine kompromittierte Cloud-Ressource in weniger als sechs Stunden eine groß angelegte Kampagne zum Abgreifen von Zugangsdaten.
Dieses Beispiel beweist nicht, dass jedes gestohlene AI-Konto einen autonomen Angriff ermöglichen wird. Es zeigt jedoch, warum langsame, manuelle Freigabeketten nicht der einzige Abwehrmechanismus bleiben können.
Unternehmen müssen wissen, welche Identitäten Modelle nutzen können, welche Anwendungen sie besitzen und wie eine normale Nutzung aussieht. Zudem benötigen sie eine schnelle Möglichkeit, Zugriffe zu sperren.
Das erfordert Zusammenarbeit über das Security Operations Center hinaus. Plattformteams müssen Zugangsdaten beobachtbar machen, während Beschaffungsteams Rechnungen konkreten Verantwortlichen und Workloads zuordnen müssen.
Entwickler benötigen außerdem genehmigte Speicher- und Rotationswege, die weiterhin praktikabel sind. Erzeugt der sichere Prozess zu viel Reibung, werden sich unverwaltete lokale Alternativen weiter verbreiten.
Der Gewinner dieses Konflikts wird nicht das Unternehmen mit der längsten Richtlinie zur zulässigen Nutzung sein. Es wird das Unternehmen sein, das AI-Zugriff schnell identifizieren, einschränken und widerrufen kann.
Die Angriffskette beginnt vor dem ersten verdächtigen Prompt
LLM-Jacking gelingt meist durch vertrauten Diebstahl von Zugangsdaten und Cloud-Missbrauch; der AI-Verbrauch dient anschließend als Monetarisierungsebene.
Ein häufiger Weg beginnt auf dem Entwicklerarbeitsplatz. Phishing, Schadsoftware, ein kompromittiertes Paket oder eine täuschende Browser-Erweiterung können einen Infostealer einschleusen.
Die Malware durchsucht Browser, Konfigurationsverzeichnisse, Befehlshistorien, Umgebungsdateien und Anwendungsspeicher. AI-Entwicklungstools schaffen zusätzliche Ziele, weil viele Modellzugangsdaten benötigen.
Sobald ein Schlüssel gestohlen wurde, kann er automatisiert getestet werden. Kriminelle Betreiber können Anbieter, verfügbares Kontingent, Beschränkungen und die weiterhin bestehende Gültigkeit der Zugangsdaten ermitteln.
Nützliche Zugangsdaten können direkt verkauft oder in einen Relay-Dienst eingebunden werden. Ein Relay nimmt Anfragen von Kunden entgegen und leitet sie über ein oder mehrere kompromittierte Konten weiter.
Der Kunde sieht einen stabilen Service-Endpunkt. Im Hintergrund kann der Betreiber widerrufene Zugangsdaten ersetzen, die Nutzung verteilen oder bestimmte Workloads an unterschiedliche Modelle weiterleiten.
Diese Trennung schützt den Käufer vor der Instabilität einzelner gestohlener Konten. Sie ermöglicht dem Verkäufer zugleich, eine Sammlung von Zugangsdaten über viele Kunden hinweg zu monetarisieren.
Eine Cloud-Kompromittierung eröffnet einen weiteren Weg. Angreifer können eine Identität erlangen, die ihnen erlaubt, Modelldienste zu aktivieren oder selbst gehostete Infrastruktur bereitzustellen.
Anschließend können sie gehostete Inferenz über das Projekt des Opfers nutzen. Alternativ können sie gestohlene Rechenkapazität einsetzen, um ein Modell direkt auszuführen.
Das Sicherheitsunternehmen Sysdig prägte 2024 den Begriff LLMjacking für die Nutzung gestohlener Cloud-Zugangsdaten zum Verbrauch kostenpflichtiger Modelldienste. Seine spätere LLMjacking research beschreibt eine Entwicklung hin zu offensiven agentischen Workloads.
Selbst gehostete Modelle schaffen eine verwandte Angriffsfläche. Ein ohne Authentifizierung aus dem Internet erreichbarer Inferenzserver kann jedem, der ihn entdeckt, kostenlose Kapazität bereitstellen.
Dieser Weg erfordert keinen gestohlenen API-Schlüssel. Die Schwachstelle liegt in einem exponierten Dienst und unzureichenden Netzwerkkontrollen.
Das Ergebnis kann dennoch LLM-Jacking ähneln, weil Außenstehende die AI-Infrastruktur einer Organisation nutzen. Die Behebung unterscheidet sich jedoch von einer Untersuchung eines Kontodiebstahls.
Teams müssen mindestens drei Arten von Vorfällen unterscheiden: kompromittierte Benutzersitzungen, gestohlene Modellzugangsdaten und gekaperte Cloud- oder selbst gehostete Infrastruktur.
Sitzungsdiebstahl erfordert Kontowiderruf, Geräteuntersuchungen und eine Überprüfung exponierter Inhalte. Der Diebstahl von API-Schlüsseln verlangt Schlüsselrotation, Log-Analyse und die Validierung zugehöriger Berechtigungen.
Bei einer Infrastrukturkompromittierung ist eine umfassendere Incident Response erforderlich. Ermittler müssen feststellen, wie der Angreifer eingedrungen ist, welche Ressourcen erstellt wurden und ob Persistenz erhalten bleibt.
Nutzungsanomalien können alle drei Fälle aufdecken, reichen allein aber nicht aus. Auch ein legitimer Produktstart kann plötzlich hohen Modellverkehr erzeugen.
Eine brauchbare Erkennung kombiniert Volumen, Identität, Geografie, Zeitpunkt, Modellauswahl und Anwendungsverhalten. Ein Workload, der sich gleichzeitig in mehreren Dimensionen verändert, verdient eine rasche Prüfung.
Teams sollten auch Anfragen überwachen, die von Sicherheitskontrollen abgelehnt werden. Solche Ereignisse können auf Missbrauch hindeuten, auch wenn ausgefeilte Angreifer harmlose Aufgaben oder eigene Modelle verwenden können.
Die besten Kontrollen senken sowohl Wahrscheinlichkeit als auch Auswirkung. Kurzlebige Zugangsdaten verkürzen das Zeitfenster, während workload-spezifische Identitäten begrenzen, worauf gestohlene Zugangsdaten zugreifen können.
Netzwerkbeschränkungen können die Nutzung aus unerwarteten Umgebungen blockieren. Kontingente und Verbrauchsgrenzen können Missbrauch verlangsamen, während Einsatzteams ermitteln.
Keine dieser Kontrollen bietet Gewissheit. Zusammen machen sie gestohlenen Zugriff weniger zuverlässig und damit für Anbieter im Untergrund weniger wertvoll.
Was die Behauptung eines 97%-Rabattes nicht beweist
Der dramatische Rabatt ist ein nützliches Warnsignal, misst jedoch weder die tatsächliche Größe, Zuverlässigkeit noch die finanziellen Auswirkungen des Marktes.
Eine Untergrundanzeige ist kein abgeschlossener Verkauf. Verkäufer können die Zugriffsqualität, den Kontotyp, das verbleibende Kontingent oder die Zeit bis zum Widerruf übertreiben.
Das beworbene Produkt kann sich auch von legitimem Zugriff unterscheiden. Käufer erhalten möglicherweise einen gemeinsam genutzten Proxy, eine Browsersitzung oder ein kurzlebiges Konto statt eines übertragbaren Abonnements.
Diese Unterscheidung verändert die Rabattberechnung. Der Vergleich eines instabilen kriminellen Relays mit zuverlässigem, unterstütztem Zugriff kann einen irreführenden Prozentsatz ergeben.
Die Zahl verrät auch nicht, wer den zugrunde liegenden Verbrauch getragen hat. Ein Teil des Zugriffs kann aus gestohlenen Zugangsdaten stammen, während andere Angebote Testversionen oder automatisierte Kontoerstellung ausnutzen können.
Google hat all diese Beschaffungswege dokumentiert. Die öffentlich verfügbaren Belege ordnen dem Markt keinem einzelnen davon einen prozentualen Anteil zu.
Ebenso belegt der Bericht nicht, dass Angreifer die zentrale Modellinfrastruktur von Google, Anthropic oder OpenAI kompromittiert haben. Der beobachtete Markt beruht überwiegend auf kompromittierten Kunden und Kontoökosystemen.
Diese Nuance sollte die Reaktion prägen. Unternehmen können nicht darauf warten, dass Anbieter jeden Fall lösen, weil viele Schwachstellen in kundenseitig verwalteten Identitäten und Geräten liegen.
Anbieter tragen dennoch erhebliche Verantwortung. Sie können Kontopooling, verdächtige Relays, unmögliche Nutzungsmuster und koordinierten Missbrauch bei der Registrierung auf ihren Plattformen erkennen.
Google erklärt, Bedrohungsinformationen zur Stärkung von Schutzmaßnahmen und zur Deaktivierung böswilliger Projekte oder Konten zu nutzen. Eine solche Durchsetzung kann die Kosten für den Betrieb eines Untergrunddienstes erhöhen.
Maßnahmen von Anbietern schaffen jedoch eine weitere Unsicherheit. Aggressive automatisierte Sperren können legitime gemeinsam genutzte Infrastruktur oder weltweit verteilte Entwicklungsteams beeinträchtigen.
Sicherheitssysteme benötigen daher mehr Belege als eine einzelne Verkehrsspitze. Sie müssen einen Produktstart, eine falsch konfigurierte Anwendung und gestohlene Zugangsdaten schnell unterscheiden.
Das Fehlen aggregierter Schadensdaten begrenzt auch Vergleiche mit Ransomware, Cryptojacking und anderen Cloud-Bedrohungen. LLM-Jacking könnte weit verbreitet sein und dennoch pro Opfer nur moderate Verluste verursachen.
Das gegenteilige Muster ist ebenfalls möglich. Eine kleinere Zahl von Cloud-Kompromittierungen könnte schwere Risiken erzeugen, weil die gestohlene Identität Zugang zu wertvollen Daten und Infrastruktur bietet.
Googles Telemetrie stellt eine weitere Grenze dar. Sie bietet starke Einblicke in das eigene Ökosystem und die Incident-Response-Arbeit, jedoch nicht in jeden Anbieter oder jede Transaktion im Untergrund.
Unabhängige Forschung hilft, das Angriffsmuster zu bestätigen. Sie kann fragmentierte Beobachtungen dennoch nicht in eine vollständige globale Marktschätzung verwandeln.
Die belastbare Schlussfolgerung ist enger und nützlicher. Kriminelle Nachfrage existiert, Verkäufer reagieren darauf, und gestohlener AI-Zugriff verfügt inzwischen über einen wiederholbaren Monetarisierungsweg.
Diese Schlussfolgerung erfordert nicht, jede Dark-Web-Anzeige für bare Münze zu nehmen. Sie erfordert, AI-Zugangsdaten als Vermögenswerte zu behandeln, die Angreifer aktiv suchen.
Die skeptische Lesart stärkt daher die operative Lehre. Teams sollten auf verifizierte Angriffsmechanismen reagieren und keine Richtlinien um eine Werbezahl eines illegalen Verkäufers herum aufbauen.
Drei Signale werden zeigen, ob LLM-Jacking weiter wächst
Die nächste Phase wird durch die Zielauswahl von Credential-Stealern, die Durchsetzung durch Anbieter und Anomalien beim Unternehmensverbrauch sichtbar werden.
Das erste Signal ist, ob Infostealer ihre Ausrichtung auf AI-Konfigurationsdateien ausweiten. Google hat bereits Malware-Controller beobachtet, die nach spezifischen Geheimnissen von Coding-Assistenten suchen.
Neue Regeln, die auf zusätzliche Agents, Modellrouter und lokale Entwicklertools zielen, würden darauf hindeuten, dass Angreifer dort weiterhin wertvolle Zugangsdaten finden.
Sicherheitsteams sollten daher Endpoint-Erkennungen auf unbekannte Suchvorgänge in Konfigurationsverzeichnissen prüfen. Außerdem sollten sie Anwendungen inventarisieren, die Modellzugangsdaten lokal speichern.
Das zweite Signal ist die Durchsetzung durch Anbieter. Achten Sie auf Angaben zu deaktivierten Kontopools, zerschlagenen Relay-Netzwerken, strengeren Registrierungsprüfungen und eingeschränkteren Authentifizierungsoptionen.
Mehr Durchsetzung würde bestätigen, dass Anbieter koordinierten Missbrauch in relevantem Umfang beobachten. Sie könnte Kriminelle jedoch auch zu selbst gehosteten Modellen und direkter Cloud-Kompromittierung drängen.
Diese Verlagerung ist wichtig. Das Sperren gestohlener Verbraucherkonten beendet die Nachfrage nach kostengünstiger Rechenkapazität nicht.
Das dritte Signal ist die Unternehmenstelemetrie. Unerklärliche Zunahmen bei Inferenzanfragen, neue Modellnutzung, unbekannte Regionen oder Verbrauch außerhalb von Bereitstellungsfenstern können kompromittierten Zugriff offenlegen.
MITREs Modell für die Übernahme von Cloud-Diensten empfiehlt, nach plötzlichen Ressourcenänderungen und unbefugtem Serviceverbrauch zu suchen. AI-Teams können diese Logik auf Tokens, Anfragen, Endpunkte und Modellfamilien übertragen.
Googles API key guidance empfiehlt Einschränkungen, Nutzungsüberwachung, isolierte Schlüssel, regelmäßige Rotation und stärkere Authentifizierung, sofern verfügbar.
Teams sollten diese Prinzipien in Verantwortlichkeitsregeln übersetzen. Jede Modellzugangsdaten benötigen eine benannte Anwendung, ein verantwortliches Team, eine genehmigte Umgebung und einen dokumentierten Widerrufsweg.
Vermeiden Sie, einen Schlüssel zwischen Personen und Workloads zu teilen. Getrennte Zugangsdaten schaffen bessere Audit-Trails und begrenzen die Reichweite einer einzelnen Kompromittierung.
Speichern Sie Produktionsgeheimnisse nicht in Repositories, Notebooks, über den Browser zugänglichem Code oder locker verwalteten lokalen Dateien. Nutzen Sie einen verwalteten Secret Store und automatisieren Sie die Bereitstellung von Zugangsdaten.
Bevorzugen Sie kurzlebige Identitätszugangsdaten, wo Anbieter sie unterstützen. Zeitlich begrenzte Zugangsdaten geben Angreifern weniger Zeit, Zugriff zu testen, zu bündeln und weiterzuverkaufen.
Legen Sie Verbrauchswarnungen auf Workload-Ebene fest, nicht nur für das gesamte Cloud-Konto. Aggregierte Abrechnung kann Missbrauch im normalen Unternehmenswachstum verbergen.
Überwachen Sie abgelehnte Anfragen und abrupte Änderungen bei der Modellauswahl. Eine kompromittierte Anwendung, die plötzlich andere Modelle aufruft, kann auf Experimente eines Angreifers hinweisen.
Beschränken Sie, welche Dienste, Anwendungen, Netzwerke und Methoden jede Identität nutzen darf. Das Prinzip der geringsten Rechte macht aus einem gestohlenen Schlüssel statt einer Master-Zugangsdaten ein begrenztes Asset.
Prüfen Sie AI-verbundene Tools mit derselben Disziplin wie Quellcode-Repositories und Cloud-Konsolen. Agents können über Connectoren sensible Berechtigungen übernehmen, die Teams übersehen.
Halten Sie ein Incident-Playbook für AI-Zugangsdaten bereit. Es sollte Widerruf, Log-Aufbewahrung, Endpoint-Inspektion, Benachrichtigung des Anbieters und Prüfungen auf angrenzenden Cloud-Zugriff abdecken.
Eine durchsuchbare Engineering-Wissensdatenbank kann Teams helfen, Verantwortlichkeitsdaten und Reaktionsverfahren festzuhalten. Sie sollte niemals aktive Geheimnisse enthalten.
Googles Warnung vor LLM-Jacking verändert die Frage, die sich Unternehmen stellen sollten. Es geht nicht länger darum, ob Kriminelle KI-Zugänge wertschätzen – der Untergrundmarkt zeigt, dass sie es tun.
Die praktische Frage lautet, ob Ihre Organisation jede Anmeldeinformation identifizieren kann, die ein Modell erreicht, ungewöhnliche Nutzung erkennt und Zugänge widerruft, bevor sie zur Handelsware werden.
Prüfen Sie diese Anmeldeinformationen jetzt. Weisen Sie jedem verbliebenen Schlüssel einen Verantwortlichen zu, entfernen Sie aufgegebene Zugänge und testen Sie den Widerrufsprozess unter realistischen Bedingungen.
