M365 ist broken by Design

In den letzten drei Tagen habe ich gleich zwei 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. Der Schaden bewegte sich daher im überschaubaren Bereich. Der Verlust an Reputation und die abgeflossenen Daten sind jedoch nicht ohne weiteres zu beheben.

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. 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 übernimmt und z.B. in seinem Browser wiederverwendet. Da kann man noch so viele Awareness- und Sensibilisierungsmaßnahmen durchführen.

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 lokalem 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, denn weite Teile der M365-Welt setzen weiterhin auf das bereits 2012 in RFC 6750 standardisierte Bearer-Prinzip.⁷ Ein kryptografischer Nachweis, dass der jeweilige Client im Besitz eines an ihn gebundenen Schlüssels ist, ist nicht Bestandteil dieses Prinzips.⁸

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 reicht damit nicht mehr für dessen Wiederverwendung von einem anderen Client, wodurch die Wiederverwendung abgefangener Tokens deutlich erschwert wird.

Microsoft kontrolliert in Unternehmen weitestgehend den Tech-Stack vom Betriebssystem über den Browser und die Anwendungen bis zum Identity Provider und liefert trotzdem bis heute keinen durchgängigen Schutz von Identitäten und gegen eine Wiederverwendung von Sessions.

Fazit

Und damit komme ich zurück zu den eingangs erwähnten zwei M365-Kontoübernahmen binnen drei Tagen 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 selbst im August 2026 noch 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.¹⁰

Wie könnte es bei Microsoft anders sein? Aus einem strukturellen Problem der Session-Sicherheit macht es ein Verkaufsargument. Man hätte das Problem einfach fixen können, so wie es beispielsweise Keycloak als Open-Source-IAM ganz gut kann.¹¹ Stattdessen gibt es Schlangenöl und zusätzliche Lizenzkosten.¹²

In diesem Sinne,
Euer Tomas Jakobs