ConsentFix v3 i phishing OAuth. Jak przejęcie kodu daje dostęp do Microsoft 365

2026-05-14

TL;DR

ConsentFix v3 to phishing OAuth wymierzony w środowiska Microsoft 365 i Microsoft Entra ID. Nie polega na klasycznym wyłudzeniu hasła. Atakujący próbuje nakłonić użytkownika do udziału w prawdziwym przepływie logowania Microsoft, a następnie przejąć kod autoryzacyjny, który może zostać wymieniony na access token i refresh token. Z perspektywy ofiary proces może wyglądać wiarygodnie, bo część logowania rzeczywiście odbywa się po stronie Microsoft.

Najkrótsza odpowiedź dla użytkownika brzmi: jeżeli strona, mail, reklama albo instrukcja prosi o kopiowanie adresu z przeglądarki, przeciąganie URL-a, wklejanie kodu, naprawianie logowania albo przekazywanie technicznego komunikatu z procesu Microsoft, przerwij działanie i zweryfikuj sprawę poza linkiem. Prawdziwa domena Microsoft w jednym kroku nie oznacza, że cały proces jest bezpieczny.

Dla organizacji ConsentFix v3 jest sygnałem, że program ochrony tożsamości nie może kończyć się na haśle i MFA. Trzeba rozumieć aplikacje OAuth, tokeny, sesje, logi Microsoft Entra ID, zgody aplikacyjne, użycie pierwszostronnych aplikacji Microsoft i zachowania użytkowników, które nie wyglądają jak klasyczne podanie hasła na fałszywej stronie.

Czym jest ConsentFix v3

ConsentFix v3 rozwija technikę opisaną wcześniej przez Push Security jako połączenie phishingu OAuth i socjotechniki podobnej do ClickFix. W typowym ClickFix użytkownik jest przekonywany, że musi skopiować i uruchomić polecenie, aby naprawić rzekomy problem. W ConsentFix podobny mechanizm przenosi się do przeglądarki i tożsamości: użytkownik ma wykonać instrukcję, która wygląda jak techniczne obejście błędu logowania, weryfikacji albo dostępu.

OAuth 2.0 to standard autoryzacji, który pozwala aplikacjom uzyskać dostęp do zasobów użytkownika bez poznawania jego hasła. W prawidłowym scenariuszu aplikacja otrzymuje kod autoryzacyjny, a następnie wymienia go na tokeny dostępu. Access token pozwala wykonać określone operacje, a refresh token może służyć do uzyskiwania nowych tokenów bez ponownego logowania, dopóki jest ważny i nie zostanie unieważniony.

W ConsentFix problem zaczyna się wtedy, gdy kod autoryzacyjny trafia nie do właściwej aplikacji, ale do strony kontrolowanej przez atakującego. Użytkownik może nie wpisywać hasła na fałszywej stronie. Może nawet zobaczyć prawdziwy proces Microsoft. Mimo to oddaje element, który pozwala atakującemu działać dalej w kontekście jego konta.

ConsentFix v3 jest istotny nie dlatego, że całkowicie zmienia zasady OAuth, ale dlatego, że próbuje zoperacjonalizować atak. Według Push Security toolkit opisywany na forum przestępczym ma wspierać przygotowanie infrastruktury, person, kampanii e-mail, zbieranie materiału OAuth i automatyzację wymiany przejętego materiału na tokeny. To przesuwa technikę z poziomu ciekawego proof of concept w stronę gotowego procesu phishingowego.

Jak działa przejęcie kodu OAuth

Najprostszy wariant ConsentFix zaczyna się od przynęty: reklamy, wyniku wyszukiwania, linku, strony udającej weryfikację, fałszywego komunikatu o błędzie albo instrukcji technicznej. Użytkownik trafia na stronę, która nie musi od razu wyglądać jak klasyczny phishing. Może przypominać ekran weryfikacji, panel pomocy, procedurę dostępu albo techniczną instrukcję dla osoby korzystającej z Microsoft 365.

Następnie atak inicjuje legalny przepływ OAuth. W opisanych przez badaczy wariantach istotną rolę odgrywały pierwszostronne aplikacje Microsoft, takie jak Azure CLI, czyli narzędzie wiersza poleceń używane do pracy z usługami Microsoft Azure. Dla wielu organizacji taka aplikacja jest zaufana, a jej użycie nie wygląda tak podejrzanie jak losowa aplikacja od nieznanego wydawcy.

Po udanym uwierzytelnieniu przeglądarka może zostać przekierowana na adres localhost z kodem autoryzacyjnym w URL-u. Localhost oznacza lokalny adres komputera użytkownika. W normalnym procesie aplikacja działająca lokalnie przejęłaby ten kod i dokończyła logowanie. W ataku użytkownik dostaje instrukcję, aby skopiować albo przeciągnąć pełny adres z przeglądarki z powrotem do strony atakującego. W tym adresie znajduje się kod, którego użytkownik nie powinien nikomu przekazywać.

Po przejęciu kodu atakujący może próbować wymienić go na tokeny. W zależności od aplikacji, zakresów uprawnień, konfiguracji tenantów i dalszych działań może to dawać dostęp do poczty, plików, danych w Microsoft Graph, SharePoint, OneDrive, Teams albo innych zasobów dostępnych dla danego użytkownika. Ryzyko rośnie, gdy ofiarą jest administrator, developer, osoba z szerokim dostępem do danych albo pracownik działu finansów, HR lub zarządu.

Dlaczego prawdziwe logowanie Microsoft nie wystarcza

W klasycznym phishingu uczymy użytkownika, aby sprawdzał domenę, nie wpisywał hasła na podejrzanej stronie i nie ufał linkom prowadzącym do fałszywych formularzy. ConsentFix jest trudniejszy, bo część procesu może przechodzić przez prawdziwą stronę Microsoft. Użytkownik może uznać, że skoro logowanie jest prawdziwe, to również instrukcja po logowaniu jest bezpieczna.

To fałszywe poczucie bezpieczeństwa jest sercem problemu. Atak nie musi kraść hasła, jeśli użytkownik ma aktywną sesję albo prawidłowo przejdzie uwierzytelnienie. MFA, czyli wieloskładnikowe uwierzytelnianie, nadal pozostaje potrzebną warstwą ochrony, ale nie rozwiązuje każdego scenariusza kradzieży tokenów. W ConsentFix użytkownik nie tyle oddaje hasło, ile pomaga atakującemu dokończyć legalnie wyglądający proces autoryzacji.

Podobna lekcja pojawia się przy phishingu omijającym MFA w modelu AiTM. Mechanizm jest inny, ale punkt ciężkości ten sam: obrona musi obejmować sesję, token, kontekst logowania i zachowanie użytkownika, a nie tylko sam formularz hasła.

ConsentFix, device code phishing i klasyczny consent phishing

Warto rozdzielić trzy pojęcia, bo w praktyce często wrzuca się je do jednego worka. Klasyczny consent phishing polega na tym, że użytkownik nadaje uprawnienia złośliwej lub nadużytej aplikacji chmurowej. Widzi ekran zgody, zatwierdza dostęp, a aplikacja otrzymuje uprawnienia do danych.

Device code phishing wykorzystuje inny legalny przepływ OAuth, zaprojektowany dla urządzeń z ograniczonym interfejsem, takich jak telewizory, drukarki albo narzędzia CLI. Atakujący generuje kod urządzenia, pokazuje go ofierze i nakłania ją do wpisania go na prawdziwej stronie Microsoft. Użytkownik myśli, że potwierdza własny dostęp, a w praktyce autoryzuje sesję atakującego.

ConsentFix opiera się natomiast na przejęciu kodu autoryzacyjnego z przepływu authorization code flow. W uproszczeniu: atakujący nie prosi o hasło i nie musi pokazywać fałszywego formularza logowania. Manipuluje użytkownikiem tak, aby przekazał URL albo kod będący efektem prawdziwego procesu OAuth.

Wszystkie trzy scenariusze mają wspólny mianownik. Atakujący przesuwają uwagę z hasła na zaufane mechanizmy autoryzacji. To wymaga innego języka w edukacji pracowników. Sam komunikat nie podawaj hasła jest za wąski, jeśli atak prosi o kod, URL, zgodę aplikacji, potwierdzenie urządzenia albo wykonanie technicznej instrukcji.

Jak taki scenariusz może wyglądać w Polsce

W polskiej organizacji ConsentFix może przyjść jako fałszywa instrukcja dostępu do Microsoft 365, Teams, SharePointa, portalu HR, panelu helpdesku, systemu ticketowego, środowiska Azure albo narzędzia developerskiego. Nie musi przypominać bankowego phishingu. Może wyglądać jak procedura służbowa: naprawa błędu logowania, odnowienie dostępu, weryfikacja konta, test po migracji do Entra ID albo instrukcja dla administratora.

Szczególnie narażone są osoby, które na co dzień wykonują techniczne czynności i są przyzwyczajone do kopiowania URL-i, kodów, tokenów, komunikatów błędów albo fragmentów konfiguracji. Administrator, developer, analityk danych czy osoba z działu IT może potraktować nietypową instrukcję jako zwykły troubleshooting. Właśnie dlatego ten scenariusz nie dotyczy wyłącznie osób nietechnicznych.

W polskim wariancie przynęta mogłaby odnosić się do firmowej poczty, intranetu, e-Doręczeń, portalu dostawcy, audytu bezpieczeństwa, migracji Microsoft 365, zmian w Entra ID albo pilnej weryfikacji konta po incydencie. Jeśli organizacja używa Microsoft 365 jako centrum komunikacji, przejęcie tokenu może szybko przełożyć się na dostęp do skrzynek, dokumentów, historii rozmów, danych klientów i korespondencji finansowej.

Co zrobić, jeśli to już się stało

Jeżeli użytkownik wkleił adres localhost, przekazał kod, zatwierdził nietypowy proces Microsoft albo podejrzewa, że wykonał instrukcję z fałszywej strony, nie powinien samodzielnie porządkować śladów. Trzeba od razu zgłosić zdarzenie do IT, Security lub SOC i opisać, co dokładnie zostało zrobione: jaki link otwarto, czy było logowanie Microsoft, czy pojawił się adres localhost, czy wklejono URL, czy zatwierdzono MFA i z jakiego urządzenia korzystano.

Po stronie technicznej pierwszym krokiem jest ograniczenie dalszego użycia przejętych sesji. W praktyce oznacza to unieważnienie sesji i refresh tokenów użytkownika, wymuszenie ponownego logowania, zmianę hasła, jeżeli istnieje ryzyko szerszej kompromitacji, oraz sprawdzenie ostatnich logowań interaktywnych i nieinteraktywnych w Microsoft Entra ID. Sama zmiana hasła może nie wystarczyć, jeśli aktywne tokeny nadal pozwalają na dostęp.

Należy sprawdzić również aktywność w poczcie, Microsoft Graph, SharePoint, OneDrive i Teams. Szczególnej uwagi wymagają nowe reguły skrzynki, przekierowania poczty, nietypowe pobrania plików, wyszukiwania w wiadomościach, dostęp z lokalizacji niepasujących do użytkownika, użycie aplikacji takich jak Azure CLI oraz działania wykonane krótko po podejrzanym logowaniu.

Jeżeli użytkownik ma uprawnienia administracyjne albo dostęp do danych wrażliwych, reakcja powinna być szersza. Trzeba ocenić, czy doszło do eskalacji, rejestracji nowego urządzenia, nadania zgód aplikacyjnych, dostępu do sekretów, pobrania danych, użycia konta do wysyłki dalszego phishingu albo przygotowania reguł utrwalających dostęp.

Co powinno sprawdzić IT, Security i SOC

Obrona przed ConsentFix nie powinna opierać się wyłącznie na blokowaniu pojedynczych domen. Takie ataki mogą korzystać z legalnych stron, wysokiej reputacji infrastruktury, krótkotrwałych przekierowań i prawdziwych usług Microsoft. Dlatego kontrola powinna objąć tożsamość, aplikacje, sesje i logi.

W Microsoft Entra ID trzeba sprawdzać nietypowe logowania do pierwszostronnych aplikacji, zwłaszcza tam, gdzie użycie powinno być ograniczone do administratorów lub developerów. Szczególne znaczenie mają logowania związane z Azure CLI, nietypowe zasoby, non-interactive sign-ins następujące po legalnym logowaniu użytkownika, dostęp przez Microsoft Graph, różnice między adresem IP pierwotnego logowania a późniejszą aktywnością oraz użycie zasobów, których użytkownik zwykle nie dotyka.

Organizacja powinna przejrzeć zasady zgód aplikacyjnych, ograniczenia user consent, proces admin consent, konfigurację Conditional Access, możliwość ograniczenia dostępu do wybranych aplikacji pierwszostronnych tylko do grup, które faktycznie ich potrzebują, oraz monitorowanie aplikacji z rodziny FOCI. FOCI, czyli Family of Client IDs, pozwala w określonych scenariuszach używać refresh tokenów między powiązanymi aplikacjami, co może zwiększać skutki przejęcia tokenu.

Trzeba też oddzielić rekomendacje dla device code phishing od ConsentFix. Blokowanie albo ograniczanie device code flow może pomóc przy atakach wykorzystujących kod urządzenia, ale ConsentFix używa innego przepływu. W tym przypadku potrzebne są kontrole wokół authorization code flow, aplikacji pierwszostronnych, tokenów, logów i zachowań w przeglądarce.

Jak ćwiczyć taki scenariusz w awareness

ConsentFix jest dobrym przykładem scenariusza, którego nie da się dobrze przećwiczyć wyłącznie testem na kliknięcie. Użytkownik może kliknąć prawdziwy link Microsoft, nie wpisać hasła na fałszywej stronie i nadal doprowadzić do ryzyka, jeśli przekaże kod autoryzacyjny albo wykona instrukcję z phishingowej strony.

W testach phishingowych dla firm taki scenariusz powinien mierzyć kilka momentów decyzji. Czy użytkownik rozpoznaje nietypową instrukcję? Czy zatrzymuje się przy prośbie o kopiowanie URL-a? Czy rozumie, że kod w adresie przeglądarki może być wrażliwy? Czy zgłasza wiadomość do właściwego kanału? Czy po błędzie potrafi szybko opisać, co zrobił?

Dla organizacji cenniejsza od samej statystyki kliknięć jest informacja, gdzie proces się załamał. Inaczej wygląda ryzyko, gdy użytkownik tylko otworzył stronę, inaczej gdy przeszedł logowanie, a jeszcze inaczej gdy wkleił pełny URL z kodem autoryzacyjnym. Raportowanie powinno odróżniać te etapy, bo każdy wymaga innej reakcji technicznej i edukacyjnej.

Praktyczna zasada dla pracowników może brzmieć prosto: nie przekazuj stronie, konsultantowi ani formularzowi adresów z przeglądarki, kodów autoryzacyjnych, kodów urządzenia, komunikatów logowania ani technicznych wartości z procesu Microsoft, jeśli samodzielnie nie uruchomiłeś znanej, firmowej procedury w oficjalnym kanale.

Wniosek

ConsentFix v3 pokazuje zmianę w phishingu tożsamościowym. Atakujący coraz częściej nie potrzebują hasła, jeśli potrafią skłonić użytkownika do przekazania tokenu, kodu, zgody albo sesji wynikającej z prawdziwego procesu autoryzacji.

Dla użytkownika najbezpieczniejsza zasada jest konkretna: gdy instrukcja po logowaniu prosi o kopiowanie URL-a, wklejenie kodu, przeciągnięcie adresu, naprawę dostępu albo potwierdzenie technicznego procesu poza znanym kanałem, przerwij działanie i zgłoś sprawę. Dla firmy to test dojrzałości procesu tożsamości, a nie tylko kolejna lekcja o podejrzanych linkach. Odporność trzeba mierzyć tam, gdzie realnie zapada decyzja: przy sesji, kodzie, tokenie, zgodzie aplikacji i reakcji po błędzie.