Zenity beschreibt die beobachtete Methode als Missbrauch der Inferenz-Endpunkte, die selbst gehostete KI-Software für Applikationen bereitstellt. Dafür sei kein Software-Exploit erforderlich. Stattdessen konfigurieren Angreifer nach Angaben der Forscher einen Agenten oder Client so, dass der offen erreichbare Endpunkt als Modell-Backend dient. Zenity nennt als Beispiele einen LiteLLM-Client, die Desktop-Anwendung CherryStudio oder die Codex-Befehlszeilenschnittstelle.

Die eigentliche Logik des Angriffs steckt dabei im Anfrageinhalt. Wie Zenity erläutert, werden die System-Persona des Agenten und seine Werkzeugdefinitionen direkt im Request mitgeliefert. Genau diese Inhalte hätten die Sensoren des Unternehmens erfasst. In den beobachteten Kampagnen kamen drei verschiedene Operatoren mit unterschiedlichen Einsatzzwecken zum Vorschein: zwei autonome Penetrationstest-Frameworks namens Strix und HexStrike AI sowie ein OpenAI-Codex-Agent mit einer Persona, die Sicherheitsverweigerungen unterdrücken und bei Web-Reverse-Engineering helfen sollte.

Im Fall von Strix nutzte eine einzelne Quell-IP laut Zenity einen LiteLLM-Client, um einen 140.000 Zeichen langen Prompt zu senden. Ziel war es, Strix gegen ein nicht näher benanntes französisches Auktionshaus einzusetzen. Der Prompt habe den Agenten angewiesen, niemals um Erlaubnis zu fragen, ohne Unterbrechung zu arbeiten, „Strix“ oder andere identifizierende Namen und Merkmale in seinen Aktionen nie offenzulegen und „bei allen Zielen extrem hart vorzugehen“. Zenity zufolge wurde der Versuch durch die eigenen Sensoren erkannt und vereitelt. Wiederholte „Erneut versuchen“-Befehle deuteten nach Einschätzung der Forscher auf einen möglichen Live-Operator hin.

Beim zweiten Fall richtete ein Angreifer den Desktop-LLM-Client auf die Ollama-Instanz des Honeypots und übermittelte das Arsenal von mehr als 150 offensiven Werkzeugen von HexStrike AI. Ein konkretes Ziel wurde in diesem Versuch nicht benannt. Für Zenity deutet das darauf hin, dass sich der Operator womöglich noch in der Vorbereitungsphase eines Angriffs befand.

Eine dritte Quell-IP verband einen OpenAI-Codex-Agenten mit einem LiteLLM-Proxy des Honeypots. Unter der Rolle eines Sicherheitsauditors sollte der Agent Arbeiten zum Web-Reverse-Engineering ausführen.

Begünstigt wird dieses Vorgehen laut Zenity auch durch die Voreinstellungen der betroffenen Software. Ollama werde auf dem Standardport 11434 ohne eingebaute Authentifizierung ausgeliefert. Bei LiteLLM sei Authentifizierung optional und davon abhängig, ob ein Nutzer einen Hauptschlüssel setzt. Zudem gebe es mit „sk-1234“ einen verbreiteten Platzhalterschlüssel, den Angreifer gezielt ansteuern.

Hinzu kommt die Erreichbarkeit der Systeme. Ollama sei standardmäßig auf den lokalen Host beschränkt, werde in der Praxis aber häufig so fehlkonfiguriert, dass es auf allen Schnittstellen erreichbar ist. LiteLLMs Proxy sei standardmäßig auf einem öffentlichen Host zum Internet hin offen.

Michael Bargury, Mitgründer und Technikchef von Zenity, sagte Dark Reading, Kunden seien grundsätzlich für das verantwortlich, was sie mit KI-Plattformen, Cloud-Infrastruktur sowie fremden und selbst entwickelten Agenten aufbauen und bereitstellen. Zugleich trügen Hersteller Verantwortung für die Absicherbarkeit und Überprüfbarkeit ihrer Plattformen. Sie sollten sichere Voreinstellungen liefern und Möglichkeiten schaffen, damit Kunden ihre Laufzeitumgebungen prüfen und anbinden können.

Zum Schutz empfiehlt Zenity unter anderem, Anfragen an häufig missbrauchte Endpunkte zu beobachten, insbesondere wenn sie vollständige Agenten-Payloads statt normaler Prompts enthalten. Außerdem rät das Unternehmen, typische Indikatoren in Anfrageinhalten zu blockieren, etwa komplette Werkzeugsammlungen oder Anfragen zu Modellen, die gar nicht selbst gehostet werden. Auch Requests im Zusammenhang mit Penetrationstest-Werkzeugen oder unsicheren Personas sowie die von den Operatoren verwendeten IP-Adressen sollten blockiert werden. Allgemeiner empfiehlt Zenity, Modell-Backends möglichst nicht ans Internet zu exponieren, echte Authentifizierung zu erzwingen, Standard- und Platzhalterschlüssel abzulehnen, Anfrageinhalte externer Quellen zu prüfen und den Verkehr zur eigenen KI-Infrastruktur zu überwachen.