Wprowadzenie do problemu / definicja luki
W połowie lutego 2026 r. ujawniono, iż podejrzewany o powiązania z Chinami klaster UNC6201 od co najmniej połowy 2024 r. wykorzystywał krytyczną lukę typu zero-day w Dell RecoverPoint for Virtual Machines (RP4VM) – rozwiązaniu do ochrony, replikacji i odtwarzania maszyn wirtualnych VMware.
Podatność otrzymała identyfikator CVE-2026-22769 i wynika z zastosowania twardo zakodowanych poświadczeń (hardcoded credentials). W praktyce oznacza to, iż atakujący (po poznaniu stałego sekretu) może uzyskać nieautoryzowany dostęp do systemu operacyjnego urządzenia/appliance i utrwalić uprawnienia root.
W skrócie
- Co? Hardcoded credentials w Dell RP4VM → potencjalny zdalny, nieautoryzowany dostęp i root persistence.
- Kto? UNC6201 (chińsko-powiązany klaster śledzony przez Google/Mandiant).
- Od kiedy? Wykorzystanie w atakach od mid-2024, ujawnienie publiczne: 2026-02-17/18.
- Skutki? Instalacja backdoorów (m.in. BRICKSTORM, później GRIMBOLT), ruch boczny i długotrwała obecność w środowisku.
- Co robić? Pilnie zaktualizować do 6.0.3.1 HF1 albo zastosować skrypt remediacyjny Dell oraz ograniczyć dostęp sieciowy do RP4VM.
Kontekst / historia / powiązania
Google Threat Intelligence Group oraz Mandiant opisują UNC6201 jako aktora wykorzystującego RP4VM do utrzymania dostępu i dalszej penetracji infrastruktury – w tym pivotowania do warstwy wirtualizacji. W raporcie zwrócono uwagę na powiązania/analogie do aktywności chińsko-nexusowych grup utrzymujących długi „dwell time” w sieciach ofiar.
Co istotne: podatność była eksploatowana „po cichu” przez wiele miesięcy, zanim trafiła do publicznych advisory (Dell opublikował DSA-2026-079 z datą 2026-02-17).
Analiza techniczna / szczegóły luki
1) Mechanizm podatności (CWE-798)
CVE-2026-22769 to przypadek CWE-798: Use of Hard-coded Credentials – w produkcie istnieje stałe poświadczenie/sekret, który (gdy zostanie poznany) umożliwia atakującemu dostęp w sposób niezgodny z modelem bezpieczeństwa. NVD wskazuje ocenę CVSS 10.0 (krytyczna) dostarczoną przez producenta (Dell).
2) Zakres podatnych wersji
Dotyczy Dell RecoverPoint for Virtual Machines w wersjach wcześniejszych niż 6.0.3.1 HF1. Dell w advisory opisuje ścieżki aktualizacji/remediacji także dla linii 5.3 (w tym zalecenie migracji/upgrade’u lub użycia skryptu naprawczego).
3) Wykorzystanie w kampanii i malware
W toku incydentów Mandiant znajdował na urządzeniach ślady BRICKSTORM, a następnie (od ok. września 2025) zastępowanie go bardziej zaawansowanym backdoorem GRIMBOLT. GRIMBOLT opisano jako narzędzie zapewniające zdalną powłokę; zwraca uwagę implementacja w C# i kompilacja Native AOT, co utrudnia analizę statyczną i bywa korzystne na „appliance’ach” o ograniczonych zasobach.
4) Utrzymanie dostępu (persistence) na appliance
Raport wskazuje m.in. nadużycie legalnych elementów systemu w celu przetrwania restartu – przykład: modyfikacja skryptu convert_hosts.sh, który jest wykonywany przy starcie przez rc.local. To klasyczny wzorzec „living off the land” na systemach linuksowych urządzeń brzegowych/backupowych.
5) Pivot do VMware i techniki „Ghost NICs”
Poza samym przejęciem appliance, obserwowano techniki ułatwiające ciche pivotowanie do infrastruktury wirtualnej, m.in. tworzenie „Ghost NICs” (tymczasowych interfejsów) oraz użycie iptables w scenariuszu Single Packet Authorization (SPA).
Praktyczne konsekwencje / ryzyko
Dlaczego to jest szczególnie groźne?
- RP4VM ma wysokie uprawnienia i „widzi” krytyczną część środowiska: backup, replikacja, integracja z VMware – to idealny punkt do eskalacji i przetrwania.
- Root persistence na urządzeniu backupowym to ryzyko zarówno dla poufności (eksfiltracja), jak i integralności (modyfikacja procesów odzyskiwania) oraz dostępności (sabotaż/„wiper”/utrudnienie DR). Opis skutków w advisory wprost mówi o nieautoryzowanym dostępie i utrwaleniu roota.
- Długi czas niewykrycia (od połowy 2024 r.) zwiększa prawdopodobieństwo, iż część środowisk mogła zostać skompromitowana przed wdrożeniem poprawek i zanim organizacje zaczęły aktywnie polować na IoC/TTP.
Rekomendacje operacyjne / co zrobić teraz
Poniżej lista działań „od razu” (priorytet: ograniczyć ekspozycję, załatać, a potem sprawdzić, czy już nie jest za późno).
1) Patch/Remediacja – działania obowiązkowe
- Zaktualizuj do 6.0.3.1 HF1 (preferowane) albo zastosuj oficjalny skrypt remediacyjny wskazany przez Dell.
- Jeżeli jesteś na linii 5.3: postępuj zgodnie z zalecaną ścieżką migracji/upgrade’u lub remediacji wskazaną w DSA-2026-079.
2) Ogranicz dostęp sieciowy do RP4VM (minimalizacja powierzchni ataku)
Dell podkreśla, iż RP4VM powinien działać w zaufanej, kontrolowanej sieci wewnętrznej z odpowiednią segmentacją i filtracją – nie jest przeznaczony do ekspozycji na sieci niezaufane/publiczne.
Checklist:
- ACL/Firewall: dostęp administracyjny tylko z sieci zarządzającej / jump hostów.
- Segmentacja: oddziel VLAN/segment dla appliance backup/DR.
- Monitoring ruchu wychodzącego (egress): twarde reguły dozwolonych destynacji.
3) Threat hunting (co sprawdzać, gdy podejrzewasz kompromitację)
Na bazie opisanych TTP warto pilnie sprawdzić:
- Nienaturalne żądania web/admin do appliance (w raporcie pojawiają się web requests z użyciem admin przed kompromitacją).
- Zmiany w plikach/skryptach uruchamianych przy starcie, w szczególności ścieżki analogiczne do modyfikacji convert_hosts.sh i mechanizmów wykonywania przez rc.local.
- Artefakty BRICKSTORM/GRIMBOLT i nietypowe połączenia C2 (Google opisuje wspólną infrastrukturę C2 dla obu rodzin).
4) Działania po naprawie
- Po wdrożeniu poprawek: potraktuj appliance jak potencjalnie „dirty” i rozważ pełną weryfikację integralności (w skrajnych przypadkach – odtworzenie z zaufanego obrazu i ponowną konfigurację). To ważne, bo sama aktualizacja nie cofa persistence/backdoorów. (Wniosek oparty na typowym przebiegu IR dla appliance z root persistence, zgodny z opisanym celem atakujących).
Różnice / porównania z innymi przypadkami
Ten incydent wpisuje się w szerszy trend: ataki na „appliance” i komponenty infrastruktury (backup/DR, edge, virtualizacja), gdzie:
- jeden błąd daje wysoki zwrot (uprzywilejowana pozycja w sieci),
- detekcja jest trudniejsza (specyficzne systemy, rzadziej monitorowane),
- a czas obecności atakującego bywa długi.
CVE-2026-22769 jest jednak szczególnie „brutalny” w naturze: to nie złożony błąd logiki, tylko hardcoded credential, czyli klasa problemów, której organizacje zwykle nie są w stanie zmitigować bez działań producenta (patch/remediation).
Podsumowanie / najważniejsze wnioski
- CVE-2026-22769 (Dell RecoverPoint for Virtual Machines) to krytyczna podatność hardcoded credentials, umożliwiająca nieautoryzowany dostęp i root-level persistence.
- UNC6201 wykorzystywał ją jako zero-day od połowy 2024 r., instalując m.in. BRICKSTORM i nowszy GRIMBOLT, oraz wykorzystując appliance do dalszej penetracji środowisk VMware.
- Najważniejsze działania: natychmiastowa aktualizacja do 6.0.3.1 HF1 / remediacja Dell + ograniczenie dostępu sieciowego + hunting pod persistence/backdoory.
Źródła / bibliografia
- Google Cloud Blog (GTIG/Mandiant): „UNC6201 Exploiting a Dell RecoverPoint for Virtual Machines Zero-Day” (Google Cloud)
- Dell Security Advisory: DSA-2026-079 (RecoverPoint for Virtual Machines Hardcoded Credential Vulnerability) (Dell)
- NVD (NIST): CVE-2026-22769 (NVD)
- BleepingComputer: „Chinese hackers exploiting Dell zero-day flaw since mid-2024” (BleepingComputer)
- SecurityWeek: „Dell RecoverPoint Zero-Day Exploited by Chinese Cyberespionage Group” (SecurityWeek)