Nach dem CSRB-Bericht zu Storm-0558 sollten Admins ihren Tenant prüfen

Wenn große Sicherheitsvorfälle publik werden, bleibt bei vielen Kunden, deren Tenants ich mir anschaue, ein mulmiges Gefühl zurück. Der CSRB-Bericht zu Storm-0558, der Anfang April erschienen ist, bringt das Thema zurück auf die Tagesordnung und findet diesmal deutliche Worte zur Sicherheitskultur bei Microsoft selbst. Über Verantwortung, Transparenz und technische Kontrolle wird schon seit Sommer 2023 diskutiert, seit dem Vorfall um die Gruppe Storm-0558 und den gestohlenen MSA-Signaturschlüssel. Neu ist, dass nun erstmals eine offizielle, unabhängige Bewertung der Ereignisse vorliegt. Mich als Berater interessiert vor allem, was das für den Alltag der Admins bedeutet und wo man jetzt ansetzen kann und muss.

Der CSRB-Bericht arbeitet den Angriff von Storm-0558 unabhängig auf

Storm-0558 ist ein Akteur aus China, der im Sommer 2023 mit einem gestohlenen Signaturschlüssel für Microsoft-Konten (MSA) Authentifizierungstoken fälschen konnte. So verschaffte er sich Zugriff auf Exchange-Online-Postfächer von etwa 25 Organisationen, darunter Ministerien und Regierungsbehörden. Bemerkenswert war die Raffinesse des Angriffs, ebenso aber die Tatsache, dass wichtige Details lange im Dunkeln blieben. Dazu gehört etwa, dass sich mit MSA-Signaturschlüsseln überhaupt Token signieren ließen, die Entra ID (damals noch Azure AD) akzeptierte. Wer tiefer in die Angriffswege einsteigen möchte, findet in Microsofts eigenen technischen Analysen reichlich Material (Blogpost zu Storm-0558, MSRC-Analyse). Der CSRB-Bericht kritisiert nun, wie Microsoft mit dem Vorfall umgegangen ist, vor allem die zögerliche Offenlegung und die fehlende proaktive Kommunikation. Tenant-Admins beschäftigt dagegen etwas anderes. Sie wollen wissen, wie sie überhaupt prüfen können, ob ihre Umgebung betroffen ist, und wie sie bei künftigen Angriffen besser reagieren.

Mit MailItemsAccessed werden Postfachzugriffe im Audit-Log sichtbar

Zu den wichtigsten technischen Lehren aus Storm-0558 gehört, wie sehr die Aufklärung von den Audit-Logs und ihrer Sichtbarkeit abhängt. Microsoft hat darauf reagiert und im Rahmen der Secure Future Initiative die Standardprotokollierung für alle Kunden spürbar erweitert. Das berüchtigte Audit-Event „MailItemsAccessed“ war früher nur mit Purview Audit (Premium) sichtbar und steht nun auch mit Audit (Standard) zur Verfügung. Jeder Admin kann damit im Bedarfsfall nachvollziehen, welche Postfächer von welchen Zugriffen betroffen waren. Genau diese Möglichkeit hat im Sommer 2023 vielen gefehlt. Ausführlicher bin ich in einem eigenen Beitrag darauf eingegangen: Purview Audit und MailItemsAccessed: Bessere Mailbox-Forensik.

Ein Problem begegnet mir in Projekten trotzdem immer wieder. Viele Admins wissen gar nicht, welche Logs es gibt, wo sie gespeichert werden und wie lange sie aufbewahrt bleiben. Wer erst im Krisenfall zu suchen beginnt, stößt schnell an Grenzen. Für Exchange Online, die Anmeldeprotokolle von Entra ID und die Azure-Aktivitäten sollte man mindestens diese Fragen klären: Wo landet das Audit-Log? Welche Aufbewahrungsfristen gelten im Standard (meist 90 Tage)? Muss ich in Richtung Purview Audit (Premium) oder Log Analytics erweitern? Und sind die Protokolle so geschützt, dass ein Angreifer seine Spuren nicht einfach verwischen kann?

# Beispiel: Letzte MailItemsAccessed-Events für ein Postfach abfragen
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) -Operations MailItemsAccessed -UserIds "[email protected]"

Mein Tipp aus der Praxis: Plane einen festen monatlichen Termin ein, an dem du stichprobenartig Audit-Logs prüfst. Achte vor allem auf ungewöhnliche Zugriffe und darauf, ob kritische Events wie MailItemsAccessed überhaupt auftauchen. So wird die Kontrolle zur Routine und geht im Ernstfall nicht unter.

OAuth-Apps, Token und Schatten-IT verdienen deutlich mehr Aufmerksamkeit

Storm-0558 hat vorgeführt, wie Angreifer mit gefälschten Token in Microsofts Cloud-Dienste eindringen können. Der gestohlene Signaturschlüssel mag ein Extremfall sein, am Grundproblem ändert das nichts. Wer die Token kontrolliert, hat auch die Ressourcen in der Hand. In vielen Tenants fällt mir auf, dass OAuth-Apps und die ihnen erteilten Berechtigungen kaum beachtet werden. Weil ständig neue Drittanwendungen und selbst gebaute Schnittstellen dazukommen, wird das immer wichtiger. Die Erfahrungen mit Midnight Blizzard und ähnlichen Vorfällen zeigen, dass man App-Consents regelmäßig prüfen muss (Midnight Blizzard: Lehren für OAuth-Apps und Test-Tenants).

Einen ersten Überblick bekommt man direkt im Entra-Portal unter „Unternehmensanwendungen“. Automatisierte Auswertungen, etwa per Graph-API oder KQL, helfen ebenfalls, den Überblick zu behalten. Kritische Anwendungen und solche mit weitreichenden Berechtigungen gehören regelmäßig auf den Prüfstand, und wo nötig, entzieht man ihnen Rechte. Zudem sollten die Consent-Einstellungen für Benutzer restriktiv konfiguriert sein.

Anbieter und Admins teilen sich die Verantwortung in der Cloud

Der CSRB-Bericht zu Storm-0558 macht deutlich, dass man Cloud-Dienste nicht als „Blackbox“ betrachten darf. Microsoft trägt als Betreiber eine enorme Verantwortung. Überwachung, Forensik und Angriffserkennung bleiben aber Aufgabe der Tenant-Admins und Security-Teams. Shared Responsibility bedeutet für mich ganz konkret, dass ich weiß, welche Logs ich habe, wie ich sie verarbeite und wie ich im Ernstfall reagiere. Gerade wenn der Anbieter selbst Fehler gemacht hat, sollte man sich nicht allein auf seine offiziellen Informationen verlassen. Panik bringt allerdings auch nichts. Die Cloud stellt viele Werkzeuge bereit, nur arbeiten sie nicht von allein, man muss sie auch einsetzen.

Es gibt keine Patentlösung, aber viele Stellschrauben

Nach Storm-0558 und dem CSRB-Bericht steht für mich fest, dass Security nie „abgehakt“ ist. Microsofts Secure Future Initiative ist ein Schritt. Wirklich sicher wird es aber erst, wenn Tenant-Admins die vorhandenen Möglichkeiten aktiv nutzen. Dazu gehört, Audit-Logs zu prüfen, OAuth-Apps kritisch zu beobachten, Berechtigungen zu hinterfragen und sich nicht blind auf Dienste zu verlassen. So sieht die gelebte Praxis in der Cloud heute aus. Bei meinen Kunden erlebe ich immer wieder, dass genau diese Haltung den Unterschied macht. Wer seine Stellschrauben kennt, bleibt auch bei der nächsten Sicherheitsmeldung handlungsfähig.

Vor allem hilft es, die Zusammenhänge strukturiert zu betrachten. Die folgende Übersicht zeigt, in welchen Schritten sich ein Angriff wie Storm-0558 aufdecken lässt, wenn Protokollierung und Überwachung stimmen:

flowchart TD
    KeyTheft["Signierschlüssel gestohlen"] --> TokenForge["Token gefälscht"]
    TokenForge --> MailAccess["Mailzugriff via API"]
    MailAccess --> AuditLog["MailItemsAccessed im Audit-Log"]
    AuditLog --> Detection["Erkennung durch Monitoring"]

Abbildung: So lässt sich ein Angriff nach dem Muster von Storm-0558 anhand der Logs nachvollziehen.