Ransomware
Wandlung eines KI-Chatbots in eine Backdoor
Eine kompromittierte KI-Anwendung kann sich schnell vom einfachen Tool zu einer kritischen Backdoor entwickeln. Wir führen eine gängige KI-Angriffskette vor und zeigen die Schwachstellen in jeder Phase auf, ebenso wie eine Verteidigungsstrategie.
Save to Folio
Generative KI (GenAI), insbesondere in Form von Chatbots mit großen Sprachmodellen (LLM), bietet eine hohe Leistungsfähigkeit, birgt jedoch auch ein erhebliches Risiko: Eine kompromittierte KI-Anwendung kann sich schnell von einem einfachen Tool zu einer kritischen Backdoor zu den sensibelsten Daten und der Infrastruktur entwickeln.
Der Schlüssel zur sicheren Nutzung des Potenzials von KI liegt darin zu verstehen, dass keine einzelne Schutzschicht im KI-Stack eine Wunderwaffe ist. Der Schutz erfordert eine robuste, mehrschichtige Verteidigungsstrategie, die das gesamte KI-Ökosystem sichert, von der Benutzerinteraktion bis hin zu den Kerndaten.
Um die Risiken zu verstehen, führen wir ein stufenweises Angriffsszenario vor, das auf ein fiktives mittelständisches Unternehmen namens FinOptiCorp abzielt, welches FinBot einsetzt, einen fortschrittlichen LLM-gestützten Kundenservice-Chatbot. Diese Angriffskette veranschaulicht, wie eine Reihe von scheinbar geringfügigen Schwachstellen miteinander verknüpft werden können, um eine schwere Sicherheitsverletzung zu verursachen.
Ablauf
Phase 1: Erkundung und erste Sondierung
Angreifer geben sich zunächst als neugierige Kunden aus, interagieren mit dem öffentlich zugänglichen Chatbot und testen systematisch dessen Grenzen mit verschiedenen Eingaben. Sie suchen nach inkonsistenten Antworten oder Fehlermeldungen, die versehentlich Informationen über die zugrunde liegende Technologie preisgeben könnten. Bei dem Angriff auf das fiktive Unternehmen führte nach zahlreichen Versuchen eine absichtlich fehlerhafte Abfrage dazu, dass der Bot eine aufschlussreiche Fehlermeldung zurückgab.
Dies war der erste kritische Riss in der Verteidigung. Die Fehlermeldung bestätigte, dass der Bot Daten aus externen Quellen für die Sentimentalitäts-Analyse nutzt, und enthüllte damit den perfekten Vektor für einen indirekten Angriff. Außerdem wurde der Python-basierte Tech Stack exponiert – eine Hilfestellung für die Angreifer, um ihre nächsten Schritte anzupassen.
Diese anfängliche Sondierung nutzt potenzielle Schwachstellen bei der Offenlegung sensibler Informationen (OWASP LLM02:2025) aus.
Phase 2: Entdeckung von Schwachstellen, System Prompt Leakage und indirekte Prompt Injection
Mit dem erworbenen Wissen fanden die Angreifer ein Bewertungsforum eines Drittanbieters, eine Parsing-Anlaufstelle für FinBot. Dort veröffentlichten sie eine scheinbar positive Bewertung, die einen versteckten Befehl enthielt.
Diese als indirekte Prompt-Injection (OWASP LLM01:2025) bekannte Technik verleitet das LLM dazu, Anweisungen aus einer nicht vertrauenswürdigen Datenquelle zu befolgen.
Der bösartig Prompt wies FinBot an, seine wichtigsten Betriebsanweisungen offenzulegen. Der Bot, der von diesen versteckten Befehlen gekapert wurde, gab daraufhin seinen gesamten System Prompt preis, darunter auch die Namen der internen Tools, auf die er zugreifen konnte, wie beispielsweise internal_api_summarizer.
Diese Exponierung der Kernlogik des Bots ist eine klassische Schwachstelle in Form einer System Prompt Leakage (OWASP LLM07:2025).
Phase 3: Ausnutzen unsicherer API-Endpunkte und Zugriff auf sensible Daten
Infolge des geleakten Prompts erkannten die Angreifer, dass das Tool internal_api_summarizer über mehr Befugnisse verfügte als vorgesehen. Dem Bot wurde übermäßige Handlungsfreiheit (OWASP LLM06:2025) gewährt, was bedeutet, dass seine Berechtigungen weit über seine kundenorientierte Rolle hinausgingen. Die Angreifer erstellten daraufhin einen neuen Prompt, der als interne Analyseaufgabe getarnt war und den Bot anwies, diese API zu verwenden, um die Kundendatenbank direkt abzufragen.
Da die interne API nicht ausreichend gesichert war, führte sie die Anfrage aus und gab sensible Kundendaten – darunter Namen, Sozialversicherungsnummern und Kontostände – über die Chatbot-Schnittstelle direkt an den Angreifer weiter.
Phase 4: Laterale Bewegungen und Kompromittierung der Infrastruktur über Befehls-Injection
Die Eindringlinge nutzten dann den kompromittierten Chatbot als Proxy, um die interne API auf herkömmliche Schwachstellen zu untersuchen. Sie entdeckten eine Schwachstelle bei der Befehlseinschleusung aufgrund einer unsachgemäßen Ausgabeverarbeitung (OWASP LLM05:2025). Die API versäumte es, den vom Bot empfangenen Text zu bereinigen, bevor sie ihn als Systembefehl ausführte.
Durch die Erstellung eines Prompts mit einem einfachen Befehl (test; ls -la /app) brachten sie den Bot dazu, eine bösartige Payload an die API zu senden. Die API führte den Befehl aus, und die Ausgabe – eine Auflistung der Dateien der Anwendung – wurde als „Zusammenfassung” zurückgesendet. Dies lieferte den eindeutigen Beweis für die Ausführung von Remote-Code, wodurch sich die Angreifer lateral von der KI-Anwendung in die zugrunde liegende Microservice-Infrastruktur bewegen konnten.
Phase 5: Auswirkung und Kompromittierung der Credentials in den Daten-Stores
Nachdem sie sich dauerhaft auf dem Server etabliert hatten, fanden die Akteure eine Konfigurationsdatei und lasen sie aus. Sie enthielt die API-Schlüssel und Anmeldedaten für die Vektordatenbank, in der die proprietären Daten für das RAG-System (Retrieval Augmented Generation) von FinBot gespeichert waren, sowie den Cloud Speicher-Bucket, der die fein abgestimmten KI-Modelle selbst enthielt.
Dies verdeutlicht Schwachstellen wie Vektor- und Einbettungsschwächen (OWASP LLM08:2025), bei denen ein Eindringling, der sich Zugang zum internen Netzwerk verschafft hat, auf schlecht gesicherte Datenspeicher zugreifen kann. Die Angreifer konnten nun riesige Mengen proprietärer Daten exfiltrieren und das wertvolle geistige Eigentum des Unternehmens stehlen: die benutzerdefinierten KI-Modelle.
Verhindern eines KI-Einbruchs über Verteidigung in mehreren Schichten
Unser Szenario zeigt, dass es bei der Absicherung von KI nicht um eine einzelne Lösung geht, sondern um den Aufbau einer robusten, mehrschichtigen Verteidigung. Eine moderne Sicherheitsplattform muss Transparenz und Kontrolle über den gesamten KI-Technologie-Stack bieten, vom proaktiven Scannen über Echtzeitschutz bis hin zur Infrastruktursicherheit.
Dieser Ansatz steht im Einklang mit etablierten Cybersicherheits-Frameworks wie dem NIST AI Risk Management Framework (AI RMF) und der CISA Zero Trust Architecture (ZTA) und trägt gleichzeitig zu einer umfassenderen Governance und Rechenschaftspflicht bei, wie sie von internationalen Standards wie ISO/IEC 42001 gefordert werden.
Prävention beginnt lange bevor eine Anwendung live geht. Ein proaktiver „Shift Left“-Ansatz identifiziert Risiken frühzeitig im Entwicklungszyklus. Sobald eine KI-Anwendung im Einsatz ist, bedarf es der Echtzeit-Sicherheitsvorkehrungen, um ihr Verhalten zu überprüfen und zu kontrollieren. Findet ein Angreifer einen Weg durch die ersten Schichten, verlagert sich der Fokus der Verteidigung auf die Eingrenzung und den Schutz der zugrunde liegenden Infrastruktur.
Trend Vision One™ bietet mit seinen Modulen einen solchen mehrschichtigen Schutz für alle Phasen einer KI-Anwendung. Die Lösung integriert eine umfassende Reihe von Funktionen zur Sicherung des gesamten KI-Stacks. Es adressiert kritische Sicherheitsherausforderungen auf jeder Ebene, von den grundlegenden Daten bis hin zum Endbenutzer. Dazu gehören die Sicherung sensibler Daten zur Vermeidung von Schwachstellen, die Validierung von Pipelines für kontinuierliche Integration und kontinuierliche Bereitstellung/Implementierung (CI/CD) zur Minderung von Schwachstellen in der Lieferkette sowie die Durchsetzung von Kontrollen zur Verhinderung von KI-Modellvergiftung oder unsachgemäßer Verwendung.