Według Google Threat Intelligence Group (GTIG) / Mandiant napastnicy dzwonią na prywatne numery pracowników, podają się za helpdesk i kierują do fałszywego logowania, aby przejąć dane oraz tokeny MFA. Analiza z 6 sierpnia 2026 r. wskazuje na dalszą aktywność UNC6671 mimo ogłoszonego końca marki BlackFile. Dla polskich firm używających Microsoft 365 i Okta wynika stąd wymóg: przed zmianą uwierzytelniania potwierdzić tożsamość helpdesku w znanym kanale.

Czy zgodzilibyśmy się na zmianę dostępu do firmowego konta tylko dlatego, że ktoś zadzwonił z poleceniem pilnej migracji zabezpieczeń? W opisie GTIG właśnie taki pretekst towarzyszy kontaktowi z pracownikiem na jego prywatnym numerze. Rozmówca przedstawia się jako pomoc techniczna, a dalszym krokiem ma być logowanie na wskazanej stronie. Dla czytelnika zarządzającego Microsoft 365 lub Okta proponujemy prostą próbę własnej procedury: ustalić, co pracownik ma zrobić między odebraniem takiego telefonu a wykonaniem polecenia. Czy instrukcja wskazuje znany wcześniej kontakt do helpdesku i wymaga niezależnego potwierdzenia prośby? Odpowiedź powinna wynikać z procedury dostępnej pracownikowi, także gdy rozmowa odbywa się poza służbową pocztą.

UNC6671 wykorzystuje obietnicę poprawy zabezpieczeń

Według analizy GTIG/Mandiant vishing, czyli phishing przez rozmowę głosową, łączy podszywanie się pod helpdesk z fałszywym logowaniem. Pilna migracja zabezpieczeń jest pretekstem do wykonania polecenia napastnika. Celem opisanym przez badaczy są dane logowania i tokeny uwierzytelniania wieloskładnikowego, czyli MFA.

Wniosek dla procedury zmian MFA dotyczy momentu poprzedzającego logowanie: pracownik najpierw potwierdza, kto zleca zmianę. Samo powołanie się na poprawę zabezpieczeń nie powinno być podstawą wykonania instrukcji. Proponujemy zapisać wprost, że pracownik przerywa taką rozmowę i sam kontaktuje się z helpdeskiem przez znany wcześniej kanał. Potwierdzenie powinno obejmować tożsamość zespołu i konkretną prośbę o zmianę.

Pytanie kontrolne dla właściciela Microsoft 365 lub Okta brzmi więc: czy pracownik potrafi znaleźć właściwy kontakt bez korzystania ze wskazówek osoby, która właśnie zadzwoniła? Sprawdźmy to na dostępnej instrukcji. Gdy kontaktu brakuje, uzupełnijmy go przed następną planowaną zmianą uwierzytelniania.

Zmiana MFA powinna zaczynać się od niezależnego potwierdzenia helpdesku, również po telefonie na prywatny numer.

Procedurę MFA sprawdźmy poza służbową pocztą

Przytoczone ustalenia GTIG opisują sposób działania napastników; nie dają podstaw do odtworzenia procedur konkretnych ofiar. Nie przypisujmy więc pracownikom złamania instrukcji, której treści nie znamy. Zderzenie procedury z praktyką przeprowadźmy we własnej organizacji, z prywatnym telefonem jako warunkiem ćwiczenia.

Poprośmy pracownika i przedstawiciela helpdesku o osobne wskazanie drogi potwierdzenia prośby dotyczącej MFA. Następnie porównajmy odpowiedzi z instrukcją. Sprawdźmy zwłaszcza, czy obie strony wskazują ten sam kanał oraz czy helpdesk wie, kto może potwierdzić zasadność zmiany. Rozbieżności zapiszmy jako zadania dla właściciela procedury.

Do ćwiczenia Microsoft 365 lub Okta dodajmy wariant, w którym pracownik wykonał już polecenie i dopiero później nabrał wątpliwości. Proponujemy wymagać wtedy wskazania odbiorcy zgłoszenia, osoby sprawdzającej zmiany uwierzytelniania oraz administratora odpowiedzialnego za ocenę sesji. To zalecany zakres reakcji na opisany mechanizm, a nie relacja z przebiegu konkretnego incydentu. Próbę zakończmy ustaleniem, jakie informacje mają trafić od helpdesku do administratora i kto potwierdzi przyjęcie sprawy.

Koniec marki BlackFile nie zamyka zadania dla zarządu

GTIG opisuje dalsze działania UNC6671 mimo ogłoszonego końca marki BlackFile oraz wiąże infrastrukturę z kilkoma markami wymuszeń. Powiązania te są oceną badaczy. Nie traktujmy ich jako rozstrzygnięcia struktury organizacyjnej napastników ani jako podstawy twierdzenia, że rośnie liczba wszystkich ataków vishingowych.

Dla zarządu proponujemy z tego wyprowadzić kryterium przeglądu: utrzymać kontrolę procesu zmian dostępu niezależnie od komunikatów o zakończeniu działalności danej marki. Przy Microsoft 365 i Okta poprośmy o wskazanie właścicieli weryfikacji połączeń, zmian MFA oraz obsługi sesji. Każdej odpowiedzialności przypiszmy oczekiwany wynik sprawdzenia, żeby samo przekazanie zgłoszenia nie kończyło zadania.

Rozmowę o nakładach zacznijmy od zakresu pracy potrzebnej we własnej firmie. Zlećmy oszacowanie czasu na uzupełnienie instrukcji kontaktu z helpdeskiem i wyjaśnienie braków w obsłudze sesji. Nie wyliczajmy kosztu firmowego incydentu na podstawie samego opisu UNC6671. Decyzję o zasobach oprzyjmy na ustalonych brakach i odpowiedzialności za ich usunięcie.

Ogłoszony koniec BlackFile nie daje podstaw do wycofania kontroli procesu, który nadal opisuje GTIG.

Polska firma powinna objąć przeglądem także aplikacje poza SSO

Źródło nie potwierdza ofiar w Polsce. Polski kontekst tego materiału dotyczy firm używających Microsoft 365 i Okta, którym proponujemy sprawdzenie własnego procesu zmian uwierzytelniania. Nie przypisujemy im incydentów opisanych przez GTIG ani nie oceniamy skali krajowych strat.

Zakres przeglądu powinien obejmować również resety dostępu do aplikacji poza wspólnym logowaniem, czyli SSO. Potraktujmy to jako osobne zadanie: wybierzmy używaną aplikację i ustalmy, kto zatwierdza reset oraz jak potwierdza uprawnienie do jego wykonania. Jeżeli nie wiadomo, kto odpowiada za tę ścieżkę, zapiszmy brak właściciela do rozstrzygnięcia.

Przy ocenie gotowości Microsoft 365 i Okta wymagajmy także wskazania sposobu sprawdzania sesji po podejrzanym kontakcie. Administrator powinien określić zakres możliwej weryfikacji oraz czynności potrzebne do zakończenia nieuprawnionego dostępu. Nie zakładajmy wyniku takiego sprawdzenia z góry. Rekomendujemy, by decyzja o zamknięciu zgłoszenia uwzględniała osobno potwierdzenie rozmówcy, zmiany MFA, sesje i resety poza SSO.

Co z tym zrobić w poniedziałek

Każde z poniższych działań ogranicz do 30 minut; celem jest konkretny wynik przeglądu, a przy brakach wskazanie odpowiedzialnego za dalszą pracę.

  1. Sprawdź drogę potwierdzenia helpdesku. Otwórz instrukcję dla użytkownika Microsoft 365 lub Okta i znajdź znany kanał kontaktu. Z pracownikiem przejdź prośbę o zmianę MFA otrzymaną na prywatny numer. Zapisz brakujące kroki niezależnego potwierdzenia.
  2. Przejrzyj obsługę zmian MFA i sesji. Z administratorem wybierz jedną procedurę zgłoszenia podejrzanego logowania. Sprawdź, czy określa odpowiedzialnych za weryfikację zmian uwierzytelniania i ocenę sesji. Wynikiem niech będzie lista braków do uzupełnienia.
  3. Sprawdź reset jednej aplikacji poza SSO. Wskaż jej właściciela i przejrzyj instrukcję resetowania dostępu. Zanotuj, kto potwierdza uprawnienie do resetu i komu przekazuje podejrzenie nadużycia. Niewiadome przypisz do wyjaśnienia konkretnej osobie.

W firmowej procedurze MFA prawo do zlecenia zmiany powinno wymagać potwierdzenia w znanym kanale. Prywatny telefon ma podlegać tej samej zasadzie weryfikacji co pozostałe drogi kontaktu z helpdeskiem. Dla Microsoft 365 i Okta przyjmijmy także warunek, że reakcja na podejrzane logowanie obejmuje ustalenia o zmianach dostępu i sesjach.

Źródła

  1. Google Threat Intelligence Group / Mandiant: UNC6671 Rebrands: Multi-Brand Vishing Extortion Targets Financial Services and Enterprise Cloud Environments. Publikacja: 6 sierpnia 2026 r.

Redakcja cyberinsight.pl.