Archiwa: DDoS - Strona 12 z 16

Dziesiątki tysięcy routerów ASUS przejętych w kampanii „WrtHug”. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Nowo ujawniona kampania Operation WrtHug kompromituje dziesiątki tysięcy domowych i SOHO routerów ASUS WRT, przede wszystkim urządzenia EoL (poza wsparciem). Badacze ze STRIKE (SecurityScorecard) szacują, że ponad 50 tys. unikatowych adresów IP należących do zainfekowanych routerów było widocznych w ciągu ostatnich 6 miesięcy. Wspólnym wskaźnikiem infekcji jest identyczny, samopodpisany certyfikat TLS na usłudze AiCloud z nietypowym 100-letnim terminem ważności od kwietnia 2022 r.. Kampania łączy się taktykami i zasięgiem z operacjami klasy ORB (Operational Relay Box), które służą do skrytego pośredniczenia w ruchu na potrzeby cyber-szpiegostwa.

W skrócie

Skala: ≥50 000 zainfekowanych routerów ASUS, głównie w Tajwanie i Azji Płd-Wsch., ale również w USA, Rosji i Europie.
Wektor: łańcuch n-day na AiCloud + zestaw błędów OS command injection i auth bypass w starszych firmware’ach ASUS WRT.
IoC: wspólny self-signed cert (AiCloud) z ważnością 100 lat.
Powiązania: zbieżność TTP z wcześniejszą kampanią AyySSHush na routery ASUS (GREYNOISE).
Kluczowe CVE: CVE-2023-41345/6/7/8, CVE-2023-39780, CVE-2024-12912, CVE-2025-2492 (AiCloud).

Kontekst / historia / powiązania

W maju 2025 r. GreyNoise opisał cichą kampanię AyySSHush: trwałe tylne wejście w tysiącach routerów ASUS, z wykorzystaniem CVE-2023-39780, modyfikacji konfiguracji SSH oraz przechowywania artefaktów w NVRAM (przetrwanie restartów i aktualizacji). WrtHug dzieli część TTP (wykorzystanie tych samych rodzin błędów i celów), ale STRIKE notuje zaledwie 7 hostów z nakładającą się infekcją, więc traktuje WrtHug jako oddzielną kampanię – potencjalnie tego samego lub skoordynowanych aktorów.

Analiza techniczna / szczegóły luki

Łańcuch ataku w WrtHug opiera się na publicznie znanych (n-day) błędach w ASUS WRT oraz podatnościach AiCloud:

OS command injection:
- CVE-2023-41345 / 41346 / 41347 / 41348 – rodzina błędów powiązana z mechanizmami tokenowymi oraz „apply” w panelu, w praktyce skorelowana z CVE-2023-39780 (RT-AX55; wstrzyknięcie komend po uwierzytelnieniu).
AiCloud (arbitrary command / auth bypass):
- CVE-2024-12912 – błąd w AiCloud pozwalający na wykonanie poleceń (CVSS 7.2, NVD).
- CVE-2025-2492 – improper authentication control w AiCloud (CVSS 9.2); możliwe wywołanie funkcji bez autoryzacji przygotowanym żądaniem.

Artefakt/kondensator IoC: na zainfekowanych urządzeniach usługa AiCloud prezentuje ten sam certyfikat TLS, samopodpisany, z okresem ważności 100 lat (od 04.2022). To najprostszy punkt zaczepienia dla huntów i detekcji.

Modele na celowniku: raporty wymieniają m.in. 4G-AC55U/860U, DSL-AC68U, GT-AC5300, GT-AX11000, RT-AC1200HP/1300G+/1300UHP i inne starsze/EoL wersje. (Lista może nie być kompletna; kluczowe jest sprawdzenie statusu wsparcia danego modelu).

Praktyczne konsekwencje / ryzyko

Skryte proxy/relay (ORB): urządzenia stają się węzłami ukrywającymi ruch na potrzeby eksfiltracji i rozpoznania – mniejsze ryzyko DDoS, większy nacisk na szpiegostwo i pivoting.
Trwałość: atak często przetrwa aktualizacje firmware’u (konfiguracja w NVRAM, zmiany SSH), więc „patch ≠ remediacja”.
Ekspozycja MŚP i domów: domowe/SoHo routery bywają pomijane w procesach hardeningu, a AiCloud bywa wystawiony do Internetu bez MFA i segmentacji.

Rekomendacje operacyjne / co zrobić teraz

Szybki hunting IoC
- Sprawdź, czy AiCloud prezentuje nietypowy, samopodpisany cert z datą ważności do 2122 r.. Jeśli tak – traktuj jako wysoki wskaźnik kompromitacji.
Weryfikacja AiCloud i dostępu zdalnego
- Jeżeli urządzenie jest EoL lub brak łatki – wyłącz AiCloud i każdy zdalny dostęp z Internetu (HTTP/HTTPS, SSH, WAN admin).
Remediacja trwałości
- Jeżeli podejrzewasz kompromitację: pełny factory reset, następnie ręczna, czysta konfiguracja (nie przywracaj kopii!), sprawdź authorized_keys, porty SSH (GREYNOISE raportował niestandardowy TCP/53282), usuń obce klucze.
Aktualizacje firmware’u
- Zastosuj najnowsze firmware’y naprawiające m.in. CVE-2025-2492 (AiCloud) oraz luki z 2023 r. W przypadku EoL – wymiana urządzenia.
Hardening
- Zmień hasła admina, włącz MFA (jeśli wspierane), ogranicz panel do LAN/VPN, wyłącz UPnP, stosuj ACL/geo-IP na brzegu, segmentuj sieć (IoT/Wi-Fi gości oddzielnie). (Dobre praktyki na bazie ogólnych zaleceń i obserwacji z raportów).
Monitoring i bloki
- Blokuj znane IP/porty z raportów (np. 53282/TCP dla SSH), loguj odwołania do AiCloud, ustaw alerty na zmiany certyfikatów i włączenie SSH.

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

WrtHug vs. AyySSHush: oba celują w ASUS WRT i łączą CVE-2023-39780, ale WrtHug ma wyraźny IoC TLS (100-letni cert) na AiCloud i inną dystrybucję geograficzną; AyySSHush akcentował trwałość przez NVRAM/SSH. Mało hostów z podwójną infekcją → różne klastry/etapy jednego lub skoordynowanych aktorów.
Botnet vs. ORB: klasyczne botnety = hałaśliwe DDoS/kripto-koparki; ORB = ciche szlaki ruchu dla operacji APT (maskowanie źródła, pivot). WrtHug ma profil ORB-like.

Podsumowanie / kluczowe wnioski

Słabe ogniwo #1: EoL routery z włączonym AiCloud i zdalnym dostępem.
Najprostsza detekcja: sprawdzenie certyfikatu TLS AiCloud (100 lat).
Remediacja ≠ patch: przy podejrzeniu infekcji reset do fabrycznych + ręczna rekonfiguracja, dopiero potem aktualizacja; dla EoL – wymiana.
Zagrożenie strategiczne: rosnący trend ORB na urządzeniach brzegowych – cichsze, długotrwałe kampanie.

Źródła / bibliografia

SecurityScorecard STRIKE – Operation WrtHug, The Global Espionage Campaign Hiding in Your Home Router (19.11.2025). (SecurityScorecard)
The Register – Tens of thousands more ASUS routers pwned by suspected, evolving China operation (19.11.2025). (The Register)
GreyNoise – Stealthy Backdoor Campaign Affecting Thousands of ASUS Routers (28.05.2025). (greynoise.io)
NVD – CVE-2023-39780 (ASUS RT-AX55 OS command injection). (nvd.nist.gov)
NVD – CVE-2025-2492 (ASUS AiCloud improper authentication control). (nvd.nist.gov)

ShadowRay 2.0: nowa fala ataków zmienia klastry Ray w koparki kryptowalut

Wprowadzenie do problemu / definicja luki

Trwa globalna kampania „ShadowRay 2.0”, w której napastnicy przejmują publicznie dostępne klastry Ray (open-source framework do skalowania aplikacji AI/Python) i zamieniają je w samopropagującą się infrastrukturę do kopania Monero. Wektor wejścia to nadal sporna, niewyłatania podatność CVE-2023-48022 w API zadań Ray, umożliwiająca zdalne wykonanie kodu bez uwierzytelnienia przy błędnej ekspozycji usług na Internet. Najnowsza fala kampanii rozszerza się poza cryptojacking – obserwowane są kradzieże danych/poświadczeń i funkcje DDoS.

W skrócie

Nowa kampania („ShadowRay 2.0”): ta sama luka, bardziej automatyczny łańcuch ataku; self-spread między węzłami/klastrami.
Ekspozycja ekosystemu: badacze szacują dziś >230 tys. serwerów Ray widocznych w Internecie (wcześniej „kilka tysięcy”).
CVE-2023-48022: zdalne RCE przez Jobs API; ocena CVSS 9.8 (CRITICAL), status „disputed” – twórcy Ray wskazują, że Ray ma działać w „ściśle kontrolowanym środowisku”.
Ładunki: generowane z pomocą LLM (charakterystyczne komentarze/docstringi), moduł XMRig ograniczający użycie CPU do ~60%, utrwalanie przez cron/systemd, reverse-shelle i moduł DDoS (Sockstress).
Brak łatki: zalecenia to „best practices” Anyscale – uruchomienie w zaufowanej sieci, filtrowanie portu 8265 (Dashboard), autoryzacja przez proxy, monitoring anomalii.

Kontekst / historia / powiązania

Pierwszą kampanię ShadowRay opisano w marcu 2024 r., wskazując aktywne nadużycia od września 2023 r. Wtedy już raportowano setki skompromitowanych klastrów oraz dominujące użycie koparek (XMRig/NBMiner/Zephyr) i reverse-shelli. Jednocześnie Anyscale podtrzymało, że brak wbudowanego uwierzytelniania to decyzja projektowa, a instancje powinny działać w środowiskach kontrolowanych; firma zapowiadała dodanie auth w przyszłych wersjach.

Analiza techniczna / szczegóły luki

CVE-2023-48022 dotyczy Jobs API w Ray i umożliwia zdalne przesłanie/uruchomienie zadań (Bash/Python) bez uwierzytelnienia, jeśli endpointy są wystawione na świat. NVD klasyfikuje lukę jako krytyczną (CVSS 9.8). Brak łatki wynika z modelu zaufania Ray – framework zakłada izolację sieciową i kontrolę dostępu po stronie operatora. W praktyce tysiące wdrożeń są błędnie wystawione (np. 0.0.0.0) lub pozbawione filtracji, co czyni je łatwym celem.

W ShadowRay 2.0 napastnicy (TRACK: IronErn440) korzystają z CVE-2023-48022 do uruchamiania wielostopniowych łańcuchów Bash/Python. Payloady, z oznakami generowania przez LLM, po zainfekowaniu rozsiewają się na wszystkie węzły klastra poprzez natywne mechanizmy orkiestracji Ray, a nawet klaster-do-klastra. Zaobserwowano dwie fale: starszą z dystrybucją przez GitLab (zakończona 5 listopada) i nową przez GitHub (aktywna od 17 listopada).

Moduły złośliwe obejmują:

Cryptojacker (XMRig) – wykrywa CPU/GPU, maskuje procesy (np. dns-filter), limity CPU (ok. 60%), zabija konkurencyjne koparki, blokuje pule w /etc/hosts i iptables, utrzymuje persistencję przez cron/systemd.
Dostęp interaktywny – wiele reverse-shelli do infrastruktury C2, z możliwością eksfiltracji danych środowisk ML (sekrety, hasła DB, klucze SSH, tokeny usług).
DDoS – komponent oparty o Sockstress do wyczerpywania zasobów TCP.

Praktyczne konsekwencje / ryzyko

Utrata mocy obliczeniowej (GPU/CPU) i wzrost kosztów chmurowych przez kopanie kryptowalut.
Wycieki sekretów produkcyjnych: hasła DB, klucze SSH, tokeny (OpenAI, HuggingFace, Slack, Stripe), dostęp do kube-API – ryzyko lateral movement i kompromitacji danych klientów.
Degradacja dostępności: możliwość użycia zasobów do DDoS oraz wpływ na trening/inferencję modeli.

Rekomendacje operacyjne / co zrobić teraz

Nie wystawiaj Ray na Internet: uruchamiaj wyłącznie w zaufowanej, odseparowanej sieci/VPC/VPN; blokuj ruch przychodzący do komponentów Ray (w tym Dashboard :8265) regułami firewall/SG.
Warstwa autoryzacji przed Dashboard/Jobs API: jeżeli dostęp zdalny jest konieczny, zastosuj reverse proxy z uwierzytelnianiem (mTLS/OIDC) i autoryzacją endpointów. Nie wiąż usług na 0.0.0.0.
Higiena sekretów: rotuj poświadczenia (DB/SSH/API), unieważnij tokeny znalezione w logach/środowiskach i wymuś krótkie TTL. (Wnioski z incydentów ShadowRay.)
Monitoring runtime: alertuj na tworzenie nietypowych zadań, reverse-shelle, połączenia do puli Monero, procesy podobne do xmrig, modyfikacje crontab/systemd. (IOC-e i TTP-y opisane przez Oligo.)
Segmentacja i egress control: ogranicz ruch wychodzący z węzłów Ray do niezbędnych destynacji; blokuj znane pule, domeny pastebin/Git* używane w kampanii.
Plan odzyskania: w razie kompromitacji – odseparuj klaster, zbuduj nowy z zaufanych artefaktów, przeprowadź triage sekretów i przegląd dostępu do chmury.
Śledź komunikaty producenta: Anyscale wcześniej sygnalizowało przyszłe wsparcie auth – wdrażaj gdy dostępne; do tego czasu polegaj na izolacji sieci i kontrolach dostępu.

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

W porównaniu z typowymi kampaniami cryptojacking w klastrach kontenerowych, ShadowRay wyróżnia:

Wykorzystanie Jobs API Ray jako „legalnego” mechanizmu wykonania kodu (przy błędnej ekspozycji), co utrudnia detekcję przez skanery SAST/kompilacyjne.
Szybkie rozprzestrzenianie w obrębie klastra dzięki wbudowanej orkiestracji Ray oraz automatyczne „cluster-to-cluster spreading” w fali 2.0.
Ładunki generowane przez LLM (charakterystyczne artefakty w kodzie), co wskazuje na rosnącą automatyzację po stronie atakujących.

Podsumowanie / kluczowe wnioski

ShadowRay 2.0 pokazuje, że błędna ekspozycja usług AI to dziś jeden z najbardziej kosztownych błędów operacyjnych.
Brak wbudowanego auth w Ray nie jest „bugiem” w rozumieniu vendor-a, ale ryzyko operacyjne – które trzeba neutralizować segmentacją, filtracją i proxy z autoryzacją.
Zespoły ML/AI powinny mieć runbook na wypadek kompromitacji klastrów treningowych/inferencyjnych oraz telemetrykę ukierunkowaną na IOC/TTP ShadowRay.

Źródła / bibliografia

BleepingComputer – „New ShadowRay attacks convert Ray clusters into crypto miners” (18 listopada 2025). (BleepingComputer)
Oligo Security – „ShadowRay: First Known Attack Campaign Targeting AI Workloads…” (26 marca 2024). (oligo.security)
NVD (NIST) – wpis CVE-2023-48022 (RCE w Ray Jobs API, CVSS 9.8, status „disputed”). (NVD)
SecurityWeek – „Ray AI Framework Vulnerability Exploited to Hack Hundreds of Clusters” (27 marca 2024). (SecurityWeek)
The Hacker News – „Critical Unpatched Ray AI Platform Vulnerability Exploited for Cryptocurrency Mining” (27 marca 2024). (The Hacker News)

Awarie Cloudflare 18 listopada 2025 r.: co poszło nie tak, jak się bronić i czego się nauczyć

Wprowadzenie do problemu / definicja luki

18 listopada 2025 r., około 11:20 UTC (12:20 czasu polskiego), sieć Cloudflare zaczęła masowo zwracać błędy HTTP 5xx, co przełożyło się na niedostępność wielu serwisów na całym świecie (w tym X, ChatGPT, Uber, Spotify, Canva). Cloudflare potwierdził, że incydent nie był atakiem — źródłem problemu okazał się błąd operacyjno-konfiguracyjny skutkujący powstaniem nadmiernie dużego pliku cech („feature file”) używanego przez moduł Bot Management. Plik przekroczył limit obsługiwany przez oprogramowanie proxy, co spowodowało jego awarię i kaskadowe błędy w ruchu klientów. Główna przyczyna została usunięta, a ruch przywrócono ok. 14:30 UTC, pełna stabilizacja nastąpiła o 17:06 UTC.

W skrócie

Kiedy: start degradacji 11:20 UTC, główne przywrócenie 14:30 UTC, koniec 17:06 UTC (18 listopada 2025).
Co zawiodło: generowanie pliku „feature” dla Bot Management (duplikaty cech po zmianie uprawnień w ClickHouse), co przekroczyło limit liczby cech w module i wywołało błąd krytyczny w proxy (FL/FL2).
Skala: globalna; zauważalny wpływ na popularne usługi internetowe (m.in. X, ChatGPT).
Co to nie było: nie DDoS/atak, lecz wewnętrzna zmiana konfiguracji + błąd obsługi limitu.

Kontekst / historia / powiązania

Cloudflare określił zdarzenie jako najpoważniejszą awarię od 2019 r. — wcześniejsze incydenty dotyczyły zwykle panelu czy nowszych funkcji, nie zaś ogólnego przepływu ruchu. Incydent wpisuje się w serię ostatnich dużych awarii w ekosystemie chmury (AWS, Azure), co potwierdza rosnącą współzależność usług infrastrukturalnych.

Analiza techniczna / szczegóły luki

Łańcuch zdarzeń (high-level):

O 11:05 UTC wdrożono zmianę uprawnień w klastrze ClickHouse, która sprawiła, że zapytanie generujące plik cech („feature file”) zaczęło zwracać duplikaty kolumn (z powodu ujawnienia metadanych z dodatkowej bazy r0).
Wygenerowany co 5 minut plik z nadmiarowymi cechami był propagowany globalnie.
Moduł Bot Management posiada limit liczby cech (ok. 200) oraz prealokację pamięci — przekroczenie limitu spowodowało panic/unwrap error w implementacji FL2 (Rust) i błędy HTTP 5xx.
W starszym silniku FL nie widać było 5xx, ale bot score = 0, co mogło generować fałszywe pozytywy w regułach antybotowych.
Dodatkowo wystąpiły wtórne skutki: Workers KV, Access, Turnstile oraz Dashboard notowały problemy logowania i wzrost opóźnień; część z nich złagodzono dzięki bypassowi KV ok. 13:04 UTC.

Dlaczego diagnoza była trudna?

System czasowo „sam się podnosił”, ponieważ jedne nody generowały „dobre”, a inne „złe” pliki — fluktuacja co ~5 min utrudniała identyfikację winowajcy.
Zbieg okoliczności: niedostępność status page (hostowanej poza infrastrukturą Cloudflare) wprowadziła podejrzenie skoordynowanego ataku.

Ostateczna naprawa: zatrzymanie generacji i dystrybucji wadliwego pliku, wstawienie „last-known-good”, restart proxy i stopniowe restartowanie zależnych usług.

Praktyczne konsekwencje / ryzyko

Ryzyko biznesowe: utrata przychodów, spadek konwersji, wizerunkowe koszty „internet stanął”. Dla spółek publicznych — wpływ na komunikację (przykład: zakłócone wydarzenia IR).
Ryzyko bezpieczeństwa: reguły oparte na bot score mogły w starszym FL reagować nieprawidłowo (score=0 → blokady/obejścia). Potencjalny degradujący wpływ na detekcję spamu w Email Security (chwilowy brak źródła reputacji IP).
Łańcuch dostaw (third-party risk): pojedyncza zmiana u dostawcy edge/CDN wpływa na dziesiątki krytycznych usług — konieczne plany obejścia i redundancja dostawców.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów SRE/Architektów:

Redundancja na warstwie CDN/edge: projektuj polityki active-active lub graceful degradation (np. fallback DNS → origin / alternatywny CDN) dla kluczowych ścieżek (auth, płatności, API).
Feature-flag kill switch: lokalne przełączniki wyłączające zależne moduły (np. scoring botów) bez restartu całego proxy/aplikacji. Cloudflare zapowiedział poszerzenie globalnych „kill switches” — odzwierciedl to po stronie klienta.
Walidacja „wewnętrznych” artefaktów konfiguracyjnych jak danych użytkownika: schemy, limity rozmiaru/rekordów, detekcja duplikatów, testy kontraktowe (CI/CD) dla plików konfig generowanych automatycznie.
Observability budżetowane: zabezpiecz systemy debugowania przed „zajadaniem CPU” przy masowych błędach (rate-limit na trace/log/error-reports).
Runbooki fail-open/fail-closed: jasno zdefiniuj tryby awaryjne dla modułów bezpieczeństwa (antybot/WAF) i konsekwencje biznesowe obu trybów.

Dla SecOps:

Polityki antybotowe oparte na wielu sygnałach, nie tylko globalnym „bot score”.
Monitorowanie skutków ubocznych (np. gwałtowny wzrost odrzuceń/akceptacji sesji) i gotowe reguły tymczasowe na czas degradacji dostawcy.
Komunikacja kryzysowa: zespół IR/PR + strona statusowa off-platform (poza dostawcą, z wieloma regionami i DNS-em niezależnym). Przykład problemów z dostępem do statuspage to lekcja o separacji zależności.

Dla devów aplikacyjnych:

Circuit breakers & timeouts na wywołaniach do usług edge.
Backpressure i retry-policy z jitterem (zapobiega lawinie po powrocie ruchu).
Tryb „read-only / degraded UI” zamiast pełnego 5xx dla krytycznych ścieżek.

Różnice / porównania z innymi przypadkami

W przeciwieństwie do typowych outage’y spowodowanych DDoS lub błędami sieciowymi, tu mieliśmy błąd w danych konfiguracyjnych + granice (limits) w module proxy, co ujawniło brak „twardych” walidacji dla artefaktów wewnętrznie generowanych (nie tylko dostarczanych przez klientów).
Od strony objawów incydent przypominał masowe ataki L7 (skok 5xx i fluktuacje), co utrudniło triage. Jednak root cause nie był security-atakiem, lecz regresją po zmianie uprawnień w ClickHouse.

Podsumowanie / kluczowe wnioski

„Trust but verify” dla własnych artefaktów konfiguracyjnych: walidacja, limity, schemy, canary rollout i globalne kill-switche.
Projektuj na awarie dostawcy edge: niezależna strona statusowa, multi-CDN, szybkie ścieżki bypass.
Observability z ograniczeniami: mechanizmy, które pomagają w diagnozie, nie mogą „zjadać” zasobów podczas katastrofy.
Ćwicz tryby degradacji: fail-open/fail-closed dla komponentów bezpieczeństwa i jasne runbooki.

Źródła / bibliografia

Szczegółowy post-mortem Cloudflare z osi czasu, technikaliami (ClickHouse, limit cech, FL/FL2): Cloudflare Blog — “Cloudflare outage on November 18, 2025”. (The Cloudflare Blog)
Relacja i wpływ na największe serwisy: Financial Times, Washington Post, The Verge, Reuters. (Financial Times)
Historia i status incydentów Cloudflare: Cloudflare Status / Incident History. (cloudflarestatus.com)

RondoDox wykorzystuje krytyczną lukę w XWiki (CVE-2025-24893) do przejmowania serwerów

Wprowadzenie do problemu / definicja luki

Nowa fala ataków botnetu RondoDox celuje w serwery XWiki, wykorzystując krytyczną podatność CVE-2025-24893 (CVSS 9.8), która umożliwia zdalne wykonanie kodu bez uwierzytelnienia. Zaatakowane instancje są włączane do sieci botnetu i wykorzystywane w kolejnych kampaniach. Informację o nowej taktyce RondoDox potwierdził m.in. serwis BleepingComputer.

W skrócie

Co się dzieje: RondoDox aktywnie skanuje i atakuje niezaktualizowane XWiki, wykorzystując CVE-2025-24893.
Dlaczego to groźne: Luka pozwala gościowi (niezalogowanemu) uruchomić kod na serwerze XWiki.
Skala/tempo: Eksploatacja tej podatności szybko się upowszechniła — od pojedynczego aktora do wielu grup (botnety, koparki, skanery).
Status w KEV: CISA dodała CVE-2025-24893 do katalogu Known Exploited Vulnerabilities 30 października 2025 r.
Remediacja: Luka załatana w XWiki 15.10.11, 16.4.1 i 16.5.0RC1.

Kontekst / historia / powiązania

Badacze VulnCheck zwrócili uwagę, że po pierwszych oznakach użycia CVE-2025-24893 do exploitu, w krótkim czasie dołączyły kolejne grupy: botnety, górnicy kryptowalut i oportunistyczni skanerzy. To klasyczny wzorzec „efektu kuli śnieżnej” po publikacji technicznych szczegółów luki.
Równolegle media branżowe raportują o „wzmożonej eksploatacji” XWiki w ostatnich dniach, a BleepingComputer precyzuje, że jednym z beneficjentów tej luki jest właśnie botnet RondoDox.

Analiza techniczna / szczegóły luki

CVE-2025-24893 dotyczy sposobu, w jaki XWiki przetwarza treści szablonów/makro w zapytaniach (m.in. kanał RSS wyszukiwarki Solr). Atakujący mogą wstrzyknąć i wykonać Groovy w kontekście serwera — bez logowania. NVD podaje nawet prosty test na podatność, który wykrywa wykonanie kodu w tytule zwracanego feedu RSS.
Skutkiem jest pełne zdalne wykonanie kodu (RCE). Broadcom/Symantec opisuje to jako możliwość wstrzyknięcia i wykonania dowolnego kodu Groovy przez spreparowane żądania.

Praktyczne konsekwencje / ryzyko

W praktyce przejęty serwer XWiki może zostać:

włączony do infrastruktury RondoDox (DDoS, pivot na inne cele, utrzymywanie C2),
wykorzystany do doinstalowania dodatkowego malware (koparki, skanery),
użyty jako przekaźnik/proxy w kolejnych atakach.
Szybka, wieloaktorowa adopcja exploitu zwiększa ryzyko masowych kompromitacji w krótkim czasie.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast aktualizuj XWiki do wersji 15.10.11, 16.4.1 lub 16.5.0RC1 (lub nowszej gałęzi naprawczej zgodnej z Twoją linią).
Zastosuj reguły WAF/IPS blokujące charakterystyczne ciągi/makra w endpointach wyszukiwarki/RSS oraz monitoruj nietypowe wywołania makr (np. {{groovy}}). (Wniosek na podstawie szczegółów NVD i opisów w Broadcom.)
Sprawdź kompromitację: logi aplikacyjne i reverse proxy dla nietypowych zapytań do /xwiki/bin/get/...SolrSearch?media=rss..., nowo utworzone konta, modyfikacje skryptów/makr, zadania cron, nieznane procesy powłoki. (Na bazie wektora z NVD.)
Segmentacja i zasada najmniejszych uprawnień: ogranicz ekspozycję XWiki do zaufanych sieci/VPN, odizoluj serwer od krytycznych segmentów. (Dobra praktyka bezpieczeństwa, wzmacniana przez obserwacje VulnCheck nt. szybkiej adopcji exploitu.)
Śledź KEV CISA i wdrażaj priorytetowe poprawki dla pozycji w katalogu (CISA KEV = aktywnie wykorzystywane).

Różnice / porównania z innymi przypadkami

W odróżnieniu od wielu wcześniejszych błędów XWiki (np. dotyczących właściwości klas czy nadużyć edytora), CVE-2025-24893 zapewnia RCE dla gościa poprzez przetwarzanie treści w publicznych endpointach (np. RSS Solr), co radykalnie zwiększa ryzyko skanów/automatyzacji przez botnety takie jak RondoDox. W efekcie czas od publikacji szczegółów do masowych nadużyć był wyjątkowo krótki.

Podsumowanie / kluczowe wnioski

RondoDox aktywnie przejmuje serwery XWiki, wykorzystując CVE-2025-24893.
Luka jest prosta do zautomatyzowania i już masowo eksploatowana przez różne grupy.
Aktualizacja XWiki do wersji naprawczych i twarde ograniczenie ekspozycji usług to priorytet „na już”.

Źródła / bibliografia

BleepingComputer: „RondoDox botnet malware now hacks servers using XWiki flaw” (17 listopada 2025). (BleepingComputer)
VulnCheck: „XWiki Under Increased Attack” (listopad 2025). (VulnCheck)
NVD: „CVE-2025-24893 – XWiki Platform injection vulnerability” (informacje o patchach i teście podatności). (NVD)
CISA: dodanie CVE-2025-24893 do KEV (30 października 2025). (CISA)
SecurityWeek: „Widespread Exploitation of XWiki Vulnerability Observed” (20 listopada 2025). (SecurityWeek)

Microsoft: botnet Aisuru użył 500 tys. IP w rekordowym ataku DDoS 15,72 Tb/s na Azure

Wprowadzenie do problemu / definicja luki

24 października 2025 r. platforma Microsoft Azure odparła wielowektorowy atak DDoS, który osiągnął 15,72 Tb/s oraz ~3,64 mld pakietów na sekundę (bpps). Telemetria wskazuje na botnet Aisuru (klasa „Turbo Mirai”), złożony głównie z przejętych urządzeń IoT i domowych routerów. Celem był pojedynczy publiczny adres IP klienta w Australii; atak prowadzono z ponad 500 tys. źródeł IP. Microsoft zaznacza, że mimo skali nie doszło do przerwy w działaniu obciążeń klientów dzięki automatycznym mechanizmom Azure DDoS Protection.

W skrócie

Skala: 15,72 Tb/s i ~3,64 mld pps — największy dotąd atak w chmurze wg Microsoftu.
Źródło: botnet Aisuru (Turbo Mirai), ponad 500 tys. IP w wielu regionach.
Wektor: krótkie, bardzo intensywne UDP floody z losowymi portami źródłowymi; znikome spoofing źródła.
Kontekst: Aisuru był wcześniej łączony z rekordem 22,2 Tb/s u Cloudflare (09.2025) i z incydentem 11,5 Tb/s opisywanym przez QiAnXin XLab.

Kontekst / historia / powiązania

O Aisuru głośno było już w 2024–2025 r. jako o jednej z największych farm IoT do DDoS i proxy. Badacze XLab (QiAnXin) wskazywali m.in. na gwałtowny przyrost puli botów po kompromitacji serwera aktualizacji firmware routerów TotoLink (wiosna 2025), co pomogło botnetowi przekroczyć setki tysięcy urządzeń. Jesienią 2025 r. Aisuru łączono również z rekordowym atakiem 22,2 Tb/s / 10,6 mld pps odpartym przez Cloudflare.

W październiku 2025 r. Brian Krebs opisał też „przestawienie” Aisuru na monetyzację poprzez wynajem ruchu proxy rezydencyjnego (sprzedaż przepustowości z zainfekowanych urządzeń), co nie wyklucza użycia tego samego zaplecza do super-wolumetrycznych DDoS.

Analiza techniczna / szczegóły ataku

Według Microsoftu, incydent w Azure był krótki i impulsowy, oparty o ekstremalnie szybkie wybuchy UDP wymierzone w pojedynczy publiczny IP. Ruch cechowały losowe porty źródłowe i minimalny spoofing, co paradoksalnie ułatwiło traceback i egzekwowanie filtrów po stronie operatorów (provider enforcement). Całość rozchodziła się geograficznie — ponad 500 tys. IP z wielu regionów — co jest typowe dla nowoczesnych botnetów IoT dysponujących szerokim „last mile” w sieciach ISP.

Profil Aisuru. Microsoft klasyfikuje Aisuru jako botnet Turbo Mirai-class, infekujący m.in. kamery IP, DVR/NVR, routery i inne urządzenia o niskiej higienie bezpieczeństwa. Raporty branżowe z 2025 r. łączyły go z rekordowymi atakami i setkami tysięcy botów; XLab opisywał skok liczebności po incydencie z serwerem aktualizacji.

Praktyczne konsekwencje / ryzyko

Ryzyko dla dostępności: jednosekundowe piki rzędu Tb/s potrafią przeciążyć łącza uprzedzające scrubbery, jeśli architektura nie jest anycast + autoscale. Ataki impulsowe utrudniają ręczne reagowanie (okno decyzji to często sekundy). (Wniosek na podstawie publicznych opisów vektorów i skali ataku.)
Łańcuch dostaw IoT: powtarzalne kompromitacje firmware/aktualizacji oraz słabe domyślne konfiguracje zwiększają pulę „zombie” dostępnych dla Aisuru i klonów.
Efekt uboczny proxy: botnety łączą modus DDoS i „residential proxy”, co podnosi opłacalność i długowieczność infrastruktury przestępczej.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów korzystających z Azure

Włącz/zweryfikuj Azure DDoS Protection (Standard/Protection Plan) na krytycznych VNet — zapewnij telemetrię i automatyczną mitgację L3/L4. Przetestuj profile adaptacyjne i alerting.
Segmentuj ekspozycję IP: ogranicz publiczne IP, używaj Azure Front Door / CDN + WAF, a dla UDP — jeśli to możliwe — ratelimiting/quotas po stronie aplikacji i protokołów. (Rekomendacje zgodne z dobrymi praktykami Microsoft Learn dot. DDoS.)
Gotowość operacyjna: ćwicz runbooki na scenariusze krótkich pików (sekundy–minuty): szybka eskalacja, zrzuty NetFlow, migawki NSG, kontakt z ISP.

Dla operatorów/ISP i SOC

FiDoS/flowspec / RTBH: przygotowane szablony filtrów na impulsowe UDP z losowymi portami źródłowymi; automatyzacja aktywacji. (Wniosek operacyjny na bazie wektora ataku.)
Higiena IoT u abonentów: kampanie wymuszające aktualizacje, blokady znanych C2, filtry na wzorce skanowania Mirai-class.
Telemetria i współdzielenie IOC: stała wymiana wskaźników między chmurą, IX-ami i operatorami (troubleshooting tracebacku ułatwił niski spoofing).

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

15,72 Tb/s (Azure) vs 22,2 Tb/s (Cloudflare): incydent Microsoftu to największy „w chmurze” wg Azure, ale rekord absolutny opisywany publicznie w 2025 r. padł u Cloudflare (22,2 Tb/s przez ~40 s). Różne środowiska, podobny hiper-wolumetryczny profil i udział Aisuru.
Aisuru vs „klasyczne” Mirai: Aisuru należy do linii Turbo Mirai — nacisk na impulsy wysokiego bpps/Tb/s i szeroką geograficznie dyspersję „last mile”, co utrudnia prosty geo-blackhole i wymusza automatyczną mitigację blisko źródeł.

Podsumowanie / kluczowe wnioski

Automatyzacja wygrywa z sekundami. Ataki impulsowe o sile Tb/s wymagają w pełni automatycznych ścieżek detekcji i mitigacji — ręczne playbooki nie wystarczą.
IoT to paliwo rakietowe dla DDoS. Ekosystem tanich, słabo zarządzanych urządzeń będzie dalej windował sufity bpps/Tb/s (casus Aisuru).
Higiena aktualizacji i łańcuch dostaw po stronie producentów/ISP to klucz do dławienia podaży botów — inaczej kolejne rekordy są kwestią czasu.

Źródła / bibliografia

Microsoft Azure Infrastructure Blog: „Defending the cloud: Azure neutralized a record-breaking 15 Tbps DDoS attack” (17.11.2025). (TECHCOMMUNITY.MICROSOFT.COM)
BleepingComputer: „Microsoft: Azure hit by 15 Tbps DDoS attack using 500,000 IP addresses” (17.11.2025). (BleepingComputer)
QiAnXin XLab: „The Most Powerful Ever? Inside the 11.5Tbps-Scale Mega Botnet AISURU” (15.09.2025). (blog.xlab.qianxin.com)
SecurityWeek: „Record-Breaking DDoS Attack Peaks at 22 Tbps and 10 Bpps” (24.09.2025). (SecurityWeek)
KrebsOnSecurity: „Aisuru Botnet Shifts from DDoS to Residential Proxies” (28.10.2025). (krebsonsecurity.com)

Cyberatak na rosyjskiego operatora portowego Port Alliance: celem zakłócenie eksportu węgla i nawozów

Wprowadzenie do problemu / definicja luki

Rosyjski operator portowy Port Alliance poinformował o trwającym trzy doby cyberataku „z zagranicy”, obejmującym zmasowany DDoS oraz próbę włamania do elementów krytycznych infrastruktury cyfrowej. Według spółki, celem było zdestabilizowanie procesów biznesowych i zakłócenie eksportu węgla oraz nawozów z terminali na akwenach: Bałtyk, Morze Azowsko-Czarne, Daleki Wschód i Arktyka. Firma twierdzi, że atak został odparty i nie spowodował przerw w pracy terminali.

W skrócie

Typ ataku: wielowektorowy — DDoS + próba intruzji (intrusion attempt) w sieci IT/operatora.
Cel deklarowany przez ofiarę: zakłócenie eksportu węgla i nawozów (wpływ na łańcuchy dostaw surowców).
Czas trwania: ok. 3 dni.
Zasięg operacyjny Port Alliance: terminale w kilku rosyjskich basenach morskich (Bałtyk, Morze Czarne/Azowskie, Daleki Wschód, Arktyka).
Stan na dziś: operator utrzymuje, że działalność nie została przerwana. (Deklaracja spółki).

Kontekst / historia / powiązania

Od 2022 r. sektor morski w regionie notuje wzmożoną aktywność cybernetyczną — od ataków DDoS i włamań po zakłócanie systemów telekomunikacyjnych i nawigacyjnych. W ostatnich miesiącach na Morzu Czarnym i Bałtyku obserwowano także kinetyczne uderzenia w infrastrukturę portową; równolegle pojawiają się doniesienia o atakach informatycznych na operatorów terminali, co wpisuje się w schemat działań hybrydowych wobec transportu morskiego i energetyki. Bieżący incydent wobec Port Alliance to kolejny przykład presji na logistykę surowców (węgiel, nawozy), istotną dla bilansu handlowego Rosji.

Analiza techniczna / szczegóły luki

1) Warstwa IT (Enterprise)

Z komunikatów prasowych i depesz wynika przede wszystkim DDoS na warstwę aplikacyjną/sieciową oraz „próba włamania” do elementów infrastruktury cyfrowej. Realistyczny scenariusz obejmuje:

L7 HTTP(S) flood (np. mis-use przeglądarek/„proxy-botnetów” i sieci VPN do obejścia GeoIP/WAF), uzupełniony L3/L4 volumetric (SYN/UDP/ACK floods) w celu wyczerpania zasobów brzegowych.
Równoległe password-spraying/credential-stuffing na portale B2B (EDI/booking), bramki API i panele partnerów (TOS/slot booking), by utrudnić obsługę łańcucha dostaw (np. rezerwacje okien przeładunkowych).
Potencjalne próby wykorzystania podatności w popularnych komponentach portowych (reverse proxy/WAF, ERP TOS-adjacent, VPN gateways).

Wskaźniki obserwacyjne (przykładowe):

Nieregularne piki w metrykach nginx_ingress_controller_requests, 5xx_ratio, wzrost RTT na ścieżkach do upstreamów, równoległy spike w conntrack_count.
Nietypowe UA/JA3/JA4, nienaturalna dystrybucja ASN/Geo, low TTL i brak zgodności TCP option fingerprint z typowym ruchem klientów.

2) Warstwa operacyjna (OT/ICS) – ryzyko pośrednie

Brak publicznych danych o wejściu do systemów OT (SCADA/PLC). Jednak doświadczenie z incydentów portowych pokazuje, że największy wpływ osiąga się przez uderzenie w TOS (Terminal Operating System) i systemy towarzyszące (gate/yard planning, OCR/bramownice, EDI z armatorami), czyli IT, które steruje fizycznym ruchem. Nawet „tylko” DDoS na portale awizacyjne potrafi przenieść chaos na plac składowy i nabrzeża (kolejki ciężarówek, błędne zlecenia, opóźnienia holowników).

3) Wiarygodność deklaracji

Oświadczenia operatora i rosyjskich mediów potwierdzają DDoS + próby włamań i trzy doby aktywności; jednocześnie firmy często komunikują „brak wpływu”, gdy realny efekt ogranicza się do systemów peryferyjnych (np. public WWW, CRM) — tego publicznie nie zweryfikowano. Wersję o „braku zakłóceń” należy traktować ostrożnie, dopóki niezależne źródła nie pokażą danych operacyjnych (ETA statków, czas postoju, throughput).

Praktyczne konsekwencje / ryzyko

Krótkoterminowe: spadek dostępności portali klientowskich, utrudniona komunikacja EDI/API z operatorami kolejowymi i armatorami; ryzyko niezsynchronizowanych wypchnięć ładunków (coal/fertilizers) i opóźnień w rozliczeniach.
Średnioterminowe: jeśli intruzja wykraczała poza DDoS (np. dostęp do systemów planowania lub list ładunkowych), możliwe zakłócenia harmonogramów i eskalacja oszustw (np. manipulacje dokumentami, podszycia w łańcuchu EDI).
Systemowe: incydent wpisuje się w trend ataków na logistykę morską i energetykę; presja na porty ma efekt dźwigni — uderzając w kilka kluczowych węzłów, wpływa się na wiele sektorów (energetyka, rolnictwo, chemia).

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw „szybkich wygranych” i działań średnioterminowych dla operatorów portowych, armatorów i firm logistycznych. Przygotowane pod kątem SOC/Blue Team/NetOps/OT.

1) Tłumienie DDoS (edge/WAF/DNS)

Warstwa L7 (HTTP/S) – NGINX / Envoy / WAF

# NGINX: prosta ochrona L7 (rate limiting + burst)
limit_req_zone $binary_remote_addr zone=rl_zone:10m rate=5r/s;
limit_req_status 429;

server {
  listen 443 ssl http2;
  # ...
  location / {
    limit_req zone=rl_zone burst=50 nodelay;
    # WAF header/JA3/JA4 anomaly check via lua/sidecar
    proxy_read_timeout 30s;
  }
}

Warstwa L4 – iptables/nftables (przykład szybkiego throttlingu)

# iptables: throttling SYN na interfejsie WAN
iptables -A INPUT -p tcp --syn -m limit --limit 50/second --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

Anycast/DNS i „fronty” anty-DDoS

Rozważ Anycast + scrubbing (komercyjni dostawcy) dla krytycznych FQDN (EDI/API/booking).
Geo-fencing + ASN allowlist dla paneli B2B — zdejmuje sporą część szumu botnetowego.

2) Ochrona kanałów B2B (EDI/API/partnerzy)

mTLS + JWT z krótkim TTL, HMAC-sig na payloadach EDI.
„Positive security model” na API: allowlist metod, rate i schema-validation (np. OAS → spectral w CI).
Wymuś per-partner client cert i źródła IP; monitoruj odchylenia JA3/JA4.

3) Detekcja & reagowanie (SOC)

Szybkie reguły Suricata (L7 flood i anomalia UA)

alert http any any -> $HOME_NET any (msg:"L7 burst (URL hot)"; flow:established,to_server;
  detection_filter: track by_src, count 100, seconds 1; classtype:attempted-dos; sid:900001; rev:1;)

alert http any any -> $HOME_NET any (msg:"Suspicious UA massing";
  content:"User-Agent|3a| curl/"; http_header; threshold:type both, track by_src, count 50, seconds 60;
  classtype:attempted-recon; sid:900002; rev:1;)

Alerting (Prometheus/Grafana)

# Przykładowa reguła: skok 5xx i jednoczesny wzrost połączeń
- alert: PossibleL7DDoS
  expr: (sum(rate(nginx_ingress_controller_requests{status=~"5.."}[1m])) /
         sum(rate(nginx_ingress_controller_requests[1m])) > 0.2)
        and (sum(rate(node_netstat_Tcp_CurrEstab[1m])) > 2 * avg_over_time(node_netstat_Tcp_CurrEstab[30m]))
  for: 2m
  labels: {severity: "high"}
  annotations: {summary: "Podejrzenie L7 DDoS"}

4) Segmentacja i „blast radius”

Oddziel IT od OT (firewalle warstwowe, jump hosty, unidirectional gateways dla telemetry) oraz „crown jewels”: TOS, billing, gate OCR.
JIT-access do VPN/administracji; MFA z odpornością na phishing (FIDO2/Passkeys).
Backupy 3-2-1 kluczowych baz (TOS/EDI) z testami restore.

5) Procedury ciągłości działania (BCP) dla portu

Tryb degradacji: papierowe awiza, manualne plany yardu, komunikacja VHF/SMS awaryjna, offline-listy ładunkowe — ćwiczone co najmniej kwartalnie.
Ćwiczenia Red/Blue-Team z naciskiem na scenariusze: „DDoS + social + EDI fraud” i „TOS read-only”.

Różnice / porównania z innymi przypadkami

Ataki DDoS na operatorów portowych zwykle mierzą w widoczną warstwę web/API (krótkotrwały, ale głośny wpływ). Tu profil pasuje — duży ruch na L7/L4 i deklarowana próba intruzji.
Ataki kinetyczne na porty (np. ostatnie uderzenia dronowe na infrastrukturę w regionie Morza Czarnego) wywołują natychmiastowy efekt operacyjny; cyber bywa „niemy”, ale może zwiększyć tarcie i wydłużyć recovery po incydencie fizycznym. (Kontekst regionalny).

Podsumowanie / kluczowe wnioski

Incydent wobec Port Alliance wpisuje się w trend presji na węzły logistyczne — nawet jeśli atak został „odparty”, już sama konieczność przełączenia na tryb awaryjny generuje koszty i opóźnienia.
DDoS + próba włamania to klasyczny duet: huk informacyjny i zasłona dla cichszej intruzji.
Operatorzy portowi powinni traktować portale EDI/API jak systemy krytyczne (mTLS, allowlist, Anycast, scrubbing), a TOS i bramy OCR segmentować jak OT.
Ćwiczenia BCP i telemetria L3-L7 (w tym JA3/JA4, HTTP semantics) są dziś równie ważne jak firewalle.

Źródła / bibliografia

The Record (Recorded Future News): „Cyberattack on Russian port operator aimed to disrupt coal, fertilizer shipments” – 14 listopada 2025. (The Record from Recorded Future)
Reuters: „Big Russian port operator says its systems were targeted by foreign hackers” – 13 listopada 2025. (Reuters)
RBC (РБК): „«Портовый альянс» сообщил о масштабной хакерской атаке на сети портов” – 13 listopada 2025. (РБК)
PortsEurope: „Cyber attack against Russia’s Port Alliance” – 14 listopada 2025. (Ports Europe)
(Kontekst regionalny) Reuters: „Ukrainian drones damage ship… Novorossiysk” – 14 listopada 2025. (Reuters)

Krytyczna luka „authentication bypass” w routerach ASUS DSL (CVE-2025-59367) — co musisz zrobić teraz

Wprowadzenie / definicja luki

ASUS potwierdził krytyczną podatność typu authentication bypass w wybranych modelach routerów z serii DSL. Luka CVE-2025-59367 pozwala zdalnemu, nieautoryzowanemu napastnikowi zalogować się do urządzenia bez podawania poprawnych poświadczeń — atak jest niskozłożony i nie wymaga interakcji użytkownika. Producent wydał firmware naprawczy 1.1.2.3_1010 m.in. dla DSL-AC51, DSL-N16 oraz DSL-AC750.

W skrócie (TL;DR)

CVE-2025-59367: krytyczny bypass autoryzacji w routerach ASUS DSL.
Modele: m.in. DSL-AC51, DSL-N16, DSL-AC750 (lista może być szersza; sprawdź stronę wsparcia swojego modelu).
Fix: zainstaluj firmware 1.1.2.3_1010 (jeśli dostępny dla Twojego modelu).
Jeśli nie możesz zaktualizować (EOL): wyłącz wszystkie usługi wystawione do Internetu (WAN admin, port forwarding, DDNS, VPN server, DMZ, port triggering, FTP) i wzmocnij hasła.

Kontekst / historia / powiązania

Routery SOHO są regularnie wykorzystywane do budowy botnetów DDoS. W 2025 r. CISA i badacze sygnalizowali kampanie przejmowania urządzeń ASUS przez zaawansowanych przeciwników (np. do tworzenia nowych botnetów), co podnosi ryzyko szybkiej weaponizacji świeżych luk. Dodatkowo w kwietniu 2025 ASUS łatał niezależną, krytyczną podatność w AiCloud (CVE-2025-2492), również umożliwiającą obejście autoryzacji.

Analiza techniczna / szczegóły luki

Identyfikator: CVE-2025-59367; klasyfikowana jako Authentication Bypass (CWE-288).
Skutek: zdalny dostęp do panelu administracyjnego bez ważnych poświadczeń → możliwość zmiany konfiguracji, wgrania własnych reguł, przekierowań portów, aktualizacji złośliwym firmware, a w efekcie pełnego przejęcia ruchu.
Złożoność: niska; brak interakcji użytkownika.
Modele/wersje: ASUS potwierdził problem w serii DSL; dla DSL-AC51/DSL-N16/DSL-AC750 dostępny jest firmware 1.1.2.3_1010. W innych modelach status zależy od strony wsparcia danego produktu.

Uwaga: Oficjalna karta CVE (NVD/CVE.org) wskazuje na sekcję „Security Update for DSL Series Router” w advisory ASUS jako źródło — warto weryfikować status konkretnego modelu w jego karcie wsparcia.

Praktyczne konsekwencje / ryzyko

Przejęcie urządzenia brzegowego: atakujący może skonfigurować proxy, przekierowania (port forwarding/DMZ), a nawet dodać złośliwe certyfikaty.
Podsłuch/mitm w sieci LAN/WLAN (kontrola DNS, statyczne trasy, reguły NAT).
Wpięcie do botnetu i wykorzystanie do wolumetrycznych DDoS lub pivotu do środowiska firmowego.
Utrudniona detekcja: wiele ataków na routery pozostaje niewidocznych w EDR/SIEM, bo urządzenia są poza zakresem telemetrii endpointowej.
Te wektory są zgodne z dotychczasowymi nadużyciami błędów w routerach ASUS raportowanymi w 2025 r.

Rekomendacje operacyjne (co zrobić teraz)

1) Patch management

Wejdź na stronę wsparcia swojego modelu (np. DSL-AC51), pobierz najnowszy firmware (1.1.2.3_1010 jeśli wskazany dla modelu), zweryfikuj sumę i zaktualizuj przez panel Administration → Firmware Upgrade.

2) Natychmiastowe twardnienie (także dla EOL)

Wyłącz ekspozycję do Internetu (WAN): Remote Access from WAN, Administration over WAN, Port Forwarding, DDNS, VPN Server, DMZ, Port Triggering, FTP.
Ustaw silne, unikalne hasła dla admina i Wi-Fi, nie używaj ponownie poświadczeń.
Regularnie sprawdzaj dostępność nowych firmware’ów.

3) Szybkie testy bezpieczeństwa (z hosta w tej samej sieci i z zewnątrz)

# Z LAN: sprawdź czy panel nie jest przywiązany do 0.0.0.0/wan
nmap -p 80,443,22,21,8080,8443 192.168.1.1 -sV --script http-auth,ssl-cert

# Z zewnątrz (na VPS): upewnij się, że WAN nie wystawia panelu
nmap -Pn -p 80,443,8080,8443 <twoje_publiczne_IP> --reason

# Test podstawowej ochrony HTTP na panelu
curl -I http://192.168.1.1/ | sed -n '1,10p'

4) Monitorowanie i forensyka sieci domowej/małej firmy

Przejrzyj logi routera (szczególnie logowania, zmiany konfiguracji, nowe reguły NAT/port forwarding).
Zweryfikuj DNS (czy nie zmieniono na obce serwery), listę UPnP i DDNS.
Rozważ reset do fabrycznych + wgranie najnowszego firmware od razu po reboocie.

5) Segmentacja

Oddziel IoT/Wi-Fi gościnne od sieci produkcyjnej (VLAN/oddzielny SSID).
Zablokuj dostęp z VLAN IoT do panelu admina routera (ACL).

6) Polityka dla urządzeń EOL

Jeśli Twój model jest EOL i nie otrzyma poprawki — pozostaw go bez usług WAN lub wymień na wspierany. Rekomendowane przez ASUS kroki (wyłączenie usług WAN + mocne hasła) traktuj jako tymczasowe.

Różnice / porównania z innymi przypadkami (AiCloud — CVE-2025-2492)

CVE-2025-59367 (ten przypadek): dotyczy serii DSL; bypass autoryzacji prowadzący do nieuprawnionego dostępu do urządzenia.
CVE-2025-2492 (kwiecień 2025): dotyczył funkcji AiCloud w szerszym zakresie modeli; również umożliwiał obejście autoryzacji i wykonywanie funkcji bez uprawnień. W obu przypadkach ryzyko przejęcia admina jest wysokie, ale zakres modeli/feature jest inny, a więc i ścieżki detekcji/mitigacji mogą się różnić (np. wyłączenie AiCloud vs. wyłączenie usług WAN).

Podsumowanie / kluczowe wnioski

Luka CVE-2025-59367 jest krytyczna i prosta w nadużyciu — aktualizacja firmware to priorytet.
Jeżeli nie możesz zaktualizować (EOL), odetnij usługi WAN i twardnij konfigurację — traktuj to jako most do wymiany sprzętu.
Utrzymuj higienę routera: aktualizacje, brak zdalnego admina z Internetu, segmentacja, silne hasła i monitoring konfiguracji.

Źródła / bibliografia

BleepingComputer — ogłoszenie o luce, modele, rekomendacje i firmware 1.1.2.3_1010. (BleepingComputer)
NVD (CVE-2025-59367) — wpis CVE, klasyfikacja i odnośnik do advisory ASUS. (NVD)
CVE.org (CVE-2025-59367) — rejestr CVE zarządzany przez CNA ASUS. (cve.org)
Strona wsparcia modelu DSL-AC51 (lista zmian firmware). (ASUS)
NVD (CVE-2025-2492) — kontekst historyczny (AiCloud, kwiecień 2025). (NVD)