M365 ist broken by Design

In den letzten Tagen hatte ich gleich mehrere Sicherheitsvorfälle in Bearbeitung. Zusammen mit völlig überraschten IT-Verantwortlichen, die glaubten, ihre Infrastrukturen sicher zu betreiben. Glücklicherweise handelte es sich um Kontenübernahmen von nicht privilegierten Benutzern. Die Frage nach der Ursache wiegt jedoch schwerer:

Warum schafft es Microsoft nicht, Identitäten in seiner M365-Welt zu schützen? Einerseits gegen Fehlbedienung der Anwender, andererseits aber gegen die typischen Phishing-as-a-Service Plattformen wie beispielsweise Kali365.¹

Dieser Blogbeitrag erklärt die fundamentale Fehlkonzeption der M365-Welt: Wie Anwendungen, Session- und Sicherheitstoken technisch funktionieren und wie Microsoft in seiner eigenen Dokumentation eingesteht, Session-Diebstahl und Replay-Angriffe nicht durchgängig verhindern zu können.

Das strukturelle Problem

Nach jeder erfolgreichen Authentifizierung müssen Windows, Outlook, Edge oder Webanwendungen und Web-Schnittstellen miteinander arbeiten können, ohne dass es jedes Mal zu einer erneuten Aufforderung zur Authentifizierung kommt, so das Single-Sign-On (SSO) Versprechen.²

Also gibt es Sessions, Cookies und Tokens, die nach einer Anmeldung im Betriebssystem und zwischen Anwendungen hin und her geschoben und erneuert werden. Klappt nur nicht immer und so gehören sporadisch auftretende Authentifizierungs-Aufforderungen zum Alltag, was bereits einen Implementierungsfehler darstellt.

Wer sich länger mit Windows-Sicherheit beschäftigt, kennt das Prinzip und erinnert sich an NTLM-Hashes direkt aus den laufenden Systemprozessen oder mit Mimikatz extrahierte Kerberos-Tickets.³ Pass-the-Hash,⁴ Pass-the-Ticket sowie Silver- und Golden-Ticket-Angriffe führten und führen bis heute zur Übernahme lokal betriebener AD-Infrastrukturen.⁵

Das Angriffsmuster ist damit Jahrzehnte alt. Für die Wiederverwendung einer bereits authentifizierten Sitzung braucht ein Angreifer weder Zugangsdaten noch einen zweiten Faktor. Die beste Passwort-Policy, das sicherste Passwort und das lückenloseste Event-ID-Monitoring auf fehlgeschlagene Anmeldeversuche sind alle im Grunde wirkungslos, wenn ein Angreifer einfach eine Sitzung kapert und z.B. in seinem Browser wiederverwendet. Soviel zum Thema Awareness- und Sensibilisierungsmaßnahmen.

Die Begrifflichkeiten und Tech-Stacks haben sich zwar in den letzten Jahren verändert: Zum Active Directory gesellte sich Azure AD, das heutige Entra-ID. Aus klassischen Win32-Anwendungen wurden schwer definierbare Chimären⁶ aus managed und unmanaged Programmcode, REST-Web-APIs mit viel Electron- und WebView-Gaggelfax dazwischen.

Am Grundprinzip hat sich jedoch nichts verändert: Ein Angreifer nutzt einfach den authentifizierten Zustand nach einer Authentifizierung. Es ist so einfach, weil weite Teile der M365-Welt auf dem bereits 2012 im RFC 6750 standardisierten Bearer-Prinzip beruhen.⁷ Das besagt vereinfacht: Der Besitz eines Tokens ist für einen Client ausreichend. Einen kryptografischen Nachweis, dass der jeweilige Client auch tatsächlich der rechtmäßige Besitzer ist, sieht dieses Prinzip nicht vor.⁸

Demonstrating Proof of Possession (DPoP)

Mit dem moderneren RFC 9449 existiert seit einigen Jahren ein RFC-Standard, der genau dieses Problem adressiert.⁹ Ein OAuth-Client besitzt ein Schlüsselpaar. Ein Authorization-Server bindet das ausgestellte Token an den öffentlichen Schlüssel des Clients. Für spätere Anfragen reicht es nicht mehr, dieses Token vorzulegen. Ein Client muss zusätzlich einen kryptografisch signierten Nachweis für seine Anfrage vorlegen. Dieser Nachweis enthält unter anderem Informationen über Art und Ziel der Anfrage. Ein abgefangenes Token allein kann damit von einem anderen Client nicht ohne Weiteres wiederverwendet werden.

Microsoft kontrolliert in Unternehmen weitestgehend den Tech-Stack vom Betriebssystem über den Browser und die Anwendungen bis zum Identity Provider und bietet keinen durchgängigen Schutz gegen die Wiederverwendung gestohlener Sessions und Tokens.

Fazit

Und damit komme ich zurück zu den eingangs erwähnten M365-Kontoübernahmen und der Überschrift dieses Beitrages. Es ist die Schlussfolgerung aus einer bemerkenswerten historischen Kontinuität und jahrzehntelangen Erfahrung mit Microsoft und dessen Produkten:¹⁰

Wenn eine IT-Infrastruktur und der zugehörige M365-Tech-Stack Identitäten nicht hinreichend schützen können, dann sind beide kaputt. Und damit meine ich strukturell broken by Design und nicht lediglich schlecht konfigurierte Tenants.

Bemerkenswert ist, dass Microsoft mit gerätegebundenen Primary Refresh Tokens (PRT)¹¹ und Token Protection¹² entsprechende Schutzmechanismen kennt. Die Unterstützung für browserbasierte Anwendungen befindet sich jedoch Stand August 2026 im Preview-Status und ist auf wenige Anwendungen, Browser, Plattformen und Ressourcen beschränkt. Wer die Original-Quelle von Microsoft liest, stellt fest, dass meine Umschreibung mit “wenige” noch sehr höflich und wohlwollend ist.¹³

Die zentralen Cloud-Dienste Exchange Online, SharePoint und Teams bleiben im Webbrowser kryptografisch gegen Session- und Token-Übernahme ungeschützt, so Microsoft selbst.

Wie könnte es anders sein? Aus einem strukturellen Problem der Session-Sicherheit macht Microsoft ein Verkaufsargument für eine Kaskade aus Schlangenöl, Buzzwords und zusätzlichen Lizenzkosten, sogar für jene, die auf Nicht-Microsoft-Systeme setzen.¹⁴

Nein, danke. Das ist meiner Meinung nach ein Fall für Regulierungsbehörden, wenn andere Browser und Systeme ausgeschlossen werden und die Installation der eigenen Software vorausgesetzt wird. Man hätte das Problem auch einfach fixen können, so wie es beispielsweise Keycloak¹⁵ als Open-Source-IAM ganz gut macht.¹⁶ Gerade weil Microsoft den M365-Tech-Stack kontrolliert und betreibt.

In diesem Sinne,
Euer Tomas Jakobs