LLMjacking, und wie man diese Jäger abwehrt

KI-Sicherheit hat viele Facetten: Sie muss Datendiebstahl verhindern, betrügerische KI-Agenten bändigen und schädliche Ratschläge von KI-Assistenten erkennen. Eine relativ einfache Bedrohung nimmt immer mehr Fahrt auf: Versuche, die Rechenleistung zu stehlen und fremde neuronale Netzwerke zum eigenen Vorteil auszunutzen. Diese Methode wird als LLMjacking bezeichnet. Da die Prognose einen dramatischen Anstieg der Kosten für KI-Rechenvorgänge voraussagt, wird auch die Zahl der Angreifer wachsen, die auf dieser Welle reiten. Bei der Bereitstellung proprietärer KI-Server und entsprechender Ökosysteme wie RAG oder MCP sind daher von Anfang an strenge Sicherheitsmaßnahmen notwendig.

Statistiken aus einem Honeypot

Wie umfangreich diese Diebstahlversuche sind und welche rasante Entwicklung sie nehmen, veranschaulicht ein Experiment, das im April 2026 ausführlich dokumentiert wurde. Der Forscher konfigurierte einen Raspberry Pi so, dass er sich als leistungsstarker privater KI-Server ausgab, und machte den Server über das Internet zugänglich. Bei Anfragen wurde die Verfügbarkeit der Server Ollama, LM Studio, AutoGPT, LangServe und text-gen-webui gemeldet – Tools, die üblicherweise als Wrapper für lokal gehostete KI-Modelle dienen. Zudem gab der Server vor, API-Anfragen im OpenAI-Format zu akzeptieren, das inzwischen als Branchenstandard gilt.

Alle diese Dienste wurden scheinbar durch eine lokale Instanz von Qwen3-Coder 30B Heretic unterstützt, einem der stärksten Open-Source-Modelle, aus in diesem Fall die Sicherheitsbeschränkung (safety alignment) entfernt wurde. Damit das Ganze noch appetitlicher wirkte, spiegelte der Honeypot-Server das Vorhandensein verschiedener RAG-Datenbanken und eines MCP-Servers mit verlockenden Funktionen wie get_credentials vor.

In Wirklichkeit beherbergte der Raspberry Pi lediglich 500 zuvor gespeicherte Antworten eines echten Qwen3-Modells, wobei ein einfaches Skript jeweils die relevanteste Antwort für eingehende Anfragen herauspickte. Diese Konfiguration genügte, um eine oberflächliche Prüfung zu bestehen, und schon konnte der Forscher die Absichten von Angreifern untersuchen.

Nach Angaben des Forschers entdeckte die populäre Suchmaschine Shodan den Server innerhalb von drei Stunden nach Inbetriebnahme. Schon eine Stunde später gingen Anfragen ein, die offenbar die Funktionen erkunden sollten. Innerhalb des folgenden Monats verarbeitete der Server mehr als 113.000 Anfragen von Tausenden eindeutiger IP-Adressen. Dabei zielten 23 % des Datenverkehrs speziell darauf ab, KI-Funktionen zu finden und lokale LLMs und KI-Agenten auszunutzen.

Mit Anfragen wie /api/tags und /v1/models können Angreifer einen Fingerabdruck erhalten und feststellen, welche Modelle auf einem Server gehostet werden. Ein Scan mit /.cursor/rules deutet gewöhnlich auf einen anschließenden Exploit-Versuch gegen den KI-Agenten hin. Eine Überprüfung mit /.well-known/mcp.json dient der Inventarisierung fremder MCP-Server. Zwar erwähnt der Autor nicht, wie viele Angriffe den Rahmen einer einfachen Überprüfung sprengten. Allein in der letzten Woche des Experiments gab es jedoch 175 aktive Versuche, das LLM zu kapern.

Was wollen die Angreifer?

Laut den Beobachtungen des Forschers versuchte keiner der Angreifer, die sich für den Lockvogel-Server interessierten, irgendwelchen Code auszuführen oder Root-Zugriff zu erhalten. (Anmerkung der Redaktion: Das ist überraschend und könnte auf eine lückenhafte Protokollierung hinweisen.) Fast alle Angriffe hatten das Ziel, Ressourcen abzuzweigen. Während des Experiments wurden beispielsweise folgende Aktivitäten protokolliert:

• Ein gut strukturierter Versuch, die technische Dokumentation auf dem Mikroprozessor zu analysieren
• Ein Prompt, um einen erotischen Roman zu schreiben
• Anfragen zur Analyse und Struktur von Social-Media-Textdaten über neue Schwachstellen
• Ein Versuch, den kompromittierten Server als API-Proxy zu verwenden, um Anthropic-Modelle aufzurufen

Bemerkenswert ist, dass zum Scannen von KI-Ressourcen standardisierte Tools eingesetzt werden, die sich rapide weiterentwickeln. Die Anfragen der Anwendung „LLM-Scanner“ stammten aus der Infrastruktur von sieben verschiedenen Cloud-Anbietern in acht Ländern. Ein Hinweis darauf, dass die LMM-Jäger über etablierte Methoden verfügen und ihre Techniken über spezialisierte Plattformen miteinander teilen. Ab der dritten Woche des Experiments nutzte der Scanner eine zusätzliche Überprüfung: Anhand einfacher abstrakter Fragen ermittelte er, ob mit einer Live-KI oder einem Honeypot interagiert wurde, der vorgefertigte Antworten zurückgibt.

Unter den unspezifischen Angriffen verzeichnete das Experiment zahlreiche Versuche, Anmeldeinformationen aus der Datei .env zu extrahieren. Die Angreifer durchsuchten systematisch alle erdenklichen Serververzeichnisse nach dieser Datei. Eine öffentlich zugängliche .env-Datei ist einer der primitivsten Fehler bei der Projektbereitstellung auf Laravel, Node.js und anderen Frameworks. Trotzdem ist dieses Versehen immer noch weit verbreitet – insbesondere unter Anfängern und Vibe-Programmierern. Die Angreifer hatten also gute Gründe, diese Datei aufzuspüren.

Fazit und Tipps zur Verteidigung

Das Scannen und die Ausnutzung öffentlich zugänglicher Server sind ein alter Hut. Mit dem Aufkommen von LLMs bietet sich Angreifern jedoch eine weitere Möglichkeit, ihre unredlichen Bemühungen zu monetarisieren. Diese Methode ist für Kriminelle äußerst lukrativ – und für ihre Opfer verheerend. Wie massiv diese Angriffe werden können, zeigt ein Blick auf den Cryptojacking-Markt. Dort stehlen Kriminelle Rechnerressourcen, um damit Kryptowährungen zu schürfen. Allein im Jahr 2025 wuchs dieser Markt um 20 %. Da sich KI-basierte Lösungen immer mehr verbreiten, die Abokosten der großen Anbieter steigen und lokale KI-Chips knapp bleiben, ist zu erwarten, dass LLMjacking zu einem Phänomen mit industriellem Maßstab wird.

Wichtige Schutzmaßnahmen für eine private KI-Infrastruktur

• Für KI-Systeme, die lokal auf einem Computer ausgeführt werden, müssen Server wie LM Studio, Ollama oder ähnliche so konfiguriert werden, dass Verbindungen nur auf der lokalen Schnittstelle (localhost) und nicht auf allen verfügbaren Netzwerkschnittstellen akzeptiert werden. Dadurch wird der LLM-Zugriff auf den Host-Computer eingeschränkt und die KI ist nicht über das Internet erreichbar.
• Für Server, die Remote-Anfragen verarbeiten (auch wenn der Server nur innerhalb eines lokalen Unternehmensnetzwerks betrieben wird), solltest du eine robuste Authentifizierung und Autorisierung implementieren. Vertraue nicht ausschließlich auf die Überprüfung des API-Schlüssels. Am effektivsten sind Lösungen, die auf OIDC oder OAuth2 und kurzlebigen Token basieren. Dies schützt nicht nur vor LLMjacking, es ermöglicht auch ein genaueres Tracking der Benutzeraktivitäten und verhindert den Missbrauch von API-Schlüsseln. Gefahr droht übrigens nicht durch externe Angreifer. Ein wachsendes Risiko ist auch der Missbrauch von Schlüsseln durch KI-Agenten. Dies gilt sowohl für LLM-Schnittstellen als auch für MCP, RAG und andere.
• Verwende Netzwerksegmentierung und IP-Erlaubnislisten, um den Zugriff auf den KI-Server nur jenen Abteilungen, Mitarbeitern und Diensten zu gewähren, die ihn wirklich benötigen.
• Stelle sicher, dass alle Verbindungen zwischen Clients und Servern mit einer aktuellen TLS-Version geschützt sind.
• Verwende das Prinzip der geringsten Berechtigungen und einen getrennten Zugriff auf bestimmte Dienste. MCP- und LLM-Komponenten sollten beispielsweise über eigene Zugriffstoken verfügen.
• Stelle sicher, dass der EDR-Sicherheitsagent auf allen Workstations und Servern installiert ist. Auch auf jenen, die KI-Modelle hosten.
• Überwache den KI-Ressourcenverbrauch, lege Nutzungskontingente für verschiedene Mitarbeiterrollen fest und richte Benachrichtigungen für ungewöhnliche Aktivitätsspitzen ein.
• Führe detaillierte Protokolle über LLM-Antworten und Anfragen, die an das Modell und die Zusatztools gestellt wurden. Integriere diese Datenquellen in dein SIEM. Sorge dafür, dass diese Protokolle nicht manipuliert oder unerlaubt gelöscht werden können.