Microsoft Authenticator: Sicherheitslücke ermöglichte den Diebstahl von Kontotoken unter Android
Der Microsoft Authenticator soll eigentlich dafür sorgen, dass Unbefugte keinen Zugriff auf unsere Konten bekommen. Ausgerechnet diese Sicherheits-App hatte unter Android jedoch eine Schwachstelle, über die andere Anwendungen sensible Anmeldetoken abgreifen konnten. Besonders brisant: Die schädliche App benötigte dafür nicht einmal besondere Android-Berechtigungen.
Die Sicherheitslücke trägt die Kennung CVE-2026-80097 und wurde mit einem CVSS-Wert von 8,6 als hochriskant eingestuft. Betroffen waren vor allem Geräte, auf denen der Microsoft Authenticator zusammen mit einem angemeldeten Geschäfts- oder Schulkonto verwendet wurde.
Microsoft hat den Fehler inzwischen behoben. Die technischen Details, die Sicherheitsforscher jetzt veröffentlicht haben, zeigen allerdings, wie weitreichend die Folgen hätten sein können.
Was steckt hinter der Sicherheitslücke im Microsoft Authenticator?
Entdeckt wurde die Schwachstelle von Sicherheitsforschern des Unternehmens Enclave. Sie untersuchten, wie der Microsoft Authenticator unter Android mit anderen Anwendungen kommuniziert.
Dabei stießen sie auf ein Problem bei der Überprüfung von App-Identitäten.
Der Microsoft Authenticator übernimmt auf Android nicht nur die bekannte Bestätigung von Anmeldungen. Er kann auch als sogenannter Authentifizierungsbroker arbeiten. Vereinfacht gesagt hilft er anderen Microsoft-Apps dabei, sich bei einem bereits angemeldeten Benutzerkonto auszuweisen.
Das ist im Alltag durchaus praktisch. Wer beispielsweise Microsoft Teams oder Outlook verwendet, muss sich dadurch nicht ständig erneut anmelden.
Genau diese Funktion ließ sich allerdings missbrauchen.
Eine manipulierte Android-App konnte gegenüber dem Authenticator behaupten, sie wäre eine vertrauenswürdige Microsoft-Anwendung. Beispielsweise Microsoft Teams.
Der Authenticator akzeptierte unter bestimmten Voraussetzungen diese vorgetäuschte Identität und stellte Anmeldetoken aus, die anschließend bei der angreifenden App landeten.
Das eigentliche Problem war also nicht ein gestohlenes Passwort, sondern eine unzureichende Kontrolle darüber, welche Anwendung Zugriff auf die Anmeldedaten erhält.
Angreifer benötigten keine besonderen Android-Berechtigungen
Besonders bemerkenswert ist, wie wenig Aufwand auf dem betroffenen Gerät notwendig war.
Nach Angaben der Forscher benötigte die schädliche Anwendung weder Zugriff auf Kontakte noch auf Dateien, Kamera oder andere geschützte Android-Funktionen.
Auch eine zusätzliche Bestätigung durch den Benutzer war für den demonstrierten Angriff nicht erforderlich.
Allerdings musste die manipulierte App bereits auf dem Android-Gerät installiert sein. Außerdem musste dort ein entsprechendes Microsoft-Geschäftskonto im Authenticator angemeldet sein.
Es handelte sich also nicht um einen Angriff, bei dem jemand allein durch den Besuch einer Webseite automatisch seine Zugangsdaten verliert.
Trotzdem ist das Risiko erheblich. Gerade scheinbar harmlose Android-Anwendungen können gefährlich werden, wenn eine installierte Sicherheitskomponente ihnen mehr vertraut, als sie sollte.
So konnte sich eine schädliche App als Microsoft Teams ausgeben
Technisch lag der Fehler in einer Android-Komponente mit dem Namen com.microsoft.identity.client.AccountChooserActivity.
Diese sogenannte Activity war für andere Anwendungen erreichbar. Das ist bei Android grundsätzlich nichts Ungewöhnliches, denn Apps müssen für bestimmte Aufgaben miteinander kommunizieren können.
Entscheidend ist, welche Informationen dabei akzeptiert werden.
Im vorliegenden Fall konnte eine aufrufende Anwendung selbst angeben, welche App sie angeblich ist. Dazu gehörten unter anderem der Paketname, die Client-ID und weitere Angaben für die Authentifizierung.
Der Microsoft Authenticator führte zwar eine Sicherheitsprüfung durch. Diese kontrollierte allerdings hauptsächlich, ob die übermittelte Anmeldeadresse zur behaupteten Anwendung passte.
War beispielsweise Microsoft Teams tatsächlich auf dem Gerät installiert, konnte die manipulierte App die notwendigen öffentlich zugänglichen Signaturinformationen verwenden, um eine passende Anfrage zu erstellen.
Die Prüfung wurde dadurch erfolgreich abgeschlossen.
Was fehlte, war die entscheidende Kontrolle: Stammt die Anfrage wirklich von Microsoft Teams oder nur von einer Anwendung, die sich dafür ausgibt?
Besonders ärgerlich ist, dass der Authenticator die tatsächliche aufrufende Anwendung grundsätzlich identifizieren konnte. Diese Information wurde jedoch nicht für die notwendige Vertrauensentscheidung verwendet.
Ein klassischer Fall von: Die Sicherheitsprüfung ist vorhanden, kontrolliert aber nicht das, worauf es wirklich ankommt.
Welche Daten konnten Angreifer abgreifen?
Den Forschern gelang es, über die Schwachstelle verschiedene Authentifizierungstoken zu erhalten.
Dazu gehörten unter anderem Access Tokens und Refresh Tokens.
Ein Access Token erlaubt einer Anwendung für einen begrenzten Zeitraum den Zugriff auf bestimmte Dienste. Ein Refresh Token kann unter passenden Bedingungen verwendet werden, um neue Zugriffstoken zu erhalten, ohne dass sich der Benutzer erneut mit seinem Passwort anmelden muss.
Gerade deshalb sind solche Informationen für Angreifer interessant.
In den Tests konnten die Forscher durch die Nachahmung verschiedener Microsoft-Anwendungen weitreichende Zugriffsrechte erhalten.
Je nach angefragter Anwendung und den bereits gewährten Berechtigungen waren unter anderem folgende Aktionen möglich:
E-Mails lesen, verändern und versenden
Dateien in OneDrive und SharePoint aufrufen oder bearbeiten
Kalender und Termine verändern
Nachrichten über Microsoft-Dienste verschicken
Auf weitere über Microsoft Graph erreichbare Unternehmensdaten zugreifen
Die Forscher zeigten außerdem, dass sich durch die Nachahmung des Authenticator-eigenen Clients Berechtigungen im Zusammenhang mit der Verwaltung von Authentifizierungsmethoden und Passkeys erhalten ließen.
Das bedeutet nicht, dass automatisch jedes Microsoft-365-Konto vollständig übernommen werden konnte. Die tatsächlichen Möglichkeiten hingen von den jeweiligen Token und Berechtigungen ab.
Trotzdem ist der potenzielle Schaden beträchtlich.
Warum ist das gerade für Unternehmen problematisch?
Viele Unternehmen setzen inzwischen vollständig auf Microsoft 365. E-Mails laufen über Exchange Online, Dateien liegen in OneDrive oder SharePoint und die tägliche Kommunikation findet über Teams statt.
Der Microsoft Authenticator spielt dabei häufig eine zentrale Rolle bei der Anmeldung.
Wird ein gültiges Zugriffstoken gestohlen, kann ein Angreifer unter Umständen auf geschützte Ressourcen zugreifen, ohne das eigentliche Kontopasswort zu kennen.
Auch eine bereits erfolgreich abgeschlossene Zwei-Faktor-Authentifizierung schützt nicht automatisch davor, dass anschließend ausgestellte Sitzungstoken missbraucht werden.
Genau das macht solche Sicherheitslücken so unangenehm.
Meiner Meinung nach wird die Sicherheit von Anmeldetoken im Alltag noch immer unterschätzt. Viele achten verständlicherweise auf starke Passwörter und die Zwei-Faktor-Authentifizierung. Dass aber auch die dahinterliegenden Sitzungsinformationen entsprechend geschützt werden müssen, gerät schnell in den Hintergrund.
Für Unternehmen mit verwalteten Android-Geräten ist das daher mehr als nur ein kleiner Fehler in einer Smartphone-App.
Microsoft hat die Schwachstelle bereits geschlossen
Die gute Nachricht: Der Fehler wurde bereits behoben.
Die korrigierte Version des Microsoft Authenticators für Android trägt die Versionsnummer 6.2606.4246 und wurde im Juli 2026 veröffentlicht.
Betroffen sind ältere Versionen der Anwendung.
Die Sicherheitslücke wurde am 8. September 2026 offiziell unter CVE-2026-80097 veröffentlicht. Am 23. Oktober machten die Enclave-Forscher ihre detaillierte technische Analyse unter dem Namen AuthMask öffentlich.
Es handelt sich deshalb nicht um eine erst am 26. Oktober entdeckte oder ungepatchte Schwachstelle. Die aktuellen Berichte erklären vor allem, wie sich der inzwischen behobene Fehler ausnutzen ließ.
Wer den Microsoft Authenticator regelmäßig über den Google Play Store aktualisiert, dürfte die Sicherheitskorrektur bereits erhalten haben.
Eine kurze Kontrolle schadet trotzdem nicht.
Was sollten Android-Nutzer jetzt tun?
Wer den Microsoft Authenticator auf einem Android-Smartphone verwendet, sollte zunächst prüfen, ob eine aktuelle Version installiert ist.
Dazu lässt sich im Google Play Store die App-Seite des Microsoft Authenticators öffnen. Wird dort eine Aktualisierung angeboten, sollte sie installiert werden.
Zusätzlich lässt sich die installierte Versionsnummer über die Android-App-Informationen kontrollieren.
Die Version sollte mindestens 6.2606.4246 entsprechen. Empfehlenswert ist grundsätzlich die neueste verfügbare Ausgabe.
Außerdem lohnt es sich, die installierten Anwendungen kritisch durchzugehen. Unbekannte oder nicht mehr benötigte Apps sollten vom Gerät entfernt werden.
Besonders bei Anwendungen aus unbekannten Quellen ist Vorsicht sinnvoll.
Was sollten IT-Administratoren beachten?
In Unternehmensumgebungen reicht es nicht unbedingt aus, einfach auf automatische App-Updates zu vertrauen.
IT-Abteilungen sollten über ihre Mobile-Device-Management-Lösung überprüfen, welche Authenticator-Versionen auf verwalteten Android-Geräten eingesetzt werden.
Zusätzlich sind einige Sicherheitsmaßnahmen sinnvoll:
Aktualisierungen für sicherheitsrelevante Anwendungen konsequent durchsetzen
Nicht verwaltete oder nicht konforme Geräte beim Zugriff auf Unternehmensdaten einschränken
Die Installation unbekannter Anwendungen möglichst begrenzen
Auffällige Anmeldungen und ungewöhnliche Microsoft-Graph-Zugriffe überwachen
Bei einem konkreten Verdacht auf kompromittierte Token bestehende Sitzungen und Aktualisierungstoken widerrufen
Vor allem bei größeren Microsoft-365-Umgebungen sollten entsprechende Kontrollen bereits zur normalen Sicherheitsstrategie gehören.
Sind bereits Angriffe bekannt?
Die Sicherheitsforscher konnten die Schwachstelle praktisch demonstrieren. Damit steht fest, dass es sich nicht nur um ein theoretisches Problem handelte.
Öffentlich bestätigte Hinweise auf eine aktive Ausnutzung durch Kriminelle liegen bislang allerdings nicht vor.
Das ist eine wichtige Unterscheidung.
Eine nachgewiesene technische Angriffsmöglichkeit bedeutet nicht automatisch, dass bereits zahlreiche Benutzer betroffen sind.
Trotzdem sollte man die Sicherheitslücke nicht unterschätzen. Schließlich können gestohlene Anmeldetoken je nach Berechtigung erhebliche Folgen haben.
Fazit: Auch eine Sicherheits-App muss ihre Gegenstelle überprüfen
Der Fehler im Microsoft Authenticator zeigt ziemlich deutlich, dass Sicherheit nicht allein durch zusätzliche Anmeldebestätigungen entsteht.
Eine Anwendung kann noch so zuverlässig Passwörter und Anmeldungen absichern. Wenn sie anschließend einer fremden App vertrauliche Zugriffstoken überlässt, weil deren Identität nicht sauber überprüft wurde, hilft die beste Absicherung an anderer Stelle nur begrenzt.
Besonders bemerkenswert finde ich, dass die schädliche Anwendung nicht einmal besondere Android-Berechtigungen benötigte. Eine falsch umgesetzte Vertrauensprüfung reichte aus.
Immerhin hat Microsoft die Schwachstelle bereits geschlossen. Wer eine aktuelle Authenticator-Version verwendet, ist gegen diesen konkreten Fehler geschützt.
Mein Fazit: Kein Grund zur Panik, aber ein guter Anlass, die installierte Version zu kontrollieren. Für Unternehmen sollte der Vorfall außerdem eine Erinnerung sein, dass mobile Geräte längst ein wichtiger Teil der eigenen IT-Sicherheitsinfrastruktur sind.
Denn am Ende entscheidet nicht nur, wie sicher sich ein Benutzer anmeldet, sondern auch, welche Anwendungen anschließend auf seine digitalen Identitäten zugreifen dürfen.
Quellen
Enclave – Technische Sicherheitsanalyse „AuthMask“ vom 23. Oktober 2026
https://enclave.ai/blog/authmask-we-made-microsoft-authenticator-hand-over-tokens
Microsoft Security Response Center – CVE-2026-80097
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-80097
Cyber Security News – Berichterstattung vom 26. Oktober 2026
https://cybersecuritynews.com/microsoft-authenticator-flaw/
National Vulnerability Database – CVE-2026-80097
https://nvd.nist.gov/vuln/detail/CVE-2026-80097
