AISURU/Kimwolf: botnet, który dobił do 31,4 Tbps — jak działa i dlaczego te „krótkie” ataki są tak groźne - Security Bez Tabu

AISURU/Kimwolf: botnet, który dobił do 31,4 Tbps — jak działa i dlaczego te „krótkie” ataki są tak groźne

Wprowadzenie do problemu / definicja luki

W przypadku AISURU/Kimwolf „luką” nie jest pojedynczy CVE, tylko systemowy problem bezpieczeństwa ekosystemu IoT i tanich urządzeń Android (TV boxy/Smart TV): domyślne hasła, rzadkie aktualizacje, ekspozycja usług (np. ADB), brak monitoringu i długi czas życia urządzeń w sieci. Taki miks pozwala budować botnety o skali liczonej w milionach hostów i odpalać hiperwolumetryczne DDoS-y, które w kilkadziesiąt sekund potrafią osiągać rekordowe przepływności.

Na początku lutego 2026 r. opisano atak przypisany AISURU/Kimwolf, który osiągnął 31,4 Tbps i trwał ok. 35 sekund — a mimo to został automatycznie wykryty i zmitigowany przez Cloudflare.


W skrócie

  • Rekordowy DDoS: 31,4 Tbps, czas trwania ~35 s.
  • Kontekst Q4 2025: kampania „The Night Before Christmas” (start 19 grudnia 2025) z falami HTTP DDoS przekraczającymi 200 mln żądań/s (rps).
  • Skala zjawiska: w 2025 r. Cloudflare raportuje 47,1 mln incydentów DDoS (wzrost 121% r/r) i średnio 5 376 mitigacji na godzinę.
  • „Paliwo” botnetu: masowo kompromitowane urządzenia (m.in. Android TV/TV boxy), plus elementy „proxy/residential”.

Kontekst / historia / powiązania

AISURU/Kimwolf to w praktyce ekosystem:

  • Aisuru jako „rodzic”/framework DDoS (silnie IoT-owy),
  • Kimwolf jako wyspecjalizowany wariant/„ramię Android”, napędzające wzrost poprzez urządzenia Android (streamery/TV boxy).

Wątek Kimwolf został szerzej opisany pod koniec 2025 r. przez XLab: botnet miał cechy wykraczające poza zwykły „DDoS blaster” (proxy, zdalna powłoka, zarządzanie plikami), a analiza wskazywała na silne powiązania z Aisuru.


Analiza techniczna / szczegóły „luki”

1) Dlaczego 35 sekund robi różnicę

Nowoczesne botnety DDoS coraz częściej działają „hit-and-run”: błyskawiczny rozbieg do maksimum i równie szybkie wygaszenie. Cloudflare opisuje ten wzorzec wprost przy Aisuru-Kimwolf (sekundy–minuty) i zwraca uwagę na techniki utrudniające detekcję.

To utrudnia obronę organizacjom, które:

  • polegają na ręcznej eskalacji,
  • mają progi alarmowe ustawione na „dłuższe” zdarzenia,
  • korzystają z ochrony o zbyt małej pojemności lub zbyt wolnej automatyce.

2) Warstwy i wektory: L4 + HTTP

W raportach z Q4 2025 widać miks:

  • warstwa sieciowa (L3/L4) (np. UDP flood / „carpet bombing”),
  • warstwa aplikacyjna (HTTP floods) z rekordami rzędu 200M rps.

3) „Carpet bombing” i rozproszenie celu

Cloudflare opisuje dla Aisuru-Kimwolf UDP carpet bombing: zamiast jednego IP — wiele adresów jednocześnie, co może rozmywać sygnały detekcyjne per-host, a finalnie i tak wysycić łącza / urządzenia brzegowe.

4) Infekcje Android i mechanika C2 (Kimwolf)

XLab wskazuje m.in.:

  • kompilację w NDK,
  • DNS-over-TLS (DoT) do „opakowania” zapytań DNS (utrudnianie inspekcji),
  • mechanizmy weryfikacji poleceń (podpisy),
  • komponenty proxy/„bandwidth monetization”.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko dla telco i operatorów: w danych Q4 2025 telekomy i dostawcy usług sieciowych pojawiają się jako jedne z głównych celów — co ma sens, bo uderzenie w sieć „kręgosłupową” daje efekt domina.
  2. DDoS jako zasłona dymna: krótkie, ekstremalne piki mogą maskować inne działania (fraud, przejęcia kont, skanowanie, próby awarii usług).
  3. Koszty i SLA: nawet jeśli aplikacja przetrwa, przeciążenie łączy, firewalli, load balancerów i upstreamu potrafi wyzerować dostępność.
  4. Wartość „residential proxy”: kompromitowane urządzenia domowe dostarczają „wiarygodnych” adresów IP, co utrudnia filtrowanie po geolokacji i reputacji.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów obrony (SOC/NOC)

  • Wymuś automatyzację: playbooki i polityki muszą reagować na piki w skali sekund (auto-mitigacja, auto-rate-limit, automatyczne przełączanie profili).
  • Filtruj wielowarstwowo: osobno progi i reguły dla L3/L4 (pps/bps) oraz HTTP (rps, per-path, per-ASN, per-ua).
  • Przygotuj scenariusz „carpet bombing”: ochrona nie tylko pojedynczego VIP-a, ale całych prefiksów / usług (w tym upstream).
  • Ćwiczenia DDoS: testy obciążeniowe, symulacje, weryfikacja limitów u ISP/CDN/WAF.

Dla właścicieli infrastruktury i IoT/Android fleet

  • Inwentaryzacja i higiena urządzeń: usuń/izoluj niezarządzalne Android TV boxy i „no-name” streamery; wymuś aktualizacje lub wymianę.
  • Zamknij ekspozycje usług: szczególnie ADB/porty zarządzania; segmentacja VLAN, brak routingu do Internetu jeśli niepotrzebny.
  • Polityka haseł i telemetryka: wyeliminuj domyślne poświadczenia, włącz monitoring ruchu wychodzącego (nietypowe piki UDP/HTTP, anomalie DNS/DoT).

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

  • Mirai vs Aisuru/Kimwolf: Mirai „zdefiniował epokę” IoT botnetów, ale Aisuru/Kimwolf pokazuje kolejny etap: większa skala, większy udział Android/TV, monetyzacja przez proxy i „usługi” obok samych DDoS. Cloudflare wprost porównuje Aisuru-Kimwolf do linii botnetów IoT wywodzących się z Mirai.
  • DDoS „długi” vs „burst”: klasyczne podejście opierało się na minutach–godzinach, dziś rekordy bije się w dziesiątkach sekund, co wymaga innej architektury detekcji i eskalacji.

Podsumowanie / kluczowe wnioski

AISURU/Kimwolf to nie „pojedynczy botnet”, tylko skalowalny model cyberprzestępczy, oparty o masowo podatne urządzenia IoT/Android. Rekord 31,4 Tbps (przy czasie trwania ~35 s) jest ważny nie dlatego, że „ktoś pobił rekord”, ale dlatego, że pokazuje nową normę: atak ma być krótki, ekstremalny i zautomatyzowany — a obrona musi działać równie szybko i być gotowa na wielowektorowe scenariusze.


Źródła / bibliografia

  1. The Hacker News — opis rekordu 31,4 Tbps i kontekstu Q4 2025. (The Hacker News)
  2. Cloudflare Blog — 2025 Q4 DDoS threat report (szczegóły kampanii i statystyk rocznych). (The Cloudflare Blog)
  3. Cloudflare Learning Center — tło techniczne Aisuru-Kimwolf i techniki ataków. (Cloudflare)
  4. BleepingComputer — ujęcie kampanii, statystyk i wektorów (200M rps, telekomy). (BleepingComputer)
  5. XLab (Qianxin) / SecurityWeek — szczegóły Kimwolf (DoT, C2, funkcje proxy/reverse shell, skala). (奇安信 X 实验室)