Eine Sicherheitslücke im Microsoft Authenticator für Android reichte fremden Apps auf Wunsch Zugriffsschlüssel für Microsoft 365 durch – ganz ohne Systemberechtigungen. Es genügte, wenn sich eine App als Microsoft Teams ausgab. Microsoft hat das Problem unter CVE-2026-80097 geschlossen, doch der Fehler sitzt an einer unbequemen Stelle.
Eine beliebige App auf dem Android-basierten Smartphone, installiert über irgendeinen harmlosen Umweg, musste nur eine einzige "Kennung" suggerieren und sich als Microsoft Teams ausgeben. Der Microsoft Authenticator vertraute ihr – und händigte im Hintergrund einen gültigen Zugriffstoken für das Microsoft-365-Konto aus. Kein Passwort, keine 2FA-Abfrage, keine Berechtigung, die der Nutzer hätte bestätigen müssen. Genau diese Lücke beschreibt der Sicherheitsforscher Ofek Levin unter dem Namen AuthMask 1.
Das Pikante daran: Die Authenticator-App ist das Werkzeug, das solche Vorfälle eigentlich verhindern soll. Für Millionen Unternehmensnutzer ist die App der zweite Faktor, die Instanz, die jeden Anmeldeversuch absichert. Dass ausgerechnet diese App Zugriffsschlüssel an einen nicht autorisierten Aufrufer durchreicht, kehrt die Logik der Multi-Faktor-Authentifizierung um.
Microsoft Teams spielen. Microsoft 365 abräumen.
Technisch dreht sich alles um eine exportierte Android-Komponente namens AccountChooserActivity 1. Exportiert bedeutet: Andere Apps auf demselben Gerät dürfen sie ansprechen. Das ist bei Android nichts Ungewöhnliches, solange die aufgerufene Komponente sorgfältig prüft, wer da klopft. Genau diese Prüfung fehlte.
Der Authenticator kontrollierte zwar, ob die App, deren Identität behauptet wurde – also Teams –, überhaupt mit einer gültigen Signatur installiert war. Im entscheidenden Schritt aber vergaß die App zu verifizieren, welche App das Token tatsächlich anforderte 1. Eine fremde App konnte also schlicht erklären, sie sei Teams, die passenden Parameter mitliefern und den Schlüssel in Empfang nehmen. Das Token kam im Klartext zurück.
Dieser Unterschied zwischen „Ist die behauptete App installiert?" und „Ist die anfragende App wirklich diese App?" wirkt vielleicht zu spezifisch, ist aber entscheidend. Vergleichbar ist das mit einem Pförtner, der prüft, ob der genannte Mitarbeiter im Haus existiert – ohne je den Ausweis des Besuchers zu verlangen, der dessen Namen nennt.
Der Generalschlüssel aus dem Authenticator
Ein einzelnes Zugriffstoken für Microsoft 365 ist kein harmloses Cookie. Mit dem erbeuteten Schlüssel ließ sich auf die Microsoft Graph API zugreifen – und damit auf nahezu alles, was das betroffene Konto hergibt: lesender und schreibender Zugriff auf das Postfach, auf Kalendereinträge, auf Chats sowie auf Dateien in OneDrive und SharePoint 1. Wer diesen Zugang hat, kann E-Mails mitlesen, in fremdem Namen schreiben, Termine ausspähen oder Dokumente abziehen.
Für den Angriff genügte, dass der Authenticator mit einem aktiven Geschäftskonto angemeldet war – der Normalzustand auf dem Diensthandy eines jeden Angestellten 1. Die bösartige App brauchte keine der auffälligen Android-Berechtigungen, über die ein aufmerksamer Nutzer stolpern könnte: keinen Zugriff auf Kontakte, keine Standortfreigabe, nichts, was im Installationsdialog Alarm ausgelöst hätte. Gerade diese Unauffälligkeit macht die Lücke aus Sicht eines Angreifers attraktiv.
Microsofts Bewertung des Vorfalls
Microsoft führt die Schwachstelle als CVE-2026-80097 und stuft sie mit einem CVSS-Wert von 8.6 als hoch ein 2. Formal ist sie als Elevation of Privilege klassifiziert, die zugrunde liegende Schwäche trägt die Kennung CWE-287 – fehlerhafte Authentifizierung 2. Das trifft den Kern: Nicht ein kryptografischer Bruch, nicht ein Pufferüberlauf, sondern eine schlicht ausgelassene Identitätsprüfung öffnete den Weg.
Was Microsoft auch behauptet: Die Lücke sei nach aktuellem Kenntnisstand nicht aktiv ausgenutzt worden; öffentlichen Exploit-Code oder einen Proof of Concept gibt es bislang nicht 2. Offengelegt wurde die Schwachstelle am 8. September 2026 im Rahmen des monatlichen Patch-Zyklus 2. Eine Entwarnung ist das nicht: Die Hürde für einen Nachbau ist niedrig, weil der Angriff keine exotische Technik erfordert, sondern das bewusste Ausnutzen einer offenen Komponente.
Die Schwachstelle hinter der Schwachstelle
Für Sicherheitsverantwortliche darf die Lehre aus dem Vorfall nicht einfach mit dem nächsten Update enden. Diese sensible Schwachstelle zeigt auf, wie viel Vertrauen Unternehmen in eine einzelne Sicherheitsanwendung legen – und wie schnell dieses Vertrauen zum Problem werden kann.
Das eigentliche Problem liegt für Daniel Schönland, Gründer des Cybersicherheitsunternehmens Identiqa und Herausgeber von #derimeter, auf einer anderen Ebene: dort, wo ein einziger Anbieter zugleich Identitäten verwaltet, die Authentifizierung absichert und den Zugang zur Cloud kontrolliert.
„Wer einem Anbieter allein alle Schlüssel anvertraut, schafft problematische Abhängigkeiten“, erklärt Schönland. „Unternehmen sollten unabhängige Sicherheitsmechanismen etablieren – etwa alternative Authentifizierungslösungen, Hardware-Sicherheitsschlüssel und zusätzliche Zugriffskontrollen. Auch ein externer, an Microsoft Entra angebundener Identitätsdienst kann sinnvoll sein, sofern er eine eigenständige Sicherheitsprüfung durchsetzt.“
Entscheidend sei nicht die Zahl der eingesetzten Produkte, sondern die Sicherung der Login-Ebene.
„Wenn ein einziger Fehler gleich so gut wie alle Sicherheitsbarrieren zum Schutz von Benutzerkonten aushebelt, waren diese Barrieren nie wirklich unabhängig. Single bzw. Preferred Vendor Strategien klingen im IT Management zwar zunächst gut, sind aber kein Sicherheitskonzept.“
Ähnliche Artikel
