KI-Assistent: Microsofts Copilot verfälschte monatelang Zugriffsprotokolle

Microsoft setzt voll auf künstliche Intelligenz: Der KI-Assistent Copilot ist mittlerweile fester Bestandteil des cloudbasierten Office-Pakets M365. Viele Unternehmen nutzen diesen Dienst auch, um geheime Informationen zu be- und zu verarbeiten. Dass jedwede Zugriffe auf derlei sensible Dokumente protokolliert gehören, versteht sich von selbst. Allerdings sah Copilot das unter bestimmten Bedingungen anders. Microsoft wusste monatelang von der Lücke, behob sie jedoch erst vor wenigen Tagen. Das Unternehmen informierte weder Betroffene noch die Öffentlichkeit.

„Copilot, fasse mir bitte den Geschäftsbericht für das zweite Quartal 2025 zusammen“ – so oder ähnlich könnte eine typische Anfrage lauten. Im „Audit-Log“, also dem Protokoll aller Zugriffe auf Dokumente in der Microsoft-Cloud, taucht dann ein Lesezugriff auf das Quelldokument durch Copilot auf. Befragte man den virtuellen Assistenten auf eine spezielle Art zu einem in M365 gespeicherten Dokument, erzeugte das jedoch lediglich einen leeren Protokolleintrag. Um dieses Verhalten zu erzeugen, genügte die Bitte, das Dokument nicht in der Antwort zu verlinken, sondern lediglich zusammenzufassen.

Dieses seltsame Verhalten fiel Zack Korman, dem CTO eines SaaS-Startups, Anfang Juli 2025 auf. Es erschien ihm problematisch, denn nur mittels vollständiger Audit-Logs können Unternehmen ihre Sicherheits- und Compliance-Anforderungen umsetzen und sich das Abfließen von Dokumenten in unbefugte Hände erkennen. Ein allzu neugieriger oder gar von Angreifern bestochener Mitarbeiter konnte den Copilot-Fehler ausnutzen und sich unerkannt Informationen verschaffen – offenkundig sind verfälschte Protokolle ein Sicherheitsproblem.

Sicherheit ist ein Prozess – aber welcher?

Korman meldete sich also beim Microsoft Security Response Center (MSRC) und vertraute darauf, dass die Profis in Redmond ihren dokumentierten Ablauf einhalten, das Problem beheben und betroffene Kunden informieren würden. Seine anfängliche Euphorie wich jedoch schnell der Ernüchterung: Zwar begann das MSRC nur drei Tage nach seiner Meldung damit, das Problem nachzustellen, doch weitere drei Tage später, am 10. Juli, hatten die Techniker offenbar bereits stillschweigend eine Fehlerbehebung ausgerollt.

Das widersprach der eigenen Prozessbeschreibung – was Korman veranlasste, noch einmal bei den Redmondern anzuklopfen und den Status zu erfragen. Am 2. August meldete der Softwareriese Vollzug: Man werde zwei Wochen später, am 17. August, eine Aktualisierung für die M365-Cloud einspielen und Korman könne einen Tag später seinen Fund veröffentlichen. Als dieser nachfragte, wann er denn eine CVE-Schwachstellenkennung für die von ihm gefundene Lücke erhalte, antwortete das MSRC abschlägig. Man vergebe generell keine CVE-IDs für Lücken in Cloud-Produkten, wenn Endkunden nicht selbst handeln müssten.

Auch das widersprach deutlich den Aussagen, die das MSRC vor etwas mehr als einem Jahr coram publico tätigte. Damals hieß es, man wolle künftig auch in Cloud-Diensten für kritische Lücken CVE-IDs vergeben, explizit auch in Fällen, in denen Kunden nicht selbst tätig werden müssen. Das solle für mehr Transparenz sorgen, versprach das MSRC im Kielwasser eines Security-GAUs: Vermutlich chinesische Angreifer hatten einen Master-Key für Azure geklaut. Doch zurück zur Copilot-Lücke: Als Korman diese Diskrepanz anmerkte, schwenkte das Microsoft-Sicherheitsteam um. Man verstehe, dass er nicht den vollen Durchblick durch den Prozess habe, hieß es leicht passiv-aggressiv, doch die Lücke sei lediglich als „wichtig“ und nicht als „kritisch“ eingestuft. Damit unterschreite sie die Microsoft-eigene Schwelle zur Vergabe einer CVE-ID.

Monatelang fehlerhafte Audit-Logs? Nicht der Rede wert!

Korman wunderte sich erneut: Von einer Klassifizierung der Sicherheitslücke wusste er bis dato nichts – üblicherweise wird diese vom betroffenen Unternehmen gemeinsam mit dem Entdecker vorgenommen und nötigenfalls ausdiskutiert. Zu Diskussionen zeigte sich Microsoft in diesem Fall jedoch genauso wenig aufgelegt wie zu Transparenz. Am 14. August teilte man Korman mit, man verzichte nicht nur auf die Vergabe einer CVE-ID, sondern plane darüber hinaus auch nicht, Kunden über die Lücke zu informieren.

Der Entdecker hatte zwischenzeitlich festgestellt, dass das Problem noch erheblich länger bestanden haben musste als ursprünglich vermutet: Bereits im August 2024, mithin ein Jahr vor Kormans Fund, hatte Michael Bargury, Gründer eines KI-Startups, in einem Vortrag auf der Sicherheitskonferenz Black Hat auf die Fehler bei der Protokollierung von KI-Dateizugriffen in der Microsoft-Cloud aufmerksam gemacht. Reichlich Zeit für den Redmonder Softwaregiganten, sich des Problems anzunehmen – dieser reagierte jedoch erst letzte Woche.

Für Unternehmen, die M365 und Copilot nutzen, bleibt ein schaler Beigeschmack. Sie müssen der Tatsache ins Auge sehen, dass ihre Audit-Protokolle möglicherweise seit Monaten fehlerhaft sind und Zugriffe stattgefunden haben, die nicht mehr nachvollziehbar sind. Auch Angreifer und Industriespione dürften die Prompt-Tricks spätestens seit der letztjährigen Black-Hat-Konferenz in ihr Instrumentarium aufgenommen haben, was die Compliance-Bauchschmerzen bei Betroffenen noch verstärken dürfte.

Microsoft rief als vertrauensbildende Maßnahme nach dem letztjährigen Azure-Disaster die „Secure Future Initiative“ aus, steht aber wegen schlampiger Sicherheitspatches und miserabler Kommunikation seit Monaten in der Kritik. heise-security-Gründer Jürgen Schmidt fasste diese in einem Kommentar mit einer rustikalen Vokabel zusammen: Bullshit. Der jüngste Vorfall scheint diesen Eindruck zu festigen.

(cku)