W analizie z 20 sierpnia 2026 r. Google Threat Intelligence Group (GTIG) opisuje trzy odrębne klastry podejrzewanego rosyjskiego cyberszpiegostwa wykorzystujące legalne przepływy uwierzytelniania wobec środowisk m.in. europejskiej obronności, administracji i nauki. Dla polskich organizacji współpracujących z obronnością i badaniami jest to powód do przeglądu zgód aplikacji oraz obsługi zaproszeń. Ocena logowania powinna objąć także odbiorcę tokenu i cel udzielanej zgody.

Jak podaje GTIG, kampania UNC7005 z 6–13 sierpnia polegała na podszywaniu się pod Finnish Operations Center wobec celów związanych z europejskim sektorem obronnym. Od tego zdarzenia zacznijmy rozmowę z osobami obsługującymi współpracę zewnętrzną. Czy nasza instrukcja pozwala zakończyć sprawdzanie logowania na rozpoznaniu prawdziwej domeny? Czy wymaga również ustalenia, jaka aplikacja otrzyma token i po co potrzebuje naszej zgody? Potraktujmy te pytania jako propozycję przeglądu własnej organizacji. Nie odtwarzamy zachowania zaatakowanych osób. Opis podszycia daje konkretny punkt odniesienia do oceny zaproszenia, a wykorzystanie legalnego uwierzytelniania uzasadnia sprawdzenie całej decyzji o dostępie.

OAuth wymaga oceny aplikacji i celu zgody

Z opisanych przez GTIG nadużyć wyciągamy wniosek: rozpoznanie prawdziwej strony logowania nie wystarcza do uznania całej operacji za bezpieczną. W ocenie OAuth uwzględnijmy także aplikację otrzymującą token oraz powód, dla którego mamy udzielić jej zgody. Sprawdzenie domeny pozostawmy jednym z elementów tej oceny.

Przy przeglądzie zgody zapiszmy nazwę aplikacji oraz zadanie, do którego ma być używana. Poprośmy osobę prowadzącą współpracę o wyjaśnienie, dlaczego właśnie ta aplikacja jest potrzebna. Odpowiedź powinna odnosić się do konkretnej pracy. Samo powtórzenie treści zaproszenia potraktujmy jako informację wymagającą niezależnego potwierdzenia.

Do oceny OAuth włączmy przekierowania: ustalmy, gdzie zaczyna się zaproszenie, dokąd prowadzi logowanie i z jaką aplikacją wiąże się zgoda. Proponujemy zapisywać te elementy osobno, aby informacja o prawdziwej stronie nie zamykała sprawdzania pozostałych. Jeśli odbiorcy tokenu lub celu zgody nie potrafimy ustalić, oznaczmy tę część jako niewyjaśnioną i skierujmy ją do administratora.

Prawdziwa strona logowania nie powinna zastępować uzasadnienia, dlaczego konkretna aplikacja ma otrzymać token.

UNC7005 daje punkt odniesienia do próby procedury

Przytoczone ustalenia o UNC7005 nie pozwalają odtworzyć procedur zaatakowanych organizacji ani ocenić decyzji ich pracowników. Zderzenie instrukcji z praktyką sprawdźmy więc u siebie: poprośmy osobę obsługującą zaproszenia o wskazanie kolejnych czynności wymaganych przed udzieleniem zgody aplikacji. Porównajmy odpowiedź z zapisami obowiązującej instrukcji.

W próbie procedury OAuth zapytajmy, komu pracownik zgłosi zaproszenie, którego związku z rzeczywistą współpracą nie umie potwierdzić. Sprawdźmy też, co zrobi po rozpoznaniu prawdziwej strony logowania, jeśli nadal nie zna celu zgody. Oczekujmy konkretnego kontaktu do osoby rozstrzygającej wątpliwości oraz wskazania momentu, w którym pracownik wstrzymuje dalsze kroki.

Wątek podszycia pod Finnish Operations Center wykorzystajmy do sprawdzenia, jak potwierdzamy nadawcę. Proponujemy kontakt znanym wcześniej kanałem, niezależnym od danych dostarczonych w zaproszeniu. W notatce z próby zapiszmy rozbieżności między instrukcją a odpowiedzią pracownika. Jeśli dokument wymaga sprawdzenia aplikacji, lecz nie wskazuje osoby mogącej pomóc w tej ocenie, uzupełnijmy właśnie ten brak.

Zarząd powinien wymagać uzasadnienia zgód OAuth

Dla zarządu przełóżmy temat OAuth na podział odpowiedzialności. Osobę prowadzącą współpracę poprośmy o potwierdzenie biznesowego celu aplikacji. Administratorowi powierzmy ocenę zgody i przekierowań. Wskażmy też osobę, która rozstrzygnie sprawę, gdy te oceny pozostawią niewiadome. Taki podział proponujemy jako ramy przeglądu.

Wynik przeglądu zgód OAuth powinien obejmować nazwy ocenionych aplikacji, ich uzasadnione zastosowania oraz sprawy wymagające wyjaśnienia. Przy każdej niewiadomej przypiszmy odpowiedzialnego za dalsze ustalenia. Nie zamykajmy zadania samym potwierdzeniem, że pracownik korzystał z prawdziwej strony logowania. W decyzji o pozostawieniu zgody wymagajmy wskazania, do czego aplikacja jest nadal potrzebna.

Ocenę GTIG dotyczącą rosyjskiego cyberszpiegostwa zachowajmy jako przypisanie autorów analizy. Trzech odrębnych klastrów nie przedstawiajmy jako jednej kampanii. Raportu nie traktujmy też jako pomiaru gwałtownego wzrostu zagrożenia. Do ustalenia zakresu własnego przeglądu wykorzystajmy opisane nadużycie uwierzytelniania, bez dopisywania kosztów incydentów ani tego, czy ataki się powiodły, bo przytoczone fakty tego nie określają.

Przegląd zgód OAuth powinien kończyć się uzasadnieniem dostępu i wskazaniem osoby odpowiedzialnej za niewyjaśnione przypadki.

Polski przegląd zacznijmy od współpracy z obronnością i badaniami

Przytoczone ustalenia nie potwierdzają polskich ofiar. Dla organizacji w Polsce punktem odniesienia jest kierunek opisanych działań: środowiska europejskiej obronności, administracji i nauki. Związek z tymi środowiskami potraktujmy jako kryterium wyboru obszaru do przeglądu, bez uznawania go za dowód ataku na własną organizację.

W polskiej firmie lub jednostce badawczej wybierzmy do pierwszego sprawdzenia istniejącą współpracę z europejską obronnością albo badaniami. Ustalmy z osobą odpowiedzialną za tę relację, jakie zaproszenia są oczekiwane i jakie aplikacje mają uzasadnione zastosowanie. Oprzyjmy listę na potwierdzonych potrzebach własnej organizacji. Przy nowym zaproszeniu wymagajmy wyjaśnienia związku proponowanej aplikacji z tą współpracą.

Analizę GTIG z 20 sierpnia wykorzystajmy również w rozmowie między administratorem a osobą prowadzącą kontakty zewnętrzne. Poprośmy ich o wspólne określenie, jak niezależnie potwierdzą zaproszenie i kto pomoże ocenić zgodę OAuth. Zakończmy rozmowę ustaleniem ścieżki przekazania wątpliwej sprawy, tak aby pracownik wiedział, do kogo zwrócić się przed kontynuowaniem logowania.

Co z tym zrobić w poniedziałek

Na każde działanie przeznacz do 30 minut; ogranicz zakres do wskazanego przykładu i zapisz wynik.

  1. Przejrzyj zgodę wybranej aplikacji OAuth. Wspólnie z administratorem ustal jej nazwę i osobę, która potwierdzi aktualny cel używania. Zapisz uzasadnienie pozostawienia zgody albo konkretną niewiadomą oraz osobę odpowiedzialną za jej wyjaśnienie.
  2. Oceń opis przekierowań dla wybranej aplikacji OAuth. Na podstawie dostępnej dokumentacji lub materiałów administratora wskaż stronę logowania i aplikację otrzymującą token. Nie odtwarzaj podejrzanego zaproszenia przez logowanie. Jeśli brakuje informacji o przebiegu, zapisz, co administrator ma ustalić przed oceną zgody.
  3. Sprawdź zasadę weryfikowania zaproszeń do współpracy z obronnością lub badaniami. Wybierz istniejącą relację i ustal znany wcześniej kanał kontaktu, którym można niezależnie potwierdzić zaproszenie. Dopisz do instrukcji, kto wykonuje sprawdzenie i komu przekazuje niewyjaśniony przypadek.

W ocenie ryzyka zgody OAuth wymagajmy rozpoznania aplikacji i uzasadnienia jej dostępu. Prawdziwa strona logowania powinna być częścią tej oceny. Gdy nie umiemy wyjaśnić, komu i po co przekazujemy token, wstrzymajmy udzielenie zgody do czasu uzyskania odpowiedzi.

Źródła

  1. Google Threat Intelligence Group: Going with the Flow(s): Distinct Clusters Target Individuals of Interest to Russia. Publikacja: 20 sierpnia 2026 r.

Redakcja cyberinsight.pl.