„Musimy ponownie skonfigurować passkey”. Jak fałszywy helpdesk przejmuje konto Microsoft 365

Dzwoni ktoś spokojny i rzeczowy. Zna nazwę firmy, przedstawia się jako pracownik helpdesku i mówi, że przed końcem dnia trzeba ponownie skonfigurować passkey albo logowanie jednokrotne. Chwilę później przychodzi SMS z instrukcją. Na ekranie pojawia się strona Microsoftu, więc całość wygląda jak zwykłe zadanie od IT.

Właśnie taki scenariusz Microsoft opisuje w aktywnych włamaniach do środowisk chmurowych obserwowanych od maja 2026 roku. Atakujący nie łamią zabezpieczeń passkey. Wykorzystują ich nazwę jako wiarygodny pretekst, a człowieka prowadzą przez proces, który daje przestępcy dostęp do konta.

Passkey jest przynętą, nie słabym punktem

Rozmówca tworzy presję: migracja właśnie trwa, konto może przestać działać, a zgłoszenie trzeba zamknąć teraz. Następnie kieruje ofiarę do strony phishingowej pośredniczącej w logowaniu albo prosi o wpisanie kodu urządzenia na autentycznej stronie Microsoftu.

Drugi wariant jest szczególnie mylący. Adres może być prawidłowy, certyfikat ważny, a logowanie naprawdę obsługiwane przez Microsoft. Problem leży w kodzie: został wygenerowany dla aplikacji kontrolowanej przez atakującego. Gdy użytkownik wpisze go i zaakceptuje logowanie, token dostępu trafia do tej aplikacji.

Dlatego komunikat „strona jest prawdziwa” nie odpowiada na najważniejsze pytanie: kto rozpoczął tę operację i dla jakiej aplikacji?

Co dzieje się po udanym logowaniu

Według Microsoft Security Research po pierwszym wejściu napastnicy dodawali własną metodę uwierzytelniania, rozpoznawali zasoby przez Microsoft Graph, pobierali pliki z SharePointa i OneDrive oraz zbierali pocztę. Pojedyncze nietypowe logowanie może więc szybko przejść w trwały dostęp do danych organizacji.

Dla zespołu bezpieczeństwa ważna jest nie tylko każda czynność osobno, lecz ich kolejność:

1. logowanie z nietypowego miejsca lub urządzenia;
2. rejestracja nowej metody uwierzytelniania;
3. intensywne zapytania do Microsoft Graph;
4. pobieranie danych z usług SaaS albo aktywność w skrzynce.

Taki łańcuch jest znacznie bardziej wymowny niż pojedynczy alert bez kontekstu.

Co powinien zrobić pracownik podczas takiego telefonu

Nie wykonuj instrukcji w trakcie niezamówionej rozmowy. Zakończ połączenie i skontaktuj się z helpdeskiem przez numer zapisany w firmowym katalogu, komunikatorze albo portalu wsparcia. Nie oddzwaniaj na numer z historii połączeń i nie korzystaj z linku przesłanego przez rozmówcę.

Nie wpisuj kodu urządzenia, którego sam nie wywołałeś na służbowym sprzęcie. Przeczytaj nazwę aplikacji, zakres zgody i treść każdego monitu. Pilność, groźba blokady konta i prośba o pominięcie zwykłej ścieżki zgłoszeń powinny zakończyć rozmowę, nie przyspieszyć kliknięcie.

Jeśli kod został już zaakceptowany, zgłoś incydent natychmiast. Sama zmiana hasła może nie wystarczyć, bo atakujący może mieć aktywną sesję, token lub dodaną metodę logowania.

Co powinien przygotować dział IT

Microsoft zaleca phishingoodporne MFA wymuszane przez Conditional Access, ograniczenie rejestracji danych zabezpieczających, wymaganie zarządzanych urządzeń oraz blokowanie przepływu kodu urządzenia, jeśli organizacja nie ma dla niego wyraźnej potrzeby biznesowej. Warto także przeglądać aplikacje i ich uprawnienia, włączyć logi aktywności Microsoft Graph oraz audyt skrzynek pocztowych.

Po potwierdzonym incydencie trzeba unieważnić sesje i tokeny, zresetować poświadczenia, usunąć metody uwierzytelniania i reguły pocztowe dodane przez napastnika, a następnie przeprowadzić bezpieczną ponowną rejestrację.

Procedura helpdesku powinna być równie konkretna jak konfiguracja techniczna. Pracownik musi wiedzieć, czy dział IT w ogóle prowadzi konfigurację przez telefon, jak potwierdza tożsamość konsultanta i gdzie zgłasza rozmowę, która wygląda podejrzanie.

Co mówi źródło, a co wnioskuje Breachroad

Microsoft opisał 9 września 2026 kampanię socjotechniczną wykorzystującą motyw passkeys. Fakty o telefonach i SMS-ach od rzekomego helpdesku, phishingu AiTM, kodach urządzeń oraz późniejszej aktywności w Microsoft 365 pochodzą z obserwacji Microsoft Security Research.

Wnioskiem Breachroad jest to, że szkolenie nie powinno sprowadzać się do rozpoznawania fałszywych domen. Użytkownik musi umieć zweryfikować także prawdziwy ekran logowania, gdy ktoś obcy steruje całym procesem. Technologia passkey pozostaje mocnym zabezpieczeniem; problemem jest przekonanie człowieka, aby autoryzował cudzą operację.

Jeśli chcesz uporządkować podstawy, przeczytaj także jak passkeys zastępują hasła. Organizacjom pomagamy ćwiczyć weryfikację takich sytuacji podczas szkoleń z cyberbezpieczeństwa.