Archiwa: Malware - Strona 84 z 126 - Security Bez Tabu

Tag: Malware

Malicious Go Crypto Module kradnie hasła i instaluje backdoora Rekoobe — groźny łańcuch supply chain w ekosystemie Go

Wprowadzenie do problemu / definicja luki

Opisywana kampania to klasyczny atak na łańcuch dostaw (software supply chain attack) w wydaniu “look-alike dependency” — złośliwy moduł Go podszywa się pod jedną z najbardziej zaufanych bibliotek w ekosystemie: golang.org/x/crypto. Celem nie jest jedynie psucie buildów, ale kradzież sekretów w momencie ich wpisywania i szybkie przejście do trwałej kompromitacji Linuxa przez SSH oraz instalację backdoora Rekoobe.

Kluczowy element “sprytu” ataku: wykorzystanie tego, jak Go pobiera moduły (proxy/mirror) i jak łatwo w review zmian w go.mod przeoczyć, że “crypto” pochodzi z innego korzenia modułu niż oczekiwany.

W skrócie

  • Złośliwy moduł: github[.]com/xinfeisoft/crypto (podszycie pod golang.org/x/crypto).
  • Backdoor wstawiono do ssh/terminal/terminal.go i przechwytywano sekrety z ReadPassword() (hasła, passphrase, tokeny wpisywane w CLI).
  • Sekrety są zapisywane lokalnie (artefakt na dysku), następnie moduł pobiera wskaźnik konfiguracyjny z GitHub Raw i wykonuje treść jako polecenia shella.
  • Kolejny etap dodaje klucz SSH do authorized_keys, luzuje reguły iptables, pobiera payloady maskowane rozszerzeniem .mp5, w tym backdoora Rekoobe.
  • Go security team zablokował moduł na publicznym Go module proxy (zwracany błąd 403 SECURITY ERROR), ale repozytoria i ślady kompromitacji nadal mogą istnieć w środowiskach ofiar.

Kontekst / historia / powiązania

Namespace confusion i “zaufane” korzenie modułów

W Go to ścieżka modułu jest tożsamością zależności. W praktyce oznacza to, że github.com/xinfeisoft/crypto może wyglądać “normalnie” w grafie zależności, jeśli reviewer patrzy tylko na nazwę “crypto”, a nie na pełny import path i pochodzenie. Dodatkowo legalny golang.org/x/crypto ma publiczne mirrory (np. GitHub), co bywa nadużywane do tworzenia pozorów “rutynowego” importu.

Rekoobe: stary backdoor, wciąż użyteczny

Rekoobe to rodzina trojanów/backdoorów dla Linuxa obserwowana co najmniej od 2015 r., zdolna m.in. do wykonywania poleceń, przesyłania plików i pobierania kolejnych komponentów.
To, że łańcuch dostaw kończy się “znanym” backdoorem, jest typowe: atakujący inwestują w skuteczny “pierwszy krok” (zależność), a potem wdrażają sprawdzony implant.

Analiza techniczna / szczegóły luki

1) Backdoor w ReadPassword() — kradzież sekretów “na krawędzi”

Atakujący zmodyfikowali implementację ReadPassword() w ssh/terminal/terminal.go. To strategiczne miejsce, bo funkcja jest wywoływana dokładnie wtedy, gdy użytkownik wpisuje poufne dane w terminalu.

Z ustaleń Socket wynika, że moduł:

  • przechwytuje wpisany sekret,
  • zapisuje go do nietypowej ścieżki: /usr/share/nano/.lock,
  • pobiera “konfigurację” z GitHub Raw (update.html),
  • wysyła sekret HTTP POST pod adres zwrócony z tej konfiguracji,
  • pobiera kolejną treść i wykonuje ją przez /bin/sh.

2) GitHub Raw jako kanał sterowania (indirection)

Zamiast hardkodować endpoint C2, kampania używa pliku w repozytorium (GitHub Raw) jako “przełącznika” umożliwiającego rotację infrastruktury bez publikowania nowej wersji modułu.

3) Linux stager: SSH persistence + osłabienie zapory + payloady “.mp5”

Pobrany skrypt (stager):

  • dopisuje klucz atakującego do /home/ubuntu/.ssh/authorized_keys,
  • ustawia domyślne polityki iptables na ACCEPT,
  • pobiera kolejne payloady z domen związanych ze spoolsv[.]cc,
  • maskuje binarki jako pliki .mp5 (np. sss.mp5, 555.mp5).

Socket opisał też konkretne endpointy i wskaźniki sieciowe (m.in. 154[.]84[.]63[.]184, komunikacja po TCP/443).

4) Dystrybucja przez ekosystem Go (proxy/mirror)

Ważna obserwacja operacyjna: nawet jeśli moduł widnieje w katalogach, kluczowa jest ścieżka pobierania. Go domyślnie korzysta z proxy (np. proxy.golang.org) w mechanizmie rozwiązywania wersji i pobierania modułów — i to właśnie tam moduł został zablokowany po zgłoszeniu, zwracając 403 SECURITY ERROR.

Praktyczne konsekwencje / ryzyko

Kogo to boli najbardziej:

  • zespoły DevOps/infra używające narzędzi CLI w Go (bastiony, jump hosty, admin boxy),
  • CI/CD na Linuxie (runner-y budujące obrazy, narzędzia deploy),
  • narzędzia, które proszą o hasła do SSH, baz danych, API lub KMS w trybie interaktywnym.

Dlaczego to groźne:

  • sekret jest kradziony przed jakimkolwiek hashowaniem/encryption po stronie aplikacji (bo to moment wejścia),
  • persistence przez authorized_keys oznacza łatwy, “cichy” powrót,
  • zmiana polityk iptables może ułatwić dalsze ruchy lateralne i ściąganie narzędzi,
  • Rekoobe zapewnia trwały kanał zdalnych poleceń i pobierania kolejnych payloadów.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowa higiena zależności (Go)

  • Przeskanuj repozytoria pod kątem importów i wpisów w go.mod / go.sum zawierających: github.com/xinfeisoft/crypto.
  • Traktuj każdą zmianę w go.mod jako zmianę bezpieczeństwa: review “pełnej ścieżki modułu”, nie tylko nazwy pakietu.
  • W CI dodaj reguły deny-list dla znanych złych modułów i alerty na “podejrzane utility deps” umożliwiające shell/HTTP w kryptografii (w tej kampanii dołączono m.in. bibliotekę ułatwiającą pipeline’y i sieć).

2) Wykrywanie na endpointach (Linux)

Ustaw detekcje/alerty na:

  • zapis do /usr/share/nano/.lock,
  • pobranie raw.githubusercontent[.]com/.../update[.]html i następujący po nim dynamiczny POST/GET,
  • wykonania /bin/sh -c <treść z sieci> lub wzorce “curl | sh”,
  • modyfikacje /home/ubuntu/.ssh/authorized_keys,
  • zmiany domyślnych polityk iptables na ACCEPT.

3) Blokady sieciowe i IOC (minimum)

Jeśli to pasuje do Twojego modelu blokowania (np. egress filtering), rozważ blokadę:

  • domen/hostów: img.spoolsv[.]cc, img.spoolsv[.]net, spoolsv[.]cc, spoolsv[.]net,
  • IP: 154[.]84[.]63[.]184 (TCP/443),
  • hash’y payloadów (SHA256):
    • sss.mp5: 4afdb3f5914beb0ebe3b086db5a83cef1d3c3c4312d18eff672dd0f6be2146bc
    • 555.mp5: 8b0ec8d0318347874e117f1aed1b619892a7547308e437a20e02090e5f3d2da6

4) Reakcja na incydent (jeśli podejrzewasz infekcję)

  • Potraktuj host jako skompromitowany: rotuj hasła/passphrase wpisywane na tym systemie (SSH, DB, API, itp.).
  • Sprawdź authorized_keys (szczególnie użytkownika ubuntu) oraz historię zmian reguł iptables.
  • Zidentyfikuj procesy/połączenia do 154[.]84[.]63[.]184:443 i artefakty .mp5 pobierane z img.spoolsv[.]cc.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W porównaniu do typowych typosquatów (literówki w nazwie), tutaj kluczowa jest wiarygodność “kultowej” biblioteki oraz atak na “credential edge” (miejsce, gdzie sekret pojawia się jawnie). To z reguły daje:

  • mniej szumu (payload uruchamia się dopiero przy realnym użyciu ReadPassword()),
  • większą wartość zdobytych danych (prawdziwe loginy, passphrase, tokeny),
  • łatwiejsze wejście w persistence (SSH key).

Dodatkowo użycie GitHub Raw jako “przekaźnika” upraszcza rotację infrastruktury i utrudnia blokady oparte wyłącznie o statyczne IoC w kodzie.

Podsumowanie / kluczowe wnioski

  • To nie jest “kolejny złośliwy pakiet” — to celowanie w fundament ekosystemu Go i kradzież sekretów w najbardziej krytycznym momencie: przy wpisywaniu w terminalu.
  • Łańcuch ataku jest prosty i skuteczny: backdoor w ReadPassword() → GitHub Raw jako indirection → sh stager → SSH persistence → Rekoobe.
  • Blokada na Go proxy (403 SECURITY ERROR) ogranicza ryzyko “dla nowych ofiar” w domyślnej ścieżce pobierania, ale nie usuwa skutków dla środowisk, które już pobrały moduł lub używają niestandardowych źródeł.
  • Największy “wins” obrony: twarde review go.mod, skan zależności w PR, oraz detekcje na konkretne zachowania (artefakty plikowe, GitHub Raw fetch + shell exec, modyfikacja authorized_keys).

Źródła / bibliografia

  1. The Hacker News — “Malicious Go Crypto Module Steals Passwords, Deploys Rekoobe Backdoor” (27 lutego 2026). (The Hacker News)
  2. Socket Research — “Malicious Go ‘crypto’ Module Steals Passwords and Deploys Rekoobe Backdoor” (26 lutego 2026). (Socket)
  3. Go.dev — Go Modules Reference (mechanika pobierania modułów i proxy). (go.dev)
  4. Doctor Web — “Rekoobe Trojan threatens Linux users” (3 grudnia 2015). (Dr.Web)
  5. Intezer — “Linux Rekoobe Operating with New, Undetected Malware Samples” (20 stycznia 2020). (Intezer)

APT37 (ScarCruft) przełamuje izolację: nowy zestaw malware do ataków na sieci air-gapped przez USB

Wprowadzenie do problemu / definicja luki

Sieci air-gapped (fizycznie odseparowane od Internetu) uchodzą za jedną z najmocniejszych kontroli bezpieczeństwa w środowiskach OT/ICS, wojsku czy badaniach. Problem w tym, że „air gap” prawie nigdy nie oznacza absolutnej izolacji — w praktyce dane i pliki i tak krążą pomiędzy segmentami dzięki nośnikom wymiennym (USB, dyski zewnętrzne). To właśnie ten „most operacyjny” staje się celem atakujących.

Najnowsze ustalenia pokazują, że północnokoreański aktor APT37 (ScarCruft) wdrożył narzędzia, które zamieniają pendrive’y w dwukierunkowy, ukryty kanał C2: pozwala to zarówno dostarczać polecenia do maszyn odciętych od sieci, jak i wynosić z nich dane.

W skrócie

  • Kampania została opisana przez Zscaler ThreatLabz jako „Ruby Jumper” i jest łączona z APT37.
  • Łańcuch infekcji startuje od złośliwego pliku LNK, który uruchamia PowerShell, wyciąga komponenty z samego skrótu i odpala dokument-przynętę.
  • Zidentyfikowane komponenty obejmują m.in.: RESTLEAF, SNAKEDROPPER, THUMBSBD, VIRUSTASK, FOOTWINE (oraz obserwowany wcześniej backdoor BLUELIGHT).
  • THUMBSBD realizuje kluczową funkcję: używa nośników wymiennych jako „transportu” do przekazywania poleceń i danych między systemami online i air-gapped.

Kontekst / historia / powiązania

APT37 to państwowa grupa szpiegowska powiązana z Koreą Północną, aktywna co najmniej od 2012 r., silnie skupiona na celach w Korei Południowej, ale z szerszym zasięgiem regionalnym.

Wzorzec działań pasuje do znanego modus operandi tej grupy: spear-phishing, pliki skrótów LNK, „living off trusted services” (nadużywanie zaufanych usług chmurowych jako infrastruktury C2 lub dystrybucji). Przykładowo, wcześniejsze analizy (np. Genians) opisywały kampanie APT37 wykorzystujące Dropbox i pliki LNK jako etap inicjalny.

„Ruby Jumper” rozwija te techniki o element szczególnie groźny dla środowisk odseparowanych: kontrolowaną propagację przez USB i mechanizm transferu poleceń/danych przez nośnik.

Analiza techniczna / szczegóły luki

1. Wejście: LNK + PowerShell + przynęta

Łańcuch startuje, gdy użytkownik otworzy złośliwy Windows Shortcut (LNK). Ten uruchamia PowerShell, który „wycina” (carving) zaszyte w skrócie elementy (m.in. kolejne skrypty/payloady) oraz uruchamia dokument-wabik, by zająć uwagę ofiary.

2. RESTLEAF: C2 przez Zoho WorkDrive

Pierwszym implantem jest RESTLEAF, który komunikuje się z infrastrukturą C2 wykorzystując Zoho WorkDrive (z perspektywy obrońcy: ruch do legalnej usługi SaaS).

W praktyce oznacza to:

  • ukrycie komunikacji na tle normalnego ruchu do usług chmurowych,
  • łatwiejsze obchodzenie blokad/allow-list opartych na reputacji domen,
  • potencjalnie trudniejsze atrybuowanie infrastruktury (bo „serwerem” jest repozytorium w chmurze).

3. SNAKEDROPPER: środowisko Ruby jako „kontener” dla kolejnych etapów

Kolejny etap to SNAKEDROPPER – loader, który instaluje środowisko Ruby 3.3.0 i maskuje je jako narzędzie związane z USB (m.in. poprzez nazwę wykonywalną typu usbspeed.exe). Następnie utrwala wykonanie (scheduled task wykonywany cyklicznie).

To ważne z dwóch powodów:

  1. atakujący dostarczają własny „runtime”, uniezależniając się od tego, co jest zainstalowane na stacji,
  2. nietypowy stos (Ruby runtime w katalogach systemowych/ProgramData) może utrudniać reguły detekcji oparte wyłącznie o klasyczne TTP (np. tylko PowerShell/LOLbins).

4. THUMBSBD: „dwukierunkowy przekaźnik C2” przez USB

THUMBSBD pełni rolę backdoora i mechanizmu „mostu” pomiędzy systemem online a air-gapped: przygotowuje pliki z poleceniami, zbiera wyniki i przenosi je przez ukryte katalogi na nośniku. Zscaler opisuje to wprost jako zamianę nośników wymiennych w dwukierunkowy ukryty przekaźnik C2.

W uproszczeniu: operator może „wgrać” polecenia na pendrive na maszynie mającej dostęp do C2 (chmury), a następnie ten sam pendrive przenosi polecenia do stacji air-gapped i wraca z danymi/rezultatami do środowiska online.

5. VIRUSTASK: propagacja w segmencie odciętym

Komponent VIRUSTASK odpowiada za rozprzestrzenianie w środowiskach air-gapped: „uzbraja” nośniki, ukrywając legalne pliki i zastępując je skrótami LNK, które uruchamiają zainstalowany runtime Ruby i dalsze elementy łańcucha. Co istotne, mechanizm ma warunek uruchomienia (np. minimalna wolna przestrzeń na nośniku).

6. FOOTWINE i BLUELIGHT: działania rozpoznawcze i szpiegowskie

W dalszym etapie THUMBSBD dostarcza FOOTWINE – spyware/backdoor z możliwościami takimi jak keylogging, zrzuty ekranu, nagrywanie audio/wideo czy zdalna powłoka. W kampanii obserwowano też BLUELIGHT, wcześniej wiązany z APT37, co wzmacnia atrybucję.

Praktyczne konsekwencje / ryzyko

Największa zmiana nie polega na „magicznej” zdolności łamania air-gapu, tylko na industrializacji przenoszenia kontroli między segmentami:

  • Ryzyko dla OT/ICS i infrastruktury krytycznej: nawet jeśli stacje operatorskie/HMI są odcięte od Internetu, operacyjny obieg plików (raporty, konfiguracje, logi) tworzy ścieżkę ataku.
  • C2 ukryte w chmurze: RESTLEAF wykorzystujący Zoho WorkDrive może wyglądać jak „normalny ruch SaaS”, co komplikuje polityki oparte na prostym allow/deny dla domen.
  • Skuteczna inwigilacja: finalne payloady nastawione są na długotrwałe zbieranie informacji (keylogging, screen/audio/video), co jest typowe dla operacji szpiegowskich.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie ograniczają ryzyko w scenariuszu „USB jako most”:

  1. Twarda kontrola nośników wymiennych
  • wdrożenie polityk device control (whitelist konkretnych VID/PID/seriali),
  • wymuszenie szyfrowania i rejestrowania użycia nośników,
  • ograniczenie autorun i blokada uruchamiania skrótów LNK z nośników (tam gdzie to możliwe operacyjnie).
  1. Detekcja na endpointach (EDR) pod kątem TTP z kampanii
  • alarmy na nietypowe uruchomienia PowerShell pochodzące z LNK,
  • monitoring tworzenia zadań harmonogramu (scheduled tasks) o podejrzanych nazwach/cykliczności,
  • polowanie na anomalię: runtime Ruby wypakowany w nietypowych lokalizacjach (np. %PROGRAMDATA%) i procesy typu usbspeed.exe uruchamiane cyklicznie.
  1. Kontrola dostępu do usług chmurowych (CASB / SWG / proxy)
  • inspekcja i alertowanie na nietypowe użycie Zoho WorkDrive w organizacji (zwłaszcza jeśli nie jest wykorzystywany biznesowo),
  • korelacja: tokeny/operacje API do chmury + zdarzenia endpointowe (LNK/PowerShell) w krótkim oknie czasu.
  1. Procedury dla środowisk air-gapped
  • „strefa buforowa” (kiosk) do skanowania nośników przed wejściem do segmentu odseparowanego,
  • walidacja plików przenoszonych do OT (formaty, podpisy, źródło, integralność),
  • jeśli to możliwe: jednokierunkowy transfer (data diode) zamiast przenoszenia danych na USB.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • Klasyczne infekcje przez LNK: APT37 korzysta z tej techniki od lat, co widać także w starszych kampaniach opisywanych publicznie (np. nadużycia usług chmurowych i LNK jako wektora).
  • Nowość w „Ruby Jumper”: nie sam phishing, lecz spójny zestaw narzędzi do obsługi pełnego cyklu air-gap (propagacja + przenoszenie poleceń + exfil przez nośnik), oraz wyraźne postawienie na chmurę SaaS (Zoho WorkDrive) jako warstwę C2.

Podsumowanie / kluczowe wnioski

APT37 pokazuje, że „air-gap” bez kontroli nośników wymiennych jest bardziej założeniem niż zabezpieczeniem. Kampania Ruby Jumper łączy:

  • inicjalny dostęp przez LNK + PowerShell,
  • C2 ukryte w Zoho WorkDrive,
  • oraz krytyczny element: THUMBSBD/VIRUSTASK, które zamieniają USB w kanał sterowania i transferu danych do/z środowisk air-gapped.

Jeśli w organizacji istnieje choćby minimalny „ruch USB” między segmentami, warto potraktować ten scenariusz jako realny i wdrożyć kontrolę nośników, hunting endpointowy oraz polityki dla usług SaaS.

Źródła / bibliografia

  • BleepingComputer – opis kampanii i przegląd narzędzi (RESTLEAF, SNAKEDROPPER, THUMBSBD, VIRUSTASK, FOOTWINE, BLUELIGHT). (BleepingComputer)
  • Zscaler ThreatLabz – raport techniczny „APT37 Adds New Capabilities for Air-Gapped Networks” (Ruby Jumper, Zoho WorkDrive, szczegóły łańcucha infekcji). (zscaler.com)
  • MITRE ATT&CK – profil grupy APT37 (G0067) i kontekst operacyjny. (MITRE ATT&CK)
  • Genians – przykład wcześniejszych kampanii APT37 z LNK i nadużyciem chmury (kontekst TTP). (genians.co.kr)

CISA ostrzega: malware RESURGE może „uśpić się” na urządzeniach Ivanti i czekać na ponowny kontakt atakującego

Wprowadzenie do problemu / definicja luki

CISA opublikowała zaktualizowane ustalenia dotyczące RESURGE – złośliwego „implantu” (komponentu osadzanego na urządzeniu brzegowym), używanego w kampaniach wykorzystujących podatność CVE-2025-0282 do kompromitacji Ivanti Connect Secure (ICS). Kluczowy wniosek jest bardzo praktyczny: RESURGE może pozostawać uśpiony (dormant) i niewykryty na urządzeniu tak długo, aż operator ataku ponownie spróbuje się z nim połączyć.

To istotne, bo w przypadku „edge device” (VPN / gateway) brak typowego „beaconingu” do C2 oznacza mniejszą szansę, że SIEM/NDR zobaczy podejrzany ruch wychodzący. W praktyce: możesz mieć pozornie „czyste” logi i brak alarmów, a urządzenie nadal jest zagnieżdżone.

W skrócie

  • RESURGE to 32-bitowa biblioteka współdzielona Linuksa (m.in. wskazywana jako libdsupgrade.so) znaleziona na skompromitowanych urządzeniach Ivanti ICS.
  • Implant działa jako pasywny C2: nie wysyła cyklicznych połączeń, tylko czeka na specyficzne połączenie przychodzące TLS.
  • Mechanizmy unikania detekcji obejmują m.in. fingerprinting TLS (CRC32) oraz elementy uwierzytelniania z użyciem fałszywego certyfikatu Ivanti, a po „rozpoznaniu” operatora – zestawienie szyfrowanej sesji (mTLS / kryptografia eliptyczna).
  • Kampanie łączono z aktorem powiązanym z Chinami (UNC5221) i ekosystemem malware „SPAWN”.

Kontekst / historia / powiązania

Wątek Ivanti ICS i podatności na urządzeniach brzegowych wraca regularnie, ale tutaj mówimy konkretnie o CVE-2025-0282 (stack-based buffer overflow), która była aktywnie wykorzystywana jako 0-day jeszcze przed udostępnieniem poprawek.

W raportach z 2025 r. pojawia się powiązanie z rodziną narzędzi „SPAWN” oraz wariantami/odnogami jak SpawnChimera, a RESURGE bywa opisywany jako wariant/powiązany komponent tej linii rozwojowej (wspólne funkcje i cele: utrzymanie dostępu, tunelowanie, backdoor).

Analiza techniczna / szczegóły luki

1) Pasywny C2 i „czekanie” na atakującego

Najbardziej niepokojący mechanizm opisany w aktualizacji: RESURGE nie musi generować ruchu wychodzącego, bo czeka w nieskończoność na odpowiednio spreparowane połączenie przychodzące TLS. To klasyczny wzorzec „low-noise persistence” na urządzeniach brzegowych.

2) Hookowanie accept() i selekcja ruchu

Według opisu technicznego, gdy implant jest załadowany w kontekście procesu web, hookuje funkcję accept(), aby analizować pakiety TLS zanim trafią do webserwera – i rozpoznawać, czy to „normalny” klient, czy operator ataku.

3) Fingerprinting TLS (CRC32) oraz fałszywy certyfikat

Ruch jest weryfikowany m.in. przez CRC32 TLS fingerprint hashing scheme – jeśli fingerprint się nie zgadza, połączenie jest obsługiwane jak legalny ruch do Ivanti. Dodatkowo pojawia się sfałszowany certyfikat Ivanti używany do potwierdzenia, że operator rozmawia z implantem, a nie prawdziwą usługą. Co ważne, w opisie podkreślono, że certyfikat ma rolę „identyfikacyjną/uwierzytelniającą”, a niekoniecznie służy do szyfrowania – co daje obrońcom potencjalny artefakt sygnaturowy na poziomie sieci.

4) Kryptografia eliptyczna i mTLS

Po udanej weryfikacji fingerprintu i „handshake’u” z operatorem, implant zestawia bezpieczny zdalny dostęp z użyciem mTLS i kryptografii krzywych eliptycznych, żądając klucza EC od operatora i weryfikując go względem wbudowanego klucza CA.

5) Funkcje: od rootkita po bootkit (w tym coreboot)

Opis funkcjonalny RESURGE jest szeroki: rootkit/bootkit/backdoor/dropper/proxy/tunneling. W materiale zwrócono też uwagę, że malware potrafi odszyfrować, zmodyfikować i ponownie zaszyfrować obrazy firmware coreboot oraz manipulować zawartością systemu plików w celu utrzymania się na poziomie rozruchu. To podnosi poprzeczkę IR: „zwykły” restart czy częściowe czyszczenie może nie wystarczyć.

6) Log-tampering i komponenty towarzyszące

W analizowanych artefaktach wskazano również wariant SpawnSloth (liblogblock.so) służący do manipulacji logami (ukrywanie aktywności), a także skrypt/binarne narzędzie związane z ekstrakcją kernela (dsmain).

Praktyczne konsekwencje / ryzyko

  1. Ryzyko „fałszywego poczucia bezpieczeństwa”
    Brak beaconingu i log-tampering oznaczają, że standardowe sygnały kompromitacji mogą być niewidoczne.
  2. Utrzymanie dostępu na urządzeniu brzegowym = klucz do sieci
    ICS zwykle stoi na styku Internet–intranet. Kompromitacja takiego węzła ułatwia pivoting, kradzież poświadczeń i długotrwałe operacje szpiegowskie.
  3. Potencjalnie trudna eradykacja
    Jeśli w grę wchodzą mechanizmy boot-level i modyfikacje związane z firmware, organizacja musi rozważyć scenariusze „bare metal / rebuild” i rygorystyczną walidację urządzeń.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które zwykle mają sens w organizacjach korzystających z Ivanti Connect Secure – szczególnie gdy urządzenie było narażone na eksploatację CVE-2025-0282 lub nie ma twardej pewności co do stanu kompromitacji:

  1. Natychmiastowa higiena podatności
  • Upewnij się, że ICS jest na wersji/konfiguracji z poprawką dla CVE-2025-0282 (oraz że nie ma „luk pobocznych” wynikających z zaległości w aktualizacjach).
  1. Polowanie na IoC i artefakty na urządzeniu
  • Szukaj wskazanych nazw/artefaktów typu libdsupgrade.so, liblogblock.so i powiązanych hashy/IoC z aktualizacji (ważne: część IoC może dotyczyć konkretnej próbki, więc traktuj to jako punkt startowy do threat huntingu).
  1. Detekcja na poziomie sieci
  • Włącz/rozszerz inspekcję połączeń przychodzących do ICS pod kątem anomalii TLS i nietypowych certyfikatów – opis wskazuje, że fałszywy certyfikat może posłużyć jako „network signature” przy aktywnym kontakcie operatora z implantem.
  1. Załóż kompromitację przy braku dowodów negatywnych
  • Jeśli urządzenie było podatne w okresie aktywnej eksploatacji, rozważ podejście: izolacja, pełny przegląd, a w razie wątpliwości wymiana/rebuild urządzenia i odtworzenie konfiguracji z zaufanego źródła.
  1. Rotacja poświadczeń i przegląd dostępu
  • Resetuj hasła kont uprzywilejowanych, kont serwisowych i integracji, które mogły być używane przez ICS (VPN, LDAP/AD bind, SSO), oraz przejrzyj konta lokalne/nieoczekiwane zmiany.
  1. Telemetry + retencja logów
  • Zwiększ retencję, wysyłkę logów poza urządzenie (syslog/SIEM), a także korelację z EDR/NDR – log-tampering na samym urządzeniu jest wtedy mniej bolesny operacyjnie.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W porównaniu do „typowego” backdoora, który odzywa się do C2 (HTTP/DNS beacon), RESURGE jest bardziej zbliżony do stylu „edge implantów” obserwowanych w kampaniach APT: minimalny hałas, pasywny kanał dostępu i nacisk na przetrwanie na urządzeniu brzegowym. Mechanizmy w rodzaju hookowania accept() i selekcji połączeń przychodzących są szczególnie problematyczne dla środowisk, które polegają głównie na wykrywaniu anomalii w ruchu wychodzącym.

Podsumowanie / kluczowe wnioski

  • RESURGE może „czekać” na urządzeniu Ivanti ICS bez generowania podejrzanego ruchu, co utrudnia wykrycie i zwiększa ryzyko długotrwałej kompromitacji.
  • Technicznie to nie jest prosty webshell: mówimy o komponencie z elementami rootkit/bootkit, zaawansowaną selekcją TLS i mechanizmami uwierzytelniania operatora.
  • Działania obronne powinny łączyć patch management, hunting po IoC/artefaktach, detekcję sieciową i gotowość do twardszych kroków (izolacja/rebuild/rotacja sekretów) w scenariuszach podwyższonego ryzyka.

Źródła / bibliografia

  1. BleepingComputer – opis aktualizacji CISA i detale techniczne (pasywny C2, TLS fingerprint, fałszywy certyfikat, coreboot). (BleepingComputer)
  2. Cybersecurity Dive – kontekst „latent/undetected”, odniesienie do analizy próbek z infrastruktury krytycznej. (cybersecuritydive.com)
  3. SecurityWeek – tło CVE-2025-0282, UNC5221 i ekosystem SPAWN/SpawnChimera. (SecurityWeek)
  4. SC Media – opis funkcji RESURGE oraz komponentów do log-tampering i narzędzi towarzyszących. (SC Media)
  5. Heise – szerszy kontekst eksploatacji Ivanti na przestrzeni 2025 r. (kontekst kampanii i aktorów). (heise online)

UFP Technologies ujawnia cyberatak w raporcie do SEC: kradzież danych, zakłócenia IT i odtworzenie z kopii zapasowych

Wprowadzenie do problemu / definicja luki

UFP Technologies (producent/kontraktowy wytwórca rozwiązań dla wyrobów medycznych) poinformował w zgłoszeniu do amerykańskiej SEC o incydencie cyberbezpieczeństwa, który dotknął część systemów IT i wiązał się z wyciekiem (exfiltracją) plików oraz informacją, że część danych mogła zostać skradziona lub zniszczona.

W praktyce tego typu zdarzenia w MedTech są krytyczne nie tylko ze względu na poufność danych, ale też przez ryzyko zakłóceń procesów produkcyjno-logistycznych (fakturowanie, etykietowanie wysyłek, realizacja zamówień), które potrafią przełożyć się na dostępność wyrobów w placówkach ochrony zdrowia.

W skrócie

  • Wykrycie incydentu: około 14 lutego 2026 r. (podejrzana aktywność w systemach IT).
  • Wpływ na biznes: naruszone „wiele, ale nie wszystkie” systemy; ucierpiały m.in. billing i generowanie etykiet wysyłkowych.
  • Dane: część danych „firmowych lub powiązanych z firmą” mogła zostać skradziona lub zniszczona; firma potwierdza exfiltrację plików, bada czy obejmowała dane osobowe.
  • Ciągłość działania: operacje trwały „w istotnym zakresie” dzięki planom awaryjnym i kopiom zapasowym.
  • Koszty i ubezpieczenie: spółka oczekuje, że znacząca część kosztów bezpośrednich zostanie pokryta z ubezpieczenia.
  • Charakter ataku: niezależne źródła oceniają, że opis pasuje do ransomware (szyfrowanie + kradzież danych), ale w momencie publikacji nikt nie przyznał się publicznie do ataku.

Kontekst / historia / powiązania

UFP zgłosił incydent w trybie Item 1.05 (Material Cybersecurity Incidents) formularza 8-K. Ten tryb wynika z zasad SEC przyjętych w 2023 r., które wymagają ujawnienia materialnego incydentu cyber w formularzu 8-K zasadniczo w ciągu 4 dni roboczych od momentu uznania incydentu za „materialny” (liczy się moment decyzji o materialności, nie wykrycia).

To ważny szczegół: spółki często wykrywają incydent wcześniej, ale formalne raportowanie zależy od procesu oceny wpływu (finansowego/operacyjnego/regulacyjnego).

Analiza techniczna / szczegóły luki

Z raportu 8-K wynika kilka technicznych wskazówek (choć sama spółka nie podaje wektora ataku ani nazwy grupy):

1. Sygnały typowe dla incydentów „double extortion”

  • Firma potwierdza, że pliki zostały exfiltrowane, a jednocześnie dane mogły zostać zniszczone.
  • Uderzenie w procesy typu billing/etykiety wysyłkowe bywa skutkiem ubocznym szyfrowania lub odcięcia systemów wspierających realizację zamówień.

Na tej podstawie SecurityWeek ocenia, że opis wygląda jak atak ransomware obejmujący kradzież danych i wdrożenie malware szyfrującego.
To wciąż hipoteza (brak potwierdzenia ze strony sprawców), ale zgodna z często obserwowanym schematem w sektorze produkcji i healthcare.

2. Reakcja IR i odzyskiwanie
UFP wskazuje na klasyczne kroki IR:

  • izolacja części środowiska,
  • wsparcie zewnętrznych doradców,
  • odtworzenie dostępu do informacji „w istotnym zakresie”,
  • wykorzystanie planów awaryjnych i backupów do wdrożenia „planowanych rozwiązań” i utrzymania operacji.

To sugeruje, że organizacja miała przynajmniej część mechanizmów ciągłości działania przygotowanych pod incydenty tego typu (co nie oznacza braku strat — zwłaszcza przy exfiltracji).

Praktyczne konsekwencje / ryzyko

Największe ryzyka, które widać wprost lub pośrednio w zgłoszeniu:

  1. Ryzyko prywatności i obowiązków notyfikacyjnych – firma nadal bada, czy wyciek obejmował dane osobowe i jakie zgłoszenia prawne/regulacyjne będą wymagane.
  2. Ryzyko operacyjne i łańcucha dostaw – problemy z fakturowaniem i etykietami wysyłek są realnym sygnałem uderzenia w „nerwy” logistyki. W MedTech to może skutkować opóźnieniami w dostawach i napięciami po stronie klientów (szpitale, dystrybutorzy, integratorzy).
  3. Ryzyko finansowe i reputacyjne – spółka na dzień raportu nie widzi „materialnego wpływu” na systemy finansowe/operacje/kondycję, ale dochodzenie trwa, a koszty (IR, prawne, PR, wzmacnianie zabezpieczeń, ewentualne roszczenia) potrafią rosnąć w czasie.

Rekomendacje operacyjne / co zrobić teraz

Jeśli prowadzisz organizację produkcyjną (szczególnie w MedTech/healthcare), ten przypadek jest dobrą checklistą, co realnie „boli” podczas incydentu:

1. Backup i odtwarzanie (to, co uratowało ciągłość)

  • Kopie offline/immutable, separacja domenowa, testy odtwarzania (RTO/RPO) dla krytycznych procesów: ERP, WMS/TMS, etykietowanie, billing.
  • „Ćwiczenia” odtwarzania nie tylko plików, ale całych zależności (AD, DNS, PKI, narzędzia do drukowania etykiet).

2. Minimalizacja blast radius

  • Segmentacja sieci i uprawnień (szczególnie między IT/OT, drukarkami etykiet, systemami magazynowymi, usługami fakturowania).
  • MFA wszędzie, gdzie się da; monitoring logowań uprzywilejowanych.

3. Detekcja exfiltracji

  • Widoczność na egress (proxy, DNS, CASB/SSE), DLP kontekstowe, alerty na nietypowe transfery/archiwizacje.
  • Retencja logów pod kątem „materiality assessment” i późniejszej analizy prawnej.

4. Gotowość do raportowania i komunikacji

  • Procedura „materiality” i playbook dla wymogów SEC/kontraktowych/branżowych.
  • Wewnętrzny proces decyzyjny: kiedy i jak komunikować wpływ na dostawy/usługi.

Różnice / porównania z innymi przypadkami

The Record zwraca uwagę, że podobne problemy (zakłócenia realizacji zamówień/shipingu) pojawiają się w raportach innych firm z branży urządzeń medycznych, które zgłaszały incydenty regulatorowi.
Wspólny mianownik w wielu takich zdarzeniach: atak nie musi „zatrzymać fabryki” wprost — wystarczy uderzenie w systemy koordynujące wysyłki, etykiety, EDI, fakturowanie.

Podsumowanie / kluczowe wnioski

  • Incydent w UFP Technologies (wykryty ok. 14.02.2026) objął część systemów IT, zakłócił procesy billingu i etykiet wysyłkowych, a spółka potwierdza exfiltrację plików i możliwość kradzieży/zniszczenia danych.
  • Opis pasuje do schematu ransomware + kradzież danych, choć na moment publikacji nie było publicznego przyznania się sprawców.
  • Największa lekcja operacyjna: ciągłość działania (backup, plany awaryjne, odtwarzanie procesów biznesowych) bywa tak samo krytyczna jak same mechanizmy prewencji.

Źródła / bibliografia

  1. UFP Technologies – zgłoszenie Form 8-K, Item 1.05 (archiwum SEC). (SEC)
  2. The Record (Recorded Future News) – omówienie zgłoszenia i kontekstu branżowego. (The Record from Recorded Future)
  3. SecurityWeek – interpretacja wskazująca na możliwy ransomware i brak przyznania się grupy. (SecurityWeek)
  4. Reuters (via MarketScreener) – krótka depesza o incydencie i odniesienie do zgłoszenia SEC. (MarketScreener)
  5. SEC – komunikat o zasadach ujawniania incydentów cyber (Item 1.05 / 4 dni robocze od oceny materialności). (SEC)

GRIDTIDE: jak Google i Mandiant przerwali globalną kampanię szpiegowską opartą o Google Sheets API

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). Kluczowy 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 ważny 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, że 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, że 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, że 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, lecz 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

  1. Ryzyko masowej inwigilacji: dostęp do PII i zasobów telekomu może służyć identyfikacji i śledzeniu „persons of interest”.
  2. Ryzyko nadużyć lawful intercept / metadanych: Google przypomina, że podobne intruzje w telekomach w przeszłości kończyły się kradzieżą CDR, podglądem SMS i nadużyciami systemów przechwytu.
  3. Trudniejsze wykrywanie: jeżeli 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) – nawet jeśli 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), nawet jeśli 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 / kluczowe 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ą, że chodzi o długofalowy wywiad, a nie szybki zysk.

Najważniejsza lekcja dla obrony: jeśli nie instrumentujesz API + tożsamości + egress, możesz przegapić atak, który „wygląda jak normalna praca z chmurą”.

Źródła / bibliografia

  1. Google Cloud Blog (GTIG & Mandiant) – “Exposing the Undercurrent: Disrupting the GRIDTIDE Global Cyber Espionage Campaign”, 25.02.2026. (Google Cloud)
  2. Reuters – relacja o skali i charakterze kampanii oraz disrupt, 25.02.2026. (Reuters)
  3. SecurityWeek – omówienie kampanii i kontekstu, 25–26.02.2026. (SecurityWeek)
  4. Cybersecurity Dive – podsumowanie i akcent na nadużycie legalnych funkcji cloud/SaaS, 25.02.2026. (cybersecuritydive.com)

GitHub Issues jako wektor ataku na Copilot: „RoguePilot” i scenariusz przejęcia repozytorium w Codespaces

Wprowadzenie do problemu / definicja luki

W lutym 2026 r. opisano podatność, w której zwykły opis zgłoszenia (GitHub Issue) może stać się nośnikiem złośliwych instrukcji dla GitHub Copilot uruchomionego wewnątrz GitHub Codespaces. Kluczowy problem nie polega na „błędzie w LLM”, tylko na zbyt głębokiej automatyzacji: podczas tworzenia Codespace z kontekstu Issue treść zgłoszenia jest automatycznie wykorzystywana jako prompt dla asystenta, co otwiera drogę do passive prompt injection.

To typ zagrożenia klasyfikowany szerzej jako prompt injection (LLM01 w OWASP Top 10 dla aplikacji LLM), gdzie atakujący manipuluje zachowaniem modelu przez odpowiednio spreparowane dane wejściowe.

W skrócie

  • Atak nazwany RoguePilot pokazuje łańcuch, w którym Issue → automatyczny prompt w Codespaces → działania Copilota → eksfiltracja tokenu.
  • W wariancie opisanym przez badaczy możliwe było doprowadzenie do wycieku uprzywilejowanego GITHUB_TOKEN z Codespaces, co w konsekwencji umożliwiało przejęcie repozytorium (zależnie od uprawnień tokenu).
  • Wykorzystano m.in. ukryte instrukcje w HTML comments w treści Issue oraz mechanizm automatycznego pobierania JSON schema w VS Code jako kanał eksfiltracji.
  • GitHub wdrożył poprawki po zgłoszeniu (responsible disclosure).

Kontekst / historia / powiązania

RoguePilot wpisuje się w rosnącą klasę zagrożeń, gdzie LLM staje się „pośrednikiem wykonawczym”: nie tylko generuje tekst, ale też steruje narzędziami w środowisku deweloperskim. To zmienia model ryzyka z „halucynacji” na AI-mediated supply chain attack — złośliwe instrukcje mogą pochodzić z treści, które dotąd traktowano jako „bezpieczne metadane projektu” (Issues, komentarze, opisy PR).

OWASP podkreśla, że prompt injection jest ryzykiem numer 1 dla systemów LLM, bo modele nie mają naturalnej granicy między „danymi” a „instrukcją”.

Analiza techniczna / szczegóły luki

1) Punkt wejścia: Issue jako „prompt”

W opisywanym scenariuszu uruchomienie Codespace z poziomu Issue powodowało, że Copilot w środowisku miał zostać automatycznie zapromptowany treścią zgłoszenia. To wystarcza, aby atakujący (np. w repo publicznym lub w repo, gdzie może tworzyć Issues) umieścił w opisie instrukcje dla agenta.

2) Ukrycie instrukcji: HTML comments

Badacze wskazali, że złośliwe polecenia można ukryć w <!-- -->, dzięki czemu człowiek „na oko” widzi zwykłe zgłoszenie, a model nadal przetwarza pełną treść.

3) Pozyskanie sekretu: GITHUB_TOKEN z Codespaces

W Codespaces dostępny jest GITHUB_TOKEN jako domyślna zmienna środowiskowa; GitHub opisuje go jako podpisany token uwierzytelniający użytkownika w codespace, możliwy do użycia np. do wywołań GitHub API.
W łańcuchu RoguePilot token miał zostać odczytany z pliku wewnątrz środowiska Codespaces (wskazywanego w analizie badaczy) i następnie wyprowadzony na zewnątrz.

4) Ominięcie ograniczeń ścieżki: symlink + PR checkout

W opisie ataku pojawia się wykorzystanie symbolicznego linku w repozytorium oraz nakłonienie Copilota do przełączenia się na przygotowany PR, w którym symlink wskazuje na wrażliwy plik w obszarze współdzielonym Codespaces.

5) Kanał eksfiltracji: automatyczne pobieranie JSON schema

Kluczowa sztuczka: VS Code potrafi automatycznie pobierać schema dla JSON, gdy w pliku występuje pole $schema. Badacze opisują, że ustawienie json.schemaDownload.enable jest w Codespaces włączone domyślnie, więc można je nadużyć jako „legalny” outbound request i dopiąć wykradane dane do URL schemy (np. w query string).
Istnienie przełącznika json.schemaDownload.enable jako opcji, która ma umożliwić wyłączenie pobierania schem, jest udokumentowane w ekosystemie VS Code.

Praktyczne konsekwencje / ryzyko

  1. Przejęcie repozytorium i supply chain
    Jeśli GITHUB_TOKEN ma uprawnienia zapisu, atakujący może wypchnąć zmiany, otworzyć/zmodyfikować PR-y, wstrzyknąć backdoora, podmienić workflow itp. To klasyczny scenariusz supply chain, tylko uruchamiany przez „zainfekowany kontekst” dla agenta AI.
  2. Atak bez „klikania w link” i bez socjotechniki wprost
    W wielu organizacjach tworzenie Codespace do „szybkiego ogarnięcia issue” jest normalnym nawykiem. Wtedy atak jest bliski „zero-interaction”: nie trzeba, by ofiara wkleiła prompt — wystarczy, że otworzy Codespace z Issue.
  3. Trudniejsza detekcja
    Instrukcje ukryte w komentarzach HTML i eksfiltracja przez „normalny” request po schema wyglądają jak działania narzędzia, a nie malware.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów dev / AppSec

  • Traktuj Issue/PR/README jako dane nieufne dla agentów AI: jeśli narzędzie automatycznie wciąga kontekst, załóż, że będzie on adversarial.
  • Ogranicz tokeny w środowiskach developerskich: skróć TTL, minimalizuj scope, rozważ rozdzielenie tokenów „do odczytu” i „do zapisu” w zależności od tasku. (Ryzyko dotyczy tego, że Codespaces udostępnia GITHUB_TOKEN do działań w repo).
  • Wyłącz lub ogranicz automatyczne pobieranie schem JSON w środowiskach, gdzie ma to sens (np. polityka organizacyjna/konfiguracje VS Code/Dev Container) — to usuwa prosty kanał eksfiltracji oparty o $schema.
  • Wykrywanie ukrytych promptów: automatyczne skanowanie treści Issue/PR pod kątem podejrzanych wzorców (np. długie instrukcje, „system prompt”-like frazy, fragmenty nakazujące pobieranie z URL, polecenia dot. tokenów/sekretów).
  • Blokada/monitoring outbound z Codespaces (jeśli to możliwe w modelu sieciowym): allowlisty domen, detekcja anomalii w żądaniach HTTP GET z parametrami przypominającymi dane.

Dla maintainerów repozytoriów

  • Ogranicz możliwość tworzenia Issues (w publicznych repo rozważ moderację/triage, szablony, wymaganie konta o określonym zaufaniu).
  • Polityka „nie odpalamy Codespace bez weryfikacji treści Issue”: szczególnie dla zgłoszeń od nowych kont.

Dla vendorów / dostawców narzędzi AI

  • Fail-safe defaults: nie wolno pasywnie promptować agenta treścią z repo bez wyraźnego „consent” i warstwy sanitizacji; trzeba też blokować ścieżki eksfiltracji (np. automatyczne fetchowanie zasobów po URL).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • Klasyczny prompt injection zwykle dotyczy czatu/aplikacji, gdzie użytkownik wkleja treść. W RoguePilot mamy passive prompt injection: model „sam” konsumuje treść z Issue przy starcie środowiska.
  • W odróżnieniu od ataków stricte na zależności (typosquatting, dependency confusion), tutaj „wejściem” jest artefakt procesowy SDLC (Issue), a „wykonawcą” — agent AI z uprawnieniami do narzędzi i tokenów.

Podsumowanie / kluczowe wnioski

RoguePilot to mocny przykład, że integracje agentów AI w narzędziach deweloperskich mogą tworzyć nowe łańcuchy ataku: dane, które do tej pory były „tylko tekstem w trackerze”, stają się instrukcją sterującą automatem z dostępem do sekretów i operacji na repo.

Najważniejsze działania obronne to:

  • odcięcie pasywnego zaufania do kontekstu (Issues/PR jako untrusted),
  • minimalizacja i kontrola GITHUB_TOKEN,
  • redukcja automatycznych mechanizmów pobierania zasobów (np. schema),
  • oraz polityki operacyjne „jak bezpiecznie używać agent mode”.

Źródła / bibliografia

  1. Orca Security Research Pod – „RoguePilot: Exploiting GitHub Copilot for a Repository Takeover” (16 lutego 2026). (Orca Security)
  2. SecurityWeek – „GitHub Issues Abused in Copilot Attack Leading to Repository Takeover” (24 lutego 2026). (SecurityWeek)
  3. GitHub Docs – „Default environment variables for your codespace” (opis GITHUB_TOKEN). (GitHub Docs)
  4. OWASP GenAI – LLM01: Prompt Injection (oraz OWASP Top 10 for LLM Applications). (OWASP Gen AI Security Project)
  5. Microsoft VS Code – issue dot. ustawienia json.schemaDownload.enable (wyłączenie pobierania schem). (GitHub)

USA nakłada sankcje na rosyjskiego „brokera exploitów” Operation Zero. W tle kradzież narzędzi cybernetycznych z L3Harris

Wprowadzenie do problemu / definicja luki

Rynek 0-day (zero-day) i „brokerów exploitów” to szara strefa pomiędzy legalnym bug bounty a handlem ofensywnymi narzędziami, które mogą trafić do służb i grup przestępczych. „Exploit broker” skupuje podatności lub gotowe łańcuchy exploitów, często oferując wysokie premie za ekskluzywność, a następnie odsprzedaje je wybranym klientom.

W tym modelu kluczowym ryzykiem jest brak „responsible disclosure”: dostawca oprogramowania nie dowiaduje się o luce, dopóki ktoś jej nie użyje. Według komunikatu Departamentu Skarbu USA, Operation Zero miało oferować wielomilionowe „bounty” za exploity na powszechnie używane produkty, w tym amerykańskie systemy operacyjne i aplikacje szyfrujące.

W skrócie

  • 24 lutego 2026 r. OFAC (Departament Skarbu USA) nałożył sankcje na rosyjskiego obywatela Sergeya Sergeyevicha Zelenyuka oraz jego firmę Matrix LLC (działającą jako Operation Zero), a także na sieć powiązanych osób i podmiotów.
  • W tle jest sprawa Petera Williamsa (byłego menedżera w spółce powiązanej z L3Harris), który przyznał się do kradzieży tajemnic handlowych i sprzedaży komponentów exploitów brokerowi z Rosji.
  • USA wskazują, że co najmniej osiem skradzionych narzędzi cybernetycznych (zbudowanych do użytku rządu USA i wybranych sojuszników) trafiło do Operation Zero, a następnie do „nieuprawnionych” użytkowników.

Kontekst / historia / powiązania

Z artykułu The Record wynika, że Operation Zero miało jawnie marketingować się do klientów spoza NATO oraz do „zagranicznych agencji wywiadowczych”. To istotne, bo sygnalizuje model biznesowy nastawiony na dostarczanie ofensywnych capability podmiotom, które mogą je wykorzystać w działaniach państwowych lub przestępczych.

Do tego dochodzi wątek „insider threat”: Williams miał wykorzystywać dostęp do sieci i zasobów pracodawcy, aby wynosić chronione komponenty i sprzedawać je w zamian za płatności w kryptowalutach oraz „follow-on support” (wsparcie po sprzedaży).

W komunikacie Skarbu USA pojawia się też drugi broker: Advance Security Solutions (operacje w UAE i Uzbekistanie), wskazany jako podmiot oferujący bounty za exploity na amerykańskie technologie.

Analiza techniczna / szczegóły luki

To nie jest pojedyncza podatność typu CVE, tylko łańcuch dostaw ofensywnych narzędzi:

  1. Pozyskanie exploitów/0-day
    Broker oferuje premie (często „za wyłączność”) za gotowe exploity na popularne platformy. Według OFAC, Operation Zero nie ujawniało luk producentom oprogramowania.
  2. Przerzut narzędzi przez kanały trudne do atrybucji
    W sprawie Williamsa pojawiają się: transfer „encrypted means”, kontrakty i płatności w kryptowalutach. To zestaw typowy dla ograniczania śladów finansowych i operacyjnych.
  3. Monetyzacja i „operacjonalizacja”
    Exploity mogą być użyte do: zdalnego wykonania kodu, eskalacji uprawnień, wykradania danych, instalacji spyware, budowy botnetów lub łańcuchów ransomware. OFAC wprost wskazuje ryzyko użycia takich narzędzi do ransomware i innych „malign activities”.
  4. Dodatkowy wektor: dane i AI
    W komunikacie Skarbu USA pada też wątek prób rozwijania metod pozyskiwania danych (PII/sensitive data) w kontekście informacji wgrywanych przez użytkowników do aplikacji AI (np. LLM). To ważny sygnał dla organizacji: „prompt/attachment hygiene” zaczyna być elementem bezpieczeństwa danych, nie tylko compliance.

Praktyczne konsekwencje / ryzyko

Dla zespołów bezpieczeństwa największe znaczenie ma to, że sankcje dotyczą ekosystemu dostawców ofensywnych capability, a nie tylko jednej kampanii malware.

Najbardziej realne ryzyka:

  • Wzrost prawdopodobieństwa ataków 0-day na popularne platformy (OS, komunikatory szyfrujące, oprogramowanie enterprise) bez uprzedzenia producenta.
  • Ryzyko insider threat w firmach technologicznych i obronnych: wynoszenie kodu, komponentów exploitów, dokumentacji lub narzędzi z repozytoriów i systemów build/release.
  • Ryzyko sankcyjne i reputacyjne: kontakt handlowy (bezpośredni lub pośredni) z podmiotami objętymi sankcjami może generować konsekwencje prawne i finansowe (w tym dla firm spoza USA, jeśli wchodzą w interakcje z systemem finansowym USA).

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/CSIRT, GRC i działów zakupów (vendor management) sensowne są działania „tu i teraz”:

  1. Screening sankcyjny i due diligence dostawców
    • Zaktualizuj listy screeningowe o nowe wpisy OFAC (SDN) i sprawdź: dostawców usług security, „research brokers”, pośredników bug bounty, a także kontrahentów płatności krypto/escrow.
  2. Wzmocnienie kontroli insider threat
    • DLP na repozytoriach kodu i systemach do zarządzania podatnościami / exploitami.
    • Monitoring nietypowych eksportów danych (duże archiwa, prywatne klucze, artefakty build).
    • Zasada najmniejszych uprawnień i rozdział ról dla dostępu do „high-risk” komponentów (exploit dev, implant frameworks, red-team tooling).
  3. Higiena 0-day readiness
    • Uporządkuj proces „rapid response patching” (SLA na krytyczne podatności) oraz plan awaryjny, gdy patcha nie ma: segmentacja, izolacja, wirtualne łatki (WAF/IPS), hardening.
    • Przećwicz playbook „exploitation suspected” (telemetria EDR, hunting, memory forensics).
  4. Polityka danych w kontekście AI/LLM
    • Zablokuj wrażliwe uploady do narzędzi AI (kod, logi, konfiguracje, dane klientów), jeśli nie masz jasnej kontroli nad retencją i dostępem; traktuj to jako element ochrony tajemnic przedsiębiorstwa. (To szczególnie istotne w świetle wątków o „data extraction” wspomnianych przez OFAC).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W odróżnieniu od sankcji nakładanych na konkretne gangi ransomware czy grupy APT, ten przypadek celuje w rynek pośredników: podmioty, które nie muszą same prowadzić kampanii, ale dostarczają „amunicję” (0-day i spyware) innym.

To podobna logika do działań wymierzonych w „dostawców” ekosystemu (np. infrastruktura, bulletproof hosting, brokerzy dostępu), tyle że tu chodzi o łańcuch dostaw exploitów i potencjalne „przecieki” narzędzi przeznaczonych dla rządowych zastosowań.

Podsumowanie / kluczowe wnioski

  • Sankcje z 24 lutego 2026 r. pokazują, że USA coraz mocniej traktują handel 0-day jako element bezpieczeństwa narodowego, zwłaszcza gdy w grę wchodzi kradzież narzędzi z sektora obronnego.
  • Dla firm najważniejsze jest podejście „systemowe”: kontrola insider threat, gotowość na 0-day oraz rygorystyczny compliance screening (w tym łańcucha dostaw usług cyber).
  • Wątek AI/LLM w komunikacie OFAC to kolejny sygnał, że ochrona danych i tajemnic handlowych musi obejmować również procesy związane z korzystaniem z narzędzi generatywnych.

Źródła / bibliografia

  1. The Record (Recorded Future News) – opis sankcji i kontekstu sprawy Williamsa/Operation Zero. (The Record from Recorded Future)
  2. U.S. Department of the Treasury (OFAC) – komunikat „Treasury Sanctions Exploit Broker Network…”, szczegóły dot. Operation Zero, powiązanych podmiotów i podstawy prawnej. (U.S. Department of the Treasury)
  3. U.S. Department of Justice – komunikat o przyznaniu się Petera Williamsa do winy (kradzież tajemnic i sprzedaż brokerowi z Rosji). (Department of Justice)
  4. TechCrunch – dodatkowe tło dziennikarskie dot. sankcji i brokerów 0-day. (TechCrunch)
  5. Reuters – szerszy kontekst pakietu sankcji cyber i powiązania ze śledztwem. (Reuters)