KI-Würmer: Morris II, EchoLeak und wie man sich schützt

Ein alter Name für eine neue Klasse

Im März 2024 tauften drei Forscher ihren Proof of Concept „Morris II”. Der Name ist eine Verbeugung vor dem Morris-Wurm von 1988, dem ersten Computerwurm, der das Internet lahmlegte. Diesmal befällt das Ding keine Betriebssysteme, sondern KI-Assistenten. Seitdem geistert der Begriff „KI-Wurm” durch die Fachpresse, und mit jeder neuen Schlagzeile wächst die Verwirrung darüber, was real ist und was Threat-Marketing.

Sortieren wir das. Ein selbstreplizierender KI-Wurm ist bisher ausschließlich ein Forschungsexperiment. In freier Wildbahn wurde noch keiner beobachtet. Die Lücke, auf der er aufbaut, ist dagegen sehr real und in mindestens einem Produktivsystem bereits ausgenutzt worden. Genau diese Trennung macht das Thema für die Praxis interessant: Der Wurm ist Zukunftsmusik, der Mechanismus dahinter steht schon vor der Tür.

Was Morris II tatsächlich ist

Morris II ist ein „adversarialer selbstreplizierender Prompt” (Cohen, Bitton, Nassi, arXiv:2403.02817, Cornell Tech / Technion / Intuit, 2024). Hinter dem sperrigen Begriff steckt eine einfache Idee mit zwei Funktionen in einem einzigen Text.

Die erste Funktion ist die Replikation. Der Prompt weist das Sprachmodell an, den Prompt selbst wieder auszugeben. Das Modell schreibt also die Angriffsanweisung in seine eigene Antwort, und die landet im nächsten System.

Die zweite Funktion ist die Payload, die Schadaktion. Im PoC war das zweierlei: Spam versenden und personenbezogene Daten exfiltrieren, konkret E-Mail-Adressen, Telefonnummern und Postanschriften aus der laufenden Korrespondenz.

Beides zusammen ergibt etwas, das sich verhält wie ein Wurm. Die Forscher haben ihren Angriff gegen selbstgebaute E-Mail-Assistenten auf Basis von ChatGPT 4.0, Gemini Pro und LLaVA demonstriert, in Black-Box- und White-Box-Szenarien, mit Text und mit Bildern als Träger. Es war ein kontrollierter Laborversuch, kein Angriff auf ein ausgeliefertes Produkt. Das gehört zur ehrlichen Einordnung dazu.

Der Verbreitungsweg: Prompt-Injection trifft RAG

Damit ein KI-Wurm springt, braucht er zwei Zutaten, die in vielen modernen KI-Setups ohnehin zusammenkommen.

Indirekte Prompt-Injection ist der Liefermechanismus. Bei der direkten Variante tippt ein Angreifer die Schadanweisung selbst ein. Bei der indirekten versteckt er sie in Inhalten, die das Modell später ohnehin verarbeitet: in einer E-Mail, einem Dokument, einer Webseite, einem Code-Kommentar, einer Commit-Message. Getarnt wird das gern mit weißer Schrift auf weißem Grund oder mit nicht-druckbaren Unicode-Zeichen (OWASP, „LLM Prompt Injection Prevention Cheat Sheet”). Der Mensch sieht eine normale Nachricht. Das Modell liest eine Anweisung.

RAG-Vergiftung ist der Beschleuniger. RAG steht für Retrieval-Augmented Generation: Der Assistent durchsucht eine Wissensdatenbank, etwa das eigene Postfach, und schiebt die gefundenen Treffer als Kontext ins Modell. Eine präparierte Mail wandert dabei in die RAG-Datenbank des Empfängers. Bei einer späteren, völlig harmlosen Anfrage wird genau diese Mail als passender Kontext abgerufen, ins Prompt eingefügt und reaktiviert. Das Modell führt die versteckte Anweisung aus, exfiltriert Daten und schreibt die Anweisung in die ausgehende Antwort. Der nächste Empfänger ist infiziert.

Der entscheidende Punkt: Das passiert ohne Klick. Niemand muss einen Anhang öffnen oder auf einen Link tippen. Der Assistent verarbeitet die Mail automatisch, sobald sie relevant wird. Die Forscher nennen zwei Angriffsklassen: Angriffe auf Anwendungen, deren Ablauf vom Modell-Output gesteuert wird, und RAG-basierte Angriffe auf Anwendungen mit Wissensanreicherung (compromptmized.com, arXiv:2403.02817). In der Laborsimulation kompromittierte ein infizierter Client rund zwanzig weitere in ein bis drei Tagen. Diese Zahl stammt aus dem Modellversuch und lässt sich nicht eins zu eins auf echte Installationen übertragen.

EchoLeak: der Mechanismus, einmal in echt

Wer den Morris-II-PoC für reine Theorie hält, sollte sich EchoLeak ansehen. Im Juni 2025 schloss Microsoft die Lücke CVE-2025-32711, CVSS-Score 9.3, entdeckt von Aim Security. Es war der erste real-world Zero-Click-Prompt-Injection-Angriff gegen ein produktiv ausgeliefertes LLM-System, in diesem Fall Microsoft 365 Copilot (arXiv:2509.10540).

Eine einzige präparierte E-Mail genügte, um remote und ohne gültige Zugangsdaten Unternehmensdaten abzuziehen. Ohne Zugangsdaten heißt: Der Angreifer brauchte selbst keinen Account. Das Opfer war ein ganz normaler, angemeldeter Copilot-Nutzer, dessen Assistent die Mail beim Beantworten einer Anfrage als Kontext heranzog. Auch hier also das RAG-Prinzip: abgerufener Inhalt landet direkt im Prompt und steuert die Ausgabe.

Interessant ist die Verkettung. EchoLeak umging Microsofts eigenen Injection-Klassifizierer (XPIA), nutzte Markdown im Referenzstil, um die Link-Redaktion auszuhebeln, ließ Bilder automatisch nachladen und missbrauchte einen per Content-Security-Policy erlaubten Microsoft-Teams-Proxy als Abflusskanal. Kein einzelner Trick, sondern eine Kette von Umgehungen, die jede für sich harmlos aussah. EchoLeak war kein selbstreplizierender Wurm. Es war Exfiltration. Aber es bewies, dass der Liefermechanismus hinter Morris II in einem Massenprodukt funktioniert.

Microsoft hat gepatcht. Das ist die gute Seite. Die unbequeme Seite kommt jetzt.

Warum man das nicht einfach wegpatcht

Die Ursache liegt nicht in einem Programmierfehler, den man korrigiert und dann ist Ruhe. Sie liegt in der Architektur. System-Anweisung und Nutzerdaten teilen sich bei einem Sprachmodell dasselbe Format: Text in natürlicher Sprache. OWASP nennt das den „semantic gap”. Das Modell hat keine verlässliche Grenze zwischen „das ist eine Anweisung meines Entwicklers, der ich folgen soll” und „das sind Daten, die ich nur verarbeiten soll”. Das britische NCSC formuliert es ähnlich: Es gibt keine inhärente Unterscheidung zwischen Daten und Instruktion.

Deshalb taugen Filter allein nicht als Lösung. Untersuchungen zeigen Umgehungsraten von rund 89 Prozent bei GPT-4o und 78 Prozent bei Claude 3.5 Sonnet gegenüber gängigen Schutzmaßnahmen; eine Arbeit vom November 2025 („Attacker Moves Second”) umging zwölf untersuchte Verteidigungen mit über 90 Prozent Erfolg. OWASP zieht daraus einen klaren Schluss: Robuster Schutz gegen hartnäckige Angriffe verlangt fundamentale architektonische Neuerungen, nicht kleine Verbesserungen an nachträglichen Sicherheits-Trainings. Prompt-Injection ist mit der heutigen LLM-Architektur womöglich nie vollständig lösbar. Maßnahmen senken das Risiko. Sie eliminieren es nicht.

Das ist keine Panikmache, sondern eine nüchterne Designaussage. Wer einen KI-Assistenten mit Zugriff auf echte Daten und echte Aktionen ausstattet, baut eine Angriffsfläche, die qualitativ neu ist.

Was das für KMU heißt

Die meisten mittelständischen Unternehmen betreiben keine eigenen Sprachmodelle. Sie nutzen Assistenten in Microsoft 365, in Google Workspace, in einem DMS oder in einem KI-Chat. Genau dort entsteht das Risiko, und genau dort kann man es eingrenzen.

Berechtigungen sind die wichtigste Stellschraube. Ein KI-Assistent ist nur so gefährlich wie die Aktionen, die er auslösen darf. Darf er eigenständig Mails versenden, Dateien teilen, in Systeme schreiben? Jede dieser Fähigkeiten ist ein potenzieller Payload-Kanal. Das Prinzip der minimalen Rechte gilt für Agenten genauso wie für menschliche Konten, nur dass viele Unternehmen es bei der KI schlicht noch nicht anwenden. Ein Assistent, der lesen, aber nicht handeln darf, kann keinen Wurm weitertragen.

Eingehende Inhalte sind nicht vertrauenswürdig, auch wenn sie intern aussehen. Eine Mail von einem bekannten Absender kann eine versteckte Anweisung tragen, ohne dass der Absender etwas davon weiß, etwa weil sein eigener Assistent bereits infiziert ist. Wer KI-Funktionen auf Postfächer, Dokumentenarchive oder Ticketsysteme loslässt, sollte wissen, welche Quellen das Modell als Kontext heranzieht, und nicht vertrauenswürdige Quellen davon trennen.

Datenabfluss kontrolliert man am Ausgang. EchoLeak floss über einen erlaubten Proxy ab. Strikte Content-Security-Policies, eine Begrenzung, wohin ein Assistent überhaupt Verbindungen aufbauen darf, und Data-Loss-Prevention auf den klassischen Kanälen begrenzen den Schaden, falls die Injection durchkommt. Auf der Endpoint-Seite leistet das ein Werkzeug wie Acronis Cyber Protect mit, das ungewollte Datenabflüsse über Mail, Web und Wechseldatenträger unterbindet. Wer Angriffe im Netz früh sehen will, kommt um kontinuierliche Erkennung nicht herum, wie sie Enginsight mit IDS, SIEM und Anomalie-Erkennung liefert.

Souveränität schlägt Blackbox. Bei US-Cloud-Assistenten weiß man weder genau, welche Schutzschichten greifen, noch wann eine Lücke geschlossen wird. Wer KI auf eigener Infrastruktur oder bei einem europäischen Anbieter mit dokumentierter Architektur betreibt, behält die Kontrolle über Datenflüsse, Berechtigungen und Protokollierung. Für DSGVO-konforme KI im Mittelstand haben wir das in einem eigenen Ratgeber aufgeschrieben; eine EU-Plattform wie Langdock ist eine mögliche Antwort für Kunden, die KI nutzen wollen, ohne die Datenhoheit abzugeben.

Auf Entwicklerseite kommt die technische Schutzliste dazu, die OWASP und das EchoLeak-Paper nennen: Nutzereingabe strikt von System-Anweisungen trennen, Roh-Prompts nicht nach außen geben, Ein- und Ausgaben filtern, Prompt-Partitionierung, herkunftsbasierte Zugriffskontrolle und kontinuierliches adversariales Testen. Keine dieser Maßnahmen ist für sich ein Bollwerk. Zusammen, als Verteidigung in der Tiefe, verschieben sie die Hürde nach oben.

Wie wir das einordnen

KI-Würmer sind heute kein Grund, einen KI-Assistenten aus dem Haus zu werfen. Sie sind ein Grund, ihn so einzurichten, wie man auch jedes andere System mit Zugriff auf sensible Daten einrichtet: mit minimalen Rechten, klaren Datenflüssen, Erkennung und einem Backup, das im Ernstfall zurückkommt. Die Bedrohung ist eine neue Klasse. Die Werkzeuge dagegen sind in weiten Teilen die, die ohnehin auf einer NIS2-Agenda stehen.

Wer wissen will, welche KI-Funktionen im eigenen Haus bereits Aktionsrechte haben und wo der Datenabfluss ungebremst wäre, fängt am besten mit einer nüchternen Bestandsaufnahme an. Genau dort setzen wir an, bevor wir eine Empfehlung formulieren. Wie eine technische Sicherheits- und Compliance-Umsetzung im Mittelstand aussieht, zeigt unser Leitfaden zu ISO 27001 und NIS2; für die Pflichtenseite gibt es die NIS2-Übersicht. Wenn Sie das auf Ihre Umgebung übertragen wollen, sprechen Sie uns an.