Microsoft Authenticator kojarzy się przede wszystkim z zatwierdzaniem logowania i kodami jednorazowymi. Na Androidzie pełni jednak jeszcze jedną funkcję – jest brokerem uwierzytelniania dla aplikacji korzystających z kont służbowych. Gdy Teams lub inny klient Microsoftu potrzebuje tokenu, może zwrócić się do Authenticatora. Od brokera oczekuje się nie tylko obsługi logowania, lecz także sprawdzenia, kto naprawdę zgłasza żądanie. Właśnie na tym etapie znaleziono błąd opisany jako AuthMask.

Autor: 6 min czytania

23 października 2026 roku Ofek Levin z Enclave opublikował analizę podatności CVE-2026-80097. Pokazał, że zwykła aplikacja na Androida, niewymagająca specjalnych uprawnień systemowych, mogła podszyć się pod zainstalowany Microsoft Teams i otrzymać tokeny powiązane z kontem służbowym użytkownika. Microsoft otrzymał zgłoszenie wcześniej i udostępnił poprawkę 8 września, czyli ponad miesiąc przed publikacją szczegółów technicznych.

Aplikacja przedstawiała się jako Teams

Źródłem problemu była dostępna dla innych aplikacji aktywność AccountChooserActivity w Microsoft Authenticator. Można było ją uruchomić zewnętrznym żądaniem Androida, a następnie przekazać parametry identyfikujące rzekomego klienta. Wśród nich znajdowały się nazwa pakietu, identyfikator aplikacji, identyfikator UID oraz adres przekierowania (redirect URI).

Mechanizm weryfikował, czy adres przekierowania odpowiada podpisowi cyfrowemu aplikacji wskazanej w otrzymanych parametrach. Nie porównywał jednak tych danych z rzeczywistą tożsamością procesu, który wysłał żądanie. Gdy atakujący podał parametry zainstalowanego Teams, kontrola przechodziła pomyślnie: podpis Teams był przecież prawidłowy. Tyle że o token prosiła zupełnie inna aplikacja. Badacz ustalił, że Authenticator mógł odczytać nazwę prawdziwego wywołującego, ale nie wykorzystywał jej przy podejmowaniu decyzji o zaufaniu.

W demonstracji broker zwracał odpowiedź właśnie aplikacji inicjującej żądanie. Zawierała ona między innymi access_token i refresh_token. Nie chodziło zatem o odgadnięcie hasła czy złamanie kryptografii, lecz o błędne ustalenie, komu wolno przekazać wynik uwierzytelnienia.

Z perspektywy Entra ID nie oznacza to, że przestawały obowiązywać MFA i Conditional Access. Token był wydawany w kontekście już uwierzytelnionego konta, natomiast lokalny komponent nieprawidłowo identyfikował odbiorcę. Dostęp nadal zależał od zakresów tokenu, czasu jego ważności i stosowanych zabezpieczeń przed ponownym użyciem. Przy szerokich uprawnieniach aplikacji był to jednak wystarczający punkt wyjścia do odczytywania firmowych danych bez zdobywania hasła pracownika.

Jaki dostęp dawały przejęte tokeny?

Badacze sprawdzili trzy sposoby podszycia się pod aplikacje Microsoftu. W wariancie udającym Teams otrzymali tokeny Microsoft Graph z delegowanymi uprawnieniami do odczytu i modyfikowania poczty, plików oraz kalendarza. Wśród wskazanych zakresów znalazły się Mail.ReadWrite, Mail.Send, Files.ReadWrite.All i Calendars.ReadWrite. Inne warianty pozwoliły uzyskać uprawnienia związane z czatem Teams oraz zarządzaniem metodami uwierzytelniania, w tym operacjami dotyczącymi passkeys. Były to wyniki kontrolowanych testów, a nie dowód przejęcia rzeczywistych organizacji.

Do odtworzenia problemu potrzebny był telefon z podatną wersją Authenticatora, zalogowanym kontem służbowym i zainstalowaną złośliwą aplikacją. Ważna jest jednak rozbieżność w opisie warunków ataku. Microsoft ocenił podatność na 8,6 w skali CVSS i wskazał wymaganą interakcję użytkownika w procesie uwierzytelniania. Enclave twierdzi natomiast, że podczas testów wystarczył stan zalogowania i nie było potrzeby kolejnego potwierdzania operacji. Nie należy łączyć tych stanowisk w bezwarunkowe twierdzenie, że atak zawsze działał bez udziału użytkownika.

W dokumentacji podatności wektor ataku oznaczono jako lokalny. To istotne rozróżnienie: nie wystarczała znajomość adresu e-mail ofiary ani sam dostęp do Internetu. Złośliwy kod musiał trafić na jej telefon. Brak wymaganych uprawnień Androida nie oznaczał braku potrzeby instalacji aplikacji.

Co oznacza to dla administratorów Entra ID?

Podatne były wersje Microsoft Authenticator dla Androida wcześniejsze niż 6.2606.4246. Microsoft opublikował poprawkę 8 września 2026 roku; iOS nie figuruje na liście produktów objętych tym CVE. Pierwszym zadaniem jest więc ustalenie, które urządzenia nadal korzystają ze starej aplikacji, i wymuszenie aktualizacji przez przyjęty w organizacji sposób zarządzania urządzeniami.

Jeśli istnieją przesłanki kompromitacji telefonu, samo zainstalowanie poprawki nie wystarczy do oceny skutków wcześniejszego dostępu. Warto przejrzeć telemetrię urządzenia, logowania użytkownika i nietypową aktywność w Microsoft Graph, a w razie potwierdzenia incydentu unieważnić odpowiednie sesje oraz zweryfikować zmiany metod uwierzytelniania. Trzeba przy tym pamiętać, że logi Entra ID nie pokażą bezpośrednio momentu przekazania tokenu między dwiema aplikacjami na telefonie.

Dlatego kontrola wersji Authenticatora powinna iść w parze z przeglądem aplikacji zainstalowanych na urządzeniach zarządzanych i alertów ochrony mobilnej. W przypadku telefonów prywatnych zakres dostępnej telemetrii może być mniejszy, co warto uwzględnić przy ocenie ryzyka i planowaniu reakcji.

Nie ma obecnie potwierdzonych informacji, że AuthMask był wykorzystywany w rzeczywistych atakach. Ten przypadek jest jednak ważny z innego powodu – nawet prawidłowo wystawiony token może trafić do niewłaściwego odbiorcy, jeżeli komponent obsługujący logowanie ufa danym zadeklarowanym przez aplikację, zamiast sprawdzać, która aplikacja rzeczywiście je wysłała.