Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 379 z 494

FBI przejmuje forum RAMP – ważny cios w ekosystem ransomware i handel „initial access”

Wprowadzenie do problemu / definicja luki

W świecie cyberprzestępczym fora i „marketplace’y” pełnią rolę infrastruktury krytycznej: to tam łączy się popyt (ransomware-as-a-service, brokerzy dostępu, sprzedawcy malware) z podażą (afilianci, „operatorzy”, pośrednicy od prania pieniędzy, sprzedawcy exploitów). Przejęcie takiego węzła rzadko kończy ransomware „w ogóle”, ale potrafi na pewien czas realnie spowolnić rekrutację afiliantów, handel dostępami do sieci (initial access) i dystrybucję narzędzi.

Właśnie w tym kontekście warto patrzeć na przejęcie RAMP (Russian Anonymous Marketplace) – rosyjskojęzycznego forum, które otwarcie dopuszczało promocję operacji ransomware.


W skrócie

  • 28 stycznia 2026 r. FBI przejęło zarówno wersję Tor, jak i clearnetową domenę forum ramp4u[.]io, zastępując je banerem „This site has been seized”.
  • Na banerze wskazano koordynację z U.S. Attorney’s Office for the Southern District of Florida oraz DOJ CCIPS (Computer Crime and Intellectual Property Section).
  • Widoczne są też techniczne ślady przejęcia: m.in. zmiana serwerów nazw na ns1.fbi.seized.gov i ns2.fbi.seized.gov.
  • Jeden z rzekomych operatorów („Stallman”) miał publicznie potwierdzić przejęcie.

Kontekst / historia / powiązania

RAMP wystartował w lipcu 2021 r. jako odpowiedź na sytuację, w której duże rosyjskojęzyczne fora (m.in. Exploit i XSS) zaczęły ograniczać/banować promocję ransomware pod rosnącą presją organów ścigania po głośnych incydentach (np. Colonial Pipeline). RAMP pozycjonował się jako jedno z niewielu miejsc, gdzie „ransomware jest dozwolone” – co szybko przyciągnęło gangi i afiliantów.

Wątek personalny jest równie istotny: według ustaleń opisywanych w materiałach, z RAMP wiązano postać działającą pod pseudonimem Orange (aliasy m.in. Wazawaka/BorisElcin), łączoną z ekosystemem Babuk; w tle pojawia się również Mikhail Matveev, oskarżany przez USA o udział w operacjach ransomware (m.in. LockBit, Babuk, Hive) i objęty sankcjami.


Analiza techniczna / szczegóły „takedownu”

Z perspektywy operacyjnej przejęcie RAMP jest klasycznym przykładem „domain seizure + takeover” z kilkoma elementami, które warto odnotować:

  1. Jednoczesne przejęcie Tor i clearnetu
    Fakt, że komunikat zajęcia pojawił się i na domenie publicznej, i na usłudze .onion, sugeruje działanie ukierunkowane na pełne odcięcie kanałów dostępu oraz redukcję możliwości „szybkiego powrotu” przez prostą zmianę domeny frontowej.
  2. Zmiana DNS/NS na infrastrukturę „seized”
    Przestawienie serwerów nazw na ns1.fbi.seized.gov / ns2.fbi.seized.gov jest technicznym potwierdzeniem, że organ ścigania uzyskał kontrolę nad kluczowym zasobem w warstwie DNS, co zwykle towarzyszy realizacji nakazów zajęcia.
  3. Wartość dowodowa danych forum
    W scenariuszu przejęcia infrastruktury forum, organy ścigania mogą potencjalnie uzyskać dostęp do danych takich jak: adresy e-mail, logi IP, wiadomości prywatne, metadane transakcji, wątki dot. sprzedaży dostępów itp. Wprost wskazywano, że brak odpowiedniego OPSEC może teraz przełożyć się na identyfikację i aresztowania.
  4. Efekt psychologiczny i dezintegracyjny
    Baner „trollujący” operatorów (odwołanie do hasła RAMP) pełni rolę komunikatu: „mamy kontrolę”, co zwykle zwiększa panikę wśród użytkowników i przyspiesza rozpad zaufania oraz migrację – często chaotyczną.

Praktyczne konsekwencje / ryzyko

Dla organizacji (obrońców)

  • Krótkoterminowe przetasowania w podziemiu: po takedownie często rośnie aktywność na alternatywnych forach/marketach, a brokerzy dostępu próbują szybko „odbudować kanały sprzedaży”. To okres zwiększonego szumu, ale też okazja do lepszego mapowania TTP i relacji.
  • Ryzyko wtórne: część aktorów może próbować „odkuć się” bardziej agresywnymi kampaniami phishingowymi, infostealerami i masową sprzedażą dostępów, by zrekompensować utracone kontakty/escrow.

Dla cyberprzestępców

  • Wzrost ryzyka deanonymizacji przy słabym OPSEC (powtarzalne aliasy, te same skrzynki e-mail, logowania bez tor/VPN, błędy w separacji person).
  • Utrata reputacji i escrow: na forach „zaufanie” jest walutą. Zniknięcie RAMP wymusza weryfikacje od nowa, co często prowadzi do konfliktów, scamów i rozłamów.

Rekomendacje operacyjne / co zrobić teraz

Jeśli odpowiadasz za bezpieczeństwo (SOC/CTI/IR), potraktuj ten moment jako szansę na podniesienie gotowości:

  1. Podnieś czujność na „initial access”
    Zwiększ korelację alertów dla: nietypowych logowań (VPN/RDP/VDI), anomalii w IAM, nowych tokenów OAuth, podejrzanych rejestracji urządzeń, i prób ruchu lateralnego. RAMP był wykorzystywany do handlu dostępami – migracja może podbić wolumen.
  2. Wzmocnij kontrolę tożsamości
    • MFA odporne na phishing (FIDO2/WebAuthn) tam, gdzie to realne
    • przegląd kont uprzywilejowanych, rotacja sekretów, ograniczenie stałych uprawnień
    • polityki „impossible travel” i detekcja proxy/VPN exit nodes
  3. Przygotuj scenariusze ransomware-ready
    • test odtwarzania kopii (nie tylko „backup exists”, ale „restore działa”)
    • izolacja domen/segmentacja, kontrola ruchu SMB/RDP/WinRM
    • gotowe playbooki: containment, komunikacja, decyzje dot. wyłączania usług
  4. Uważaj na „nowe fora” i podszycia
    Po głośnych przejęciach często rośnie liczba scam-forów i kampanii podszywających się pod „następcę”, co bywa wykorzystywane także do infekowania przestępców (infostealery), ale przy okazji może zwiększać liczbę wycieków narzędzi do sieci publicznej.

Różnice / porównania z innymi przypadkami

RAMP wyróżniał się tym, że był jednym z ostatnich dużych hubów pozwalających wprost na promocję ransomware. Dlatego jego utrata jest bardziej „systemowa” niż przejęcie pojedynczej grupy czy strony wyciekowej.

Z doświadczeń poprzednich takedownów wynika, że:

  • ekosystem nie znika, tylko migruje (często na kilka konkurencyjnych platform),
  • okres przejściowy generuje tarcia, scamy i błędy OPSEC,
  • dla obrońców to moment, w którym warto intensywniej zbierać sygnały o nowych kanałach rekrutacji i sprzedaży dostępów.

Podsumowanie / kluczowe wnioski

Przejęcie RAMP przez FBI (28 stycznia 2026 r.) to realne zakłócenie infrastruktury wspierającej ransomware-as-a-service, rekrutację afiliantów i rynek „initial access”.
Najważniejsze efekty będą prawdopodobnie widoczne w dwóch obszarach:

  • operacyjnym (przerwanie kanałów handlu i komunikacji, migracja),
  • kontrwywiadowczym (potencjalny dostęp organów ścigania do danych użytkowników i metadanych aktywności).

Dla organizacji to dobry moment, by założyć, że część aktorów „przegrupuje się” i spróbuje odzyskać tempo – a więc wzmocnić detekcję, IAM, backup/restore oraz gotowość IR.


Źródła / bibliografia

  • BleepingComputer – informacje o przejęciu, banerze, DNS i historii RAMP (BleepingComputer)
  • The Register – uzupełnienie kontekstu, komentarze dot. migracji i znaczenia dla ekosystemu (The Register)
  • U.S. Department of Justice (DOJ) – tło dot. Matveeva (LockBit/Babuk/Hive), CCIPS, nagroda do $10M (Department of Justice)
  • U.S. Treasury (OFAC) – sankcje na Matveeva i szerszy kontekst rosyjskiego ekosystemu ransomware (U.S. Department of the Treasury)

eScan: przejęty serwer aktualizacji posłużył do dystrybucji złośliwego „update” (supply chain) – co wiemy i jak reagować

Wprowadzenie do problemu / definicja luki

Incydenty typu supply chain (kompromitacja łańcucha dostaw) należą do najgroźniejszych, bo nadużywają mechanizmu, któremu organizacje ufają najbardziej: legalnych aktualizacji. W przypadku eScan (MicroWorld Technologies) potwierdzono, że nieautoryzowany plik trafił do ścieżki dystrybucji aktualizacji w obrębie jednego z regionalnych klastrów serwerów, a następnie został pobrany przez część klientów w ograniczonym oknie czasowym 20 stycznia 2026 r.


W skrócie

  • eScan potwierdził nieautoryzowany dostęp do konfiguracji regionalnego serwera aktualizacji i dystrybucję błędnego/złośliwego pliku w kanale update w dniu 20.01.2026 (wąskie okno czasowe, wybrany klaster).
  • Morphisec opisał kampanię jako wieloetapową infekcję opartą o podmieniony komponent aktualizacji (m.in. Reload.exe) oraz dalsze payloady (m.in. CONSCTLX.exe), z naciskiem na „anti-remediation” (blokowanie przyszłych aktualizacji).
  • Kluczowy problem operacyjny: na systemach dotkniętych incydentem automatyczna naprawa/aktualizacja może nie działać, bo malware celowo psuje mechanikę aktualizacji.

Kontekst / historia / powiązania

To nie pierwszy raz, gdy eScan pojawia się w kontekście nadużyć aktualizacji. W 2024 r. opisywano operację przypisywaną aktorom powiązanym z Koreą Płn., gdzie mechanizm aktualizacji eScan miał zostać wykorzystany do dostarczania backdoorów i minerów (kampania określana m.in. jako GuptiMiner) – tam scenariusz obejmował manipulację ruchem/aktualizacją (MitM) i podmianę paczki.
Różnica w 2026 r. jest zasadnicza: tym razem mówimy o dystrybucji przez legalną infrastrukturę aktualizacji (zaufany kanał vendorowy), co zwykle zwiększa „skuteczność” kampanii i utrudnia wczesne wykrycie.


Analiza techniczna / szczegóły luki

Z perspektywy TTP (tactics/techniques/procedures) w opisie Morphisec przewijają się trzy szczególnie niebezpieczne elementy:

1) Trojanizacja komponentu aktualizacji (Stage 1)
Atak miał zacząć się od podmiany 32-bitowego komponentu związanego z aktualizacją – wskazywany jest Reload.exe – który następnie realizował persistence, wykonywanie poleceń i przygotowanie gruntu pod kolejne etapy.

2) „Anti-remediation”: blokowanie przyszłych aktualizacji i naprawy
Złośliwy kod miał modyfikować m.in. plik HOSTS oraz elementy konfiguracji/rejestru eScan tak, aby utrudnić komunikację z serwerami aktualizacji i uniemożliwić pobieranie kolejnych definicji/patche’y. To klasyczny wzorzec: utrzymać foothold i „odciąć” ofiarę od leczenia.

3) Persistence przez Scheduled Tasks + artefakty w rejestrze (Stage 2/3)
Morphisec opisuje m.in. tworzenie zadań harmonogramu podszywających się pod defragmentację (np. nazwy w stylu Windows\Defrag\…Defrag, przykładowo „CorelDefrag”) oraz podejrzane klucze w HKLM\Software\{GUID} z danymi w formie tablicy bajtów (PowerShell payload).

C2 / infrastruktura
Wskazano też przykładowe adresy C2 i zasoby pobierania kolejnych payloadów (w publikacjach zwykle podawane w formie zanonimizowanej typu hxxps://… i [.]). W praktyce SOC powinien dodać je do blokad na brzegu sieci i w DNS/Proxy, a następnie skorelować z logami. (


Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyka dla organizacji korzystających z eScan:

  • Utrata zaufania do kanału aktualizacji: nawet poprawnie zarządzany endpoint może zostać zainfekowany „legalnym” update’em.
  • Zablokowanie aktualizacji definicji AV/EDR: jeśli mechanizm aktualizacji zostanie uszkodzony, stacja robocza może pozostać w stanie „ślepoty” na nowe próbki i IOC.
  • Trwała obecność (persistence) i możliwość dalszej eskalacji: opisywane backdoory/downloader’y (np. CONSCTLX.exe) sugerują gotowość do dogrywania kolejnych modułów (kradzież danych, lateral movement, ransomware).
  • Ryzyko wtórnych kompromitacji: Morphisec rekomenduje także reset poświadczeń, jeśli zainfekowane hosty mogły uzyskać dostęp do kont/zasobów (typowy następny krok po supply chain).

Rekomendacje operacyjne / co zrobić teraz

Jeśli macie eScan w środowisku (enterprise lub consumer), sensowny playbook „tu i teraz”:

  1. Ustal ekspozycję na okno 20.01.2026
    • Przejrzyj logi aktualizacji eScan oraz ruch sieciowy z tego dnia, zwłaszcza jeśli endpointy korzystały z regionalnych serwerów/CDN.
  2. Traktuj dotknięte hosty jak potencjalnie skompromitowane
    • Izoluj z sieci systemy, na których wystąpiły symptomy: błędy aktualizacji, komunikaty o niedostępności update, zmiany w HOSTS, brak nowych definicji.
  3. Polowanie na IOC (endpoint + AD + sieć)
    • Szukaj: Reload.exe (nietypowe hashe/ścieżki), CONSCTLX.exe, zadań w Windows\Defrag\, podejrzanych kluczy HKLM\Software\{GUID} z danymi binarnymi, katalogów-znaczników (np. opisywany efirst w ProgramData).
  4. Zablokuj infrastrukturę C2
    • Dodaj domeny/IP z raportu do blokad (DNS sinkhole, proxy, firewall) i sprawdź historię połączeń.
  5. Naprawa eScan może wymagać działania manualnego
    • Morphisec podkreśla, że na zainfekowanych systemach automatyczne „doleczenie” może nie zadziałać, bo mechanizm aktualizacji został celowo uszkodzony — wymagany jest kontakt z vendorem i ręczne zastosowanie patcha/narzędzia naprawczego.
  6. Forensics i higiena poświadczeń
    • Zweryfikuj, czy doszło do uruchomienia Stage 3/backdoora; w razie potwierdzenia – pełne IR: timeline, triage pamięci, przegląd kont uprzywilejowanych, rotacja haseł/tokenów.

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

2024 (GuptiMiner) vs 2026 (kompromitacja serwera/klastra aktualizacji):

  • 2024: opisywano scenariusz, w którym atakujący podmieniają paczkę aktualizacji w trakcie dostarczania (MitM / słabe zabezpieczenia kanału).
  • 2026: według potwierdzenia eScan i analizy Morphisec, złośliwy plik był dystrybuowany przez legalną infrastrukturę aktualizacji (co zwykle bardziej przypomina klasyczne supply chain w stylu „zaufany update staje się wektorem ataku”).

Wniosek praktyczny: nawet jeśli organizacja „nie klika w linki” i ma twarde polityki, update pipeline dostawcy pozostaje krytycznym punktem ryzyka, który warto obejmować monitoringiem (np. allowlisting hash/certyfikatów + anomalia w zachowaniu procesu aktualizacji).


Podsumowanie / kluczowe wnioski

  • Incydent eScan to klasyczny atak na łańcuch dostaw, gdzie legalny kanał aktualizacji posłużył do dystrybucji malware w dniu 20 stycznia 2026 r.
  • Kluczową cechą kampanii jest blokowanie mechanizmu naprawy/aktualizacji (HOSTS + konfiguracja/rejestr eScan), co podnosi koszt i czas reakcji.
  • Najrozsądniejsze podejście: szybko ustalić ekspozycję, izolować podejrzane hosty, wykonać threat hunting po IOC, zablokować C2 i wdrożyć manualną ścieżkę remediation rekomendowaną przez vendor/partnerów badawczych.

Źródła / bibliografia

  1. BleepingComputer – potwierdzenie incydentu przez MicroWorld/eScan, symptomy, kontekst i odniesienia do analizy Morphisec. (BleepingComputer)
  2. Morphisec Threat Labs – „Threat Bulletin: Critical eScan Supply Chain Compromise” (łańcuch infekcji, IOC, persistence, remediation). (Morphisec)
  3. SC Media (SCWorld) – streszczenie incydentu i rekomendacje działań operacyjnych (threat hunting, blokady C2, ostrożność wobec certyfikatu). (SC Media)
  4. SecurityWeek – tło historyczne: kampania 2024 wykorzystująca mechanizm aktualizacji eScan (GuptiMiner, MitM). (SecurityWeek)

SolarWinds Web Help Desk: krytyczne luki (RCE i bypass uwierzytelniania) – co wiemy i jak zareagować

Wprowadzenie do problemu / definicja luki

SolarWinds załatał zestaw poważnych podatności w produkcie Web Help Desk (WHD) – systemie do obsługi zgłoszeń i zasobów IT. W praktyce jest to oprogramowanie, które często działa jako aplikacja serwerowa dostępna dla wielu użytkowników (czasem niestety także z Internetu), a więc stanowi atrakcyjny cel ataków.

W opublikowanych informacjach kluczowe są cztery podatności ocenione jako krytyczne (CVSS 9.8), obejmujące zdalne wykonanie kodu (RCE) bez uwierzytelnienia oraz obejście uwierzytelniania (auth bypass).


W skrócie

  • 4× krytyczne (9.8):
    • CVE-2025-40551 i CVE-2025-40553deserializacja niezaufanych danych → RCE bez logowania
    • CVE-2025-40552 i CVE-2025-40554bypass uwierzytelniania / wykonywanie akcji, które powinny wymagać logowania
  • Dodatkowo SolarWinds wymienia 2× „High” (m.in. hardcoded credentials) w tym samym wydaniu poprawek.
  • Rekomendowana poprawka: aktualizacja do WHD 2026.1; według Rapid7 podatne są wersje 12.8.8 Hotfix 1 i niższe.
  • Na 28 stycznia 2026 Rapid7 nie potwierdza „in-the-wild exploitation” dla tych nowych CVE, ale podkreśla historyczne zainteresowanie atakujących WHD.

Kontekst / historia / powiązania

Web Help Desk ma już „historię” podatności o wysokiej wadze, a to istotnie zmienia ocenę ryzyka: nawet jeśli nowa kampania nie jest jeszcze publicznie potwierdzona, to produkt był wcześniej atrakcyjnym celem.

  • Rapid7 wskazuje, że WHD pojawiał się w przeszłości na liście CISA Known Exploited Vulnerabilities (KEV).
  • BleepingComputer przypomina również o wcześniejszych obejściach poprawek oraz o przypadkach, gdy CISA wskazywała podatności WHD jako wykorzystywane w atakach.

Wniosek praktyczny: dla systemów helpdesk/ITSM ryzyko jest podwójne, bo poza przejęciem serwera atakujący często zyskuje też dostęp do bazy zgłoszeń, integracji, załączników oraz danych o infrastrukturze.


Analiza techniczna / szczegóły luki

CVE-2025-40551 oraz CVE-2025-40553 – RCE przez deserializację (unauth)

To klasyczny i groźny wzorzec: aplikacja deserializuje dane pochodzące od klienta, które nie są odpowiednio walidowane. Skutkiem może być zdalne wykonanie kodu / komend systemowych na hoście, i to bez uwierzytelnienia.

Z perspektywy obrońcy najgorsze elementy tego scenariusza to:

  • brak potrzeby posiadania konta,
  • potencjalnie „wysoka niezawodność” exploitacji typowa dla klas deserializacji (gdy istnieje odpowiedni łańcuch gadżetów),
  • szybkie uzbrajanie PoC, gdy detale techniczne trafią do obiegu.

CVE-2025-40552 oraz CVE-2025-40554 – obejście uwierzytelniania

Te dwie podatności opisano jako auth bypass, umożliwiający zdalnemu, nieuwierzytelnionemu atakującemu wykonywanie akcji/metod, które powinny być chronione logowaniem.

Co ważne, Rapid7 zwraca uwagę, że ocena CVSS sugeruje wpływ zbliżony do RCE – czyli w praktyce auth bypass może być ścieżką do wykonania kodu (np. przez wywołanie „nie tego” endpointu/akcji, która finalnie prowadzi do uruchomienia komendy lub deserializacji).

Dodatkowe „High” w pakiecie poprawek

Wydanie 2026.1 adresuje też m.in.:

  • CVE-2025-40536 – bypass kontroli bezpieczeństwa (8.1)
  • CVE-2025-40537hardcoded credentials (7.5), które w pewnych warunkach mogą ułatwiać dostęp do funkcji administracyjnych.

Praktyczne konsekwencje / ryzyko

Jeśli WHD jest osiągalny z sieci atakującego (Internet, sieć partnera, płaska sieć LAN, źle zabezpieczony VPN), typowy łańcuch skutków wygląda tak:

  • Przejęcie serwera WHD (RCE) → trwałość (webshell/usługa) → kradzież danych i ruch boczny
  • Dostęp do danych operacyjnych: zgłoszenia, dane użytkowników, integracje, tokeny, załączniki (często zawierające konfiguracje, logi, zrzuty ekranów, a czasem nawet hasła/API keys)
  • Możliwość użycia helpdesku do eskalacji organizacyjnej: podszywanie się, resetowanie haseł, manipulacja procesami wsparcia.

Podkreślmy: nawet jeśli „na dziś” (28 stycznia 2026) nie ma potwierdzonej masowej eksploatacji tych nowych CVE, historia WHD i jego typowa rola w firmie powodują, że to przypadek „patch fast”.


Rekomendacje operacyjne / co zrobić teraz

Priorytet 1: aktualizacja

  • Zaktualizuj do SolarWinds Web Help Desk 2026.1 (to wersja zawierająca poprawki dla CVE-2025-40551/40552/40553/40554).
  • Jeśli nie masz pewności, czy jesteś w grupie ryzyka: Rapid7 wskazuje, że podatne są 12.8.8 Hotfix 1 i niższe.

Priorytet 2: ograniczenie ekspozycji (gdy patchowanie nie jest natychmiast możliwe)

  • Zdejmij WHD z Internetu (jeśli jest publiczny) i wystawiaj wyłącznie przez VPN / ZTNA.
  • Ogranicz dostęp do panelu WHD na firewallu (allowlist IP, segmentacja).
  • Wymuś dodatkową warstwę uwierzytelniania przed WHD (reverse proxy + MFA), o ile architektura na to pozwala.

Priorytet 3: weryfikacja potencjalnej kompromitacji

  • Przejrzyj logi serwera aplikacji i reverse proxy pod kątem nietypowych żądań, błędów serializacji, podejrzanych sekwencji wywołań endpointów oraz anomalii czasowych.
  • Sprawdź, czy na hoście nie pojawiły się nowe pliki/artefakty (webshelle, nietypowe JAR/WAR, zadania harmonogramu, nowe usługi).
  • Jeśli WHD przechowuje/wykorzystuje sekrety (integracje, SMTP, API), rozważ rotację tych poświadczeń po aktualizacji.

Różnice / porównania z innymi przypadkami

W porównaniu do „typowych” podatności webowych (np. XSS/CSRF), obecny zestaw CVE jest groźniejszy z dwóch powodów:

  1. Brak uwierzytelnienia w ścieżkach prowadzących do RCE i wykonywania akcji uprzywilejowanych.
  2. Powtarzalność problemów w WHD (wcześniejsze obejścia poprawek, wzmianki o KEV i aktywnym wykorzystywaniu innych luk) – co w praktyce oznacza, że środowiska z WHD powinny być traktowane jak „wysoki priorytet” w backlogu podatności.

Podsumowanie / kluczowe wnioski

  • SolarWinds załatał w WHD cztery krytyczne luki (CVSS 9.8): dwie prowadzące do unauth RCE przez deserializację, dwie to auth bypass z potencjalnie porównywalnym wpływem.
  • Docelowa akcja: aktualizacja do WHD 2026.1 i potraktowanie jej jako pilnej, zwłaszcza jeśli WHD jest szeroko dostępny w sieci.
  • Nawet bez potwierdzonej eksploatacji „tu i teraz”, WHD jest produktem, który bywał celem ataków w przeszłości – dlatego warto równolegle wykonać kontrolę bezpieczeństwa po stronie hosta i logów.

Źródła / bibliografia

  • SolarWinds (release notes): WHD 2026.1 – lista naprawionych CVE, w tym CVE-2025-40551/40552/40553/40554 (documentation.solarwinds.com)
  • BleepingComputer: omówienie poprawek i kontekstu historycznego WHD (BleepingComputer)
  • Rapid7 (ETR): podsumowanie techniczne, wersje podatne, stan eksploatacji (Rapid7)
  • NVD: karta CVE-2025-40551 (opis, wektor CVSS 3.1, CWE-502) (NVD)
  • CISA KEV Catalog (wzmianka o wcześniejszej pozycji dot. SolarWinds WHD / hardcoded credential) (CISA)

Mustang Panda (HoneyMyte) rozwija CoolClient: nowe moduły kradzieży danych z przeglądarek i monitor schowka

Wprowadzenie do problemu / definicja luki

Chińsko-powiązana grupa szpiegowska znana jako Mustang Panda (w nomenklaturze części dostawców także HoneyMyte / Earth Preta / Bronze President) zaktualizowała swój backdoor CoolClient tak, aby skuteczniej wspierał kradzież danych uwierzytelniających i „życie z zasobów” (LOTL) w środowiskach ofiar. Najważniejsza zmiana: CoolClient nie jest już wyłącznie furtką do zdalnego dostępu, ale stał się platformą do wdrażania infostealerów (kradzież logowań z przeglądarek) oraz monitorowania schowka i aktywnego okna.


W skrócie

  • Nowy CoolClient potrafi monitorować schowek i śledzić tytuły aktywnych okien, a także podsłuchiwać poświadczenia do proxy HTTP.
  • W kampaniach zaobserwowano trzy rodziny stealerów: pod Chrome, Edge oraz wariant „uniwersalny” dla przeglądarek Chromium.
  • Eksfiltracja danych (np. cookies) może wykorzystywać legalne usługi (np. Google Drive) i tokeny/API wbudowane w operacje, co utrudnia detekcję po samym „dokąd wychodzi ruch”.
  • Cele kampanii to m.in. instytucje rządowe w kilku krajach Azji oraz poza nią (m.in. Myanmar, Mongolia, Malezja, Rosja, Pakistan).

Kontekst / historia / powiązania

CoolClient jest kojarzony z Mustang Panda co najmniej od 2022 r. i bywał wdrażany jako dodatkowa furtka obok innych znanych implantów tej klasy (np. PlugX, LuminousMoth).
Z perspektywy „rodziny” aktora warto pamiętać, że różni dostawcy opisywali go pod wieloma nazwami (np. Earth Preta), a kampanie często opierały się o spreparowane archiwa-przynęty i klasyczny spear-phishing.
W 2025 r. IBM X-Force wskazywał na szeroki arsenał i nakładające się klastry aktywności przypisywane temu ekosystemowi (m.in. ToneShell/Pubload oraz nowe techniki dystrybucji), co dobrze tłumaczy, dlaczego CoolClient jest dziś „rozbudowywany” zamiast zastępowany.


Analiza techniczna / szczegóły luki

1) Łańcuch uruchomienia i wieloetapowość (.DAT)

Z obserwacji badaczy wynika, że CoolClient korzysta z zaszyfrowanych plików .DAT i wieloetapowego wykonania. W opisie Kaspersky widoczny jest schemat, w którym implant:

  • odszyfrowuje kolejne artefakty (np. time.dat, loader.dat, main.dat),
  • uruchamia proces-pośrednik (write.exe) i wstrzykuje do niego kolejny etap,
  • buduje trwałość przez Run key, usługę systemową oraz zaplanowane zadanie.

2) Utrzymanie uprawnień i „passuac”

Warianty widziane w terenie wspierają obejście UAC i eskalację: przy sprzyjających warunkach uruchamiany jest tryb „passuac”, a następnie ustawiana jest trwałość przez zadanie harmonogramu.

3) Nowe funkcje: schowek, aktywne okno, sniffing proxy

Nowością w aktualnych wariantach jest:

  • monitor schowka (m.in. poprzez typowe API systemowe używane przez clipboard stealery),
  • telemetria aktywnego okna (np. tytuł okna),
  • HTTP proxy credential sniffer oparty o inspekcję pakietów i ekstrakcję nagłówków.

4) Ekosystem pluginów i zdalna powłoka

CoolClient utrzymuje architekturę z pluginami ładowanymi w pamięci, rozszerzoną m.in. o:

  • plugin zdalnej powłoki (ukryty cmd.exe, I/O przez potoki),
  • plugin zarządzania usługami (enumeracja, start/stop, modyfikacje),
  • rozbudowany plugin menedżera plików (mapowanie dysków sieciowych, kompresja ZIP, wyszukiwanie, uruchamianie plików).

5) Infostealery: Chrome/Edge/Chromium i eksfiltracja „przez legalne chmury”

W operacjach udokumentowano wdrażanie stealerów kradnących loginy z przeglądarek (różne warianty pod Chrome, Edge i Chromium-based).
Co istotne operacyjnie: w części przypadków eksfiltracja (np. pliki cookies) była wykonywana narzędziowo (np. przez curl) do legalnych usług typu Google Drive, z użyciem tokenów/kluczy wbudowanych w działania aktora, co utrudnia prostą blokadę na podstawie „złośliwej domeny”.

6) Dystrybucja: legalne oprogramowanie i DLL sideloading

BleepingComputer (na bazie ustaleń Kaspersky) wskazuje, że w obserwowanych atakach malware bywał wdrażany przez legalne komponenty związane z Sangfor, a wcześniej operatorzy uruchamiali CoolClient przez DLL side-loading z wykorzystaniem podpisanych binariów (np. popularne aplikacje użytkowe).

Uwaga „na radar”: badacze sygnalizują także użycie nieopisanego wcześniej rootkita w powiązaniu z tym zestawem narzędzi, ale szczegóły mają zostać opublikowane w osobnym raporcie.


Praktyczne konsekwencje / ryzyko

  • Kompromitacja tożsamości: kradzież haseł/cookies/sesji z przeglądarek to ryzyko przejęcia dostępu do poczty, SSO, paneli administracyjnych i narzędzi chmurowych.
  • Trudniejsza detekcja na poziomie sieci: eksfiltracja przez popularne legalne usługi (np. Google Drive) może „zniknąć w szumie” i wyglądać jak typowy ruch biznesowy.
  • Wysokie ryzyko post-exploitation: pluginy (shell, zarządzanie usługami, operacje na plikach) i techniki eskalacji/UAC sprzyjają długiej obecności w sieci i lateral movement.

Rekomendacje operacyjne / co zrobić teraz

  1. Ochrona poświadczeń i sesji
  • Włącz/egzekwuj MFA odporne na phishing (FIDO2/WebAuthn) dla kont uprzywilejowanych i dostępu do krytycznych SaaS.
  • Rotuj hasła i unieważnij sesje tam, gdzie wykryto anomalie przeglądarkowe (cookies/tokens).
  1. Detekcja na endpointach (EDR)
  • Poluj na nietypowe uruchomienia i wstrzyknięcia z udziałem procesów typu write.exe oraz aktywności wokół zaszyfrowanych .dat i nietypowych usług/zadań harmonogramu.
  • Monitoruj wywołania związane ze schowkiem oraz pobieranie danych logowania z profili przeglądarek (szczególnie w kontekście narzędzi typu curl).
  1. Kontrola ruchu do usług chmurowych
  • Nie blokuj „w ciemno” Google Drive, ale wdrażaj CASB / DLP / polityki uploadu dla stacji i kont uprzywilejowanych (kto, co i skąd wysyła pliki).
  • W proxy/secure web gateway ustaw alerty na masowe uploady i podejrzane nagłówki autoryzacji w nietypowych kontekstach (np. curl na stacjach użytkowników).
  1. Higiena oprogramowania i odporność na sideloading
  • Ogranicz uruchamianie nieautoryzowanych binariów (AppLocker/WDAC), zwłaszcza z katalogów użytkownika i ścieżek tymczasowych.
  • Waliduj łańcuch dostaw: jeśli w środowisku jest oprogramowanie wykorzystywane do „legitymizacji” uruchomienia, przejrzyj modele dystrybucji i podpisy/hashe.

Różnice / porównania z innymi przypadkami

W wielu kampaniach APT backdoor służy głównie do zdalnego sterowania i pobierania kolejnych modułów. Tu widać przesunięcie akcentu: CoolClient staje się platformą do kradzieży tożsamości (infostealery, schowek, proxy sniffing) oraz do eksfiltracji „pod przykrywką” legalnych usług.
Na tle wcześniejszych opisów Earth Preta/Mustang Panda (phishing, archiwa-przynęty, szeroki arsenał) to spójna ewolucja: mniej hałaśliwe domeny C2 w warstwie eksfiltracji, większy nacisk na dostęp przez konta i sesje.


Podsumowanie / kluczowe wnioski

CoolClient w najnowszych kampaniach Mustang Panda/HoneyMyte to już nie tylko „backdoor”, ale modułowa platforma post-exploitation z funkcjami typowymi dla wyspecjalizowanych złodziei danych (schowek, przeglądarki, proxy) i z mechanizmami utrzymania dostępu (usługi, taski, obejście UAC). Priorytet obrony powinien przesunąć się na ochronę tożsamości (MFA/FIDO2), telemetry EDR wokół przeglądarek i narzędzi transferu, oraz kontrolę uploadów do legalnych chmur.


Źródła / bibliografia

  1. BleepingComputer – opis kampanii i podsumowanie zmian w CoolClient (27 stycznia 2026). (BleepingComputer)
  2. Kaspersky Securelist (GReAT) – analiza techniczna CoolClient i stealerów (27 stycznia 2026). (Securelist)
  3. Trend Micro – tło dot. Earth Preta/Mustang Panda i taktyk kampanii (2023). (www.trendmicro.com)
  4. IBM X-Force – kontekst dot. Hive0154/Mustang Panda, arsenału i technik dystrybucji (2025). (IBM)

WinRAR: podatność path traversal CVE-2025-8088 nadal masowo wykorzystywana — jak działa łańcuch ataku i co zrobić teraz

Wprowadzenie do problemu / definicja luki

CVE-2025-8088 to podatność typu path traversal w WinRAR dla Windows, która pozwala atakującym zapisać pliki poza katalogiem wskazanym przez użytkownika podczas rozpakowywania. W praktyce oznacza to możliwość „podrzucenia” złośliwego pliku w lokalizacji uruchamianej automatycznie (np. Windows Startup) i uzyskania wykonania kodu przy spełnieniu warunku interakcji użytkownika (otwarcie/rozpakowanie spreparowanego archiwum).

Co ważne: chociaż poprawka jest dostępna od lipca 2025, najnowsze raporty pokazują, że luka jest nadal intensywnie wykorzystywana przez wiele grup — od aktorów państwowych po cyberprzestępców „commodity”.


W skrócie

  • Co to jest: path traversal w WinRAR/UnRAR na Windows (CWE-35).
  • Jak jest wykorzystywane: przez Alternate Data Streams (ADS) na NTFS do ukrycia i wypakowania payloadu w niezamierzone miejsce (często Startup).
  • Kogo dotyczy: WinRAR/UnRAR i komponenty na Windows (m.in. UnRAR.dll) — platformy Linux/Unix i Android nie są dotknięte.
  • Status: aktywna eksploatacja obserwowana od 18 lipca 2025 i nadal trwająca (raporty z 27 stycznia 2026).
  • Mitigacja: aktualizacja do WinRAR 7.13+ oraz przegląd zależności (UnRAR.dll) w innych produktach.

Kontekst / historia / powiązania

Podatność została wykryta i zgłoszona przez badaczy ESET, a WinRAR opublikował poprawkę w linii 7.13 (wersja final 30.07.2025; notki aktualizowane 12.08.2025).

W styczniu 2026 Google Threat Intelligence Group (GTIG) opisał problem jako klasyczny przykład „n-day”, który mimo dostępnej łatki pozostaje skuteczny, bo:

  • użytkownicy często nie aktualizują WinRAR (brak automatycznych aktualizacji w typowych wdrożeniach),
  • a wektor „archiwum + socjotechnika” jest tani i powtarzalny dla wielu grup.

Analiza techniczna / szczegóły luki

Mechanizm: path traversal + ADS (NTFS)

CVE-2025-8088 wykorzystuje Alternate Data Streams (ADS) — cechę NTFS pozwalającą dołączać „strumienie” danych do pliku w sposób mało widoczny dla użytkownika. Atakujący przygotowuje archiwum tak, aby zawierało plik-przynętę (np. dokument), a właściwy payload był ukryty w ADS.

Następnie, podczas podglądu/otwarcia pliku z archiwum lub rozpakowywania, WinRAR:

  1. rozpakowuje plik-przynętę (żeby ofiara widziała „normalny” dokument),
  2. równolegle rozpakowuje ADS-y, a dzięki obejściu ścieżki docelowej może je zrzucić poza wybrany katalog.

Typowe payloady i post-exploitation

W obserwowanych kampaniach wypakowywane były m.in. LNK, HTA, BAT, CMD i inne skrypty/artefakty, które uruchamiają kolejne etapy infekcji (np. przy logowaniu). Szczególnie atrakcyjny jest zrzut do Windows Startup folder — daje to persistence „bez fajerwerków”.

Ocena ryzyka (NVD)

NVD opisuje podatność jako umożliwiającą wykonanie dowolnego kodu po spreparowaniu archiwum i interakcji użytkownika; wektor CVSS v3.1 wskazuje m.in. UI:R (wymagana akcja użytkownika), ale z pełnym wpływem na poufność/integralność/dostępność.


Praktyczne konsekwencje / ryzyko

Największe ryzyko wynika z połączenia trzech czynników:

  1. Masowość: raporty z 27.01.2026 mówią o wielu aktorach i różnych ładunkach (od RAT-ów po stealery).
  2. „Niewidzialność” dla użytkownika: ofiara widzi poprawny dokument, a złośliwe ADS-y są „w tle”.
  3. Persistence bez exploitów kernelowych: zrzut do Startup daje trwałość po restarcie/logowaniu.

GTIG wskazuje, że oprócz grup powiązanych z państwami (m.in. obserwowane operacje przypisywane aktorom powiązanym z Rosją/Chinami), podatność jest wykorzystywana także przez cyberprzestępców do dystrybucji popularnych narzędzi zdalnego dostępu i stealerów (np. AsyncRAT, XWorm).


Rekomendacje operacyjne / co zrobić teraz

1) Aktualizacja i inwentaryzacja (najważniejsze)

  • Zaktualizuj WinRAR do 7.13 lub nowszej.
  • Zidentyfikuj, gdzie w organizacji występują komponenty UnRAR.dll / UnRAR (często są „zagnieżdżone” w innych aplikacjach, instalatorach, narzędziach backupowych) i zaktualizuj zależności.

2) Ogranicz skutki socjotechniki

  • Blokuj/izoluj archiwa z nieznanych źródeł (brama mailowa, sandbox).
  • Wrażliwe zespoły (finanse, HR, logistyka, zarząd) — dodatkowe reguły dla załączników RAR/ZIP, zwłaszcza w kampaniach spearphishing. (To wpisuje się w obserwowany model ataku opisany przez ESET/GTIG).

3) Hardening punktów uruchomieniowych

  • Monitoruj i ogranicz możliwość zapisu do lokalizacji persistence, w szczególności ścieżek powiązanych z Startup.
  • Zaostrz polityki uruchamiania dla LNK/HTA/skryptów z katalogów użytkownika i TEMP (SRP/AppLocker/WDAC — zależnie od środowiska).

4) Detekcja i hunting

  • Wykorzystaj informacje i IOCs opublikowane przez GTIG do polowań (jeśli prowadzisz threat hunting / SOC).
  • Koreluj zdarzenia: rozpakowanie archiwum → powstanie plików typu LNK/HTA/BAT/CMD w nietypowych ścieżkach → uruchomienie przy logowaniu.

Różnice / porównania z innymi przypadkami

WinRAR podkreśla, że CVE-2025-8088 jest odrębna od wcześniejszej podatności naprawionej w 7.12.
ESET dodatkowo wskazuje podobną podatność path traversal CVE-2025-6218 ujawnioną około miesiąc wcześniej (czerwiec 2025), co pokazuje, że klasa błędów w obsłudze ścieżek i archiwów była w tym okresie szczególnie „gorąca” i atrakcyjna dla atakujących.


Podsumowanie / kluczowe wnioski

  • CVE-2025-8088 to praktyczny, „wdzięczny” exploit chain: archiwum + ADS + path traversal → zrzut do Startup → persistence → dalsza infekcja.
  • Najnowsze dane (27.01.2026) potwierdzają ciągłą eksploatację przez szeroki przekrój aktorów.
  • Największym problemem nie jest brak patcha, tylko opóźnione aktualizacje i „ukrycie” zależności (UnRAR.dll) w innych produktach.

Źródła / bibliografia

  1. BleepingComputer — „WinRAR path traversal flaw still exploited by numerous hackers” (27.01.2026). (BleepingComputer)
  2. Google Threat Intelligence Group — „Diverse Threat Actors Exploiting Critical WinRAR Vulnerability CVE-2025-8088” (27.01.2026). (Google Cloud)
  3. NVD (NIST) — wpis podatności CVE-2025-8088. (NVD)
  4. RARLAB / win-rar.com — „WinRAR 7.13 Final released” (release notes + zakres wpływu). (WinRAR download free and support)
  5. ESET WeLiveSecurity — „Update WinRAR tools now: RomCom and others exploiting zero-day vulnerability” (analiza ADS i timeline). (welivesecurity.com)

Ponad 6 tys. serwerów SmarterMail narażonych na automatyczne przejęcia kont admina (CVE-2026-23760)

Wprowadzenie do problemu / definicja luki

SmarterMail (serwer pocztowy i platforma współpracy od SmarterTools) znalazł się na celowniku masowych, zautomatyzowanych ataków po ujawnieniu krytycznej luki CVE-2026-23760. Błąd pozwala bez uwierzytelnienia przejąć konto administratora poprzez nieprawidłowo zaprojektowane API resetu hasła, a następnie – dzięki wbudowanym funkcjom administracyjnym – doprowadzić do zdalnego wykonania poleceń na hoście (RCE).

Równolegle organizacje typu Shadowserver raportowały tysiące instancji wystawionych do internetu, które wyglądały na podatne, a analitycy obserwowali już ataki „in the wild”.


W skrócie

  • CVE-2026-23760: obejście uwierzytelnienia w API resetu hasła; dotyczy wersji przed build 9511.
  • Wektor: POST /api/v1/auth/force-reset-password akceptuje żądania anonimowe i w krytycznej ścieżce dla sysadmina nie weryfikuje starego hasła / tokenu resetu.
  • Skutek: przejęcie konta admina → szybka eskalacja do RCE/SYSTEM przez funkcje administracyjne (np. wykonywanie komend).
  • Eksploatacja była obserwowana masowo i automatycznie (sekwencje żądań API, tworzenie „System Events”, sprzątanie śladów).
  • Skala: raportowano >6 000 publicznie dostępnych serwerów potencjalnie narażonych.

Kontekst / historia / powiązania

CVE-2026-23760 wypłynęło krótko po innej krytycznej luce w SmarterMail (CVE-2025-52691), co podbiło zainteresowanie atakujących (i presję na zespoły IT). BleepingComputer opisał sytuację jako serię zdarzeń: zgłoszenie, szybka poprawka, a następnie szybka adaptacja eksploitu i skanowanie internetu w poszukiwaniu podatnych serwerów.

Istotny kontekst operacyjny: w przypadku serwerów pocztowych ekspozycja na internet jest często „z definicji” (webmail, panel admina, API), więc okno czasowe między patchem a masową eksploatacją bywa wyjątkowo krótkie. SecurityWeek cytował watchTowr, że poprawka została szybko przeanalizowana (reverse engineering) i zaczęła być wykorzystywana na szeroką skalę.


Analiza techniczna / szczegóły luki

1) Root cause: reset hasła admina bez dowodu tożsamości

watchTowr opisał problem jako błąd w logice resetu hasła: endpoint force-reset-password jest dostępny anonimowo (co samo w sobie bywa normalne dla resetów), ale ścieżka dla kont sysadmin pozwala podać Username i NewPassword bez weryfikacji OldPassword lub tokenu resetu.

W praktyce: jeśli atakujący zna (lub zgadnie) nazwę konta administratora (często „admin”), może zresetować hasło i zalogować się jako administrator.

2) Od przejęcia konta do RCE – dwie obserwowane ścieżki

  • Ścieżka A (watchTowr): po przejęciu sysadmina możliwe jest doprowadzenie do wykonania poleceń systemowych przez wbudowane funkcje administracyjne (watchTowr opisał drogę przez ustawienia i mechanizm, który finalnie uruchamia komendę na hoście).
  • Ścieżka B (Huntress): w atakach „in the wild” widziano użycie funkcji System Events – napastnik po zdobyciu tokena dostępu tworzył złośliwy event-hook, wyzwalał go (np. dodaniem domeny), a potem wykonywał działania porządkowe (kasowanie domeny i hooka).

3) Sygnały masowej automatyzacji

Huntress pokazał typową sekwencję żądań API obserwowaną u wielu ofiar w krótkich odstępach czasu (co wygląda na automatyczne skrypty), zaczynając od wymuszenia resetu hasła, potem autoryzacji i konfiguracji mechanizmów do wykonania komend.


Praktyczne konsekwencje / ryzyko

Przejęty serwer SmarterMail to zwykle „klucz do królestwa” poczty:

  • dostęp do skrzynek, korespondencji i danych wrażliwych,
  • możliwość podszywania się (phishing/BEC), reguły przekierowań, utrwalanie dostępu,
  • infrastruktura do dalszych ataków (malware, pivot w sieci, kradzież poświadczeń),
  • ryzyko incydentu zgodności (RODO), reputacji i ciągłości działania.

NVD wprost wskazuje, że uprawnienia sysadmina w SmarterMail mogą przekładać się na administracyjne uprawnienia na hoście (SYSTEM/root) dzięki wbudowanym funkcjom zarządzania – co z perspektywy IR oznacza traktowanie takiego zdarzenia jak pełne przejęcie serwera.


Rekomendacje operacyjne / co zrobić teraz

1) Patch i weryfikacja wersji

  • Zaktualizuj do build 9511 lub nowszego (wszystko „przed 9511” jest wprost wskazywane jako podatne).

2) Jeśli nie możesz zaktualizować natychmiast (awaryjnie)

  • ogranicz dostęp do panelu/web API (VPN/allowlista IP, przynajmniej dla interfejsu administracyjnego),
  • rozważ tymczasowe reguły reverse proxy/WAF ograniczające dostęp do ścieżek API resetu hasła (uwaga: to obejście, nie „fix”),
  • włącz monitoring anomalii na endpointach /api/v1/auth/* i akcjach administracyjnych.

3) „Assume breach” – szybkie polowanie i IR

Szukaj w logach (proxy / aplikacyjnych) nietypowych żądań:

  • POST /api/v1/auth/force-reset-password oraz dalszych sekwencji API,
  • tworzenia/edycji System Events / event-hooków i operacji dodania/usunięcia domen (pattern z Huntress).

IOCs/sygnały (wg Huntress):

  • powtarzające się, szybkie sekwencje żądań API,
  • user-agent python-requests/2.32.4 widziany w atakach,
  • artefakt plikowy wskazywany w analizie Huntress (plik z wynikami rozpoznania).

4) Higiena po incydencie

  • reset haseł kont uprzywilejowanych (i rotacja kluczy/sekretów, jeśli serwer miał dostęp do innych systemów),
  • przegląd reguł przekazywania poczty, integracji i webhooków,
  • sprawdzenie trwałości (scheduled tasks, usługi, web-shelle, nieznane binaria),
  • segmentacja i minimalizacja ekspozycji usług zarządzających.

Różnice / porównania z innymi przypadkami

Warto odróżnić dwie głośne luki SmarterMail z przełomu stycznia:

  • CVE-2026-23760 – „czyste” przejęcie admina przez reset hasła bez weryfikacji (API), a potem RCE jako konsekwencja uprawnień admina i funkcji administracyjnych.
  • CVE-2025-52691 – wcześniejsza, krytyczna podatność pre-auth (opisywana jako droga do RCE na niezałatanych serwerach), wspominana w kontekście tej fali ataków.

Operacyjnie: w CVE-2026-23760 kluczowe jest, że atakujący może „wejść drzwiami frontowymi” jako admin (zmieniając hasło), co utrudnia detekcję, jeśli organizacja monitoruje wyłącznie klasyczne wskaźniki exploitów RCE.


Podsumowanie / kluczowe wnioski

  • CVE-2026-23760 to krytyczny błąd projektowy w API resetu hasła, który umożliwia przejęcie konta sysadmina i w praktyce prowadzi do pełnego kompromisu serwera.
  • Skala ekspozycji jest duża (tysiące instancji wystawionych do internetu), a eksploatacja była obserwowana jako zautomatyzowana.
  • Najważniejsze działania: aktualizacja do build 9511+, ograniczenie ekspozycji panelu/API oraz szybkie threat hunting pod kątem sekwencji API i nadużyć System Events.

Źródła / bibliografia

  • BleepingComputer – o skali ekspozycji i trwających atakach (BleepingComputer)
  • NVD (NIST) – opis CVE-2026-23760, wersje podatne, charakter wpływu (NVD)
  • watchTowr Labs – analiza techniczna root cause i PoC dla force-reset-password (watchTowr Labs)
  • Huntress – obserwacje ataków „in the wild”, sekwencje API i IOCs (Huntress)
  • SecurityWeek – kontekst masowej eksploatacji i mechaniki nadużyć (SecurityWeek)

Krytyczna luka „sandbox escape” w vm2 dla Node.js (CVE-2026-22709) – jak działa i co zrobić natychmiast

Wprowadzenie do problemu / definicja luki

vm2 to popularna biblioteka do uruchamiania niezaufanego JavaScriptu w „piaskownicy” (sandboxie) w środowisku Node.js. Jej typowy cel to umożliwienie wykonywania kodu użytkownika bez dostępu do systemu plików czy API hosta.

W praktyce okazało się, że w vm2 wykryto krytyczną podatność typu sandbox escape oznaczoną jako CVE-2026-22709. Pozwala ona napastnikowi uciec z izolacji i wykonać dowolny kod na hoście (RCE) – czyli dokładnie złamać fundamentalne założenie „bezpiecznej piaskownicy”.


W skrócie

  • Identyfikator: CVE-2026-22709
  • Wektor: obejście mechanizmu sanitizacji callbacków dla Promise.then() / Promise.catch()
  • Skutek: sandbox escape → RCE na hoście
  • Wersje podatne: vm2 przed 3.10.2
  • Naprawa: aktualizacja do ≥ 3.10.2 (w praktyce najlepiej do najnowszej wersji z gałęzi 3.10.x)
  • Ocena ryzyka: CVSS 9.8 (Critical) wg CNA (GitHub)

Kontekst / historia / powiązania

vm2 jest szeroko używane m.in. w platformach SaaS pozwalających użytkownikom uruchamiać własne skrypty, runnerach kodu online czy botach/czatbotach. BleepingComputer podaje skalę użycia rzędu 200k+ projektów na GitHub oraz około ~1 mln pobrań tygodniowo w npm.

Jednocześnie vm2 ma historię kolejnych ucieczek z sandboxa. W 2023 r. głośne były m.in. CVE-2023-29017 oraz CVE-2023-30547 – obie klasy „sandbox escape”.
Według BleepingComputer projekt był nawet wstrzymany w 2023 r. z powodu powtarzających się problemów, a później „wskrzeszony” (powrót rozwoju i wersji 3.10.x).


Analiza techniczna / szczegóły luki

Sedno problemu to niekonsekwentna sanitizacja callbacków przypinanych do obietnic (Promises):

  • vm2 sanitizuje callbacki dla swojej „lokalnej” implementacji obietnic (w uproszczeniu: localPromise.prototype.then),
  • ale nie obejmuje tym samym mechanizmem „globalnych” Promise (tj. globalPromise.prototype.then),
  • a ponieważ wartości zwracane z async funkcji są oparte o globalny Promise, atakujący może doprowadzić do wykonania callbacka w sposób umożliwiający wyrwanie się do kontekstu hosta.

W praktyce publicznie pokazano PoC, w którym poprzez manipulację obsługą błędu i uzyskanie dostępu do konstruktorów (np. Function) da się finalnie doprowadzić do uruchomienia polecenia systemowego na hoście (np. przez child_process).

Status poprawek (ważne operacyjnie):

  • wg maintenera podatność była częściowo zaadresowana w 3.10.1,
  • a 3.10.2 „domknęło” fix tak, aby uniknąć możliwego obejścia.

Praktyczne konsekwencje / ryzyko

Jeśli Twoja aplikacja używa vm2 do uruchamiania jakiegokolwiek kodu pochodzącego od użytkownika lub z nie w pełni zaufanego źródła, konsekwencje mogą obejmować:

  • przejęcie serwera/aplikacji (RCE),
  • kradzież sekretów (zmienne środowiskowe, tokeny CI/CD, klucze API),
  • pivot do sieci wewnętrznej,
  • modyfikację danych i łańcuchy ataków supply chain (np. modyfikacja artefaktów build).

Co istotne: wektor CVSS wskazuje m.in. AV:N oraz brak wymogu uprawnień i interakcji użytkownika (wg CNA/GitHub), co w praktyce oznacza, że scenariusze zdalne są realne w wielu wdrożeniach.


Rekomendacje operacyjne / co zrobić teraz

  1. Zrób szybki inventory zależności
    • Sprawdź, czy vm2 jest zależnością bezpośrednią lub transytywną (np. npm ls vm2, SBOM, skan SCA).
  2. Zaktualizuj vm2 do wersji bezpiecznej
    • Minimum ≥ 3.10.2 (a najlepiej do najnowszej wersji w 3.10.x).
  3. Jeśli nie możesz zaktualizować „tu i teraz” – załóż, że sandbox jest zawodny
    • Uruchamiaj niezaufany kod w oddzielnym procesie/serwisie z twardą izolacją (kontener/VM), bez dostępu do sekretów i z minimalnymi uprawnieniami.
    • Ogranicz egress (firewall), włącz profile typu AppArmor/SELinux/seccomp tam, gdzie to możliwe.
  4. Wdróż detekcję i kontrolę ryzyka
    • Monitoruj anomalie procesów (uruchomienia node, sh, bash, child_process), nietypowe połączenia sieciowe, zmiany plików.
  5. Rozważ alternatywę architektoniczną
    • Jeśli Twoim wymaganiem jest uruchamianie niezaufanego kodu, traktuj vm2 jako element wysokiego ryzyka i preferuj podejścia „defense-in-depth” (izolacja na poziomie OS, osobny worker pool, sandboxing poza jednym procesem Node). Kontekst „wracających ucieczek” w vm2 jest dobrze udokumentowany.

Różnice / porównania z innymi przypadkami

  • CVE-2026-22709 dotyczy wprost Promises i sanitizacji callbacków (then/catch) oraz różnicy między promise „lokalnym” a „globalnym” w kontekście async.
  • Wcześniejsze głośne podatności (np. CVE-2023-29017, CVE-2023-30547) również prowadziły do sandbox escape, ale wynikały z innych mechanizmów (np. obsługa wyjątków / sanitizacja wyjątków).

Wniosek praktyczny: nawet jeśli „załataliście” jedną klasę bypassu, model zagrożeń dla vm2 powinien zakładać kolejne obejścia, dlatego izolacja warstwowa (process/container/VM) jest kluczowa.


Podsumowanie / kluczowe wnioski

  • CVE-2026-22709 to krytyczny sandbox escape w vm2, umożliwiający RCE na hoście.
  • Podatne są wersje przed 3.10.2; fix został domknięty w 3.10.2.
  • Jeśli vm2 obsługuje kod użytkownika lub dane, które mogą zostać „przemycone” do wykonywanego JS, priorytetem jest natychmiastowy upgrade i izolacja defense-in-depth.

Źródła / bibliografia

  1. BleepingComputer – opis podatności, kontekst popularności i historia vm2 (BleepingComputer)
  2. NVD (NIST) – rekord CVE-2026-22709 i opis mechanizmu podatności (NVD)
  3. GitHub Advisory Database – GHSA-99p7-6v5w-7xg8, metryki i techniczne detale/PoC (GitHub)
  4. Semgrep Blog – omówienie ryzyka i rekomendacja aktualizacji do 3.10.2 (semgrep.dev)
  5. Snyk Vulnerability Database – widok wersji i statusu podatności w najnowszych wydaniach (VulnInfo Guide)