Archiwa: Windows - Strona 27 z 68 - Security Bez Tabu

APT37 (ScarCruft) przełamuje izolację: nowy zestaw malware do ataków na sieci air-gapped przez USB

Wprowadzenie do problemu / definicja luki

Sieci air-gapped (fizycznie odseparowane od Internetu) uchodzą za jedną z najmocniejszych kontroli bezpieczeństwa w środowiskach OT/ICS, wojsku czy badaniach. Problem w tym, że „air gap” prawie nigdy nie oznacza absolutnej izolacji — w praktyce dane i pliki i tak krążą pomiędzy segmentami dzięki nośnikom wymiennym (USB, dyski zewnętrzne). To właśnie ten „most operacyjny” staje się celem atakujących.

Najnowsze ustalenia pokazują, że północnokoreański aktor APT37 (ScarCruft) wdrożył narzędzia, które zamieniają pendrive’y w dwukierunkowy, ukryty kanał C2: pozwala to zarówno dostarczać polecenia do maszyn odciętych od sieci, jak i wynosić z nich dane.


W skrócie

  • Kampania została opisana przez Zscaler ThreatLabz jako „Ruby Jumper” i jest łączona z APT37.
  • Łańcuch infekcji startuje od złośliwego pliku LNK, który uruchamia PowerShell, wyciąga komponenty z samego skrótu i odpala dokument-przynętę.
  • Zidentyfikowane komponenty obejmują m.in.: RESTLEAF, SNAKEDROPPER, THUMBSBD, VIRUSTASK, FOOTWINE (oraz obserwowany wcześniej backdoor BLUELIGHT).
  • THUMBSBD realizuje kluczową funkcję: używa nośników wymiennych jako „transportu” do przekazywania poleceń i danych między systemami online i air-gapped.

Kontekst / historia / powiązania

APT37 to państwowa grupa szpiegowska powiązana z Koreą Północną, aktywna co najmniej od 2012 r., silnie skupiona na celach w Korei Południowej, ale z szerszym zasięgiem regionalnym.

Wzorzec działań pasuje do znanego modus operandi tej grupy: spear-phishing, pliki skrótów LNK, „living off trusted services” (nadużywanie zaufanych usług chmurowych jako infrastruktury C2 lub dystrybucji). Przykładowo, wcześniejsze analizy (np. Genians) opisywały kampanie APT37 wykorzystujące Dropbox i pliki LNK jako etap inicjalny.

„Ruby Jumper” rozwija te techniki o element szczególnie groźny dla środowisk odseparowanych: kontrolowaną propagację przez USB i mechanizm transferu poleceń/danych przez nośnik.


Analiza techniczna / szczegóły luki

1. Wejście: LNK + PowerShell + przynęta

Łańcuch startuje, gdy użytkownik otworzy złośliwy Windows Shortcut (LNK). Ten uruchamia PowerShell, który „wycina” (carving) zaszyte w skrócie elementy (m.in. kolejne skrypty/payloady) oraz uruchamia dokument-wabik, by zająć uwagę ofiary.

2. RESTLEAF: C2 przez Zoho WorkDrive

Pierwszym implantem jest RESTLEAF, który komunikuje się z infrastrukturą C2 wykorzystując Zoho WorkDrive (z perspektywy obrońcy: ruch do legalnej usługi SaaS).

W praktyce oznacza to:

  • ukrycie komunikacji na tle normalnego ruchu do usług chmurowych,
  • łatwiejsze obchodzenie blokad/allow-list opartych na reputacji domen,
  • potencjalnie trudniejsze atrybuowanie infrastruktury (bo „serwerem” jest repozytorium w chmurze).

3. SNAKEDROPPER: środowisko Ruby jako „kontener” dla kolejnych etapów

Kolejny etap to SNAKEDROPPER – loader, który instaluje środowisko Ruby 3.3.0 i maskuje je jako narzędzie związane z USB (m.in. poprzez nazwę wykonywalną typu usbspeed.exe). Następnie utrwala wykonanie (scheduled task wykonywany cyklicznie).

To ważne z dwóch powodów:

  1. atakujący dostarczają własny „runtime”, uniezależniając się od tego, co jest zainstalowane na stacji,
  2. nietypowy stos (Ruby runtime w katalogach systemowych/ProgramData) może utrudniać reguły detekcji oparte wyłącznie o klasyczne TTP (np. tylko PowerShell/LOLbins).

4. THUMBSBD: „dwukierunkowy przekaźnik C2” przez USB

THUMBSBD pełni rolę backdoora i mechanizmu „mostu” pomiędzy systemem online a air-gapped: przygotowuje pliki z poleceniami, zbiera wyniki i przenosi je przez ukryte katalogi na nośniku. Zscaler opisuje to wprost jako zamianę nośników wymiennych w dwukierunkowy ukryty przekaźnik C2.

W uproszczeniu: operator może „wgrać” polecenia na pendrive na maszynie mającej dostęp do C2 (chmury), a następnie ten sam pendrive przenosi polecenia do stacji air-gapped i wraca z danymi/rezultatami do środowiska online.

5. VIRUSTASK: propagacja w segmencie odciętym

Komponent VIRUSTASK odpowiada za rozprzestrzenianie w środowiskach air-gapped: „uzbraja” nośniki, ukrywając legalne pliki i zastępując je skrótami LNK, które uruchamiają zainstalowany runtime Ruby i dalsze elementy łańcucha. Co istotne, mechanizm ma warunek uruchomienia (np. minimalna wolna przestrzeń na nośniku).

6. FOOTWINE i BLUELIGHT: działania rozpoznawcze i szpiegowskie

W dalszym etapie THUMBSBD dostarcza FOOTWINE – spyware/backdoor z możliwościami takimi jak keylogging, zrzuty ekranu, nagrywanie audio/wideo czy zdalna powłoka. W kampanii obserwowano też BLUELIGHT, wcześniej wiązany z APT37, co wzmacnia atrybucję.


Praktyczne konsekwencje / ryzyko

Największa zmiana nie polega na „magicznej” zdolności łamania air-gapu, tylko na industrializacji przenoszenia kontroli między segmentami:

  • Ryzyko dla OT/ICS i infrastruktury krytycznej: nawet jeśli stacje operatorskie/HMI są odcięte od Internetu, operacyjny obieg plików (raporty, konfiguracje, logi) tworzy ścieżkę ataku.
  • C2 ukryte w chmurze: RESTLEAF wykorzystujący Zoho WorkDrive może wyglądać jak „normalny ruch SaaS”, co komplikuje polityki oparte na prostym allow/deny dla domen.
  • Skuteczna inwigilacja: finalne payloady nastawione są na długotrwałe zbieranie informacji (keylogging, screen/audio/video), co jest typowe dla operacji szpiegowskich.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie ograniczają ryzyko w scenariuszu „USB jako most”:

  1. Twarda kontrola nośników wymiennych
  • wdrożenie polityk device control (whitelist konkretnych VID/PID/seriali),
  • wymuszenie szyfrowania i rejestrowania użycia nośników,
  • ograniczenie autorun i blokada uruchamiania skrótów LNK z nośników (tam gdzie to możliwe operacyjnie).
  1. Detekcja na endpointach (EDR) pod kątem TTP z kampanii
  • alarmy na nietypowe uruchomienia PowerShell pochodzące z LNK,
  • monitoring tworzenia zadań harmonogramu (scheduled tasks) o podejrzanych nazwach/cykliczności,
  • polowanie na anomalię: runtime Ruby wypakowany w nietypowych lokalizacjach (np. %PROGRAMDATA%) i procesy typu usbspeed.exe uruchamiane cyklicznie.
  1. Kontrola dostępu do usług chmurowych (CASB / SWG / proxy)
  • inspekcja i alertowanie na nietypowe użycie Zoho WorkDrive w organizacji (zwłaszcza jeśli nie jest wykorzystywany biznesowo),
  • korelacja: tokeny/operacje API do chmury + zdarzenia endpointowe (LNK/PowerShell) w krótkim oknie czasu.
  1. Procedury dla środowisk air-gapped
  • „strefa buforowa” (kiosk) do skanowania nośników przed wejściem do segmentu odseparowanego,
  • walidacja plików przenoszonych do OT (formaty, podpisy, źródło, integralność),
  • jeśli to możliwe: jednokierunkowy transfer (data diode) zamiast przenoszenia danych na USB.

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

  • Klasyczne infekcje przez LNK: APT37 korzysta z tej techniki od lat, co widać także w starszych kampaniach opisywanych publicznie (np. nadużycia usług chmurowych i LNK jako wektora).
  • Nowość w „Ruby Jumper”: nie sam phishing, lecz spójny zestaw narzędzi do obsługi pełnego cyklu air-gap (propagacja + przenoszenie poleceń + exfil przez nośnik), oraz wyraźne postawienie na chmurę SaaS (Zoho WorkDrive) jako warstwę C2.

Podsumowanie / kluczowe wnioski

APT37 pokazuje, że „air-gap” bez kontroli nośników wymiennych jest bardziej założeniem niż zabezpieczeniem. Kampania Ruby Jumper łączy:

  • inicjalny dostęp przez LNK + PowerShell,
  • C2 ukryte w Zoho WorkDrive,
  • oraz krytyczny element: THUMBSBD/VIRUSTASK, które zamieniają USB w kanał sterowania i transferu danych do/z środowisk air-gapped.

Jeśli w organizacji istnieje choćby minimalny „ruch USB” między segmentami, warto potraktować ten scenariusz jako realny i wdrożyć kontrolę nośników, hunting endpointowy oraz polityki dla usług SaaS.


Źródła / bibliografia

  • BleepingComputer – opis kampanii i przegląd narzędzi (RESTLEAF, SNAKEDROPPER, THUMBSBD, VIRUSTASK, FOOTWINE, BLUELIGHT). (BleepingComputer)
  • Zscaler ThreatLabz – raport techniczny „APT37 Adds New Capabilities for Air-Gapped Networks” (Ruby Jumper, Zoho WorkDrive, szczegóły łańcucha infekcji). (zscaler.com)
  • MITRE ATT&CK – profil grupy APT37 (G0067) i kontekst operacyjny. (MITRE ATT&CK)
  • Genians – przykład wcześniejszych kampanii APT37 z LNK i nadużyciem chmury (kontekst TTP). (genians.co.kr)

Trend Micro ostrzega przed krytycznymi lukami RCE w Apex One: CVE-2025-71210 i CVE-2025-71211

Wprowadzenie do problemu / definicja luki

Trend Micro (w segmencie enterprise komunikujące się też marką TrendAI) opublikowało ostrzeżenie o dwóch krytycznych podatnościach typu Remote Code Execution (RCE) w konsoli zarządzającej Trend Micro Apex One dla Windows. Luki mają charakter directory/path traversal (CWE-22) i mogą umożliwić atakującemu wgranie złośliwego kodu oraz wykonanie poleceń na serwerze zarządzającym — czyli w newralgicznym miejscu całego systemu ochrony endpointów.


W skrócie

  • Podatności: CVE-2025-71210 i CVE-2025-71211 (obie CVSS 9.8, krytyczne).
  • Komponent: Apex One Management Console (Windows).
  • Warunek istotny operacyjnie: Trend Micro podkreśla, że atakujący musi mieć dostęp do konsoli zarządzającej — dlatego szczególnie ryzykowne są środowiska, w których IP/GUI konsoli jest wystawione do Internetu lub szerokich sieci.
  • Naprawa: dla on-prem Apex One 2019 wydano Critical Patch (CP) Build 14136; środowiska SaaS zostały już zmitigowane.

Kontekst / historia / powiązania

Apex One (oraz ekosystem produktów „Apex”) jest regularnie celem badaczy, bo konsola zarządzająca stanowi „punkt centralny” do dystrybucji polityk i agentów. W najnowszym biuletynie Trend Micro zaznacza też, że CP zawiera dodatkowe usprawnienia ochrony związane z wcześniejszymi krytycznymi problemami (m.in. CVE-2025-54948 / CVE-2025-54987), co jest sygnałem, że producent wzmacnia obszary historycznie narażone na nadużycia w warstwie zarządzania.

Warto odnotować, że bieżące luki zostały zgłoszone w ramach odpowiedzialnego ujawniania przez Zero Day Initiative (ZDI), a identyfikatory ZDI-CAN-28001 i ZDI-CAN-28002 pojawiają się w dokumentacji i harmonogramie advisory ZDI.


Analiza techniczna / szczegóły luki

Co oznacza „directory/path traversal” w konsoli zarządzającej?

W uproszczeniu: błąd typu traversal pojawia się, gdy aplikacja nie ogranicza poprawnie ścieżek plików do „bezpiecznego” katalogu bazowego. Atakujący może wtedy manipulować parametrami (np. sekwencjami ../) tak, aby:

  • zapisać plik poza dozwolonym katalogiem (np. w lokalizacji wykonywalnej),
  • albo odwołać się do zasobów, do których nie powinien mieć dostępu.

W tym przypadku Trend Micro opisuje scenariusz, w którym podatność może pozwolić zdalnemu atakującemu na przesłanie złośliwego kodu i wykonanie komend w środowisku konsoli.

Dwie podatności, podobny mechanizm – inny „punkt zaczepienia”

  • CVE-2025-71210: Console Directory Traversal RCE (ZDI-CAN-28001).
  • CVE-2025-71211: analogiczna klasa błędu, ale dotycząca innego pliku wykonywalnego w obrębie konsoli (ZDI-CAN-28002).

Ważny warunek eksploatacji (nie ignoruj go)

Trend Micro wprost wskazuje, że do skutecznego ataku wymagany jest dostęp do Apex One Management Console; jeśli konsola ma publicznie dostępny adres IP, producent sugeruje stosowanie ograniczeń źródeł (source restrictions) jako czynnika mitygującego ryzyko.

To nie czyni luk „niegroźnymi” — w praktyce dostęp do konsoli bywa osiągalny przez:

  • przejęte konto administratora (phishing/credential stuffing),
  • tunelowanie z sieci wewnętrznej po wcześniejszym foothold,
  • błędne wystawienie panelu w Internecie,
  • nadużycia w segmentacji sieci.

Praktyczne konsekwencje / ryzyko

Jeśli atakujący uzyska RCE na serwerze zarządzającym Apex One, konsekwencje eskalują szybciej niż w typowym incydencie endpointowym:

  • przejęcie dystrybucji polityk (wyłączenie ochrony, wyjątki, manipulacja konfiguracją),
  • potencjalne rozsyłanie payloadów do hostów zarządzanych,
  • pivot do innych systemów (konsola często ma szerokie uprawnienia i łączność),
  • ryzyko „quiet takeover”: napastnik może działać pod przykrywką legalnych mechanizmów zarządzania.

Choć publiczne doniesienia koncentrują się na samej naprawie, sens operacyjny jest prosty: konsola bezpieczeństwa po przejęciu staje się narzędziem ataku.


Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj on-prem Apex One 2019 do CP Build 14136 (priorytet P1).
  2. Jeśli używasz wariantu SaaS (Apex One as a Service / Trend Vision One Endpoint – Standard Endpoint Protection), sprawdź status, ale Trend Micro wskazuje, że SaaS zostało już zmitigowane.
  3. Zablokuj ekspozycję konsoli:
    • usuń publiczny dostęp do panelu,
    • wymuś dostęp wyłącznie przez VPN/ZTNA,
    • zastosuj allowlistę źródeł (source restrictions), o której wspomina producent.
  4. Wymuś twarde uwierzytelnianie do konsoli:
    • MFA,
    • rotacja haseł kont uprzywilejowanych,
    • dedykowane konta admin (bez poczty/WWW).
  5. Monitoring i detekcja:
    • przegląd logów serwera zarządzającego i zdarzeń aplikacyjnych,
    • alerty na nietypowe uploady/operacje plikowe w katalogach aplikacji,
    • kontrola nowych procesów uruchamianych przez usługi konsoli.
  6. Higiena uprawnień:
    • ogranicz prawa konta/serwisu, jeśli architektura na to pozwala,
    • odseparuj serwer konsoli w sieci (segment + reguły egress).

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

  • Nowe luki (CVE-2025-71210/71211) to CWE-22 (traversal) w konsoli i mają CVSS 9.8, ale Trend Micro podkreśla wymóg dostępu do panelu.
  • W 2025 r. głośne były podatności CWE-78 (command injection) w on-prem konsoli (np. CVE-2025-54948), które również dotykały warstwy zarządzającej — NVD opisuje je jako możliwość uploadu złośliwego kodu i wykonania komend.

Wspólny mianownik: konsola zarządzająca jako „high-value target”. Różnica: klasa błędu i detale warunków wejściowych, ale skutek operacyjny (przejęcie serwera zarządzającego) pozostaje podobnie groźny.


Podsumowanie / kluczowe wnioski

  • Dwie krytyczne podatności traversal w konsoli Apex One mogą prowadzić do RCE (CVE-2025-71210 i CVE-2025-71211, CVSS 9.8).
  • Największe ryzyko mają środowiska, gdzie konsola jest dostępna z zewnątrz lub gdzie łatwo o kradzież poświadczeń do panelu.
  • Dla on-prem Apex One 2019 kluczowa jest aktualizacja do CP Build 14136; SaaS jest już po stronie dostawcy zmitigowany.

Źródła / bibliografia

  1. Trend Micro (TrendAI) – Security Bulletin: Apex One and Apex One (Mac) – February 2026 (KA-0022458). (success.trendmicro.com)
  2. BleepingComputer – Trend Micro warns of critical Apex One code execution flaws (26 lutego 2026). (BleepingComputer)
  3. SecurityWeek – Trend Micro Patches Critical Apex One Vulnerabilities. (SecurityWeek)
  4. Zero Day Initiative – wpisy dotyczące ZDI-CAN-28001 / ZDI-CAN-28002 (harmonogram/advisories). (zerodayinitiative.com)
  5. NVD (NIST) – kontekst wcześniejszych luk w Apex One (np. CVE-2025-54948). (nvd.nist.gov)

Aeternum C2: botnet, którego „serce” mieszka w blockchainie Polygon (i dlaczego to komplikuje takedown)

Wprowadzenie do problemu / definicja „luki”

Aeternum C2 to loader botnetowy, który przenosi kluczowy element infrastruktury C2 do publicznego łańcucha Polygon. Zamiast klasycznego serwera C2 (domena/IP), operator publikuje polecenia jako dane w smart kontraktach, a zainfekowane hosty pobierają je, odpytując publiczne endpointy RPC. W praktyce oznacza to C2 odporne na typowe działania typu sinkhole, przejęcie domen czy wyłączanie serwerów.


W skrócie

  • C2 na Polygonie: polecenia trafiają do smart kontraktów i są odczytywane przez boty via publiczne RPC.
  • Panel operatorski: webowy panel (opisywany jako aplikacja w Next.js) służy do wyboru kontraktu, typu komendy i URL payloadu, a następnie zapisuje komendę w blockchainie jako transakcję.
  • Szyfrowanie: komendy są szyfrowane AES-GCM, a klucz wyprowadzany PBKDF2 (100k iteracji) z adresu kontraktu – co może umożliwiać defensywną dekrypcję historycznych poleceń, bo adres kontraktu jest publiczny.
  • „Ekonomia ataku”: niski koszt operacyjny – w doniesieniach pada, że ok. 1 USD w MATIC wystarcza na 100–150 transakcji z komendami.
  • Model „crimeware”: oferta sprzedaży dostępu do panelu/kompilacji oraz źródeł (C++) pojawia się w opisach kampanii.

Kontekst / historia / powiązania

Aeternum C2 wpisuje się w trend „decentralizacji” C2: brak jednego hosta do przejęcia. Media branżowe porównują ten schemat do wcześniejszych przypadków, np. Glupteba, gdzie blockchain był wykorzystywany jako kanał zapasowy do pobierania właściwego adresu C2. W Aeternum blockchain ma być kanałem pierwotnym, co zwiększa odporność na takedown.


Analiza techniczna / szczegóły działania

1) Architektura: loader + smart kontrakt + publiczne RPC

  • Loader (Windows, buildy x86/x64) pobiera instrukcje nie z domeny, tylko z kontraktu na Polygonie.
  • Odczyt poleceń odbywa się przez wywołanie funkcji kontraktu (np. getDomain()), a aktualizacja poleceń przez updateDomain(), co generuje zdarzenia/logi w łańcuchu.

2) Format komend i targetowanie

W analizie panelu opisano prosty język poleceń:

  • all:url:<URL> – uruchom na wszystkich hostach
  • hwid:<...>:url:<URL> – uruchom tylko na hoście o wskazanym HWID
  • warianty z args: oraz savestartupname: (pod kątem uruchomienia payloadu i „dopalenia” trwałości).

Ciekawy detal: HWID ma wynikać z MD5 numeru seryjnego dysku C: (co upraszcza selektywne „dozowanie” ładunków).

3) Szyfrowanie poleceń i potencjalna słabość projektu

Komendy przechowywane w kontrakcie są szyfrowane AES-GCM, a klucz ma być wyprowadzany przez PBKDF2 (SHA-256, 100 000 iteracji) z materiału powiązanego z adresem kontraktu. W praktyce, jeśli schemat derivacji opiera się o publiczny adres (a tak opisano w analizie panelu), obrońcy mogą dekodować historyczne polecenia dla danego kanału C2.

To ważne: „blockchainowe C2” utrudnia wyłączenie, ale przez swoją transparentność potrafi ułatwiać telemetrię i rekonstrukcję działań operatora – o ile znamy kontrakty i schemat kryptograficzny.

4) Panel operatorski i OPSEC

W badaniu panelu podkreślono, że panel prosi o klucz prywatny Polygon i deklaruje jego szyfrowanie AES-256-GCM po stronie przeglądarki (localStorage), bez wysyłania klucza na serwer. To poprawia OPSEC operatora (mniej elementów do przejęcia), ale nadal zostawia artefakty po stronie urządzenia operatora.

5) Anti-analysis i „commodity” funkcje

Doniesienia branżowe opisują mechanizmy utrudniające analizę (np. wykrywanie środowisk wirtualnych) oraz weryfikację „niewykrywalności” buildów przez usługi typu skan AV (wskazywano m.in. Kleenscan).


Praktyczne konsekwencje / ryzyko

  1. Takedown jest trudniejszy: nie ma „serwera”, który można wyłączyć – polecenia siedzą w publicznym łańcuchu.
  2. Detekcja sieciowa musi się zmienić: klasyczne IoC (domena/IP C2) przestają wystarczać; trzeba patrzeć na ruch do endpointów RPC i specyficzne wzorce zapytań.
  3. Ryzyko wieloładunkowe: według opisu, operator może zarządzać wieloma kontraktami/payloadami (stealer/RAT/miner/clipper), co sprzyja szybkiej monetyzacji infekcji.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC / Blue Team

  • Monitoring egress: zidentyfikuj i profiluj ruch do publicznych Polygon RPC (HTTP/S). Szukaj cyklicznych zapytań (polling) z nietypowych hostów użytkowników/serwerów.
  • Detekcje oparte o zachowanie: koreluj: nowe procesy + pobieranie binariów z URL + nietypowy ruch do RPC + mechanizmy trwałości (np. uruchamianie przy starcie).
  • Threat hunting po blockchainie: jeśli w telemetryce (EDR/proxy) znajdziesz adres kontraktu, możesz pivotować po zdarzeniach/logach kontraktu i odtwarzać sekwencję komend (w analizach pokazano, że bywa to wykonalne).

Dla IR / Incident Response

  • Szybkie odcięcie pobierania payloadów: nawet jeśli nie wyłączysz C2, możesz blokować domeny/hostingi, z których Aeternum ściąga payload (URL jest elementem komendy).
  • Zabezpiecz artefakty sieciowe: pełne PCAP/proxy logs z okresu infekcji mogą pozwolić na identyfikację kontraktu i rekonstrukcję poleceń.

Dla IT / prewencji

  • Hardening stacji/serwerów: ogranicz uruchamianie niepodpisanych binariów, włącz reguły ASR (tam gdzie możliwe), kontroluj persistence (startup/run keys/scheduled tasks).
  • Segmentacja i least privilege: loader jest „bramą” do kolejnych ładunków – minimalizuj skutki przez ograniczanie uprawnień i dostępu lateralnego.

Różnice / porównania z innymi przypadkami

  • Glupteba (2021): blockchain jako kanał pomocniczy do odzyskania „prawdziwego” C2.
  • Aeternum C2 (2025/2026): blockchain jako kanał główny – bez klasycznego C2 do przejęcia.

W skrócie: wcześniejsze kampanie traktowały blockchain jako mechanizm odporności; Aeternum przesuwa go do roli „kręgosłupa” operacji.


Podsumowanie / kluczowe wnioski

Aeternum C2 to praktyczny przykład, że decentralizacja C2 przestaje być teorią: smart kontrakty na Polygonie mogą utrzymywać kanał poleceń długo po tym, jak klasyczna infrastruktura zostałaby wyłączona. Jednocześnie transparentność łańcucha (logi, zdarzenia) daje obrońcom nowe opcje analityczne – zwłaszcza gdy schemat szyfrowania/derywacji klucza jest przewidywalny. Największa zmiana po stronie defensywy to przejście z „blokowania domen” na polowanie na zachowania i telemetrię RPC/blockchain.


Źródła / bibliografia

  1. The Hacker News – opis Aeternum C2 i modelu C2 na Polygonie (26 lutego 2026). (The Hacker News)
  2. Ctrl-Alt-Int3l – analiza panelu, funkcji smart kontraktu, szyfrowania AES-GCM/PBKDF2 i formatu komend. (Ctrl-Alt-Int3l)
  3. SecurityWeek – omówienie odporności na takedown i elementów „crimeware” (sprzedaż, panel). (SecurityWeek)
  4. SC Media (SCWorld) – streszczenie techniki C2 przez smart kontrakty i cech anty-analizy. (SC Media)
  5. MITRE ATT&CK – technika „Credentials in Registry” (kontekstowo, jako typowy wzorzec polowania; nie jako potwierdzenie dla Aeternum). (attack.mitre.org)

SolarWinds łata 4 krytyczne podatności RCE w Serv-U (CVE-2025-40538 – CVE-2025-40541)

Wprowadzenie do problemu / definicja luki

SolarWinds wydał poprawki dla czterech krytycznych podatności w Serv-U (rozwiązanie do zarządzanego transferu plików / FTP/MFT). To klasa systemów, która często stoi na styku sieci (DMZ), obsługuje wrażliwe dane i integruje się z AD/LDAP — a więc jej kompromitacja bywa równoznaczna z szybkim „przeskokiem” do wnętrza organizacji.

W tym przypadku mówimy o podatnościach, które mogą prowadzić do zdalnego wykonania kodu (RCE) z wysokimi uprawnieniami, jeśli spełnione są określone warunki dostępu.


W skrócie

  • CVE: CVE-2025-40538, CVE-2025-40539, CVE-2025-40540, CVE-2025-40541
  • Ocena: każda podatność ma CVSS 9.1 (Critical).
  • Dotyczy: linia Serv-U 15.5.
  • Naprawiono w: Serv-U 15.5.4 (release date: 24 lutego 2026).
  • Ważny niuans: część scenariuszy nadużycia wymaga uprawnień administracyjnych (np. domain admin / group admin), ale skutkiem może być pełne przejęcie procesu/usługi i wykonanie kodu z wysokimi uprawnieniami.

Kontekst / historia / powiązania

Z perspektywy obrony istotne są dwa fakty:

  1. Serv-U bywa wdrażany jako usługa krytyczna (transfer danych B2B, automatyzacje, integracje). Wiele organizacji trzyma go publicznie dostępnym, co zwiększa presję na szybkie łatanie.
  2. Agencje i zespoły CSIRT ostrzegają o konieczności pilnych aktualizacji — m.in. singapurskie CSA rekomenduje natychmiastowe przejście na wersję naprawioną.

Analiza techniczna / szczegóły luki

SolarWinds w oficjalnych release notes wskazuje, że Serv-U 15.5.4 usuwa cztery błędy o charakterze RCE, obejmujące trzy klasy problemów: Broken Access Control, Type Confusion oraz IDOR.

CVE-2025-40538 — Broken Access Control → eskalacja do RCE

Opis (w uproszczeniu): błąd kontroli dostępu pozwala atakującemu (w określonych warunkach) utworzyć użytkownika typu system admin i finalnie doprowadzić do wykonania kodu z podwyższonymi uprawnieniami (w zależności od kontekstu: m.in. w oparciu o uprawnienia domain/group admin).

CVE-2025-40539 i CVE-2025-40540 — Type Confusion → wykonanie natywnego kodu

To klasy podatności pamięciowe, gdzie „pomylenie typu” obiektu może umożliwić wykonanie arbitralnego natywnego kodu. SolarWinds klasyfikuje oba jako krytyczne RCE.

CVE-2025-40541 — IDOR → ścieżka do RCE

IDOR (Insecure Direct Object Reference) oznacza podatność z obszaru kontroli dostępu, w której aplikacja pozwala odwoływać się do zasobów/obiektów bez właściwej autoryzacji. W tym przypadku SolarWinds wskazuje, że może to prowadzić do wykonania kodu.

„Admin-required”, ale nadal krytyczne — dlaczego?

NVD zaznacza, że nadużycie CVE-2025-40538 wymaga uprawnień administracyjnych, a w środowiskach Windows ryzyko bywa oceniane inaczej, bo usługi często działają na mniej uprzywilejowanych kontach serwisowych. To jednak nie eliminuje zagrożenia: w realnych incydentach napastnicy często najpierw zdobywają poświadczenia (phishing, password spraying, reuse), a dopiero potem „domykają” przejęcie przez RCE w kluczowej usłudze.


Praktyczne konsekwencje / ryzyko

Jeśli podatności zostaną wykorzystane w praktyce, najbardziej realistyczne skutki to:

  • Przejęcie serwera MFT/FTP (RCE), a następnie kradzież lub modyfikacja danych w tranzycie i „w spoczynku”.
  • Pivot do sieci wewnętrznej (Serv-U często ma łączność do AD/LDAP, udziałów plikowych, baz danych, systemów integracyjnych).
  • Długotrwała obecność dzięki stworzeniu nowych uprzywilejowanych kont (scenariusz szczególnie istotny przy CVE-2025-40538).

Rekomendacje operacyjne / co zrobić teraz

Priorytet 1 — aktualizacja

  • Zaktualizuj Serv-U do 15.5.4 (to wersja zawierająca poprawki dla wszystkich czterech CVE).

Priorytet 2 — ogranicz powierzchnię ataku

  • Ogranicz dostęp do paneli administracyjnych (allowlist IP/VPN, brak ekspozycji do internetu, segmentacja DMZ).
  • Wymuś MFA tam, gdzie to możliwe, i ogranicz liczbę kont z uprawnieniami domain/group admin mających jakikolwiek związek z obsługą Serv-U.

Priorytet 3 — szybki hunting (24–72h)

  • Przejrzyj logi pod kątem:
    • nowych/nieoczekiwanych kont administracyjnych i zmian ról,
    • nietypowych operacji wykonywanych przez konta domenowe/grupowe,
    • anomalii procesów i potomków procesu usługi Serv-U (nieoczekiwane interpretery, narzędzia systemowe, droppery).
  • Zabezpiecz telemetrię EDR na hoście i rozważ reguły detekcji dla nietypowych child-processów usługi.

Priorytet 4 — higiena poświadczeń

  • Rotacja haseł dla kont administracyjnych, które mogły mieć styczność z Serv-U.
  • Audyt uprawnień: minimalizuj role, usuń konta nieużywane, wdrażaj zasadę najmniejszych uprawnień.

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

W obrębie tej paczki CVE warto rozróżnić:

  • Błędy logiczne (Broken Access Control / IDOR): często bardziej zależne od tego, kto i skąd ma dostęp (np. panel admin), ale potrafią kończyć się pełnym przejęciem, jeśli omijają krytyczne bramki autoryzacji.
  • Błędy pamięciowe (Type Confusion): zwykle bardziej „surowe” technicznie (natywny kod), a ich eksploatacja bywa atrakcyjna dla atakujących, bo daje stabilny RCE przy sprzyjających warunkach.

W praktyce — jeśli Serv-U jest wystawiony na świat i ma szerokie uprawnienia integracyjne, oba typy podatności są równie groźne operacyjnie.


Podsumowanie / kluczowe wnioski

  • SolarWinds załatał 4 krytyczne podatności RCE w Serv-U 15.5, ocenione na CVSS 9.1, i opublikował poprawki w Serv-U 15.5.4 (24.02.2026).
  • Część scenariuszy wymaga uprzywilejowanego dostępu, ale to nie zmniejsza pilności — bo w łańcuchach ataków zdobycie poświadczeń bywa pierwszym krokiem.
  • Najrozsądniejsza strategia to: aktualizacja + ograniczenie ekspozycji + szybki hunting pod kątem nowych kont admin, anomalii procesów i nietypowych działań administracyjnych.

Źródła / bibliografia

  1. SolarWinds Documentation — Serv-U 15.5.4 release notes (Fixed CVEs) (documentation.solarwinds.com)
  2. SecurityWeek — SolarWinds Patches Four Critical Serv-U Vulnerabilities (SecurityWeek)
  3. NVD (NIST) — CVE-2025-40538 (opis, warunki nadużycia) (nvd.nist.gov)
  4. CSA (Singapore) — Critical Vulnerabilities in SolarWinds Serv-U (Cyber Security Agency of Singapore)
  5. CCB Belgium — Warning: critical vulnerabilities in SolarWinds Serv-U… (ccb.belgium.be)

Arkanix Stealer: krótkożyjący infostealer jako „eksperyment AI” – co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Arkanix Stealer to rodzina malware typu infostealer (kradzież informacji), sprzedawana jako usługa (MaaS – malware-as-a-service) i promowana na forach cyberprzestępczych pod koniec 2025 r. Wyróżnia ją to, że badacze znaleźli przesłanki sugerujące AI/LLM-asystowany rozwój – co może obniżać próg wejścia dla autorów malware i skracać cykl „pomysł → działający stealer”.


W skrócie

  • Arkanix był reklamowany co najmniej od października 2025, a projekt miał mieć charakter krótkożyjący i nastawiony na szybki zysk.
  • Oferowano dwie linie ładunku: wersję Python (basic) oraz natywną C++ (premium), z ochroną/obfuskacją (m.in. VMProtect) i dodatkowymi funkcjami.
  • Istniał panel zarządzania oraz komunikacja przez Discord – element typowy dla MaaS.
  • Kaspersky wskazuje na ślady, które mogą sugerować udział LLM w kodowaniu, a projekt mógł być „bardziej publicznym produktem software’owym” niż klasycznie skrytym stealerem.

Kontekst / historia / powiązania

Z perspektywy rynku cyberprzestępczego Arkanix wpisuje się w trend „commodity stealers”: szybko rozwijanych narzędzi kradnących dane z przeglądarek, portfeli krypto i komunikatorów, dystrybuowanych przez kanały społecznościowe i „społeczności narzędziowe”.

Badacze opisują promocję Arkanixa w podziemiu oraz komponenty „biznesowe” (panel, tiering, społeczność na Discordzie). Właśnie taka produktowa otoczka MaaS sprawia, że nawet krótkożyjące kampanie potrafią zostawić duży „dług” incydentowy (sprzedane loginy, tokeny, dane przeglądarkowe).


Analiza techniczna / szczegóły luki

Architektura i modele dostarczania (Python vs C++)

Kaspersky opisuje zestaw implantów obejmujący Python loader/stealer oraz natywny wariant C++, przy czym model sprzedaży zakładał rozdział funkcji na „basic” i „premium”.

Zakres kradzionych danych

W dostępnych analizach przewija się typowy profil infostealera:

  • dane z Chromium-based przeglądarek (np. loginy, cookies, profile),
  • artefakty/sekrety związane z krypto-walletami,
  • informacje systemowe, a w „premium” – dodatkowe moduły typu screenshoty, Wi-Fi credentials, dane z aplikacji (np. platformy gamingowe/VPN).

ChromElevator i „post-exploitation”

Ciekawy element z raportu Kaspersky: Arkanix wykorzystywał publicznie dostępne narzędzie post-exploitation dla przeglądarek o nazwie ChromElevator, dostarczane przez natywną wersję stealera. To sugeruje pragmatyczne składanie „klocków” (gotowe komponenty + własny loader/panel), co dobrze pasuje do hipotezy o przyspieszonym wytwarzaniu.

Ślady AI/LLM w kodzie

BleepingComputer relacjonuje wnioski Kaspersky o przesłankach LLM-asystowanego developmentu (ślady w kodzie, które mogą wskazywać na udział modelu językowego i redukcję kosztu/czasu wytwarzania). Ważne praktycznie: nawet jeśli Arkanix „zniknął”, sam wzorzec (AI-wspomagane, szybko iterowane stealer-MaaS) jest ryzykiem systemowym.

IoC i infrastruktura

Kaspersky udostępnia listę IoC (hashy, domen, IP) oraz opis infrastruktury/promocji; to kluczowe do detekcji i threat huntingu.


Praktyczne konsekwencje / ryzyko

  1. Przejęcia kont: cookies/tokeny sesyjne mogą omijać samo hasło, a zebrane dane logowania trafiają do sprzedaży lub do dalszych ataków (BEC, przejęcia SaaS, lateral movement).
  2. Kradzież środków: kompromitacja portfeli krypto, rozszerzeń walletów lub seedów (bezpośrednia strata finansowa).
  3. Ryzyko łańcuchowe: infostealery są często „pierwszym etapem” – po nich pojawia się loader, ransomware lub włam do repozytoriów/CI.
  4. Trudniejszy tracking: krótkie życie projektu + modularność + szybkie iteracje utrudniają korelację kampanii i budowanie stabilnych sygnatur.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/Blue Team

  • Włącz hunt pod kątem artefaktów infostealerów: nietypowe dostępy do profili przeglądarek, masowe odczyty baz Login Data/Cookies (Chromium), podejrzane procesy potomne przeglądarek, anomalie w katalogach profilu użytkownika.
  • Zaciągnij IoC z raportu Kaspersky do SIEM/EDR i ustaw alertowanie (hash/domena/IP), a następnie koreluj z ruchem DNS/HTTP(S). (Securelist)
  • Blokuj dystrybucję przez Discord (tam gdzie to realne): polityki proxy/DNS, kontrola aplikacji, allowlisting binarek, ograniczenia dla plików pobieranych z komunikatorów i „community file sharing”.
  • Kontrola uruchamiania: AppLocker/WDAC (Windows), blokady dla uruchamiania z katalogów użytkownika (Downloads/Temp), szczególnie dla skryptów i dropperów.

Dla IT/SecOps

  • Wymuś MFA (najlepiej phishing-resistant, np. FIDO2) dla kluczowych usług; traktuj infostealery jako scenariusz „hasło już wyciekło”.
  • Zredukuj wartość danych w przeglądarce: polityki blokujące zapisywanie haseł, przejście na menedżer z ochroną, segmentacja profili, ograniczenia dla rozszerzeń.
  • Ochrona krypto (jeśli dotyczy organizacji): cold storage, separacja środowisk, zakaz seedów w plikach/komunikatorach, monitoring zmian w rozszerzeniach walletów.
  • IR playbook: jeżeli podejrzewasz infekcję infostealerem – reset haseł + unieważnienie sesji/tokenów, rotacja kluczy API, przegląd reguł przekierowań w poczcie, sprawdzenie OAuth app consent.

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

W porównaniu do „klasycznych” stealerów-MaaS, Arkanix wygląda na projekt:

  • bardziej produktowy (panel + społeczność) i jednocześnie krótkożyjący, co pasuje do modelu „szybki zysk i znikamy”.
  • oferujący wyraźny podział na Python vs natywny C++ (tiering funkcji i utrudnianie analizy/wykrycia).
  • z sygnałami sugerującymi, że LLM mógł przyspieszać tworzenie/iterację funkcji, co w dłuższej perspektywie może zwiększać „tempo mutacji” podobnych rodzin malware.

Podsumowanie / kluczowe wnioski

Arkanix Stealer jest dobrym przykładem, że nie trzeba wieloletniego projektu, by wypuścić na rynek działający infostealer z panelem i community. Najbardziej niepokojący wątek to przesłanki AI-asystowanego developmentu: nawet jeśli sam Arkanix był epizodem, to mechanika (szybkie składanie modułów + automatyzacja kodowania + sprzedaż w modelu MaaS) może w 2026 r. oznaczać więcej krótkich, trudnych do przypisania kampanii.


Źródła / bibliografia

  1. BleepingComputer – „Arkanix Stealer pops up as short-lived AI info-stealer experiment” (22 lutego 2026). (BleepingComputer)
  2. Kaspersky Securelist (GReAT) – „Arkanix Stealer: a C++ & Python infostealer” (19 lutego 2026). (Securelist)
  3. G DATA Security Blog – „Arkanix Stealer: Newly discovered short term profit malware” (1 grudnia 2025). (gdatasoftware.com)
  4. eSecurity Planet – „Rapidly Evolving Arkanix Stealer Hits Credentials and Wallets” (2 grudnia 2025). (eSecurity Planet)

CVE-2026-21513 w MSHTML: jak APT28 omija MotW i doprowadza do wykonania plików (analiza Akamai)

Wprowadzenie do problemu / definicja luki

CVE-2026-21513 to podatność typu Security Feature Bypass w MSHTML (Trident) – historycznym silniku renderowania HTML kojarzonym z Internet Explorerem, który nadal bywa wykorzystywany przez różne komponenty Windows. Luka została załatana w ramach Patch Tuesday z lutego 2026, a co ważniejsze: Microsoft i społeczność bezpieczeństwa potwierdzili aktywną eksploatację “in the wild”.

W praktyce mówimy o scenariuszu, w którym atakujący doprowadza do ominięcia mechanizmów ochronnych (m.in. zaufania/ostrzeżeń związanych z uruchamianiem zasobów), a następnie do uruchomienia wskazanych zasobów/plików poza oczekiwanym kontekstem bezpieczeństwa.


W skrócie

  • Komponent: MSHTML / IEFRAME (m.in. ieframe.dll)
  • Typ: protection mechanism failure / security feature bypass (CWE-693)
  • CVSS (CNA Microsoft): 8.8 (HIGH), wektor: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
  • Wymagana interakcja użytkownika: tak (np. otwarcie pliku HTML lub skrótu .lnk)
  • Status: w CISA KEV + termin działań (KEV “due date”) 2026-03-03
  • Atrybucja kampanii: Akamai wiąże obserwowaną eksploatację z APT28

Kontekst / historia / powiązania

Choć Edge nie używa MSHTML jako silnika przeglądarki, legacy komponenty Windows wciąż mogą opierać się o IE/Trident. To otwiera furtkę do “powrotu” starych klas ataków – szczególnie tam, gdzie istnieją osadzone kontrolki, WebBrowser control lub inne elementy, które potrafią parsować HTML przez MSHTML.

W lutym 2026 tematy “security feature bypass” w Windows pojawiały się grupowo (np. analogiczne klasy problemów w Shell/Word), co sugeruje szerszy trend: atakujący konsekwentnie szukają sposobów, by zwiększyć niezawodność initial access poprzez obchodzenie ostrzeżeń i mechanizmów zaufania.


Analiza techniczna / szczegóły luki

Root cause (wg Akamai / PatchDiff-AI)

Akamai opisuje analizę “inside the fix” wykonaną z użyciem PatchDiff-AI, która wiąże CVE-2026-21513 z konkretną ścieżką kodu w ieframe.dll (Internet Explorer frame). Kluczowy problem: niewystarczająca walidacja docelowego URL podczas obsługi nawigacji hyperlinków, co pozwala doprowadzić sterowane dane do ścieżki wywołującej ShellExecuteExW. Efekt: wykonanie zasobu lokalnego lub zdalnego poza zamierzonym kontekstem bezpieczeństwa przeglądarki.

Akamai wskazuje też nazwę funkcji widoczną w call stack / analizie różnic: _AttemptShellExecuteForHlinkNavigate.

Jak wygląda łańcuch eksploatacji (kampania “in the wild”)

Z perspektywy kampanii przypisanej do APT28, Akamai opisuje próbkę wykorzystującą złośliwy skrót Windows (.lnk), w którym osadzono HTML (doklejony zaraz po standardowej strukturze LNK). Taki plik ma inicjować komunikację z infrastrukturą atakującego (wskazany domenowy IOC), a sama technika eksploatacji używa m.in. zagnieżdżonych iframe’ów i wielu kontekstów DOM do manipulacji granicami zaufania.

Istotny szczegół: mechanika ma pozwalać na obejście Mark of the Web (MotW) oraz Internet Explorer Enhanced Security Configuration (IE ESC), czyli elementów, które normalnie utrudniają automatyczne/nieświadome uruchamianie treści i ostrzegają użytkownika.

Co zmienia poprawka

Według Akamai, fix polega na ostrzejszej walidacji protokołów w nawigacji hyperlinków tak, aby wspierane protokoły (np. file://, http://, https://) były obsługiwane w kontekście przeglądarki, zamiast trafiać “wprost” do ShellExecuteExW.


Praktyczne konsekwencje / ryzyko

  • Ryzyko operacyjne: to nie jest “tylko bypass ostrzeżenia”. W realnym łańcuchu ataku omijanie MotW/ostrzeżeń znacząco podnosi skuteczność infekcji (większa szansa, że payload uruchomi się bez podejrzanych promptów).
  • Powierzchnia ataku: Akamai podkreśla, że podatna ścieżka może zostać wywołana przez dowolny komponent osadzający MSHTML, więc wektory dostarczenia mogą wykraczać poza .lnk (np. inne scenariusze z osadzonym renderowaniem HTML).
  • Priorytet patchowania: obecność w CISA KEV to silny sygnał, że podatność jest praktycznie wykorzystywana i wymaga szybkich działań (KEV due date 2026-03-03).

Rekomendacje operacyjne / co zrobić teraz

  1. Pilne wdrożenie poprawek z lutego 2026
    To podstawowa i docelowa mitigacja. Tenable i Akamai jednoznacznie wskazują, że aktualizacje z February 2026 Security Updates / Patch Tuesday zamykają podatność.
  2. Hunting/Detekcja pod kątem IOC (z raportu Akamai)
    Akamai publikuje konkretne wskaźniki, które warto wrzucić do SIEM/EDR oraz kontroli DNS/Proxy:
    • SHA-256 próbki LNK: aefd15e3c395edd16ede7685c6e97ca0350a702ee7c8585274b457166e86b1fa
    • Domena: wellnesscaremed[.]com
    • (mapowanie TTP) MITRE ATT&CK: T1204.001, T1566.001
  3. Hardening “initial access” (jeśli patching nie jest natychmiastowy)
    • ogranicz uruchamianie/otwieranie .lnk i plików HTML z niezaufanych źródeł (polityki, ASR/EDR, ograniczenia w mail gateway)
    • wzmocnij kontrolę nad treściami pobieranymi z Internetu oraz strefami (gdzie możliwe) – bo celem ataku jest obejście ostrzeżeń kontekstowych (MotW)
  4. Identyfikacja miejsc, gdzie MSHTML jest nadal osadzone
    Skoro wektor może dotyczyć komponentów wykorzystujących legacy renderowanie, warto zidentyfikować aplikacje/komponenty w organizacji, które używają WebBrowser control / MSHTML i potraktować je jako podwyższone ryzyko.

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

W lutym 2026 obok CVE-2026-21513 pojawiły się podobne klasowo problemy (np. security feature bypass w Windows Shell oraz w Word). SANS ISC zwraca uwagę, że wspólnym mianownikiem jest sytuacja, w której użytkownik nie jest właściwie ostrzegany przed uruchomieniem pobranego kodu/zasobów, a mechanizmy typu SmartScreen mają być obchodzone.

W praktyce: jeśli organizacja miała już procesy “MotW/SmartScreen bypass triage”, CVE-2026-21513 pasuje do tej samej półki priorytetu.


Podsumowanie / kluczowe wnioski

  • CVE-2026-21513 to aktywnie wykorzystywany bypass mechanizmów ochronnych w MSHTML/IEFRAME, który w realnych kampaniach prowadzi do uruchomienia zasobów przez ścieżkę z ShellExecuteExW.
  • Kampania opisana przez Akamai używa sprytnie spreparowanego .lnk z osadzonym HTML i technik manipulacji kontekstem DOM, aby ominąć MotW/IE ESC.
  • Najważniejsze działania: patchowanie lutego 2026 + szybkie polowanie na IOC (hash + domena) i kontrola wektorów initial access opartych o .lnk/HTML.

Źródła / bibliografia

  1. Akamai, Inside the Fix: Analysis of In-the-Wild Exploit of CVE-2026-21513 (20 Feb 2026). (akamai.com)
  2. NVD (NIST), CVE-2026-21513 Detail (publ. 10 Feb 2026; KEV info, CVSS 8.8, CWE-693). (NVD)
  3. Tenable, Microsoft’s February 2026 Patch Tuesday Addresses 54 CVEs… (10 Feb 2026). (Tenable®)
  4. Rapid7 Vulnerability DB, Microsoft Windows: CVE-2026-21513… (10 Feb 2026). (Rapid7)
  5. SANS ISC Diary, Microsoft Patch Tuesday – February 2026 (10 Feb 2026). (SANS Internet Storm Center)

FBI: ponad 20 mln USD strat przez falę ataków „ATM jackpotting” z użyciem malware (2025)

Wprowadzenie do problemu / definicja luki

„ATM jackpotting” to cyber-fizyczny scenariusz ataku na bankomat, w którym przestępcy wymuszają wypłatę gotówki bez autoryzowanej transakcji. W przeciwieństwie do skimmingu czy przechwytywania PIN-ów, celem nie są dane klientów, tylko sam bankomat i jego warstwa sterowania.

W lutym 2026 FBI opublikowało alert (FLASH), w którym opisuje gwałtowny wzrost incydentów „malware-enabled jackpotting” w USA: ponad 700 zdarzeń w 2025 r. i ponad 20 mln USD strat.


W skrócie

  • FBI śledzi ok. 1 900 incydentów jackpotting od 2020 r., z czego >700 przypadło na 2025 r.
  • W atakach ma być wykorzystywana m.in. rodzina malware Ploutus, która umożliwia wydawanie poleceń modułowi wypłat przez warstwę XFS (eXtensions for Financial Services), omijając autoryzację bankową.
  • Wejście w kompromitację zwykle wymaga fizycznego dostępu do bankomatu (np. użycie powszechnie dostępnych „generycznych” kluczy), a następnie podmiany/nośnika lub manipulacji dyskiem.
  • FBI publikuje przykładowe IOC (nazwy plików, hashe) i wskazuje konkretne zdarzenia Windows przydatne w detekcji (m.in. 6416, 4663, 4688, 1102).

Kontekst / historia / powiązania

Jackpotting nie jest nową koncepcją — badacze demonstrowali ją publicznie już ponad dekadę temu. Różnica polega na tym, że to, co kiedyś bywało „showcase’em” podatności i złych praktyk wdrożeniowych, dziś jest powtarzalnym modelem przestępczym: szybkie wejście, szybka wypłata, szybkie wyjście. TechCrunch podkreśla, że ataki „wyszły” z obszaru demonstracji badawczych do realnej, masowej przestępczości, a FBI wiąże skalę z rosnącą liczbą incydentów w ostatnich latach.


Analiza techniczna / szczegóły luki

1) Co dokładnie omija Ploutus/XFS?

Z perspektywy architektury bankomatu: aplikacja ATM zwykle wysyła żądania (np. „dispense cash”) do warstwy pośredniej XFS, a następnie — w normalnym trybie — następuje autoryzacja po stronie banku, zanim gotówka zostanie wydana. FBI opisuje, że jeśli napastnik uzyska możliwość wydawania własnych komend do XFS, może pominąć autoryzację i wymusić wypłatę „na żądanie”.

2) Typowe drogi infekcji (wąskie gardło: fizyczny dostęp)

Według alertu FBI, najczęściej scenariusz zaczyna się od otwarcia frontu bankomatu (np. generyczne klucze), a potem:

  • wyjęcie dysku, podłączenie do komputera napastnika, skopiowanie malware i ponowne zamontowanie dysku w bankomacie, lub
  • podmiana dysku na przygotowany wcześniej nośnik z malware i restart urządzenia.

FBI zaznacza też, że malware wchodzi w interakcję bezpośrednio ze sprzętem bankomatu, omijając część mechanizmów oryginalnego oprogramowania.

3) IOC i ślady systemowe (Windows)

W FLASH pojawiają się przykładowe wskaźniki kompromitacji na zainfekowanych bankomatach Windows, m.in. nietypowe pliki wykonywalne takie jak: Newage.exe, Color.exe, Levantaito.exe, NCRApp.exe, sdelete.exe, Promo.exe, WinMonitor.exe, WinMonitorCheck.exe, Anydesk1.exe oraz lista zidentyfikowanych hashy MD5.

Z punktu widzenia telemetrii i wykrywania FBI wskazuje m.in.:

  • zdarzenia związane z nośnikami USB i audytem: 6416 (wykrycie nowego zewnętrznego urządzenia), 4663 (dostęp/modyfikacja obiektu przy odpowiednim audycie), oraz 4688 (tworzenie procesu — szczególnie wartościowe po włączeniu logowania linii poleceń),
  • 1102 jako sygnał czyszczenia logów (istotne w kontekście zacierania śladów).

Praktyczne konsekwencje / ryzyko

  1. Straty finansowe i operacyjne
    To atak na instytucję/operującego bankomatami: gotówka znika natychmiast, często zanim systemy centralne „zorientują się”, że urządzenie zachowuje się nietypowo. FBI podkreśla, że ataki mogą zająć minuty i bywają wykrywane dopiero po fakcie.
  2. Ryzyko reputacyjne
    Nawet jeśli dane klientów nie zostały przejęte, narracja „bankomaty wypłacają gotówkę na zawołanie” wpływa na zaufanie do sieci urządzeń i standardów ochrony.
  3. Ryzyko eskalacji do zdalnego dostępu
    FBI zwraca uwagę na obecność/wykorzystanie narzędzi zdalnego dostępu (np. AnyDesk/TeamViewer) jako potencjalny element układanki, jeśli jest nieautoryzowany.

Rekomendacje operacyjne / co zrobić teraz

Poniżej praktyczny „checklist” inspirowany zaleceniami FBI — szczególnie użyteczny dla banków, operatorów sieci ATM i firm serwisowych.

1) Zabezpieczenia fizyczne (najważniejszy kontrolny punkt)

  • wymiana standardowych zamków (ograniczenie skuteczności generycznych kluczy),
  • czujniki (wibracja/temperatura) i alarmy otwarcia klap serwisowych,
  • dodatkowe bariery do krytycznych elementów (cashbox, dostęp serwisowy),
  • monitoring wizyjny i retencja nagrań.

2) „Gold image” i walidacja integralności

FBI mocno akcentuje praktykę utrzymywania kontrolowanego, zweryfikowanego obrazu („gold image”) oraz ciągłą walidację hashy plików wykonywalnych/bibliotek/konfiguracji. Odchylenia (nowe, niepodpisane binaria) traktuj jako potencjalną kompromitację — to pomaga wykrywać ataki, które omijają monitoring sieciowy, bo artefakty są wprowadzane lokalnie.

3) Twarde polityki dla nośników i urządzeń

  • audyt użycia pamięci wymiennych i zdarzeń USB,
  • whitelisting urządzeń (blokada nieautoryzowanych dysków/telefonów),
  • (gdzie możliwe) szyfrowanie dysku oraz kontrole integralności firmware/boot.

4) Telemetria, EDR i reguły detekcji pod jackpotting

  • włącz i zbieraj: 6416 / 4663 / 4688 / 1102 oraz koreluj je w sekwencje (np. „USB inserted → malware copied → malware executed → logs cleared”),
  • wykrywaj nieoczekiwane procesy i pliki (IOC z alertu) oraz nietypowe wpisy autostartu/usług,
  • centralizuj logi i wydłuż retencję (żeby utrudnić „przeczekanie” incydentu).

5) Gotowość operacyjna i współpraca

  • uporządkuj harmonogram serwisów i dostępów (łatwiej wyłapać anomalie),
  • przeszkol personel ochrony/serwisu w rozpoznawaniu symptomów (otwarcia poza oknem serwisowym, obce urządzenia, bankomat „out of service” bez powodu),
  • raportuj incydenty zgodnie z kanałami FBI/IC3 i zbieraj komplet danych o urządzeniu oraz logach.

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

  • Jackpotting vs skimming: skimming celuje w dane kart/PIN i oszustwa transakcyjne; jackpotting celuje w mechanizm wydawania gotówki i zwykle nie wymaga danych klientów.
  • Atak sieciowy vs cyber-fizyczny: tu często kluczowe jest naruszenie fizyczne (otwarcie obudowy, dostęp do dysku/portów). Dlatego klasyczne zabezpieczenia IT (firewalle, segmentacja) są potrzebne, ale niewystarczające bez twardych kontroli fizycznych i integralności obrazu.

Podsumowanie / kluczowe wnioski

  • Skala incydentów rośnie: >700 zdarzeń w 2025 r. i >20 mln USD strat według FBI.
  • Technicznie rdzeniem problemu jest możliwość wydawania poleceń do XFS, co pozwala ominąć autoryzację i sterować wypłatą gotówki.
  • Obrona to miks „security engineering” i ochrony fizycznej: zamki/czujniki/monitoring + gold image + audyt USB/logów + whitelisting.

Źródła / bibliografia

  1. FBI / IC3 – Increase in Malware-Enabled ATM Jackpotting Incidents Across United States (FLASH-20260219-001) (Federal Bureau of Investigation)
  2. BleepingComputer – FBI: Over $20 million stolen in surge of ATM malware attacks in 2025 (BleepingComputer)
  3. TechCrunch – FBI says ATM ‘jackpotting’ attacks are on the rise… (TechCrunch)
  4. SecurityWeek – FBI: $20 Million Losses Caused by 700 ATM Jackpotting Attacks in 2025 (SecurityWeek)
  5. SC Media – FBI provides ATM jackpotting prevention guidance after $20M stolen… (scworld.com)