Eric Woodruff Senior Sicherheitsforscher

Dieser Artikel beschreibt eine Reihe von Entdeckungen des Sicherheitsforschungsteams von Semperis, die dazu führten, dass in Entra ID Aktionen durchgeführt werden konnten, die über die erwarteten Berechtigungskontrollen hinausgingen. Dies basiert auf einer Analyse des OAuth 2.0-Bereichs (Berechtigungen). Unsere besorgniserregendste Entdeckung betraf die Möglichkeit, Benutzer zu privilegierten Rollen hinzuzufügen und zu entfernen, einschließlich der mächtigsten Rolle in Entra ID: Globaler Administrator. Wir haben unsere Entdeckungen an das Microsoft Security Response Center (MSRC) gemeldet und mit Microsoft zusammengearbeitet, um sicherzustellen, dass diese Entdeckungen behoben wurden.

Es ist zwar nicht bekannt, ob Organisationen durch diese Entdeckung bereits kompromittiert wurden, aber ein Angreifer könnte diesen Zugang dazu genutzt haben, seine Rechte zum globalen Administrator zu erhöhen und weitere Mittel zur Persistenz in einem Mandanten zu installieren. Ein Angreifer könnte diesen Zugang auch nutzen, um in jedes System in Microsoft 365 oder Azure sowie in jede SaaS-Anwendung, die mit Entra ID verbunden ist, einzudringen.

Die Erkennung setzt voraus, dass der Initiator die Rolle des Anwendungsadministrators oder Cloud-Anwendungsadministrators in Entra ID innehat, die als privilegiert gilt. In vielen Unternehmen ist es leider so, dass Benutzer, denen diese Rollen zugewiesen sind, nicht als privilegiert behandelt werden, was sie zu bevorzugten Zielen für Angreifer macht.

Betroffene Unternehmen sollten wissen, wie sie feststellen können, ob ihre Microsoft-Anwendungen möglicherweise angegriffen wurden, wie später in diesem Artikel beschrieben.

Fibel zur Anwendungsintegration

Um diesen Angriffsvektor zu verstehen, müssen Sie die grundlegenden Komponenten verstehen.

Kunden von Microsoft 365 und Azure sind vielleicht mit den Systemen und Diensten vertraut, mit denen sie interagieren, darunter Microsoft Teams, SharePoint Online, Exchange Online, Azure Key Vault und Verwaltungsportale wie das Azure-Portal und das Microsoft 365 Admin Center sowie die Suite anderer Microsoft-Dienste. Was Sie vielleicht nicht wissen, sind die Hunderte von Microsoft-Anwendungen, die Ihren Microsoft-Bestand am Laufen halten. Außerhalb von Microsoft selbst kann man diese Anwendungen als Erstanbieter-Anwendungen bezeichnen, da sie nicht von einem Drittanbieter bereitgestellt werden.

Entra ID ist die Identitätsplattform und Autorisierungs-Engine jeder Microsoft 365- und Azure-Umgebung. Kunden, die die Authentifizierung bei Okta, Ping Identity oder anderen Identitätsanbietern mit Microsoft-Diensten föderieren, müssen immer noch das Autorisierungsmodell verwalten, das innerhalb ihrer Microsoft-Umgebung existiert. Entra ID ist der zugrunde liegende Autorisierungsmechanismus, der es diesen Microsoft-Anwendungen ermöglicht, unter Verwendung von Industriestandards für moderne Authentifizierung und Autorisierung miteinander zu interagieren und zu arbeiten: OpenID Connect und OAuth 2.0.

Jeder Microsoft-Kunde hat seinen eigenen Entra-Tenant (früher bekannt als Azure AD). In jedem Tenant wird jede Microsoft-Anwendung durch ein Sicherheitsprinzipalobjekt repräsentiert, das als Dienstprinzipal bezeichnet wird . Benutzer und Gruppen sind Sicherheitsprinzipale, mit denen wir alle am besten vertraut sind; Sie können diesen Prinzipalen Rollen und Berechtigungen zuweisen. Genau wie Benutzern und Gruppen können auch Anwendungen Rollen und Berechtigungen über ihre Dienstprinzipien zugewiesen werden. Diese Rollen und Berechtigungen werden bei der Interaktion mit Entra ID oder anderen Microsoft 365-Diensten ausgewertet.

Mehrmandantenfähige Anwendungen in Entra ID

Entra ID betrachtet in der Regel alle Microsoft-Anwendungen als mandantenfähige Anwendungen, auch solche, die einzigartige Eigenschaften haben.

Bei mandantenfähigen Anwendungen legt der Entwickler in der App-Registrierung fest, wie die Anwendung funktionieren soll. Dazu gehören Aktionen wie die Festlegung der Microsoft Graph-API-Berechtigungen, die die Anwendung benötigt, sowie die von der Anwendung für den Zugriff auf Microsoft Graph verwendeten Anmeldeinformationen. Microsoft Graph ist der einheitliche API-Endpunkt für mehrere Microsoft-Dienste, darunter Entra ID.

Wenn ein Unternehmen eine mandantenfähige Anwendung konsumiert, wird die Anwendung im konsumierenden Mandanten durch einen Service Principal repräsentiert(Abbildung 1).

Abbildung 1. Beispiel für eine Anwendungsregistrierung und die Beziehung zu ihrem Dienstherrn.

Der Fall von mehreren Berechtigungsnachweisen

Entra ID ermöglicht die Zuweisung und Verwendung von zwei Arten von Berechtigungsnachweisen für die Authentifizierung: Geheimnisse (Passwörter) und Schlüssel (Zertifikate). Beide Arten von Berechtigungsnachweisen haben im Rahmen unserer Entdeckung funktioniert. Im Folgenden werde ich sowohl Geheimnisse als auch Schlüssel einfach als Berechtigungsnachweise bezeichnen.

Interessant ist, dass Entra ID die Speicherung von Anmeldeinformationen an zwei Stellen erlaubt: in der App-Registrierung (die, wie bereits erwähnt, vom Entwickler verwaltet wird) und im Service Principal. Bei mandantenfähigen Anwendungen befindet sich der Service-Principal im Kunden-Mandanten und unter der Kontrolle des Kunden, der dem Service-Principal dann Anmeldeinformationen zuweisen kann(Abbildung 2).

Abbildung 2. Diagramm, das zeigt, dass der Fabrikam-Mieter einen Berechtigungsnachweis für den Dienstprinzipal einrichtet.

Zum Schutz vor der Zuweisung oder Verwendung von Geheimnissen auf Service-Principals können Anwendungsentwickler einen Mechanismus in Entra ID verwenden, der App-Instance Property Lock genannt wird. Unsere Nachforschungen und Gespräche mit Microsoft haben ergeben, dass Microsoft einen anderen Mechanismus einsetzt, der zum gleichen Ergebnis führt: die Authentifizierung mit einem Berechtigungsnachweis auf einem Dienstprinzipal wird nicht zugelassen.

Unabhängig davon, ob ein Berechtigungsnachweis einer App-Registrierung oder einem Dienstprinzipal zugewiesen ist, können beide verwendet werden, um einen OAuth 2.0-Client-Berechtigungsnachweisfluss durchzuführen, um als diese Anwendung in Microsoft Graph zu agieren(Abbildung 3).

Abbildung 3. Fluss der OAuth 2.0 Client-Zugangsdaten in Entra ID.

Bei der Erteilung von Berechtigungsnachweisen für Kunden finden die folgenden Schritte statt:

  1. Die Anwendung verwendet ihre Client-ID und Zugangsdaten, um sich bei Entra ID zu authentifizieren. Eine Anwendung ist alles, was die Client-ID, die Tenant-ID und den Berechtigungsnachweis kennt. Für die Zwecke dieses Missbrauchs ist also die benannte Anwendung zwar eine Microsoft-Anwendung, aber die handelnde Anwendung ist der Angreifer.
  2. Entra ID überprüft die Client-ID und den Berechtigungsnachweis und antwortet mit einem Zugriffstoken.
  3. Die Anwendung fordert Daten von Microsoft Graph an und gibt dabei das Token weiter.
  4. Microsoft Graph validiert das Zugriffstoken.
  5. Wenn das Token gültig ist, liefert Microsoft Graph die angeforderten Daten oder Aktionen.

Alle Einzelheiten zu diesem Ablauf finden Sie in der Microsoft-Dokumentation "Microsoft identity platform and the OAuth 2.0 client credentials flow".

Da Microsoft Graph eine REST-API ist, können Aktionen wie GET verwendet werden, um Daten von Entra ID anzufordern, und Aktionen wie POST und PATCH können verwendet werden, um Daten in Entra ID zu erstellen oder zu ändern.

Wenn einer Anwendung die Anwendungsberechtigung Group.Create zugewiesen ist und Sie über die Berechtigung für diese Anwendung verfügen, können Sie eine Gruppe erstellen und die Entra ID Audit-Protokolle würden zeigen, dass die Gruppe vom Dienstprinzipal für diese Anwendung erstellt wurde.

Nehmen wir an, Sie haben eine Anwendung eines Drittanbieters mit dem Namen Custom Application, die Sie für den Zugriff auf Microsoft Graph über das Microsoft Graph PowerShell SDK verwenden. Die Anmeldeinformationen, die als $creds übergeben werden, enthalten die Anwendungs-ID und die Anmeldeinformationen(Abbildung 4).

Abbildung 4. Verbinden mit Microsoft Graph als benutzerdefinierte Anwendung.

Wenn Sie Aktionen mit den für diese Anwendung genehmigten Berechtigungen durchführen - in diesem Fall Group.Create - werden dieseAktionen in den Entra ID Audit-Protokollen als von der Anwendung durchgeführt angezeigt. Wie Sie in Abbildung 5 sehen können , ist die Anwendung der Sicherheitsprinzipal, der für die Operation "Gruppe hinzufügen" verantwortlich ist.

Abbildung 5. Ergebnisse der Erstellung einer Gruppe als benutzerdefinierte Anwendung.

Als Microsoft-Anwendungen fungieren

In Entra ID hat Microsoft in der Vergangenheit Kunden die Möglichkeit gegeben, Anmeldeinformationen für fast alle Microsoft-Anwendungsdienstprinzipale zuzuweisen. In begrenzten Fällen können diese Berechtigungsnachweise in OAuth 2.0 Client Credential Grant Flows verwendet werden, um auf Microsoft Graph zuzugreifen, der als Microsoft-Anwendung innerhalb des eigenen Mandanten des Kunden fungiert.

Wie bei der benutzerdefinierten Anwendung im vorigen Beispiel haben wir dem Dienstprinzipal für die Microsoft-Anwendung Device Registration Service einen Berechtigungsnachweis zugewiesen . Anschließend konnten wir uns authentifizieren und als Device Registration Service auf Microsoft Graph zugreifen(Abbildung 6).

Abbildung 6. Verbinden mit Microsoft Graph als Geräteregistrierungsdienst.

Erhöhte Berechtigungen durch Microsoft-Anwendungen

Bei unseren Nachforschungen haben wir festgestellt, dass bestimmte Microsoft-Anwendungsdienstprinzipale bestimmte Aktionen ausführen durften, die nicht in der Liste der autorisierten Berechtigungen definiert waren. Das heißt, dass wir bestimmte privilegierte Aktionen ausführen durften, obwohl wir anscheinend keine Berechtigung dazu hatten.

Innerhalb von Microsoft Graph können Sie die verfügbaren Berechtigungen ermitteln, indem Sie die zugewiesenen Bereiche (Scopes)untersuchen - derOAuth 2.0-Begriff für Berechtigungen.

In unserem Beispiel, das Abbildung 6 zeigt, sehen Sie, dass die Bereiche für den Geräteregistrierungsdienst leer sind (Abbildung 7). Das sollte bedeuten, dass diese Anwendung keine Berechtigung hat, irgendetwas über die Graph-API zu tun, und wir sollten eine 403 unautorisierte Antwort erhalten haben, wenn wir eine unautorisierte Aktion versuchen.

Abbildung 7. Unsere leeren Geltungsbereiche (Berechtigungen) für den Geräteregistrierungsdienst.

Als wir jedoch versuchten, bestimmte privilegierte Aktionen durchzuführen, konnten wir dies tun. In diesem Beispiel zeigen Abbildung 8 und Abbildung 9 einen erfolgreichen Versuch, einen Benutzer zur Rolle des globalen Administrators als Geräteregistrierungsdienst hinzuzufügen.

Abbildung 8. Hinzufügen eines Benutzers mit der Rolle Globaler Administrator als Geräteregistrierungsdienst.
Abbildung 9. Die Ergebnisse des Entra ID Audit-Protokolls zeigen eine erfolgreiche Rollenverwaltung.

Unser Ergebnis

Bei unseren Nachforschungen haben wir die folgenden Fähigkeiten für jeden der genannten Dienste entdeckt. Der Umfang der Auswirkungen liegt innerhalb des angestrebten Entra-Mieters.

Viva Engage (Yammer)

Die Fähigkeit, Benutzer zu löschen und dauerhaft zu löschen, einschließlich privilegierter Benutzer wie Global Administrators. MSRC stufte diese Fähigkeit als Sicherheitslücke mittleren Schweregrads ein.

Microsoft Rechteverwaltungsdienst

Die Fähigkeit, Benutzer zu erstellen. MSRC stufte diese Fähigkeit als wenig schwerwiegend ein. Die Erklärung für den niedrigen Schweregrad war, dass die erstellten Benutzerobjekte nicht privilegiert waren.

Geräte-Registrierungsdienst

Die Fähigkeit, die Mitgliedschaft in privilegierten Rollen zu ändern, einschließlich der Rolle des globalen Administrators. MSRC stufte diese Fähigkeit als wichtigen Schweregrad ein, Privilegienerweiterung unter Identität (Entra ID).

Verwendung des Mechanismus zur Erhöhung der Privilegien und der Persistenz

Alle unsere Entdeckungen sind insofern besorgniserregend, als dass sie bekannte Autorisierungskontrollen umgehen. Der Fund des Geräteregistrierungsdienstes ist jedoch der zentrale Punkt für die Erhöhung der Berechtigungen und die mögliche Persistenz eines Angreifers.

In einem Entra-Mandanten können Anwendungsadministratoren, Cloud-Anwendungsadministratoren, globale Administratoren und Benutzer, die als Eigentümer einer Anwendung zugewiesen sind, dem Serviceprinzipal Anmeldeinformationen zuweisen.

Anwendungsadministrator und Cloud-Anwendungsadministrator werden von Microsoft als privilegierte Rollen betrachtet, wie in der Dokumentation "Microsoft Entra built-in roles" beschrieben . In vielen Unternehmen können die Integrationen von Drittanbieteranwendungen andere Wege der Privilegienerweiterung und des Missbrauchs bieten, wenn ein Anwendungsadministrator oder Cloud-Anwendungsadministrator kompromittiert wurde, unabhängig davon, ob sich das Unternehmen bewusst ist, dass diese Wege eingerichtet werden.

In einem neuen Entra-Tenant haben jedoch weder der Anwendungsadministrator noch der Cloud-Anwendungsadministrator die Rechte in einem Entra-Tenant, die Zuweisung privilegierter Rollen zu verwalten.

Es ist auch wichtig zu wissen, dass diese Rollen nicht in der Lage sind, Microsoft Graph API-Berechtigungen zu erteilen, was ein häufiges Missverständnis derjenigen ist, die mit Entra ID arbeiten.

Wenn ein Angreifer, der von der Schwachstelle im Geräteregistrierungsdienst weiß, einen Benutzer kompromittiert, dem die Rolle des Anwendungsadministrators oder des Cloud-Anwendungsadministrators zugewiesen wurde, könnte der Angreifer diesen Zugriff nutzen, um in die Rolle des globalen Administrators oder eine andere gewünschte Rolle einzudringen.

Obwohl es für einen Angreifer etwas plump erscheinen mag, mit der Rolle des globalen Administrators zu bestehen, könnte Persistenz mit diesen Privilegien installiert werden, indem eine neue Anwendungsregistrierung und ein Dienstprinzipal mit privilegierten Anwendungsberechtigungen erstellt werden. Ebenso könnte ein Angreifer neue privilegierte Anwendungsberechtigungen in einer bestehenden Single-Tenant-Anwendung installieren oder eine bestehende privilegierte Anwendung finden und zusätzliche Anmeldedaten installieren. Unternehmen, die nicht ständig auf diese Art von Änderungen achten und nicht über die nötige Reife verfügen, um bekannte von böswilligen Operationen in Entra ID zu unterscheiden, würden die Installation von dauerhaftem Zugriff oder die vorübergehende Änderung der Rollenzuweisung in Entra ID wahrscheinlich nicht bemerken.

Die Lösung und das versteckte fehlende Glied

Wir sind dankbar für die Gespräche, die wir mit MSRC und dem Microsoft Identity Team während der Klärung unserer Fragen geführt haben. Unsere Bedenken betrafen in erster Linie den fehlenden Geltungsbereich (Berechtigung) für unseren Zugang zu Microsoft Graph.

Während unseres Gesprächs wies Microsoft darauf hin, dass es andere Autorisierungsmechanismen gibt, die hinter den Kulissen für Microsoft-Anwendungen existieren. Diese Mechanismen ermöglichten es uns, die in diesem Artikel beschriebenen Aktionen durchzuführen.

Microsoft hat zu Recht betont, dass diese Fähigkeit daher kein wesentlicher Fehler in einem seiner Autorisierungsmodelle ist. Allerdings räumte es ein, dass die Fähigkeiten von außen, basierend auf dem, was wir sehen können und worauf wir Zugriff haben, als Fehler erscheinen könnten. Außerhalb von Microsoft sind die OAuth 2.0-Bereiche bei der Interaktion mit Microsoft Graph absolut, so dass wir ohne Kenntnis anderer Autorisierungssysteme nur Vermutungen anstellen können.

Darüber hinaus haben unsere Nachforschungen dazu geführt, dass Microsoft viele Änderungen vorgenommen hat, um die Verwendung von Anmeldeinformationen in Microsoft-Anwendungen weiter einzuschränken. Microsoft hat weitere Kontrollmechanismen eingeführt, die die Verwendung von Anmeldeinformationen für Dienstprinzipale einschränken. Wir haben festgestellt, dass die Liste der Dienstprinzipale, als die wir uns authentifizieren können, immer kürzer wurde

Wenn wir nun versuchen, uns als Device Registration Service zu authentifizieren, erhalten wir eine Fehlermeldung von Microsoft Graph(Abbildung 10).

Abbildung 10. Fehlgeschlagene Authentifizierung als Device Registration Service.

Aufdeckung von früherem Missbrauch

Die Anwendungen, die den Kern unserer Erkenntnisse bilden, sind wahrscheinlich in den meisten Microsoft-Kundenbeständen vorhanden. Wir sind der festen Überzeugung, dass diese Schwachstelle mindestens so lange existiert wie diese Anwendungen, was mehrere Jahre zurückliegt.

Die beiden Methoden zur Aufdeckung dieses Missbrauchs sind Entra ID Audit-Protokolle und verweilende Anmeldedaten in den missbrauchten Anwendungen. Leider haben beide Methoden ihre Grenzen. Audit-Protokolle sind nur so lange von Nutzen, wie sie aufbewahrt werden, und ein Angreifer könnte die Anmeldeinformationen auf den ursprünglich missbrauchten Anwendungen nach der Installation weiterer Persistenz entfernt haben.

Wenn ein Unternehmen Daten findet, die darauf hinweisen, dass dem Device Registration Service Berechtigungsnachweise zugewiesen wurden, oder wenn es Audit-Daten für den Device Registration Service entdeckt, sollte es sich große Sorgen machen. Uns ist kein triftiger Grund bekannt, warum dem Geräteregistrierungsdienst ein Berechtigungsnachweis zugewiesen werden sollte.

Nachwirkende Zeugnisse

Sie können Microsoft Graph verwenden, um die betroffenen Dienstprinzipale zu untersuchen, damit Sie feststellen können, ob ihnen zusätzliche Anmeldeinformationen hinzugefügt wurden.

Überprüfen Sie bei diesen Graph-Abfragen die Ausgabe, um festzustellen, ob Werte gesetzt wurden oder ob die Zugangsdaten als Null zurückgegeben werden.

Die Anwendungs-ID ist ein global eindeutiger Wert. Diese PowerShell-Befehle und die Microsoft Graph-Abfrage funktionieren in jedem Entra-Mandanten.

Geräte-Registrierungsdienst

Microsoft Graph PowerShell SDK

((Get-MGServicePrincipal -Filter "AppId eq '01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9'").KeyCredentials).count

((Get-MGServicePrincipal -Filter "AppId eq '01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9'").PasswordCredentials).count

Microsoft Graph-Abfrage

https://graph.microsoft.com/v1.0/servicePrincipals(appId='01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9')?$select=keyCredentials,passwordCredentials

Audit-Protokolleinträge

Unternehmen können Entra ID Audit-Protokolldaten untersuchen, die bestimmten Mustern entsprechen. Beachten Sie, dass die Suche nach Audit-Protokolldaten nur so weit zurück möglich ist, wie die Organisation diese Protokolle gespeichert hat.

Suche nach Aktionen durch den Geräteregistrierungsdienst

AuditLogs

| where parse_json(tostring(InitiatedBy.app)).displayName == "Device Registration Service"

Jagd auf die Zuweisung von Geheimnissen an den Geräteregistrierungsdienst

AuditLogs

| where OperationName == "Add service principal credentials"

| where TargetResources[0].displayName == " Device Registration Service"

Schutz der Semperis Kunden

Für Benutzer von Semperis Directory Services Protector ( DSP) oder Purple Knightveröffentlichen wir einen Sicherheitsindikator, Suspicious credentials on Microsoft service principal (Verdächtige Anmeldeinformationen für Microsoft-Dienste), der nach Anmeldeinformationen sucht, die den Device Registration Services und Viva Engage zugewiesen wurden, und diese meldet. Im Rahmen eines Ansatzes für mehrschichtige Identitätssicherheit können Unternehmen auch ihre SIEM-Auditprotokolle auf Marker überprüfen.

Stoppen von Angriffen auf privilegierte Anwendungen

Privilegierte Anwendungen und ihre Dienstprinzipale in Entra ID sind eine der häufigsten Möglichkeiten für Angreifer, um in Entra ID Fuß zu fassen und sich dort zu halten sowie in andere Cloud-Systeme wie Microsoft 365, Azure und Multicloud- und SaaS-Anwendungen, die in Entra ID integriert sind, einzudringen.

Eine der besten Schutzmaßnahmen, die Unternehmen ergreifen können, ist die Sicherstellung, dass der Anwendungsadministrator und der Cloud-Anwendungsadministrator genauso privilegiert behandelt werden wie die globalen Administratoren und dass bewährte Verfahren wie die Trennung von Privilegien, Workstations mit privilegiertem Zugriff und eine starke phishing-resistente Authentifizierung als Anforderungen und nicht als Optionen behandelt werden.

Verwandte Forschung und Danksagungen

Die Forschung im Bereich der Entra ID-Anwendungen und Service Principals ist kein neues Konzept. Unsere Forschungen überschneiden sich mit ähnlichen Forschungen von Dirk-jan Mollema aus dem Jahr 2019, der sich mit der Zuweisung von Anmeldeinformationen an Dienstprinzipale und der Nutzung von OAuth 2.0-Anwendungsberechtigungen zur Ausführung von Funktionen befasste, die ein Anwendungsadministrator nicht ausführen können sollte. Seitdem ist die Liste der Anwendungen, die verwendet werden können, immer kleiner geworden und wurde im Juli 2024 als Ergebnis der Reaktion von Microsoft auf unsere Erkenntnisse weiter reduziert.

Offenlegung und Zeitplan

Die in diesem Beitrag beschriebenen Entdeckungen wurden dem MSRC wie in der folgenden Zeitleiste dokumentiert gemeldet. Da es sich um eine komplexe Entdeckung handelte, hat es einige Zeit gedauert, die Ergebnisse mit MSRC aufzuarbeiten. Wir schätzen die Schnelligkeit, mit der die Entdeckung des Device Registration Service (Geräteregistrierungsdienst) behoben wurde, und das Engagement von Microsoft, seine Anwendungen auf der Grundlage unserer gemeinsamen Arbeit weiter zu sichern.

  • Januar 11, 2024: MSRC-Fälle erstellt
  • 30. Januar 2024: MSRC lieferte eine erste Antwort mit geringem Schweregrad
  • Februar 6, 2024: Antwort an MSRC bezüglich der Zuordnung des Schweregrads
  • März 4, 2024: Der Geräteregistrierungsdienst wurde als wichtig eingestuft
  • März 4, 2024: Viva Engage als niedriger Schweregrad eingestuft
  • 4. März 2024: Microsoft Rights Management Services als wenig schwerwiegend eingestuft
  • März 4, 2024: Microsoft Rights Management Services Fall gelöst und geschlossen
  • März 4, 2024: Der Fall des Geräteregistrierungsdienstes wurde gelöst und geschlossen
  • April 1, 2024: Viva Engage wird als mittelschwer eingestuft
  • 17. April 2024: Erste Mitteilung an MSRC bezüglich der Offenlegung
  • April 19, 2024: Viva Engage Fall gelöst und geschlossen
  • 5. Juni 2024: Entwurf des Offenlegungsartikels an MSRC geschickt
  • Juni 13, 2024: Treffen mit MSRC zu Fällen und Offenlegung
  • 7. August 2024: Öffentliche Bekanntgabe