Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 376 z 487

DynoWiper: nowy wiper użyty w nieudanej próbie sabotażu polskiego sektora energii (Sandworm)

Wprowadzenie do problemu / definicja luki

Pod koniec grudnia 2025 r. odnotowano skoordynowaną próbę ataku na polski sektor energetyczny, w której wykorzystano destrukcyjne złośliwe oprogramowanie typu wiper (malware do trwałego niszczenia danych). Według ustaleń ESET oraz relacji medialnych, atak był nieudany – nie ma dowodów na skuteczne zakłócenie działania infrastruktury.

W tym przypadku kluczowe jest to, że mówimy o klasie incydentów nastawionych nie na kradzież danych czy okup (ransomware), ale na szybkie unieruchomienie systemów poprzez kasowanie/niszczenie plików oraz potencjalne utrudnienie odtworzenia środowiska.


W skrócie

  • Atak miał miejsce 29–30 grudnia 2025 r. i obejmował m.in. dwie elektrociepłownie (CHP) oraz system wspierający zarządzanie energią z OZE (np. wiatr i fotowoltaika).
  • ESET przeanalizował próbkę nowego wipera, nadając mu nazwę DynoWiper (detekcja: Win32/KillFiles.NMO).
  • Atrybucja do grupy Sandworm (powiązanej z rosyjskim GRU) ma według ESET „średni” poziom pewności i opiera się na nakładaniu się TTP oraz podobieństwach do wcześniejszych aktywności destrukcyjnych.
  • Kontekst historyczny jest istotny: Sandworm ma udokumentowaną historię operacji destrukcyjnych, w tym kampanii przeciw energetyce.

Kontekst / historia / powiązania

Sandworm to jeden z najbardziej znanych „destrukcyjnych” aktorów APT, wiązany z jednostką GRU 74455 i aktywny co najmniej od 2009 r. W narracji wokół incydentu pojawia się też wymiar symboliczny: ESET zwraca uwagę, że działania zbiegły się z 10. rocznicą głośnego ataku na ukraińską energetykę (2015), który był szeroko opisywany jako przełomowy przykład cyberataku na infrastrukturę krytyczną.

Z perspektywy strategii zagrożeń ważny jest sam wybór celów: połączenie aktywów wytwórczych (CHP) oraz elementów „krwiobiegu” nowoczesnej energetyki – systemów komunikacji i zarządzania generacją rozproszoną (OZE).


Analiza techniczna / szczegóły luki

1) Co wiemy na pewno o DynoWiper

Publicznie udostępnione informacje są na razie dość oszczędne: ESET potwierdza analizę nowego wipera DynoWiper i wskazuje jego charakter destrukcyjny (data-wiping), a także nazwę detekcji Win32/KillFiles.NMO. Reuters i inne media streszczają, że malware miało niszczyć pliki i unieruchamiać systemy.

2) Jak typowo działają wipery w środowiskach IT/OT (użyteczne do obrony)

Ponieważ szczegóły implementacyjne DynoWiper nie zostały szeroko opisane w materiałach publicznych (na dzień publikacji źródeł), warto przełożyć „wiper” na obserwowalne artefakty obronne. W praktyce wipery często realizują część lub całość poniższych działań:

  • masowe usuwanie plików (czasem z użyciem list rozszerzeń/ścieżek) lub ich nadpisywanie,
  • kasowanie kopii zapasowych/Shadow Copies i punktów przywracania,
  • destabilizacja systemu (np. niszczenie konfiguracji, usług, krytycznych katalogów),
  • równoległe użycie narzędzi „living-off-the-land” (np. do dystrybucji w domenie) – szczególnie w kampaniach przypisywanych Sandworm, gdzie destrukcja bywa etapem końcowym po wcześniejszym dostępie i przygotowaniu środowiska. (To jest uogólnienie na bazie znanego profilu grupy w ATT&CK.)

3) Atrybucja: dlaczego Sandworm

ESET komunikuje atrybucję do Sandworm z „medium confidence”, wskazując na silne nakładanie się z wcześniejszymi aktywnościami wiperowymi tej grupy. Z kolei MITRE ATT&CK opisuje Sandworm jako grupę o profilu destrukcyjnym, z historią operacji obejmujących m.in. NotPetya i wcześniejsze kampanie przeciw sektorom państwowym i krytycznym.


Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyko w tym typie incydentu to krótki czas do efektu i wysoki koszt odtwarzania. Nawet jeśli atak nie powoduje natychmiastowego blackoutu, wiper:

  • może zatrzymać procesy biznesowe (OT/IT) przez konieczność odbudowy stacji, serwerów i domeny,
  • utrudniać sterowanie i bilansowanie (szczególnie, gdy celem są elementy komunikacji OZE z operatorami),
  • generować koszty operacyjne i reputacyjne – nawet przy braku fizycznych skutków.

W tym przypadku polskie władze i badacze mówią, że nie doszło do skutecznych zakłóceń, ale sam dobór celów (CHP + zarządzanie OZE) pokazuje, gdzie atakujący mógłby próbować uzyskać efekt „systemowy”.


Rekomendacje operacyjne / co zrobić teraz

Poniższe działania są praktyczne niezależnie od tego, czy DynoWiper pojawi się ponownie (i nawet przy ograniczonej widoczności jego IoC):

  1. Segmentacja IT/OT i kontrola przepływów
  • „Hard separation” krytycznych stref OT (SCADA/EMS/DMS, serwery inżynierskie) od IT; dopuszczaj tylko jawnie dozwolone protokoły i kierunki.
  • Bastionowanie dostępu z MFA i rejestrowaniem sesji.
  1. Wzmocnienie Active Directory i mechanizmów dystrybucji
  • Monitoruj nietypowe użycie GPO, PSExec/WMI/WinRM oraz narzędzi zdalnej administracji.
  • Ogranicz uprawnienia kont serwisowych; wprowadź JIT/JEA dla adminów.
  1. Backupy odporne na wipery
  • Kopie offline/immutable, testowane odtwarzanie (bare metal + AD recovery).
  • Osobne poświadczenia i oddzielona sieć do backupu.
  1. Detekcja behawioralna pod destrukcję
  • Alerty na: gwałtowny wzrost operacji delete/rename, masowe modyfikacje w krótkim oknie czasu, niszczenie kopii zapasowych.
  • Korelacja zdarzeń na hostach pełniących role „przesiadkowe” między IT i OT.
  1. Ćwiczenia IR ukierunkowane na „wiper scenario”
  • Procedury: izolacja segmentów, odcięcie dystrybucji narzędzi, priorytety przywracania (najpierw tożsamość, potem łączność, potem aplikacje).

Różnice / porównania z innymi przypadkami

  • DynoWiper vs klasyczne ransomware: tu celem nie jest monetyzacja, tylko degradacja zdolności operacyjnej. To zmienia priorytety: kluczowe są backupy i odtwarzanie, a nie negocjacje/odszyfrowywanie.
  • DynoWiper vs wcześniejsze operacje Sandworm: publicznie potwierdzony jest przede wszystkim „destrukcyjny DNA” Sandworm i jego historia kampanii o wysokim wpływie (MITRE opisuje m.in. NotPetya i ataki na energetykę). W przypadku DynoWiper na ten moment wiemy mniej o technikaliach, ale atrybucja ESET opiera się na zbieżnościach TTP z wcześniejszymi wiperami.

Podsumowanie / kluczowe wnioski

DynoWiper jest kolejnym sygnałem, że destrukcyjne operacje cybernetyczne nie są „historią z 2015 roku”, tylko realnym scenariuszem dla współczesnej energetyki – zwłaszcza w kontekście systemów hybrydowych łączących konwencjonalne źródła z OZE.

Najważniejsze na dziś:

  • traktuj wiper jako scenariusz „fast impact” (minuty–godziny),
  • inwestuj w odporność odtwarzania i segmentację,
  • buduj detekcję behawioralną pod masowe niszczenie danych,
  • ćwicz IR pod operacje destrukcyjne, nie tylko pod wycieki.

Źródła / bibliografia

  1. ESET Research – Sandworm behind cyberattack on Poland’s power grid in late 2025 (welivesecurity.com)
  2. The Hacker News – New DynoWiper Malware Used in Attempted Sandworm Attack on Polish Power Sector (The Hacker News)
  3. Reuters – raport o atrybucji i kontekście ataku (Reuters)
  4. TechCrunch – opis celu i kontekstu ataku (CHP + łączność OZE) (TechCrunch)
  5. MITRE ATT&CK – profil grupy Sandworm (G0034) (attack.mitre.org)

CISA dopisuje 4 podatności do KEV: Zimbra, Versa Concerto, Vite i eslint-config-prettier – aktywna eksploatacja i termin działań do 12.02.2026

Wprowadzenie do problemu / definicja luki

Katalog Known Exploited Vulnerabilities (KEV) prowadzony przez CISA to lista podatności, dla których istnieją dowody realnej eksploatacji “in the wild”. Trafienie CVE do KEV w praktyce podnosi priorytet obsługi incydentów i zarządzania łatami: oznacza, że luka nie jest tylko teoretyczna, ale jest (lub była) używana przez atakujących.

W aktualizacji z 22 stycznia 2026 r. dopisano cztery pozycje, z terminem działań do 12 lutego 2026 r. (wymóg dotyczy agencji FCEB w USA, ale rekomendacje są uniwersalne dla wszystkich organizacji).


W skrócie

Do KEV (data dodania: 2026-01-22) trafiły:

  • CVE-2025-68645 – Zimbra Collaboration (ZCS): podatność typu Local File Inclusion (LFI) w Webmail Classic UI przez endpoint /h/rest (bez uwierzytelnienia), oceniana m.in. na 8.8 (HIGH).
  • CVE-2025-34026 – Versa Concerto SD-WAN: authentication bypass związany z konfiguracją Traefik reverse proxy; możliwy dostęp do endpointów administracyjnych oraz m.in. heap dumpów/trace logów (CVSS v4: 9.2 CRITICAL wg CNA).
  • CVE-2025-31125 – Vite (vitejs): obejście kontroli dostępu ujawniające treści plików przez parametry ?inline&import lub ?raw?import – istotne głównie, gdy dev server jest wystawiony na sieć.
  • CVE-2025-54313 – eslint-config-prettier: złośliwy kod w wybranych wersjach paczki npm (supply chain) – uruchomienie install.js i załadowanie node-gyp.dll na Windows.

Wspólny wymóg KEV: wdrożyć mitygacje wg dostawcy / wytycznych lub zaprzestać używania, jeśli nie ma skutecznej mitygacji; termin w KEV: 2026-02-12.


Kontekst / historia / powiązania

Ten zestaw CVE jest ciekawy, bo łączy klasyczne podatności aplikacyjne (Zimbra), podatność w platformie orkiestracji (SD-WAN) (Versa), ryzyko wynikające z błędnej ekspozycji narzędzi deweloperskich (Vite) oraz incydent łańcucha dostaw (eslint-config-prettier).

W praktyce oznacza to, że eksploatacja dotyczy zarówno infrastruktury komunikacyjnej (poczta), sieci/SD-WAN, jak i ekosystemu developer tooling oraz zależności npm.


Analiza techniczna / szczegóły luki

CVE-2025-68645 (Zimbra ZCS) – LFI przez /h/rest

NVD opisuje lukę jako Local File Inclusion spowodowaną niewłaściwą obsługą parametrów w serwlecie RestFilter. Atakujący zdalnie, bez logowania, może manipulować dispatchingiem żądań do endpointu /h/rest, co umożliwia dołączanie plików z katalogu WebRoot do odpowiedzi.
W kontekście poczty oznacza to ryzyko ujawnienia wrażliwych plików (konfiguracje, zasoby aplikacji), a w części scenariuszy bywa to etapem do dalszych działań (np. przygotowania kolejnego łańcucha exploitów).

CVE-2025-34026 (Versa Concerto) – obejście uwierzytelnienia

Podatność to authentication bypass w obszarze Traefik reverse proxy, umożliwiający dostęp do endpointów administracyjnych; NVD wskazuje także możliwość użycia wewnętrznego endpointu Actuator do pozyskania m.in. heap dumpów i logów śledzenia. Zakres znanych podatnych wersji: 12.1.2 – 12.2.0 (mogą istnieć kolejne).
To szczególnie groźne w środowiskach, gdzie Concerto jest “mózgiem” zarządzania SD-WAN – kompromitacja takiej warstwy zwykle ma efekt kaskadowy.

CVE-2025-31125 (Vite) – ujawnienie plików w dev server

Vite może ujawnić zawartość plików, które powinny być zablokowane, poprzez użycie parametrów ?inline&import albo ?raw?import. Kluczowe ograniczenie z opisu: zagrożone są głównie aplikacje, które jawnie wystawiły dev server na sieć (np. --host / server.host). Luka ma poprawki w wielu liniach wydań (m.in. 6.2.4, 6.1.3, 6.0.13, 5.4.16, 4.5.11).
Uwaga praktyczna: w NVD widać rozbieżność oceny CVSS między NIST i CNA (GitHub) – co często wynika z innego podejścia do preconditionów (interakcja użytkownika / ekspozycja na sieć). Do KEV trafiają jednak przypadki rzeczywiście wykorzystywane, więc priorytet powinien wynikać z ekspozycji i telemetryki, a nie samej liczby.

CVE-2025-54313 (eslint-config-prettier) – supply chain i malware na Windows

To nie “zwykła luka”, tylko złośliwy kod osadzony w konkretnych wersjach pakietu: 8.10.1, 9.1.1, 10.1.6, 10.1.7. Instalacja uruchamia install.js, który na Windows ładuje node-gyp.dll (malware).
W praktyce jest to ryzyko dla pipeline’ów CI/CD i stacji deweloperskich, zwłaszcza gdy zależności są pobierane bez pinowania i bez weryfikacji integralności.


Praktyczne konsekwencje / ryzyko

  • Zimbra: możliwy wyciek danych i informacji konfiguracyjnych z serwera pocztowego, co może wspierać dalszą eskalację lub ruch boczny.
  • Versa Concerto: ryzyko przejęcia kontroli nad warstwą orkiestracji SD-WAN; potencjalnie wpływ na wiele lokalizacji jednocześnie oraz na widoczność/telemetrię sieci.
  • Vite: wyciek plików (np. .env, klucze, konfiguracje) w scenariuszach, gdzie dev server został nieintencjonalnie wystawiony na Internet lub do segmentu o niskim zaufaniu.
  • eslint-config-prettier: kompromitacja łańcucha dostaw – w najgorszym wypadku kradzież sekretów, tokenów i dalsze skażenie buildów (szczególnie dotkliwe w organizacjach software’owych).

Rekomendacje operacyjne / co zrobić teraz

Priorytet 0: identyfikacja ekspozycji i szybka redukcja powierzchni ataku (≤24h)

  1. Sprawdź, czy w organizacji występują: Zimbra ZCS 10.0/10.1, Versa Concerto 12.1.2–12.2.0, Vite w podatnych wersjach, oraz czy w zależnościach npm pojawiają się wskazane wersje eslint-config-prettier.
  2. Jeśli nie ma natychmiastowej mitygacji – zgodnie z wpisem KEV rozważ czasowe wyłączenie/usunięcie komponentu z ekspozycji.

Priorytet 1: naprawa / aktualizacja (≤72h)

  • Zimbra: aktualizuj do wersji naprawionych (co najmniej 10.0.18+ lub 10.1.13+, zgodnie z zakresem CPE w NVD) i ogranicz publiczną ekspozycję, jeśli to możliwe.
  • Versa Concerto: zastosuj mitygacje i aktualizacje wg zaleceń dostawcy; minimalnie usuń ekspozycję paneli/endpointów administracyjnych z niezaufanych sieci i zweryfikuj, czy nie ma dostępu do Actuator/diagnostyki.
  • Vite: aktualizacja do wersji naprawionych (właściwa linia wydań), a dodatkowo twarda zasada: dev server nie może być wystawiony na Internet; ogranicz --host, segmentuj sieć, stosuj allowlisty i reverse proxy tylko w razie konieczności.
  • eslint-config-prettier: usuń/podmień skompromitowane wersje, wymuś pinowanie wersji, sprawdź lockfile, a w środowiskach Windows potraktuj to jak potencjalny incydent (triage hostów, weryfikacja procesów instalacji, rotacja sekretów zależnie od ekspozycji).

Priorytet 2: detekcja i hunting (≤7 dni)

  • Przejrzyj logi WAF/reverse proxy i logi aplikacyjne pod kątem nietypowych żądań do /h/rest (Zimbra) oraz podejrzanych wywołań endpointów administracyjnych/diagnostycznych (Versa).
  • Zidentyfikuj repozytoria i pipeline’y, które mogły pobrać skompromitowane wersje eslint-config-prettier, i sprawdź artefakty buildów z okresu użycia.

Deadline (KEV): 12.02.2026 – to data egzekwowana dla FCEB, ale warto przyjąć ją jako wewnętrzny SLA dla systemów internet-facing i krytycznych.


Różnice / porównania z innymi przypadkami

  • Zimbra (LFI/RFI): klasyczny wektor webowy, często łatwy do masowego skanowania; ryzyko rośnie, gdy serwer jest publicznie wystawiony.
  • Versa (auth bypass w warstwie orkiestracji): mniej “głośny” niż typowe RCE, ale potencjalnie bardziej systemowy – dostęp do orkiestratora bywa równoważny dostępowi do dużej części sieci.
  • Vite (dev tooling): ryzyko jest często “organizacyjne” (błędna ekspozycja), a nie czysto produktowe – to sygnał, by wzmacniać standardy uruchomień dev/prod.
  • eslint-config-prettier (supply chain): incydent zależności – wymaga dojrzałości w SBOM, pinowaniu, kontroli integralności i reakcji na skażone paczki.

Podsumowanie / kluczowe wnioski

  1. Cztery CVE dodane do KEV 22.01.2026 obejmują bardzo różne klasy ryzyka – od podatności webowych po supply chain.
  2. Wpis do KEV oznacza praktyczną eksploatację, więc priorytet powinien być wysoki niezależnie od sporów wokół CVSS (szczególnie widocznych przy Vite).
  3. Minimalny standard reakcji: patch/mitygacja lub wyłączenie produktu tam, gdzie nie da się szybko zabezpieczyć – z celem operacyjnym do 12.02.2026.

Źródła / bibliografia

  • NVD: CVE-2025-68645 (Zimbra ZCS /h/rest, KEV update) (nvd.nist.gov)
  • NVD: CVE-2025-34026 (Versa Concerto auth bypass, KEV update, CVSS) (nvd.nist.gov)
  • NVD: CVE-2025-31125 (Vite, parametry inline/raw/import, KEV update, fixed versions) (nvd.nist.gov)
  • NVD: CVE-2025-54313 (eslint-config-prettier, złośliwe wersje, node-gyp.dll, KEV update) (nvd.nist.gov)

Pwn2Own Automotive 2026: 76 unikatowych 0-day i ponad 1,0 mln USD nagród. Fuzzware.io zgarnia tytuł Master of Pwn

Wprowadzenie do problemu / definicja luki

Pwn2Own Automotive to konkurs „ofensywnej weryfikacji bezpieczeństwa”, w którym zespoły badawcze demonstrują działające łańcuchy exploitów przeciw realnym komponentom ekosystemu automotive: systemom IVI (in-vehicle infotainment), systemom operacyjnym oraz infrastrukturze ładowania EV. Kluczowy element to 0-day – podatność nieznana publicznie i niewydana jeszcze w formie łatki w momencie demonstracji (część prób może też obejmować tzw. n-day, czyli znane już błędy). Wszystkie błędy trafiają do dostawców w trybie skoordynowanego ujawnienia przez ZDI.

W edycji 2026 stawka była wyjątkowo praktyczna: obok klasycznych celów automotive, mocno wybrzmiał temat EVSE (ładowarki) jako „kolejnego komputera w sieci” – z protokołami, zdalnym zarządzaniem, aktualizacjami i realnym wpływem na zachowanie procesu ładowania.


W skrócie

  • Przez 3 dni przyznano 1 047 000 USD za 76 unikatowych 0-day.
  • Master of Pwn zdobyło Fuzzware.io (Tobias Scharnowski, Felix Buchmann, Kristian Covic): 28 punktów i 215 500 USD.
  • Po dniu 1: 516 500 USD i 37 unikatowych 0-day.
  • Po dniu 2: +439 250 USD i 29 unikatowych 0-day (łącznie 955 750 USD i 66).
  • Dzień 3 domknął konkurs do 76 – co oznacza +10 unikatowych 0-day względem stanu po dniu 2 (wyliczenie na podstawie oficjalnych sum).

Kontekst / historia / powiązania

Pwn2Own w wydaniu automotive to odpowiedź na transformację branży w stronę software-defined vehicle: więcej kodu, więcej integracji, więcej powierzchni ataku. ZDI podkreśla, że o zwycięstwie w Master of Pwn decydują punkty za udane demonstracje (nie tylko wysokość nagród), a kolejność prób jest losowana — więc można wygrać „konsekwencją” i szerokim pokryciem celów.

W 2026 po raz kolejny mocno wybrzmiał motyw „zderzeń” (collisions): jeśli ktoś demonstruje podatność już wykorzystaną wcześniej w konkursie, nagroda i/lub punkty są istotnie mniejsze, ale sama demonstracja nadal ma wartość (potwierdza problem i presję na dostawcę).


Analiza techniczna / szczegóły luki

Z perspektywy inżynierii bezpieczeństwa najciekawsze jest nie „kto wygrał”, tylko jakie klasy błędów powtarzają się w automotive/EVSE.

1) IVI: klasyka podatności pamięci i błędy logiki

W samym dniu 3 pojawiają się m.in.:

  • Stack-based buffer overflow (np. przeciw Alpine iLX-F511)
  • Heap-based buffer overflow prowadzący do arbitralnego wykonania kodu (Sony XAV-9500ES)
  • Race condition i błędne uprawnienia jako elementy łańcucha (Kenwood)

To wzorzec typowy dla urządzeń wbudowanych: „pamięć + uprawnienia + wyścigi/symlinki” = łatwa eskalacja w środowiskach, gdzie procesy często działają z podwyższonymi uprawnieniami lub mają szeroki dostęp do zasobów.

2) EVSE: łańcuchy podatności, manipulacja sygnałem i TOCTOU

W dzień 1 i 2 widać wyraźnie, że ładowarki to nie tylko „RCE na urządzeniu”, ale również elementy pozwalające wpływać na logikę ładowania:

  • Fuzzware.io łączyło podatności, by uzyskać wykonanie kodu i manipulować sygnałem ładowania (w kontekście dodatków/bonusów konkursowych).
  • W dzień 3 Juurin Oy wykorzystało błąd TOCTOU w Alpitronic HYC50 (w relacji ZDI wprost nazwany TOCTOU) – pokazując, że błędy wyścigu/czasu wciąż są krytyczne w systemach przemysłowo-motoryzacyjnych.

3) „N-day”, twardo zakodowane dane i komendy

W relacjach ZDI przewijają się również błędy „mniej sexy, bardziej realne”:

  • Hardcoded credential (CWE-798), command injection, bypass uwierzytelnienia — typowo wynikające z pośpiechu integracyjnego i „serwisowych” interfejsów pozostawionych w produkcji.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko łańcuchowe w łańcuchu dostaw: IVI i EVSE to układanka wielu dostawców (SoC, middleware, web UI, biblioteki). Jedna klasa błędu (np. overflow) może występować w wielu wariantach produktu.
  2. EVSE jako cel infrastrukturalny: kompromitacja ładowarki to potencjalnie:
  • punkt wejścia do sieci operatora (zdalne zarządzanie, serwis),
  • manipulacja procesem ładowania (integralność i bezpieczeństwo operacyjne),
  • ryzyko masowe (flota urządzeń o wspólnym firmware).
  1. Presja czasowa na poprawki: ZDI raportuje błędy do dostawców, a publiczne ujawnienie jest opóźnione, by dać czas na patching. Dla obrońców oznacza to okno, w którym „wiemy, że coś jest”, ale nie zawsze mamy jeszcze CVE i patch.

Rekomendacje operacyjne / co zrobić teraz

Dla producentów OEM / dostawców IVI i ECU

  • Wzmocnij pipeline pod kątem klas błędów dominujących w konkursie: fuzzing interfejsów parsujących dane, sanitizery, testy regresji pod overflow / OOB / race / symlink.
  • Przejrzyj „serwisowe” ścieżki: komendy, debug, endpoints, domyślne hasła — bo w relacjach wprost pojawiają się command injection i hardcoded credential.
  • Zaplanuj aktualizacje „na twardo”: podpisywanie aktualizacji, weryfikacja integralności, ograniczenie uprawnień procesów i segmentacja komponentów (żeby pojedynczy błąd nie dawał od razu roota).

Dla operatorów EVSE / zespołów infrastruktury

  • Traktuj ładowarki jak OT/IoT: segmentacja sieci, egress control, monitoring anomalii i twarde polityki zdalnego zarządzania.
  • Wymuś higienę tożsamości: rotacja sekretów, brak domyślnych kont, ograniczenie dostępu serwisowego.

Dla SOC/CSIRT

  • Ustaw czujność na publikacje ZDI po okresie embargo (gdy ruszą advisories/patch notes) i przygotuj playbook „szybkiego triage” dla IVI/EVSE w organizacji.

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

W porównaniu do „klasycznych” edycji Pwn2Own (przeglądarki, OS-y), automotive wnosi dwie praktyczne różnice:

  1. Dodatki/bonusy (np. związane z osiągnięciem określonego efektu jak manipulacja sygnałem, utrzymanie persystencji itp.) zmieniają optymalizację ataków: liczy się nie tylko RCE, ale też impact.
  2. Collisions są szczególnie pouczające dla obrońców: skoro różne zespoły wpadają na te same miejsca, prawdopodobnie mamy do czynienia z „gorącymi punktami” architektury (wspólne biblioteki, te same warstwy integracji).

Podsumowanie / kluczowe wnioski

  • Pwn2Own Automotive 2026 pokazało skalę problemu: 76 unikatowych 0-day i ponad 1,0 mln USD w nagrodach w trzy dni.
  • Fuzzware.io dowiozło zwycięstwo dzięki szerokiemu pokryciu celów i punktów: 28 pkt oraz 215 500 USD.
  • Najważniejszy sygnał dla rynku: EVSE stało się pełnoprawną powierzchnią ataku, a klasyczne błędy (overflow, command injection, race/TOCTOU, złe uprawnienia) nadal występują w krytycznych komponentach.

Na poziomie strategii bezpieczeństwa to argument za tym, by łączyć secure-by-design (architektura, uprawnienia, aktualizacje) z secure-by-testing (fuzzing, sanitizery, testy łańcuchów). Konkursy takie jak Pwn2Own brutalnie weryfikują, co „przechodzi” w realnym sprzęcie — zanim trafi to w ręce przestępców.


Źródła / bibliografia

  1. ZDI: Pwn2Own Automotive 2026 – Day Three Results and the Master of Pwn (zerodayinitiative.com)
  2. ZDI: Pwn2Own Automotive 2026 – Day Two Results (Zero Day Initiative)
  3. ZDI: Pwn2Own Automotive 2026 – Day One Results (zerodayinitiative.com)
  4. ZDI: Pwn2Own Automotive 2026 Rules (zerodayinitiative.com)
  5. Help Net Security: Tesla, Sony, and Alpine systems compromised on day one… (Help Net Security)

INC Ransomware: błąd OpSec ujawnił infrastrukturę i pozwolił odzyskać dane 12 ofiar w USA

Wprowadzenie do problemu / definicja luki

W ransomware zwykle zakładamy, że po eksfiltracji dane „znikają” w ekosystemie przestępców: trafiają na serwery pośrednie, do chmury, na leak site albo do prywatnych archiwów grupy. Ten przypadek pokazuje, że czasem o losie danych decyduje nie kryptografia, a operacyjna higiena atakujących (OpSec).

W styczniu 2026 r. ujawniono, że błąd OpSec grupy INC Ransomware doprowadził do odsłonięcia długowiecznej infrastruktury przechowującej zaszyfrowane paczki danych wielu ofiar — co finalnie umożliwiło odzyskanie danych skradzionych 12 organizacjom z USA.


W skrócie

  • Punktem startowym było klasyczne IR: wykrycie aktywnego szyfrowania na produkcyjnym SQL Server i analiza próbki wariantu RainINC.
  • Śledczy znaleźli artefakty użycia legalnego narzędzia backupowego restic (m.in. skrypty PowerShell, zmienione nazwy binarek, zmienne repozytorium), mimo że w tej konkretnej intruzji eksfiltracja poszła inną ścieżką.
  • W skrypcie new.ps1 znajdowały się (po dekodowaniu Base64) twardo wpisane parametry do repozytorium restic w S3-kompatybilnym storage (endpoint/bucket/repo) oraz zmienne środowiskowe typu AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, RESTIC_PASSWORD.
  • Kontrolowana enumeracja repozytoriów doprowadziła do identyfikacji zaszyfrowanych danych 12 niepowiązanych ofiar (różne branże), a następnie do ich odszyfrowania i zabezpieczenia we współpracy z organami ścigania.

Kontekst / historia / powiązania

INC Ransomware działa w modelu ransomware-as-a-service (RaaS) co najmniej od 2023 r. i łączy szyfrowanie z presją publikacyjną (double extortion). W przeszłości przypisywano jej ataki na organizacje z różnych krajów i sektorów, a jej operacje często pokazują „enterprise’owy” poziom standaryzacji narzędzi i procedur.

W tym incydencie istotne jest nie „kolejne ransomware”, tylko to, jak atakujący próbowali ukryć eksfiltrację w „normalnym” ruchu operacyjnym. MITRE ATT&CK opisuje ten wzorzec jako eksfiltrację przez usługi webowe / chmurowe (np. obiekty w chmurze), co bywa trudne do odróżnienia od legalnych procesów w organizacji.


Analiza techniczna / szczegóły luki

1) Punkt wejścia w analizę: szyfrowanie i staging w „niewinnej” lokalizacji

W badanej sprawie ładunek ransomware uruchomiono z C:\PerfLogs\win.exe (PerfLogs to katalog domyślnie obecny w Windows i bywa ignorowany). Korelacja TI wskazała na wariant RainINC powiązany z INC.

2) Artefakty restic jako „ślad kampanii”, a nie pojedynczego incydentu

Kluczowy zwrot nastąpił, gdy w środowisku znaleziono pozostałości po restic, mimo że w tej konkretnej intruzji dane miały zostać skopiowane inaczej (np. podczas ruchu bocznego). To zasugerowało, że restic jest elementem powtarzalnego toolchainu INC, wdrażanym selektywnie.

Śledczy odnotowali m.in.:

  • binarkę restic podmienioną nazwą (np. winupdate.exe) i lokowaną w podejrzanych miejscach (np. System32),
  • skrypty PowerShell do uruchamiania backupu,
  • zmienne konfiguracyjne repozytorium i komendy backupu,
  • listy plików sterujące selektywną kradzieżą.

3) „Wpadka” OpSec: twardo wpisane parametry dostępu do S3-kompatybilnego repo

Najbardziej obciążającym artefaktem był new.ps1 z komendami zakodowanymi Base64. Po dekodowaniu ujawniał on schemat uruchomienia restic oraz twardo wpisane dane potrzebne do połączenia z repozytorium w obiektowej chmurze (S3-kompatybilny endpoint), w tym RESTIC_REPOSITORY i RESTIC_PASSWORD oraz klucze w stylu AWS.

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

  1. Restic szyfruje dane po stronie klienta i przechowuje je w repozytorium jako nieczytelne obiekty — więc przejęcie „gołych” blobów nic nie daje bez poprawnej konfiguracji.
  2. Skrypt pozostawił wystarczająco dużo „kontekstu”, by badacze mogli bez destrukcyjnych działań enumerować snapshoty repozytoriów (w logice restic, a nie w logice samego S3) i zidentyfikować dane wielu ofiar.

4) Efekt: repozytoria jako długowieczna „hurtownia” łupów

Hipoteza okazała się trafna: infrastruktura restic/S3 była najwyraźniej wielokrotnie używana i nie została zdemontowana po zakończeniu negocjacji z pojedynczą ofiarą. Enumeracja wykazała zaszyfrowane dane 12 niepowiązanych podmiotów (m.in. healthcare, manufacturing, tech, usługi profesjonalne).


Praktyczne konsekwencje / ryzyko

  • Dla ofiar: nawet jeśli incydent jest „zamknięty” (negocjacje, płatność lub brak płatności), dane mogą dalej zalegać w infrastrukturze atakujących — czasem dłużej, niż wszyscy zakładają.
  • Dla obrońców: legalne narzędzia (backup, synchronizacja, zdalna administracja) coraz częściej stają się bronią. Ruch wygląda jak „normalny”, a eksfiltracja do chmury wpisuje się w znane taktyki ATT&CK.
  • Dla IR/DFIR: artefakty z „nieużytego” narzędzia mogą być cenniejsze niż sama próbka ransomware — bo prowadzą do infrastruktury i metod operacyjnych.

Rekomendacje operacyjne / co zrobić teraz

1) Threat hunting: gdzie patrzeć (konkretne tropy)

  • Telemetria procesów/EDR pod kątem uruchomień z nietypowych lokalizacji: C:\PerfLogs\ oraz „binarki systemowe” uruchamiane z katalogów stagingowych.
  • Wykrywanie restic i „podszywek” typu winupdate.exe, zwłaszcza gdy:
    • binarka pojawia się w System32 lub innych wrażliwych ścieżkach,
    • wykonywana jest z parametrami backupu --files-from (selektywna kradzież).
  • PowerShell: alerty na Base64 w poleceniach oraz skrypty ustawiające zmienne środowiskowe AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, RESTIC_REPOSITORY, RESTIC_PASSWORD.

2) Kontrola egress i chmury

  • Ogranicz/monitoruj ruch do S3-kompatybilnych endpointów (nie tylko „AWS proper”), zwłaszcza z serwerów, które nie powinny wykonywać backupów do Internetu.
  • Wprowadź allow-listę domen/IP dla backupów i wymuś identyfikację aplikacji (proxy/NGFW) — „backupowy” ruch z nietypowego procesu to sygnał ostrzegawczy.

3) Gotowość na ransomware: procedury i odporność

  • Uporządkuj plan reakcji (izolacja, triage, polowanie na lateral movement, analiza danych wrażliwych) według checklist i dobrych praktyk dla ransomware.
  • Zadbaj o kopie zapasowe odporne na sabotaż (immutability/offline), regularne testy odtwarzania i segmentację uprawnień do repozytoriów backupowych.

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

W wielu kampaniach ransomware spotyka się narzędzia „living off the land” (legalne, powszechne w IT), ale ten przypadek wyróżnia się tym, że:

  • restic nie był tylko „narzędziem do kradzieży”, ale też standardowym elementem infrastruktury, potencjalnie współdzielonym między kampaniami,
  • błąd OpSec polegał na pozostawieniu artefaktów umożliwiających rekonstrukcję sposobu dostępu do repozytoriów (a nie na „dziurze” w chmurze),
  • skala odzysku danych (wielu niepowiązanych poszkodowanych) jest rzadkością w realnych sprawach ransomware.

Podsumowanie / kluczowe wnioski

  • Najcenniejsze w IR bywa to, co wygląda na „szum”: skrypty, staging, pozostałości po legalnych narzędziach.
  • INC wykorzystało restic i S3-kompatybilny storage do utrzymania zaszyfrowanych łupów w sposób przypominający legalne backupy — ale ich OpSec nie dowiózł.
  • Dla obrony oznacza to jedno: jeśli polujesz na ransomware, poluj też na „backup-like exfiltration” i na wszelkie anomalie wokół narzędzi kopii zapasowych, PowerShell oraz ruchu do chmury.

Źródła / bibliografia

  1. BleepingComputer — „INC ransomware opsec fail allowed data recovery for 12 US orgs” (22 stycznia 2026). (BleepingComputer)
  2. Cyber Centaurs — „When Ransomware Makes a Mistake Inside INC Ransomware’s Backup Infrastructure” (22 stycznia 2026). (Digital Forensics & Data Breach Services)
  3. restic docs — „Preparing a new repository” (S3 i backendy S3-kompatybilne). (restic.readthedocs.io)
  4. MITRE ATT&CK — T1567 / T1567.002 (Exfiltration Over Web Service / Exfiltration to Cloud Storage). (attack.mitre.org)
  5. CISA — #StopRansomware Guide / ransomware response resources. (CISA)

Okta SSO na celowniku: vishing + „real-time” phishing kits kradną dane z firmowych usług

Wprowadzenie do problemu / definicja luki

Okta ostrzega przed kampaniami, w których klasyczne socjotechniki telefoniczne (vishing) łączą się z „adversary-in-the-middle” (AitM) – czyli phishingiem pośredniczącym, zdolnym przechwytywać loginy oraz kody MFA w trakcie prawdziwego logowania. W praktyce nie chodzi o pojedynczą „lukę” w oprogramowaniu, tylko o uprzemysłowiony model kradzieży tożsamości: rozmowa telefoniczna + strona phishingowa sterowana w czasie rzeczywistym.


W skrócie

  • Ataki startują od telefonu od „IT/Helpdesku” i pretekstu (np. pomoc przy konfiguracji passkeys).
  • Ofiara trafia na spersonalizowaną stronę AitM, a treść tej strony może być zmieniana na żywo tak, by pasowała do „scenariusza” rozmowy i aktualnego wyzwania MFA.
  • Dane logowania (oraz kody TOTP/OTP) są przechwytywane, a napastnik po wejściu do Okta SSO sprawdza, do jakich aplikacji ma dostęp ofiara i rozpoczyna eksfiltrację danych (np. z CRM).
  • Okta podkreśla, że MFA z „number matching” nie jest phishing-resistant, jeśli atakujący prowadzi użytkownika przez telefon.

Kontekst / historia / powiązania

To nie jest odosobniony trend. Raporty threat-intel pokazują, że grupy przestępcze coraz częściej monetyzują dostęp poprzez kradzież danych i wymuszenia, bazując na przejęciu tożsamości (IdP/SSO), a nie na „głośnym” malware na stacjach roboczych. Google Threat Intelligence opisywało scenariusze, w których vishing/credential harvesting ułatwia późniejsze „pivoty” na usługi typu Okta czy Microsoft 365.

Równolegle rośnie presja na helpdeski i procesy odzyskiwania dostępu. Okta w innych ostrzeżeniach wskazuje, że przejęcie kont pracowniczych bywa używane do wejścia do systemów HR/finansowych (np. payroll fraud) i do środowisk typu CRM/ITSM.


Analiza techniczna / szczegóły luki

Kluczowym elementem jest „real-time session orchestration” – atakujący ma panel C2, którym steruje tym, co widzi użytkownik w przeglądarce podczas rozmowy telefonicznej. Dzięki temu:

  1. ofiara widzi komunikaty „pasujące” do tego, co mówi rozmówca,
  2. napastnik może w locie dopasować ekran do realnego wyzwania MFA, które właśnie zobaczył po stronie prawdziwego logowania,
  3. przechwycone hasło + jednorazowy kod (OTP/TOTP) pozwalają na natychmiastowe zalogowanie.

Okta opisuje też, że dane wpisane na stronie mogą być automatycznie przekazywane do kanałów operatorów (np. komunikatorów), co skraca czas od „kliknięcia” do przejęcia sesji.

W obserwowanych incydentach (wg doniesień branżowych) po kompromitacji Okta SSO atakujący przeglądali listę aplikacji w dashboardzie i wybierali te, z których najłatwiej eksfiltrować dane (typowo CRM i narzędzia współpracy).


Praktyczne konsekwencje / ryzyko

Najważniejsza zmiana ryzyka polega na tym, że kompromitacja jednego konta SSO:

  • otwiera drogę do wielu usług naraz (poczta, dyski, CRM, narzędzia dev/ops),
  • przyspiesza eksfiltrację (atakujący „poluje” na najbardziej wartościowe aplikacje dostępne z dashboardu),
  • często kończy się wymuszeniem: „zapłać, inaczej publikujemy dane”.

Dodatkowo, jeśli organizacja ma słabe procesy resetu kont / MFA, atak może eskalować „administracyjnie” (np. poprzez podszycie się pod pracownika w rozmowie z helpdeskiem). Tego typu wektory są typowe dla kampanii nastawionych na duże firmy.


Rekomendacje operacyjne / co zrobić teraz

1) Wymuś phishing-resistant MFA (to najważniejsze).
Okta wskazuje na metody odporne na phishing (np. FastPass / FIDO2 / passkeys) jako skuteczną odpowiedź na model „telefon + AitM”.

2) Utwardź procesy helpdesk / odzyskiwania dostępu.
W praktyce: mocniejsza weryfikacja tożsamości, „call-back” na numer z systemu, dodatkowe zatwierdzenia dla resetów MFA i kont uprzywilejowanych. Tego typu procedury są kluczowe przeciw grupom specjalizującym się w socjotechnice helpdeskowej.

3) Ogranicz ryzykowne logowania politykami dostępu.
Okta rekomenduje m.in. kontrolę dostępu po strefach sieciowych/allowlistach (tam, gdzie to realne operacyjnie), by utrudnić logowania z infrastruktury anonimizującej.

4) Monitoring pod kątem „sygnałów przejęcia tożsamości”.
Szukaj anomalii: nietypowe logowania, skoki geolokalizacji/IP, nagłe rejestracje nowych metod MFA, podejrzane działania na aplikacjach wysokiej wartości (CRM/ITSM), nietypowe eksporty danych. (To wprost odpowiada na etap „po zalogowaniu do SSO wybieramy aplikacje do eksfiltracji”).

5) Trening użytkowników, ale z właściwym przekazem.
Tu nie chodzi o „nie klikaj linków” – tylko o zasadę: helpdesk nie prosi o kody MFA/OTP i nie prowadzi użytkownika do „nowego linku logowania” przez telefon.


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

  • Klasyczny phishing: statyczna strona i próba zebrania hasła.
  • AitM bez rozmowy: przechwytuje sesję/OTP, ale często przegrywa na etapie „przekonania” użytkownika do nietypowych akcji.
  • Vishing + AitM (ten przypadek): rozmowa telefoniczna usuwa tarcie decyzyjne, a „real-time” sterowanie stroną sprawia, że nawet bardziej świadomy użytkownik widzi wiarygodny kontekst i „zgodne” komunikaty MFA.

W skrócie: to „phishing, który reaguje” – i dlatego organizacje, które polegają na MFA podatnym na socjotechnikę, są w gorszej sytuacji niż te z phishing-resistant MFA.


Podsumowanie / kluczowe wnioski

Ten wektor ataku pokazuje, że tożsamość (IdP/SSO) jest dziś dla przestępców „punktem centralnym” – przejęcie jednego konta może wystarczyć do kradzieży danych z wielu usług i szybkiego wymuszenia. Najskuteczniejsza obrona to phishing-resistant MFA plus twarde procedury helpdeskowe i monitoring zdarzeń tożsamościowych.


Źródła / bibliografia

  1. BleepingComputer: Okta SSO accounts targeted in vishing-based data theft attacks (BleepingComputer)
  2. Okta Threat Intelligence: Phishing kits adapt to the script of callers (okta.com)
  3. Okta Threat Intelligence: Help desks targeted in social engineering targeting HR applications (okta.com)
  4. Google Cloud Threat Intelligence: The Cost of a Call: From Voice Phishing to Data Extortion (Google Cloud)
  5. Rapid7: Scattered Spider – insights, observations, and recommendations (Rapid7)

Nowy ransomware Osiris: BYOVD z użyciem sterownika POORTRY i ślady powiązań z INC

Wprowadzenie do problemu / definicja luki

W styczniu 2026 r. badacze Symantec i Carbon Black Threat Hunter Team opisali nową rodzinę ransomware nazwaną Osiris, używaną w ukierunkowanym ataku na dużego operatora franczyz gastronomicznych w Azji Południowo-Wschodniej (incydent miał miejsce w listopadzie 2025).

Kluczowym elementem kampanii było rozbrojenie zabezpieczeń poprzez technikę BYOVD (Bring Your Own Vulnerable Driver) – w tym przypadku z użyciem sterownika POORTRY, który służy do eskalacji uprawnień i ubijania procesów bezpieczeństwa.


W skrócie

  • Nowa rodzina ransomware: Osiris to nowy szczep (bez potwierdzonych powiązań kodowych z dawnym „Osiris” z 2016 r.).
  • Model ataku: najpierw eksfiltracja danych (Rclone → Wasabi), potem szyfrowanie.
  • Evasion/EDR kill: sterownik POORTRY + narzędzie KillAV i zestaw narzędzi dual-use/LoTL.
  • Możliwe tropy do INC: zbieżności operacyjne (m.in. Wasabi i Mimikatz jako kaz.exe).

Kontekst / historia / powiązania

Nazwa „Osiris” może mylić: istniał ransomware o tej nazwie kojarzony z ekosystemem Locky (2016), ale Symantec podkreśla, że w obecnym przypadku nie ma przesłanek o powiązaniu między rodzinami.

Ciekawsze są natomiast powiązania taktyczne z grupą INC ransomware (Warble): w opisywanym incydencie zaobserwowano eksfiltrację do Wasabi buckets oraz użycie Mimikatz pod nazwą kaz.exe, co wcześniej wiązano z aktywnością INC.

Warto też pamiętać, że POORTRY (znany też jako BURNTCIGAR) ma historię użycia przez różne gangi ransomware i był rozwijany w sposób nastawiony na skuteczne „wyłączanie” EDR.


Analiza techniczna / szczegóły luki

1) Sekwencja działań (kill chain)

Z opisu incydentu wynika dość „klasyczny” schemat nowoczesnego ransomware, ale z mocnym naciskiem na obronę przed EDR:

  1. Wczesna aktywność i rekonesans + narzędzia dual-use/LoTL.
  2. Eksfiltracja danych: wykorzystanie Rclone do wysyłki do chmury Wasabi (kilka dni przed szyfrowaniem).
  3. Utrzymanie/zdalny dostęp: m.in. zmodyfikowany RustDesk (w kampanii opisywany jako wariant/instalacja „podszyta” pod legalne narzędzie).
  4. Neutralizacja zabezpieczeń: sterownik POORTRY (w kontekście BYOVD) oraz użycie KillAV i włączenie RDP jako kanału dostępu.
  5. Szyfrowanie + notatka okupu: pliki otrzymują rozszerzenie .Osiris, kasowane są migawki VSS.

2) POORTRY/BYOVD w praktyce

W klasycznym BYOVD atakujący „przynoszą” legalny, ale podatny sterownik i nadużywają jego funkcji do działań w jądrze. W tym przypadku Symantec zwraca uwagę, że POORTRY jest nietypowy, bo to sterownik „szyty” pod ubijanie narzędzi bezpieczeństwa, a nie tylko nadużycie cudzego podatnego drivera.

Dodatkowy kontekst daje Sophos: POORTRY to narzędzie rozwijane latami, a jego autorzy wykorzystywali luki/kruczki procesu zaufania do podpisywania sterowników (w praktyce: gra na granicy zaufania do podpisów, łańcuchów i wyjątków zgodności).

3) Funkcje ransomware Osiris

Symantec opisuje Osiris jako „pełnoprawny” payload ransomware z typowymi funkcjami: zatrzymywanie usług, ubijanie procesów, selektywne szyfrowanie katalogów/rozszerzeń i zrzut notatki okupu.

Istotne detale operacyjne:

  • Osiris ma tryby szyfrowania (m.in. częściowe vs pełne) oraz opcje związane z środowiskami wirtualizacji (Hyper-V).
  • Ma zdefiniowane listy pomijanych rozszerzeń i folderów systemowych, co ogranicza ryzyko „zabicia” systemu zanim skończy się szyfrowanie.
  • Zastosowano hybrydowy schemat kryptograficzny i unikalny klucz per plik; w doniesieniach medialnych doprecyzowano połączenie mechanizmów krzywych eliptycznych z AES-128-CTR oraz optymalizacje wydajnościowe (async I/O).

Praktyczne konsekwencje / ryzyko

  1. Podwójne wymuszenie (double extortion): skoro dane są kradzione przed szyfrowaniem (Rclone → Wasabi), sama odbudowa z kopii może nie zamknąć incydentu — ryzyko wycieku i presji negocjacyjnej zostaje.
  2. EDR pod ostrzałem: użycie sterownika w jądrze do wyłączania ochrony znacząco zwiększa skuteczność ransomware i skraca czas „od wykrycia do szyfrowania”.
  3. Ryzyko powtórzeń TTP: jeśli to faktycznie ewolucja/odprysk ekosystemu INC (albo naśladownictwo), zespoły IR mogą spodziewać się podobnych wzorców: eksfiltracja do Wasabi, kaz.exe, zestaw narzędzi sieciowych i zdalnego dostępu.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (0–72h)

  • Polowanie na Rclone: uruchomienia, zadania zaplanowane, nietypowe transfery do chmury oraz artefakty konfiguracji (szczególnie kierunek: Wasabi).
  • Telemetria sterowników: korelacja zdarzeń ładowania driverów + alerty na nietypowe/podejrzane sterowniki w środowisku (w tym POORTRY).
  • Hunting na „kaz.exe” i narzędzia dual-use: wykrywanie nietypowych uruchomień Mimikatz/LSASS access oraz narzędzi rozpoznania i lateral movement (w raporcie wymieniono m.in. Netscan/Netexec/MeshAgent).
  • Weryfikacja RustDesk: jeśli w organizacji jest dopuszczony, sprawdzić integralność i łańcuch dostarczenia; jeśli nie jest dopuszczony — potraktować jako IOC/TTP do eskalacji.

Utwardzanie (1–4 tygodnie)

  • Kontrola sterowników (Windows): polityki ograniczające ładowanie sterowników, tam gdzie możliwe włączanie mechanizmów typu HVCI/Memory Integrity i egzekwowanie zasad podpisu (w praktyce: minimalizacja powierzchni BYOVD). (Kontekst ryzyka i obejść pokazuje analiza Sophos).
  • Ograniczenie RDP: w raporcie wskazano, że RDP zostało włączone w środowisku ofiary — warto egzekwować „deny by default”, MFA, jump hosty i segmentację.
  • Segmentacja i egress control: ransomware, które eksfiltruje dane do chmury, bardzo korzysta z braku kontroli wyjścia. Ogranicz egress do „known good” i monitoruj nowe destynacje.
  • Odporność na kasowanie VSS: kopie zapasowe offline/immutability, testy odtwarzania i ochrona repozytoriów backupu (Osiris usuwa migawki).

Różnice / porównania z innymi przypadkami

  • Osiris 2025/2026 vs „Osiris” 2016 (Locky): zbieżna nazwa, ale Symantec nie widzi związku rodzinnego — to ważne, bo inaczej wyglądałby proces triage (IOC, logika szyfrowania, negocjacje, dekryptory).
  • BYOVD „klasyczne” vs POORTRY: w wielu kampaniach BYOVD nadużywa się legalnych podatnych driverów; tutaj istotny jest komponent „EDR killer” rozwijany jako własny ekosystem (co podnosi poprzeczkę dla obrony).
  • Podobieństwa do INC: wspólne „smaczki” (Wasabi, kaz.exe) mogą oznaczać: (a) kopiowanie TTP, (b) migrację afilianta, (c) współdzielenie playbooków. W praktyce dla obrony różnica jest mniejsza niż dla atrybucji — liczy się dopasowanie detekcji do TTP.

Podsumowanie / kluczowe wnioski

Osiris wygląda na nowy, dojrzały operacyjnie ransomware, wdrażany przez sprawnych napastników: najpierw kradzież danych, potem szyfrowanie, a po drodze agresywne „zdejmowanie” zabezpieczeń przez komponenty jądra (POORTRY/BYOVD).

Dla SOC/IR najważniejsze są trzy obszary: kontrola egress i polowanie na eksfiltrację (Rclone/Wasabi), telemetria sterowników i próby wyłączania EDR, oraz wczesne wykrywanie narzędzi dual-use używanych do rekonesansu i ruchu bocznego.


Źródła / bibliografia

  • The Hacker News — „New Osiris Ransomware Emerges as New Strain Using POORTRY Driver in BYOVD Attack” (22.01.2026). (The Hacker News)
  • SECURITY.COM (Symantec/Broadcom) — „Osiris: New Ransomware, Experienced Attackers?” (22.01.2026). (security.com)
  • Sophos — „Attack tool update impairs Windows computers” (27.08.2024) – kontekst POORTRY/BURNTCIGAR. (news.sophos.com)
  • SiliconANGLE — opis kampanii i uzupełniające szczegóły techniczne (22.01.2026). (SiliconANGLE)

KONNI wykorzystuje AI do budowy backdoora w PowerShell i celuje w deweloperów (blockchain/crypto)


Wprowadzenie do problemu / definicja luki

W styczniu 2026 Check Point Research opisał aktywną kampanię phishingową przypisywaną do KONNI – północnokoreańskiego aktora działającego co najmniej od 2014 roku. Tym razem kluczową zmianą jest dobór ofiar (software development/engineering) oraz narzędzie egzekucji: backdoor w PowerShell, którego cechy wskazują na AI-assist/AI-generated development (nie tyle nowe TTP, co szybsze i „czyściejsze” wytwarzanie kodu z typowymi artefaktami LLM).

W praktyce nie jest to „pojedyncza luka CVE”, ale łańcuch infekcji oparty o socjotechnikę, pliki skrótów Windows (LNK) i wieloetapowe uruchomienie komponentów, którego efektem jest trwały dostęp do hosta oraz możliwość dalszej eskalacji do narzędzi zdalnego zarządzania.


W skrócie

  • Kampania celuje w deweloperów i zespoły inżynieryjne z dostępem do zasobów blockchain/crypto (repozytoria, API, portfele, infrastruktura).
  • Start łańcucha: link hostowany na Discord → pobranie ZIP z przynętą (PDF) i LNK, który uruchamia loader PowerShell i rozpakowuje kolejne elementy (DOCX + CAB).
  • Utrwalenie: Scheduled Task podszywający się pod OneDrive, uruchamiany cyklicznie, deszyfrujący (XOR) i wykonujący backdoor „in-memory”.
  • Backdoor zawiera rozbudowane anti-analysis (progi sprzętowe, blacklist narzędzi, wymaganie aktywności myszą), fingerprinting przez WMI oraz mechanizmy eskalacji UAC (fodhelper).
  • C2: obejście „bramki” po stronie serwera przez emulację JavaScript challenge i pozyskanie cookie __test, a potem cykliczne wysyłanie metadanych hosta do endpointu PHP.

Kontekst / historia / powiązania

KONNI historycznie kojarzono głównie z celami w Korei Południowej (dyplomacja, rząd, NGO, akademia) oraz klasycznym spear-phishingiem opartym o tematy geopolityczne. W opisywanej kampanii widać przesunięcie na ekosystemy techniczne: development i obszary, gdzie pojedynczy kompromitowany endpoint może otworzyć drogę do kontenerów, CI/CD, sekretów w repozytoriach czy kluczy do usług.

Z szerszej perspektywy to pasuje do obserwacji, że północnokoreański program cyber jest wykorzystywany nie tylko do szpiegostwa, ale również do operacji generujących środki finansowe, m.in. przez kradzieże kryptowalut i naruszenia sankcji.


Analiza techniczna / szczegóły luki

1) Przynęty i initial access

Przynęty wyglądają jak materiały projektowe (architektura, stack, harmonogramy, budżety/milestones) powiązane z blockchain/crypto. Wektor początkowy wprost nie jest ujawniony, ale łańcuch startuje od linku hostowanego na Discord, prowadzącego do archiwum ZIP.

Z perspektywy MITRE ATT&CK to klasyczny przypadek User Execution: Malicious File (T1204.002) – ofiara musi otworzyć/uruchomić spreparowany plik (tu: LNK).

2) Łańcuch infekcji (ZIP → LNK → CAB → BAT/PS1)

W ZIP znajdują się PDF (lure) oraz LNK. LNK uruchamia osadzony loader PowerShell, który:

  • zapisuje na dysk przynętę DOCX i archiwum CAB (oba osadzone w LNK i XOR-owane jednobajtowym kluczem),
  • otwiera DOCX, żeby odciągnąć uwagę,
  • rozpakowuje CAB, gdzie znajdują się: PowerShell backdoor, dwa batch file oraz exe do UAC bypass,
  • uruchamia pierwszy batch.

3) Persistence i „living off the land”

Pierwszy batch tworzy staging w C:\ProgramData, przenosi komponenty i zakłada Scheduled Task podszywający się pod zadanie OneDrive uruchamiane co godzinę. Zadanie czyta zaszyfrowany backdoor, wykonuje XOR-decrypt (klucz ‘Q’) i uruchamia kod w pamięci. Następnie batch usuwa się z dysku (redukcja śladów).

4) Cechy sugerujące AI-generated backdoor

CPR wskazuje na nietypowo „produktowy” charakter skryptu: czytelna struktura, komentarze/dokumentacja oraz artefakt wprost przypominający placeholder z generatorów LLM: komentarz w rodzaju „your permanent project UUID” (instrukcja dla człowieka jak uzupełnić wartość). To zestaw sygnałów, który ma wspierać tezę o AI-assist/AI-generated development.

5) Funkcje backdoora: anti-analysis, identyfikacja hosta, eskalacja

Backdoor wykonuje:

  • anti-analysis/sandbox evasion: progi sprzętowe, wykrywanie narzędzi (IDA, Wireshark, Procmon itd.), wymaganie interakcji użytkownika (ruch/kliknięcia myszy),
  • single-instance przez mutex Global\SysInfoProject_<projectUUID> (UUID stały dla próbek wskazanych w raporcie),
  • fingerprinting przez WMI (m.in. serial płyty głównej + UUID systemu), SHA-256 i skrócenie do 16 znaków,
  • rozgałęzienie działań wg uprawnień: dla „User” – fodhelper UAC bypass przez manipulacje w HKCU\Software\Classes i przekierowanie protokołu ms-settings, a następnie modyfikację ConsentPromptBehaviorAdmin (de facto ograniczenie promptów UAC dla adminów).

Dodatkowo, w scenariuszu „Admin” raport opisuje m.in. dodanie wykluczenia Windows Defender dla C:\ProgramData i podmianę zadania harmonogramu na wersję z wyższym kontekstem uprawnień.

6) C2 i obejście „bramki” anty-bot

C2 jest zabezpieczone client-side’ową „bramką” (AES/JS) i cookie __test. Backdoor emuluje JavaScript challenge: pobiera implementację AES używaną przez stronę, odtwarza logikę JS, odszyfrowuje ciphertext z serwera i wyciąga token, a następnie używa go jako cookie do kolejnych żądań. Potem okresowo wysyła metadane hosta (ID, poziom uprawnień, IPv4, username) do endpointu PHP, a odpowiedzi traktuje jako tasking (PowerShell wykonywany w tle).

7) Warianty i IoC

CPR wspomina też o wariancie z października 2025, gdzie początkowy payload był wprost obfuskowanym skryptem PowerShell pobierającym kolejne komponenty, a OneDriveUpdater.exe służył głównie do pobrania i uruchomienia klienta SimpleHelp (legit RMM) dla interaktywnego dostępu.

W raporcie podano też przykładowe domeny/IP C2 oraz listy hashy (IoC).


Praktyczne konsekwencje / ryzyko

Dla organizacji software’owych i zespołów blockchain/crypto ryzyko jest szczególne, bo kompromitacja jednego stanowiska developerskiego może przełożyć się na:

  • wyciek sekretów z repozytoriów (tokeny do Git, klucze API, SSH),
  • przejęcie CI/CD (wstrzyknięcia w pipeline, supply-chain),
  • dostęp do środowisk chmurowych i walletów/kluczy podpisujących,
  • lateral movement do zasobów produkcyjnych.

Kontekst finansowy jest istotny: w oficjalnych opracowaniach dot. aktywności DPRK podkreśla się skalę cyber-kradzieży i ich rolę w finansowaniu działań państwa, w tym obchodzeniu sankcji.


Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h)

  1. Zablokuj/ogranicz uruchamianie LNK z pobranych archiwów i katalogów typu Downloads/Temp (tam, gdzie to możliwe politykami). To bezpośrednio tnie klasę ataków „malicious file + user execution”.
  2. Polowanie na Scheduled Tasks podszywające się pod OneDrive i uruchamiające inline PowerShell (szczególnie z odczytem bajtów z C:\ProgramData\… i natychmiastowym IEX).
  3. Telemetria EDR: alerty na PowerShell obfuskowany arytmetyką, nietypowe tworzenie słowników stringów + Invoke-Expression.
  4. Wykrywanie zmian w rejestrze pod fodhelper UAC bypass (ścieżki pod HKCU\Software\Classes i ms-settings) oraz modyfikacji ConsentPromptBehaviorAdmin.
  5. Network: blokady/alerty na wskazane w raporcie domeny/IP oraz na nietypowe żądania do endpointów PHP po wcześniejszym „handshake” z cookie __test.

Średni termin (1–4 tygodnie)

  • Hardening stacji dev: separacja kont, MFA wszędzie, minimalizacja lokalnych uprawnień admin, izolacja sekretów (vault), rotacja tokenów.
  • Ograniczenie możliwości dodawania Defender exclusions i monitorowanie wykluczeń dla C:\ProgramData.
  • Kontrole supply-chain: podpisywanie artefaktów, wymuszenie code review dla zmian w pipeline, zasada „two-person rule” dla kluczy produkcyjnych.
  • Uświadamianie: „projektowe PDF/DOCX z Discorda” jako realna przynęta dla devów – to dziś równie typowe jak „faktura” w klasycznych kampaniach.

Różnice / porównania z innymi przypadkami

  • KONNI (AI-assist backdoor): raportowane elementy wskazują na wykorzystanie AI głównie do wytwarzania/formatowania kodu (komentarze-artefakty, modularność), przy zachowaniu znanych TTP (LNK, scheduled task, PowerShell).
  • Szerszy trend AI-generated malware: Check Point kilka dni wcześniej opisał „VoidLink” jako przykład bardziej „frameworkowego” podejścia, gdzie AI miało przyspieszać nie tylko pisanie kodu, ale też planowanie i iterację całego projektu. To sugeruje, że „AI w malware” szybko przesuwa się od ciekawostek do realnego przyspieszacza R&D po stronie atakujących.
  • LNK jako stały motyw: niezależnie od tej konkretnej kampanii, analizy TTP w regionie (w tym porównania aktorów państwowych) pokazują, że pliki LNK w archiwach ZIP są dojrzałym i powtarzalnym wzorcem initial access.

Podsumowanie / kluczowe wnioski

  1. KONNI rozszerza profil ofiar: deweloperzy + blockchain/crypto to atrakcyjny cel, bo daje dostęp do sekretów i infrastruktury o wysokiej wartości.
  2. Największa nowość nie leży w „magicznych” nowych technikach, tylko w tym, że AI może obniżać koszt i czas tworzenia użytecznych implantów (bardziej uporządkowany kod, szybkie wariantowanie).
  3. Obrona powinna iść dwutorowo: (a) twarde kontrole uruchamiania plików i PowerShell, (b) security hygiene w środowisku dev (sekrety, pipeline, uprawnienia).
  4. Warto traktować kanały typu Discord jako realny wektor dystrybucji „materiałów projektowych” – szczególnie w społecznościach dev/web3.

Źródła / bibliografia

  1. Check Point Research – KONNI Adopts AI to Generate PowerShell Backdoors (22 stycznia 2026). (Check Point Research)
  2. MITRE ATT&CK – User Execution: Malicious File (T1204.002). (attack.mitre.org)
  3. Genians – analiza spear-phishing i nadużyć LNK/ZIP w kampaniach APT (kontekst TTP). (genians.co.kr)
  4. MOFA Japan (PDF) – raport dot. naruszeń/obchodzenia sankcji i roli DPRK cyber (kontekst finansowy).
  5. Check Point – VoidLink Signals the Start of a New Era in AI-Generated Malware (19 stycznia 2026). (Check Point Blog)