Gunra ransomware (CISA AA26-222A): co oznacza #StopRansomware dla firm B2B i produkcji oraz jak przygotować się 30/90 dni

13 August 2026 5 min read 1054 words

10 sierpnia 2026 CISA, FBI, DC3, NSA, USSS i KNPA opublikowały wspólny advisory #StopRansomware AA26-222A o rodzinie Gunra — RaaS z wycieku kodu Conti, z wariantami Windows i Linux (do 100 wątków) i podwójnym wymuszeniem. Dla podmiotów NIS2 essential/important to trzy obowiązki: offline niemutowalne backupy, patch znanych luk VPN/RDP oraz raportowanie 24h/72h przez CSIRT NASK. Nie jesteśmy SOC 24/7, nie wydajemy opinii prawnej, nie deklarujemy zgodności NIS2/KSC. Poniżej: fakty vs wnioski, plan 30/90 dni i zakres, w jakim CHORS.NET może pomóc.

Najważniejsze fakty

Źródło i data. Joint Cybersecurity Advisory AA26-222A został opublikowany 10.08.2026 przez CISA, FBI, DC3, NSA, USSS oraz KNPA (Korea National Police Agency). Polska wersja językowa advisory nie istnieje — to anglojęzyczny dokument operacyjny dla specjalistów IR/IT/OT [1][2].
Pochodzenie i taksonomia. Gunra to RaaS wywodzący się z wycieku kodu źródłowego Conti 1. Pierwsze obserwacje rodowodu sięgają kwietnia 2025; od początku 2026 program został sformalizowany i rekrutuje afilianów na dark webowych forach [1][3][5].
Wektory i technika. Wariant Linux pozwala konfigurować liczbę wątków szyfrowania do 100 i wspiera szyfrowanie częściowe; wariant Windows zachowuje tradycyjny model z szybkim masowym szyfrowaniem. Łańcuch infekcji obejmuje exploit znanych podatności w VPN/RDP, lateral movement, eskalację uprawnień i eksfiltrację przed zaszyfrowaniem (double extortion) [3][4][5].
Sektor i geografia. Zgodnie z advisory ofiary obserwowano w Americas, Europa, Middle East, Afryce i Azji-Pacyfiku. Wśród sektorów: healthcare, financial services, critical manufacturing, transport/logistyka, utilities, government services, academia, retail, professional/nonprofit [1][2].
Wczesne publiczne ofiary. Cybercriminals powiązani z Gunra opublikowali 40 TB danych z American Hospital Dubai, w tym rekordy medyczne i dane kart płatniczych; znamiennym przypadkiem jest też deklarowane wycieknięcie 450 mln rekordów pacjentów (w trakcie weryfikacji niezależnej) [3][6].
IOC i TTP. Pełne wskaźniki kompromitacji (IOC) zostały opublikowane w formacie STIX 2.x (XML/JSON) jako załącznik do advisory [1][2].
Rekomendacje CISA. (a) Patch known exploited VPN/RDP vulnerabilities (lista w CISA KEV); (b) offline, immutable backups w segmented location; (c) network segmentation (szczególnie IT/OT); (d) hardening RDP (wyłączenie exposure internetowego, wymuszenie MFA); (e) testy procedury odtworzenia z backupu co najmniej kwartalnie [1][2].
Polska/europejska implikacja NIS2. Podmioty essential/important dotknięte incydentem kwalifikują się do raportowania wg art. 23 NIS2 (24h early warning → 72h notyfikacja → raport końcowy), a ich obowiązki w BCP/DR wynikają z art. 21 ust. 2 lit. c (ciągłość działania) oraz art. 21 ust. 2 lit. d (bezpieczeństwo łańcucha dostaw, w tym ocena dostawców RMM/VPN) [7][8].
Źródła (7). CISA AA26-222A [1], CISA/DOD PDF [2], Trend Micro research [3], DarkReading [4], CSO Online [5], Cybersecuritynews.com [6], EC NIS2 directive page [7], NIS2-templates.com 24h trigger [8].

Uwaga metodologiczna: fakty oznaczone [1][2] pochodzą z oficjalnego advisory (klasa A). Wnioski operacyjne (kontekst NIS2, plan 30/90 dni) są rekomendacjami CHORS, nie częścią advisory. Rekomendacje dla konkretnej firmy wymagają jej własnego kontekstu (segment, dostawcy, ekspozycja) — nie udostępniamy generycznych checklist „dla wszystkich".

Tabela decyzyjna: co wiemy → co to znaczy dla firmy B2B/produkcji → co zrobić

Obszar	Co wiemy (fakty z advisory + research)	Co to oznacza dla firmy B2B / produkcji	Zalecane działanie 30 dni	Zalecane działanie 90 dni
VPN/RDP	CISA wprost wymienia patch known exploited VPN/RDP jako działanie #1 [1][2]	Klienci NIS2 z publicznym RDP/VPN narażeni na initial access RaaS affiliate	Inwentaryzacja publicznie dostępnych RDP/VPN; wyłączenie jeśli nieuzasadnione; MFA dla pozostałych; priorytetowy patch z listy CISA KEV	Testy penetracyjne autoryzowane (Authorized Vulnerability Assessment) i/lub Passive Exposure Snapshot celem wykrycia shadow-VPN/RDP
Backupy	Offline, immutable backups w segmented location [1][2]	Bez tego recovery po zaszyfrowaniu = decyzja „płacić albo przestać istnieć"	Audit 3-2-1 (3 kopie, 2 media, 1 offline/offsite); test odtworzenia jednej pełnej maszyny; immutability (WORM/S3 Object Lock)	Ciągłe testy odtwarzania, automatyzacja RPO/RTO, segmentacja kopii od AD/IDP
Lateral movement / IT-OT	Gunra używa szyfrowania wielowątkowego (do 100) na Windows i Linux [3][4]	Wspólne domeny AD/IdP i segment IT-OT to klasyczny wektor dla producentów	Mapowanie Tier-0/Tier-1/Tier-2; segmentacja VLAN; ograniczenie kont serwisowych do PAW; monitorowanie nietypowych zdalnych sesji	Pełny model Purdue + wdrożenie jump-host; passive monitoring na granicy IT/OT (bez aktywnego skanowania OT)
Łańcuch dostaw IT	Afilianci atakują dostawców RMM/VPN/IT-services [1][3]	Dla producentów korzystających z MSP lub współdzielących admin-tools to wektor pośredni	Inwentaryzacja dostawców z dostępem do AD/IdP/VPN; przegląd umów pod kątem obowiązków bezpieczeństwa; rotacja poświadczeń	Wdrożenie Vendor Risk Management zgodnie z P3 NIS2/KSC Readiness (art. 21 ust. 2 lit. d); okresowe audyty dostawców
Raportowanie NIS2 (art. 23)	24h early warning od momentu „uświadomienia sobie" potencjalnego incydentu; 72h notyfikacja [7][8]	Bindowanie 24h zaczyna się bardzo wcześnie; brak procedury = opóźnienie + utrata zaufania regulatora	Opracowanie/odświeżenie playbooku incydentowego; wyznaczenie osoby kontaktowej do CSIRT NASK; szablon early-warning	Ćwiczenia tabletop (symulacja ransomware 1× kwartał); ustalone kanały komunikacji (mail + telefon) z CSIRT NASK
Wyciek danych (DLS)	Double extortion: Tor portal negocjacyjny + dedicated leak site [1][3]	Nawet po odtworzeniu z backupu dane mogą być opublikowane; konsekwencje RODO, kary UODO, utrata reputacji	Identyfikacja klasyfikacji danych (w tym dane osobowe, dane wrażliwe); DLP baseline; procedura „gdy DLS publikuje"	DLP rozszerzony; retencja i minimalizacja danych; plan komunikacji kryzysowej do klientów/regulatora
AI-assisted discovery (kontekst)	Wiele rodzin RaaS używa szyfrowania wspomaganego technikami automatyzacji; Gunra kładzie nacisk na szybkość (100 wątków) [3]	Czas od initial access do pełnego szyfrowania jest krótszy niż ludzka reakcja; detekcja musi być automatyczna	Tuning EDR pod TTP z MITRE ATT&CK (TA0008/TA0010); automatyczne odcięcie lateral movement przy alertach	Integracja EDR + SIEM/SOAR; playbooki auto-izolacji hostów; threat hunting kwartalny

Perspektywa inż. Marcina Białczyka (CHORS.NET)

Skala i szybkość to nie są przypadkowe wybory projektantów Gunra — to efekt prostej kalkulacji: ile minut mija od pierwszego zdarzenia lateral movement do momentu, w którym backup nie nadąża z restore, a 100 wątków szyfruje wszystko, co nie jest offline. W mojej praktyce operatorskiej widzę, że organizacje, które nie inwestują w niemutowalne backupy w odseparowanej lokalizacji, de facto podejmują decyzję „zapłacić albo przestać istnieć" na długo przed pierwszym incydentem. Backup, którego nie da się szybko odtworzyć, to nie backup — to archiwum. W benchmarkach, które prowadzę dla klientów, celujemy w pełne odtworzenie pojedynczej maszyny krytycznej (DC/IdP) w <2h i odtworzenie testowe pełnego środowiska co najmniej raz na kwartał. Jeśli tego nie robisz, nie wiesz, czy masz backup — wiesz tylko, że masz jego kopię.

Druga oś, którą traktuję priorytetowo, to ekspozycja VPN/RDP. Joint advisory wprost wskazuje to jako pierwszy punkt, bo afilianci Gunra polują na publicznie dostępne RDP i niezaktualizowane VPN — to nie jest „teoria", to jest codzienność rynku IAB (initial access broker). W ramach Passive Exposure Snapshot (P0) pokazuję klientowi, które ich końcówki i tunele faktycznie „świecą" w OSINT i rejestrach, bez aktywnego kontaktu z infrastrukturą. To ten sam model, który stosujemy przy ocenie dostawców MSP i RMM w P3 NIS2/KSC Readiness. Tam, gdzie widzimy publiczny RDP z 2019-vintage firmware, rekomendacja jest binarna: wyłącz albo przebuduj — nie ma opcji „jeszcze trochę poczekamy".

Trzecia oś, równie ważna dla producentów i integratorów IT/OT, to świadomość, że Gunra ma wariant Linux do 100 wątków. To nie jest „taki sam ransomware tylko na serwery" — to sygnał, że kontenery, hypervisors i bazy danych są dziś w polu zainteresowania afilianci tak samo jak file-server. W moich raportach P2 (On-site / Extended Assessment) traktuję segment IT/OT jako strefę, w której aktywne metody są zakazane (polityka 02 — sekcja 4, stop conditions), ale gdzie pasywne wsparcie dowodowe i hardening konfiguracji są konieczne. Jeśli twoja organizacja ma segment produkcyjny, nie pytaj „czy mamy backupy" — pytaj „czy backupy produkcyjne są niemutowalne i odseparowane od AD". To jest ta różnica, która decyduje o tym, czy wyciek będzie tygodniową przerwą w produkcji, czy utratą zdolności operacyjnej na wiele miesięcy.

(przypadek klienta — np. krótki scenariusz: „Producent z sektora FMCG, 800 stacji roboczych, publiczny RDP 24/7; po konsultacji P0 + P3 w ramach programu gotowości, ekspozycja zamknięta w 18 dni, backup niemutowalny wdrożony w 60 dni; pełne odtworzenie z backupu przetestowane w 92 dni od audytu."). Bez realnego case'a — nie wpisuję.

Najczęściej zadawane pytania

Czy moja firma może zostać bezpośrednio zaatakowana przez Gunra, jeśli nie jest w sektorze rządowym ani infrastruktury krytycznej?

Tak — afilianci Gunra celują multi-sector, w tym w produkcję, logistykę, retail, healthcare, finanse, professional services. Sektor nie jest filtrem; filtrem jest to, czy masz publicznie dostępne VPN/RDP i/lub dostawcę RMM z niezałatanymi podatnościami.

Czy CHORS.NET wystawia certyfikat NIS2 albo deklaruje pełną zgodność po tym artykule?

Nie. CHORS.NET nie certyfikuje NIS2/KSC i nie wydaje samodzielnej opinii prawnej; nie jesteśmy też SOC 24/7 i nie gwarantujemy wykrycia każdego incydentu. Współpracujemy z kancelariami w zakresie interpretacji prawa i wspieramy klientów w P3 NIS2/KSC Readiness (gap assessment, control matrix, evidence pack).

Co konkretnie oznacza „offline, immutable backup w segmented location" w praktyce?

(1) Kopia fizycznie lub logicznie odseparowana od AD/IdP (np. konto serwisowe z minimalnym zakresem, brak dziedziczenia uprawnień); (2) niemutowalność (Object Lock, WORM, write-once media lub air-gapped NAS); (3) test odtworzenia pełnej maszyny krytycznej co najmniej raz na kwartał z mierzonym czasem. Samo posiadanie backupu bez testu odtworzenia jest niewystarczające.

Czy powinienem zgłaszać incydent do CSIRT NASK nawet jeśli mam tylko podejrzenie?

W NIS2 24-godzinny zegar early warning startuje od momentu uświadomienia sobie potencjalnego incydentu — to niski próg. W praktyce oznacza to: jeśli widzisz nietypowe zachowanie (szyfrowanie plików, logowanie z nietypowej lokalizacji, DLS mention), nie czekaj na pełną analizę — wyślij early warning przez formularz CSIRT NASK i uzupełnij w ciągu 72h. Interpretacja prawna wymaga konsultacji z kancelarią.

Co powinienem zrobić natychmiast, jeśli widzę już zaszyfrowane pliki i żądanie okupu?

(1) Odizoluj zaatakowane hosty (odłącz sieć, nie wyłączaj); (2) zabezbier logi (pamięć, dysk, EDR telemetria); (3) powołaj osobę kontaktową i eskalację wewnętrzną; (4) wyślij early warning do CSIRT NASK w 24h; (5) nie płać okupu bez analizy skutków i bez konsultacji z kancelarią oraz odpowiednim organem — w niektórych jurysdykcjach płatność może naruszać sankcje; (6) uruchom plan komunikacji kryzysowej do klientów/partnerów.

Czy CHORS.NET prowadzi „pentesty" albo „testy penetracyjne" jako standardową usługę?

W naszej nomenklaturze (P1 — Authorized Vulnerability Assessment, z komponentem Exposure Validation) prowadzimy autoryzowaną walidację po uzgodnionym zakresie (AtT + RoE + manifest), nigdy bez podpisanego pakietu i capability tokens. Nie używamy pojęcia „pentest" jako nazwy handlowej — to określenie zbyt nieostre w kontekście polityki 02 i zakazów (exploitacja, brute force, DoS, persistence). Pełny zakres możliwości jest opisany w /uslugi/.

Jak CHORS.NET pomaga

CHORS.NET wspiera stronę techniczno-operacyjną: pasywna ocena ekspozycji, weryfikacja konfiguracji, Evidence Pack i przygotowanie do NIS2/KSC. Zobacz: Usługi, Jak pracuje CHORS.NET, NIS2/KSC Readiness Center oraz Polityka AI.

Granice i założenia

Nie jesteśmy SOC 24/7 i nie gwarantujemy wykrycia każdego incydentu. Artykuł opisuje klasę ryzyka i ogólne ramy — nie jest usługą detekcyjną.
Nie certyfikujemy zgodności z NIS2/KSC i nie wydajemy samodzielnej opinii prawnej. W zakresie interpretacji prawa współpracujemy z kancelariami.
Wyniki dotyczą stanu na 2026-08-10. Rodziny ransomware ewoluują (warianty Linux/Windows, TTP, IOCs); rekomendacje wymagają cyklicznego przeglądu co najmniej kwartalnie.
Nie udostępniamy generycznych checklist „dla wszystkich". Każdy plan 30/90 dni wymaga kontekstu konkretnej firmy: segmenty NIS2, ekspozycja (publiczny RDP/VPN/RMM), dostawcy MSP, klasyfikacja danych, topologia IT/OT.
Artykuł ma charakter informacyjny i techniczny. Nie stanowi porady prawnej ani rekomendacji inwestycyjnej.
Przy interpretacji przepisów NIS2/KSC (art. 21, art. 23) sięgamy do kancelarii. Powyższe odwołania do artykułów mają charakter ramowy i wymagają weryfikacji prawnej w konkretnym stanie faktycznym.
W obszarze OT/ICS stosujemy podejście pasywne. Nie prowadzimy aktywnego skanowania PLC/HMI/SCADA; nasze wsparcie P2 ma charakter pasywnego wsparcia dowodowego i hardening konfiguracji.

Precyzyjna wiedza
o ciemnych systemach.