EchoLeak - Microsoft 365 Copilot

Zusammenfassung

EchoLeak ist der Name, den Aim Labs einer Schwachstelle in Microsoft 365 Copilot gegeben hat. Microsoft führt sie als CVE-2025-32711, eine Schwachstelle zur Offenlegung von Informationen. Die Forschenden zeigten, dass Inhalte aus einer externen, vom Angreifer verfassten E-Mail in den Copilot-Kontext abgerufen werden konnten, sobald jemand später eine gewöhnliche Arbeitsfrage stellte. Die Antwort konnte dann Organisationsdaten aus dem Tenant tragen, ohne dass die Person etwas anklicken musste.

Dieser Eintrag ist als offengelegte Schwachstelle eingeordnet. Er dokumentiert eine validierte Schwachstelle und eine Demonstration der Forschenden, aber keinen bestätigten Sicherheitsvorfall und keine bekannte böswillige Nutzung gegen Kunden.

Einordnung und Evidenzstatus

Betroffenes System und Vertrauenspfad

Microsoft 365 Copilot beantwortet Fragen mit Inhalten, auf die die angemeldete Person zugreifen kann, etwa E-Mails, Dateien und Chats. Genau beim Retrieval bricht der Vertrauenspfad: Eine E-Mail eines beliebigen externen Absenders ist variabler Inhalt, steht nach dem Abruf aber im selben modellsichtbaren Kontext wie die Anfrage und die internen Daten.

Betroffen ist deshalb nicht das Modell allein, sondern die Kombination aus breitem Datenzugriff, dem Abruf nicht vertrauenswürdiger externer Inhalte und einem Ausgabekanal, der das Netzwerk erreichen kann.

Angriffskette im Überblick

Im Überblick beschrieben die Forschenden diese Abfolge: Ein Angreifer schickt eine E-Mail an jemanden in der Zielorganisation, die wie gewöhnlicher Geschäftsinhalt wirkt. Später stellt eine Person Copilot eine Frage, durch die diese E-Mail abgerufen wird. Der abgerufene Text beeinflusst die Antwort, und die Antwort enthält Ausgaben, die beim Anzeigen Daten aus dem Kontext an ein vom Angreifer kontrolliertes Ziel senden.

Laut den Forschenden musste die Kette mehrere vorhandene anwendungsseitige Schutzmaßnahmen umgehen. Dieser Eintrag beschreibt bewusst weder die Umgehungstechniken noch den E-Mail-Wortlaut oder die beteiligten Ausgabeformate.

Demonstrierte Wirkung und beobachtete Ausnutzung

Demonstriert: In einer kontrollierten Umgebung zeigten die Forschenden einen Zero-Click-Pfad, über den Daten im Zugriff von Copilot an eine externe Partei gelangen konnten.

Gegen reale Kunden beobachtet: nichts berichtet. Öffentliche Berichte zum Microsoft-Hinweis gaben an, dass keine Ausnutzung bekannt war. Dass das Modell beeinflusst wird, ist noch nicht die Sicherheitsfolge; sie entsteht erst durch das, was die beeinflusste Ausgabe erreichen und übertragen kann.

Begünstigende Kontrolllücken

• Externe E-Mails wurden in denselben Kontext wie vertrauenswürdige interne Daten abgerufen, ohne dass nachgelagerte Kontrollen eine klare Provenienzunterscheidung durchsetzten.
• Klassifikatoren zur Erkennung injektionsähnlicher Texte ließen sich mit Text umgehen, der wie normale Geschäftspost wirkte. Das zeigt, warum probabilistische Prüfung eine Schicht und keine Grenze ist.
• Modellausgaben konnten Netzwerkanfragen an Ziele außerhalb der Organisation auslösen. Damit war ein Datenfluss vom sensiblen Kontext zu einer externen Senke möglich.
• Der breite Zugriff von Copilot auf die Daten der Person bedeutete, dass eine einzige beeinflusste Antwort viele Informationen berühren konnte.

Reaktion von Hersteller und Forschenden

Aim Labs meldete das Problem vor der Veröffentlichung an Microsoft. Microsoft veröffentlichte CVE-2025-32711 am 2025-06-11, bewertete sie im eigenen Eintrag mit CVSS v3.1 9.3 (Critical) und erklärte, die Schwachstelle sei serviceseitig vollständig behoben; Kunden mussten nichts tun.

Nachweise, die Verteidiger sichern sollten

• Aufzeichnungen, welche Elemente (zum Beispiel welche E-Mails) in eine Assistentenantwort abgerufen wurden, mit Absender- und Quellkennungen.
• Die gerenderte Ausgabe sowie alle URLs oder Ressourcen, die der Client beim Anzeigen einer Antwort geladen hat.
• Protokolle ausgehender Anfragen von Assistenten-Clients und Proxys, besonders zu unbekannten Domains kurz nach einer Antwort.
• Mailflussdaten zu eingehenden externen Nachrichten, die später vom Assistenten abgerufen wurden.

Lehren für die Abwehr

• Datenprovenienz: Kennzeichnungen externer Herkunft an abgerufenen Elementen erhalten und die Richtlinie, nicht das Modell, entscheiden lassen, was diese Herkunft beeinflussen darf.
• Informationsflusskontrolle: Jeden Ausgabekanal mit Netzwerkzugang als Senke behandeln und Flüsse vom sensiblen Kontext zu nicht freigegebenen Zielen blockieren.
• Eingabe- und Inhaltsprüfung sowie Erkennung: nützliche Signale, aber ein Fehlalarm oder ein übersehener Fall darf nichts freigeben.
• Least Privilege: begrenzen, was ein Assistent für eine Aufgabe abrufen darf, um die Reichweite einer einzelnen beeinflussten Antwort zu verkleinern.

Verwandte Lernthemen

• RAG und Retrieval - Wie RAG als Anwendungsarchitektur funktioniert: die Retrieval-Pipeline, warum Relevanz kein Vertrauen ist, Security Trimming, Provenienz, Zitate und abgeleiteter Zustand.
• Vertrauensgrenzen und Modellkontext - Was modellsichtbarer Kontext ist, warum Position kein Vertrauen erzeugt und warum Kontrollen außerhalb des Modells liegen.