Ein Klick statt Alarm: Warum das Muster so gefährlich ist
Stellen Sie sich vor, Ihr Team öffnet einen harmlos wirkenden Link, um „eine Antwort zu finden“. Nicht der klassische Anhang, nicht ein Admin-Tool, nicht einmal eine sichtbare Datei. Stattdessen läuft ein Such-Workflow in Microsoft 365 Copilot Enterprise an – und damit eine Maschine, die aus E‑Mail, Kalender, OneDrive und SharePoint aufräumt, statt sie zu beschützen. Der eigentliche Bruch liegt nicht darin, dass Angreifer neue Daten „erfinden“, sondern dass sie vorhandene Daten zielgerichtet aus dem Unternehmenssystem herausziehen und dabei die Opfer-Interaktion auf ein Minimum reduzieren.
Das ist die neue Schlagrichtung: Nicht nur Sicherheitslücken in Einzelkomponenten, sondern verkettete Effekte über Produktgrenzen hinweg. In der Praxis wird der Angriff so gefährlich, weil er sich in normale Benutzerflüsse einbettet. Wenn das Ereignis für den Nutzer nicht sichtbar ist, wird es auch für das SOC schwerer: Keine offensichtliche Exfiltration, kein „Upload“, keine auffällige Aktion am Endpoint – der Datenabfluss tarnt sich als legitime Suche.
Search by Prompt: Wenn Parameter den Cursor auf vertrauliche Daten lenken
Copilot Enterprise Search unterscheidet sich vom klassischen Copilot-Bildgenerator-Gefühl: Es schreibt nicht primär Content aus dem Nichts, sondern durchsucht vorhandene Unternehmensquellen. Genau diese Deterministik macht den Angriffsraum attraktiv. Wer den Suchparameter missbrauchen kann, bekommt Zugriff auf das, was ohnehin bereits indexiert und im Zugriffskontext vorhanden ist.
Der Kern des Problems ist ein Muster, das man aus anderen Bereichen kennt: Parameter-to-Prompt-Injection. Dabei wird nicht die „Anweisung“ als Text gejailbreakt, sondern die Eingabeform so präpariert, dass sie im System wie eine legitime Suchanfrage verarbeitet wird. Für Angreifer ist das ein Lottogewinn, weil Suchanfragen häufig unternehmensweit als „sicher“ gelten: Nutzer bekommen Ergebnisse, keine Downloads, keine Makros.
Wichtig ist die Implikation für Sicherheitsarchitektur: Wenn eine KI-gestützte Suche im Hintergrund Rechte und Kontext übernimmt, wird der Schutz nicht mehr nur am klassischen Perimeter oder an Dateianhängen entschieden, sondern an der Frage, welche Eingaben als autorisierte Suche gelten. Parameter sind damit nicht nur UI-Bestandteil, sondern potenzieller Einfallspunkt in die Logik des Modells und die nachgelagerte Rendering-Kette.
Race Condition als Einfallstor: HTML wird kurz „unsicher“ dargestellt
Selbst wenn die Suche erfolgreich ist, müsste ein Abflussprozess idealerweise blockiert werden. Hier zeigt sich, warum „KI-Security“ nicht ohne Web-Security auskommt: Der Angriff nutzt eine Race Condition beim HTML-Rendering.
Das Prinzip ist simpel und unbequem: Der Inhalt wird zunächst als „rohes“ HTML übertragen oder dargestellt, bevor er in einen neutralisierten Code-Block umgewandelt wird. In einem sauberen System wäre diese Zwischenphase eliminiert oder durch starke Sanitization dauerhaft ausgeschlossen. Bei einer Race Condition gibt es jedoch ein enges Zeitfenster, in dem das System Dinge tut, die es nicht tun dürfte: Schadcodeelemente können ausgeführt werden, bevor die sichere Darstellung greift.
Für die Verteidigung ist das ein Weckruf, weil es zeigt, dass selbst moderne Plattformen an der Schnittstelle zwischen „Daten“ und „Darstellung“ verwundbar bleiben. In Unternehmensumgebungen ist diese Schnittstelle selten banal: Ergebnisse werden in Browser-UI-Templates gerendert, Komponenten tauschen Daten asynchron aus, und „es passiert nur für Millisekunden“ ist in der Sicherheitswelt kein Argument, wenn es Angreifern gelingt, genau in diese Millisekunden zu treffen.
Vergleichen lässt sich das mit einer ganzen Reihe historischer Web-Klassenrisiken: XSS-Varianten, die nicht durch einen direkten Script-Tag, sondern durch Umgehungslogik oder Timing getriggert werden. Die KI macht es nur besonders attraktiv, weil Ergebnisse häufig genau dort dargestellt werden, wo die Aufmerksamkeit ohnehin liegt.
SSRF und der CSP-Umweg: Von Bing als vertrauenswürdigem Transportdienst
Der dritte Baustein dreht das Setup in Richtung Exfiltration. Server-Side Request Forgery (SSRF) ist in der Praxis ein Klassiker: Eine Anwendung, die eigentlich nur bestimmte Ressourcen „abrufen“ darf, wird dazu gebracht, Anfragen aus einer ungeplanten Umgebung heraus zu starten – und zwar gegen die Regeln.
Hier kommt ein besonders raffinierter Hebel: Es wird eine Funktion genutzt, die im Kontext einer Bildsuche arbeitet. Bildanfragen werden über Bing-Dienste abgewickelt, und dabei werden sie als „vertrauenswürdig“ eingestuft, obwohl aus Sicht der eigentlichen Sicherheitsrichtlinie externe Inhalte blockiert werden sollten. Content-Security-Policy (CSP) schützt typischerweise das Frontend davor, beliebige externe Inhalte in die Seite zu laden. Aber wenn die Anfrage den Umweg über einen Drittanbieter-/Intermediary-Kanal nimmt, ist die Frage nicht mehr „darf der Browser das“, sondern „darf das System selbst diese Anfrage so stellen“.
Das Ergebnis ist eine Art Datentransport über URL-basierte Nebenkanäle: Die gestohlenen Informationen werden in eine Bild-URL eingebettet. Anschließend wird diese URL vom Server des Angreifers abgerufen, und die Serverlogs enthalten die Daten direkt.
Für Verteidiger ist das der Teil, der die Messlatte verschiebt: Selbst wenn das Frontend korrekt sanitizes und CSP sauber konfiguriert ist, kann ein SSRF-Weg als „autorisiertes Transportrohr“ wirken. Es ist das gleiche Grundproblem wie bei vielen OAuth- oder Token-Relay-Angriffen: Wenn ein System eine vermeintlich erlaubte Kommunikation nach außen führt, wird die Exfiltration zum Engineering-Detail.
Warum die Kette so gut funktioniert: Exploit Chains statt Einzelpatches
Einzelne Schwachstellen sind oft schwer genug, aber sie lassen sich in der Regel durch Patchen, WAF-Regeln oder harte Output-Sanitization begrenzen. Eine Exploit Chain macht dagegen genau dort Stress, wo Sicherheit „gestaffelt“ wirkt.
Der Angriff besteht aus drei voneinander unabhängigen Sicherheitsmechanismen, die jeweils für sich vergleichsweise geringe Auswirkungen hätten:
Das Schreckbild ist dabei nicht nur das technische Detail, sondern die organisatorische Folge: Patch-Strategien sind oft auf einzelne CVEs ausgerichtet. Doch in echten Systemen bilden sich Angriffswege aus mehreren Schichten: Produktlogik, Frontend-Rendering, Browser-Security und Server-Services. Wenn eine Kette funktioniert, ist die eigentliche Sicherheitslücke häufig nicht die eine Komponente, sondern die fehlende vollständige Neutralisierung über den gesamten Lebenszyklus eines Datums.
Für Unternehmen bedeutet das: Risikomanagement, das nur nach „welcher CVE“ sucht, greift zu kurz. Es braucht Modelle dafür, wie KI-gestützte Features Daten verarbeiten und wo sie darstellen oder an externe Dienste weitergeben. Gerade bei Plattformen, die „Suche“ als universelles Tool anbieten, ist die Datenflusskarte komplex und die Wahrscheinlichkeit für Nebenkanäle hoch.
Was jetzt zu tun ist: Sicherheitskontrollen, die zu diesem Muster passen
Die gute Nachricht ist, dass solche Angriffsketten meist wiederkehrende Eigenschaften haben. Die schlechte Nachricht: Viele Kontrollen adressieren nur die ersten Stufen.
Das lässt sich nicht vollständig im Betrieb „weg-konfigurieren“, weil viele Komponenten in Cloud-Services liegen. Aber Unternehmen können zumindest sicherstellen, dass sie ihre Detektion und ihr Governance-Modell an den realen Datenfluss anpassen: Wer in welcher Rolle darf welche Quellen durchsuchen, welche Ergebnisse werden geloggt, und wie schnell werden anomale Muster sichtbar.
Wer verliert, wer gewinnt: Plattformen im Brennglas
Gewinner sind in solchen Szenarien selten „die Angreifer“, sondern die Teile des Systems, die Kommunikation und Darstellung zu großzügig koppeln. Wenn eine Plattform KI-Suche tief in Unternehmensdaten integriert, wird der Nutzerkontext zur Superkraft. Angreifer brauchen dann nur noch einen Weg, diese Superkraft als Transportmittel zu nutzen.
Für Anbieter ist das ein Hinweis, dass KI-Features nicht als neue Insel betrachtet werden dürfen. Web-Sicherheitspraktiken wie strikte Output-Sanitization, deterministisches Rendering ohne Zeitfenster und sichere Drittanbieter-Integrationen sind nicht „Alter Hut“, sondern die zentrale Infrastruktur.
Für Unternehmen wiederum steigt der Aufwand in der Frage, welche Daten KI-gestützte Suche „sofort“ verfügbar machen dürfen. Indexierung, Rechteauswertung und Ergebnisdarstellung sind damit nicht nur Komfortfunktionen, sondern potenzielle Angriffsflächen.
Schluss: Die nächste Sicherheitsdebatte muss an der Datenkette ansetzen
Die beunruhigendste Erkenntnis ist nicht, dass KI anfällig ist. Das ist inzwischen fast ein Gemeinplatz. Beunruhigend ist, dass ein moderner Datenabfluss über einen Klick funktioniert, weil die Sicherheitsmodelle an den Übergängen reißen: von Parameter zu Suchlogik, von Logik zu Rendering, von Rendering zu Außenkommunikation.
Die offene Frage für die nächsten Monate lautet deshalb nicht, ob Copilot „sicher genug“ ist. Sie lautet: Wie gut können Unternehmen nachweisen und überwachen, dass Daten in KI-Workflows durchgehend neutral bleiben, bevor sie das System verlassen? Solange diese Kette unvollständig gedacht wird, bleibt Exfiltration eine Frage von Timing und Transportkanälen – nicht von offensichtlichen Angriffen.
Stellen Sie sich vor, Ihr Team öffnet einen harmlos wirkenden Link, um „eine Antwort zu finden“. Nicht der klassische Anhang, nicht ein Admin-Tool, nicht einmal eine sichtbare Datei. Stattdessen läuft ein Such-Workflow in Microsoft 365 Copilot Enterprise an – und damit eine Maschine, die aus E‑Mail, Kalender, OneDrive und SharePoint aufräumt, statt sie zu beschützen. Der eigentliche Bruch liegt nicht darin, dass Angreifer neue Daten „erfinden“, sondern dass sie vorhandene Daten zielgerichtet aus dem Unternehmenssystem herausziehen und dabei die Opfer-Interaktion auf ein Minimum reduzieren.
Das ist die neue Schlagrichtung: Nicht nur Sicherheitslücken in Einzelkomponenten, sondern verkettete Effekte über Produktgrenzen hinweg. In der Praxis wird der Angriff so gefährlich, weil er sich in normale Benutzerflüsse einbettet. Wenn das Ereignis für den Nutzer nicht sichtbar ist, wird es auch für das SOC schwerer: Keine offensichtliche Exfiltration, kein „Upload“, keine auffällige Aktion am Endpoint – der Datenabfluss tarnt sich als legitime Suche.
Search by Prompt: Wenn Parameter den Cursor auf vertrauliche Daten lenken
Copilot Enterprise Search unterscheidet sich vom klassischen Copilot-Bildgenerator-Gefühl: Es schreibt nicht primär Content aus dem Nichts, sondern durchsucht vorhandene Unternehmensquellen. Genau diese Deterministik macht den Angriffsraum attraktiv. Wer den Suchparameter missbrauchen kann, bekommt Zugriff auf das, was ohnehin bereits indexiert und im Zugriffskontext vorhanden ist.
Der Kern des Problems ist ein Muster, das man aus anderen Bereichen kennt: Parameter-to-Prompt-Injection. Dabei wird nicht die „Anweisung“ als Text gejailbreakt, sondern die Eingabeform so präpariert, dass sie im System wie eine legitime Suchanfrage verarbeitet wird. Für Angreifer ist das ein Lottogewinn, weil Suchanfragen häufig unternehmensweit als „sicher“ gelten: Nutzer bekommen Ergebnisse, keine Downloads, keine Makros.
Wichtig ist die Implikation für Sicherheitsarchitektur: Wenn eine KI-gestützte Suche im Hintergrund Rechte und Kontext übernimmt, wird der Schutz nicht mehr nur am klassischen Perimeter oder an Dateianhängen entschieden, sondern an der Frage, welche Eingaben als autorisierte Suche gelten. Parameter sind damit nicht nur UI-Bestandteil, sondern potenzieller Einfallspunkt in die Logik des Modells und die nachgelagerte Rendering-Kette.
Race Condition als Einfallstor: HTML wird kurz „unsicher“ dargestellt
Selbst wenn die Suche erfolgreich ist, müsste ein Abflussprozess idealerweise blockiert werden. Hier zeigt sich, warum „KI-Security“ nicht ohne Web-Security auskommt: Der Angriff nutzt eine Race Condition beim HTML-Rendering.
Das Prinzip ist simpel und unbequem: Der Inhalt wird zunächst als „rohes“ HTML übertragen oder dargestellt, bevor er in einen neutralisierten Code-Block umgewandelt wird. In einem sauberen System wäre diese Zwischenphase eliminiert oder durch starke Sanitization dauerhaft ausgeschlossen. Bei einer Race Condition gibt es jedoch ein enges Zeitfenster, in dem das System Dinge tut, die es nicht tun dürfte: Schadcodeelemente können ausgeführt werden, bevor die sichere Darstellung greift.
Für die Verteidigung ist das ein Weckruf, weil es zeigt, dass selbst moderne Plattformen an der Schnittstelle zwischen „Daten“ und „Darstellung“ verwundbar bleiben. In Unternehmensumgebungen ist diese Schnittstelle selten banal: Ergebnisse werden in Browser-UI-Templates gerendert, Komponenten tauschen Daten asynchron aus, und „es passiert nur für Millisekunden“ ist in der Sicherheitswelt kein Argument, wenn es Angreifern gelingt, genau in diese Millisekunden zu treffen.
Vergleichen lässt sich das mit einer ganzen Reihe historischer Web-Klassenrisiken: XSS-Varianten, die nicht durch einen direkten Script-Tag, sondern durch Umgehungslogik oder Timing getriggert werden. Die KI macht es nur besonders attraktiv, weil Ergebnisse häufig genau dort dargestellt werden, wo die Aufmerksamkeit ohnehin liegt.
SSRF und der CSP-Umweg: Von Bing als vertrauenswürdigem Transportdienst
Der dritte Baustein dreht das Setup in Richtung Exfiltration. Server-Side Request Forgery (SSRF) ist in der Praxis ein Klassiker: Eine Anwendung, die eigentlich nur bestimmte Ressourcen „abrufen“ darf, wird dazu gebracht, Anfragen aus einer ungeplanten Umgebung heraus zu starten – und zwar gegen die Regeln.
Hier kommt ein besonders raffinierter Hebel: Es wird eine Funktion genutzt, die im Kontext einer Bildsuche arbeitet. Bildanfragen werden über Bing-Dienste abgewickelt, und dabei werden sie als „vertrauenswürdig“ eingestuft, obwohl aus Sicht der eigentlichen Sicherheitsrichtlinie externe Inhalte blockiert werden sollten. Content-Security-Policy (CSP) schützt typischerweise das Frontend davor, beliebige externe Inhalte in die Seite zu laden. Aber wenn die Anfrage den Umweg über einen Drittanbieter-/Intermediary-Kanal nimmt, ist die Frage nicht mehr „darf der Browser das“, sondern „darf das System selbst diese Anfrage so stellen“.
Das Ergebnis ist eine Art Datentransport über URL-basierte Nebenkanäle: Die gestohlenen Informationen werden in eine Bild-URL eingebettet. Anschließend wird diese URL vom Server des Angreifers abgerufen, und die Serverlogs enthalten die Daten direkt.
Für Verteidiger ist das der Teil, der die Messlatte verschiebt: Selbst wenn das Frontend korrekt sanitizes und CSP sauber konfiguriert ist, kann ein SSRF-Weg als „autorisiertes Transportrohr“ wirken. Es ist das gleiche Grundproblem wie bei vielen OAuth- oder Token-Relay-Angriffen: Wenn ein System eine vermeintlich erlaubte Kommunikation nach außen führt, wird die Exfiltration zum Engineering-Detail.
Warum die Kette so gut funktioniert: Exploit Chains statt Einzelpatches
Einzelne Schwachstellen sind oft schwer genug, aber sie lassen sich in der Regel durch Patchen, WAF-Regeln oder harte Output-Sanitization begrenzen. Eine Exploit Chain macht dagegen genau dort Stress, wo Sicherheit „gestaffelt“ wirkt.
Der Angriff besteht aus drei voneinander unabhängigen Sicherheitsmechanismen, die jeweils für sich vergleichsweise geringe Auswirkungen hätten:
- Eine injizierbare Eingabeform im Search-Kontext lenkt die Suche auf relevante Daten.
- Eine Race Condition im Rendering erzeugt ein kurzzeitiges Ausführungsfenster.
- Ein SSRF-/Transportkanal über Bing macht aus dem gelaunten Ergebnis einen Datenabfluss, der über Logs und HTTP-Requests nach außen verschwindet.
Das Schreckbild ist dabei nicht nur das technische Detail, sondern die organisatorische Folge: Patch-Strategien sind oft auf einzelne CVEs ausgerichtet. Doch in echten Systemen bilden sich Angriffswege aus mehreren Schichten: Produktlogik, Frontend-Rendering, Browser-Security und Server-Services. Wenn eine Kette funktioniert, ist die eigentliche Sicherheitslücke häufig nicht die eine Komponente, sondern die fehlende vollständige Neutralisierung über den gesamten Lebenszyklus eines Datums.
Für Unternehmen bedeutet das: Risikomanagement, das nur nach „welcher CVE“ sucht, greift zu kurz. Es braucht Modelle dafür, wie KI-gestützte Features Daten verarbeiten und wo sie darstellen oder an externe Dienste weitergeben. Gerade bei Plattformen, die „Suche“ als universelles Tool anbieten, ist die Datenflusskarte komplex und die Wahrscheinlichkeit für Nebenkanäle hoch.
Was jetzt zu tun ist: Sicherheitskontrollen, die zu diesem Muster passen
Die gute Nachricht ist, dass solche Angriffsketten meist wiederkehrende Eigenschaften haben. Die schlechte Nachricht: Viele Kontrollen adressieren nur die ersten Stufen.
- Sucheingaben absichern: Nicht jede Parameterform darf unvalidiert in ein Prompt- oder Query-Handling übergehen. Validierung und erlaubte Suchmuster sind besser als „wir hoffen, dass der Inhalt harmlos bleibt“.
- Rendering-Zwischenphasen eliminieren: Wenn Inhalte asynchron umgewandelt werden, sollten Systeme keine Zwischenzustände liefern, in denen JavaScript-fähige HTML-Strukturen sichtbar werden können.
- SSRF- und Außenkommunikation strenger behandeln: Externe Kanäle über Intermediaries sollten als potenzielles Exfiltrationsziel betrachtet werden, nicht als „vertrauenswürdig, weil es ein Dienst ist“.
- Telemetrie auf den Datenfluss statt auf Endpunkt-Downloads: Wenn Exfiltration über URL-Requests oder Serverlogs läuft, müssen Erkennungsregeln anders aussehen als klassisches „Outlook-Anhang hochgeladen“.
- Red-Team-Arbeitsweisen für KI-Workflows: Angriffssimulationen sollten Such-, Prompt- und Rendering-Szenarien kombinieren, nicht isolierte Tests für einzelne Feature-Buttons.
Das lässt sich nicht vollständig im Betrieb „weg-konfigurieren“, weil viele Komponenten in Cloud-Services liegen. Aber Unternehmen können zumindest sicherstellen, dass sie ihre Detektion und ihr Governance-Modell an den realen Datenfluss anpassen: Wer in welcher Rolle darf welche Quellen durchsuchen, welche Ergebnisse werden geloggt, und wie schnell werden anomale Muster sichtbar.
Wer verliert, wer gewinnt: Plattformen im Brennglas
Gewinner sind in solchen Szenarien selten „die Angreifer“, sondern die Teile des Systems, die Kommunikation und Darstellung zu großzügig koppeln. Wenn eine Plattform KI-Suche tief in Unternehmensdaten integriert, wird der Nutzerkontext zur Superkraft. Angreifer brauchen dann nur noch einen Weg, diese Superkraft als Transportmittel zu nutzen.
Für Anbieter ist das ein Hinweis, dass KI-Features nicht als neue Insel betrachtet werden dürfen. Web-Sicherheitspraktiken wie strikte Output-Sanitization, deterministisches Rendering ohne Zeitfenster und sichere Drittanbieter-Integrationen sind nicht „Alter Hut“, sondern die zentrale Infrastruktur.
Für Unternehmen wiederum steigt der Aufwand in der Frage, welche Daten KI-gestützte Suche „sofort“ verfügbar machen dürfen. Indexierung, Rechteauswertung und Ergebnisdarstellung sind damit nicht nur Komfortfunktionen, sondern potenzielle Angriffsflächen.
Schluss: Die nächste Sicherheitsdebatte muss an der Datenkette ansetzen
Die beunruhigendste Erkenntnis ist nicht, dass KI anfällig ist. Das ist inzwischen fast ein Gemeinplatz. Beunruhigend ist, dass ein moderner Datenabfluss über einen Klick funktioniert, weil die Sicherheitsmodelle an den Übergängen reißen: von Parameter zu Suchlogik, von Logik zu Rendering, von Rendering zu Außenkommunikation.
Die offene Frage für die nächsten Monate lautet deshalb nicht, ob Copilot „sicher genug“ ist. Sie lautet: Wie gut können Unternehmen nachweisen und überwachen, dass Daten in KI-Workflows durchgehend neutral bleiben, bevor sie das System verlassen? Solange diese Kette unvollständig gedacht wird, bleibt Exfiltration eine Frage von Timing und Transportkanälen – nicht von offensichtlichen Angriffen.
