Eksploit na „ESXicape”: dlaczego to, iż powstał ponad rok przed ujawnieniem, powinno martwić każdego admina VMware

securitybeztabu.pl 2 dni temu

Wprowadzenie do problemu / definicja luki

W marcu 2025 r. VMware (Broadcom) opublikował poprawki na trzy podatności w ESXi/Workstation/Fusion (CVE-2025-22224, CVE-2025-22225, CVE-2025-22226), które były wykorzystywane „in the wild”.

W styczniu 2026 r. analiza incydentu opisana przez Huntress dorzuciła bardzo niepokojący szczegół: narzędzia użyte do ucieczki z maszyny wirtualnej (VM escape) wyglądały na przygotowane ponad rok przed publicznym ujawnieniem tych CVE (na podstawie ścieżek PDB i znaczników czasowych w binariach).

Mówimy więc nie tylko o „kolejnych CVE”, ale o praktycznym scenariuszu: atakujący, po zdobyciu dostępu do jednej VM z uprawnieniami admina, potrafi przejść na poziom hypervisora ESXi i zagrozić wszystkim workloadom na hoście.

W skrócie

Podatności: CVE-2025-22224 (TOCTOU/OOB write), CVE-2025-22225 (arbitrary write → escape do kernela), CVE-2025-22226 (OOB read → leak).
Warunek: atak wymaga lokalnych uprawnień administracyjnych w VM (czyli najpierw trzeba skompromitować środowisko).
Huntress: w obserwowanym łańcuchu wejście miało nastąpić przez skompro-mitowany SonicWall VPN, potem nadużycie konta Domain Admin i dopiero wdrożenie toolkitu do ucieczki z VM.
Największy „red flag”: komponenty toolkitu wskazywały na prace rozwojowe co najmniej od listopada 2023 i „deliverable” z lutego 2024.

Kontekst / historia / powiązania

Oficjalne advisory Broadcom (VMSA-2025-0004) jasno mówi, iż VMware ma informacje sugerujące aktywną eksploatację wszystkich trzech CVE oraz iż nie ma obejść (workarounds) — najważniejsze są aktualizacje do wersji naprawionych.

Co istotne, rządowe instytucje ostrzegawcze też potraktowały temat poważnie — np. kanadyjskie Cyber Centre wprost wskazało, iż „exploit exists in the wild” dla tej trójki CVE.

Z perspektywy obrony oznacza to jedno: choćby jeżeli te luki nie są zdalnym RCE „z internetu”, to w realnych kampaniach są używane jako eskalacja na poziom hypervisora po wcześniejszym przełamaniu perymetru.

Analiza techniczna / szczegóły luki

1) Co dokładnie łata VMSA-2025-0004?

Broadcom opisuje:

CVE-2025-22224: TOCTOU prowadzące do out-of-bounds write (krytyczne; maks. CVSS 9.3).
CVE-2025-22225: arbitrary write w ESXi; zapis w jądrze przez VMX prowadzący do escape z sandboxa.
CVE-2025-22226: out-of-bounds read w HGFS skutkujące wyciekiem pamięci z procesu VMX.

NVD podkreśla najważniejszy element modelu ataku dla CVE-2025-22224: wykonanie kodu jako proces VMX na hoście, przy założeniu lokalnych uprawnień admina w VM.

2) Jak wyglądał łańcuch ataku według Huntress?

Huntress opisał wieloetapową operację, w której:

atakujący wdraża narzędzia na Windowsowej VM,
używa komponentów do obejścia/wyłączenia wybranych mechanizmów (m.in. techniki związane z ładowaniem sterowników),
uruchamia „orchestrator” (opisywany jako MAESTRO) do VM escape,
a następnie instaluje backdoora na ESXi komunikującego się przez VSOCK (Virtual Sockets), z nasłuchem na porcie 10000 i kanałem trudnym do obserwacji przez klasyczne narzędzia sieciowe.

To ostatnie jest szczególnie ważne operacyjnie: VSOCK omija typowe punkty kontroli (firewall/IDS w sieci), więc detekcja przesuwa się z „patrzmy na pakiety” na „patrzmy na procesy i sockety na hoście ESXi”. Huntress sugeruje m.in. obserwację nietypowych procesów i użycie poleceń typu lsof -a na hostach ESXi do wypatrywania śladów VMCI/VSOCK.

3) Skąd wniosek o „ponad rok przed ujawnieniem”?

Tu nie chodzi o spekulację „ktoś mógł mieć 0-day”, tylko o artefakty w binariach:

ścieżki PDB i nazewnictwo katalogów sugerujące „deliverable” dla „all version escape” oraz datę luty 2024,
komponent VSOCK związany z pracami z listopada 2023.

W praktyce oznacza to, iż exploit (albo przynajmniej platforma eksploatacyjna + post-exploitation) mógł być gotowy, zanim vendor opublikował advisory.

Praktyczne konsekwencje / ryzyko

„VM isolation is not absolute” przestaje być hasłem z prezentacji, a staje się realnym scenariuszem incydentu: kompromitacja jednej VM może przełożyć się na przejęcie hosta ESXi i wszystkich maszyn na nim.
Atak nie musi zaczynać się „od VMware”. W opisywanym przypadku wejście miało być przez urządzenie VPN, a VMware było „drugim krokiem” do osiągnięcia dominacji w środowisku wirtualizacji.
Ryzyko rośnie, gdy:

trzymasz wiele krytycznych workloadów na jednym hoście (duży „blast radius”),
masz słabą separację ról (admin VM ≈ admin wszystkiego),
używasz end-of-life wersji ESXi — Huntress zwraca uwagę, iż toolkit obejmował bardzo szeroki przekrój buildów, a EOL oznacza brak poprawek.

Rekomendacje operacyjne / co zrobić teraz

Priorytet 1: poprawki i inwentaryzacja

Zweryfikuj podatność względem VMSA-2025-0004 i wgraj wersje naprawione wskazane w „Response Matrix” (dla ESXi/Workstation/Fusion/Cloud Foundation/Telco).
Jeśli masz ESXi w wersjach EOL: potraktuj to jako ryzyko nieakceptowalne (brak fixów) i planuj migrację/upgrade.

Priorytet 2: zmniejsz szanse na „local admin w VM”

Ponieważ warunkiem jest admin w VM, w praktyce bronisz się tak samo jak przed ransomware:

MFA i hardening na VPN/edge, szybkie łatanie urządzeń brzegowych,
redukcja uprawnień Domain Admin, segmentacja, ograniczenie RDP/WinRM,
monitorowanie nietypowych zmian zasad zapory w VM i prób „odcięcia” ruchu na zewnątrz (w opisywanym ataku modyfikowano firewall).

Priorytet 3: detekcja na ESXi (nie tylko w sieci)

Włącz i centralizuj logi ESXi, monitoruj procesy i nietypowe binaria na datastore.
Uwzględnij w playbookach, iż kanały typu VSOCK mogą być niewidoczne dla klasycznych sensorów NDR — potrzebujesz telemetrii hostowej.

Różnice / porównania z innymi przypadkami

W przeciwieństwie do typowych podatności „remote RCE w vCenter/ESXi”, tutaj punkt ciężkości to escape z gościa do hosta: nie wystarczy „patchuj wystawione na internet”, bo atak może przyjść z wnętrza (po phishingu/VPN/AD).
To także przykład, iż informacja „exploited in the wild” w advisory bez detali (co często się zdarza) może oznaczać znacznie więcej niż skanowanie — Huntress pokazał dopracowany łańcuch i zaplecze narzędziowe.

Podsumowanie / najważniejsze wnioski

CVE-2025-22224/22225/22226 to nie „kolejne CVE do backlogu”, tylko zestaw luk, które umożliwiają realny VM escape i przejęcie hypervisora w scenariuszu po naruszeniu perymetru.
Najbardziej niepokojący sygnał z analizy Huntress: exploit/toolkit mógł istnieć jako 0-day ponad rok przed publicznym ujawnieniem.
Obrona wymaga dwóch równoległych działań: agresywnego patchowania ESXi oraz ograniczania prawdopodobieństwa, iż atakujący kiedykolwiek uzyska „admin w VM” (VPN/AD/endpoint).