Archiwa: DDoS - Strona 10 z 16 - Security Bez Tabu

Tag: DDoS

Kimwolf: gigantyczny botnet na Android TV przejmuje 1,8 mln urządzeń i uczy się „przetrwania” (ENS, DoT, podpisy ECC)

Wprowadzenie do problemu / definicja luki

Kimwolf to nowo opisany botnet dla ekosystemu Android (głównie Android TV boxy / smart TV / set-top boxy), który w krótkim czasie osiągnął skalę kojarzoną dotąd raczej z największymi rodzinami IoT. Według analizy QiAnXin XLab, botnet był w stanie zgromadzić ~1,83 mln aktywnych IP dziennie (szczyt), a łączna liczba zaobserwowanych zainfekowanych IP przekroczyła 3,66 mln.

To nie jest „tylko kolejny DDoS”. XLab podkreśla, że Kimwolf — poza atakami wolumetrycznymi — ma też funkcje proxy forwardingu, reverse shell oraz zarządzania plikami, czyli zestaw typowy dla infrastruktury „komercyjnego” nadużycia (proxy-as-a-service) i zdalnej administracji przejętymi urządzeniami.

W skrócie

  • Skala: pik ~1 829 977 aktywnych botów/IP w dobie, kumulatywnie >3,66 mln IP.
  • Użycie: ponad 1,7 mld komend DDoS w obserwowanym oknie czasu (19–22 listopada 2025).
  • Infrastruktura: botnet korzysta z DNS over TLS (DoT) do „opakowania” zapytań DNS oraz wdraża mechanizmy odporności (m.in. ENS / EtherHiding) po działaniach typu takedown.
  • Powiązania: widoczne związki z botnetem AISURU (klasa „Turbo Mirai”), który wg Cloudflare stał za rekordami 29,7 Tbps i 14,1 Bpps.

Kontekst / historia / powiązania

XLab opisuje start dochodzenia od próbki pozyskanej 24 października 2025. Wyróżnikiem był domenowy adres C2 14emeliaterracewestroxburyma02132[.]su, który miał osiągać bardzo wysokie pozycje w rankingach popularności domen (w pewnym momencie nawet wyprzedzając Google).

Wątek AISURU jest tu istotny, bo pokazuje „rodzinne” podobieństwa i potencjalne współdzielenie infrastruktury/know-how. Cloudflare w raporcie za Q3 2025 opisuje AISURU jako botnet o armii 1–4 mln hostów, zdolny do regularnych ataków przekraczających 1 Tbps oraz 1 Bpps, z rekordami na poziomie 29,7 Tbps i 14,1 Bpps. W praktyce: Kimwolf wpisuje się w trend botnetów o skali „internetowej infrastruktury”, a nie „małych sabotaży”.

Analiza techniczna / szczegóły luki

Architektura i funkcje

Kimwolf jest kompilowany z użyciem Android NDK, co zwykle utrudnia analizę (kod natywny) i bywa spotykane w rodzinach nastawionych na wydajność i trudniejsze reverse engineering.
Zestaw funkcji obejmuje:

  • DDoS (wydawanie masowych komend ataków),
  • proxy forwarding (monetyzacja przez „wynajem” ruchu z domowych IP),
  • reverse shell (zdalne wykonywanie poleceń),
  • file management (operacje na plikach na urządzeniu).

Ukrywanie i odporność C2

XLab wskazuje kilka mechanizmów, które są rzadziej spotykane w „klasycznych” botnetach TV boxów:

  • DoT (DNS over TLS) do tunelowania zapytań DNS i ograniczenia widoczności dla prostych systemów detekcji.
  • Proste, ale skuteczne szyfrowanie wrażliwych danych (opisywane jako Stack XOR).
  • Uwierzytelnianie poleceń C2 oparte o podpisy cyfrowe (ECC) — bot akceptuje instrukcje dopiero po poprawnej weryfikacji podpisu, co utrudnia „podszycie się” pod serwer sterujący.
  • Po kolejnych zakłóceniach infrastruktury botnet miał wdrożyć ENS / EtherHiding jako element zwiększania odporności na takedowny.

Dlaczego infekcje są trudne do wykrycia?

W raporcie podkreślono m.in. niską wykrywalność w publicznych źródłach i fakt, że ścieżka propagacji nie jest jeszcze jednoznacznie ustalona — co w połączeniu z DoT i podpisami po stronie C2 utrudnia korelację próbek z infrastrukturą.

Praktyczne konsekwencje / ryzyko

Dla internetu i operatorów usług

Skala ~1,8 mln węzłów oznacza realną możliwość:

  • masowych ataków wolumetrycznych (w tym krótkich, ale bardzo intensywnych),
  • degradacji usług na poziomie ISP i upstreamów,
  • „szumu” utrudniającego reagowanie incydentowe.

W tle widać ciągłość z AISURU: Cloudflare opisuje, że tego typu botnety potrafią generować ataki, które „przesuwają granice” (rekordy Tbps/Bpps) i rosną szybciej niż zdolności ręcznego reagowania.

Dla firm i użytkowników końcowych

Najbardziej niedoszacowane ryzyko Kimwolf to proxying: przejęte TV boxy mogą stać się „czyimś wyjściem na internet” do:

  • nadużyć (spam, skanowanie, ataki na logowanie),
  • omijania geoblokad i fraudu,
  • ukrywania źródła działań przestępczych (Twoje IP jako „kozioł ofiarny”).

Rekomendacje operacyjne / co zrobić teraz

Jeśli zarządzasz siecią (SOHO / SMB / Enterprise)

  1. Segmentuj IoT/TV boxy (oddzielny VLAN/SSID, polityki egress-only tam, gdzie się da).
  2. Twardy egress: blokuj nietypowe połączenia wychodzące z segmentu IoT (szczególnie do nieznanych hostów/portów) i rozważ politykę „allow-list” dla DNS/NTP/aktualizacji.
  3. Kontrola DoT: jeżeli środowisko tego wymaga, ogranicz DoT do zaufanych resolverów lub wymuś firmowy DNS (bo Kimwolf używa DoT jako warstwy ukrycia).
  4. Threat hunting na wskaźniki domenowe: monitoruj zapytania/połączenia do podejrzanych domen C2, w tym wskazywanych publicznie w analizach (np. …02132[.]su).
  5. Telemetry first: w segmencie IoT zbieraj NetFlow/Zeek/IDS — krótkie, intensywne piki ruchu wychodzącego i „dziwne” sesje do wielu hostów to typowy wzorzec botnetów DDoS.

Jeśli jesteś użytkownikiem Android TV box / smart TV

  • Preferuj urządzenia certyfikowane i aktualizowane (realne wsparcie producenta).
  • Aktualizuj firmware i aplikacje; unikaj „egzotycznych” APK i niepotrzebnych uprawnień.
  • Jeśli urządzenie nie dostaje aktualizacji lub pochodzi z niepewnego źródła — wymiana bywa najtańszą formą bezpieczeństwa (botnety żyją latami na sprzęcie bez poprawek).

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

Kimwolf vs. „klasyczny Mirai”
Mirai (i liczne pochodne) często opierały się na prostym modelu: skanowanie, słabe hasła, masowy DDoS. Kimwolf wygląda na bardziej „produktowy”: DoT do ukrycia, podpisy ECC do kontroli C2 oraz odporność z ENS/EtherHiding.

Kimwolf vs. AISURU
AISURU to potwierdzony „młot pneumatyczny” DDoS, z rekordami 29,7 Tbps i 14,1 Bpps opisywanymi przez Cloudflare. Kimwolf — sądząc po obserwacjach XLab i doniesieniach branżowych — może być:

  • blisko spokrewnioną linią rozwojową,
  • albo „modułem”/odnogą tego samego ekosystemu, nastawioną mocniej na proxy i odporność infrastruktury.

Podsumowanie / kluczowe wnioski

Kimwolf to sygnał, że botnety na Android TV boxach nie są już „tanimi armatami do DDoS”, tylko coraz częściej wielofunkcyjną infrastrukturą przestępczą: od DDoS po proxy i zdalne zarządzanie. Skala (miliony urządzeń), techniki ukrycia (DoT) i odporność (ENS/EtherHiding, podpisy ECC) wskazują na dojrzałe podejście do utrzymania botnetu mimo takedownów.

Jeśli w Twojej organizacji są Android TV boxy (sale konferencyjne, digital signage, kioski) — potraktuj je jak IoT wysokiego ryzyka: segmentacja, kontrola egress i monitoring DNS/ruchu to absolutne minimum.

Źródła / bibliografia

  1. QiAnXin XLab – “Kimwolf Exposed: The Massive Android Botnet with 1.8 Million Infected Devices” (奇安信 X 实验室)
  2. Cloudflare – “2025 Q3 DDoS threat report” (The Cloudflare Blog)
  3. Security Affairs – omówienie odkrycia i skali Kimwolf (Security Affairs)
  4. The Hacker News – opis kampanii i statystyk komend DDoS (The Hacker News)
  5. SecurityWeek – podsumowanie funkcji (proxy/reverse shell/file mgmt) i powiązań z AISURU (SecurityWeek)

Kimwolf: gigantyczny botnet na Androida przejmuje 1,8 mln urządzeń i „twardnieje” dzięki ENS oraz DNS-over-TLS

Wprowadzenie do problemu / definicja „luki”

Kimwolf to nowo ujawniona, masowa sieć botnet działająca na urządzeniach z Androidem (w praktyce głównie tanie TV boxy / set-top boxy i Smart TV), wykorzystywana do ataków DDoS oraz – co ważne – do funkcji typowych dla zdalnego dostępu: proxy/forwarding ruchu, reverse shell i zarządzanie plikami.

To nie jest pojedyncza „luka” w sensie CVE, tylko kampania infekcji i utrzymywania kontroli nad urządzeniami, gdzie problemem systemowym są: słabe aktualizacje firmware’u, podatny ekosystem tanich urządzeń, a także rosnąca „odporność infrastruktury” operatorów botnetu.

W skrócie

  • Skala: badacze szacują, że Kimwolf kontroluje >1,8 mln urządzeń, rozproszonych globalnie (ponad 220 krajów/regionów).
  • DDoS: zaobserwowano ~1,7 mld komend DDoS wydanych w krótkim oknie czasowym (19–22 listopada 2025).
  • Ewazja i odporność: komunikacja obejmuje m.in. DNS-over-TLS (DoT) oraz mechanizm weryfikacji poleceń (podpisy cyfrowe); po takedownach C2 botnet przeszedł na ENS (Ethereum Name Service), żeby utrudnić wyłączanie infrastruktury.
  • Powiązania: istnieją mocne przesłanki łączące Kimwolf z ekosystemem botnetu Aisuru (znanego m.in. z rekordowych wolumenów DDoS).

Kontekst / historia / powiązania

O Kimwolf zrobiło się głośno m.in. dlatego, że jeden z domenowych adresów C2 (bardzo długi, w strefie .su) miał według analiz „wystrzelić” w rankingach popularności domen (Cloudflare Domain Rankings), co było skorelowane z masową aktywnością botnetu.

XLab (QiAnXin) wskazuje, że Kimwolf jest powiązany z Aisuru – botnetem klasy „TurboMirai”, który w raportach Cloudflare przewija się jako źródło hiperwolumetrycznych ataków (włącznie z rekordami rzędu 29,7 Tbps i 14,1 mld pakietów/s).

W praktyce oznacza to możliwy scenariusz: ci sami operatorzy (lub ściśle powiązana grupa) rozwijają równoległe „armie” – i mogą je łączyć w kampaniach, w zależności od celu i presji obronnej (takedowny, detekcje).

Analiza techniczna / szczegóły działania

Poniżej najważniejsze elementy techniczne, które wyróżniają Kimwolf na tle wielu „typowych” botnetów IoT/Android:

1) Zakres funkcji: nie tylko DDoS

Kimwolf ma klasyczne możliwości botnetu DDoS, ale równolegle oferuje:

  • proxy forwarding (pośredniczenie w ruchu, potencjalnie do nadużyć i „ukrywania” źródła),
  • reverse shell (zdalna powłoka),
  • zarządzanie plikami.

To ważne, bo w takim układzie botnet może być używany nie tylko do „głośnych” ataków, ale też do cichych operacji (np. jako infrastruktura pośrednicząca).

2) Łańcuch komunikacji i utrudnianie detekcji: DoT + kryptografia

Badacze opisują użycie:

  • DNS-over-TLS (DoT) do „opakowania” zapytań DNS i utrudniania tradycyjnej inspekcji/detekcji,
  • mechanizmu weryfikacji poleceń podpisem cyfrowym (na krzywych eliptycznych), gdzie bot ma wykonywać tylko poprawnie podpisane instrukcje,
  • dodatkowo prostej warstwy szyfrowania/ukrywania danych wrażliwych (operacje XOR stosu).

Wniosek praktyczny: samo „przejęcie” kanału C2 lub podszywanie się pod operatora może być trudniejsze niż w prostych klonach Mirai, bo boty nie muszą ufać „każdemu” serwerowi.

3) Odporność infrastruktury: przejście na ENS po takedownach

XLab wskazuje, że domeny C2 były zdejmowane co najmniej kilka razy, a operatorzy reagowali „utwardzaniem” infrastruktury i przejściem na ENS (Ethereum Name Service), co jest przykładem trendu „blockchain-based naming / EtherHiding” jako odpowiedzi na klasyczne takedowny DNS.

4) Skala i geografia

XLab szacuje >1,8 mln zainfekowanych urządzeń i podaje rozkład w 222 krajach/regionach, z wysokimi udziałami m.in. w Brazylii, Indiach i USA.
Za typowe ofiary wskazywane są urządzenia klasy TV BOX / set-top box / Smart TV (często w sieciach domowych).

Praktyczne konsekwencje / ryzyko

Dla organizacji (i dostawców usług) Kimwolf to ryzyko w kilku warstwach:

  1. DDoS o bardzo dużej skali
    Jeśli XLab ma rację, potencjał Kimwolf może zbliżać się do „poziomu” największych botnetów obserwowanych w telemetrii Cloudflare.
  2. „Residential proxy” jako usługa (ciche nadużycia)
    Możliwości proxy + duża baza urządzeń domowych to idealny przepis na:
  • maskowanie źródeł ataków,
  • omijanie geoblokad,
  • automatyzację nadużyć (fraud, scraping, credential stuffing) z „wiarygodnych” IP użytkowników końcowych.
  1. Trudniejsza detekcja na poziomie DNS
    DoT oraz bardziej „dojrzałe” mechanizmy uwierzytelniania poleceń utrudniają szybkie odcięcie i proste reguły oparte o DNS.

Rekomendacje operacyjne / co zrobić teraz

Poniżej podejście „praktyczne”, bez wchodzenia w vendor-specific playbooki.

Dla zespołów SOC / sieci w firmach (szczególnie ISP, telco, hosting, e-commerce)

  • Inwentaryzuj i ogranicz IoT/Android TV w sieci: jeśli nie jest krytyczne biznesowo, trzymaj takie urządzenia poza siecią produkcyjną (osobny VLAN, brak routingu do zasobów).
  • Polityka DNS:
    • monitoruj/alertuj nietypowe wzorce DoT (TCP/853) oraz nagłe „skoki” w liczbie połączeń do resolverów/endpointów,
    • rozważ egzekwowanie DNS do firmowych resolverów (tam, gdzie to możliwe), zamiast pozwalania na „dowolny DoT na zewnątrz”. (Uwaga: DoT bywa legalny – chodzi o kontrolę i widoczność, nie ślepe blokowanie).
  • Telemetria egress: profiluj urządzenia, które generują nienaturalny ruch wychodzący (zwłaszcza UDP), albo zachowują się jak proxy.
  • Przygotuj runbook pod hiperwolumetryczne DDoS: ćwiczenia z CDN/WAF/DDoS scrubbingiem; Cloudflare raportuje, że skala takich ataków rośnie i może mieć efekt „kolateralny” na operatorów/ISP nawet gdy nie są celem.

Dla użytkowników domowych / małych firm

  • Wymuś aktualizacje (jeśli producent w ogóle je dostarcza) i unikaj urządzeń bez jasnego wsparcia.
  • Nie instaluj „podejrzanych” APK i ogranicz sideloading.
  • Jeśli TV box zachowuje się nietypowo (lagi, przegrzewanie, wysycenie łącza): reset do ustawień fabrycznych + aktualizacja; a w razie braku wsparcia – wymiana urządzenia.

Różnice / porównania z innymi przypadkami

  • Mirai i pochodne zwykle bazują na prostych mechanizmach C2 i masowym skanowaniu/eksploitacji IoT; Kimwolf wyróżnia się naciskiem na proxy oraz „twardszą” warstwę komunikacji (DoT, podpisy poleceń).
  • Aisuru jest w raportach Cloudflare symbolem hiperwolumetrycznego DDoS i botnet-for-hire; powiązania Kimwolf↔Aisuru sugerują, że operatorzy mogą prowadzić ekosystem botnetów, a nie jeden monolit.
  • Odporność na takedowny przez ENS to element „nowej generacji” infrastruktury botnetów – domeny w klasycznym DNS da się gasić szybciej niż nazwy rozwiązywane przez mechanizmy powiązane z blockchainem.

Podsumowanie / kluczowe wnioski

Kimwolf to sygnał, że botnety na Android TV/TV boxach przestały być „tylko” źródłem taniego DDoS. Skala >1,8 mln urządzeń, funkcje proxy/reverse shell, użycie DoT, kryptograficznej walidacji poleceń i przejście na ENS po takedownach pokazują botnet projektowany pod długie życie i odporność.

Jeżeli Twoja organizacja jest zależna od dostępności usług (ISP/telco, e-commerce, gaming, finanse, infrastruktura), traktuj to jako argument za: lepszą kontrolą egress/DNS, segmentacją IoT oraz gotowością na hiperwolumetryczne kampanie DDoS, których skala w telemetrii dostawców ochrony realnie rośnie.

Źródła / bibliografia

  1. SecurityWeek – „Kimwolf Android Botnet Ensnares 1.8 Million Devices” (19 grudnia 2025) (SecurityWeek)
  2. QiAnXin XLab – „Kimwolf Exposed: The Massive Android Botnet with 1.8 Million Infected Devices” (17 grudnia 2025) (blog.xlab.qianxin.com)
  3. Cloudflare – „2025 Q3 DDoS threat report” (3 grudnia 2025) (The Cloudflare Blog)
  4. Cloudflare – „Aisuru botnet: Early October attacks escalate into record-setting DDoS activity” (grudzień 2025) (Cloudflare)

Dania oficjalnie obwinia Rosję o cyberataki na infrastrukturę krytyczną i serwisy wyborcze: co wiemy i jak się przygotować

Wprowadzenie do problemu / definicja luki

Dania po raz pierwszy publicznie przypisała Rosji konkretne, „destrukcyjne i zakłócające” cyberataki: jeden wymierzony w infrastrukturę wodociągową, drugi – w serwisy internetowe związane z wyborami samorządowymi i regionalnymi. To ważny sygnał dla całej Europy: operacje w cyberprzestrzeni coraz częściej mają charakter hybrydowy (łączą presję polityczną, dezinformację, incydenty sabotażowe i cyberataki), a celami są nie tylko „duże” instytucje państwowe, ale też lokalne podmioty odpowiedzialne za ciągłość usług publicznych.

W skrócie

  • Duński wywiad wojskowy (FE/DDIS) ocenia, że pro-rosyjskie grupy Z-Pentest oraz NoName057(16) mają powiązania z państwem rosyjskim.
  • Atak na wodociągi (2024) miał charakter destrukcyjny: według doniesień doprowadził do problemów z dostawą wody (m.in. pęknięcia rur i czasowe braki u ok. 500 gospodarstw).
  • Osobno odnotowano DDoS przeciw duńskim serwisom w okresie poprzedzającym wybory samorządowe i regionalne (2025), przypisywany NoName057(16).
  • Władze traktują incydenty jako element rosyjskiej strategii destabilizacji państw wspierających Ukrainę.

Kontekst / historia / powiązania

Publiczne przypisanie odpowiedzialności (atrybucja) ma znaczenie operacyjne i polityczne. Z perspektywy bezpieczeństwa to „zamknięcie pętli”: państwo nie tylko obsługuje incydent, ale wskazuje sprawcę, opisuje modus operandi i stawia to w kontekście szerszej kampanii.

FE/DDIS wskazał, że:

  • Z-Pentest stał za destrukcyjnym atakiem na duński obiekt wodociągowy (2024),
  • a NoName057(16) za przeciążeniowymi atakami DDoS na duńskie witryny w okresie przedwyborczym (2025).

Na poziomie strategicznym Dania wpisuje te zdarzenia w rosyjną „wojnę hybrydową” przeciw państwom Zachodu.

Analiza techniczna / szczegóły luki

Atak na wodociągi: dlaczego to jest „destrukcyjne”

Incydent w sektorze wodnym jest szczególnie niebezpieczny, bo dotyka OT/ICS (systemów sterowania przemysłowego). Według relacji medialnych atak na obiekt wodociągowy w rejonie Kopenhagi doprowadził do anomalii pracy infrastruktury (m.in. wzrostu ciśnienia / uszkodzeń), co przełożyło się na awarie i przerwy w dostawach.

To typowy scenariusz, w którym:

  • atakujący szuka dostępu do paneli/sterowników,
  • zmienia parametry procesu (np. ciśnienie, tryby pracy pomp),
  • wywołuje awarię fizyczną lub kontrolowany chaos eksploatacyjny.

Nawet jeśli skala była ograniczona, „progiem sukcesu” jest tu pokazanie możliwości: że da się naruszyć ciągłość usługi publicznej.

DDoS przed wyborami: atak prosty, ale skuteczny w przekazie

Druga część historii dotyczy przeciążeniowych ataków DDoS na serwisy internetowe w okolicach wyborów samorządowych i regionalnych (2025). DDoS zwykle nie oznacza włamania ani kradzieży danych – jego celem jest czasowa niedostępność usług (przeciążenie ruchem). Ale politycznie i społecznie potrafi być bardzo dotkliwy: w dniu głosowania lub tuż przed nim uderza w informację, komunikację i zaufanie.

Atrybucja do Rosji: co faktycznie oznacza

Warto odróżnić trzy poziomy:

  1. „grupa pro-rosyjska” (deklaracje, narracja, cele),
  2. „powiązania z państwem” (wsparcie, koordynacja, zadania, zasoby),
  3. „operacja państwowa” (pełne sterowanie).

FE/DDIS publicznie ocenił powiązania obu grup z państwem rosyjskim – to mocny komunikat, ale nadal „ocena wywiadowcza”, nie ujawnienie całego materiału dowodowego (co jest standardem w takich sprawach).

Praktyczne konsekwencje / ryzyko

Dla infrastruktury krytycznej (woda, energia, transport)

  • Ryzyko realnych szkód fizycznych (awarie, przestoje, koszty napraw, odpowiedzialność regulatora).
  • Efekt mrożący: operatorzy mogą przechodzić w tryb „ręcznego sterowania” i ograniczać usługi, by odzyskać kontrolę.
  • Najsłabsze ogniwo to często styki IT–OT (zdalny dostęp, dostawcy utrzymania, nieaktualne systemy, brak segmentacji).

Dla procesów demokratycznych

  • DDoS może ograniczać dostęp do informacji (strony urzędów, komisji, mediów) i wzmacniać narrację o „państwie, które nie działa”.
  • Nawet jeśli głosowanie nie zostaje przerwane, koszt ponosi zaufanie publiczne.

AP odnotowuje, że podobne działania są elementem szerszego wzorca incydentów przypisywanych Rosji w Europie po 2022 r., obejmującego również sabotaż i cyberoperacje.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz” – szczególnie dla operatorów usług kluczowych (water/wastewater), samorządów i podmiotów okołowyborczych.

Ochrona OT/ICS (wodociągi, zakłady komunalne)

  • Segmentacja IT/OT i twarde reguły ruchu (allow-list), z kontrolą połączeń do strefy OT.
  • Zdalny dostęp tylko przez bastion (MFA, PAM, rejestrowanie sesji, czasowe uprawnienia).
  • Monitoring anomalii procesowych: alerty na nietypowe parametry (np. skoki ciśnienia, częstotliwość załączeń pomp).
  • Kopie zapasowe konfiguracji PLC/SCADA + procedury odtworzeniowe testowane w praktyce.
  • Audyt kont serwisowych i dostawców utrzymania (to częsty wektor wejścia).

Odporność na DDoS (wybory, administracja, media lokalne)

  • Włączenie ochrony na poziomie CDN/WAF i usług anty-DDoS (przynajmniej dla kluczowych domen).
  • Przygotowanie „trybu awaryjnego”: statyczne strony informacyjne, mirror, komunikaty w kanałach alternatywnych.
  • Testy obciążeniowe przed wydarzeniami wysokiego ryzyka (wybory, kryzysy).
  • Logika komunikacji kryzysowej: kto ogłasza, gdzie ogłasza, jak szybko.

Zarządzanie incydentem i „gotowość organizacyjna”

  • Scenariusze tabletop: „atak na OT” i „DDoS w dzień głosowania”.
  • Jasny podział odpowiedzialności IT/OT/PR/prawny oraz kontakty do CERT/CSIRT.
  • Retencja logów i synchronizacja czasu (NTP) – bez tego analiza incydentu bywa fikcją.

Różnice / porównania z innymi przypadkami

  • OT vs IT: atak na wodociągi pokazuje przejście od „samej niedostępności” do ryzyka oddziaływania na proces fizyczny. To inna klasa incydentu niż typowe DDoS-y.
  • Skala szkód vs efekt strategiczny: nawet ograniczony incydent (np. kilkaset gospodarstw bez wody) może mieć wysoką wartość propagandową i testową: sprawdza czas reakcji, komunikację, poziom przygotowania.
  • DDoS jako broń informacyjna: technicznie bywa „low effort”, ale świetnie działa jako element kampanii hybrydowej – zwłaszcza w momentach społecznie wrażliwych (wybory).

Podsumowanie / kluczowe wnioski

  1. Dania oficjalnie wskazała Rosję jako odpowiedzialną za konkretne cyberataki na wodociągi i infrastrukturę internetową wokół wyborów.
  2. Incydent w sektorze wodnym to ostrzeżenie: OT/ICS nie jest „za nudne, by atakować” – wręcz przeciwnie, jest idealne do działań destabilizacyjnych.
  3. DDoS nadal pozostaje prostym narzędziem o dużym wpływie społecznym.
  4. Najbardziej opłacalne kroki obronne to: segmentacja IT/OT, kontrola zdalnego dostępu, monitoring anomalii procesowych oraz przygotowane playbooki na DDoS i incydenty wyborcze.

Źródła / bibliografia

  1. FE/DDIS (Forsvarets Efterretningstjeneste) – komunikat o przypisaniu ataków grupom Z-Pentest i NoName057(16) oraz ich powiązaniach z państwem rosyjskim. (Forsvarets Efterretningstjeneste)
  2. Associated Press – opis incydentu wodociągowego, skali zakłóceń i kontekstu „hybrydowej” presji. (AP News)
  3. The Guardian – informacje o charakterze ataków, wskazanych grupach i reakcji władz. (The Guardian)
  4. Euronews – potwierdzenie publicznej atrybucji i wątku ataków na serwisy wyborcze. (euronews)
  5. SecurityWeek (reprint AP) – syntetyczne ujęcie tematu w kontekście cyberbezpieczeństwa. (SecurityWeek)

FBI rozbija domniemany serwis do prania pieniędzy dla grup ransomware (E-Note)

Wprowadzenie do problemu / definicja luki

Departament Sprawiedliwości USA poinformował o zakłóceniu działalności i przejęciu infrastruktury E-Note — internetowej usługi wymiany/kantoru kryptowalut, która miała umożliwiać pranie środków dla transnarodowych grup cyberprzestępczych, w tym operatorów ransomware. W sprawie oskarżono 39-letniego obywatela Rosji, Mykhailo (Mykhalio) Petrovicha Chudnovetsa, a amerykańskie i europejskie służby przejęły m.in. domeny i aplikacje mobilne powiązane z serwisem.

W skrócie

  • Skala: FBI zidentyfikowało ponad 70 mln USD przepływów związanych z atakami ransomware i przejęciami kont, obsłużonych przez E-Note od 2017 r.
  • Infrastruktura: zajęto serwery, aplikacje oraz domeny e-note.com, e-note.ws i jabb.mn.
  • Zarzuty: Chudnovets — konspiracja w celu prania pieniędzy (do 20 lat więzienia).
  • Partnerzy: działania koordynowane z BKA (Niemcy), NBI (Finlandia) i policją stanu Michigan.

Kontekst / historia / powiązania

Uderzenie w E-Note wpisuje się w szerszą kampanię przeciwko no-KYC/no-AML kryptousługom, które od lat służą do „cashoutu” zysków z cyberprzestępczości. Przypomnijmy: w 2024 r. BKA zamknęła 47 rosyjskojęzycznych serwisów wymiany bez KYC, a analizy pokazały ich centralną rolę w ekosystemie prania środków. Również FBI ostrzegało wcześniej przed korzystaniem z nierejestrowanych w USA „money services businesses” (MSB).

Analiza techniczna / szczegóły luki

  • Model działania: E-Note miało łączyć procesor płatności z siecią „money mules” (słupów) oraz konwersją krypto-fiat, oferując szybkie transfery transgraniczne i wypłaty gotówkowe — krytyczny krok do „wybielenia” okupów.
  • Artefakty infrastrukturalne: przejęto serwery, bazy klientów i rejestry transakcyjne, co może umożliwić wsteczne śledzenie przepływów i identyfikację klientów/pośredników.
  • Powiązania z ransomware: wg FBI przez usługę przepływały środki z ataków na ochronę zdrowia i infrastrukturę krytyczną (wskazuje to na użycie przez aktorów „big-game hunting”).
  • Brak KYC/AML: operacyjny charakter usługi wskazuje na obchodzenie reżimów KYC/AML, co czyniło ją atrakcyjną dla operatorów APT-crime i brokerów dostępu. FBI od 2024 r. podkreśla, że usługi MSB bez rejestracji/AML są sygnałem alarmowym.

Praktyczne konsekwencje / ryzyko

  • Ryzyko wtórne (exposure): firmy, które nieświadomie opłaciły odzysk lub współpracowały z zewnętrznymi „cashout” brokerami, mogą pojawić się w przejętych rejestrach klienta/operacji. To może skutkować pytaniami organów nadzoru i wymogiem audytu AML.
  • Retorsje cyberprzestępców: krótkoterminowo możliwa jest relokacja do innych no-KYC oraz wzrost opłat „cashout”. W przeszłości podobne takedowny prowadziły do migracji na mniejsze, bardziej rozproszone platformy.
  • Okazja śledcza: pełne bazy transakcyjne to szansa na atrybucję i recoup (odzysk środków) przy współpracy organów i podmiotów prywatnych analityki on-chain.

Rekomendacje operacyjne / co zrobić teraz

  1. Blokady i detekcje
    • Dodaj do blokad DNS/URL i EDR: e-note.com, e-note.ws, jabb.mn; przejrzyj proxy/DNS pod kątem historycznych wywołań.
    • Uzupełnij reguły UEBA/SIEM o wykrywanie wzorców „cashout”: nietypowe przelewy na giełdy P2P/no-KYC, nagłe mikropłatności, rozbijanie kwot (structuring).
  2. AML/KYC i zgodność
    • Zweryfikuj dostawców „OTC/wykup okupu” pod kątem rejestracji MSB i programu AML — to wymóg regulacyjny w USA i dobry standard globalnie.
    • Odśwież procedury zgodności z no-KYC exchange exposure; wykorzystaj listy ryzyka (np. zewnętrzne feedy analityki łańcuchów).
  3. IR/Threat Intel
    • Jeśli Twoja organizacja miała incydent z płatnością w krypto, przeprowadź retrospekcję transakcyjną (on-chain tracing) i kontakt z organami — FBI udostępniło dedykowany kanał dla potencjalnych ofiar E-Note.
    • Zmapuj zależności z kampaniami ransomware celującymi w ochronę zdrowia i ICS; zaktualizuj playbooki DDoS-i-negocjacje na scenariusz „brak kanału cashout”.
  4. Polityka płatności okupu
    • Weryfikuj ryzyko sankcyjne/AML przed jakimikolwiek transferami — nierejestrowane MSB to czerwone światło i potencjalne naruszenie prawa.

Różnice / porównania z innymi przypadkami

  • W porównaniu z szerokimi operacjami (np. niemieckie zamknięcie 47 serwisów no-KYC w 2024 r.), sprawa E-Note to precyzyjny takedown pojedynczego węzła cashout, ale z wartością śledczą (pełne bazy klientów i transakcji).
  • Wspólny mianownik: brak KYC, szybkie swapy i „mosty” krypto-fiat — dokładnie te cechy, które analitycy uznają za „kręgosłup” prania środków z cyberprzestępczości.

Podsumowanie / kluczowe wnioski

Takedown E-Note to kolejny cios w ekosystem wyprowadzania okupów. Najważniejsze dla obrony: blokady znanych artefaktów, przegląd ekspozycji AML/KYC, oraz współpraca z organami w zakresie ewentualnych przepływów przez E-Note. Na poziomie rynku można oczekiwać dyspersji na mniejsze, bardziej ukryte usługi — warto więc budować detekcje behawioralne, a nie tylko listy domen.

Źródła / bibliografia

  • U.S. DOJ (Eastern District of Michigan): „FBI disrupts virtual money laundering service used to facilitate criminal activity” — komunikat, 17 grudnia 2025. (Department of Justice)
  • The Record / Recorded Future News: „FBI takes down alleged money laundering service for ransomware groups”, 17 grudnia 2025. (The Record from Recorded Future)
  • FBI IC3 PSA: „Alert on Cryptocurrency Money Services Businesses (MSB)”, 25 kwietnia 2024 — ostrzeżenia dot. nierejestrowanych usług. (ic3.gov)
  • Chainalysis: „German authorities seize Russian-centric no-KYC exchanges”, 25 września 2024 — tło nt. roli no-KYC w cyberpraniu. (Chainalysis)
  • The Record: „Germany shuts down 47 cryptocurrency exchange services used by cybercriminals”, 20 września 2024 — kontekst operacji BKA. (The Record from Recorded Future)

SoundCloud potwierdza incydent bezpieczeństwa: wyciek e-maili, blokady VPN i ataki DDoS

Wprowadzenie do problemu / definicja luki

SoundCloud potwierdził naruszenie bezpieczeństwa, w wyniku którego nieuprawniony podmiot uzyskał dostęp do „pomocniczego panelu usługowego” i wyeksfiltrował adresy e-mail oraz publiczne dane z profili. Firma podkreśla, że nie doszło do naruszenia haseł ani danych finansowych. Incydent zbiegł się w czasie z czasową blokadą dostępu przez VPN (błędy 403) oraz atakami DDoS na warstwę web. SoundCloud ocenia, że zdarzenie dotknęło ok. 20% użytkowników i zostało opanowane.

W skrócie

  • Zakres: e-maile + publiczne informacje profilowe; bez haseł/finansów.
  • Skala: ok. 20% kont (na podstawie danych SoundCloud).
  • Dostępność: uboczne zmiany konfiguracyjne po reakcji na incydent spowodowały problemy z dostępem przez VPN; równolegle wystąpiły DDoS.
  • Atrybucja: media branżowe łączą sprawę z ShinyHunters (informacja niepotwierdzona oficjalnie).

Kontekst / historia / powiązania

O problemach z dostępem przez VPN do SoundCloud użytkownicy raportowali od kilku dni (kody 403 „Forbidden”). Doniesienia prasowe wskazują, że utrudnienia nie wynikały z celowej polityki blokowania VPN, lecz z efektów ubocznych zmian bezpieczeństwa po incydencie.
W międzyczasie serwis doświadczał również ataków DDoS, które przejściowo ograniczały dostępność warstwy web.
BleepingComputer podał, że za włamaniem może stać grupa ShinyHunters, znana z głośnych kampanii wymuszeń w 2025 r. (ale SoundCloud nie potwierdził tej atrybucji).

Analiza techniczna / szczegóły luki

  • Punkt wejścia: „ancillary service dashboard” — panel usług pomocniczych; po wykryciu anomalii uruchomiono procedury IR i odcięto dostęp.
  • Zakres danych: wyłącznie adresy e-mail oraz publicznie widoczne dane profilu (np. nazwa użytkownika, bio). Brak dowodów na ekspozycję haseł, tokenów płatności, danych finansowych.
  • Dotknięta populacja: ~20% bazy użytkowników. W materiałach prasowych szacuje się to na dziesiątki milionów kont, ale to przeliczenia oparte na publicznych metrykach — oficjalny komunikat podaje tylko odsetek.
  • Wpływ na infrastrukturę: po wdrożeniu zmian twardniających konfigurację pojawiły się problemy z VPN; dodatkowo serwis odnotował co najmniej dwa skuteczne epizody DDoS na warstwę web.

Praktyczne konsekwencje / ryzyko

  • Zwiększone ryzyko phishingu i spear-phishingu na adresy e-mail powiązane z kontami SoundCloud (np. fałszywe „ostrzeżenia o naruszeniu”, prośby o reset hasła czy płatności).
  • Korelacja tożsamości: publiczne pola profilu ułatwiają dopasowanie aliasów do e-maili, co wspiera ataki socjotechniczne na innych platformach.
  • Ryzyko dla firm: konta „pro/creators” często używają adresów biznesowych — możliwe kampanie BEC/brand impersonation celowane w branżę muzyczną i agencje.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników SoundCloud:

  1. Wzmożona czujność na phishing: ignoruj linki w mailach „z resetem hasła” — przechodź ręcznie do domeny soundcloud.com.
  2. Włącz 2FA na wszystkich powiązanych kontach (e-mail, SoundCloud, media społecznościowe).
  3. Rozdziel aliasy e-mail: jeśli używasz jednego adresu dla wielu serwisów, rozważ aliasy/ustawienia catch-all, by szybciej wykrywać nadużycia.
  4. Aktualizuj menedżer haseł i sprawdź, czy nie powielasz haseł między serwisami (mimo braku dowodów na wyciek haseł to dobra praktyka).

Dla zespołów SecOps/IT w organizacjach współpracujących z SoundCloud (wytwórnie, agencje, SaaS):

  1. Filtrowanie i DMARC/DKIM/SPF – podnieś politykę do p=quarantine/reject po testach, aby utrudnić spoofing domeny.
  2. Reguły detección (SIEM/SEG): słowa kluczowe i TTP dot. podszywania się pod SoundCloud; alerty na domeny typosquatting.
  3. Twardnienie dostępu z VPN/WAF: jeśli Twój ruch do SoundCloud przechodzi przez egress VPN, miej plan obejścia (np. split-tunnel/allow-list tymczasowych wyjątków), do czasu pełnego przywrócenia funkcjonalności po stronie dostawcy.
  4. Higiena tożsamości: przegląd uprawnień w panelach „usług pomocniczych” i SaaS (least privilege, SSO, MFA, klucze sprzętowe).

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

W 2025 r. głośne kampanie ShinyHunters skupiały się na kradzieży danych z ekosystemów chmurowych i wymuszeniach (m.in. ofiary korzystające z Salesforce). Jeśli trop ShinyHunters przy SoundCloud się potwierdzi, byłby to kolejny przypadek kradzieży danych kontaktowych z usług towarzyszących, a nie z „rdzeniowego” systemu logowania/płatności. Różnica: tutaj skala oficjalnie opisana jest procentowo (20%) i obejmuje mało wrażliwe kategorie danych, choć realne ryzyko phishingu pozostaje wysokie.

Podsumowanie / kluczowe wnioski

  • SoundCloud opanował incydent i deklaruje brak bieżącego ryzyka dla platformy, ale skutki dla prywatności (phishing) mogą być odczuwalne miesiącami.
  • VPN-y: utrudnienia były efektem ubocznym działań naprawczych — firma pracuje nad pełnym przywróceniem zgodności.
  • Dane krytyczne (hasła/finanse) nie zostały naruszone wg SoundCloud, ale higiena tożsamości i 2FA to w tej sytuacji obowiązek.

Źródła / bibliografia

  • Oficjalny komunikat SoundCloud: „Protecting Our Users and Our Service”, 15 grudnia 2025. (SoundCloud)
  • BleepingComputer: „SoundCloud confirms breach after member data stolen, VPN access disrupted”, 15 grudnia 2025. (bleepingcomputer.com)
  • The Register: „SoundCloud bounces some VPNs as it cleans up cyberattack”, 16 grudnia 2025. (The Register)
  • Help Net Security: „SoundCloud breached, hit by DoS attacks”, 16 grudnia 2025. (Help Net Security)
  • SecurityWeek: „User Data Compromised in SoundCloud Hack”, 16 grudnia 2025. (SecurityWeek)

CyberVolk/VolkLocker: „nowy” ransomware z krytyczną wadą kryptograficzną

Wprowadzenie do problemu / definicja luki

13 grudnia 2025 r. opisano nową usługę RaaS grupy hacktywistycznej CyberVolk o nazwie VolkLocker. Debiut okazał się nieudany z powodu poważnych błędów kryptograficznych, które umożliwiają potencjalne odszyfrowanie danych bez płacenia okupu. Ransomware korzysta z automatyzacji przez Telegram i celuje w systemy Windows oraz Linux.

W skrócie

  • Co się stało: CyberVolk uruchomił RaaS „VolkLocker”, ale implementacja szyfrowania zawiera krytyczne błędy.
  • Dlaczego to ważne: Błąd w generowaniu/przechowywaniu kluczy (m.in. hard-coded klucz AES-GCM, ślady w katalogu %TEMP%) może pozwolić ofiarom na darmową dekryptację.
  • Jak atak działa: Golang, warianty na Windows/Linux, C2 i telemetria oparte o Telegram (automatyczne powiadomienia o infekcji, zrzuty ekranu, podstawowe info o systemie).
  • Kontekst: CyberVolk to pro-rosyjska formacja hacktywistyczna rozwijająca RaaS od 2024 r.; wcześniej łączono ją z atakami DDoS i kampaniami o motywacji politycznej.

Kontekst / historia / powiązania

CyberVolk pojawił się w 2024 r. jako kolektyw hacktywistyczny łączący DDoS i ransomware. Infrastruktura rekrutacyjna i operacyjna była (i jest) silnie oparta na Telegramie, co obniża barierę wejścia dla „afiliantów”. W 2025 r. grupa wróciła z nowym „produktem” RaaS – VolkLocker – ale popełniła kardynalne błędy projektowe.

Analiza techniczna / szczegóły luki

  • Język i platformy: VolkLocker jest napisany w Go i posiada buildy dla Windows i Linux.
  • Komunikacja i automatyzacja: Wykorzystanie Telegram API/Bot do C2 i automatycznych powiadomień o infekcjach (zrzut ekranu, podstawowe dane hosta). Niektóre warianty demonstrowały dodatkowe funkcje (np. keylogging).
  • Kryptografia (błąd krytyczny):
    • Zidentyfikowano twardo zakodowany klucz AES-256-GCM w binariach.
    • W niektórych próbkach klucz zapisywany jest jawnie do %TEMP%, co tworzy „skrót” do deszyfracji.
    • Konsekwencja: w praktyce możliwe jest odzyskanie danych bez okupu, jeśli ofiara pozyska klucz z procesu/artefaktów.
  • Dowody na „choroby wieku dziecięcego”: Publiczne analizy badaczy potwierdzają niedojrzałość projektu i błędy operacyjne w najnowszych wersjach VolkLocker.

Praktyczne konsekwencje / ryzyko

  • Dla ofiar: Istnieje realna szansa na odzyskanie danych bez płatności dzięki błędom w obsłudze kluczy. Niemniej wczesne warianty mogły już zaszyfrować zasoby – konieczna jest triage i analiza pamięci/artefaktów.
  • Dla SOC/IR: Telegram-based C2 i „łatwy onboarding” afiliantów zwiększają liczbę incydentów miernej jakości, ale o dużej częstotliwości. Zespół musi przygotować szybkie playbooki pod Go-ransomware i detekcje dla ruchu/artefaktów Telegrama.
  • Ewolucja zagrożenia: Takie błędy zwykle są szybko poprawiane – okno „darmowej dekryptacji” może być krótkie w kolejnych buildach. (Wniosek inferencyjny na bazie dotychczasowych kampanii RaaS.)

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów IR/SOC:

  1. Zabezpiecz artefakty: zrzuty pamięci, %TEMP%, katalogi robocze malware – szukaj hex-klucza i plików tymczasowych pozostawionych przez VolkLocker.
  2. Blokuj Telegram C2 (domeny/API, ruch wychodzący do botów) tam, gdzie to możliwe politycznie i operacyjnie.
  3. Sygnatury i YARA/EDR: zastosuj detekcje opublikowane przez badaczy (reguły pod Go, AES-GCM, ścieżki %TEMP%, artefakty procesu).
  4. Sprawdź dostępność dekryptorów w serwisach NoMoreRansom i Emsisoft – nawet jeśli dedykatora dla VolkLocker jeszcze nie ma, pojawienie się publicznego klucza może to zmienić.

Dla zespołów bezpieczeństwa/IT:

  • Segmentacja i kopie zapasowe (3-2-1, odseparowane, regularnie testowane na odtwarzanie).
  • Zasady egress ograniczające komunikację do platform komunikatorów (Telegram) z serwerów produkcyjnych.
  • Hardening stacji/serwerów i aktualizacje; monitorowanie tworzenia nietypowych plików w %TEMP%.
  • Playbook „free decrypt”: jeśli triage wskaże hard-coded key/plik z kluczem – procedura odzysku z minimalnym RTO/RPO. (Wniosek operacyjny)

Różnice / porównania z innymi przypadkami

  • Błędy klucza w RaaS zdarzały się wcześniej (np. w młodych rodzinach ransomware), ale jednoczesne hard-codowanie klucza i pozostawianie go w plikach tymczasowych to rzadkie, podwójne potknięcie zwiększające szanse na odzysk. W porównaniu z dojrzałymi rodzinami (LockBit/BlackCat) poziom OPSEC w VolkLocker jest istotnie niższy. (Wniosek porównawczy oparty na źródłach technicznych i praktyce branżowej)

Podsumowanie / kluczowe wnioski

  • CyberVolk wraca z RaaS, ale VolkLocker cierpi na poważne wady kryptograficzne, co tworzy okazję do darmowej dekryptacji w obecnych wersjach.
  • Automatyzacja przez Telegram obniża próg wejścia dla afiliantów i może zwiększyć szum incydentów – przygotuj detekcje i blokady.
  • Okno okazji może się zamknąć wraz z poprawkami – działaj szybko: artefakty, pamięć, klucze, testy dekryptorów. (Wniosek operacyjny)

Źródła / bibliografia

  1. BleepingComputer – „CyberVolk’s ransomware debut stumbles on cryptography weakness”, 13.12.2025. (BleepingComputer)
  2. SentinelOne – „CyberVolk Returns | Flawed VolkLocker…”, analiza techniczna (2025). (SentinelOne)
  3. SOC Prime – „VolkLocker ransomware detection” (Windows/Linux, hard-coded AES-GCM). (SOC Prime)
  4. SentinelOne – „CyberVolk: A deep dive into the hacktivists…” (kontekst 2024). (SentinelOne)
  5. NoMoreRansom / Emsisoft – katalogi narzędzi dekryptujących (ogólne wytyczne i potencjalne aktualizacje). (nomoreransom.org)

DOJ i CISA ostrzegają: rosyjskie grupy CARR/NoName057(16) i Z-Pentest celują w infrastrukturę krytyczną (woda, energia, żywność)

Wprowadzenie do problemu / definicja luki

9 grudnia 2025 r. amerykański Departament Sprawiedliwości (DOJ) i CISA wraz z innymi agencjami opublikowały wspólne ostrzeżenie dotyczące kampanii prorosyjskich „hacktywistów” uderzających w systemy OT/ICS w sektorach wody i ścieków, energii oraz żywności. Ataki wykorzystują przede wszystkim słabo zabezpieczone, wystawione do internetu połączenia VNC do paneli HMI, co umożliwia zdalne manipulowanie procesami technologicznymi i wywoływanie efektów fizycznych.

W skrócie

  • Kto atakuje: Cyber Army of Russia Reborn (CARR), NoName057(16), Z-Pentest oraz powiązana od 2025 r. grupa Sector16.
  • Jak atakują: skanowanie otwartych portów VNC, brutalne łamanie haseł/wykorzystanie haseł domyślnych, dostęp do HMI/SCADA, zmiany parametrów i wyłączanie alarmów, czasem równoległe DDoS.
  • Skutki: realne oddziaływanie na procesy – m.in. rozlanie setek tysięcy galonów wody pitnej i incydent z amoniakiem w zakładzie mięsnym w Los Angeles (XI 2024).
  • Powiązania z państwem: CARR miała być finansowana/kierowana przez GRU; NoName057(16) – projekt sankcjonowany przez państwo, z własnym narzędziem DDoSia.

Kontekst / historia / powiązania

Wraz z eskalacją wojny Rosji przeciw Ukrainie (2022) wzrosła liczba prorosyjskich grup, które zaczęły łączyć DDoS z ingerencjami w OT. W 2024 r. administratorzy CARR i NoName zainicjowali Z-Pentest, deklarując specjalizację w intruzjach OT i porzucając DDoS na rzecz „głośniejszych” włamań do HMI. W 2025 r. pojawiła się także Sector16 współpracująca z Z-Pentest.

Równolegle trwa presja prawna i „kinetyczna”: w lipcu 2025 r. operacja międzynarodowa Eastwood (Europol/Eurojust) uderzyła w infrastrukturę NoName057(16), a 9 grudnia 2025 r. DOJ ogłosił dwa akty oskarżenia wobec obywatelki Ukrainy powiązanej z CARR i NoName.

Wcześniej (19 lipca 2024 r.) OFAC nałożył sankcje na liderkę CARR Julię Pankratovą i kluczowego hakera Denisa Degtiarenkę.

Analiza techniczna / szczegóły luki

Wspólna porada CISA/NSA/FBI/EPA/DOE/DISA identyfikuje powtarzalny, tani łańcuch działań (TTP), nastawiony na oportunistyczne cele:

  • skanowanie internetu w poszukiwaniu wystawionych HMI/SCADA z otwartym VNC,
  • użycie VPS do bruteforce i/lub korzystanie z domyślnych/słabych haseł,
  • przejęcie widoku i sterowania w HMI (zmiany parametrów, nazw urządzeń, wyłączanie alarmów, restart),
  • rejestracja ekranu/„proofy” i propaganda w Telegramie; czasem DDoS równolegle, by ułatwić wejście do sieci.

Autorzy wskazują, że sprawcy często nie rozumieją w pełni procesów przemysłowych (niska „maturity”), ale mimo to doprowadzają do fizycznych skutków i „loss of view”, wymuszając ręczne przejęcie sterowania przez operatorów.

Praktyczne konsekwencje / ryzyko

  • Woda i ścieki: manipulacje SCADA doprowadziły do rozlania „setek tysięcy galonów” wody pitnej; DOJ łączy te incydenty z CARR.
  • Żywność: atak na zakład mięsny w Los Angeles (XI 2024) – skażenie/utylizacja mięsa i wyciek amoniaku.
  • Energetyka i inne sektory: czasowe utraty widoczności, defacement HMI, przerwy w działaniu, koszty operacyjne i reputacyjne.

Rekomendacje operacyjne / co zrobić teraz

Architektura i dostęp

  • Bezwzględnie zablokuj VNC z internetu; jeśli VNC musi istnieć, tylko przez VPN + MFA, allow-listy i jump-hosty; rozważ całkowitą eliminację VNC z OT.
  • Segmentacja sieci (ISA/IEC 62443), oddzielenie stref IT/OT, dostęp uprzywilejowany (PAM) dla kont operatorów HMI.

Twardnienie HMI/SCADA

  • Zmień domyślne hasła, wymuś MFA tam, gdzie możliwe; wyłącz nieużywane usługi, ogranicz konta serwisowe.
  • Wymuś lock-out po nieudanych logowaniach; monitoruj nietypowe sesje VNC/RDP.

Monitoring i detekcja

  • Rejestrowanie i alertowanie na: otwarcie portów VNC, nowe połączenia z VPS/hostingów, nagłe wyłączenia alarmów HMI, zmiany parametrów procesu.
  • Wdrażaj mapowanie do MITRE ATT&CK for ICS i testy w oparciu o znane TTP z CSA.

Procedury i ćwiczenia

  • Playbooki na loss of view i ręczne przejęcie sterowania; regularne ćwiczenia z zespołami utrzymania ruchu.
  • Kanały eskalacji i komunikacja z regulatorami/CSIRT-ami sektorowymi.

Zarządzanie ryzykiem dostawców

  • Kontrole zdalnego serwisu (czasowe dostępy, jednorazowe poświadczenia), SBOM dla elementów ICS, weryfikacja zabezpieczeń paneli HMI produkowanych przez OEM.

Różnice / porównania z innymi przypadkami

W odróżnieniu od klasycznych kampanii APT (np. długotrwałe, ukryte infiltracje), opisywane ataki są głośne i oportunistyczne – mają dawać szybki efekt propagandowy (screeny z HMI), ale i tak potrafią wywoływać realne skutki fizyczne. Z-Pentest odróżnia się od typowych „DDoS-brigad” tym, że celuje bezpośrednio w OT/HMI, a nie wyłącznie w warstwę www/IT.

Podsumowanie / kluczowe wnioski

  • Największym wektorem ryzyka jest VNC do HMI wystawione do internetu.
  • Grupy CARR/NoName/Z-Pentest mają (według DOJ/CISA) związki organizacyjne/finansowe z rosyjskimi strukturami państwowymi, a ich działania wykraczają poza DDoS, dotykając realnych procesów przemysłowych.
  • Nawet „małe” zakłady i gminne wodociągi są na celowniku – ataki są automatycznie skanowane i niezależne od skali ofiary.

Źródła / bibliografia

  • The Record: przegląd ostrzeżeń DOJ/CISA i powiązanych działań (10 grudnia 2025). (The Record from Recorded Future)
  • DOJ: „Justice Department Announces Actions to Combat Two Russian State-Sponsored Cyber Criminal Hacking Groups” (9 grudnia 2025). (Department of Justice)
  • Wspólna porada CISA/NSA/FBI/EPA/DOE/DC3: „Pro-Russia Hacktivists Conduct Opportunistic Attacks Against Critical Infrastructure” (9 grudnia 2025).
  • OFAC: sankcje na liderów CARR (19 lipca 2024). (U.S. Department of the Treasury)
  • Europol: Operacja Eastwood przeciw NoName057(16) (16 lipca 2025). (Europol)