Wprowadzenie do problemu / definicja luki
Pod koniec października 2025 r., równolegle z szeroką awarią usług AWS w regionie US-EAST-1, laboratoria FortiGuard zaobserwowały aktywność nowego botnetu ShadowV2 – wariantu Mirai ukierunkowanego na IoT (routery, NAS-y, DVR). Kampania wykorzystywała zestaw znanych podatności (n-day) m.in. w urządzeniach D-Link i TP-Link i – co istotne – była aktywna tylko w oknie trwania awarii, co badacze interpretują jako „próbny bieg” przed większymi operacjami.
W skrócie
- Czym jest ShadowV2? Mirai-like DDoS bot na IoT; identyfikuje się jako „ShadowV2 Build v1.0.0 IoT version”.
- Jak atakuje? Wektor wejścia przez znane luki (DD-WRT, D-Link, DigiEver, TBK, TP-Link), dropper binary.sh, C2 na silverpath.shadowstresser[.]info/81.88.18[.]108; ataki UDP/TCP/HTTP.
- Kiedy uderzył? W czasie globalnej awarii AWS 20–21 października 2025 r.; aktywność ograniczona do tego okna.
- Dlaczego to ważne? Daje sygnał o łączeniu kampanii IoT z trendem DDoS-as-a-Service opisanym wcześniej przez Darktrace (Docker, API, panel operatorski).
Kontekst / historia / powiązania
ShadowV2 pojawił się w badaniach wcześniej jako platforma DDoS-as-a-Service wykorzystująca kontenery Docker i komponenty w Python/Go, łącznie z rozbudowanym API i panelem operatorskim (m.in. mechanizmy HTTP/2 rapid reset, próby obejścia Cloudflare UAM). Ta „chmurowa” gałąź ShadowV2 łączy się teraz z falą infekcji IoT, co sugeruje projekt modułowy i dostosowanie do różnych środowisk (cloud + brzeg/IoT).
Analiza techniczna / szczegóły luki
Wykorzystywane podatności (wybrane):
- DD-WRT: CVE-2009-2765
- D-Link: CVE-2020-25506, CVE-2022-37055, CVE-2024-10914 (znana jako wykorzystywana; brak łatek dla modeli EoL), CVE-2024-10915 (D-Link potwierdził brak poprawek dla dotkniętych modeli).
- DigiEver: CVE-2023-52163
- TBK: CVE-2024-3721
- TP-Link: CVE-2024-53375 (naprawiana w wydaniu beta firmware).
Łańcuch infekcji i C2:
Eksploity → downloader binary.sh z 81.88.18[.]108 → pobranie binariów „shadow.*” → konfiguracja XOR (klucz 0x22) z nagłówkami UA i ścieżkami → rozwiązywanie silverpath.shadowstresser[.]info (fallback na IP) → rejestracja w C2 → wykonanie profili ataków UDP/TCP/HTTP (m.in. UDP flood, TCP SYN/ACK STOMP, HTTP flood). Artefakty pokrywają się ze stylem Mirai (LZRD) i potwierdzają orientację na DDoS.
Zasięg i branże:
Telemetria FortiGuard wskazuje na aktywność w 28+ krajach (Ameryki, Europa, Afryka, Azja, Oceania) oraz w co najmniej 7 sektorach: rząd, technologie, wytwórstwo, MSSP, telekomy/carrierzy, edukacja i retail/hospitality.
Praktyczne konsekwencje / ryzyko
- Ryzyko DDoS na żądanie: ShadowV2 może być wynajmowany do zalewania ruchem aplikacji/serwisów (UDP/TCP/HTTP), co zwiększa presję na warstwy L3–L7.
- Ekspozycja IoT i EoL: Duża część wektorów dotyczy urządzeń po końcu wsparcia (EoL) – brak łatek = trwała podatność.
- Okna zdarzeń podczas awarii chmurowych: globalne awarie (jak AWS 20.10.2025) tworzą „szum” operacyjny i zmieniają wzorce ruchu, co atakujący mogą traktować jako maskowanie testów C2/propagacji.
- Ryzyko mieszane cloud + edge: wcześniejsze kampanie ShadowV2 wobec Docker/EC2 łączą się teraz z IoT – to podnosi powierzchnię ataku po obu stronach łańcucha.
Rekomendacje operacyjne / co zrobić teraz
Dla SOC/Blue Team (24–48 h):
- Blokady sieciowe/IDS: dodać IoC z raportu Fortinet (domeny/IP C2, wzorce ruchu Mirai), wymusić blokadę rozwiązywania *.shadowstresser[.]info i 81.88.18[.]108.
- Polowanie (threat hunting): szukać pobrań binary.sh, anomalii HTTP z podejrzanymi UA oraz ruchu do publicznych DNS z urządzeń brzegowych.
- Telemetria warstw L3–L7: monitorować skoki UDP/TCP/HTTP flood i próby HTTP/2 rapid reset (na WAF/ADC).
Dla NetOps/SecOps (7 dni):
- Inwentaryzacja IoT/SoHo: zmapować modele D-Link/TP-Link/DVR/NAS; oznaczyć sprzęt EoL; tam gdzie producent nie łata – wymiana lub segregacja sieciowa (VLAN/ACL).
- Twardnienie urządzeń: wyłącz UPnP, WAN admin, zmień hasła, aktualizuj firmware (jeśli dostępny), włącz listy dozwolonych adresów dla paneli.
- Zasady DDoS-ready: profilowanie ruchu, scrubbing/blackholing u operatora, pre-shared runbook z dostawcą WAF/CDN.
- Gotowość na awarie chmurowe: plany degradacji usług (tryb offline), multi-region i fallback DNS; wnioski z awarii AWS (15+ godzin do pełnej odbudowy usług) wdrożyć do planów DR.
Dla chmury/DevOps:
- Przegląd ekspozycji Docker/EC2: zamknąć otwarte Docker API; egzekwować IAM least privilege; telemetryzować anomalie API (np. docker-sdk-python/*).
- Chaos engineering & runbooki: ćwiczyć awarie zależności (DynamoDB/DNS) i kolejki backlogów – lekcja z październikowej awarii AWS.
Różnice / porównania z innymi przypadkami
W odróżnieniu od „klasycznych” klonów Mirai, ShadowV2 łączy stare wektory IoT z nowoczesną logistyką operatorską (kontenery, API, panel, techniki L7 jak HTTP/2 rapid reset). To zbliża botnet bardziej do platformy usługowej (DDoS-aaS) niż do prostego robaka IoT.
Podsumowanie / najważniejsze wnioski
- ShadowV2 wykorzystał globalny „szum” awarii AWS jako okazję testową, sondując podatne urządzenia IoT w wielu krajach i sektorach.
- Trend jest jasny: konwergencja IoT + chmura + DDoS-aaS. Obrona wymaga jednocześnie higieny IoT, twardnienia chmury i gotowości DDoS.
- Organizacje z urządzeniami EoL muszą liczyć się z trwałą ekspozycją – segmentacja lub wymiana to jedyne skuteczne środki.
Źródła / bibliografia
- FortiGuard Labs: szczegółowa analiza ShadowV2 (IoC, CVE, C2, zasięg). (fortinet.com)
- BleepingComputer: omówienie kampanii podczas awarii AWS, status poprawek D-Link/TP-Link. (BleepingComputer)
- Darktrace (Inside the SOC): tło ShadowV2 jako DDoS-as-a-Service (Docker/EC2, panel, HTTP/2). (Darktrace)
- ThousandEyes: analiza awarii AWS 20.10.2025 (przyczyna DNS/DynamoDB, czas trwania, fazy odbudowy). (thousandeyes.com)
- Reuters: relacja newsowa z wpływu awarii (skala i usługi dotknięte). (Reuters)
