SearchLeak: Ein Patch löst das strukturelle Problem nicht

SearchLeak: Ein Blick auf die Angriffskette

Um SearchLeak richtig einzuordnen, lohnt ein genauer Blick auf die drei aufeinanderfolgenden Schwachstellen, aus denen die Kette besteht:

• Stufe 1: Parameter-to-Prompt Injection. Der Angreifer bettet bösartige Anweisungen in eine präparierte Microsoft 365 Copilot-Such-URL ein. Copilot verarbeitet URL-Parameter als Teil seines Query-Kontexts – ein Designmerkmal, das für die produktive Nutzung gedacht ist, aber keine ausreichende Trennung zwischen Nutzeranweisung und externem Input durchsetzt. Das Ergebnis: Der Angreifer kann den Instruktionskontext des KI-Assistenten kontrollieren, ohne direkten Zugriff auf das System zu haben.
• Stufe 2: HTML-Rendering-Race-Condition. Die injizierten Anweisungen werden verarbeitet, bevor die Sitzungssicherheitsprüfungen vollständig abgeschlossen sind. Der zeitliche Zustand zwischen Injection und der vollständig initialisierten Sicherheitsschicht erzeugt ein Ausführungsfenster für die Angreifer-Instruktionen.
• Stufe 3: SSRF-basierter CSP-Bypass über Bing. Die erbeuteten Daten – E-Mails, MFA-Codes, Kalenderereignisse, Dateien – werden nicht direkt an eine Angreifer-Infrastruktur exfiltriert, sondern über einen Bing-Request durch eine vertrauenswürdige Microsoft-Domain geroutet. Browserseitige Content Security Policies (CSPs), die externe Ziele blockieren würden, werden so umgangen: Der ausgehende Traffic sieht aus wie ein legitimer Microsoft-API-Aufruf.

Keiner dieser drei Vektoren wäre allein kritisch. In der Kombination erzeugen sie einen vollständig authentifizierten, im Rahmen einer legitimen Infrastruktur operierenden Exfiltrations-Agenten – und zwar den KI-Assistenten des Opfers selbst.

Das Grundproblem: KI als Session-Proxy

Was SearchLeak besonders aufschlussreich macht, ist nicht die technische Raffinesse, sondern was die Schwachstelle über die Architektur moderner Enterprise-KI-Tools verrät.

Microsoft 365 Copilot – wie die meisten KI-Unternehmenstools seiner Kategorie – agiert als verlängerter Arm der Benutzersitzung. Es erbt die Zugriffsrechte des authentifizierten Nutzers: Wenn ein Nutzer auf eine E-Mail zugreifen kann, kann der KI-Assistent diese E-Mail abrufen, zusammenfassen und – wenn ein Angreifer die richtigen Anweisungen injizieren kann – exfiltrieren. Zwischen dem, was der Nutzer autorisiert ist zu sehen, und dem, wozu der KI-Assistent instruiert werden kann, existiert keine unabhängige Governance-Schicht.

Dieser Designansatz war eine bewusste Entscheidung: Er vereinfacht die Deploymentarchitektur und maximiert die Fähigkeiten des KI-Assistenten. Er erzeugt aber auch eine strukturelle Eigenschaft, die für Detection-first-Sicherheitsmodelle fundamental problematisch ist. Denn der gesamte Angriff produziert keine Anomalien, die SIEM-Systeme, DLP-Lösungen oder Zero-Trust-Netzwerkkontrollen erkennen könnten. Der Zugriff war autorisiert. Die Identität war valide. Das Gerät war sauber. Der Exfiltrationspfad war eine vertrauenswürdige Microsoft-Domain. Jedes Detektions-Tool meldete einen normalen KI-Assistenzbetrieb – weil der Traffic sich strukturell nicht von einem normalen KI-Assistenzbetrieb unterschied.

NIS2 und DSGVO: Die Konsequenzen für Unternehmen

Für in Deutschland tätige Unternehmen – insbesondere KRITIS-Betreiber und Organisationen unter dem NIS2-Umsetzungsgesetz – hat SearchLeak direkte regulatorische Relevanz.

NIS2 verpflichtet betroffene Einrichtungen, geeignete technische und organisatorische Maßnahmen zu implementieren, um Sicherheitsrisiken zu managen. Eine KI-Deployment-Architektur ohne unabhängige Zugriffs-Governance-Schicht – bei der der KI-Assistent als unkontrollierter Session-Proxy agiert – ist eine Konfiguration, die NIS2-Auditoren nach einem Vorfall kritisch bewerten werden. Die Frage ist nicht, ob die Schwachstelle gepatcht war, sondern ob die Architekturentscheidung, die sie ausnutzbar machte, einer angemessenen Risikoabwägung standgehalten hat.

Unter der DSGVO gelten die Zugangskontrollpflichten nach Artikel 32 explizit für die automatisierte Verarbeitung personenbezogener Daten. Ein KI-Assistent, der im Rahmen seiner normalen Funktion auf E-Mails, Kalendereinträge und Authentifizierungsdaten von Mitarbeitern zugreift, verarbeitet personenbezogene Daten. Die Frage, ob diese Verarbeitung unter ausreichender technischer Kontrolle stattfindet – insbesondere ob der KI-Zugriff auf klassifizierte Daten durch eine attributebasierte Zugriffskontrolle (ABAC) Governance-Seitig abgesichert ist –, müssen Datenschutzbeauftragte in ihre Risikofolgenabschätzungen aufnehmen.

Das BSI hat in seinen KI-Sicherheitsrichtlinien klargestellt, dass KI-Systeme, die auf Unternehmensdaten zugreifen, als eigenständige Principals im Zugriffsmodell behandelt werden müssen – nicht als Erweiterung der Benutzersitzung. SearchLeak liefert für diese Anforderung sozusagen die Fallstudie.

Wie gegensteuern: ABAC für KI-Agenten

Die Kontrolle, die SearchLeak auf der Policy-Ebene gestoppt hätte, ist architektonisch klar definiert: Eine attributebasierte Zugriffskontrolle (ABAC), angewendet auf den KI-Agenten als eigenständigen Principal.

In einem ABAC-Modell für KI-Zugriffe wird jede vom KI-Assistenten initiierte Datenanfrage gegen eine Policy-Engine ausgewertet, bevor Daten zurückgegeben werden. Die Policy evaluiert in Echtzeit:

• Datenattribute: Klassifizierung der Datei (Vertraulich, Personenbezogen, Authentifizierungsdaten), Speicherort, Tags
• Benutzerattribute: Rolle, Abteilung, Freigabestufe, geografischer Kontext
• Kontextattribute: Art des Zugriffs (Nutzeranfrage vs. automatisierte Abfrage), Zeitstempel, Gerätezustand, Anfragepfad

Eine solche Policy hätte die SearchLeak-Harvesting-Phase unabhängig davon, welche Anweisungen in den KI-Kontext injiziert wurden, abgebrochen. Das ist der strukturelle Unterschied zwischen KI als Session-Proxy und KI als governed Principal: Im ersten Modell bestimmt die Injection, was abgerufen wird. Im zweiten Modell bestimmt die Policy, was abgerufen werden darf – und die Policy ist nicht manipulierbar durch den KI-Kontext selbst.

„Die Entdeckung der SearchLeak-Schwachstelle verdeutlicht eindringlich, dass das aktuelle Sicherheitsdesign von Enterprise-KI-Tools, die lediglich als Erweiterung der Benutzersitzung agieren, ein massives strukturelles Risiko darstellt.“

Marc ten Eikelder, Kiteworks

Was Security-Teams jetzt tun sollten

SearchLeak ist kein isoliertes Ereignis. Es ist eine öffentlich dokumentierte Demonstration einer Angriffskategorie, die Sicherheitsforscher wie Angreifer jetzt aktiv auf alle anderen Enterprise-KI-Plattformen anwenden werden.

Für deutsche Unternehmen bedeutet das konkret:

• KI-Assistenten, die auf Unternehmensdaten zugreifen, müssen in die Bedrohungsszenarien einbezogen werden – nicht als “Tool”, sondern als Datenzugriffsprinzipal mit eigenem Risikowert.
• Der AI-as-session-proxy-Ansatz ist ein Architekturrisiko, das durch eine ABAC-basierte Zugriffskontrolle adressiert werden muss.
• Audit-Logs für KI-initiierte Datenzugriffe müssen die gleiche Granularität aufweisen wie Logs für menschliche Zugriffe. Eine forensische Analyse nach einem Vorfall setzt voraus, dass diese Daten existieren.

Fazit

Die Entdeckung der SearchLeak-Schwachstelle verdeutlicht eindringlich, dass das aktuelle Sicherheitsdesign von Enterprise-KI-Tools, die lediglich als Erweiterung der Benutzersitzung agieren, ein massives strukturelles Risiko darstellt. Da herkömmliche Überwachungssysteme solche Angriffe nicht als Anomalie erkennen können, geraten Unternehmen schnell in Konflikt mit regulatorischen Vorgaben wie NIS2 und der DSGVO. Um KI-Assistenten künftig sicher zu betreiben, müssen Security-Teams diese zwingend als eigenständige Datenzugriffs-Principal behandeln. Nur durch die Implementierung einer unabhängigen, attributbasierten Zugriffskontrolle (ABAC) lässt sich die Datenhoheit auf Policy-Ebene wirksam verteidigen.

Über den Autor:
Marc ten Eikelder ist Head of EMEA Marketing und Senior Director of Industry Research bei Kiteworks und arbeitet seit über zehn Jahren an der Schnittstelle zwischen technischer Datensicherheits-Architektur, regulatorischer Compliance und Marktkommunikation in der DACH-Region.

Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.