Wprowadzenie do problemu / definicja
Dysphoria to nowa odsłona botnetu klasy IoT, która rozwija techniki utrudniające wykrycie i przejęcie infrastruktury sterującej. Kluczową zmianą jest wykorzystanie usług nazw opartych na blockchainie do odnajdywania elementów command-and-control oraz użycie przejętych urządzeń jako warstwy pośredniczącej między botami a właściwą infrastrukturą operatorów.
Taki model znacząco zwiększa odporność kampanii na klasyczne działania obronne, takie jak sinkholing, blokowanie domen czy przejmowanie pojedynczych serwerów C2. W praktyce oznacza to, że botnet może szybciej odtwarzać swoją infrastrukturę i skuteczniej ukrywać rzeczywiste punkty zarządzania.
W skrócie
- Dysphoria jest łączona z linią rozwojową botnetu JackSkid.
- Po zakłóceniu wcześniejszej infrastruktury operatorzy mieli przejść na model oparty na ENS i SNS.
- Botnet rozprzestrzenia się przez słabe hasła Telnet i SSH oraz przez znane luki w urządzeniach brzegowych.
- Istnieje wariant relay-only, w którym przejęte hosty pełnią funkcję przekaźników ruchu zamiast bezpośrednio prowadzić ataki DDoS.
- Architektura oparta na blockchainie i warstwie relay utrudnia identyfikację oraz neutralizację operatorów.
Kontekst / historia
Punktem zwrotnym dla tej rodziny zagrożeń były działania wymierzone w kilka botnetów IoT, w tym JackSkid. Po zakłóceniu dotychczasowej infrastruktury operatorzy najwyraźniej przyspieszyli migrację do bardziej rozproszonego i trudniejszego do usunięcia modelu komunikacji.
Z dostępnych analiz wynika, że już krótko po marcowych działaniach przeciwko wcześniejszej infrastrukturze zaczęły pojawiać się próbki korzystające z nazw rejestrowanych w ekosystemach blockchainowych. W kolejnych tygodniach zaobserwowano dalszy rozwój funkcji ukrywania infrastruktury, rozszerzanie mechanizmów rozwiązywania nazw oraz większy nacisk na pośredniczenie ruchu zamiast wyłącznie na klasyczne kampanie DDoS.
To sugeruje dojrzewanie architektury botnetu. Zamiast prostego, scentralizowanego modelu sterowania pojawia się konstrukcja warstwowa, w której część zainfekowanych urządzeń pełni rolę bufora i osłony dla właściwych serwerów operatorów.
Analiza techniczna
Technicznie Dysphoria odchodzi od klasycznego schematu, w którym malware łączy się z twardo zakodowanym adresem IP albo domeną DNS. Zamiast tego próbki odwołują się do rekordów publikowanych w usługach nazw powiązanych z blockchainem. Takie rekordy mogą zawierać informacje potrzebne do odnalezienia aktywnej infrastruktury sterującej lub węzłów pośredniczących.
Model działania można opisać etapowo. Najpierw bot pobiera dane o punkcie wejścia z mechanizmu nazewniczego opartego na blockchainie. Następnie komunikuje się z węzłem dystrybucyjnym, który przekazuje listę aktywnych serwerów lub hostów relay. W efekcie część ruchu nie trafia bezpośrednio do właściwego C2, lecz przechodzi przez inne zainfekowane urządzenia.
Taka architektura utrudnia namierzanie operatorów, ponieważ rzeczywiste serwery sterujące są odsunięte od botów o co najmniej jedną warstwę. Nawet jeśli obrońcy zidentyfikują i odetną część relay nodes, operator może stosunkowo łatwo odtworzyć ścieżki komunikacji przez aktualizację rekordów i podmianę pośredników.
Istotnym elementem ewolucji jest wariant relay-only. Tego rodzaju próbka może nie zawierać pełnego zestawu modułów odpowiedzialnych za ataki DDoS, lecz koncentruje się na przekazywaniu ruchu między połączeniem przychodzącym a zdalnym punktem usługowym C2. Dzięki temu zainfekowane urządzenia stają się elementami ukrytej sieci transportowej, a nie tylko prostymi botami wykonującymi polecenia.
W analizach wskazano również użycie mechanizmów UPnP do mapowania portów na lokalnym urządzeniu brzegowym. To zwiększa szanse na zestawienie połączeń przez NAT i umożliwia wykorzystanie przejętych urządzeń jako dostępnych z Internetu punktów pośrednich. Taki mechanizm ma duże znaczenie w środowiskach domowych i małych firmach, gdzie routery oraz urządzenia IoT często są słabo monitorowane.
Wektor infekcji pozostaje typowy dla ekosystemu IoT. Najczęściej chodzi o brute force lub credential stuffing wobec usług Telnet i SSH, a także o wykorzystanie znanych podatności zdalnego wykonania kodu. W materiałach analitycznych pojawia się między innymi CVE-2025-9528 dotyczące podatności command injection w urządzeniach Linksys E1700, choć sama obecność tej luki nie musi oznaczać, że jest ona głównym kanałem propagacji całej kampanii.
Konsekwencje / ryzyko
Najważniejszym skutkiem wdrożenia blockchain-based C2 jest wzrost odporności operacyjnej botnetu. Tradycyjne działania defensywne, takie jak blokowanie pojedynczych domen, odcinanie jednego adresu IP czy przejęcie pojedynczego serwera, przestają być wystarczające. Infrastruktura może być szybciej odbudowywana, a boty mogą otrzymywać zaktualizowane informacje o nowych punktach dostępowych.
Drugim istotnym ryzykiem jest wykorzystanie ofiar jako przekaźników. Dla zespołów bezpieczeństwa oznacza to trudniejszą analizę ruchu sieciowego, ponieważ przejęte urządzenie może nie tylko odbierać polecenia, ale również przekazywać komunikację innych węzłów. W rezultacie infrastruktura ofiary może zostać wykorzystana do maskowania źródła ruchu, pośredniczenia w atakach lub wspierania dalszych etapów operacji botnetu.
Z perspektywy organizacji problem dotyczy przede wszystkim routerów SOHO, kamer IP, bram, urządzeń przemysłowych i innych systemów brzegowych, które nie są regularnie aktualizowane albo nadal korzystają z domyślnych lub słabych poświadczeń. W takich środowiskach ryzyko trwałej kompromitacji i niewidocznego udziału w kampaniach przestępczych pozostaje wysokie.
Rekomendacje
Podstawą obrony pozostaje zmniejszenie powierzchni ataku urządzeń IoT. Należy wyłączyć domyślne konta, wdrożyć silne i unikalne hasła oraz wszędzie tam, gdzie to możliwe, wyłączyć Telnet na rzecz lepiej kontrolowanych metod administracji. Zdalne zarządzanie nie powinno być wystawiane bezpośrednio do Internetu, lecz udostępniane przez VPN albo wydzielony segment administracyjny.
Organizacje powinny prowadzić pełny inwentarz urządzeń IoT i regularnie weryfikować ich stan aktualizacji. Sprzęt niewspierany przez producenta należy traktować jako wysokie ryzyko i w zależności od możliwości wymieniać lub izolować w odseparowanych segmentach sieci.
W praktyce warto wdrożyć następujące działania:
- wyłączyć lub ograniczyć Telnet i niepotrzebne usługi administracyjne,
- stosować silne hasła oraz rotację poświadczeń dla urządzeń brzegowych,
- blokować UPnP tam, gdzie nie jest niezbędne biznesowo,
- segmentować urządzenia IoT od stacji roboczych i kluczowych systemów,
- monitorować nietypowe połączenia wychodzące z kamer, routerów i bram,
- wykrywać nagły wzrost liczby sesji TCP inicjowanych przez urządzenia, które normalnie nie pełnią funkcji komunikacyjnych,
- wdrożyć procedury izolacji i analizy powłamaniowej dla urządzeń zachowujących się jak proxy lub relay.
Dobrą praktyką jest również budowanie reguł korelacyjnych pod kątem nietypowych zachowań urządzeń IoT. Jeśli kamera IP, router oddziałowy lub brama VoIP nagle zaczyna przekazywać znaczną liczbę sesji sieciowych, powinno to uruchamiać automatyczne alertowanie i działania ograniczające skutki incydentu.
Podsumowanie
Dysphoria pokazuje, że współczesne botnety IoT coraz częściej wykorzystują bardziej odporne i rozproszone architektury komunikacji. Połączenie blockchainowych usług nazw z warstwą przekaźnikową budowaną z urządzeń ofiar znacząco utrudnia likwidację infrastruktury C2 i zwiększa elastyczność operatorów.
Dla obrońców oznacza to konieczność wyjścia poza proste blokowanie wskaźników kompromitacji. Kluczowe pozostają higiena haseł, segmentacja, aktualizacje, ograniczanie ekspozycji usług administracyjnych oraz monitorowanie anomalii sieciowych w urządzeniach IoT. To właśnie te podstawowe mechanizmy wciąż stanowią najskuteczniejszą linię obrony przed botnetami nowej generacji.
Źródła
- The Hacker News — Dysphoria IoT Botnet Adds Blockchain C2 and Victim Relays After JackSkid Disruption — https://thehackernews.com/2026/07/dysphoria-iot-botnet-adds-blockchain-c2.html
- National Vulnerability Database — CVE-2025-9528 Detail — https://nvd.nist.gov/vuln/detail/CVE-2025-9528