N0va: phishkit przejmuje sesje przez device code phishing

Najbardziej mylący element tego scenariusza polega na tym, że użytkownik może zobaczyć legalny proces logowania Microsoft i przejść wymagane uwierzytelnienie. Jeżeli jednak kod urządzenia został wygenerowany dla sesji rozpoczętej przez napastnika, zatwierdzenie procesu może doprowadzić do wydania dostępu i tokenów kontrolowanych przez atakującego.

N0va nie tworzy nowej klasy ataku. To aktualna kampania wykorzystująca znany mechanizm. Techniczne podstawy opisujemy szerzej w artykule Device code phishing w Microsoft 365.

Co wiadomo o kampanii N0va

Według materiału The Hacker News, opartego na analizie ANY.RUN, N0va był obserwowany w kampaniach wymierzonych w organizacje w Ameryce Północnej i Europie. Wśród wskazanych sektorów znalazły się administracja publiczna, technologie, konsulting i ochrona zdrowia.

Przynęty podszywały się między innymi pod Microsoft Security, Teams, SharePoint, OneDrive, DocuSign, Google Drive, Dropbox, Zoom i Adobe Sign. Sama lista marek nie jest jednak najistotniejsza. W praktyce wspólnym elementem jest wiarygodny kontekst biznesowy, który ma skłonić użytkownika do rozpoczęcia procesu uwierzytelnienia.

Badacze opisywali również rozproszoną infrastrukturę: elementy kampanii mogły korzystać z przejętych legalnych witryn oraz usług chmurowych. To utrudnia ocenę zdarzenia na podstawie pojedynczego sygnału, ale nie oznacza, że każdy wymieniony dostawca lub host jest złośliwy.

Jak N0va wykorzystuje device code phishing

W device code flow aplikacja rozpoczyna proces uwierzytelnienia i otrzymuje kod, który użytkownik wpisuje w odpowiednim portalu. Mechanizm ma legalne zastosowania, ale może zostać nadużyty, gdy proces rozpoczyna napastnik, a kod przekazuje ofierze jako część przynęty.

Opisany łańcuch zaczyna się od przynęty wykorzystującej zaufaną usługę. Następnie ofiara otrzymuje instrukcję z kodem urządzenia i trafia do prawdziwego procesu uwierzytelniania Microsoft. Po zalogowaniu i wykonaniu wymaganych kroków infrastruktura atakującego może uzyskać access token i refresh token związane z rozpoczętą sesją.

Według relacji z analizy ANY.RUN N0va wykorzystywał następnie mechanizmy token exchange lub rejestracji urządzenia, aby dążyć do dostępu SSO do zasobów firmowych. Źródła opisują w tym kontekście próbę uzyskania dostępu opartego na Primary Refresh Token. To ważne rozróżnienie: samo przejście przez prawdziwą stronę logowania nie potwierdza, że użytkownik autoryzuje proces, który sam rozpoczął.

Dlaczego MFA może nie wystarczyć

MFA chroni przed wieloma scenariuszami przejęcia hasła, ale device code phishing wykorzystuje inną zależność. Ofiara nie musi przekazywać napastnikowi jednorazowego kodu MFA. Może sama wykonać wymagane uwierzytelnienie na legalnej stronie, jednocześnie zatwierdzając sesję zainicjowaną poza swoim normalnym procesem pracy.

Dlatego pytanie „czy domena logowania jest prawdziwa?” nie wystarcza. Użytkownik powinien również wiedzieć, kto rozpoczął proces, skąd pochodzi kod urządzenia i czy rzeczywiście właśnie łączy urządzenie lub aplikację z kontem służbowym.

Jeżeli kod pojawia się w nieoczekiwanym e-mailu, dokumencie, komunikatorze albo na stronie otwartej z wiadomości, proces należy przerwać i zweryfikować innym, znanym kanałem.

Co N0va może dać napastnikowi

Access token i refresh token mogą umożliwiać dostęp do zasobów przypisanych do przejętej tożsamości zgodnie z zakresem wydanych uprawnień. The Hacker News wskazuje w kontekście N0va na pocztę, pliki i aplikacje chmurowe połączone z kontem.

Nie należy jednak traktować każdego udanego phishingu jako automatycznego pełnego przejęcia całego środowiska. Zakres skutków zależy od konfiguracji tożsamości, wydanych tokenów, polityk dostępu, rejestracji urządzenia i dalszych działań napastnika.

Dla zespołu bezpieczeństwa problemem jest to, że część aktywności może wyglądać jak korzystanie z prawidłowo uwierzytelnionego konta. Analiza powinna więc łączyć sygnały z poczty, logowania, tożsamości, urządzeń i usług chmurowych.

Co powinien zrobić użytkownik

Najważniejszym punktem decyzji jest sam kod urządzenia. Nie wpisuj kodu otrzymanego z nieoczekiwanej wiadomości tylko dlatego, że instrukcja prowadzi później do prawdziwej strony Microsoft.

Jeżeli proces nie został rozpoczęty przez Ciebie w aplikacji lub na urządzeniu, które właśnie konfigurujesz, zatrzymaj się i zweryfikuj prośbę. Nie kontynuuj na podstawie samego logo, nazwy usługi ani poprawnej domeny ostatniego ekranu.

Po wpisaniu podejrzanego kodu i zakończeniu logowania zgłoś zdarzenie natychmiast. Nie czekaj na widoczne objawy przejęcia konta.

Co powinno sprawdzić IT

Organizacja powinna najpierw ustalić, czy device code flow jest w ogóle potrzebny. Jeżeli nie ma uzasadnionych przypadków użycia, warto go ograniczyć. Jeżeli jest potrzebny, wyjątki powinny być kontrolowane i monitorowane.

Po podejrzanym zdarzeniu zespół techniczny powinien sprawdzić logowania i sesje użytkownika, unieważnić podejrzane tokeny, przeanalizować rejestrację urządzeń oraz aktywność w usługach dostępnych z przejętego konta. Zakres reakcji powinien wynikać z faktycznych śladów i konfiguracji środowiska.

W programie awareness warto ćwiczyć sytuacje, w których końcowy ekran jest prawdziwy, ale cały proces został rozpoczęty przez napastnika. Testy phishingowe dla firm mogą sprawdzać właśnie rozpoznawanie nietypowego kontekstu i bezpieczną ścieżkę zgłoszenia.

N0va a wcześniejsze kampanie device code phishing

PHISHLY opisywało już device code phishing jako technikę. N0va nie zastępuje tego materiału, bo odpowiada na inne pytanie: jak konkretna kampania z września 2026 r. łączy przynęty znanych usług, legalne uwierzytelnianie i dalsze działania na tokenach.

Dzięki temu oba materiały mają odrębne role. Artykuł o device code phishingu pozostaje technicznym przewodnikiem, a ten wpis dokumentuje aktualną kampanię N0va i jej znaczenie dla zespołów bezpieczeństwa.

Wniosek

N0va pokazuje, że legalny ekran uwierzytelniania może być częścią złośliwego łańcucha. W opisanym scenariuszu użytkownik nie powinien ufać procesowi wyłącznie dlatego, że kończy się on na prawdziwej stronie Microsoft.

Skuteczna ochrona wymaga połączenia kontroli tożsamości z zachowaniem użytkownika: ograniczenia niepotrzebnego device code flow, monitorowania nietypowych sesji oraz szkolenia pracowników, aby nie zatwierdzali procesu, którego sami nie rozpoczęli.