In vielen Tenants, die ich begleite, gehört Microsoft 365 Copilot inzwischen zum Alltag. Im Juni 2025 wurde dann etwas bekannt, bei dem viele erst einmal schlucken mussten: EchoLeak, ein Zero-Click-Angriff auf Copilot (CVE-2025-32711). Angreifer konnten über präparierte E-Mails oder Dokumente KI-Kommandos einschleusen, ohne dass die Nutzer davon etwas merkten. Microsoft hat die Schwachstelle zeitnah serverseitig behoben und nach eigenen Angaben keine Angriffe beobachtet. Mit den technischen und organisatorischen Lehren sollte man sich trotzdem beschäftigen, denn das Grundproblem bleibt bestehen. Indirekte Prompt-Injektion, genauer die Cross-Prompt-Injection-Attack (XPIA), ist längst keine Science-Fiction mehr. Seit KI fest im Arbeitsalltag steckt, ist sie ein reales Risiko.

EchoLeak nutzte den Kontext aus, den Copilot für seine Antworten heranzieht

Mit den Exploits, die man aus der Zeit von Makroviren oder verseuchten Dateianhängen kennt, hat EchoLeak wenig gemeinsam. Die Lücke beruhte darauf, dass Microsoft 365 Copilot Inhalte aus E-Mails, Dokumenten und Nachrichten als Kontext für KI-Abfragen verwendet. Steckten in diesen Quellen versteckte Anweisungen, konnten sie die KI dazu bringen, sensible Daten preiszugeben oder interne Vorgaben zu übergehen. Die betroffenen Nutzer mussten dafür selbst nichts tun. Der Angriff lief also auf Umwegen, über an sich legitime Inhalte, die Copilot verarbeitete. In Microsofts Sicherheitsbewertung heißt es ausdrücklich, dass weder eine Benutzereingabe noch ein Klick nötig war. Geschlossen wurde die Lücke serverseitig, Kunden mussten also nichts unternehmen. Dennoch hat EchoLeak eine Debatte angestoßen: Wie lassen sich solche Angriffe künftig verhindern oder ihre Reichweite zumindest eingrenzen?

Oversharing bestimmt, wie groß der Schaden einer solchen Lücke wird

In der Praxis erlebe ich immer wieder, dass das Zusammenspiel von KI und Datenfreigabe unterschätzt wird. Welchen Schaden eine Schwachstelle wie EchoLeak anrichten kann, hängt maßgeblich davon ab, worauf Copilot zugreifen darf. Liegen sensible Informationen wahllos geteilt in SharePoint, Teams oder OneDrive, oft aus Bequemlichkeit oder Unkenntnis, wächst der mögliche Schadensradius eines Prompt-Injection-Angriffs schnell ins Riesige. Hier helfen die altbekannten Prinzipien Least Privilege und Datenminimierung. Mit Restricted SharePoint Search, gezielten Freigabe- und Zugriffsrichtlinien und einer gut durchdachten Sensibilisierung der Fachbereiche lässt sich die Angriffsfläche deutlich verkleinern. Selbst die besten technischen Copilot-Kontrollen bringen nichts, wenn im Hintergrund Dokumente unkontrolliert geteilt werden oder Berechtigungen über Jahre wuchern.

Praktischer Tipp: Prüft mindestens einmal im Quartal, wer auf eure sensibelsten SharePoint-Bibliotheken zugreifen kann, und passt die Freigabeeinstellungen an. Damit schränkt ihr die Angriffsfläche für KI-Funktionen wie Copilot gezielt ein, gerade wenn neue Projekte oder Teams an den Start gehen.

Das folgende Ablaufdiagramm zeigt, wie schädliche Inhalte über verschiedene Kanäle in den Copilot-Kontext gelangen können:

direction TD
Eingang["E-Mail/Dokument mit injizierter Anweisung"] --> Inbox["Postfach/SharePoint"]
Inbox --> Copilot["Microsoft 365 Copilot"]
Copilot --> KI["KI-Modell"]
KI --> Antwort["Antwort an Nutzer"]

Abbildung: Indirekte Prompt-Injektion durch EchoLeak (vereinfachter Angriffsablauf)

Sensitivitätslabels und DLP schützen nur bei durchdachter Anwendung

Der Reflex „Dann schützen wir eben alles mit Sensitivitätslabels!“ ist nachvollziehbar, reicht aber meist nicht. Microsoft Purview bringt mit Sensitivitätslabels und Data Loss Prevention (DLP) seit Jahren solide Werkzeuge mit, um Datenzugriff und Datenabfluss zu steuern, auch im Zusammenhang mit KI (Purview-Dokumentation). Wirksam sind Labels allerdings nur, wenn man sie konsequent und mit Plan einsetzt, bei Dateien genauso wie bei E-Mails. Je nach Richtlinie können sie verhindern, dass Copilot überhaupt auf Dateien mit der Kennzeichnung „Hoch Vertraulich“ zugreift. DLP wiederum kann dafür sorgen, dass sensible Inhalte nicht in Antworten auftauchen. In der Realität sind Labels aber oft zu pauschal oder gar nicht gesetzt, und die DLP-Regeln haben mit der KI-Nutzung kaum etwas zu tun. Wer Copilot einsetzt oder das vorhat, sollte seine Label- und DLP-Strategie spätestens jetzt überprüfen und nachschärfen. Andernfalls bleibt eine Lücke, die kein Patch schließen kann. Wie das konkret aussehen kann, beschreibe ich ausführlich im Beitrag Copilot und Sensitivitätslabels: Wie Daten geschützt bleiben.

Purview Audit macht Copilot-Interaktionen nachvollziehbar

Zu EchoLeak sind laut Microsoft zwar keine Exploits bekannt geworden, nachvollziehen können muss man KI-Interaktionen trotzdem. Dafür gibt es das Purview-Audit-Log, das sämtliche Copilot-Interaktionen protokolliert, sofern die nötigen Audit-Funktionen aktiviert sind (Microsoft 365 E5, Purview Audit Premium). Ganz so feingliedrig wie bei klassischen Dateioperationen ist die Aufzeichnung nicht. Man sieht aber, welche Benutzer welche Anfragen gestellt haben und in welchen Kontexten Copilot darauf zugegriffen hat. Für forensische Untersuchungen und Compliance-Prüfungen ist das ein wichtiger Baustein. Weitere Details und typische Stolpersteine bei der Auditierung von Copilot habe ich im Beitrag Copilot-Interaktionen, Audit und Aufbewahrung: Was passiert wirklich mit euren Prompts? zusammengetragen.

DSPM für KI macht Risiken sichtbar und begrenzt den Blast Radius

Interessant finde ich, dass aktuelle DSPM-Ansätze (Data Security Posture Management) inzwischen auch KI abdecken. Werkzeuge wie Microsoft Purview spüren weiterhin klassische Risiken wie unklassifizierte Daten oder zu großzügige Freigaben auf, werten mittlerweile aber auch gezielt KI-bezogene Risiken aus (Purview-DSPM für KI). Auf diese Weise fallen verborgene Risiken und offen liegende Daten auf, bevor daraus ein EchoLeak 2.0 entsteht. Am meisten erreicht man, wenn Überblick und Kontrolle zusammenkommen, also DSPM, Sensitivitätslabels und DLP gemeinsam mit regelmäßigen Berechtigungsprüfungen. Damit lässt sich der Schaden durch indirekte Angriffe am wirksamsten eingrenzen.

EchoLeak ist ein Weckruf für echte Governance

Aus den Schlagzeilen war EchoLeak schnell wieder verschwunden, die zugrunde liegenden Probleme sind aber geblieben. Mit KI kommt ein neuer Angriffsvektor hinzu, den Patches allein nicht beherrschen. Wer Oversharing duldet und Berechtigungen schleifen lässt, macht es Angriffen nach dem Muster von XPIA leicht. Mich bestärkt das in meiner Einschätzung, dass das eigentliche Sicherheitsnetz aus Data Governance, gezielt eingesetzten Sensitivitätslabels, aktivem Monitoring und einem geschärften Bewusstsein in den Fachbereichen besteht – und nicht allein aus dem nächsten Update. Wer Copilot produktiv einsetzen möchte, kommt um diese Hausaufgaben nicht herum. Sonst bleibt die Angriffsfläche dauerhaft zu groß.