M365 Defender | MC1253510 eröffnet beunruhigendes

Zwischen dem 17. Februar und dem 17. November 2025 hat Microsoft Defender for Cloud Apps (MDA) einen Teil der Entra ID Anmeldeereignisse nicht verarbeitet. Ursache war laut Microsoft ein Code-Fehler in der Datenpipeline, die Sign-in-Events aus Entra ID an MDA übergibt.

Die Ereignisse selbst gingen nicht verloren, sie lagen weiterhin in Entra ID vor. In MDA fehlten sie aber neun Monate lang, wodurch Aktivitätsansichten, Aktivitätswarnungen, die Anomalieerkennung, MDA-gespeiste Advanced-Hunting-Tabellen, die Sentinel-Integration über MDA-Datenpfade und die Auswertung von Dateirichtlinien mit unvollständigen Daten arbeiteten.

Microsoft hat den Fehler am 30. November 2025 behoben und den Vorfall am 16. März 2026 über den Message-Center-Beitrag MC1253510 offengelegt, also dreieinhalb Monate nach dem Fix. Die Benachrichtigung ging mit dem Betreff "Data privacy notification available in Message Center" nur an betroffene Tenants. Microsoft schreibt, es sei keine weitere Aktion nötig.

Für die Plattform stimmt das, für Dein Security-Team nicht: Wenn Du zwischen Februar und November 2025 Untersuchungen, Compliance-Prüfungen oder Audit-Antworten auf MDA-Anmeldedaten gestützt hast, können deren Ergebnisse auf lückenhaften Daten beruhen. Die folgenden Schritte zeigen, wie Du das aufarbeitest.

weiteres dazu auf "https://blog.minerva-ia.com/en/blog/222poqnz"

Öffne das Message Center und suche nach MC1253510 beziehungsweise nach der Benachrichtigung mit dem Betreff "Data privacy notification available in Message Center". Nur betroffene Tenants haben diese Nachricht erhalten.

Findest Du die Nachricht nicht, obwohl Dein Tenant MDA aktiv nutzt, ist Dein Tenant nach Microsofts Einordnung nicht betroffen. Blind verlassen würde ich mich darauf nicht: Prüfe in dem Fall stichprobenartig, ob Dir im fraglichen Zeitraum Anmeldeaktivitäten im MDA-Aktivitätsprotokoll fehlen, die in Entra ID nachweisbar sind. Bei Widersprüchen eröffnest Du ein Support-Ticket, weil nur Microsoft die tenantbezogene Betroffenheit final bestätigen kann.

Bevor Du Untersuchungen nachziehst, brauchst Du Klarheit, womit Du sie überhaupt nachziehen kannst. Stand Juli 2026 ist der betroffene Zeitraum aus allen Standard-Retentions herausgelaufen:

Übrig bleiben drei realistische Quellen. Erstens ein Log-Analytics-Workspace oder Sentinel, sofern Du die Entra-Diagnoseeinstellungen für SigninLogs schon vor oder während des Zeitraums aktiv hattest und die Workspace-Aufbewahrung (oder das Archive-Tier) weit genug zurückreicht. Zweitens Exporte in ein Storage-Konto, einen Event Hub oder ein Dritt-SIEM. Drittens das Unified Audit Log mit Purview Audit Premium: Dort werden Entra-Datensätze ein Jahr aufbewahrt, wodurch Du von heute aus noch die Anmeldeereignisse ab Mitte Juli 2025 erreichst, also das letzte Drittel des betroffenen Zeitraums. Dieses Fenster schrumpft täglich, weshalb dieser Schritt keinen Aufschub verträgt.

Dokumentiere das Ergebnis dieser Inventur schriftlich: welche Quelle welchen Teil des Zeitraums abdeckt und wo dauerhaft nichts mehr rekonstruierbar ist. Diese Feststellung brauchst Du später für die Audit-Dokumentation in Schritt 6.

Erstelle eine Liste aller Security-Untersuchungen, Compliance-Prüfungen und Audit-Antworten zwischen dem 17. Februar und dem 17. November 2025, in die MDA-Anmeldedaten eingeflossen sind. Typische Kandidaten: Kompromittierungsverdachte, Offboarding-Prüfungen, Impossible-Travel-Fälle, Auswertungen für Datenschutz oder Betriebsrat. Microsoft gibt an, der Fix habe die Verarbeitung der betroffenen Ereignisse wiederhergestellt.

Ob die historischen Events damit rückwirkend vollständig in MDA sichtbar wurden, geht aus der Meldung nicht eindeutig hervor. Deshalb gleichst Du jede dieser Untersuchungen gegen die Entra-Quellen ab, deren Daten von der Lücke nie betroffen waren.

Liegen die SigninLogs in Log Analytics oder Sentinel, prüfst Du gezielt pro Fall (kql):

Fehlt Dir der Workspace, bleibt das Unified Audit Log mit Audit Premium für den Restzeitraum ab Mitte Juli 2025:

Pro Untersuchung hältst Du eines von drei Ergebnissen fest: Ergebnis bestätigt, Ergebnis muss revidiert werden, oder Zeitraum nicht mehr prüfbar. Auch die dritte Kategorie ist ein dokumentationspflichtiges Ergebnis, kein Grund zum Weglassen.

Sentinel war nur dort betroffen, wo Daten über MDA hereinkamen. Analyseregeln und Hunting-Queries auf der Tabelle SigninLogs aus den Entra-Diagnoseeinstellungen haben im gesamten Zeitraum korrekt gearbeitet. Regeln auf MDA-gespeisten Tabellen dagegen nicht: Dazu zählt IdentityLogonEvents, weil diese Tabelle ihre Entra-Anmeldedaten aus Defender for Cloud Apps bezieht, und je nach Regellogik auch CloudAppEvents.

Gehe Deine aktiven Analyseregeln durch und ordne jede Regel ihrer Datenquelle zu. Im Portal geht das über die Regelübersicht, bei vielen Regeln schneller per PowerShell mit Get-AzSentinelAlertRule aus dem Modul Az.SecurityInsights und einem Filter auf die Query-Eigenschaft.

Ein Hinweis zur Tabellenwahl für die Zukunft: Die Advanced-Hunting-Tabelle EntraIdSignInEvents (bis zum 9. Dezember 2025 AADSignInEventsBeta, benötigt Entra ID P2) bezieht ihre Daten direkt aus Entra ID und war von der MDA-Lücke nicht betroffen. Wo Deine Detections nur Anmeldesignale brauchen, ist der direkte Entra-Pfad die bessere Wahl, weil er eine Pipeline-Abhängigkeit weniger hat.

Die MDA-Anomalieerkennung baut Verhaltens-Baselines aus historischen Daten. Neun Monate unvollständige Anmeldedaten verzerren diese Baselines, weshalb nach dem Fix am 30. November 2025 mit erhöhten False-Positive- und False-Negative-Raten zu rechnen war.

Prüfe rückblickend Deine Alert-Statistik seit Dezember 2025: Ein Anstieg von Impossible-Travel- oder Unusual-Sign-in-Alerts in dieser Phase ist mit hoher Wahrscheinlichkeit der Rekalibrierung geschuldet und kein Angriffsindikator. Umgekehrt gilt: Ausbleibende Alerts im betroffenen Zeitraum sind kein Beleg dafür, dass nichts passiert ist.

Für ISO-27001-zertifizierte Organisationen berührt der Vorfall die Controls A.8.15 (Protokollierung) und A.8.16 (Überwachungsaktivitäten), dazu A.5.22, weil MDA eine überwachte Lieferantendienstleistung ist, deren Ausfall Du bewerten musst. NIS2-regulierte Unternehmen nehmen den Vorfall in die Risikomanagement-Dokumentation auf.

Das Dokument sollte enthalten: den Zeitraum und die betroffenen Funktionen, das Ergebnis Deiner Betroffenheitsprüfung, die Liste der nachgezogenen Untersuchungen mit Ergebnis, die dauerhaft nicht mehr prüfbaren Zeiträume aus Schritt 2 und die abgeleiteten Maßnahmen. Damit belegst Du im nächsten Audit, dass Du den Vorfall bewertet hast, statt ihn erst auf Nachfrage des Auditors zu entdecken.

Der Vorfall hinter MC1253510 ist unangenehmer als eine gewöhnliche Störung, weil er das Vertrauensmodell eines Sicherheitsprodukts trifft. Ein CASB, der neun Monate lang einen Teil der Anmeldesignale nicht sieht, erzeugt in dieser Zeit keine Fehlermeldung, sondern Stille, und Stille liest ein SOC als Normalzustand.

Dass die Lücke erst nach neun Monaten geschlossen und dreieinhalb Monate nach dem Fix offengelegt wurde, verschärft das Problem: Die Standard-Retentions von Entra-Portal, Advanced Hunting und MDA waren zum Zeitpunkt der Offenlegung für den Großteil des Zeitraums bereits abgelaufen. Wer keine eigenen Log-Exporte betreibt, kann heute nur noch über Purview Audit Premium einen Rest des Zeitraums rekonstruieren.

Daraus folgen zwei dauerhafte Konsequenzen für Deinen Betrieb. Erstens: Entra-Diagnoseeinstellungen mit Export nach Log Analytics oder in ein Storage-Konto sind keine Kür, sondern die einzige Versicherung gegen genau diese Fallkonstellation, bei der ein Cloud-Anbieter eine Lücke erst nach Ablauf der Portal-Retention meldet. Zweitens: Das Monitoring braucht selbst ein Monitoring.

Ein wöchentlicher Plausibilitätscheck, der Ereigniszahlen in MDA gegen die Entra-SigninLogs stellt, hätte diese Lücke im eigenen Tenant nach Tagen sichtbar gemacht statt nach Monaten. Microsofts Formulierung, es sei keine weitere Aktion nötig, beschreibt den Zustand der Plattform. Den Zustand Deiner Nachweise beschreibt sie nicht, und genau dafür bist Du zuständig.