Eric Woodruff | Leitender Identitätsarchitekt

Wichtigste Ergebnisse

  • Bei der Prüfung von 38 weiteren Anwendungen seit unserer ersten Untersuchung hat Semperis zwei Anwendungen identifiziert, die anfällig für nOAuth-Missbrauch sind. Wir haben unsere Ergebnisse zu diesen beiden Anwendungen an die Softwareanbieter gemeldet.
  • Eine der anfälligen Anwendungen verfügte über Berechtigungen, die es einem Angreifer ermöglichen würden, sich wieder in Microsoft 365 einzuloggen, was verdeutlicht, dass nOAuth nicht nur Daten in der SaaS-Anwendung gefährden kann, sondern auch die Microsoft 365-Umgebung eines Unternehmens.
  • In unserem aktuellen Fall mit dem Microsoft Security Response Center hat das MSRC diese Sicherheitslücke als mittelschwer eingestuft. Semperis hält jedoch an seiner Einstufung als SCHWERWEGEND fest . nOAuth ist für Kunden von anfälligen Anwendungen nach wie vor schwer zu erkennen und für Kunden von anfälligen Anwendungen unmöglich abzuwehren. Der Missbrauch ist öffentlich dokumentiert und weist eine geringe Komplexität auf, sobald eine anfällige Anwendung gefunden wurde.

Dieser Artikel ist eine Fortsetzung unserer ursprünglichen Forschung zu nOAuth. Obwohl es uns vorkommt, als hätten wir diese Ergebnisse erst gestern auf der TROOPERS25 und der fwd:cloudsec 2025 veröffentlicht, begann unsere Forschung bereits im Herbst 2024.

Nach weiteren Untersuchungen zu nOAuth sechs Monate nach unserem ursprünglichen Gespräch und erneut ein Jahr nach unserer ersten Untersuchung haben wir festgestellt, dass das Risiko eines Missbrauchs von nOAuth weiterhin besteht und dass viele Unternehmen sich dieser Schwachstelle nach wie vor nicht bewusst sind.

Im Oktober und November 2025 haben wir 38 weitere Anwendungen auf den Missbrauch von nOAuth getestet und zwei davon als anfällig identifiziert. Im Rahmen unserer vorherigen Untersuchung haben wir 104 Anwendungen getestet und neun davon als anfällig eingestuft. Dies bedeutet, dass insgesamt etwa 8 % der verfügbaren Apps für nOAuth anfällig sind.

Informationen zur Integration von SaaS-Anwendungen in Microsoft 365

Die Microsoft Graph API ist die einheitliche API für den Zugriff auf alle Microsoft 365-Dienste: Exchange Online, SharePoint, OneDrive und die meisten anderen Microsoft 365-Dienste. SaaS-Anwendungen von Drittanbietern, die eine Integration mit diesen Diensten anstreben, beantragen Zugriff auf Microsoft Graph, um im Namen der Benutzer mit deren Daten oder Diensten interagieren zu können.

Ein Beispiel hierfür ist Calendly, das Zugriff auf den Kalender eines Benutzers anfordert, um dessen Besprechungstermine in Office 365 verwalten zu können (Abbildung 1). Zur Klarstellung: Calendly ist nicht anfällig für nOAuth. Wir verwenden es lediglich als Referenzanwendung, um Ihnen das allgemeine Verhalten von SaaS-Anwendungen näherzubringen.

Screenshot, der die Berechtigungen zeigt, die der Calendly-App gewährt werden, damit sie zur Verwaltung von Kalenderterminen verwendet werden kann.
Abbildung 1. Calendly-Berechtigungen, die Lese-/Schreibzugriff auf den Kalender gewähren

Wenn ein Benutzer auf die Anwendung zugreift, erhält die SaaS-Anwendung, sofern die Berechtigungen erteilt wurden, einen OAuth 2.0-Zugriffstoken von Entra ID. Die Anwendung verwendet diesen Zugriffstoken dann mit der Microsoft Graph-API, um auf den Dienst zuzugreifen. In diesem Beispiel verfügt der an Calendly übermittelte Zugriffstoken über die Berechtigungen „Calendar.ReadWrite ” und „Calendar.ReadWrite.Shared ”.

In vielen Szenarien erhält die SaaS-Anwendung auch ein Aktualisierungstoken (Abbildung 2). Dieses Token ermöglicht es der SaaS-Anwendung, den Zugriff auf die Daten des Benutzers aufrechtzuerhalten, auch wenn der Benutzer die Anwendung nicht aktiv nutzt.

Screenshot, der die der Calendly-App gewährten Berechtigungen zeigt, damit sie ein Aktualisierungstoken verwenden kann
Abbildung 2: Calendly-Berechtigungen, die die Verwendung eines Aktualisierungstokens ermöglichen

Warum benötigen SaaS-Anwendungen diese Art von Zugriff? In unserem Beispiel ermöglicht dieser Zugriff Calendly, Kundentermine in Ihrem Kalender zu buchen, auch wenn Sie die App nicht aktiv nutzen. Auf diese Weise kann die SaaS-Anwendung im Hintergrund weiterhin mit Ihren Daten arbeiten.

Dies ist hervorragend für die Produktivität, und an den angeforderten Berechtigungen ist grundsätzlich nichts auszusetzen. Wenn diese Berechtigungen jedoch mit einer Anfälligkeit für nOAuth kombiniert werden, ist die Grundlage geschaffen, dass Angreifer die Anwendung missbrauchen und möglicherweise wieder auf Microsoft 365 zugreifen können.

Der Unterschied zwischen Authentifizierung und Autorisierung

Um vollständig zu verstehen, wie nOAuth die Rückkehr zu Microsoft 365 erleichtern kann, sollten Sie wissen, dass OpenID Connect (OIDC) die Authentifizierung mit einem ID-Token und OAuth 2.0 die Autorisierung mit einem Zugriffstoken ermöglicht. Wenn ein Aktualisierungstoken einem Zugriffstoken beigefügt ist, kann die SaaS-Anwendung neue Zugriffstoken erhalten, unabhängig davon, ob der Benutzer authentifiziert ist.

Abgesehen von den sprachlichen Nuancen der Identität erleichtert OIDC die Anmeldung eines Benutzers bei einer Anwendung. OAuth 2.0 regelt die Berechtigungen, die eine Anwendung für die Daten eines Benutzers hat. Ein Refresh-Token ermöglicht der Anwendung den Zugriff auf die Daten des Benutzers, auch wenn dieser nicht angemeldet ist (Abbildung 3).

Ein Diagramm, das den Unterschied zwischen Authentifizierung und Autorisierung veranschaulicht
Abbildung 3. Ein Diagramm, das den Unterschied zwischen Authentifizierung und Autorisierung veranschaulicht

Wenn ein Benutzer zum ersten Mal auf eine Anwendung zugreift, kann eine Authentifizierung und Autorisierung stattfinden: Die Anwendung erhält möglicherweise ein ID-Token für den Benutzer und ein Zugriffstoken, damit die App auf Microsoft 365-Ressourcen zugreifen kann. Für den Endbenutzer ist dieser Vorgang in der Regel transparent, es sei denn, die Anwendung wurde noch nie verwendet und es ist eine Zustimmung erforderlich.

Es gibt zahlreiche Frameworks und Bibliotheken für die Verwaltung von Tokens, jedoch entscheidet letztendlich der SaaS-Anwendungsentwickler, wie Tokens verwaltet werden.

Wenn sich ein Benutzer anschließend authentifiziert, kann die Anwendung versuchen, einen neuen Zugriffs- und Aktualisierungstoken anzufordern, sofern die vorhandenen Token noch gültig sind. Da Authentifizierung und Autorisierung im Wesentlichen als unterschiedliche Funktionen behandelt werden, ermöglicht diese Trennung zwischen den beiden Abläufen Angreifern, sich Zugang zu verschaffen.

Missbrauch von nOAuth für den Wechsel zu Microsoft 365

Im Rahmen unserer ersten Untersuchungen haben wir eine anfällige Anwendung entdeckt, die mit Microsoft 365 mit Calendars.ReadWrite.Shared-Berechtigungen integriert war. Gemäß der Microsoft-Dokumentation umfasst diese Integration:

Ermöglicht es der App, Ereignisse in allen Kalendern der Organisation, auf die der Benutzer Zugriff hat, zu erstellen, zu lesen, zu aktualisieren und zu löschen. Dies umfasst auch delegierte und freigegebene Kalender.

Besorgniserregend, jedoch nicht in der Lage, einen Angriff wie Business Email Compromise (BEC) zu ermöglichen.

Dieses Mal haben wir eine wesentlich umfangreichere und bedenkliche Berechtigungsgruppe festgestellt (Abbildung 4):

  • Kalender.Lesen und Schreiben
  • E-Mail senden
  • Kontakte.Lesen und Schreiben
  • E-Mail lesen und schreiben
  • Offline-Zugriff
Abbildung 4: Berechtigungen für die anfällige Anwendung

Wie bereits erwähnt, sind diese Berechtigungen bedenklich, da sie es einem Angreifer ermöglichen, nicht nur den Benutzer innerhalb der SaaS-Anwendung zu kompromittieren, sondern auch die App-Oberfläche zu nutzen, um sich wieder in Microsoft 365 einzuschleusen.

Bitte beachten Sie, dass Authentifizierung und Autorisierung unterschiedliche Funktionen mit unterschiedlichen Tokens sind. Der Angreifer erlangt im Wesentlichen die Kontrolle über den Zugriff der Benutzer in Microsoft 365 über diese Zugriffs- und Aktualisierungstokens, die innerhalb der SaaS-Anwendung verwaltet werden (Abbildung 5).

Diagramm, das ein allgemeines Beispiel dafür veranschaulicht, wie ein Angreifer Zugriff auf das Konto eines legitimen Benutzers erlangt
Abbildung 5. Visualisierung eines Angreifers, der sich Zugang zum Konto eines legitimen Benutzers verschafft

In der anfälligen SaaS-Anwendung äußert sich dieses Verhalten darin, dass ein Angreifer E-Mails als der kompromittierte Benutzer versenden kann (Abbildung 6).

Screenshot von E-Mails, die sich als kompromittierter Benutzer ausgeben
Abbildung 6: E-Mail, die als kompromittierter Benutzer aus der SaaS-Anwendung versendet wurde

Da die E-Mail von einem legitimen Benutzer im Mandanten stammt, verfügt der Angreifer nun über eine effektive Möglichkeit, sich innerhalb von Exchange Online als der kompromittierte Benutzer auszugeben (Abbildung 7).

Screenshot, der den Inhalt einer betrügerischen E-Mail darstellt
Abbildung 7. Die E-Mail, die wir im Rahmen unserer Angriffssimulation erhalten haben

Der Angreifer hat keinen direkten Zugriff auf das Zugriffstoken, sodass die Benutzeroberfläche der SaaS-Anwendung bestimmt, wie er mit Microsoft 365-Ressourcen interagieren kann. Dennoch bestätigen diese Erkenntnisse unsere seit langem bestehenden Bedenken hinsichtlich nOAuth und der potenziellen Datenzugriffsmöglichkeiten und lateralen Pfade, die dadurch ermöglicht werden können.

Die Erforschung von nOAuth ist vergleichbar mit dem Versuch, eine negative Aussage zu beweisen.

Als wir unsere Ergebnisse im Juni 2025 veröffentlichten, lautete die häufigste Frage, wie viele Anwendungen insgesamt betroffen sein könnten. Dies ist verständlich, da unbestimmte Zahlen keine guten Schlagzeilen ergeben.

Es war und ist jedoch nach wie vor unmöglich, die Anzahl der potenziell anfälligen Anwendungen zu quantifizieren. Eine Suche nach der Anzahl der vorhandenen SaaS-Anwendungen ergibt Zahlen zwischen 70.000 und mehr als 300.000. Der Microsoft 365 Defenders Cloud-App-Katalog listet 36.932 SaaS-Anwendungen auf, jedoch sind nicht alle davon für die Authentifizierung mit Entra ID integriert.

Unabhängig davon, wie Sie die Zahlen berechnen, handelt es sich um Spekulationen. Im unteren Bereich, wenn 50 % aller Anwendungen Entra ID für die Authentifizierung verwenden, würden wir bei einer Prüfung von 142 (von 35.000) Anwendungen einen Testanteil von 0,4 % erreichen. Im oberen Bereich (von 150.000 Apps) würden wir einen Testanteil von 0,098 % erreichen.

Bei Troopers habe ich erklärt, dass wir neun anfällige Anwendungen identifiziert haben, und ich bezweifle, dass wir 90 % aller anfälligen Anwendungen gefunden haben. Angesichts unserer neuen Erkenntnisse bezweifle ich, dass es insgesamt 11 anfällige Anwendungen gibt. Es ist schlichtweg unmöglich, dies zu wissen.

Microsoft würde wissen, wie viele Anwendungen mit „removeUnverifiedEmailClaim“ auf „false“ konfiguriert sind und wie viele Anwendungen aufgrund einer Ausnahmeregelung diese Angabe weiterhin verwenden dürfen. Dies gibt jedoch keinen Aufschluss darüber, ob die Anwendung anfällig ist.

Was die Berechtigungen betrifft, so haben wir zwar nur Missbräuche von Anwendungen mit Exchange Online-Integrationen festgestellt, jedoch sind Integrationen mit SharePoint und OneDrive ebenso verbreitet. Es wäre naiv zu glauben, dass nur ein bestimmter Prozentsatz der Anwendungen mit diesen Integrationen für nOAuth anfällig ist. Es gibt Hunderte weiterer Microsoft Graph-Berechtigungen, von denen viele äußerst bedenklich wären, wenn sie in die Hände eines Angreifers gelangen würden. Tatsächlich ist dies das Hauptziel einer weiteren sehr verbreiteten Angriffsmethode: die illegale Erteilung von Zustimmungen.

Zeitplan und Reaktion des MSRC

  • 18. November 2025: Aufgrund neuer Erkenntnisse speziell zu Microsoft 365 und dieser Möglichkeit, sich wieder einzuloggen, haben wir einen Fall bei MSRC gemeldet. Wir haben alle Details zu den Erkenntnissen schriftlich und in einem Video, das den Angriff auf unseren Testbenutzer zeigt, bereitgestellt. Außerdem haben wir MSRC gebeten, die Möglichkeit zum Senden einer nicht verifizierten E-Mail-Anforderung einzustellen. Wie in unserem ursprünglichen Beitrag erläutert, gibt es andere Möglichkeiten, die E-Mail-Anforderung zu erhalten.
  • 3. Dezember 2025: Das MSRC antwortete, dass der Fall als mittleres Risiko eingestuft werde, und schloss den Fall. In seiner Antwort erklärte das MSRC Folgendes:

Nach sorgfältiger Untersuchung haben wir diesen Fall als Schwachstelle mittlerer Schwere eingestuft. Unsere jeweiligen Produkt-/Serviceteams wurden darüber informiert und werden möglicherweise daran arbeiten, in zukünftigen Versionen bei Bedarf weitere tiefgreifende Schutzmechanismen hinzuzufügen.

Daher schließen wir diesen Fall.

Warum nOAuth nach wie vor von Bedeutung ist

Wir werden weiterhin nach nOAuth-anfälligen Anwendungen suchen und uns aus mehreren Gründen für Änderungen bei Microsoft einsetzen:

  • Der Missbrauch von nOAuth ist öffentlich dokumentiert.
  • Untersuchungen haben den Zugang zu sensiblen Informationen auf Plattformen wie Personalmanagementsystemen (HRMS) nachgewiesen.
  • Untersuchungen haben ergeben, dass potenzielle Wege für eine seitliche Bewegung bestehen, um wieder zu Microsoft 365 zurückzukehren.
  • Kunden von anfälligen Anwendungen haben keine Abwehrmöglichkeit gegen nOAuth.
  • Sicherheitsforscher haben nachgewiesen, dass es relativ einfach ist, die Kunden von SaaS-Anwendungen zu ermitteln.
  • Die Nutzung von Plattformen wie LinkedIn, um privilegierte Nutzer von SaaS-Anwendungen anzusprechen und deren E-Mail-Adressen zu ermitteln, ist ebenfalls unkompliziert.

Semperis Schnappschuss

Obwohl Unternehmen keine starken Abwehrmaßnahmen gegen nOAuth haben, ist es wichtig, das Risiko in Bezug auf Ihre Daten zu verstehen. Bevor Sie eine neue SaaS-Anwendung einführen, sollten Sie den Anbieter fragen, ob er über die nOAuth-Forschung informiert ist, und ihn auf unsere Blogs verweisen.

Für Anbieter und Entwickler ist die Einhaltung der OpenID Connect-Spezifikationen von Microsoft von entscheidender Bedeutung, um sicherzustellen, dass Ihre Anwendung nicht anfällig für nOAuth ist. Weitere Informationen finden Sie in unserer früheren Studie.

Verwandte Ressourcen

• nOAuth-Missbrauchswarnung: Vollständige Kontoübernahme von Entra-mandantenübergreifenden SaaS-Anwendungen
• nOAuth-On-Demand-Sitzung (TROOPERS25)