Archiwa: DDoS - Security Bez Tabu

Dysphoria: botnet IoT ukrywa C2 w blockchainie i wykorzystuje zainfekowane przekaźniki

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

Tengu: nowy botnet Mirai dla Linuksa wykorzystuje watchdog sprzętowy do utrudniania usuwania infekcji

Wprowadzenie do problemu / definicja

Tengu to nowa rodzina botnetu oparta na dziedzictwie Mirai, zaprojektowana do infekowania urządzeń działających pod kontrolą Linuksa, w tym systemów IoT, routerów, kamer, urządzeń brzegowych i platform embedded. Zagrożenie łączy klasyczne możliwości prowadzenia ataków DDoS z bardziej zaawansowanymi technikami utrwalania obecności w systemie oraz utrudniania działań naprawczych.

Najbardziej charakterystyczną cechą Tengu jest wykorzystanie watchdogu sprzętowego do wymuszania restartu urządzenia po przerwaniu głównego procesu malware. To oznacza, że tradycyjne działania administracyjne, takie jak ręczne zabicie procesu, mogą nie tylko nie usunąć zagrożenia, ale wręcz pomóc mu wrócić do działania po ponownym uruchomieniu systemu.

W skrócie

Tengu atakuje linuxowe urządzenia głównie przez brute force na usługach Telnet.
Po infekcji komunikuje się z serwerem C2 i obsługuje wiele metod ataków DDoS.
Malware potrafi uruchamiać proxy SOCKS5, wykonywać polecenia systemowe i pobierać dodatkowe ładunki.
Rozbudowane mechanizmy persistence utrudniają usunięcie infekcji.
Wykorzystanie watchdogu sprzętowego zwiększa skuteczność ponownej aktywacji po interwencji obrońców.

Kontekst / historia

Rodzina Mirai od lat pozostaje jednym z najważniejszych zagrożeń dla ekosystemu IoT. Jej skuteczność wynika z wykorzystywania słabo zabezpieczonych urządzeń dostępnych z internetu, zwłaszcza tych korzystających z domyślnych lub słabych danych uwierzytelniających. Tengu rozwija ten model, ale idzie o krok dalej, oferując operatorom bardziej elastyczne funkcje operacyjne i silniejsze mechanizmy samoobrony.

Według analiz, próbki Tengu były dostarczane za pomocą prostych skryptów powłokowych po skutecznym odgadnięciu poświadczeń przez Telnet. Złośliwe oprogramowanie przygotowano dla wielu architektur, co wskazuje na celowe ukierunkowanie na zróżnicowane środowiska linuxowe i embedded. Taka wieloarchitekturność zwiększa skalę potencjalnych infekcji i ułatwia operatorom budowę rozproszonej infrastruktury botnetu.

Analiza techniczna

Tengu działa jako malware wieloarchitekturne pobierane przez dropper z hosta powiązanego również z infrastrukturą dowodzenia i kontroli. Adres serwera C2 jest ukrywany i odszyfrowywany w czasie wykonania, co utrudnia analizę statyczną. Część komunikacji, taka jak rejestracja bota, heartbeat czy wyniki wykonanych poleceń, odbywa się jawnie, natomiast komendy operatorskie i aktualizacje są zabezpieczane mechanizmem szyfrowania przypominającym nowoczesne schematy strumieniowe.

Zakres funkcji malware jest szeroki i wykracza poza standardowy model prostego bota DDoS. Tengu potrafi zbierać informacje o systemie i sieci, wykonywać dowolne polecenia przekazane przez operatora, pobierać dodatkowe pliki ELF i APK, a także uruchamiać serwer proxy, domyślnie w wariancie SOCKS5. Dzięki temu zainfekowane urządzenie może być wykorzystywane nie tylko do zakłócania dostępności usług, ale również jako punkt pośredni do dalszych działań.

Botnet obsługuje również liczne techniki ataku DDoS obejmujące ruch UDP, TCP, ICMP oraz wybrane metody warstwy aplikacyjnej. To pozwala operatorom elastycznie dostosowywać typ ataku do celu oraz charakterystyki przejętych urządzeń.

Na szczególną uwagę zasługują mechanizmy persistence. Tengu może dodawać fałszywe usługi systemd, modyfikować skrypty init.d, ingerować w pliki startowe powłoki oraz podejmować próby utrwalenia przez cron. Dodatkowo malware może oznaczać swój plik jako immutable, co znacząco utrudnia jego usunięcie przy użyciu standardowych narzędzi administracyjnych.

Najgroźniejszym elementem jest jednak wykorzystanie watchdogu sprzętowego. Malware uruchamia proces pomocniczy podszywający się pod legalny komponent systemowy, otwiera urządzenie watchdog i utrzymuje jego aktywność. Jeżeli główny proces zostanie zabity, podtrzymywanie ustaje, a urządzenie może zostać automatycznie zrestartowane po upływie ustawionego czasu. Po restarcie wcześniejsze mechanizmy persistence próbują ponownie uruchomić złośliwe oprogramowanie.

Tengu stosuje również techniki utrudniające działania naprawcze i analizę. Należą do nich m.in. szyfrowanie stringów, wykonywanie z pamięci, maskowanie linii poleceń procesu, ignorowanie wybranych sygnałów systemowych, ograniczanie tworzenia zrzutów pamięci oraz kontrole antydebuggingowe. Malware może także usuwać konkurencyjne rodziny złośliwego oprogramowania z przejętego hosta, aby zachować pełną kontrolę nad urządzeniem.

Konsekwencje / ryzyko

Z punktu widzenia organizacji i operatorów infrastruktury Tengu zwiększa ryzyko na kilku poziomach. Po pierwsze, przejęte urządzenia mogą zostać wykorzystane do kampanii DDoS, co oznacza realne zagrożenie dla dostępności usług. Po drugie, obecność funkcji proxy i zdalnego wykonywania poleceń sprawia, że zainfekowany host może zostać użyty jako przystanek do dalszych operacji w sieci.

Dużym problemem są także mechanizmy persistence i wykorzystanie watchdogu sprzętowego. W praktyce błędnie przeprowadzona reakcja na incydent może doprowadzić do ponownej aktywacji infekcji po restarcie urządzenia. Dodatkowo modyfikacje binariów odpowiedzialnych za restart i wyłączanie systemu mogą utrudnić bezpieczne odseparowanie hosta od środowiska produkcyjnego.

Szczególnie zagrożone pozostają urządzenia IoT i embedded Linux wystawione do internetu, korzystające z Telnetu, domyślnych haseł, słabych poświadczeń lub nieaktualnego firmware. W środowiskach przemysłowych i edge skutki takiej infekcji mogą wykraczać poza sam incydent cyberbezpieczeństwa i prowadzić do zakłóceń operacyjnych.

Rekomendacje

Podstawową rekomendacją jest ograniczenie ekspozycji usług administracyjnych do internetu, zwłaszcza Telnetu. Jeżeli zdalny dostęp nie jest niezbędny, powinien zostać wyłączony. Tam, gdzie jest konieczny, należy stosować silne, unikalne hasła oraz odpowiednią kontrolę dostępu.

aktualizować firmware i oprogramowanie urządzeń IoT oraz embedded,
wyłączyć domyślne konta i zmienić fabryczne poświadczenia,
segmentować sieci IoT od zasobów krytycznych i środowisk użytkowników,
monitorować nietypowe połączenia wychodzące i aktywność proxy,
sprawdzać obecność podejrzanych usług systemd, wpisów init, cron i zmian w plikach startowych,
weryfikować integralność binariów systemowych odpowiedzialnych za restart i wyłączanie hosta,
podczas reakcji na incydent analizować mechanizmy persistence przed ponownym uruchomieniem urządzenia w środowisku produkcyjnym.

W środowiskach o podwyższonym ryzyku warto wdrożyć rozszerzony monitoring behawioralny, analizę telemetrii sieciowej oraz kontrolę anomalii związanych z wykonywaniem procesów z pamięci i nieautoryzowanymi zmianami w ścieżkach startowych systemu.

Podsumowanie

Tengu pokazuje, że współczesne warianty Mirai nie są już wyłącznie prostymi narzędziami do prowadzenia ataków DDoS. To rozbudowane malware, które łączy funkcje zdalnego sterowania, pobierania kolejnych ładunków, ukrywania aktywności i wielowarstwowego utrwalania obecności w systemie.

Wykorzystanie watchdogu sprzętowego jako mechanizmu antyremediation stanowi szczególnie niebezpieczny element tej kampanii. Dla zespołów bezpieczeństwa oznacza to konieczność traktowania urządzeń IoT i systemów embedded jako pełnoprawnej części powierzchni ataku oraz prowadzenia dokładnej analizy persistence przed przywróceniem takich urządzeń do eksploatacji.

Źródła

Dysphoria: botnet IoT z blockchainowym C2 utrudnia wykrywanie i neutralizację

Wprowadzenie do problemu / definicja

Dysphoria to nowa generacja botnetu IoT, która pokazuje wyraźną zmianę w sposobie budowy infrastruktury dowodzenia i kontroli. Zamiast opierać się wyłącznie na klasycznych, scentralizowanych serwerach C2, malware wykorzystuje rekordy w blockchainowych systemach nazw oraz sieć pośredników zbudowaną z wcześniej przejętych urządzeń. Taki model znacząco utrudnia zakłócenie działania botnetu i zwiększa jego odporność na standardowe metody blokowania.

W praktyce oznacza to, że zainfekowane urządzenie nie musi łączyć się bezpośrednio z głównym serwerem operatora. Może pobierać informacje o infrastrukturze z rozproszonych źródeł, a następnie komunikować się przez relaye działające na innych przejętych hostach. To podnosi koszt wykrycia kampanii i komplikuje analizę incydentów.

W skrócie

Dysphoria wyewoluowała po zakłóceniu wcześniejszej infrastruktury powiązanej z rodziną JackSkid.
Botnet wykorzystuje blockchainowe systemy nazw jako element mechanizmu C2.
Zainfekowane urządzenia mogą pełnić rolę relayów ukrywających właściwą infrastrukturę operatora.
Główne wektory infekcji to słabe hasła Telnet i SSH oraz wybrane podatności w urządzeniach IoT.
Celem pozostają operacje DDoS oraz utrzymanie odpornej, rozproszonej infrastruktury sterującej.

Kontekst / historia

Tło aktywności Dysphoria wiąże się z wcześniejszymi działaniami wymierzonymi w botnety IoT, w tym infrastrukturę JackSkid. Po zakłóceniu tych zasobów operatorzy szybko przeszli na bardziej odporny model komunikacji, ograniczając zależność od pojedynczych, łatwych do przejęcia serwerów.

Analizy opisywane publicznie wskazują, że od końca marca do czerwca 2026 roku malware było intensywnie rozwijane. W kolejnych wariantach pojawiły się funkcje szyfrowania ciągów znaków, obsługa różnych blockchainowych systemów nazw oraz moduły relayowe, których zadaniem jest pośredniczenie w ruchu zamiast bezpośredniego prowadzenia ataków.

To podejście wpisuje się w szerszy trend obserwowany w świecie cyberzagrożeń: infrastruktura przestępcza staje się bardziej rozproszona, dynamiczna i trudniejsza do neutralizacji. W przypadku botnetów IoT szczególne znaczenie ma to, że operatorzy mogą oprzeć część architektury na urządzeniach ofiar.

Analiza techniczna

Najważniejszą cechą Dysphoria jest rozdzielenie warstw infrastruktury sterującej. Bot odczytuje informacje z rekordów publikowanych w blockchainowych systemach nazw, a następnie pobiera dane o aktywnych punktach komunikacyjnych. Dzięki temu nie musi przechowywać na stałe jednego adresu C2, który łatwo byłoby zablokować lub przejąć.

Kolejny etap ewolucji polega na wykorzystywaniu przejętych urządzeń jako relayów. W takim modelu zainfekowany host komunikuje się z urządzeniem pośredniczącym, które przekazuje ruch dalej do właściwej infrastruktury operatorskiej. Taka warstwa pośrednia ogranicza ekspozycję prawdziwych serwerów i utrudnia obrońcom korelację telemetrii sieciowej.

Badacze zwracają też uwagę na wariant relay-only. W tej odsłonie malware koncentruje się na przekazywaniu ruchu i utrzymaniu kanałów komunikacyjnych, a nie na bezpośrednim uruchamianiu modułów DDoS. W praktyce oznacza to, że część infekcji może pełnić funkcję czysto infrastrukturalną, stając się elementem rozproszonej siatki pośredniczącej.

W analizach pojawia się również wykorzystanie UPnP do mapowania portów, co może ułatwiać zestawianie łączności przez NAT. Po stronie systemów Linux malware korzysta z mechanizmów umożliwiających wydajną obsługę wielu połączeń równocześnie. W efekcie operatorzy są w stanie budować elastyczną i trudniejszą do zakłócenia warstwę komunikacyjną na bazie urządzeń należących do ofiar.

Jeśli chodzi o propagację, Dysphoria nadal bazuje na dobrze znanych słabościach ekosystemu IoT. Należą do nich przede wszystkim domyślne lub słabe hasła dla usług Telnet i SSH, a także wykorzystanie znanych luk umożliwiających zdalne wykonanie kodu w routerach, bramach i innych urządzeniach brzegowych. W publicznych analizach wskazywano również podatność CVE-2025-9528 dotyczącą command injection w routerze Linksys E1700.

Konsekwencje / ryzyko

Dla organizacji zagrożenie ma kilka wymiarów. Po pierwsze, urządzenia IoT mogą zostać błyskawicznie włączone do botnetu i użyte do ataków DDoS. Po drugie, przejęty sprzęt może pełnić rolę relaya, co oznacza, że infrastruktura ofiary staje się elementem ukrywania i przekazywania złośliwego ruchu. Po trzecie, rozproszony model C2 wydłuża czas wykrycia i zwiększa złożoność reakcji na incydent.

Szczególnie narażone są środowiska z dużą liczbą urządzeń brzegowych, starszych routerów, kamer IP, rejestratorów oraz przemysłowych gatewayów. W wielu przypadkach taki sprzęt działa przez lata bez aktualizacji firmware’u, przy jednoczesnym zachowaniu zdalnego dostępu administracyjnego. To tworzy warunki idealne dla trwałej obecności botnetu.

Istnieje także ryzyko operacyjne i reputacyjne. Jeśli urządzenie w sieci firmy zacznie działać jako relay, może to prowadzić do zgłoszeń abuse, problemów z partnerami sieciowymi, przeciążeń łączy oraz dodatkowych kosztów związanych z analizą ruchu i dochodzeniem powłamaniowym.

Rekomendacje

Podstawą obrony pozostaje ograniczenie powierzchni ataku urządzeń IoT. Organizacje powinny niezwłocznie zmienić domyślne hasła, wyłączyć niepotrzebne konta administracyjne oraz stosować silne, unikalne poświadczenia dla usług zarządzających. Tam, gdzie to możliwe, Telnet powinien zostać całkowicie wyłączony.

Kluczowe jest także zarządzanie podatnościami. Niezbędny jest pełny inwentarz urządzeń IoT, regularne aktualizowanie firmware’u oraz szybka identyfikacja sprzętu, który nie otrzymuje już poprawek bezpieczeństwa. Tego typu urządzenia należy odizolować albo wymienić, szczególnie jeśli są wystawione do internetu.

Równie ważne jest ograniczenie ekspozycji usług zdalnych. Zdalna administracja powinna być dostępna wyłącznie przez VPN lub wydzieloną sieć zarządczą. Funkcje takie jak UPnP warto wyłączyć wszędzie tam, gdzie nie są niezbędne, ponieważ mogą ułatwiać malware budowanie ścieżek komunikacji.

Od strony detekcji należy monitorować nietypowe połączenia wychodzące z urządzeń IoT, anomalie w mapowaniu portów oraz wzorce ruchu HTTP i TCP, które nie odpowiadają normalnemu profilowi pracy sprzętu. Szczególną uwagę warto zwrócić na urządzenia, które zaczynają inicjować liczne sesje sieciowe lub komunikują się z dynamicznie zmieniającymi się hostami.

Skuteczną barierą pozostaje również segmentacja sieci. Urządzenia IoT powinny być odseparowane od krytycznych systemów biznesowych i objęte restrykcyjnymi regułami ruchu wychodzącego. Ograniczenie komunikacji do minimum znacząco utrudnia wykorzystanie ich jako relayów lub uczestników operacji DDoS.

Podsumowanie

Dysphoria pokazuje, że botnety IoT przechodzą w kierunku bardziej odpornych i rozproszonych modeli operacyjnych. Wykorzystanie blockchainowych systemów nazw oraz relayów opartych na zainfekowanych urządzeniach podnosi odporność infrastruktury C2 i utrudnia jej przejęcie.

Dla zespołów bezpieczeństwa wniosek jest jasny: tradycyjne problemy IoT, takie jak słabe hasła, brak aktualizacji i zbyt szeroka ekspozycja usług administracyjnych, nadal pozostają głównym punktem wejścia. Jednocześnie nowe techniki ukrywania komunikacji sprawiają, że nawet relatywnie prosty botnet może stać się znacznie trudniejszy do wykrycia i usunięcia.

Źródła

The Hacker News — https://thehackernews.com/2026/07/dysphoria-iot-botnet-adds-blockchain-c2.html
XLab — Dysphoria Botnet Analysis — https://blog.xlab.qianxin.com/dysphoria-botnet-analysis/
NVD — CVE-2025-9528 — https://nvd.nist.gov/vuln/detail/CVE-2025-9528
Nokia Deepfield / Comcast — JackSkid Infrastructure Observations — https://github.com/
NICTER Blog — Analysis of JackSkid ENS/SNS Shift — https://blog.nicter.jp/

Dysphoria: botnet IoT z blockchainowym C2 utrudnia wykrywanie i neutralizację

Wprowadzenie do problemu / definicja

W skrócie

Dysphoria wyewoluowała po zakłóceniu wcześniejszej infrastruktury powiązanej z rodziną JackSkid.
Botnet wykorzystuje blockchainowe systemy nazw jako element mechanizmu C2.
Zainfekowane urządzenia mogą pełnić rolę relayów ukrywających właściwą infrastrukturę operatora.
Główne wektory infekcji to słabe hasła Telnet i SSH oraz wybrane podatności w urządzeniach IoT.
Celem pozostają operacje DDoS oraz utrzymanie odpornej, rozproszonej infrastruktury sterującej.

Kontekst / historia

Analiza techniczna

Konsekwencje / ryzyko

Rekomendacje

Podsumowanie

Źródła

The Hacker News — https://thehackernews.com/2026/07/dysphoria-iot-botnet-adds-blockchain-c2.html
XLab — Dysphoria Botnet Analysis — https://blog.xlab.qianxin.com/dysphoria-botnet-analysis/
NVD — CVE-2025-9528 — https://nvd.nist.gov/vuln/detail/CVE-2025-9528
Nokia Deepfield / Comcast — JackSkid Infrastructure Observations — https://github.com/
NICTER Blog — Analysis of JackSkid ENS/SNS Shift — https://blog.nicter.jp/

Dysphoria: botnet IoT z blockchainowym C2 utrudnia wykrywanie i neutralizację

Wprowadzenie do problemu / definicja

W skrócie

Dysphoria wyewoluowała po zakłóceniu wcześniejszej infrastruktury powiązanej z rodziną JackSkid.
Botnet wykorzystuje blockchainowe systemy nazw jako element mechanizmu C2.
Zainfekowane urządzenia mogą pełnić rolę relayów ukrywających właściwą infrastrukturę operatora.
Główne wektory infekcji to słabe hasła Telnet i SSH oraz wybrane podatności w urządzeniach IoT.
Celem pozostają operacje DDoS oraz utrzymanie odpornej, rozproszonej infrastruktury sterującej.

Kontekst / historia

Analiza techniczna

Konsekwencje / ryzyko

Rekomendacje

Podsumowanie

Źródła

The Hacker News — https://thehackernews.com/2026/07/dysphoria-iot-botnet-adds-blockchain-c2.html
XLab — Dysphoria Botnet Analysis — https://blog.xlab.qianxin.com/dysphoria-botnet-analysis/
NVD — CVE-2025-9528 — https://nvd.nist.gov/vuln/detail/CVE-2025-9528
Nokia Deepfield / Comcast — JackSkid Infrastructure Observations — https://github.com/
NICTER Blog — Analysis of JackSkid ENS/SNS Shift — https://blog.nicter.jp/

NadMesh: nowy botnet atakuje usługi AI, klucze chmurowe i tokeny Kubernetes

Wprowadzenie do problemu / definicja

NadMesh to nowo opisany botnet napisany w języku Go, którego operatorzy koncentrują się na przejmowaniu publicznie dostępnych usług AI, interfejsów administracyjnych oraz słabo zabezpieczonych elementów środowisk chmurowych i kontenerowych. W przeciwieństwie do klasycznych kampanii nastawionych głównie na DDoS lub cryptomining, NadMesh stawia na kradzież danych uwierzytelniających i sekretów infrastrukturalnych.

Najważniejszym celem atakujących są klucze dostępu do chmury, tokeny kont serwisowych Kubernetes, pliki konfiguracyjne oraz zmienne środowiskowe, które mogą otworzyć drogę do dalszej eskalacji uprawnień i poruszania się po infrastrukturze ofiary.

W skrócie

NadMesh aktywnie skanuje internet w poszukiwaniu eksponowanych usług AI i narzędzi DevOps.
Malware poluje na platformy takie jak ComfyUI, Ollama, n8n, Open WebUI, Langflow i Gradio.
Po uzyskaniu dostępu wykrada pliki .env, konfiguracje AWS i Dockera oraz tokeny Kubernetes.
Celem kampanii nie jest tylko przejęcie hosta, ale także uzyskanie dostępu do chmury, klastrów i procesów CI/CD.
Zagrożenie może prowadzić do trwałej kompromitacji środowiska i nadużyć finansowych.

Kontekst / historia

Botnet został opisany w lipcu 2026 roku, a jego nazwa pochodzi od identyfikatora widocznego w kodzie kontrolera. Dostępne analizy wskazują, że aktywność kampanii nasiliła się na początku lipca, kiedy zaobserwowano wzrost skanowania infrastruktury dostępnej z internetu oraz prób infekcji.

Kampania wpisuje się w rosnący trend ataków na szybko wdrażane narzędzia AI, środowiska eksperymentalne i komponenty DevOps, które trafiają do sieci bez odpowiedniego uwierzytelniania, segmentacji i kontroli dostępu. Problem dotyczy szczególnie usług uruchamianych tymczasowo, które z czasem zaczynają działać jak elementy produkcyjne.

Analiza techniczna

Mechanizm działania NadMesh opiera się na ciągłym skanowaniu internetu i zasilaniu kolejki celów informacjami o widocznych usługach. Botnet priorytetyzuje środowiska związane z AI, ale wykorzystuje również bardziej tradycyjne powierzchnie ataku, takie jak otwarty Docker API, Jenkins Script Console, niezabezpieczony Redis, słabe hasła do Telnetu i SSH oraz wybrane podatności umożliwiające zdalne wykonanie kodu.

Na szczególną uwagę zasługują wdrożenia oparte na MCP. W analizowanych przypadkach wskazano wykorzystanie wywołań typu tools/call do uruchamiania poleceń, co w nieprawidłowo zabezpieczonych środowiskach może prowadzić do wykonania kodu po stronie ofiary. To istotne ryzyko, ponieważ część serwerów MCP pozostaje publicznie dostępna i oferuje narzędzia zdolne do wykonywania komend systemowych.

Po skutecznym uzyskaniu dostępu malware koncentruje się na ekstrakcji materiału poświadczającego. Celem są między innymi:

klucze i profile AWS,
tokeny kont serwisowych Kubernetes,
sekrety zapisane w plikach .env,
dane logowania do rejestrów kontenerów,
konfiguracje Dockera,
dostęp do modeli i narzędzi wykonawczych powiązanych z usługami AI.

NadMesh wykazuje również cechy bardziej dojrzałego zaplecza operacyjnego. Obserwacje wskazują na adaptacyjne ponowne skanowanie podsieci, częstsze odpytywanie najbardziej obiecujących hostów, próby omijania potencjalnych honeypotów oraz równoległe utrzymywanie kilku wersji agenta. Dodatkowo próbki są zaciemniane i pakowane, co utrudnia ich wykrywanie wyłącznie na podstawie hashy.

W aktywności operatorów pojawiają się także próby wykorzystania podatności, w tym CVE-2026-39987 w Marimo, a także innych wektorów związanych z publicznie dostępnymi komponentami administracyjnymi. To pokazuje, że NadMesh nie jest prostym skanerem usług AI, lecz hybrydową platformą do kompromitacji hostów, wykradania sekretów i dalszej eksploatacji środowiska.

Konsekwencje / ryzyko

Największe zagrożenie związane z NadMesh wynika z faktu, że wartością dla atakującego nie jest sam serwer, lecz zasoby, do których ten serwer ma dostęp. Kradzież poświadczeń chmurowych i tokenów Kubernetes może umożliwić przejęcie znacznie szerszego fragmentu infrastruktury niż pojedynczy host.

przejęcie kont i zasobów w chmurze,
uruchamianie nowych workloadów przez atakującego,
dostęp do magazynów danych i sekretów,
pivoting do innych klastrów i środowisk,
kompromitację pipeline’ów CI/CD,
nadużycia finansowe związane z wykorzystaniem zasobów obliczeniowych ofiary.

W praktyce nawet pozornie niewielka ekspozycja usługi AI może stać się punktem wejścia do poważnego incydentu obejmującego konta chmurowe, środowiska kontenerowe i łańcuch dostaw oprogramowania. Co istotne, początkowa infekcja może być mniej zauważalna niż późniejsze użycie skradzionych poświadczeń.

Rekomendacje

Organizacje korzystające z narzędzi AI, platform orkiestracyjnych i rozwiązań DevOps powinny pilnie zweryfikować swoją ekspozycję na internet oraz sposób przechowywania sekretów. W przypadku NadMesh kluczowe znaczenie ma ograniczenie dostępności usług oraz szybka rotacja poświadczeń znajdujących się na narażonych hostach.

usunąć z publicznego internetu niezabezpieczone usługi ComfyUI, Ollama, Gradio, n8n, Open WebUI i podobne komponenty,
zablokować publiczny dostęp do Docker API, Jenkins Script Console, Redis oraz innych interfejsów administracyjnych bez silnego uwierzytelniania,
wymusić segmentację sieci oraz dostęp wyłącznie przez VPN, bastion host lub listy kontroli dostępu,
przeprowadzić inwentaryzację sekretów zapisanych w plikach .env, konfiguracjach AWS i Docker oraz tokenach serwisowych Kubernetes,
rotować i unieważniać wszystkie poświadczenia, które mogły znajdować się na potencjalnie naruszonych hostach,
sprawdzić mechanizmy persistence, zadania cron, katalogi tymczasowe i pliki authorized_keys,
wdrożyć monitoring aktywności w API chmurowych oraz działań kont serwisowych w Kubernetes,
rozszerzyć patch management o narzędzia AI, notebooki i usługi pomocnicze używane przez zespoły inżynierskie,
stosować zasadę najmniejszych uprawnień dla workloadów AI i usług wspierających,
ograniczyć możliwość wykonywania komend przez narzędzia MCP i wymusić pełne uwierzytelnianie oraz autoryzację.

Jeśli kompromitacja została potwierdzona, należy odizolować host, usunąć mechanizmy trwałości, unieważnić wszystkie poświadczenia dostępne z poziomu tego systemu, a następnie przeanalizować logi IAM, logi chmurowe i zdarzenia kontenerowe pod kątem dalszego wykorzystania skradzionych danych dostępowych.

Podsumowanie

NadMesh pokazuje wyraźną zmianę priorytetów po stronie operatorów botnetów. Coraz częściej nie chodzi już o samą moc obliczeniową przejętych urządzeń, lecz o dostęp do sekretów, tożsamości maszynowych i uprawnień chmurowych, które pozwalają przejmować kolejne warstwy infrastruktury.

Dla zespołów bezpieczeństwa to sygnał, że publicznie dostępne usługi AI, interfejsy administracyjne oraz komponenty orkiestracyjne należy traktować jak krytyczną powierzchnię ataku. Brak kontroli nad tym obszarem może prowadzić do incydentów o znacznie większej skali niż początkowa infekcja pojedynczego hosta.

Źródła

HollowByte: nowy wektor DoS w OpenSSL umożliwia wyczerpanie pamięci serwera pakietem 11 bajtów

Wprowadzenie do problemu / definicja

HollowByte to nowo ujawniona technika ataku typu denial of service wymierzona w serwery korzystające z OpenSSL do obsługi połączeń TLS. Istota problemu polega na tym, że podatne implementacje alokują pamięć na podstawie długości zadeklarowanej w nagłówku komunikatu handshake, zanim otrzymają pełną zawartość wiadomości. Dzięki temu napastnik może wymuszać kosztowne operacje po stronie serwera przy użyciu minimalnego ruchu sieciowego.

W skrócie

Atak HollowByte pozwala nieuwierzytelnionemu podmiotowi stopniowo zwiększać zużycie pamięci procesu poprzez wielokrotne inicjowanie połączeń TLS i wysyłanie krótkiego, 11-bajtowego pakietu z zawyżoną deklaracją długości danych. W efekcie serwer rezerwuje pamięć, oczekując na dalszy payload, który nigdy nie nadchodzi. Problem może prowadzić do degradacji wydajności, fragmentacji sterty i trwałego wzrostu RSS procesu nawet po zakończeniu ataku.

atak nie wymaga wysokiej przepustowości,
może być prowadzony równolegle na wielu sesjach TLS,
wpływa głównie na dostępność i stabilność usług,
poprawki trafiły do nowszych wersji OpenSSL w kilku wspieranych gałęziach.

Kontekst / historia

OpenSSL pozostaje jednym z kluczowych komponentów współczesnej infrastruktury internetowej. Biblioteka jest powszechnie wykorzystywana przez serwery WWW, reverse proxy, API, bazy danych, aplikacje kontenerowe i liczne usługi uruchamiane w systemach Linux oraz Unix. Z tego powodu każda podatność wpływająca na przebieg negocjacji TLS może mieć szeroki zasięg operacyjny.

HollowByte został opisany jako słabość związana nie z wykonaniem kodu czy wyciekiem danych, lecz z nieefektywną obsługą pamięci podczas przetwarzania niekompletnych komunikatów handshake. Tego rodzaju podatności często bywają niedoszacowane, ponieważ nie prowadzą bezpośrednio do przejęcia systemu, ale mogą skutecznie obniżać dostępność usług publicznych i wewnętrznych.

Analiza techniczna

Źródło problemu znajduje się w sposobie obsługi komunikatów TLS Handshake. Każda wiadomość handshake zawiera 4-bajtowy nagłówek, w którym 3 bajty określają długość dalszej części komunikatu. W podatnych wersjach OpenSSL serwer ufa tej wartości zbyt wcześnie i dokonuje alokacji bufora zgodnie z deklarowanym rozmiarem jeszcze przed odebraniem całej wiadomości.

Napastnik może więc zestawić połączenie TLS, wysłać krótki komunikat z dużą zadeklarowaną długością danych i przerwać transmisję dalszego payloadu. Serwer utrzymuje przydzieloną pamięć i oczekuje na brakujące dane, co przy wielu równoległych połączeniach prowadzi do sztucznego wzrostu zużycia zasobów. Taki model ataku jest asymetryczny: koszt po stronie atakującego pozostaje bardzo niski, natomiast koszt po stronie serwera rośnie nieproporcjonalnie.

Znaczenie ma również zachowanie alokatora pamięci. Nawet jeśli część buforów zostanie zwolniona po zamknięciu sesji, pamięć nie zawsze wraca od razu do systemu operacyjnego. W praktyce może to powodować utrzymywanie przydzielonych obszarów w procesie, pogłębianie fragmentacji sterty i trwały wzrost RSS. Przy atakach prowadzonych falami, z różnymi deklarowanymi rozmiarami, odzyskiwanie pamięci staje się jeszcze trudniejsze, a pełna normalizacja bywa możliwa dopiero po restarcie usługi.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem HollowByte jest zagrożenie dla dostępności usług. W środowiskach o ograniczonych zasobach pamięci atak może stosunkowo szybko doprowadzić do wzrostu opóźnień, niestabilności działania, aktywacji mechanizmów OOM i czasowej niedostępności aplikacji. W większych środowiskach skutki mogą narastać wolniej, ale nadal przekładać się na spadek wydajności i stabilności.

Ryzyko dotyczy szczególnie infrastruktury, w której OpenSSL odpowiada za terminację TLS przed warstwą biznesową. Obejmuje to między innymi serwery NGINX i Apache, bramy API, reverse proxy, aplikacje uruchamiane w kontenerach oraz komponenty chmurowe bazujące na standardowych pakietach systemowych. Dodatkowym wyzwaniem jest możliwość prowadzenia ataku poniżej typowych progów alarmowych związanych z wolumenem ruchu, co może utrudniać szybką detekcję przez SOC i zespoły operacyjne.

Rekomendacje

Priorytetem powinno być zidentyfikowanie systemów korzystających z podatnych wersji OpenSSL, zarówno bezpośrednio, jak i pośrednio przez pakiety dystrybucyjne, obrazy kontenerowe oraz zależności aplikacyjne. Następnie należy zaplanować aktualizację do wersji zawierających poprawkę, odpowiednio dla używanej gałęzi.

przeprowadzić inwentaryzację bibliotek OpenSSL w środowisku,
zaktualizować pakiety do wersji zawierających poprawkę,
ograniczyć liczbę równoległych połączeń TLS z pojedynczych źródeł,
skrócić timeouty dla niekompletnych handshake’y,
monitorować RSS oraz anomalie pamięci w procesach obsługujących TLS,
korelować zdarzenia związane z dużą liczbą niedokończonych sesji,
wykorzystać reverse proxy, WAF lub usługi anty-DDoS zdolne do wykrywania nietypowych wzorców handshake.

Warto również zweryfikować, czy po wdrożeniu aktualizacji konieczny jest restart usług w celu odzyskania pamięci i przywrócenia stabilnego profilu pracy. Organizacje korzystające z pakietów systemowych powinny potwierdzić, że poprawka została dostarczona przez ich dostawcę w używanym kanale aktualizacji. Dobrą praktyką jest także wykonywanie testów odpornościowych obejmujących niekompletne komunikaty handshake i niskowolumenowe scenariusze DoS.

Podsumowanie

HollowByte pokazuje, że nawet pozornie niewielka słabość w obsłudze handshaku TLS może przełożyć się na realne ryzyko operacyjne dla szerokiej infrastruktury. Mechanizm ataku wykorzystuje zaufanie do długości zadeklarowanej w nagłówku, aby wymuszać kosztowne alokacje pamięci przy użyciu minimalnego pakietu wejściowego. W efekcie organizacje mogą mierzyć się z trwałym wzrostem zużycia pamięci, fragmentacją sterty i pogorszeniem dostępności usług.

Najskuteczniejszą odpowiedzią pozostaje szybka aktualizacja OpenSSL, weryfikacja zależności w łańcuchu dostaw oprogramowania oraz wzmocnienie monitoringu pod kątem anomalii w warstwie TLS i pamięci procesów. Choć podatność nie prowadzi bezpośrednio do kradzieży danych ani zdalnego wykonania kodu, jej znaczenie biznesowe i operacyjne jest wysokie.

Źródła

BleepingComputer — https://www.bleepingcomputer.com/news/security/hollowbyte-ddos-flaw-bloats-openssl-server-memory-with-11-byte-payload/
OpenSSL Library — Release and Advisory Timeline — https://mirror.openssl-library.org/news/timeline/
OpenSSL Library — Downloads — https://www.openssl-library.org/source/