Wprowadzenie do problemu / definicja luki
W lutym 2026 Google Threat Intelligence Group (GTIG) wraz z Mandiant i partnerami przeprowadził skoordynowane działania disrupt (takedown/sinkhole) przeciw kampanii szpiegowskiej przypisywanej aktorowi UNC2814, powiązanemu z Chinami (PRC-nexus). najważniejszy element tej operacji to nadużycie legalnych funkcji chmury – w szczególności Google Sheets API – jako kanału C2 (command-and-control), bez wykorzystywania podatności w samych produktach Google.
To istotny trend: zamiast „łamać” usługę, napastnik korzysta z niej zgodnie ze specyfikacją, maskując ruch wśród prawidłowych wywołań API. Dla SOC oznacza to, iż klasyczne detekcje oparte o domeny C2 i nietypowe protokoły mogą nie zadziałać.
W skrócie
- Aktor: UNC2814 (śledzony przez GTIG od 2017 r.), kampania o charakterze szpiegowskim.
- Skala: potwierdzony wpływ na 53 ofiary w 42 krajach, z podejrzeniem kolejnych infekcji/aktywności w następnych państwach.
- Cele: głównie telekomy oraz organizacje rządowe (w wielu regionach świata).
- Narzędzie: nowy backdoor GRIDTIDE z C2 przez Google Sheets (API), ukrywający się w legalnym ruchu chmurowym.
- Disrupt: wyłączone projekty Google Cloud kontrolowane przez atakujących, infrastruktura i konta wykorzystywane do Sheets API/C2 oraz publikacja IOC.
- Istotna uwaga: Google podkreśla brak kompromitacji produktów – to abuse of functionality, nie „bug”.
Kontekst / historia / powiązania
Telekomy od lat są „złotą żyłą” dla wywiadu: dostęp do metadanych połączeń, SMS-ów, danych abonentów i potencjalnie mechanizmów lawful intercept pozwala budować obraz relacji i aktywności osób (dysydenci, aktywiści, dyplomaci, biznes, administracja). Google wskazuje, iż w badanej aktywności znaleziono system zawierający PII (m.in. imię i nazwisko, numer telefonu, data i miejsce urodzenia, numery identyfikacyjne).
Warto też odnotować: GTIG zaznacza, iż obserwowana aktywność UNC2814 nie pokrywa się z nagłaśnianym klastrem „Salt Typhoon” – inne ofiary i inne TTP.
Analiza techniczna / szczegóły luki
1. Pierwszy sygnał: podejrzany proces i eskalacja do roota
W opisie śledztwa Mandiant pojawia się detekcja na serwerze CentOS, gdzie binarka /var/tmp/xapt uruchamia shella z uprawnieniami roota, a następnie wykonuje sh -c id 2>&1 w celu potwierdzenia eskalacji (uid=0). Nazwa „xapt” ma wyglądać wiarygodnie (podszycie pod „apt”).
2. Utrzymanie dostępu i ruch lateralny
Po kompromitacji aktor poruszał się po środowisku m.in. przez SSH oraz wykorzystywał LotL. Persistencja obejmowała usługę systemd:
- /etc/systemd/system/xapt.service
- uruchamianie instancji z /usr/sbin/xapt
oraz start przez nohup ./xapt (odporność na zamknięcie sesji).
W kampanii zauważono też wdrożenie SoftEther VPN Bridge do zestawienia szyfrowanego tunelu wychodzącego (metadane konfiguracji sugerują użycie tej infrastruktury przez lata).
3. GRIDTIDE jako backdoor: C2 w Google Sheets
GRIDTIDE to backdoor w C umożliwiający wykonywanie poleceń oraz upload/download plików. Najciekawsze jest to, jak traktuje arkusz nie jak dokument, ale kanał komunikacyjny:
Konfiguracja i kryptografia
- malware oczekuje 16-bajtowego klucza w osobnym pliku na hoście,
- używa go do odszyfrowania konfiguracji (AES-128 CBC),
- w konfiguracji są m.in. dane konta serwisowego i identyfikator arkusza,
- autoryzacja odbywa się przez Service Account do Google Sheets API.
„Czyszczenie śladów” w arkuszu
- przy starcie GRIDTIDE usuwa dane z pierwszych 1000 wierszy (A–Z) metodą batchClear, by nie mieszać sesji i usuwać historię poleceń/danych.
Fingerprinting hosta
- zbiera m.in. użytkownika, nazwę hosta, wersję OS, lokalne IP, katalog roboczy, ustawienia językowe i strefę czasową,
- odkłada fingerprint w komórce V1.
Składnia komend i role komórek
- komendy mają format: <type>-<command_id>-<arg_1>-<arg_2>,
- istotne typy operacji:
- C (Command) – wykonanie Base64-zakodowanych komend bash i zapis wyniku do arkusza,
- U (Upload) – rekonstrukcja danych z zakresu komórek i zapis na hoście,
- D (Download) – pocięcie pliku i wysyłka fragmentów do arkusza,
- mechanika C2:
- A1: polling po komendy i zwrot statusu,
- A2..An: transfer danych (wyniki/fragmenty plików),
- V1: metadane hosta.
Ewazja i „udawanie normalności”
- dane są kodowane wariantem URL-safe Base64 (zamiana + i / na - i _),
- polling ma adaptacyjne opóźnienia (po serii prób przejście na losowe 5–10 minut), co zmniejsza „szum”.
To dokładnie ten przypadek, w którym ruch wygląda jak „zwykłe API do SaaS”, a nie klasyczny C2.
Praktyczne konsekwencje / ryzyko
- Ryzyko masowej inwigilacji: dostęp do PII i zasobów telekomu może służyć identyfikacji i śledzeniu „persons of interest”.
- Ryzyko nadużyć lawful intercept / metadanych: Google przypomina, iż podobne intruzje w telekomach w przeszłości kończyły się kradzieżą CDR, podglądem SMS i nadużyciami systemów przechwytu.
- Trudniejsze wykrywanie: o ile C2 idzie przez legalne platformy (Sheets/API), to bez dobrej telemetrii (API logs, egress, identity) łatwo przeoczyć aktywność, bo „nie ma podejrzanej domeny”.
Rekomendacje operacyjne / co zrobić teraz
Poniżej zestaw praktyk, które realnie podnoszą szanse wykrycia „SaaS-as-C2” w stylu GRIDTIDE (zwłaszcza w środowiskach serwerowych i hybrydowych):
1. Kontrola tożsamości i kluczy
- Przegląd Service Accounts: rotacja kluczy, ograniczenia IAM (zasada najmniejszych uprawnień), wyłączanie nieużywanych kont.
- Alerty na tworzenie/eksport kluczy do Service Account oraz nietypowe użycie po godzinach.
2. Telemetria i detekcje na API
- W logach proxy/egress/SIEM buduj detekcje na:
- nietypowe wywołania Google Sheets API z serwerów, które nie powinny „automatyzować arkuszy”,
- wzrost częstotliwości requestów i powtarzalny polling (A1),
- anomalie w user-agent / bibliotece / tokenach (jeśli dostępne).
- Jeśli masz DLP/UEBA: polityki na masowe odczyty/zapisy do arkuszy z kont serwisowych.
3. Hunting na hostach (Linux)
Szukaj artefaktów i wzorców z opisu Mandiant/GTIG:
- pliki: /var/tmp/xapt, /usr/sbin/xapt, jednostka /etc/systemd/system/xapt.service, użycie nohup do startu,
- podejrzane procesy uruchamiające id celem potwierdzenia roota,
- nietypowe wdrożenia SoftEther VPN Bridge na serwerach, gdzie nie ma uzasadnienia biznesowego.
4. Egress i segmentacja
- Ograniczaj serwerom dostęp wychodzący (allowlist) – choćby jeżeli to „legalny” SaaS.
- Segmentacja i twarde reguły dla stref administracyjnych (jump hosts), by utrudnić lateral movement przez SSH.
5. Wykorzystaj IOC i wsparcie producentów
GTIG opublikował zestaw IOC powiązanych z infrastrukturą UNC2814 aktywną co najmniej od 2023 r. – warto je włączyć w pipeline (SIEM/EDR/NDR), choćby jeżeli spodziewasz się „małej ilości hitów”.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- GRIDTIDE (Sheets-as-C2): bardzo „czyste” maskowanie w API, gdzie arkusz jest buforem poleceń/danych.
- Klasyczne C2: łatwiej blokować domeny/IP, łatwiej profilować protokoły.
- Wspólny mianownik: obrona musi przesuwać się z „blokowania infrastruktury” na behawior + identity + telemetrykę SaaS (kto, skąd i po co używa API).
Podsumowanie / najważniejsze wnioski
Kampania UNC2814 z backdoorem GRIDTIDE to podręcznikowy przykład, jak legalne platformy SaaS mogą stać się niewidocznym C2. Skala (53 ofiary / 42 kraje) i profil celów (telekomy, rządy) potwierdzają, iż chodzi o długofalowy wywiad, a nie szybki zysk.
Najważniejsza lekcja dla obrony: jeżeli nie instrumentujesz API + tożsamości + egress, możesz przegapić atak, który „wygląda jak normalna praca z chmurą”.
Źródła / bibliografia
- Google Cloud Blog (GTIG & Mandiant) – “Exposing the Undercurrent: Disrupting the GRIDTIDE Global Cyber Espionage Campaign”, 25.02.2026. (Google Cloud)
- Reuters – relacja o skali i charakterze kampanii oraz disrupt, 25.02.2026. (Reuters)
- SecurityWeek – omówienie kampanii i kontekstu, 25–26.02.2026. (SecurityWeek)
- Cybersecurity Dive – podsumowanie i akcent na nadużycie legalnych funkcji cloud/SaaS, 25.02.2026. (cybersecuritydive.com)
