Archiwa: Security News - Strona 228 z 297

Rumuński urząd gospodarki wodnej „Apele Române” zaatakowany ransomware: ok. 1000 systemów zaszyfrowanych przez nadużycie BitLockera

Wprowadzenie do problemu / definicja luki

W weekend 20–22 grudnia 2025 rumuńska administracja gospodarki wodnej Administrația Națională „Apele Române” (ANAR) padła ofiarą ataku ransomware, który objął ok. 1000 systemów w centrali i 10 z 11 regionalnych administracji dorzeczy. Incydent dotknął głównie warstwę IT (serwery i stacje robocze), a nie systemy operacyjne OT sterujące infrastrukturą hydrotechniczną.

To zdarzenie jest dobrym przykładem trendu, który obserwujemy coraz częściej w sektorze publicznym i krytycznym: „ransomware” nie musi oznaczać wgrania egzotycznego szyfratora. Atakujący potrafią wykorzystać legalne mechanizmy systemu (tzw. living-off-the-land), aby uzyskać efekt paraliżu, a jednocześnie utrudnić detekcję i analizę.

W skrócie

Skala: ok. 1000 zaszyfrowanych/„zablokowanych” systemów; 10/11 jednostek regionalnych dotkniętych incydentem.
Zakres: serwery GIS, bazy danych, e-mail/web, DNS oraz stacje robocze Windows.
Technika: nadużycie wbudowanego w Windows BitLockera do zablokowania danych.
OT bez zmian: według komunikatów systemy OT nie zostały naruszone, a infrastruktura hydrotechniczna miała działać normalnie (koordynacja przez łączność głosową/radiową).
Żądanie okupu: pozostawiono notę z żądaniem kontaktu w terminie 7 dni.

Kontekst / historia / powiązania

„Apele Române” odpowiada za zarządzanie zasobami wodnymi i elementami infrastruktury hydrotechnicznej, a więc obszar, który w wielu krajach bywa klasyfikowany jako krytyczny (z punktu widzenia ciągłości działania państwa i bezpieczeństwa publicznego). Dlatego nawet „tylko IT” może mieć realne konsekwencje operacyjne: prognozowanie, raportowanie, dyspozytornie, obieg dokumentów, GIS i łączność to często krwioobieg działań terenowych.

W tle pojawia się też aspekt systemowy: w komunikatach cytowanych przez media wskazywano, że infrastruktura ANAR nie była wcześniej objęta krajowym systemem ochrony krytycznych infrastruktur IT, a po incydencie rozpoczęto działania integracyjne.

Analiza techniczna / szczegóły incydentu

1) Co dokładnie zostało dotknięte?

Z opisu incydentu wynika, że atak objął mieszankę typową dla środowisk administracji publicznej:

GIS (systemy informacji geograficznej),
serwery baz danych,
poczta i usługi web,
serwery DNS,
stacje robocze Windows oraz Windows Server.

To zestaw krytyczny dla pracy operacyjnej (planowanie, mapy, dane terenowe, komunikacja, rozliczenia), nawet jeśli sterowanie OT odbywa się osobnymi kanałami.

2) „Ransomware” przez BitLockera – dlaczego to ważne?

Najciekawszy technicznie element tej sprawy to ustalenie, że atakujący użyli BitLockera (wbudowanej funkcji Windows do szyfrowania dysków) w sposób złośliwy, by zablokować pliki na przejętych systemach.

To ma kilka praktycznych implikacji dla obrony:

mniej „sygnatur” malware – bo narzędzie jest legalne i często używane przez administratorów,
wyższe ryzyko błędnej interpretacji w SIEM/EDR, jeśli reguły „admin activity” są zbyt szerokie,
kluczowe staje się zarządzanie kluczami odzyskiwania (escrow) i kontrola uprawnień do włączania BitLockera.

3) Atak wektor i atrybucja

Na moment publikacji doniesień nie wskazano publicznie jednoznacznego wektora wejścia ani sprawcy (brak przypisania do konkretnej grupy).

Warto zauważyć, że przy scenariuszu „BitLocker jako szyfrator” atakujący zwykle potrzebują:

uprawnień administratora lokalnego lub domenowego (żeby masowo włączać szyfrowanie),
możliwości uruchamiania poleceń zdalnie (np. przez narzędzia administracyjne lub skrypty),
dostępu do kontrolerów domeny / polityk (GPO), jeśli szyfrowanie rozlewa się na dużą flotę.

To nie jest dowód na konkretną technikę w tym przypadku, ale pomaga zrozumieć, dlaczego wnioski obronne zwykle koncentrują się na AD, segmentacji i kontroli uprawnień.

Praktyczne konsekwencje / ryzyko

1) Ryzyko dla ciągłości działania

Nawet przy braku naruszenia OT, awaria warstwy IT potrafi:

opóźnić reakcję na zdarzenia hydrologiczne (mapy, dane, raporty),
utrudnić koordynację pracy terenowej,
zablokować obieg dokumentów i komunikację (e-mail),
zwiększyć ryzyko błędów operacyjnych, gdy organizacja przechodzi na tryb ręczny/telefoniczny.

W materiałach podkreślano, że dyspozytornie miały przejść na łączność głosową (telefon/radio), a podstawowe działania miały być kontynuowane.

2) Ryzyko danych i „podwójnego wymuszenia”

W dostępnych informacjach mowa jest o szyfrowaniu/zablokowaniu (ransom note), ale brak potwierdzenia publicznego, czy doszło do eksfiltracji danych.
W praktyce wiele kampanii łączy szyfrowanie z kradzieżą danych, więc organizacje zwykle muszą równolegle prowadzić analizę pod kątem wycieku (logi proxy, ruch wychodzący, konta uprzywilejowane, narzędzia do transferu).

3) Aspekt prawny i śledczy

Media informowały także o reakcji organów ścigania – wątek postępowania karnego pojawił się w relacjach dot. incydentu.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „do wdrożenia” w organizacjach, które chcą ograniczyć ryzyko scenariusza „ransomware przez BitLocker” i podobnych ataków na IT w instytucjach publicznych/CI.

1) Kontrola BitLockera i kluczy odzyskiwania

Wymuś centralny escrow kluczy odzyskiwania (AD/Azure AD/MDM) i audytuj pokrycie.
Ogranicz, kto może włączać BitLockera masowo (role, GPO, MDM), oraz monitoruj zmiany polityk.
W SIEM/EDR zbuduj alerty na:
- nagłe fale „Enable BitLocker / manage-bde”,
- masowe modyfikacje ochrony dysku,
- nietypowe procesy uruchamiające komponenty BitLockera (np. z kontekstu usług zdalnych).

2) Ochrona AD i kont uprzywilejowanych

Wprowadź Tiering / PAW (oddzielne stacje dla adminów), MFA wszędzie, gdzie to możliwe.
Zastosuj zasadę Just Enough Administration i Just-In-Time dla uprawnień wysokiego ryzyka.
Odetnij możliwość lateral movement: segmentacja, blokady administracji z „user VLAN” do serwerów.

3) Twarde kopie zapasowe i odtwarzanie

Kopie 3-2-1 + offline/immutable (nieosiągalne z domeny).
Regularne testy odtwarzania: RTO/RPO dla GIS, DB, poczty, DNS.
Oddziel backup adminów od zwykłego AD (inny las/tenant lub przynajmniej inne konta i strefy zaufania).

4) Reakcja na incydent (checklista „pierwsze 24–72 h”)

Izolacja segmentów, blokada kont podejrzanych, rotacja haseł uprzywilejowanych.
Szybkie ustalenie „blast radius”: które hosty mają włączony BitLocker i czy klucze są dostępne.
Zabezpieczenie artefaktów (logi, obrazy dysków krytycznych systemów) zanim rozpocznie się masowe odtwarzanie.

5) Polityka okupu

W komunikatach przywoływano podejście, by nie negocjować z atakującymi w ramach rekomendacji krajowych instytucji cyber. Niezależnie od polityki organizacji, decyzja o płatności powinna wynikać z analizy prawnej, ryzyka oraz realnych możliwości odtworzenia usług (a nie z presji czasu w nocie okupu).

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

Wątek wyróżniający tę sprawę na tle „klasycznych” ataków ransomware to użycie BitLockera zamiast dedykowanego szyfratora. To wpisuje się w szerszą kategorię ataków „LOTL”, gdzie przestępcy minimalizują własny kod na ofierze, a maksymalizują użycie narzędzi wbudowanych lub powszechnych (co utrudnia detekcję i atrybucję).

BleepingComputer wskazywał też, że to kolejny głośny incydent ransomware w Rumunii w ostatnich latach, przypominając m.in. o wcześniejszych atakach na podmioty krytyczne (energetyka, ochrona zdrowia).

Podsumowanie / kluczowe wnioski

Incydent w „Apele Române” pokazuje, że paraliż IT w instytucji odpowiedzialnej za zasoby wody może być poważnym problemem nawet bez naruszenia OT.
Technicznie najważniejsza lekcja to ryzyko nadużycia BitLockera: legalna funkcja bezpieczeństwa może stać się narzędziem wymuszenia, jeśli atakujący zdobędą uprawnienia administracyjne.
Dla obrony kluczowe są: kontrola uprawnień (AD), segmentacja, backupy offline/immutable oraz monitoring aktywności związanej z szyfrowaniem dysków.

Źródła / bibliografia

BleepingComputer – raport o ataku na Romanian Waters (ANAR), skala i BitLocker. (BleepingComputer)
Digi24 – szczegóły dot. zakresu systemów, BitLocker i kontekst działań krajowych zespołów. (Digi24)
HotNews – aktualizacja o braku wpływu na działania kluczowe, komunikacja głosowa, OT bez zmian. (HotNews.ro)
Europa Liberă România (RFE/RL) – informacje o bezpieczeństwie obiektów hydrotechnicznych i wątku śledczym. (Europa Liberă România)
The Register – dodatkowe potwierdzenie skali i czasu rozpoczęcia ataku. (go.theregister.com)

Fałszywe zaproszenia na „koncert noworoczny” w kampanii Paper Werewolf (GOFFEE): jak działa backdoor EchoGather i dlaczego XLL to problem

Wprowadzenie do problemu / definicja luki

Spear-phishing nadal wygrywa w atakach ukierunkowanych, bo omija „twarde” zabezpieczenia przez… człowieka. W opisywanej kampanii przynęta była wyjątkowo prozaiczna: fałszywe zaproszenie na koncert noworoczny skierowane do rosyjskojęzycznych odbiorców (m.in. środowisk wojskowych i sektora obronnego). Kluczowe jest jednak nie samo „zaproszenie”, lecz nośnik wykonania kodu: plik Excel XLL.

XLL to w praktyce biblioteka DLL ładowana przez Excela jako dodatek. W przeciwieństwie do makr VBA, XLL działa jako kod natywny ładowany do procesu Excela, co może utrudniać kontrolę politykami „anti-macro” i detekcję opartą o typowe heurystyki makr.

W skrócie

Badacze powiązali kampanię z grupą Paper Werewolf (GOFFEE) i nowym backdoorem EchoGather.
Wejście obejmowało złośliwy plik XLL (dodatek Excela) oraz alternatywne łańcuchy z WinRAR i plikami LNK/PowerShell.
EchoGather zbiera dane o hoście, beaconuje do C2 ukrytego pod ścieżkami wyglądającymi jak serwis dostaw jedzenia i wspiera m.in. zdalne komendy oraz eksfiltrację plików.
Intezer wskazuje również element „AI tradecraft”: przynęty PDF wyglądały na generowane AI i zawierały błędy językowe oraz zniekształcony symbol (imitacja godła).
Reuters podkreśla szerszy trend: łatwo dostępne narzędzia AI obniżają próg wejścia dla tworzenia wiarygodnych (lub „prawie wiarygodnych”) dokumentów-wabików.

Kontekst / historia / powiązania

GOFFEE (znany też jako Paper Werewolf) to aktor obserwowany co najmniej od 2022 r., ukierunkowany na podmioty w Federacji Rosyjskiej. Kaspersky opisywał jego kampanie z użyciem m.in. złośliwych załączników phishingowych i zmian w narzędziach na przestrzeni lat (np. wcześniejsze komponenty typu Owowa oraz późniejsze schematy dystrybucji).

W 2024 r. (wg Kaspersky) grupa wprowadzała nowe implanty i odchodziła od wcześniejszych komponentów na rzecz innych technik w ekosystemie ataku. Taki „ciągły ruch” w TTP jest typowy dla zespołów, które:

mają jeden geograficzny/branżowy fokus,
testują nowe metody wejścia (np. inne formaty plików),
próbują ominąć zmiany w zabezpieczeniach endpointów i poczty.

Na tym tle XLL jako nośnik wygląda jak logiczny krok: organizacje często zaostrzają polityki makr, ale dodatki DLL-owe wciąż bywają gorzej „obudowane” kontrolami.

Analiza techniczna / szczegóły luki

1) Wejście: XLL jako dodatek Excela

W kampanii opisanej przez Intezer próbki XLL trafiły m.in. do VirusTotal w końcówce października 2025 r.
XLL to DLL ładowany przez Excel, zwykle z eksportami typu xlAutoOpen, ale tu ciekawostka: logika nie była klasycznie „przywiązana” do standardowego xlAutoOpen. Intezer opisuje uruchomienie poprzez zachowanie w DllMain i opóźnienie wykonania do zdarzenia związanego z zakończeniem wątku (DLL_THREAD_DETACH), co może utrudniać detekcję sandboxom i mechanizmom analizującym „early execution”.

2) Loader → dropper → uruchomienie payloadu

Intezer wskazuje, że loader zrzuca plik jako mswp.exe w ścieżce %APPDATA%\Microsoft\Windows, a następnie uruchamia go w trybie ukrytym (CREATE_NO_WINDOW) i przechwytuje stdout/stderr przez pipe’y.

3) EchoGather: co robi backdoor

EchoGather (64-bit) ma twardo zaszytą konfigurację i łączy się z C2 przez HTTP(S) z użyciem WinHTTP. Zbiera m.in. adresy IPv4, nazwę hosta (NetBIOS), użytkownika, domenę stacji, PID i ścieżkę binarki; dane koduje Base64 i wysyła w pętli z losowym opóźnieniem rzędu kilku minut.

C2/„maskowanie ruchem”: w analizowanej próbce adres C2 był zbudowany tak, by ścieżka wyglądała jak elementy serwisu dostaw (np. „dostavka/…/sushi/…/msk/…”). To dokładnie ten typ kamuflażu, który potrafi „zginąć” w proxy logach, jeśli organizacja nie ma dobrego profilowania ruchu wychodzącego.

Komendy: Intezer opisuje cztery kategorie poleceń, w tym:

zdalne wykonanie komend (uruchamiane przez cmd.exe /C …),
zwrot konfiguracji,
eksfiltrację plików porcjowaną w chunki,
zdalny zapis pliku na maszynie ofiary.

4) Przynęty (decoy) i wątek „AI-generated”

W infrastrukturze powiązanej z kampanią znaleziono skrypty PowerShell dekodujące dwie „porcje” Base64: PDF-wabik i payload EchoGather. PDF był opisany jako zaproszenie na koncert dla „wysokich rangą” oficerów, ale zawierał znamiona sztucznej generacji: błędy literowe w cyrylicy, literówki oraz nieudolną imitację godła (dwugłowego orła).

Reuters zwraca uwagę, że to dobry przykład, jak dostępne narzędzia AI mogą pomagać w skalowaniu tworzenia dokumentów-wabików (nawet jeśli nadal da się je czasem „wyczuć” po jakości).

5) Alternatywny łańcuch: WinRAR i CVE-2025-8088

Intezer opisuje też pivot na domenę, który doprowadził do archiwum RAR wykorzystującego podatność oznaczoną jako CVE-2025-8088: nadużycie NTFS ADS + path traversal, pozwalające na zapis w nieoczekiwanych lokalizacjach (np. elementy Startup). W łańcuchu pojawiają się m.in. pliki LNK uruchamiające BAT i finalnie PowerShell pobierający skrypt z serwera zewnętrznego, który znów wypakowuje PDF + EchoGather.

Praktyczne konsekwencje / ryzyko

Dla organizacji kluczowe ryzyka są trzy:

Ciche rozpoznanie + wyciek danych: EchoGather jest nastawiony na rekonesans i transfer plików, czyli klasyczny profil cyber-szpiegowski.
Elastyczność operacyjna atakującego: zdalne komendy i zdalny zapis plików to „pomost” do dalszej eskalacji, doinstalowania narzędzi, ruchu bocznego i dłuższej obecności w sieci.
Ryzyko łańcucha dostaw/produkcji (w sektorach obronnych i high-tech): Reuters wskazuje, że cele sugerują zainteresowanie wglądem w produkcję, łańcuch dostaw i R&D.

Nawet jeśli Twoja organizacja nie jest w „docelowej geografii”, ten case jest ważny, bo pokazuje dwa trendy, które łatwo przenoszą się na inne kampanie: XLL jako nośnik i „AI-wabiki”.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h)

Zablokuj/ogranicz przyjmowanie XLL w poczcie (gateway) i w systemach wymiany plików; dodaj kontrolę również dla archiwów RAR zawierających LNK/BAT/PS1.
Hunt na endpointach:
- Excel uruchamia nietypowe procesy potomne (np. mswp.exe, cmd.exe, powershell.exe) i to jeszcze z lokalizacji użytkownika/AppData,
- obecność mswp.exe w %APPDATA%\Microsoft\Windows,
- ruch wychodzący HTTP(S) do domen/ścieżek wyglądających „dziwnie tematycznie” (np. „dostavka/…/sushi/…”) oraz beaconing co ~5–6 minut.
Aktualizacje/patching: jeśli w środowisku jest WinRAR, zweryfikuj wersje i podatności oraz wprowadź zasadę „RAR-y tylko z zaufanych źródeł” (to często realniejszy kontrolny punkt niż próba edukowania o każdej CVE).

Utwardzenie (1–4 tygodnie)

ASR/EDR hardening: reguły blokujące procesy potomne Office, uruchamianie skryptów z katalogów użytkownika, oraz egzekwowanie podpisu dla wybranych typów wykonywalnych (tam, gdzie to realne operacyjnie).
Allowlisting (AppLocker/WDAC): ogranicz wykonywanie binarek z %APPDATA%, %TEMP% i podobnych lokalizacji użytkownika, jeżeli profil biznesowy na to pozwala.
Kontrola dodatków Office: polityki ograniczające ładowanie dodatków/plików wykonywalnych jako add-in oraz „mark-of-the-web”/strefy internetowe w łańcuchu dostarczania (w praktyce: sklejone z politykami przeglądarki, poczty i EDR).
Higiena poczty: edukacja i procedury weryfikacji załączników (adres nadawcy, oczekiwany kontekst biznesowy, potwierdzenie kanałem alternatywnym). CERT Polska dobrze opisuje praktyczne zasady obchodzenia się z podejrzanymi załącznikami.

Różnice / porównania z innymi przypadkami

Makra VBA vs XLL: makra to kod skryptowy uruchamiany w ramach silnika makr i coraz częściej blokowany politykami (np. „block macros from the internet”). XLL to natywny DLL ładowany do procesu Excela (LoadLibrary), co daje atakującemu większą swobodę i bywa trudniejsze do objęcia tymi samymi kontrolami co makra.

Ewolucja GOFFEE: Kaspersky opisywał wcześniejsze schematy dystrybucji GOFFEE oparte o phishing i różne implanty. Kampania EchoGather pokazuje „eksperymentowanie” z nowym wektorem (XLL) przy utrzymaniu starej, sprawdzonej logiki: decoy document jako zasłona dymna + uruchomienie payloadu w tle.

Podsumowanie / kluczowe wnioski

Ta kampania to nie tylko „phishing z PDF-em”, ale przede wszystkim praktyczny przykład przejścia na XLL jako nośnik uruchomienia kodu w środowiskach, gdzie makra są już mocno utrudnione.
EchoGather ma funkcjonalności typowe dla implantów szpiegowskich (rekonesans, komendy, transfer plików) i komunikuje się z C2 w sposób, który może wyglądać „normalnie” w logach bez dobrej telemetrii i profilowania ruchu.
Wabiki generowane (lub wspomagane) przez AI będą się pojawiać coraz częściej — nie dlatego, że są idealne, tylko dlatego, że są tanie i szybkie w produkcji.

Jeśli chcesz, mogę też przygotować krótką „sekcję SOC” do wklejenia w runbook: gotowe hipotezy huntingowe, pola do sprawdzenia w EDR/SIEM i listę priorytetowych alertów pod ten łańcuch.

Źródła / bibliografia

Intezer – Tracing a Paper Werewolf campaign through AI-generated decoys and Excel XLLs (Intezer)
The Record (Recorded Future News) – Cyber spies use fake New Year concert invites to target Russian military (The Record from Recorded Future)
Kaspersky Securelist – GOFFEE’s recent attacks: new tools and techniques (Securelist)
Reuters – Russian defense firms targeted by hackers using AI, other tactics (Reuters)
CERT Polska – Uważaj na fałszywe załączniki! (cert.pl)

Ponad 115 tys. firewalli WatchGuard Firebox wciąż podatnych na aktywnie wykorzystywaną lukę RCE (CVE-2025-14733)

Wprowadzenie do problemu / definicja luki

WatchGuard potwierdził aktywne próby wykorzystania krytycznej podatności typu remote code execution (RCE) w zaporach Firebox z systemem Fireware OS. Luka ma identyfikator CVE-2025-14733, dotyczy procesu iked (Internet Key Exchange daemon) i pozwala na zdalne, nieuwierzytelnione wykonanie kodu przy spełnieniu określonych warunków konfiguracyjnych. Producent ocenia ją jako Critical (CVSS 9.3).

Skala problemu jest duża: według analiz przytaczanych w mediach branżowych, >115 tys. instancji Fireboxów wystawionych do Internetu pozostawało niezałatanych w trakcie opisywanej kampanii ataków (różne źródła podają też wyniki skanów rzędu ~125 tys. IP).

W skrócie

Co to jest: krytyczne RCE w Fireware OS / iked (out-of-bounds write).
Kiedy groźne: gdy urządzenie ma/ miało konfigurację IKEv2 VPN (Mobile User VPN IKEv2 lub BOVPN IKEv2 z dynamicznym peerem); ryzyko może utrzymywać się nawet po „wyczyszczeniu” części ustawień, jeśli pozostaje BOVPN do statycznego peera.
Status: WatchGuard udostępnił poprawki (m.in. 2025.1.4, 12.11.6, 12.5.15, 12.3.1 Update 4).
Eksploatacja: producent i media potwierdzają aktywne próby ataków „in the wild”; CISA dodała CVE do katalogu KEV.

Kontekst / historia / powiązania

To kolejny przykład trendu, w którym atakujący polują na urządzenia brzegowe (firewalle/VPN), bo są:

wystawione do Internetu,
często zarządzają „kluczowymi” tunelami i ruchem,
a kompromitacja daje wygodny przyczółek do dalszej penetracji sieci.

Dodatkowo WatchGuard wprost wskazuje, że obserwowane próby wykorzystania CVE-2025-14733 wpisują się w szerszą kampanię wymierzoną w infrastrukturę edge u wielu dostawców.

Analiza techniczna / szczegóły luki

Mechanizm

CVE-2025-14733 to out-of-bounds write w procesie iked Fireware OS, co może prowadzić do zdalnego wykonania kodu bez uwierzytelnienia.

Zakres wersji podatnych (wg producenta)

Podatne są wersje Fireware OS:

11.10.2 – 11.12.4_Update1
12.0 – 12.11.5
2025.1 – 2025.1.3

Warunek „czy mój Firebox jest realnie narażony?”

Kluczowy niuans: WatchGuard wyjaśnia, że urządzenia są podatne na atak tylko wtedy, gdy w grę wchodzi konfiguracja IKEv2 VPN (Mobile User VPN IKEv2 lub BOVPN IKEv2 z dynamicznym gateway peer). Co więcej, nawet jeśli część konfiguracji została usunięta, urządzenie może nadal pozostać w ryzyku, gdy nadal istnieje BOVPN do statycznego peera.

IoA (Indicators of Attack) i objawy

WatchGuard opublikował Indicators of Attack pomocne w detekcji prób eksploatacji/kompromitacji, m.in.:

IP-y powiązane z aktywnością atakujących (producent rozróżnia znaczenie połączeń outbound vs inbound),
logi sugerujące nietypowe zachowanie IKEv2 (np. nietypowo długi łańcuch certyfikatów / ponadnormatywnie duży payload CERT),
symptomy na urządzeniu: zawieszenie lub crash iked, co może zrywać negocjacje/re-key tuneli.

Praktyczne konsekwencje / ryzyko

Jeśli atak się powiedzie, skutki typowe dla przejęcia firewalla/VPN są bardzo poważne:

pełne przejęcie urządzenia brzegowego i ruchu,
możliwość pivotu do sieci wewnętrznej (AD, serwery plików, backupy),
podsłuch/ingerencja w tunele, podstawienie reguł, trwałość dostępu,
ryzyko incydentu ransomware lub eksfiltracji danych.

Ryzyko jest podbite przez fakt, że skany Internetu wskazują dziesiątki/ponad sto tysięcy potencjalnie podatnych instancji, a luka jest łączona z aktywną eksploatacją.

Rekomendacje operacyjne / co zrobić teraz

1) Patch natychmiast (priorytet P0)

WatchGuard udostępnił poprawione wersje, m.in.:

Fireware 2025.1.4+
Fireware 12.11.6+
Fireware 12.5.15+
Fireware 12.3.1 Update 4+

Uwaga: media wskazują, że Fireware 11.x jest EoL i może nie otrzymać poprawek — w takim przypadku realnie wchodzi w grę upgrade sprzętu/wersji albo odcięcie ekspozycji/usługi.

2) Ustal ekspozycję i warunki podatności

Sprawdź, czy na urządzeniu jest (lub była) konfiguracja IKEv2 VPN (Mobile User VPN IKEv2, BOVPN IKEv2 z dynamic gateway peer).
Zweryfikuj, czy nie pozostały elementy, które utrzymują ryzyko (np. BOVPN do statycznego peera).

3) Detekcja i hunting (krótkoterminowo)

Monitoruj IoA od WatchGuard: podejrzane IP, wskazane wzorce logów, objawy zawieszeń/crashy iked.
Jeżeli widzisz symptomy kompromitacji: traktuj urządzenie jak potencjalnie przejęte.

4) Rotacja sekretów po incydencie

WatchGuard rekomenduje rotację lokalnie przechowywanych sekretów na podatnych firewallach, jeśli wykryto oznaki złośliwej aktywności. W praktyce obejmuje to co najmniej: klucze/pre-shared keys, hasła kont lokalnych, certyfikaty/klucze prywatne używane przez VPN (w zależności od wdrożenia).

5) Minimalizacja powierzchni ataku (dobre praktyki)

Niezależnie od patchowania:

ogranicz wystawienie usług VPN do niezbędnych adresów (ACL, geo, allowlist),
chroń interfejsy zarządzania (MFA, dostęp tylko z sieci administracyjnych),
zbieraj logi z urządzeń brzegowych do SIEM i ustaw alerty na anomalie w IKEv2.

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

BleepingComputer zwraca uwagę na podobieństwo do wcześniejszej luki w Fireboxach (CVE-2025-9242), co praktycznie oznacza dwie lekcje:

IKE/IPsec na brzegu pozostaje „gorącą” powierzchnią ataku,
po publikacji poprawek okno czasowe do masowego skanowania i prób eksploatacji bywa bardzo krótkie — dlatego proces patchowania urządzeń edge powinien działać w trybie „emergency change”.

Podsumowanie / kluczowe wnioski

CVE-2025-14733 to krytyczne, aktywnie wykorzystywane RCE w WatchGuard Firebox / Fireware OS (iked).
Najważniejszy krok to natychmiastowa aktualizacja do wersji zawierających fix (np. 2025.1.4 / 12.11.6 / 12.5.15 / 12.3.1 Update 4).
Równolegle trzeba wykonać weryfikację konfiguracji IKEv2 i przeprowadzić hunting po IoA oraz symptomach iked.
W środowiskach na EoL realnym remedium może być upgrade/ wymiana lub zdecydowane ograniczenie ekspozycji usług.

Źródła / bibliografia

WatchGuard PSIRT Advisory: WGSA-2025-00027 (CVE-2025-14733) (watchguard.com)
WatchGuard Blog: dostępne wersje Fireware 2025.1.4 / 12.11.6 / 12.5.15 / 12.3.1 Update 4 (watchguard.com)
BleepingComputer: „Critical RCE flaw impacts over 115,000 WatchGuard firewalls” (BleepingComputer)
SecurityWeek: „WatchGuard Patches Firebox Zero-Day Exploited in the Wild” (SecurityWeek)
CISA: Known Exploited Vulnerabilities Catalog (wpis dla CVE-2025-14733) (cisa.gov)

Cyberatak na La Poste i La Banque Postale: jak DDoS potrafi sparaliżować logistykę i bankowość w szczycie sezonu

Wprowadzenie do problemu / definicja luki

Na trzy dni przed Bożym Narodzeniem francuska grupa La Poste oraz jej ramię bankowe La Banque Postale odnotowały poważne zakłócenia działania usług online. Według komunikatów i relacji medialnych przyczyną był incydent typu DDoS (Distributed Denial of Service), który „zapycha” infrastrukturę ogromną liczbą żądań, prowadząc do niedostępności serwisów i aplikacji.

W praktyce DDoS nie musi oznaczać włamania ani kradzieży danych — jego celem bywa destabilizacja i wymuszenie przestojów. Z perspektywy usług masowych (poczta, tracking przesyłek, bankowość detaliczna) to często wystarcza, by w krytycznym momencie uderzyć w ciągłość działania.

W skrócie

Atak DDoS uczynił niedostępnymi strony i aplikacje La Poste oraz powiązanych usług, co uderzyło w obsługę paczek i operacje wymagające dostępu do systemów wewnętrznych.
Problemy objęły także La Banque Postale — m.in. autoryzację płatności i część funkcji bankowości mobilnej/online; awaryjnie przeniesiono autoryzacje na SMS.
Według deklaracji operatora nie było wpływu na dane klientów, a dochodzenie prowadziła prokuratura w Paryżu; brak było jednoznacznej atrybucji.
We wtorek rano usługi nadal nie były w pełni przywrócone; wskazywano, że intensywność ataku spadła, ale działania wciąż trwają.

Kontekst / historia / powiązania

Ten incydent nie wydarzył się w próżni. Media zwracają uwagę na wzrost liczby zakłóceń i incydentów cybernetycznych dotykających administrację i duże organizacje we Francji w ostatnich tygodniach — co napędza narrację o „hybrydowej” presji na państwa europejskie, choć w tym konkretnym przypadku nie wskazano sprawcy.

Wątek DDoS jako narzędzia destabilizacji jest też spójny z obserwacjami francuskiej agencji ANSSI: ataki DDoS są jedną z najczęstszych metod działań „na zakłócenie”, szczególnie lubianą przez środowiska hacktywistyczne, ale wykorzystywaną również przez aktorów o bardziej zróżnicowanych profilach. ANSSI wskazywała też na wyraźny wzrost (globalnie „podwojenie”) liczby takich ataków obserwowanych przeciwko celom francuskim w 2024 r.

Dodatkowy smaczek kontekstowy: euronews odnotował, że niektóre z tych samych usług (np. tracking Colissimo i skrytka Digiposte) miały być zakłócone już w sobotę, zanim doszło do poniedziałkowego „dużego” incydentu — bez potwierdzenia, czy to ten sam wektor.

Analiza techniczna / szczegóły ataku

Co oznacza „DDoS” w realiach poczty i bankowości?

DDoS to przeciążenie usług z wielu źródeł jednocześnie (botnety, infrastruktura pośrednicząca, czasem „booter/stresser”). Efekt końcowy bywa identyczny jak przy awarii: aplikacje nie odpowiadają, API time-outuje, a systemy zależne (autoryzacje, tracking, formularze nadawcze) przestają działać.

W raportowanym przypadku:

La Poste komunikowała niedostępność usług online i brak wpływu na dane klientów, ale wyraźne zakłócenia obsługi paczek i operacji wymagających trackingu/dostępu do systemów.
Wskazywano niedostępność wielu witryn i aplikacji w ekosystemie (m.in. La Poste, Colissimo, La Banque Postale oraz usługi tożsamości cyfrowej).

Dlaczego autoryzacje płatności „przesiadły się” na SMS?

Jeśli bankowość mobilna/online nie jest w stanie przeprowadzić typowej ścieżki SCA (np. autoryzacja w aplikacji lub mechanizmem takim jak Certicode), bank może uruchomić obejście: alternatywny kanał potwierdzeń. W tym zdarzeniu opisywano przekierowanie zatwierdzania operacji do SMS.

To klasyczny kompromis „ciągłość działania vs. ergonomia/ryzyko”:

plus: klienci nadal mogą dokończyć część transakcji,
minus: SMS jest statystycznie słabszym kanałem (SIM swap, przejęcia numerów, malware na telefonie), więc powinien być traktowany jako tryb awaryjny z dodatkowymi limitami i monitoringiem anomalii.

Dlaczego takie incydenty potrafią trwać wiele godzin?

W relacjach podkreślano, że sytuacja utrzymywała się przez co najmniej wiele godzin i nie była w pełni rozwiązana jeszcze następnego ranka.
Przy DDoS „czas trwania” zależy m.in. od:

zdolności do odfiltrowania ruchu (scrubbing/Anycast/CDN),
charakteru ataku (wolumetryczny vs aplikacyjny),
tego, czy atakujący adaptuje się do filtrów,
oraz tego, czy organizacja ma gotowe scenariusze degradacji (np. tryb „tylko odczyt”, caching, odcięcie mniej krytycznych funkcji).

Praktyczne konsekwencje / ryzyko

Dla logistyki i klientów

Najbardziej dotkliwe są „punkty tarcia” na styku cyfrowego i fizycznego: nadanie/odbiór przesyłki, etykieta, tracking, płatność online. Gdy systemy trackingu i operacje zależne od systemów wewnętrznych padają, fizyczna sieć placówek nadal działa, ale efektywność gwałtownie spada.
Sezonowość zwiększa wrażliwość: w okresie przedświątecznym nawet krótkie okno niedostępności generuje falę zgłoszeń, kolejki i presję na personel.

Dla bankowości

Zakłócenie autoryzacji i dostępu do aplikacji przekłada się na opóźnienia płatności, wzrost fraud alertów i większe ryzyko błędów operacyjnych (np. klienci „ponawiają” transakcje).
Nawet jeśli karty i bankomaty działają, utrata kanałów cyfrowych w czasie szczytu zakupowego uderza w zaufanie i obciążenie call center/oddziałów.

Ryzyko strategiczne: DDoS jako „tani” sabotaż

ANSSI zwraca uwagę, że DDoS to częsta broń destabilizacji — relatywnie łatwa do uruchomienia, trudna do „zamknięcia” jednym ruchem i skuteczna medialnie.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista praktyk, które realnie ograniczają skutki DDoS dla usług masowych (logistyka/bankowość), bez obiecywania „magicznej odporności”:

Zabezpieczenie warstwy brzegowej (edge)

Anycast + globalny CDN, WAF i mechanizmy bot management.
Stała integracja z dostawcą scrubbingu (nie „na telefon w kryzysie”).

Playbooki DDoS i testy w warunkach „peak season”

Symulacje ataków aplikacyjnych (L7) na API i krytyczne ścieżki (tracking, logowanie, autoryzacja).
Runbook: kto podejmuje decyzję o degradacji funkcji, jakie progi odcięć, jak komunikować to klientom.

Degradacja kontrolowana zamiast „total down”

Tryb tylko do odczytu dla trackingu (np. cache ostatniego statusu).
Kolejkowanie zadań (message queue), by operacje z placówek mogły się buforować i wrócić po przywróceniu.

Awaryjna autoryzacja płatności: ogranicz ryzyko

Jeśli wchodzisz w SMS jako plan B, ustaw limity kwotowe/ryzyko, wymuś dodatkową analizę behawioralną, podbij monitoring na SIM swap.
Komunikat do klientów: jak rozpoznać phishing w czasie incydentu (atakujący lubią „podszyć się” pod kryzys).

Komunikacja kryzysowa

Jedna strona statusowa poza główną domeną (najlepiej u niezależnego dostawcy) + aktualizacje w mediach społecznościowych.
Jasny opis: co działa, co nie działa, jakie obejścia są bezpieczne.

Różnice / porównania z innymi przypadkami

DDoS vs ransomware: ransomware zwykle uderza w integralność i poufność (często także dostępność), ale wymaga wejścia do środka. DDoS może być „czystym” atakiem na dostępność — szybciej uruchamianym i łatwiej skalowanym w czasie.
DDoS na usługi publiczne vs infrastruktura krytyczna: ANSSI opisywała przypadki, w których silne DDoS-y dotykały nawet bardzo istotnych elementów (np. wpływ na dostępność usług krytycznych), co pokazuje, że granica „tylko niedogodność” potrafi się przesuwać.
Efekt domina: tu widać typowy wzorzec — jedna fala niedostępności potrafi jednocześnie uderzyć w tracking, płatności, autoryzacje i obsługę w placówkach, bo nowoczesne procesy są silnie „API-first”.

Podsumowanie / kluczowe wnioski

DDoS w grudniu to nie tylko problem IT — to test odporności operacyjnej całej organizacji. W przypadku La Poste i La Banque Postale kluczowe było to, że atak uderzył w usługi online w krytycznym oknie przedświątecznym, powodując zakłócenia w logistyce i bankowości, przy jednoczesnych deklaracjach braku wpływu na dane klientów.

Najważniejsza lekcja jest prosta: odporność na DDoS nie kończy się na filtracji ruchu. Liczy się plan degradacji usług, alternatywne (ale bezpieczne) ścieżki autoryzacji, oraz komunikacja, która ogranicza chaos i podatność na phishing „podszywający się” pod incydent.

Źródła / bibliografia

SecurityWeek (Associated Press): „Cyberattack Disrupts France’s Postal Service and Banking During Christmas Rush”. (SecurityWeek)
The Guardian: „France’s national post office hit by suspected cyber-attack”. (The Guardian)
Le Monde: „La Poste victime d’une cyberattaque juste avant Noël”. (Le Monde.fr)
Euronews (FR): „Les services numériques de La Poste visés par une cyberattaque…”. (euronews)
ANSSI / CERT-FR: „Panorama de la cybermenace 2024” (sekcja o wzroście DDoS).

Irański APT Infy („Prince of Persia”) wraca: nowe wersje Foudre i Tonnerre, DGA oraz C2 z elementami Telegrama

Wprowadzenie do problemu / definicja luki

Infy (znany też jako „Prince of Persia”) to przypisywany Iranowi aktor APT, kojarzony z długotrwałymi kampaniami szpiegowskimi, w których wykorzystywał własne rodziny malware oraz infrastrukturę C2 (command-and-control). Po okresie względnej ciszy badacze ponownie obserwują aktywność grupy – tym razem z odświeżonym toolsetem i technikami utrudniającymi wykrywanie oraz „zrywanie” łączności z serwerami sterującymi.

W praktyce nie jest to pojedyncza „luka” w rozumieniu CVE, tylko powrót kampanii malware: infekcje inicjowane socjotechniką (phishing) i plikami biurowymi, a następnie etapowe wdrażanie komponentów Foudre/Tonnerre do rozpoznania ofiary i eksfiltracji danych.

W skrócie

Infy/„Prince of Persia” wraca po latach z nowszymi wersjami Foudre i Tonnerre; najnowsze warianty Tonnerre były obserwowane we wrześniu 2025 r.
Zmienia się wektor wejścia: obok klasycznych dokumentów z makrami pojawiają się pliki Excel z osadzonym wykonywalnym payloadem (co potrafi ominąć część polityk „macro hygiene”).
Istotnym elementem odporności jest DGA (Domain Generation Algorithm) oraz dodatkowa walidacja „prawdziwości” domeny C2 z użyciem podpisu RSA.
SafeBreach opisuje też scenariusz, w którym część C2/operacji jest przekierowywana do Telegrama (bot/grupa) jako kanału kontroli/transferu.

Kontekst / historia / powiązania

Infy to nazwa używana w branży do opisu aktora i kampanii obserwowanych co najmniej od wczesnych lat 2010., wiązanych m.in. z celowaniem w aktywistów i organizacje wrażliwe politycznie. Malpedia opisuje Infy jako grupę podejrzewaną o irańskie pochodzenie, obserwowaną w kontekście ukierunkowanych działań i własnych rodzin złośliwego oprogramowania.

Starsze analizy Unit 42 (Palo Alto Networks) dokumentowały „Prince of Persia/Infy” jako kampanię opartą o spear-phishing z dokumentami Office i etapowe dostarczanie malware. To ważne tło, bo pokazuje, że dzisiejszy „powrót” to raczej ciągłość rozwoju i ewolucja TTP, a nie całkowicie nowy byt.

Analiza techniczna / szczegóły luki

1) Łańcuch infekcji: Office jako nośnik, ale z twistem

Według SafeBreach i relacji The Hacker News, aktor odchodzi (przynajmniej częściowo) od klasyki w postaci makr w Excelu na rzecz dokumentów Excel z osadzonym plikiem wykonywalnym, który instaluje Foudre. Równolegle wciąż mogą występować warianty oparte o makra.

Z perspektywy MITRE ATT&CK taki model często „opiera się” o zachowanie użytkownika (otwarcie pliku, włączenie zawartości/uruchomienie elementu), czyli wzorce z obszaru User Execution: Malicious File.

2) Role malware: Foudre jako etap 1, Tonnerre jako etap 2

SafeBreach opisuje Foudre jako pierwszy etap (profilowanie/rozpoznanie i selekcja), a Tonnerre jako komponent uruchamiany, gdy ofiara jest „warta” dalszej inwestycji (np. eksfiltracja, rozszerzone komendy). W kampanii wykryto m.in. Foudre v34 oraz Tonnerre w wersjach 12–18 i 50.

3) Odporność C2: DGA + walidacja podpisem

Najbardziej charakterystyczny element obecnej odsłony to:

DGA – generowanie domen C2 w czasie, co utrudnia blokowanie listą statycznych domen,
walidacja C2 – pobranie pliku podpisu RSA i porównanie z lokalnym „wzorcem”, aby upewnić się, że malware łączy się z właściwą infrastrukturą (a nie np. sinkhole/pułapką analityków).

4) Telegram jako element ekosystemu sterowania

Nowością opisywaną przez SafeBreach jest sytuacja, w której infrastruktura C2 kieruje komunikację do zasobów Telegrama (bot/grupa) jako alternatywnego kanału – co może poprawiać „przeżywalność” kampanii i utrudniać klasyczne blokady po IP/domenie.

Uwaga praktyczna: nawet jeśli badacze publikują szczegóły, w środowisku obronnym lepiej traktować je jako punkt startowy do detekcji (telemetria endpoint + proxy/DNS), a nie „jedyne IOC”, bo aktor może szybko rotować elementy infrastruktury.

5) Zasięg geograficzny i profil celów

W podsumowaniach wskazuje się ofiary w wielu krajach (m.in. Iran, Irak, Turcja, Indie, Kanada oraz część Europy). To sugeruje, że kampania ma charakter szerszy niż lokalny i może obejmować diasporę, podmioty powiązane tematycznie lub łańcuchy relacji biznesowych.

Praktyczne konsekwencje / ryzyko

Ryzyko wycieku danych: Tonnerre jest opisywany jako etap, w którym pojawia się realna eksfiltracja/operacje na plikach, a infrastruktura ma katalogowanie i logowanie komunikacji.
Trudniejsze blokowanie C2: DGA + walidacja „autentyczności” C2 zmniejszają skuteczność prostych blokad domen/IP i mogą ograniczać skuteczność sinkholingu.
Wyzwania dla polityk Office: organizacje skupione wyłącznie na blokadzie makr mogą mieć lukę kontrolną, jeśli wektor przechodzi na osadzone executables / nietypowe SFX/loader-y.

Rekomendacje operacyjne / co zrobić teraz

Wzmocnij kontrolę uruchomień z Office

Blokuj/ograniczaj tworzenie procesów potomnych przez aplikacje Office (np. reguły ASR w Microsoft Defender, polityki EDR).
Monitoruj nietypowe zachowania: Excel → tworzenie plików wykonywalnych, uruchamianie SFX/loaderów, wykonywanie DLL z katalogów tymczasowych. (Zgodne z ryzykiem User Execution: Malicious File).

DNS i egress: przygotuj się na DGA

Wykrywaj anomalie DNS (dużo nieudanych zapytań, domeny o nietypowej entropii/alfabecie, krótkie „losowe” hosty).
Stosuj egress filtering i proxy z inspekcją; DGA bez wyjścia na Internet traci sens.

Detekcje na endpoint

Poluj na wzorce: dokumenty Office jako initial access, a potem binaria w nietypowych lokalizacjach + ruch HTTP(S) do świeżo generowanych domen.

Procedury IR i threat hunting

Jeśli podejrzewasz infekcję: izolacja hosta, pełna triage (autoruny, harmonogram zadań, persistence), korelacja DNS/Proxy/EDR.
Ustal, czy w organizacji występowały kontakty z infrastrukturą opisywaną przez badaczy i czy doszło do nietypowych transferów danych.

Różnice / porównania z innymi przypadkami

Klasyczne APT vs „odporne C2”: DGA to technika znana od lat, ale połączenie jej z walidacją C2 (podpis RSA) i potencjalnym „fallbackiem” do popularnej platformy komunikacyjnej (Telegram) tworzy bardziej elastyczny, trudniejszy do przejęcia łańcuch sterowania.
Makra to nie jedyny problem: przesunięcie w stronę osadzonych wykonywalnych elementów w dokumentach pokazuje, że polityki „disable macros” są konieczne, ale niewystarczające, jeśli nie ma twardej kontroli uruchomień i zachowań procesów.

Podsumowanie / kluczowe wnioski

Powrót Infy/„Prince of Persia” to sygnał ostrzegawczy: grupa rozwija toolset (Foudre/Tonnerre), zmienia elementy dostarczania (Excel z osadzonym payloadem), a przede wszystkim zwiększa odporność infrastruktury (DGA + walidacja RSA, a według SafeBreach także elementy oparte o Telegram). Dla obrony kluczowe jest odejście od myślenia „zablokuj domenę i po sprawie” na rzecz podejścia warstwowego: kontrola uruchomień z Office, analiza anomalii DNS, telemetria EDR oraz dobrze przećwiczone IR.

Źródła / bibliografia

The Hacker News – opis ponownej aktywności Infy, zmiany w łańcuchu ataku i elementy DGA/walidacji C2. (The Hacker News)
SafeBreach – raport techniczny o Foudre/Tonnerre, wariantach, C2 i obserwacjach dotyczących Telegrama. (SafeBreach)
Unit 42 (Palo Alto Networks) – historyczny kontekst kampanii „Prince of Persia/Infy” i model działania. (Unit 42)
Malpedia – profil aktora Infy (kontekst, nazewnictwo, ogólny opis). (Malpedia)
MITRE ATT&CK – User Execution: Malicious File jako punkt odniesienia dla wektora „użytkownik otwiera złośliwy plik”. (attack.mitre.org)

Docker Hardened Images są teraz open source i darmowe: co to zmienia dla bezpieczeństwa kontenerów?

Wprowadzenie do problemu / definicja luki

Kontener jest tak bezpieczny, jak jego fundament — a fundamentem najczęściej jest obraz bazowy (base image). To właśnie na nim budujesz swoje aplikacje, dziedziczysz pakiety, konfigurację, użytkowników, a nierzadko także „historyczne” decyzje o tym, co w obrazie w ogóle powinno się znaleźć.

Docker Hardened Images (DHI) to zestaw „utwardzonych” obrazów bazowych i aplikacyjnych utrzymywanych przez Docker, projektowanych tak, by minimalizować powierzchnię ataku i ograniczać ryzyko na poziomie supply chain (łańcucha dostaw oprogramowania). Teraz — i to jest clou wiadomości — katalog ponad 1000 obrazów DHI jest dostępny za darmo i jako open source na licencji Apache 2.0.

W skrócie

Docker udostępnił 1000+ utwardzonych obrazów jako darmowe i open source (Apache 2.0).
DHI są projektowane jako minimalne, „rootless” i publikowane z naciskiem na brak znanych podatności w momencie wydania (oraz stałe utrzymanie).
Wokół DHI zbudowano warstwę weryfikowalności: SBOM, VEX, raporty CVE, skany sekretów oraz SLSA Build Level 3 i podpisane attestations.
Nadal istnieje podział na Free i Enterprise — m.in. SLA na krytyczne łatki (7 dni) pozostaje po stronie wersji komercyjnej.

Kontekst / historia / powiązania

Docker Hardened Images zostały uruchomione w maju 2025 r. jako oferta ukierunkowana na bezpieczeństwo obrazów i ograniczanie ryzyk na warstwie kontenerów.

W grudniu 2025 temat wraca z mocnym akcentem: 21 grudnia 2025 BleepingComputer opisuje decyzję o udostępnieniu DHI „subscription-free” (bez subskrypcji) oraz przeniesieniu ciężaru monetyzacji na wariant Enterprise.

Warto też zauważyć, że projekt nie powstał w próżni — SecurityWeek wskazuje, że katalog DHI był budowany we współpracy z firmami i projektami z ekosystemu (m.in. Cloudsmith, GitLab, Microsoft, NGINX, Sonatype, Sysdig, Wiz).

Analiza techniczna / szczegóły luki

1) „Hardened” w praktyce: minimalizm + rootless + utrzymanie

DHI są opisywane jako obrazy:

rootless (uruchamiane bez uprawnień roota),
odchudzone (bez zbędnych komponentów),
publikowane z założeniem „zero-known CVEs” (brak znanych podatności w momencie publikacji) oraz z ciągłym utrzymaniem.

2) Warstwa „dowodów”: SBOM, VEX, CVE i SLSA

Najciekawsza (i najbardziej praktyczna) część DHI to nie tylko „co jest w obrazie”, ale co da się udowodnić na temat jego pochodzenia i zawartości.

Docker dokumentuje, że DHI wykorzystują podpisane attestations: to „podpisane oświadczenia” o obrazie (jak powstał, co zawiera i jakie kontrole przeszedł), zwykle podpisywane narzędziami Sigstore (np. Cosign).

Wśród typowych metadanych/attestations pojawiają się m.in.:

SBOM (CycloneDX oraz SPDX),
VEX (wskazanie podatności, które nie dotyczą obrazu wraz z uzasadnieniem),
listy/raporty CVE (różne formaty),
skany sekretów, testy, skany antywirusowe,
SLSA provenance i SLSA verification summary,
informacje o źródłach materiałów użytych do budowy obrazu.

Dodatkowo Docker podkreśla, że obrazy i chart-y są budowane zgodnie z SLSA Build Level 3 i publikowane z kompletem podpisanych attestations, możliwych do inspekcji m.in. przez Docker Scout lub Cosign.

3) Open source „na serio”: Apache 2.0 i publiczny katalog

Po stronie GitHub projekt jest udostępniony jako Docker Hardened Images z jasną informacją o licencji Apache 2.0 oraz publicznymi repozytoriami (m.in. katalog definicji, advisories, keyring, changelog/log).

Przykładowe użycie (z dokumentacji w README projektu):

docker login dhi.io
docker pull dhi.io/node:24-debian13
docker pull dhi.io/python:3.12-alpine3.22
docker pull dhi.io/postgres:17-debian13

To ważne: w praktyce oznacza to, że „bezpieczny start” może być równie prosty jak zmiana obrazu bazowego w Dockerfile — ale z dodatkową możliwością walidacji SBOM/VEX/provenance w pipeline.

Praktyczne konsekwencje / ryzyko

Co realnie zyskujesz, jeśli przejdziesz na utwardzone obrazy w stylu DHI?

Mniej niepotrzebnych komponentów → mniejsza powierzchnia ataku i mniej „szumu” w skanerach.
Lepsza weryfikowalność supply chain: SBOM, VEX i podpisane attestations ułatwiają audyt, dochodzenie po incydencie i budowę polityk bezpieczeństwa w CI/CD.
Czytelniejszy model utrzymania: Docker opisuje dwa poziomy DHI (Free i Enterprise) i rozdziela „darmowy dostęp” od „gwarantowanych czasów reakcji / compliance”.

Ryzyko / pułapki wdrożeniowe:

Jeśli liczysz na twarde czasy łatania: SLA 7 dni na krytyczne CVE dotyczy Enterprise, a nie darmowego tieru (Free nadal dostaje łatki, ale bez gwarantowanego okna czasowego).
Migracja na minimalne, rootless obrazy bywa „bolesna” dla aplikacji, które po cichu zakładają obecność narzędzi systemowych, shella, pakiet managera albo uprawnień roota.

Rekomendacje operacyjne / co zrobić teraz

Zrób inwentaryzację obrazów bazowych
Wypisz, jakie obrazy bazowe masz w organizacji (prod i build) i gdzie są używane (repo, pipeline, runtime).
Wybierz kandydatów do migracji „low risk”
Na początek: serwisy stateless i obrazy, które i tak regularnie przebudowujesz.
Wprowadź twarde zasady w CI/CD

pinowanie obrazu po digest, nie po „pływającym” tagu,
walidacja metadanych supply chain: SBOM, VEX, provenance i skany jako bramki jakości.

Ustal politykę aktualizacji

Jeśli potrzebujesz przewidywalności: rozważ Enterprise (SLA, compliance warianty, ELS), bo Free nie gwarantuje okna na krytyczne łatki.

Testy kompatybilności
Dla każdej aplikacji sprawdź:

czy działa bez roota,
czy nie wymaga „narzędzi z obrazu” (curl, bash, package manager),
czy logika healthchecków i startu nie polega na brakujących binarkach.

Różnice / porównania z innymi przypadkami

DHI vs „zwykłe” obrazy bazowe (np. standardowe obrazy dystrybucyjne / obrazy z Docker Hub):

w praktyce różnica rzadko polega na tym, że „tamte są niebezpieczne”, tylko że trudniej jest udowodnić ich pochodzenie i stan (SBOM/VEX/provenance/attestations jako standard),
DHI kładą nacisk na rootless + minimalizm + transparentne metadane oraz konsekwentny model utrzymania.

DHI Free vs DHI Enterprise:

Free: dostęp do katalogu i core funkcji,
Enterprise: elementy „enterprise-readiness” (SLA, warianty compliance, customizacja, Extended Lifecycle Support).

Podsumowanie / kluczowe wnioski

Udostępnienie Docker Hardened Images jako darmowych i open source to realny krok w stronę podniesienia bazowego poziomu bezpieczeństwa kontenerów — szczególnie tam, gdzie organizacje chcą przestać „ręcznie” składać bezpieczne base image’y i zamiast tego weryfikować supply chain na podstawie podpisanych dowodów (SBOM/VEX/SLSA).

Najważniejszy niuans: darmowe nie znaczy „z SLA” — jeśli Twoje ryzyko wymaga gwarantowanego czasu na krytyczne łatki, ten element nadal jest po stronie komercyjnej.

Źródła / bibliografia

BleepingComputer — „Docker Hardened Images now open source and available for free” (21 grudnia 2025). (BleepingComputer)
Docker Hardened Images (GitHub) — projekt i README (Apache 2.0, katalog, przykłady użycia). (GitHub)
Docker Docs — „Docker Hardened Images” (podział Free/Enterprise i opis produktu). (Docker Documentation)
Docker Docs — „Attestations” (SBOM/VEX/CVE/SLSA i podpisane metadane). (Docker Documentation)
SecurityWeek — „Docker Makes 1,000 Hardened Images Free and Open Source” (19 grudnia 2025). (SecurityWeek)

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)

Segmentuj IoT/TV boxy (oddzielny VLAN/SSID, polityki egress-only tam, gdzie się da).
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.
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).
Threat hunting na wskaźniki domenowe: monitoruj zapytania/połączenia do podejrzanych domen C2, w tym wskazywanych publicznie w analizach (np. …02132[.]su).
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

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