Krajobraz zagrożeń 19-25/02/2026

W najnowszym Krajobrazie Zagrożeń przyjrzeliśmy się trzem tematom obrazującym nowoczesne problemy atakujących i zabezpieczających. Pierwszym poruszonym przez nas wątkiem są ataki UNC2814 z wykorzystaniem API Arkuszy Google jako C2 — komunikacja niezwykle trudna do wykrycia w organizacji, jednak zauważona przez samo Google. Przyjrzeliśmy się także jak wersjonowanie kodu ułatwia pracę oszustom, ale może się okazać zdradliwe, o czym przekonała się grupa Diesel Vortex atakująca spedycję z wykorzystaniem metody Dual-Domain. Nie zabrakło też elementów związanych z AI w postaci PromptSpy, malware na system Android wykorzystującego Gemini do dynamicznej analizy danych w trakcie ataku. Uniknięcie wykrycia jest jednym z głównych celów atakujących, ale ich metody dynamicznie się zmieniają. Współcześnie skuteczna detekcja wymaga uważnego śledzenia każdej zmiany technik pojawiających się w atakach.

Zaawansowane zagrożenia

Arkusze, dokumenty i C2 — Google Sheets API w atakach.

25 lutego zespół Google Threat Intelligence Group (GTIG) opublikował raport dotyczący globalnej kampanii cyberszpiegowskiej z użyciem backdoora GRIDTIDE. Według analizy, ataki przeprowadzała grupa UNC2814 powiązana z Chinami, śledzona przez GTIG od 2017 roku. W przedstawionej analizie zawarto opis technik wykorzystywanych w kampanii oraz opis działań zabezpieczających przez Google. Ta perspektywa jest szczególnie wartościowa i zwraca uwagę na szerszy problem wykorzystywania przez atakujących legalnych usług, których właściciele muszą wykazać się odpowiedzialnością.

Atak został wykryty dzięki monitorowaniu zasobów klienckich przez Google, podczas którego zidentyfikowano podejrzaną aktywność na serwerze CentOS. Początkowo zaobserwowano plik binarny wywołujący powłokę jako root i późniejsze działania pozwalające atakującemu ocenić, czy rzeczywiście uzyskał dostateczne uprawnienia.

GRIDTIDE to zaawansowany backdoor napisany w języku C posiadający funkcje wykonywania komend oraz pobierania i wgrywania plików. Jako C2 wykorzystuje on Arkusze Google, które służą w tym scenariuszu do transferu danych oraz komend. Po uruchomieniu payloadu i ustanowieniu trwałego dostępu z wykorzystaniem usług atakujący wykorzystywał SoftEther VPN Bridge do komunikacji z zewnętrznym adresem IP. Malware wymaga obecności na hoście dodatkowego pliku z konfiguracją umożliwiającą dostęp do dokumentu w Google Drive wykorzystywanego jako kanał C2. Po wyczyszczeniu arkusza Google z zawartych tam danych z wykonania wcześniejszych komend, GRIDTIDE zbiera dane na temat hosta i umieszcza je w komórce V1 arkusza. Następnie, posługując się specjalnie skonstruowanymi komendami wydaje polecenia złośliwemu oprogramowaniu, które w odpowiedzi podaje informacje umieszczane w arkuszu. Status wykonania zadania pojawia się w komórce A1, a eksfiltrowane dane w zakresie od A2 do komórki określonej w komendzie. Przesyłane dane były zakodowane dzięki Base64.

Rys. Uproszczony schemat działania UNC2814 w opisywanych atakach. Źródło: GTIG.

Analiza GTIG nie wykazała eksfiltracji wrażliwych plików w trakcie tej kampanii, ale uzyskany dostęp mógł na to pozwolić. W innych kampaniach realizowanych przez powiązane z Chinami grupy obserwowano działania mające na celu kradzież danych dotyczących między innymi połączeń i wiadomości wyselekcjonowanych celów. Według raportu na dzień 18 lutego grupa UNC2814 zaatakował 53 ofiary w 42 krajach, w tym w Polsce, a podejrzenie infekcji zidentyfikowano w kolejnych 20 krajach. Globalna skala ataku pokazuje szeroki zasięg cyberszpiegowskich działań grup powiązanych z Chinami. Zespół GTIG podkreśla, iż klastry aktywności UNC2814 i Salt Typhoon są zupełnie odrębne od siebie. Charakteryzują się innymi celami oraz taktykami, technikami i procedurami (TTP).

GTIG poinformowało ofiary opisywanych ataków, ale opisano również szereg działań podjętych w celu zakłócenia aktywności UNC2814. Wszystkie projekty w Google Cloud, zidentyfikowana infrastruktura, konta i dostęp do API Arkuszy Google kontrolowane przez atakującego zostały wyłączone. Ponadto zespół GTIG podzielił się IoC (Indicators of Compromise) zarówno plikowymi, jak i sieciowymi, które zidentyfikowali w ramach śledzenia grupy. W raporcie znalazła się także reguła YARA pozwalająca wykryć GRIDTIDE.

W raporcie podkreślono, iż choć tym razem atakujący wykorzystali Arkusze Google, każde podobne rozwiązanie lub innego rodzaju API może zostać użyte w tym samym celu. Odpowiedzialne działania właścicieli nadużywanej infrastruktury są najważniejsze dla skutecznej analizy i unieszkodliwiania ataków. To szczególnie ważne w erze chmurowej, gdzie tego typu infrastruktura staje się fundamentem działania małych oraz dużych firm, ale także prywatnych projektów, o których bezpieczeństwie klient nie zawsze pamięta. Co więcej, skuteczny monitoring pozwala dostawcy infrastruktury obserwować ataki w szerszej perspektywie. Umożliwia to zaobserwowanie wzorców, masowych ataków, ale także zaawansowanych kampanii, które klient widzi tylko w zakresie swoich zasobów. Dodatkowy kontekst pozwala skuteczniej przeciwdziałać atakom i ograniczać ich skutki, o ile oczywiście dostawca rzetelnie podchodzi do zagrożeń i komunikacji w razie incydentów.

Więcej informacji:
https://cloud.google.com/blog/topics/threat-intelligence/disrupting-gridtide-global-espionage-campaign

Cybercrime

Diesel Vortex — double trouble.

Systemy kontroli wersji, takie jak Git, są powszechnie wykorzystywane do zarządzania kodem i współpracy zespołowej. Niewłaściwie zabezpieczone repozytorium może jednak ujawnić historię rozwoju projektu, strukturę narzędzia, dane konfiguracyjne, a choćby elementy infrastruktury operacyjnej. Zależność ta dotyczy nie tylko legalnych podmiotów – z tych samych narzędzi korzystają również grupy cyberprzestępcze.

W przypadku grupy Diesel Vortex, aktora systematycznie atakującego zachodnią logistykę, punktem wyjścia do analizy stało się publicznie dostępne repozytorium .git. Zawierało ono kompletną platformę phishingową, historię commitów oraz artefakty operacyjne z kampanii prowadzonej od września 2025 do lutego 2026 roku. Dostępny kod, charakteryzujący się wielowarstwową strukturą, zawiera ślady wcześniejszych iteracji oraz osierocone pliki i niespójne elementy konfiguracyjne. Wskazuje to na organiczny rozwój projektu w czasie i jego adaptację do kolejnych kampanii, przy czym analiza nie potwierdza jednoznacznie wieloletniej ciągłości grupy pod tą samą nazwą, a raczej ewolucję samego narzędzia. Charakter zmian w kodzie sugeruje, iż platforma, funkcjonująca wewnętrznie pod nazwami GlobalProfit oraz MC Profit Always, była przygotowywana do wykorzystania w modelu komercyjnym, zbliżonym do Phishing-as-a-Service.

Dane pozyskane z repozytorium, odzyskany wewnętrzny dokument planistyczny oraz logi z webhooków Telegrama pozwoliły także na odtworzenie operacyjnego podziału ról w ramach grupy. Zidentyfikowano wyraźną segmentację funkcji, obejmującą programistów odpowiedzialnych za rozwój kodu i rotację infrastruktury domenowej, wsparcie komunikacyjne oraz personel zajmujący się pozyskiwaniem kontaktów. Artefakty językowe w kodzie i dokumentacji wskazują na rosyjskojęzyczne zaplecze techniczne, jednak logi operacyjne odnotowujące komunikację w języku armeńskim sugerują wielojęzyczny charakter zespołu.

Architektura samej platformy została zaprojektowana z myślą o maksymalnym utrudnieniu detekcji poprzez zastosowanie modelu Dual-Domain. Polega on na rozdzieleniu funkcji domen: pierwsza z nich (Advertise) pełni funkcję prezentacyjną i buduje pozory legalności, natomiast adekwatne przechwytywanie danych odbywa się na ukrytej domenie operacyjnej (System), ładowanej poprzez pełnoekranową ramkę iframe. Mechanizm ten wykorzystuje podpisane tokeny HMAC generowane dynamicznie dla żądań iframe, co skutecznie utrudnia próby analizy przy użyciu standardowych crawlerów.

W celu maskowania aktywności przed filtrami antyspamowymi, grupa stosowała homoglify cyrylickie w nazwach domen, wykorzystując znaki wizualnie identyczne z łacińskimi. Infrastruktura była chroniona przez zaawansowany, dziewięcioetapowy mechanizm filtrowania ruchu, obejmujący fingerprinting środowiska oraz blokowanie adresów IP powiązanych z dostawcami chmury i firmami cyberbezpieczeństwa, takimi jak Palo Alto Networks, Google czy Microsoft. W przypadku wykrycia środowiska analitycznego serwer zwracał odpowiedzi HTTP sugerujące nieistniejący zasób lub błąd po stronie serwera, co powoduje, iż infrastruktura wydaje się nieaktywna, mimo iż pozostaje operacyjna dla rzeczywistych ofiar.

Model operacyjny nie zakładał pasywnego zbierania danych – zastosowany mechanizm pollingu wymuszał cykliczną komunikację przeglądarki ofiary z serwerem w oczekiwaniu na instrukcje. Dzięki integracji z Telegramem, operatorzy mogli w czasie rzeczywistym nadzorować każdą sesję, co pozwalało na manualne sterowanie procesem przechwytywania kodów MFA i dynamiczne reagowanie na zachowanie ofiary.

Rys. Architektura Dual-Domain, źródło: Have I Been Squatted

Dopiero w tym kontekście widoczny staje się docelowy model wykorzystania infrastruktury. Platforma została zaprojektowana z myślą o wyspecjalizowanym uderzeniu w sektor transportu, spedycji i logistyki (TSL), a konkretnie firmy transportowe oraz brokerów z Ameryki Północnej i Europy. Wykorzystując 22 szablony phishingowe imitujące platformy takie jak DAT, Truckstop, RMIS czy TIMOCOM, atakujący przejęli ponad 1600 unikalnych zestawów poświadczeń. Grupa pozyskiwała dane uwierzytelniające oraz szczegółowe informacje o aktualnych zleceniach transportowych, jednak kluczowym elementem ataku było zdobycie numerów MC (Motor Carrier Number), nadawanych przez Federal Motor Carrier Safety Administration, które stanowią cyfrowy odpowiednik licencji operacyjnej. Przejęcie tych danych umożliwiało sprawcom podszycie się pod legalne firmy i realizację oszustwa Double Brokeringu. Polega on na przejęciu zlecenia transportowego i podzleceniu go innemu podmiotowi przy jednoczesnej modyfikacji dokumentacji przewozowej tak, aby płatność od brokera trafiła do sprawców. Równolegle grupa prowadziła próby oszustw finansowych wymierzonych w użytkowników kart paliwowych EFS, co pozwalało na szybką monetyzację dostępów.

Mimo biegłości technicznej, grupa pozostawiła ślady forensicowe pozwalające na nakreślenie jej otoczenia operacyjnego. Domena rejestracyjna oraz metadane grafik przygotowywanych w programie Adobe Photoshop, zawierające rosyjskojęzyczne nazwy warstw oraz strefę czasową UTC+3 (m.in. Moskwa), korelują z rosyjskojęzycznym środowiskiem działania. Dodatkowo, analiza infrastruktury wskazała na wspólny adres kilku spółek logistycznych w Moskwie, co może sugerować osadzenie kampanii w środowisku posiadającym głęboką wiedzę branżową. Choć skala finansowa podmiotów operujących pod tym adresem, takich jak UNIX GROUP LLC z przychodem rzędu 154 mln USD w 2024 r., wskazuje na potężne zaplecze gospodarcze, nie stanowi to bezpośredniego dowodu ich udziału w przestępczym procederze.

Podsumowując, analiza wskazuje na wysoki poziom dojrzałości organizacyjnej i technicznej grupy, wyraźny podział ról oraz zdolność do komercjalizacji infrastruktury phishingowej. W realiach sektora TSL tożsamość cyfrowa przewoźnika oraz dostęp do informacji o zleceniach transportowych stanowią zasób o krytycznym znaczeniu operacyjnym. W odpowiedzi na tego typu zagrożenia najważniejsze znaczenie ma wdrożenie uwierzytelniania odpornego na phishing (np. FIDO2).

Więcej informacji:
https://haveibeensquatted.com/blog/diesel-vortex-inside-the-russian-cybercrime-group-targeting-us-eu-freight
https://ctrlaltintel.com/threat%20research/DieselVortex/

Future

Gemini, powiedz mi, jak przejąć Androida.

Najnowsze ustalenia zespołu ESET Research wskazują na istotną zmianę jakościową w krajobrazie zagrożeń mobilnych. Odkryty przez badaczy malware nazwany PromptSpy jest pierwszym znanym przypadkiem złośliwego systemu na system Android, które integruje generatywny model językowy bezpośrednio w swoim łańcuchu operacyjnym. Nie chodzi tu o wykorzystanie sztucznej inteligencji na etapie przygotowania kampanii, generowania phishingu czy kodu – ale o użycie dużego modelu językowego w trakcie działania malware na zainfekowanym urządzeniu. To przesunięcie z etapu „AI jako narzędzie twórcy ataku” do „AI jako element wykonawczy malware” stanowi jakościowy przełom w sposobie projektowania mobilnego złośliwego oprogramowania.

Rys. Fragment kodu malware z zakodowanym promptem do Gemini; źródło: ESET RESEARCH.

Dotychczas mobilny malware opierał się na statycznie zakodowanych regułach interakcji z interfejsem użytkownika: zdefiniowanych współrzędnych kliknięć, twardo zapisanych sekwencjach akcji czy prostych mechanizmach automatyzacji UI. PromptSpy zrywa z tym podejściem. W swoim module wykorzystuje zewnętrzny model językowy – w tym przypadku usługę Google Gemini – do analizy aktualnego stanu interfejsu użytkownika w czasie rzeczywistym. Malware generuje zrzut struktury UI w postaci XML, przesyła go do modelu AI wraz z instrukcją w języku naturalnym i otrzymuje odpowiedź zawierającą rekomendowane działania: które elementy należy kliknąć, jakie gesty wykonać i w jakiej kolejności. Otrzymane instrukcje są następnie wykonywane na urządzeniu. W praktyce oznacza to dynamiczną, kontekstową adaptację do konkretnej wersji systemu, nakładki producenta czy konfiguracji urządzenia, bez konieczności implementowania w kodzie setek wariantów logiki.

Rys. Komunikacja sieciowa złośliwego systemu i Gemini; źródło: ESET RESEARCH.

Kluczowym zastosowaniem tego mechanizmu w PromptSpy jest utrzymywanie trwałości (persistence) poprzez manipulowanie interfejsem w taki sposób, aby utrudnić użytkownikowi zamknięcie lub usunięcie aplikacji. W połączeniu z modułem zdalnego dostępu opartym na technologii VNC daje to operatorom możliwość pełnej kontroli nad urządzeniem ofiary: podglądu ekranu, wykonywania działań w jej imieniu, przechwytywania danych oraz blokowania prób deinstalacji. Generatywna AI nie odpowiada więc za cały łańcuch ataku, ale pełni rolę krytycznego elementu decyzyjnego, który zwiększa odporność malware na różnice środowiskowe i utrudnia analizę statyczną.

W szerszym kontekście krajobrazu zagrożeń oznacza to zmiana, w którym logika działania malware staje się częściowo „zewnętrzna” i dynamiczna. W tym podejściu analitycy tracą też możliwość statycznej a choćby dynamicznej analizy, gdyż tradycyjne podejście do analizy kodu – polegające na identyfikacji twardo zakodowanych funkcji, ciągów znaków czy schematów wywołań API – traci na skuteczności, gdy najważniejsze decyzje są podejmowane przez model językowy działający poza aplikacją. W efekcie pojawia się nowa warstwa nieprzewidywalności: to samo malware może zachowywać się odmiennie w zależności od kontekstu, odpowiedzi modelu czy choćby zmian w samym modelu AI. Dynamika ta wpisuje się w szerszy trend „uzbrajania” systemów generatywnych w funkcje operacyjne, co znacząco skraca cykl adaptacji atakujących do nowych zabezpieczeń.

Wykrywanie tego typu zagrożeń wymaga odejścia od czysto sygnaturowych metod detekcji na rzecz podejścia behawioralnego i kontekstowego. najważniejsze znaczenie ma monitorowanie nietypowych wzorców komunikacji sieciowej – w szczególności powtarzalnych zapytań do usług LLM zawierających dane strukturalne interfejsu użytkownika – oraz anomalii w korzystaniu z uprawnień takich jak Accessibility Services, overlay czy zdalny dostęp do ekranu. Istotne jest także wykrywanie pętli interakcji UI realizowanych w sposób nieprzypominający działań człowieka, o wysokiej częstotliwości i deterministycznej sekwencyjności, charakterystycznej dla automatyzacji sterowanej algorytmicznie. W środowiskach korporacyjnych konieczne staje się rozszerzenie polityk bezpieczeństwa o kontrolę wykorzystania aplikacji komunikujących się z modelami AI oraz korelację zdarzeń sieciowych.

PromptSpy pokazuje, iż LLM przestają być wyłącznie narzędziem wspomagającym atakujących na etapie przygotowawczym, a stają się elementem wykonawczym w czasie rzeczywistym. W perspektywie oznacza to dalsze przyspieszenie ewolucji zagrożeń, większą adaptacyjność malware oraz konieczność redefinicji podejścia do analizy TTP. Krajobraz zagrożeń w erze LLM będzie coraz mniej oparty na statycznych artefaktach, a coraz bardziej na dynamicznych interakcjach między złośliwym kodem a zewnętrznymi systemami inteligentnymi. Dla zespołów bezpieczeństwa oznacza to potrzebę integracji monitoringu zachowań aplikacji, analizy ruchu do usług AI oraz głębszego zrozumienia sposobu, w jaki modele językowe mogą zostać włączone w operacyjne łańcuchy ataku.

Więcej informacji:
https://www.welivesecurity.com/en/eset-research/promptspy-ushers-in-era-android-threats-using-genai/