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, iż 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żeli architektura nie jest anycast + autoscale. Ataki impulsowe utrudniają manualne 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żeli 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 / najważniejsze wnioski
- Automatyzacja wygrywa z sekundami. Ataki impulsowe o sile Tb/s wymagają w pełni automatycznych ścieżek detekcji i mitigacji — manualne 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)
