VECT 2.0: ransomware, które przez błąd szyfrowania działa jak destrukcyjny wiper - Security Bez Tabu

VECT 2.0: ransomware, które przez błąd szyfrowania działa jak destrukcyjny wiper

Cybersecurity news

Wprowadzenie do problemu / definicja

VECT 2.0 to rodzina ransomware-as-a-service, która w praktyce może prowadzić nie tylko do zaszyfrowania, ale także do trwałego uszkodzenia danych. Z analizy technicznej wynika, że błąd w obsłudze nonce podczas szyfrowania większych plików sprawia, iż malware zachowuje się bardziej jak wiper niż klasyczne ransomware.

To istotna różnica z punktu widzenia ofiary. W standardowym scenariuszu ransomware napastnicy przynajmniej teoretycznie są w stanie dostarczyć narzędzie do odszyfrowania plików po opłaceniu okupu. W przypadku VECT 2.0 część danych może być jednak nieodwracalnie utracona niezależnie od wyniku negocjacji.

W skrócie

  • VECT 2.0 pojawił się jako platforma RaaS pod koniec 2025 roku.
  • Warianty dla Windows, Linux i ESXi korzystają z tego samego wadliwego mechanizmu szyfrowania.
  • Pliki większe niż 128 KB są dzielone na cztery fragmenty, ale zapisywany jest tylko jeden nonce.
  • W efekcie trzy z czterech zaszyfrowanych obszarów mogą pozostać niemożliwe do odszyfrowania.
  • Największe ryzyko dotyczy maszyn wirtualnych, baz danych, kopii zapasowych i dokumentów roboczych.

Kontekst / historia

VECT był promowany na rosyjskojęzycznych forach cyberprzestępczych jako usługa dla afiliantów. Projekt budował wizerunek dojrzałego, wieloplatformowego zestawu narzędzi, który miał wspierać ataki na stacje robocze, serwery oraz środowiska wirtualizacyjne.

W 2026 roku zagrożenie ponownie zwróciło uwagę badaczy po doniesieniach o powiązaniach z aktorem TeamPCP. Model działania zakładał szeroką dostępność panelu oraz buildera, co mogło ułatwiać wejście mniej zaawansowanym partnerom do ekosystemu ransomware.

Na poziomie marketingowym VECT 2.0 sprawiał wrażenie rozwiniętej platformy. Dopiero szczegółowa analiza kodu pokazała, że za tą warstwą kryją się poważne błędy projektowe i implementacyjne, które fundamentalnie zmieniają charakter zagrożenia.

Analiza techniczna

Kluczowy problem dotyczy sposobu szyfrowania dużych plików, czyli takich, które przekraczają 131 072 bajty. Malware wykorzystuje ChaCha20-IETF z biblioteką libsodium, jednak sposób implementacji powoduje krytyczny błąd w procesie odzyskiwania danych.

Dla małych plików mechanizm jest relatywnie spójny: generowany jest pojedynczy nonce, cały plik zostaje zaszyfrowany, a parametr potrzebny do odszyfrowania dopisywany jest na końcu pliku. W takim przypadku odszyfrowanie pozostaje technicznie możliwe.

Problemy zaczynają się przy większych zasobach. VECT 2.0 dzieli plik na cztery części zlokalizowane na początku, w jednej czwartej, połowie i trzech czwartych długości pliku. Każdy fragment szyfrowany jest osobno z użyciem nowego, losowego 12-bajtowego nonce.

Błąd polega na tym, że wszystkie operacje korzystają z tego samego bufora pamięci dla nonce. Każde kolejne wywołanie nadpisuje poprzednią wartość, a po zakończeniu procesu na dysk trafia wyłącznie ostatni zapisany nonce. Oznacza to, że trzy wcześniejsze fragmenty tracą niezbędne parametry potrzebne do ich odszyfrowania.

Co szczególnie istotne, brakujące nonce nie są przechowywane w innym miejscu, nie są zapisywane do osobnych plików i nie są przekazywane operatorowi. W praktyce oznacza to, że nawet po zapłaceniu okupu napastnik może nie mieć technicznej możliwości odwrócenia skutków działania malware.

Ten sam problem zaobserwowano w wariantach dla Windows, Linux i ESXi, co sugeruje wspólną bazę kodu. Badacze zwrócili również uwagę na dodatkowe oznaki niskiej jakości implementacji, w tym elementy kodu, które nie realizują deklarowanych funkcji lub działają niepełnie.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją jest zerwanie podstawowego modelu działania ransomware, czyli założenia, że dane da się odzyskać po spełnieniu żądań finansowych. W przypadku VECT 2.0 incydent może oznaczać trwałą destrukcję informacji, a nie tylko czasową utratę dostępu do plików.

Ryzyko dla organizacji jest wysokie, ponieważ próg 128 KB obejmuje nie tylko duże obrazy dysków, bazy danych czy backupy, ale również wiele codziennych dokumentów, archiwów, skrzynek pocztowych i plików projektowych. W środowiskach ESXi skutki mogą być szczególnie dotkliwe, jeśli uszkodzeniu ulegną pliki maszyn wirtualnych lub powiązane zasoby operacyjne.

Dodatkowym zagrożeniem jest błędne założenie, że negocjacje z operatorem zwiększą szansę na odzyskanie danych. W tym przypadku taki scenariusz może okazać się bezwartościowy, ponieważ problem nie wynika z braku klucza po stronie ofiary, lecz z nieodwracalnej utraty parametrów potrzebnych do odszyfrowania części danych.

Rekomendacje

Organizacje powinny traktować VECT 2.0 jak zagrożenie o charakterze destrukcyjnym, a nie wyłącznie jako klasyczne ransomware. Plany reagowania na incydenty powinny uwzględniać scenariusz trwałej utraty danych i konieczność pełnego odtworzenia środowiska z bezpiecznych kopii zapasowych.

  • Utrzymywanie offline’owych i niemodyfikowalnych kopii zapasowych.
  • Regularne testy odtwarzania systemów oraz danych krytycznych.
  • Wzmocniona ochrona repozytoriów backupów, platform wirtualizacyjnych, serwerów plików i baz danych.
  • Segmentacja sieci oraz ograniczanie możliwości lateral movement.
  • Kontrola narzędzi zdalnej administracji i monitorowanie nietypowych operacji na plikach.
  • Wdrożenie EDR/XDR, monitoringu integralności plików i reguł wykrywających anomalie szyfrowania.

W trakcie obsługi incydentu należy możliwie szybko odizolować zainfekowane hosty, zabezpieczyć próbki malware, ustalić zakres zniszczeń oraz sprawdzić, które zasoby zostały objęte wadliwym mechanizmem szyfrowania. Decyzje dotyczące ewentualnych negocjacji nie powinny opierać się na założeniu, że operator posiada skuteczny deszyfrator.

Podsumowanie

VECT 2.0 pokazuje, że nowoczesne kampanie ransomware nie zawsze działają zgodnie z deklarowanym modelem wymuszenia. W tym przypadku błąd implementacyjny sprawia, że malware dla większych plików zachowuje się jak wiper, prowadząc do nieodwracalnej utraty danych.

Dla zespołów bezpieczeństwa oznacza to konieczność zmiany perspektywy: priorytetem stają się odporność operacyjna, skuteczne kopie zapasowe, segmentacja i szybkie odtworzenie środowiska. VECT 2.0 należy klasyfikować nie tylko jako ransomware, ale również jako realne zagrożenie destrukcyjne dla infrastruktury przedsiębiorstw.

Źródła