MFA ausgetrickst: Microsoft-Hack sprengt NIS2-Compliance

Wie der Sicherheitsvorfall bei Microsoft die Compliance gefährdet.

Seit Mai 2026 beobachtet Microsoft Security Research Social-Engineering-Kampagnen, bei denen Angreifer das Thema Passkeys und Single Sign-On (SSO) als Vorwand nutzen, um Sicherheitsbarrieren zu umgehen.

Zusammenfassung (TL; DR):

• Angreifer erbeuteten durch gezieltes Social Engineering aktive Benutzersitzungen von Beschäftigten und umgingen so die MFA-Barrieren von Microsoft.
• Über die Microsoft-Graph-API luden die Täter im Anschluss tagelang unbemerkt große Datenmengen aus SharePoint, OneDrive und Exchange herunter.
• Aufgrund der strengen Vorgaben des NIS2-Umsetzungsgesetzes für Meldungen und Sicherheitsnachweise zwingt dieser Vorfall Unternehmen zu einer attributbasierten Zugriffskontrolle auf Inhaltsebene.

Falsche interne IT-Helpdesk-Mitarbeiter

Anrufer gaben sich als interne IT-Helpdesk-Mitarbeiter aus, kontaktierten Beschäftigte auf ihren privaten Mobiltelefonen und teilten ihnen mit, ihre Passkey- oder Mehrfaktor-Authentifizierung müsse dringend aktualisiert werden.

Die Anrufe führten die Opfer auf täuschend echte Microsoft-Anmeldeseiten. Von dort nutzten sie Adversary-in-the-Middle-Proxys oder Device-Code-Phishing, um aktive Sitzungen abzugreifen und registrierten in mehreren Fällen einen eigenen Authenticator als vertrauenswürdige MFA-Methode für das Konto.

Der Datenabfluss im Schatten der Graph-API

Interessant ist aber erst, was danach kam. Die Angreifer nutzten die Graph-API, um Benutzer, Gruppen und Berechtigungen zu kartieren und luden anschließend über Stunden oder mehrere Tage hinweg große Mengen an Daten aus SharePoint Online, OneDrive for Business und teilweise Exchange Online herunter. Microsofts eigene Einschätzung dazu verdient besonderes Augenmerk. Der Missbrauch der Graph-API „erscheint bei Betrachtung eines einzelnen API-Aufrufs kaum verdächtig” , wie es im Bericht sinngemäß heißt.

Kein Passkey-Problem

Dieser Satz beschreibt ein Problem, das mit Passkeys nichts zu tun hat. Die Identität ist inzwischen der eigentliche Perimeter für Unternehmensinhalte geworden und die Angreifer haben das erkannt. Laut CrowdStrike 2026 Global Threat Report  kamen 82 Prozent der 2025 registrierten Angriffe ohne jegliche Malware aus, gegenüber 51 Prozent fünf Jahre zuvor. Angreifer melden sich zunehmend einfach an, statt sich hineinzuhacken.

Der Compliance-Druck durch NIS2 und BSI

Für einen deutschen Compliance-Verantwortlichen oder Datenschutzbeauftragten liegt die eigentliche Verschärfung woanders. Seit dem Dezember 2025 ist das deutsche NIS2-Umsetzungsgesetz in Kraft und betrifft rund 30.000 Unternehmen. Betreiber kritischer Anlagen müssen dem BSI alle drei Jahre konkrete Nachweise über die Umsetzung ihrer Sicherheitsmaßnahmen vorlegen, zusätzlich zur unverzüglichen Meldepflicht innerhalb von 24 Stunden bei erheblichen Sicherheitsvorfällen.

Sicherheitsmodell stößt an seine Grenzen

Genau an dieser Nachweispflicht zeigt sich, warum das übliche Sicherheitsmodell an seine Grenzen stößt. Die meisten Plattformen behandeln die Anmeldung als einmaliges Tor. Ist die MFA-Prüfung bestanden, gilt die Sitzung für alles, was sie umfasst, als vertrauenswürdig, bis sie abläuft oder jemand etwas bemerkt. Ein Compliance-Team, das im Ernstfall belegen soll, welche konkrete Richtlinie einen bestimmten Dateizugriff autorisiert hat, findet dafür keinen einzelnen Log-Eintrag, weil die Plattform diese Frage im Moment des Zugriffs nie gestellt hat.

Sie hat nur festgehalten, dass eine Anfrage stattfand und dass eine gültige Sitzung sie ausgelöst hat. Das ist genau der Grund, warum Microsoft diese Form der Datenexfiltration als praktisch unsichtbar beschreibt, solange man nur einzelne API-Aufrufe betrachtet.

24-Stunden-Meldepflicht

Die 24-Stunden-Meldepflicht des NIS2-Umsetzungsgesetzes verschärft dieses Problem. Wer dem BSI innerhalb eines Tages eine erste Einschätzung eines erheblichen Sicherheitsvorfalls liefern muss, braucht dafür belastbare Informationen darüber, welche Inhalte betroffen waren und wie der Zugriff zustande kam. Ein Satz von Rohdaten aus einzelnen, unverbundenen API-Aufrufen liefert diese Einschätzung nicht in der geforderten Zeit. Erst die Korrelation über mehrere Ereignisse hinweg macht aus einem Log eine belastbare erste Meldung.

Attributbasierte Zugriffskontrolle als Lösung

Eine Lösung beginnt nicht allein bei besserem Phishing-Training, auch wenn Sensibilisierung und Training weiterhin ihren Platz haben. Der wirksamere Ansatz behandelt jede einzelne Inhaltsanfrage – eine Datei, ein Postfach, einen freigegebenen Ordner – als etwas, das im Moment des Zugriffs gegen eine Richtlinie geprüft wird, unabhängig davon, wie gut authentifiziert die anfragende Sitzung erscheint. Eine attributbasierte Zugriffskontrolle auf Inhaltsebene sorgt dafür, dass eine gekaperte Sitzung nicht automatisch die gesamte Reichweite des zugehörigen Kontos erbt.

Protokollierung zur Unterstützung

Der zweite Baustein ist eine Protokollierung, die über einzelne Ereignisse hinweg gelesen werden kann, nicht nur innerhalb eines einzelnen Ereignisses. Ein einzelner Graph-API-Aufruf zum Auflisten von Dateien wirkt für sich genommen unauffällig. Ein Muster aus Enumeration, gefolgt von tagelangen Massendownloads über SharePoint, OneDrive und Exchange hinweg, ist alles andere als unauffällig – allerdings nur, wenn tatsächlich etwas diese Ereignisse miteinander in Beziehung setzt, statt sie als vereinzelte Zeilen in einem ohnehin vollen Protokoll abzulegen.

Was Aufsichtsbehörden erwarten

Für Vorstände und Aufsichtsräte lohnt sich an dieser Stelle ein nüchterner Vergleich. Ein Compliance-Team, das eine konkrete Richtlinie und einen konkreten Zeitpunkt für jeden Dateizugriff vorlegen kann, befindet sich in einer grundlegend anderen Position gegenüber dem BSI oder einer Datenschutzaufsichtsbehörde als eines, das nur eine Liste von API-Aufrufen und eine nachträgliche Rekonstruktion liefern kann. Der Unterschied ist keine Frage der Technikpräferenz, sondern der Unterschied zwischen einem vorbereiteten Nachweis und einer unter Zeitdruck zusammengestellten Vorfallschronik.

Sicherheitsvorfall bei Microsoft war kein klassisches Hacking

Das NIS2-Umsetzungsgesetz macht aus einer guten Idee eine terminierte Pflicht. Wer alle drei Jahre konkrete Nachweise gegenüber dem BSI erbringen muss, kann sich nicht mehr darauf verlassen, dass ein bestandener Login als Beleg für ordnungsgemäßen Zugriff ausreicht. Der Sicherheitsvorfall bei Microsoft war kein klassisches Hacking.

Häufige Fragen (FAQ)