Archiwa: DDoS - Strona 15 z 21 - Security Bez Tabu

Tag: DDoS

FBI rozbija domniemany serwis do prania pieniędzy dla grup ransomware (E-Note)

Wprowadzenie do problemu / definicja luki

Departament Sprawiedliwości USA poinformował o zakłóceniu działalności i przejęciu infrastruktury E-Note — internetowej usługi wymiany/kantoru kryptowalut, która miała umożliwiać pranie środków dla transnarodowych grup cyberprzestępczych, w tym operatorów ransomware. W sprawie oskarżono 39-letniego obywatela Rosji, Mykhailo (Mykhalio) Petrovicha Chudnovetsa, a amerykańskie i europejskie służby przejęły m.in. domeny i aplikacje mobilne powiązane z serwisem.

W skrócie

  • Skala: FBI zidentyfikowało ponad 70 mln USD przepływów związanych z atakami ransomware i przejęciami kont, obsłużonych przez E-Note od 2017 r.
  • Infrastruktura: zajęto serwery, aplikacje oraz domeny e-note.com, e-note.ws i jabb.mn.
  • Zarzuty: Chudnovets — konspiracja w celu prania pieniędzy (do 20 lat więzienia).
  • Partnerzy: działania koordynowane z BKA (Niemcy), NBI (Finlandia) i policją stanu Michigan.

Kontekst / historia / powiązania

Uderzenie w E-Note wpisuje się w szerszą kampanię przeciwko no-KYC/no-AML kryptousługom, które od lat służą do „cashoutu” zysków z cyberprzestępczości. Przypomnijmy: w 2024 r. BKA zamknęła 47 rosyjskojęzycznych serwisów wymiany bez KYC, a analizy pokazały ich centralną rolę w ekosystemie prania środków. Również FBI ostrzegało wcześniej przed korzystaniem z nierejestrowanych w USA „money services businesses” (MSB).

Analiza techniczna / szczegóły luki

  • Model działania: E-Note miało łączyć procesor płatności z siecią „money mules” (słupów) oraz konwersją krypto-fiat, oferując szybkie transfery transgraniczne i wypłaty gotówkowe — krytyczny krok do „wybielenia” okupów.
  • Artefakty infrastrukturalne: przejęto serwery, bazy klientów i rejestry transakcyjne, co może umożliwić wsteczne śledzenie przepływów i identyfikację klientów/pośredników.
  • Powiązania z ransomware: wg FBI przez usługę przepływały środki z ataków na ochronę zdrowia i infrastrukturę krytyczną (wskazuje to na użycie przez aktorów „big-game hunting”).
  • Brak KYC/AML: operacyjny charakter usługi wskazuje na obchodzenie reżimów KYC/AML, co czyniło ją atrakcyjną dla operatorów APT-crime i brokerów dostępu. FBI od 2024 r. podkreśla, że usługi MSB bez rejestracji/AML są sygnałem alarmowym.

Praktyczne konsekwencje / ryzyko

  • Ryzyko wtórne (exposure): firmy, które nieświadomie opłaciły odzysk lub współpracowały z zewnętrznymi „cashout” brokerami, mogą pojawić się w przejętych rejestrach klienta/operacji. To może skutkować pytaniami organów nadzoru i wymogiem audytu AML.
  • Retorsje cyberprzestępców: krótkoterminowo możliwa jest relokacja do innych no-KYC oraz wzrost opłat „cashout”. W przeszłości podobne takedowny prowadziły do migracji na mniejsze, bardziej rozproszone platformy.
  • Okazja śledcza: pełne bazy transakcyjne to szansa na atrybucję i recoup (odzysk środków) przy współpracy organów i podmiotów prywatnych analityki on-chain.

Rekomendacje operacyjne / co zrobić teraz

  1. Blokady i detekcje
    • Dodaj do blokad DNS/URL i EDR: e-note.com, e-note.ws, jabb.mn; przejrzyj proxy/DNS pod kątem historycznych wywołań.
    • Uzupełnij reguły UEBA/SIEM o wykrywanie wzorców „cashout”: nietypowe przelewy na giełdy P2P/no-KYC, nagłe mikropłatności, rozbijanie kwot (structuring).
  2. AML/KYC i zgodność
    • Zweryfikuj dostawców „OTC/wykup okupu” pod kątem rejestracji MSB i programu AML — to wymóg regulacyjny w USA i dobry standard globalnie.
    • Odśwież procedury zgodności z no-KYC exchange exposure; wykorzystaj listy ryzyka (np. zewnętrzne feedy analityki łańcuchów).
  3. IR/Threat Intel
    • Jeśli Twoja organizacja miała incydent z płatnością w krypto, przeprowadź retrospekcję transakcyjną (on-chain tracing) i kontakt z organami — FBI udostępniło dedykowany kanał dla potencjalnych ofiar E-Note.
    • Zmapuj zależności z kampaniami ransomware celującymi w ochronę zdrowia i ICS; zaktualizuj playbooki DDoS-i-negocjacje na scenariusz „brak kanału cashout”.
  4. Polityka płatności okupu
    • Weryfikuj ryzyko sankcyjne/AML przed jakimikolwiek transferami — nierejestrowane MSB to czerwone światło i potencjalne naruszenie prawa.

Różnice / porównania z innymi przypadkami

  • W porównaniu z szerokimi operacjami (np. niemieckie zamknięcie 47 serwisów no-KYC w 2024 r.), sprawa E-Note to precyzyjny takedown pojedynczego węzła cashout, ale z wartością śledczą (pełne bazy klientów i transakcji).
  • Wspólny mianownik: brak KYC, szybkie swapy i „mosty” krypto-fiat — dokładnie te cechy, które analitycy uznają za „kręgosłup” prania środków z cyberprzestępczości.

Podsumowanie / kluczowe wnioski

Takedown E-Note to kolejny cios w ekosystem wyprowadzania okupów. Najważniejsze dla obrony: blokady znanych artefaktów, przegląd ekspozycji AML/KYC, oraz współpraca z organami w zakresie ewentualnych przepływów przez E-Note. Na poziomie rynku można oczekiwać dyspersji na mniejsze, bardziej ukryte usługi — warto więc budować detekcje behawioralne, a nie tylko listy domen.

Źródła / bibliografia

  • U.S. DOJ (Eastern District of Michigan): „FBI disrupts virtual money laundering service used to facilitate criminal activity” — komunikat, 17 grudnia 2025. (Department of Justice)
  • The Record / Recorded Future News: „FBI takes down alleged money laundering service for ransomware groups”, 17 grudnia 2025. (The Record from Recorded Future)
  • FBI IC3 PSA: „Alert on Cryptocurrency Money Services Businesses (MSB)”, 25 kwietnia 2024 — ostrzeżenia dot. nierejestrowanych usług. (ic3.gov)
  • Chainalysis: „German authorities seize Russian-centric no-KYC exchanges”, 25 września 2024 — tło nt. roli no-KYC w cyberpraniu. (Chainalysis)
  • The Record: „Germany shuts down 47 cryptocurrency exchange services used by cybercriminals”, 20 września 2024 — kontekst operacji BKA. (The Record from Recorded Future)

SoundCloud potwierdza incydent bezpieczeństwa: wyciek e-maili, blokady VPN i ataki DDoS

Wprowadzenie do problemu / definicja luki

SoundCloud potwierdził naruszenie bezpieczeństwa, w wyniku którego nieuprawniony podmiot uzyskał dostęp do „pomocniczego panelu usługowego” i wyeksfiltrował adresy e-mail oraz publiczne dane z profili. Firma podkreśla, że nie doszło do naruszenia haseł ani danych finansowych. Incydent zbiegł się w czasie z czasową blokadą dostępu przez VPN (błędy 403) oraz atakami DDoS na warstwę web. SoundCloud ocenia, że zdarzenie dotknęło ok. 20% użytkowników i zostało opanowane.

W skrócie

  • Zakres: e-maile + publiczne informacje profilowe; bez haseł/finansów.
  • Skala: ok. 20% kont (na podstawie danych SoundCloud).
  • Dostępność: uboczne zmiany konfiguracyjne po reakcji na incydent spowodowały problemy z dostępem przez VPN; równolegle wystąpiły DDoS.
  • Atrybucja: media branżowe łączą sprawę z ShinyHunters (informacja niepotwierdzona oficjalnie).

Kontekst / historia / powiązania

O problemach z dostępem przez VPN do SoundCloud użytkownicy raportowali od kilku dni (kody 403 „Forbidden”). Doniesienia prasowe wskazują, że utrudnienia nie wynikały z celowej polityki blokowania VPN, lecz z efektów ubocznych zmian bezpieczeństwa po incydencie.
W międzyczasie serwis doświadczał również ataków DDoS, które przejściowo ograniczały dostępność warstwy web.
BleepingComputer podał, że za włamaniem może stać grupa ShinyHunters, znana z głośnych kampanii wymuszeń w 2025 r. (ale SoundCloud nie potwierdził tej atrybucji).

Analiza techniczna / szczegóły luki

  • Punkt wejścia: „ancillary service dashboard” — panel usług pomocniczych; po wykryciu anomalii uruchomiono procedury IR i odcięto dostęp.
  • Zakres danych: wyłącznie adresy e-mail oraz publicznie widoczne dane profilu (np. nazwa użytkownika, bio). Brak dowodów na ekspozycję haseł, tokenów płatności, danych finansowych.
  • Dotknięta populacja: ~20% bazy użytkowników. W materiałach prasowych szacuje się to na dziesiątki milionów kont, ale to przeliczenia oparte na publicznych metrykach — oficjalny komunikat podaje tylko odsetek.
  • Wpływ na infrastrukturę: po wdrożeniu zmian twardniających konfigurację pojawiły się problemy z VPN; dodatkowo serwis odnotował co najmniej dwa skuteczne epizody DDoS na warstwę web.

Praktyczne konsekwencje / ryzyko

  • Zwiększone ryzyko phishingu i spear-phishingu na adresy e-mail powiązane z kontami SoundCloud (np. fałszywe „ostrzeżenia o naruszeniu”, prośby o reset hasła czy płatności).
  • Korelacja tożsamości: publiczne pola profilu ułatwiają dopasowanie aliasów do e-maili, co wspiera ataki socjotechniczne na innych platformach.
  • Ryzyko dla firm: konta „pro/creators” często używają adresów biznesowych — możliwe kampanie BEC/brand impersonation celowane w branżę muzyczną i agencje.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników SoundCloud:

  1. Wzmożona czujność na phishing: ignoruj linki w mailach „z resetem hasła” — przechodź ręcznie do domeny soundcloud.com.
  2. Włącz 2FA na wszystkich powiązanych kontach (e-mail, SoundCloud, media społecznościowe).
  3. Rozdziel aliasy e-mail: jeśli używasz jednego adresu dla wielu serwisów, rozważ aliasy/ustawienia catch-all, by szybciej wykrywać nadużycia.
  4. Aktualizuj menedżer haseł i sprawdź, czy nie powielasz haseł między serwisami (mimo braku dowodów na wyciek haseł to dobra praktyka).

Dla zespołów SecOps/IT w organizacjach współpracujących z SoundCloud (wytwórnie, agencje, SaaS):

  1. Filtrowanie i DMARC/DKIM/SPF – podnieś politykę do p=quarantine/reject po testach, aby utrudnić spoofing domeny.
  2. Reguły detección (SIEM/SEG): słowa kluczowe i TTP dot. podszywania się pod SoundCloud; alerty na domeny typosquatting.
  3. Twardnienie dostępu z VPN/WAF: jeśli Twój ruch do SoundCloud przechodzi przez egress VPN, miej plan obejścia (np. split-tunnel/allow-list tymczasowych wyjątków), do czasu pełnego przywrócenia funkcjonalności po stronie dostawcy.
  4. Higiena tożsamości: przegląd uprawnień w panelach „usług pomocniczych” i SaaS (least privilege, SSO, MFA, klucze sprzętowe).

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

W 2025 r. głośne kampanie ShinyHunters skupiały się na kradzieży danych z ekosystemów chmurowych i wymuszeniach (m.in. ofiary korzystające z Salesforce). Jeśli trop ShinyHunters przy SoundCloud się potwierdzi, byłby to kolejny przypadek kradzieży danych kontaktowych z usług towarzyszących, a nie z „rdzeniowego” systemu logowania/płatności. Różnica: tutaj skala oficjalnie opisana jest procentowo (20%) i obejmuje mało wrażliwe kategorie danych, choć realne ryzyko phishingu pozostaje wysokie.

Podsumowanie / kluczowe wnioski

  • SoundCloud opanował incydent i deklaruje brak bieżącego ryzyka dla platformy, ale skutki dla prywatności (phishing) mogą być odczuwalne miesiącami.
  • VPN-y: utrudnienia były efektem ubocznym działań naprawczych — firma pracuje nad pełnym przywróceniem zgodności.
  • Dane krytyczne (hasła/finanse) nie zostały naruszone wg SoundCloud, ale higiena tożsamości i 2FA to w tej sytuacji obowiązek.

Źródła / bibliografia

  • Oficjalny komunikat SoundCloud: „Protecting Our Users and Our Service”, 15 grudnia 2025. (SoundCloud)
  • BleepingComputer: „SoundCloud confirms breach after member data stolen, VPN access disrupted”, 15 grudnia 2025. (bleepingcomputer.com)
  • The Register: „SoundCloud bounces some VPNs as it cleans up cyberattack”, 16 grudnia 2025. (The Register)
  • Help Net Security: „SoundCloud breached, hit by DoS attacks”, 16 grudnia 2025. (Help Net Security)
  • SecurityWeek: „User Data Compromised in SoundCloud Hack”, 16 grudnia 2025. (SecurityWeek)

CyberVolk/VolkLocker: „nowy” ransomware z krytyczną wadą kryptograficzną

Wprowadzenie do problemu / definicja luki

13 grudnia 2025 r. opisano nową usługę RaaS grupy hacktywistycznej CyberVolk o nazwie VolkLocker. Debiut okazał się nieudany z powodu poważnych błędów kryptograficznych, które umożliwiają potencjalne odszyfrowanie danych bez płacenia okupu. Ransomware korzysta z automatyzacji przez Telegram i celuje w systemy Windows oraz Linux.

W skrócie

  • Co się stało: CyberVolk uruchomił RaaS „VolkLocker”, ale implementacja szyfrowania zawiera krytyczne błędy.
  • Dlaczego to ważne: Błąd w generowaniu/przechowywaniu kluczy (m.in. hard-coded klucz AES-GCM, ślady w katalogu %TEMP%) może pozwolić ofiarom na darmową dekryptację.
  • Jak atak działa: Golang, warianty na Windows/Linux, C2 i telemetria oparte o Telegram (automatyczne powiadomienia o infekcji, zrzuty ekranu, podstawowe info o systemie).
  • Kontekst: CyberVolk to pro-rosyjska formacja hacktywistyczna rozwijająca RaaS od 2024 r.; wcześniej łączono ją z atakami DDoS i kampaniami o motywacji politycznej.

Kontekst / historia / powiązania

CyberVolk pojawił się w 2024 r. jako kolektyw hacktywistyczny łączący DDoS i ransomware. Infrastruktura rekrutacyjna i operacyjna była (i jest) silnie oparta na Telegramie, co obniża barierę wejścia dla „afiliantów”. W 2025 r. grupa wróciła z nowym „produktem” RaaS – VolkLocker – ale popełniła kardynalne błędy projektowe.

Analiza techniczna / szczegóły luki

  • Język i platformy: VolkLocker jest napisany w Go i posiada buildy dla Windows i Linux.
  • Komunikacja i automatyzacja: Wykorzystanie Telegram API/Bot do C2 i automatycznych powiadomień o infekcjach (zrzut ekranu, podstawowe dane hosta). Niektóre warianty demonstrowały dodatkowe funkcje (np. keylogging).
  • Kryptografia (błąd krytyczny):
    • Zidentyfikowano twardo zakodowany klucz AES-256-GCM w binariach.
    • W niektórych próbkach klucz zapisywany jest jawnie do %TEMP%, co tworzy „skrót” do deszyfracji.
    • Konsekwencja: w praktyce możliwe jest odzyskanie danych bez okupu, jeśli ofiara pozyska klucz z procesu/artefaktów.
  • Dowody na „choroby wieku dziecięcego”: Publiczne analizy badaczy potwierdzają niedojrzałość projektu i błędy operacyjne w najnowszych wersjach VolkLocker.

Praktyczne konsekwencje / ryzyko

  • Dla ofiar: Istnieje realna szansa na odzyskanie danych bez płatności dzięki błędom w obsłudze kluczy. Niemniej wczesne warianty mogły już zaszyfrować zasoby – konieczna jest triage i analiza pamięci/artefaktów.
  • Dla SOC/IR: Telegram-based C2 i „łatwy onboarding” afiliantów zwiększają liczbę incydentów miernej jakości, ale o dużej częstotliwości. Zespół musi przygotować szybkie playbooki pod Go-ransomware i detekcje dla ruchu/artefaktów Telegrama.
  • Ewolucja zagrożenia: Takie błędy zwykle są szybko poprawiane – okno „darmowej dekryptacji” może być krótkie w kolejnych buildach. (Wniosek inferencyjny na bazie dotychczasowych kampanii RaaS.)

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów IR/SOC:

  1. Zabezpiecz artefakty: zrzuty pamięci, %TEMP%, katalogi robocze malware – szukaj hex-klucza i plików tymczasowych pozostawionych przez VolkLocker.
  2. Blokuj Telegram C2 (domeny/API, ruch wychodzący do botów) tam, gdzie to możliwe politycznie i operacyjnie.
  3. Sygnatury i YARA/EDR: zastosuj detekcje opublikowane przez badaczy (reguły pod Go, AES-GCM, ścieżki %TEMP%, artefakty procesu).
  4. Sprawdź dostępność dekryptorów w serwisach NoMoreRansom i Emsisoft – nawet jeśli dedykatora dla VolkLocker jeszcze nie ma, pojawienie się publicznego klucza może to zmienić.

Dla zespołów bezpieczeństwa/IT:

  • Segmentacja i kopie zapasowe (3-2-1, odseparowane, regularnie testowane na odtwarzanie).
  • Zasady egress ograniczające komunikację do platform komunikatorów (Telegram) z serwerów produkcyjnych.
  • Hardening stacji/serwerów i aktualizacje; monitorowanie tworzenia nietypowych plików w %TEMP%.
  • Playbook „free decrypt”: jeśli triage wskaże hard-coded key/plik z kluczem – procedura odzysku z minimalnym RTO/RPO. (Wniosek operacyjny)

Różnice / porównania z innymi przypadkami

  • Błędy klucza w RaaS zdarzały się wcześniej (np. w młodych rodzinach ransomware), ale jednoczesne hard-codowanie klucza i pozostawianie go w plikach tymczasowych to rzadkie, podwójne potknięcie zwiększające szanse na odzysk. W porównaniu z dojrzałymi rodzinami (LockBit/BlackCat) poziom OPSEC w VolkLocker jest istotnie niższy. (Wniosek porównawczy oparty na źródłach technicznych i praktyce branżowej)

Podsumowanie / kluczowe wnioski

  • CyberVolk wraca z RaaS, ale VolkLocker cierpi na poważne wady kryptograficzne, co tworzy okazję do darmowej dekryptacji w obecnych wersjach.
  • Automatyzacja przez Telegram obniża próg wejścia dla afiliantów i może zwiększyć szum incydentów – przygotuj detekcje i blokady.
  • Okno okazji może się zamknąć wraz z poprawkami – działaj szybko: artefakty, pamięć, klucze, testy dekryptorów. (Wniosek operacyjny)

Źródła / bibliografia

  1. BleepingComputer – „CyberVolk’s ransomware debut stumbles on cryptography weakness”, 13.12.2025. (BleepingComputer)
  2. SentinelOne – „CyberVolk Returns | Flawed VolkLocker…”, analiza techniczna (2025). (SentinelOne)
  3. SOC Prime – „VolkLocker ransomware detection” (Windows/Linux, hard-coded AES-GCM). (SOC Prime)
  4. SentinelOne – „CyberVolk: A deep dive into the hacktivists…” (kontekst 2024). (SentinelOne)
  5. NoMoreRansom / Emsisoft – katalogi narzędzi dekryptujących (ogólne wytyczne i potencjalne aktualizacje). (nomoreransom.org)

DOJ i CISA ostrzegają: rosyjskie grupy CARR/NoName057(16) i Z-Pentest celują w infrastrukturę krytyczną (woda, energia, żywność)

Wprowadzenie do problemu / definicja luki

9 grudnia 2025 r. amerykański Departament Sprawiedliwości (DOJ) i CISA wraz z innymi agencjami opublikowały wspólne ostrzeżenie dotyczące kampanii prorosyjskich „hacktywistów” uderzających w systemy OT/ICS w sektorach wody i ścieków, energii oraz żywności. Ataki wykorzystują przede wszystkim słabo zabezpieczone, wystawione do internetu połączenia VNC do paneli HMI, co umożliwia zdalne manipulowanie procesami technologicznymi i wywoływanie efektów fizycznych.

W skrócie

  • Kto atakuje: Cyber Army of Russia Reborn (CARR), NoName057(16), Z-Pentest oraz powiązana od 2025 r. grupa Sector16.
  • Jak atakują: skanowanie otwartych portów VNC, brutalne łamanie haseł/wykorzystanie haseł domyślnych, dostęp do HMI/SCADA, zmiany parametrów i wyłączanie alarmów, czasem równoległe DDoS.
  • Skutki: realne oddziaływanie na procesy – m.in. rozlanie setek tysięcy galonów wody pitnej i incydent z amoniakiem w zakładzie mięsnym w Los Angeles (XI 2024).
  • Powiązania z państwem: CARR miała być finansowana/kierowana przez GRU; NoName057(16) – projekt sankcjonowany przez państwo, z własnym narzędziem DDoSia.

Kontekst / historia / powiązania

Wraz z eskalacją wojny Rosji przeciw Ukrainie (2022) wzrosła liczba prorosyjskich grup, które zaczęły łączyć DDoS z ingerencjami w OT. W 2024 r. administratorzy CARR i NoName zainicjowali Z-Pentest, deklarując specjalizację w intruzjach OT i porzucając DDoS na rzecz „głośniejszych” włamań do HMI. W 2025 r. pojawiła się także Sector16 współpracująca z Z-Pentest.

Równolegle trwa presja prawna i „kinetyczna”: w lipcu 2025 r. operacja międzynarodowa Eastwood (Europol/Eurojust) uderzyła w infrastrukturę NoName057(16), a 9 grudnia 2025 r. DOJ ogłosił dwa akty oskarżenia wobec obywatelki Ukrainy powiązanej z CARR i NoName.

Wcześniej (19 lipca 2024 r.) OFAC nałożył sankcje na liderkę CARR Julię Pankratovą i kluczowego hakera Denisa Degtiarenkę.

Analiza techniczna / szczegóły luki

Wspólna porada CISA/NSA/FBI/EPA/DOE/DISA identyfikuje powtarzalny, tani łańcuch działań (TTP), nastawiony na oportunistyczne cele:

  • skanowanie internetu w poszukiwaniu wystawionych HMI/SCADA z otwartym VNC,
  • użycie VPS do bruteforce i/lub korzystanie z domyślnych/słabych haseł,
  • przejęcie widoku i sterowania w HMI (zmiany parametrów, nazw urządzeń, wyłączanie alarmów, restart),
  • rejestracja ekranu/„proofy” i propaganda w Telegramie; czasem DDoS równolegle, by ułatwić wejście do sieci.

Autorzy wskazują, że sprawcy często nie rozumieją w pełni procesów przemysłowych (niska „maturity”), ale mimo to doprowadzają do fizycznych skutków i „loss of view”, wymuszając ręczne przejęcie sterowania przez operatorów.

Praktyczne konsekwencje / ryzyko

  • Woda i ścieki: manipulacje SCADA doprowadziły do rozlania „setek tysięcy galonów” wody pitnej; DOJ łączy te incydenty z CARR.
  • Żywność: atak na zakład mięsny w Los Angeles (XI 2024) – skażenie/utylizacja mięsa i wyciek amoniaku.
  • Energetyka i inne sektory: czasowe utraty widoczności, defacement HMI, przerwy w działaniu, koszty operacyjne i reputacyjne.

Rekomendacje operacyjne / co zrobić teraz

Architektura i dostęp

  • Bezwzględnie zablokuj VNC z internetu; jeśli VNC musi istnieć, tylko przez VPN + MFA, allow-listy i jump-hosty; rozważ całkowitą eliminację VNC z OT.
  • Segmentacja sieci (ISA/IEC 62443), oddzielenie stref IT/OT, dostęp uprzywilejowany (PAM) dla kont operatorów HMI.

Twardnienie HMI/SCADA

  • Zmień domyślne hasła, wymuś MFA tam, gdzie możliwe; wyłącz nieużywane usługi, ogranicz konta serwisowe.
  • Wymuś lock-out po nieudanych logowaniach; monitoruj nietypowe sesje VNC/RDP.

Monitoring i detekcja

  • Rejestrowanie i alertowanie na: otwarcie portów VNC, nowe połączenia z VPS/hostingów, nagłe wyłączenia alarmów HMI, zmiany parametrów procesu.
  • Wdrażaj mapowanie do MITRE ATT&CK for ICS i testy w oparciu o znane TTP z CSA.

Procedury i ćwiczenia

  • Playbooki na loss of view i ręczne przejęcie sterowania; regularne ćwiczenia z zespołami utrzymania ruchu.
  • Kanały eskalacji i komunikacja z regulatorami/CSIRT-ami sektorowymi.

Zarządzanie ryzykiem dostawców

  • Kontrole zdalnego serwisu (czasowe dostępy, jednorazowe poświadczenia), SBOM dla elementów ICS, weryfikacja zabezpieczeń paneli HMI produkowanych przez OEM.

Różnice / porównania z innymi przypadkami

W odróżnieniu od klasycznych kampanii APT (np. długotrwałe, ukryte infiltracje), opisywane ataki są głośne i oportunistyczne – mają dawać szybki efekt propagandowy (screeny z HMI), ale i tak potrafią wywoływać realne skutki fizyczne. Z-Pentest odróżnia się od typowych „DDoS-brigad” tym, że celuje bezpośrednio w OT/HMI, a nie wyłącznie w warstwę www/IT.

Podsumowanie / kluczowe wnioski

  • Największym wektorem ryzyka jest VNC do HMI wystawione do internetu.
  • Grupy CARR/NoName/Z-Pentest mają (według DOJ/CISA) związki organizacyjne/finansowe z rosyjskimi strukturami państwowymi, a ich działania wykraczają poza DDoS, dotykając realnych procesów przemysłowych.
  • Nawet „małe” zakłady i gminne wodociągi są na celowniku – ataki są automatycznie skanowane i niezależne od skali ofiary.

Źródła / bibliografia

  • The Record: przegląd ostrzeżeń DOJ/CISA i powiązanych działań (10 grudnia 2025). (The Record from Recorded Future)
  • DOJ: „Justice Department Announces Actions to Combat Two Russian State-Sponsored Cyber Criminal Hacking Groups” (9 grudnia 2025). (Department of Justice)
  • Wspólna porada CISA/NSA/FBI/EPA/DOE/DC3: „Pro-Russia Hacktivists Conduct Opportunistic Attacks Against Critical Infrastructure” (9 grudnia 2025).
  • OFAC: sankcje na liderów CARR (19 lipca 2024). (U.S. Department of the Treasury)
  • Europol: Operacja Eastwood przeciw NoName057(16) (16 lipca 2025). (Europol)

Portugalia tworzy „safe harbor” dla badaczy bezpieczeństwa. Nowe wyjątki w prawie o cyberprzestępczości

Wprowadzenie do problemu / definicja luki

Portugalia zaktualizowała ustawę o cyberprzestępczości (Lei n.º 109/2009), dodając nowy art. 8.º-A: „Akty niepodlegające karze ze względu na interes publiczny w cyberbezpieczeństwie”. Przepis wprowadza prawny „safe harbor” dla badań bezpieczeństwa w dobrej wierze, ograniczając ryzyko karne dla researcherów działających proporcjonalnie i w interesie publicznym. Zmiana została przyjęta w Dekrecie-Ustawie nr 125/2025, który jednocześnie transponuje dyrektywę NIS2 i wchodzi w życie po 120 dniach od publikacji.

W skrócie

  • Co się zmienia? Działania, które normalnie podpadałyby pod „nieuprawniony dostęp” lub „nielegalną intercepcję”, mogą być niekaralne, jeśli spełnione są surowe warunki „good-faith research”.
  • Warunki kluczowe: cel publiczny (ujawnienie i poprawa bezpieczeństwa), brak korzyści majątkowej, niezwłoczne zgłoszenie luki właścicielowi/administratorowi i autorytetowi ds. cyberbezpieczeństwa, działania ściśle proporcjonalne, zakaz DoS, socjotechniki, phishingu, instalacji malware itd.
  • Kiedy prawo zacznie obowiązywać? 120 dni po publikacji (tj. 3 kwietnia 2026 r.).

Kontekst / historia / powiązania

Zmiana jest częścią szerszej reformy wdrażającej NIS2: Dekret-Ustawa 125/2025 ustanawia nowy reżim cyberbezpieczeństwa, rozszerza zakres podmiotowy i kompetencje CNCS (narodowego centrum cyberbezpieczeństwa), a także modyfikuje m.in. prawo o łączności elektronicznej i bezpieczeństwie wewnętrznym. W tym pakiecie rząd po raz drugi nowelizuje ustawę o cyberprzestępczości (109/2009), dodając wspomniany art. 8.º-A. Informację o „safe harbor” nagłośniły media branżowe.

Analiza techniczna / szczegóły luki

Nowy art. 8.º-A precyzuje, kiedy badania bezpieczeństwa nie są karalne (streszczenie najważniejszych punktów):

  1. Cel i intencja – jedynym celem jest identyfikacja podatności w systemach/produktach/usługach IT w celu zwiększenia bezpieczeństwa (m.in. poprzez odpowiedzialne ujawnienie).
  2. Brak korzyści ekonomicznej – badacz nie działa w celu uzyskania zysku ani obietnicy zysku (poza wynagrodzeniem z tytułu zwykłej działalności zawodowej).
  3. Obowiązek niezwłocznego powiadomienia – po odkryciu luki należy natychmiast poinformować właściciela/administratora systemu lub usługodawcę oraz krajową władzę ds. cyberbezpieczeństwa; ta ostatnia kieruje sprawę do Polícia Judiciária (policji sądowej), jeśli zachodzi istotność karna. Należy też przestrzegać RODO/GDPR przy przetwarzaniu danych.
  4. Proporcjonalność i minimalizacja szkód – działania ogranicza się do tego, co niezbędne do identyfikacji luki; zakazane są w szczególności:
    • DoS/DDoS,
    • socjotechnika i wprowadzanie w błąd użytkowników/administratorów,
    • phishing,
    • kradzież haseł lub innych danych wrażliwych,
    • usuwanie/zmiana danych,
    • wyrządzanie szkód systemowi,
    • instalacja i dystrybucja złośliwego oprogramowania.
  5. Dane uzyskane podczas testów – podlegają zasadom ochrony danych; jeśli je pozyskano, należy je usunąć w ciągu 10 dni od usunięcia luki i utrzymać poufność do końca procedury.
  6. Zgoda właściciela – działania wykonane za zgodą właściciela/administratora systemu również są niekaralne, przy zachowaniu obowiązków notyfikacyjnych.

Wejście w życie: Dekret wchodzi w życie po 120 dniach od publikacji w Dzienniku Ustaw; lokalne media wyliczają datę na 3 kwietnia 2026.

Praktyczne konsekwencje / ryzyko

  • Dla researcherów: to realna, ustawowa „bezpieczna przystań”, ale z istotnymi ograniczeniami: zero DoS/socjotechniki, pełna proporcjonalność, brak zysku i twardy reżim zgłaszania. Przekroczenie tych ram może ponownie wprowadzić działania w sferę karną.
  • Dla organizacji: rośnie znaczenie procesu przyjmowania zgłoszeń podatności (VDP) i gotowości do współpracy z CNCS. Brak procedur może skutkować opóźnieniami, wyciekami oraz karami administracyjnymi z reżimu NIS2.
  • Dla rynku: formalizacja „good-faith research” powinna poprawić czas reakcji na luki i jakość komunikacji, o ile firmy ustanowią jasne kanały disclosure. Media branżowe przewidują pozytywny wpływ na ekosystem bezpieczeństwa.

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji w Portugalii i podmiotów obsługujących portugalskich klientów:

  1. Ustanów VDP (Vulnerability Disclosure Policy) z jasnym kanałem kontaktu, SLA triage i polityką prywatności danych badawczych. Odnieś VDP do wymogów art. 8.º-A (powiadomienia, poufność, usuwanie danych).
  2. Wyznacz rolę „VDP ownera” po stronie bezpieczeństwa/IT i powiąż ją z zespołem prawnym oraz kontaktami do CNCS (krajowa władza ds. cyberbezpieczeństwa).
  3. Zaktualizuj wewnętrzne procedury NIS2: klasyfikacja incydentów, progi zgłoszeń i koordynacja z CSIRT – tak, by obsłużyć napływ zgłoszeń od researcherów po wejściu prawa w życie.
  4. Zabroń DoS/socjotechniki w regulaminach testów (np. programy bug bounty), aby nie zachęcać do działań wyłączonych z ochrony.
  5. Przygotuj klauzule prawne (NDA „limited”), które pozwolą na poufność do czasu naprawy i wykazanie usunięcia danych w 10 dni od załatania luki.

Dla researcherów:

  • Dokumentuj intencję i proporcjonalność, prowadź dziennik czynności.
  • Natychmiast zgłaszaj lukę właścicielowi/administratorowi i władzy ds. cyberbezpieczeństwa; zachowuj zgodność z RODO.
  • Unikaj wszystkich technik wyraźnie zakazanych (DoS, phishing, malware itd.).
  • Nie przyjmuj korzyści majątkowych za sam fakt nieautoryzowanego testu (bug bounty po zaproszeniu/uregulowane – tak; wymuszenia – nie).

Różnice / porównania z innymi przypadkami

Nowy portugalski przepis przypomina praktykę „safe harbor” znaną z programów bug bounty, ale ma rangę ustawową i precyzyjnie określone wyłączenia (DoS, socjotechnika, phishing). To bardziej formalne i restrykcyjne rozwiązanie niż ogólne, niepisane zasady „co jest OK” w branży – dzięki temu daje większą pewność prawną zarówno badaczom, jak i organizacjom. Jednocześnie ciężar dowodu dobrej wiary i proporcjonalności spoczywa na researcherze.

Podsumowanie / kluczowe wnioski

Portugalia wprowadza rzadko spotykany, ustawowy parasol ochronny dla badań bezpieczeństwa – ale ściśle skrojony i podporządkowany interesowi publicznemu. Jeśli firmy przygotują VDP i dostosują procesy NIS2, a researcherzy zachowają proporcjonalność, transparentność i zgodność z RODO, ekosystem zyska na szybszym i bezpieczniejszym ujawnianiu podatności.

Źródła / bibliografia

  1. Diário da República – Decreto-Lei n.º 125/2025 (oficjalny tekst; art. 7 dodaje art. 8.º-A do prawa o cyberprzestępczości; wejście w życie po 120 dniach).
  2. BleepingComputer – omówienie zmian i kontekstu dla researcherów. (BleepingComputer)
  3. ANACOM – nota o publikacji dekretu-ustawy i transpozycji NIS2. (Anacom)
  4. DataGuidance – informacja o transpozycji NIS2 w Portugalii. (DataGuidance)
  5. ECO SAPO – termin wejścia w życie: 3 kwietnia 2026 r. (ECO)

LockBit 5: „nowa, bezpieczna domena bloga” i… błyskawiczny wyciek infrastruktury

Wprowadzenie do problemu / definicja luki

LockBit 5.0 ogłosił „nową, bezpieczną domenę bloga z wielowarstwową ochroną przed wszechmocnym FBI”. Zaledwie kilkadziesiąt godzin później OSINT-owcy i media branżowe powiązali tę infrastrukturę z konkretną domeną i adresem IP, ujawniając wrażliwe szczegóły konfiguracji serwera. To kolejny przykład kompromitacji higieny operacyjnej (opsec) gangu po jego powrocie na scenę.

W skrócie

  • Nowa infrastruktura LockBit 5.0 została powiązana z domeną karma0[.]xyz oraz adresem IP 205.185.116.233 (AS53667 – PONYNET/FranTech).
  • Serwer wykazywał otwarte porty wysokiego ryzyka (m.in. 3389/TCP – RDP, 5985 – WinRM), co przeczy narracji o „wielowarstwowej ochronie”.
  • Na nowym DLS (data leak site) pojawiły się recyklingowane wpisy ofiar – część ofiar miała pochodzić z wcześniejszych wycieków i innych grup (Weyr0/RansomHouse).
  • Równolegle monitorujący leak-sitów odnotowali nowy onion dla „bezpiecznego bloga”.
  • W szerszym tle: po Operation Cronos (luty 2024) gang odbudował się i w 2025 r. wypuścił LockBit 5.0 z technicznymi usprawnieniami.

Kontekst / historia / powiązania

Operacja służb „Cronos” w lutym 2024 r. uderzyła w infrastrukturę i panele LockBit, co znacząco ograniczyło jego możliwości – ale nie zakończyło działalności afiliantów. W 2025 r. gang ogłosił wersję 5.0 i stopniowo odbudował ekosystem RaaS. Dzisiejsza wpadka z domeną i IP wpisuje się w pasmo problemów opsec po serii wcześniejszych ekspozycji zaplecza grupy.

Analiza techniczna / szczegóły luki

  • Punkty wiązania (pivoty): badacze powiązali „nowy bezpieczny blog” z domeną karma0[.]xyz (zwracała stronę z brandingiem „LOCKBITS.5.0”) oraz adresem 205.185.116.233 w AS53667 (PONYNET/FranTech). Dane te zostały publicznie opublikowane na X (Twitter) przez analityka OSINT i następnie opisane w serwisach branżowych.
  • Konfiguracja usług: skany zewnętrzne wskazywały na wiele otwartych portów, m.in. 21/FTP, 80/HTTP (Apache/2.4.58 + PHP 8.0.30), 3389/RDP, 5000/HTTP, 5985/WinRM, 47001/HTTP i 49666 (usługa plików). Obecność RDP/3389 i WinRM/5985 na hostach przestępczych to rzadko spotykany błąd opsec, ułatwiający identyfikację, fingerprinting i potencjalne zakłócenia. (Uwaga: lista portów pochodzi z publikacji branżowej; nie stanowi niezależnie zweryfikowanego skanu.)
  • Metadane rejestracyjne: w materiałach pojawia się rozbieżność dat WHOIS (część źródeł podaje rejestrację 2 listopada 2025, inne – 12 kwietnia 2025 i użycie nameserverów Cloudflare). To typowe w przypadku prywatności WHOIS i zmian rejestratora; należy traktować te daty jako niejednoznaczne.
  • Nowy onion / DLS: wpis monitorujący leak-sity wskazuje nowy adres .onion opisany przez LockBit jako „new secure blog domain with a multi-layered protection system”.

Praktyczne konsekwencje / ryzyko

  • Ryzyko eskalacji DDoS i ingerencji: publiczne powiązanie adresu IP i domeny zwiększa szansę na działania obronne (blokady, zgłoszenia nadużyć) oraz kolizję z innymi gangami/crowd-sourcowanymi atakami.
  • Podważona wiarygodność DLS: sygnały o recyklingu ofiar podkopują presję negocjacyjną LockBit (ofiary i negocjatorzy mogą uznać nowe „publikacje” za blef).
  • Wymierne IOCs dla obrony: karma0[.]xyz, 205.185.116.233, AS53667 i nowy onion to artefakty do blokowania i korelacji w telemetrii SOC/TI.
  • Nieprzerwany rozwój narzędzi TTP: mimo wpadek opsec, LockBit 5.0 pozostaje technicznie dojrzały (wieloplatformowość: Windows/Linux/ESXi, obfuscation, utrudnianie analizy, szybkie szyfrowanie), co przekłada się na wciąż wysokie ryzyko dla organizacji.

Rekomendacje operacyjne / co zrobić teraz

Blokady i detekcje (prewencja):

  • Dodać do polityk blokowania: karma0[.]xyz, 205.185.116.233, segmenty AS53667; monitorować ewentualne rotacje IP/domen.
  • Aktualizować listy domen/URL DLS/CS w secure web gateway/EDR/NDR.
  • W regułach IDS/IPS oraz SIEM dodać korelację na nowy onion (jeśli telemetrycznie widoczny w ruchu TOR).

Twardnienie środowisk:

  • Egzekwować MFA + restrykcje sieciowe na RDP/WinRM/SSH/VPN; dla RDP – preferować RD Gateway + Just-In-Time + przesiadka na tunelowane połączenia bastionowe.
  • Wyłączyć SMB v1, ograniczyć „shadow copy” i włączyć tamper protection w EDR.
  • Wdrożyć application allowlisting dla hostów serwerowych, segmentację sieci (zwłaszcza ESXi/hiperwizory) i kopie zapasowe 3-2-1 z testem odtwarzania.

Detekcje TTP (przykłady):

  • Wykrywanie masowego rename + nietypowe rozszerzenia plików, wyłączenia ETW, zabijania usług AV/EDR, zrzutów LSASS, eksfiltracji poprzez tunelowanie HTTP(S)/TOR.
  • Korelowanie artefaktów LockBit 5.0 ze wskaźnikami znanymi z badań (np. obfuskacja, dynamiczne rozwiązywanie API, wsparcie ESXi).

Reakcja i komunikacja:

  • Przy incydentach z „LockBit 5.0” ocenić autentyczność wpisu na DLS – weryfikować, czy nie jest to recykling. Nie płacić za „stare” dane.

Różnice / porównania z innymi przypadkami

W przeszłości wycieki infrastruktury dotyczyły m.in. paneli afiliańckich i czatów LockBit (2025), ale obecny incydent jest nietypowy, bo uderza w „nową, wzmocnioną” domenę PR-owo reklamowaną przez gang – i to niemal natychmiast po starcie. W materialne technicznym 5.0 widać progres po stronie malware’u, podczas gdy opsec i warstwa publikacyjna pozostają piętą achillesową operacji.

Podsumowanie / kluczowe wnioski

  • LockBit 5.0 traci narrację o „nietykalności”: domena karma0[.]xyz i 205.185.116.233 szybko trafiły do publicznych IOCs, a serwer wyglądał na słabo utwardzony.
  • Recykling ofiar dodatkowo podważa presję szantażową gangu.
  • Dla obrońców to moment na blokady, korelacje i hunting z użyciem świeżych wskaźników, pamiętając, że technicznie LockBit 5.0 pozostaje niebezpieczny.

Źródła / bibliografia

  1. DataBreaches.net: „LockBit 5’s ‘new secure blog domain’ infra leaked already” (07.12.2025). (DataBreaches.Net)
  2. CyberSecurityNews: „LockBit 5.0 Infrastructure Exposed in New Server, IP, and Domain Leak” (07.12.2025). (Cyber Security News)
  3. Ransomware.live: wpis „new blog domain lockbit 5.0” (05.12.2025). (Ransomware Live)
  4. Europol: „Law enforcement disrupt world’s biggest ransomware operation” (20.02.2024). (Europol)
  5. Trend Micro Research: „New LockBit 5.0 Targets Windows, Linux, ESXi” (25.09.2025). (www.trendmicro.com)

Aisuru: botnet stojący za rekordowym atakiem DDoS 29,7 Tb/s. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

W trzecim kwartale 2025 r. Cloudflare zarejestrował i zneutralizował rekordowy atak DDoS o szczytowym wolumenie 29,7 Tb/s, przypisany do gigantycznego botnetu Aisuru. To tzw. atak hiper-wolumetryczny (powyżej 1 Tb/s lub 1 mld pakietów/s), który przeciąża łącza i infrastrukturę sieciową, zanim aplikacyjne systemy ochronne zdążą zareagować. Cloudflare szacuje skalę Aisuru na 1–4 mln zainfekowanych hostów (IoT/routers), co czyni go jedną z największych aktualnie działających armii DDoS.

W skrócie

  • Rekord: 29,7 Tb/s przez ~69 s, metoda UDP carpet bombing (~15 tys. docelowych portów/s), losowane atrybuty pakietów dla ominięcia filtrów.
  • Cloudflare raportuje równolegle atak 14,1 Bpps, pokazując, że Aisuru uderza zarówno przepływem bitów, jak i ekstremalnym PPS.
  • Microsoft potwierdził, że Aisuru uderzył w Azure ruchem 15,72 Tb/s i ~3,64 Bpps z ponad 500 tys. IP. Klasa: Turbo-Mirai IoT.
  • Źródła ruchu i cele: wzrost ataków z Azji (m.in. Indonezja), ofiary w telco, hostingu, grach, finansach; krótkie kampanie (≤10 min) utrudniają reakcję manualną.

Kontekst / historia / powiązania

W 2025 r. „sufit” DDoS przesuwał się wielokrotnie: 7,3 Tb/s w czerwcu, 11,5 Tb/s we wrześniu, 22,2 Tb/s we wrześniu, aż po 29,7 Tb/s w Q3. Niezależne analizy QiAnXin XLab wiążą liczne rekordy z Aisuru (wcześniej znanym też jako „AIRASHI/kitty”), który agresywnie rekrutował urządzenia (m.in. po kompromitacji serwera aktualizacji routerów TotoLink).

Dodatkowo KrebsOnSecurity opisał, że domeny powiązane z infrastrukturą Aisuru zdominowały publiczny ranking „Top Domains” Cloudflare (DNS 1.1.1.1), co zmusiło firmę do redakcji listy — kolejny dowód skali i aktywności botnetu.

Analiza techniczna / szczegóły ataku

Rekord 29,7 Tb/s (L3/L4):

  • Vektor: UDP carpet bombing — rozproszone „śmieciowe” pakiety do tysięcy portów jednocześnie (średnio ~15 tys. portów/s).
  • Ewazja: losowanie pól pakietów (src/dst port, payload, flaga), by utrudnić reguły statyczne; routing Anycast i systemy automatycznej detekcji Cloudflare zadziałały autonomicznie.
  • Czas trwania: ~69 s — uderzenia krótkie, ale o wysokiej energii, silnie zaburzające ścieżki tranzytowe ISP.

Profil botnetu Aisuru:

  • Skład: IoT/routers (kamery IP, DVR/NVR, SoC Realtek, routery T-Mobile/Zyxel/D-Link/Linksys/TotoLink).
  • Klasa: „Turbo-Mirai-class” (wg Microsoft) — wysoki PPS i przepływ bez konieczności masowego spoofingu (Azure: minimalne spoofing).
  • Wielkość/zasoby: 1–4 mln hostów (Cloudflare), incydent Azure: >500 tys. IP.

Trendy 2025 Q3:

  • Ataki >100 Mpps +189% QoQ, >1 Tb/s +227% QoQ; 71–89% kampanii kończy się <10 min.
  • Główne branże atakowane: IT & Services, Telco, Gambling, gwałtowny wzrost w Automotive i sektorach powiązanych z surowcami.
  • Dominujące wektory sieciowe: UDP, potem DNS, SYN, ICMP. Źródła: przede wszystkim Azja (lider — Indonezja).

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla operatorów/ISP: nawet jeśli nie są celem, natężenie ruchu może zrywać stabilność segmentów krajowej infrastruktury (przeciążenia uplinków, blackholing, degradacja usług).
  • Ryzyko dla usług online: krótkie, lecz ekstremalne „impulsy” potrafią wywołać długotrwałe skutki operacyjne (niespójność danych, utrudnione przywracanie, SLO/SLA breach).
  • Ryzyko reputacyjne i finansowe: downtime, kary umowne, utrata klientów — szczególnie w grach online, fintechu i hostingu.

Rekomendacje operacyjne / co zrobić teraz

Architektura & sieć

  1. Always-on, upstream-first DDoS: stała ochrona u dostawców tranzytu/CDN (Anycast, autoscaling, mitigacja autonomiczna). Odrzuć model wyłącznie „on-demand”.
  2. Segmentacja i nadmiarowość tras: rozproszenie punktów wejścia (multi-region, multi-ISP), szybkie przełączenia (BGP communities, RTBH/Flowspec).
  3. Ustanów progi PPS/Tbps w bramach i u operatora; rozsądne rate-limiting/ACL dla UDP, uRPF/BCP-38 przeciw spoofingowi (nawet jeśli Aisuru często go nie używa).
  4. Twarde limity dla DNS/UDP: kapsułowanie usług w tunelach z kontrolą przepływu, separacja resolverów publicznych od krytycznych.

Aplikacje & edge
5. DoS-aware konfiguracje: krótkie time-outy, ochrona endpointów logowania/API, „circuit breakers”.
6. WAF + bot management (dla warstwy HTTP), choć w Aisuru kluczowa jest warstwa sieciowa — chronić obie.
7. Observability: min. 1 s granularności metryk (PPS/Tbps/port/ASN), alerty na „microbursts”.

Operacje & procedury
8. Runbooki i symulacje: ćwiczenia failover/RTBH/„blackhole”, drille łączone z dostawcami (ISP/CDN). Microsoft zaleca nie czekać do realnego ataku — testy przed peakami sezonowymi.
9. Kontakt z ISP/CDN: z wyprzedzeniem uzgodnione ścieżki eskalacji, tryby „emergency”.
10. Higiena IoT (dla producentów/ISP): aktualizacje firmware, domyślnie unikalne hasła, bezpieczny łańcuch dostaw aktualizacji (nauka z incydentu TotoLink).

Różnice / porównania z innymi przypadkami

  • Mirai vs Aisuru (Turbo-Mirai-class): podobna baza (IoT), lecz Aisuru skaluje zarówno Tb/s, jak i Bpps i stosuje carpet bombing z losowymi atrybutami pakietów, co utrudnia klasyczne wzorce detekcji; ponadto obserwuje się krótkie „impulse attacks” zamiast długich kampanii.
  • Rekordy 2025: 7,3 → 11,5 → 22,2 → 29,7 Tb/s w ciągu kilku miesięcy — bez precedensu, z częstym wskazaniem Aisuru jako sprawcy/ko-sprawcy.

Podsumowanie / kluczowe wnioski

  • 29,7 Tb/s to nowy punkt odniesienia dla L3/L4 DDoS — krótkie, ale dewastujące „uderzenia” wymagają stałej, autonomicznej ochrony i współpracy z operatorami.
  • Aisuru to obecnie apex-botnet: miliony urządzeń, zwinna taktyka (UDP carpet bombing, wysokie PPS), komercyjny model „botnet-for-hire”.
  • Organizacje powinny modernizować playbooki DDoS: upstream-first, szybkie decyzje BGP, granularne telemetrie i regularne ćwiczenia.

Źródła / bibliografia

  1. Cloudflare — Q3 2025 DDoS Threat Report (29,7 Tb/s; 1–4 mln hostów; charakterystyka ataku). (The Cloudflare Blog)
  2. Microsoft Tech Community — Azure neutralized a record-breaking 15 Tbps DDoS attack (Aisuru jako Turbo-Mirai; 500k IP; 3,64 Bpps). (TECHCOMMUNITY.MICROSOFT.COM)
  3. BleepingComputer — Aisuru botnet behind new record-breaking 29.7 Tbps DDoS attack (podsumowanie zdarzeń, 69 s, statystyki Q3). (BleepingComputer)
  4. QiAnXin XLab — Inside the 11.5Tbps-Scale Mega Botnet AISURU (profil, rekrutacja urządzeń, TotoLink). (奇安信 X 实验室)
  5. KrebsOnSecurity — Cloudflare Top Domains & Aisuru (dominacja domen Aisuru w rankingach DNS, wpływ na Radar). (Krebs on Security)