Jeśli twoja organizacja zostanie zaatakowana przez VECT 2.0 — nie płać ocupu. Nie dlatego że zasadniczo nie należy płacić (choć to też), ale dlatego że operator fizycznie nie jest w stanie dostarczyć działającego deszyfrowania dla żadnego pliku powyżej 128 KB. Klucze potrzebne do odszyfrowania trzech czwartych każdego większego pliku zostają zniszczone w momencie szyfrowania — przez błąd w kodzie, który istnieje od pierwszej wersji VECT i nigdy nie został naprawiony.
Sprawdź swoje kopie zapasowe. Sprawdź czy są offline. Sprawdź czy ostatnio testowałeś przywracanie. To jest jedyna użyteczna reakcja na VECT.
Dlaczego to inne niż typowy ransomware
W klasycznym modelu RaaS atakujący szyfruje pliki kluczem który przechowuje, ofiara płaci, dostaje klucz, odszyfrowuje. Model działa bo obu stronom opłaca się dotrzymać umowy — atakujący chce pieniędzy, ofiara chce plików.
VECT 2.0 zepsuł ten kontrakt nie przez złą wolę, ale przez błąd implementacyjny. Check Point Research przeanalizował wszystkie trzy warianty — Windows, Linux, ESXi — i odkrył identyczną wadę w każdym z nich.
Dla pliku powyżej 128 KB VECT dzieli go na cztery fragmenty i szyfruje każdy osobnym, losowo generowanym kluczem jednorazowym (nonce). Problem: wszystkie cztery operacje używają tego samego bufora w pamięci. Każdy nowy nonce nadpisuje poprzedni. Na koniec do pliku zapisywany jest tylko ostatni — czwarty nonce. Trzy pierwsze są generowane, używane i natychmiast tracone. Dla każdego pliku powyżej 128 KB, trzy czwarte zawartości są zaszyfrowane kluczem który już nie istnieje nigdzie na świecie — ani na maszynie ofiary, ani u atakującego, ani na żadnym serwerze sterującym.
To nie jest jednorazowa pomyłka w konkretnej wersji. CPR przeanalizował wcześniejsze próbki VECT i potwierdził że identyczna wada istnieje od pierwszego publicznie obserwowanego wdrożenia. Przez wszystkie wersje, na wszystkich platformach, nigdy nienaprawiona.
Próg 128 KB w praktyce
Czym jest "mały plik" dla VECT? Plikiem poniżej 128 kilobajtów — co w praktyce oznacza: prawie niczym co ma wartość operacyjną.
Typowy dokument Word zaczyna się od kilkuset kilobajtów. Arkusz kalkulacyjny z danymi: megabajty. Zdjęcie: 1-5 MB. Plik bazy danych: gigabajty. Kopia zapasowa systemu: terabajty. Obraz maszyny wirtualnej na ESXi: dziesiątki gigabajtów. Wszystko powyżej 128 KB — wszystko co firma rzeczywiście chciałaby odzyskać — jest trwale niszczone przez VECT, nie szyfrowane.
Nota okupu którą VECT zostawia na zainfekowanych systemach mówi: "all of your files have been encrypted with ChaCha20 which is an unbreakable encryption algorithm." Dwie warstwy kłamstwa w jednym zdaniu: szyfr to nie ChaCha20-Poly1305 AEAD jak VECT twierdzi w swojej reklamie, ale surowy ChaCha20-IETF bez uwierzytelnienia — i dla większości plików nie ma czegoś do odszyfrowania, bo klucze zostały zniszczone przy szyfrowaniu.
CPR odkrył że sami operatorzy VECT nieprawidłowo opisują własny szyfr w materiałach reklamowych. Prawdopodobnie sami nie wiedzą czego używają.
Profesjonalna fasada, amatorska realizacja
Raport CPR dokumentuje wzorzec: VECT wie jak profesjonalne narzędzie powinno wyglądać, ale nie potrafi tego zaimplementować.
Warianty Linux i ESXi oferują flagi --fast, --medium i --secure sugerujące wybór między szybkością a dokładnością szyfrowania. Kod parsuje te flagi do zmiennych — i nigdy ich nie używa. Każde uruchomienie stosuje te same hardkodowane progi niezależnie od wybranej opcji. Operator który wybrał --fast dostaje dokładnie to samo co operator który wybrał --secure.
Mechanizm "zaciemniania" łańcuchów w wariancie Linux to podwójne XOR — co matematycznie daje oryginalny tekst. Łańcuchy są w plaintext w binarnym. Nawet ASCII art w kodzie jest uszkodzony przez zapomniane znaki ucieczki.
Harmonogram wątków generuje 48 wątków na maszynie z 8 CPU. Optymalnie powinno być 8-16. Przy 48 wątkach system spędza więcej czasu na przełączaniu kontekstu niż na szyfrowaniu — co aktywnie spowalnia działanie ransomware. To klasyczny błąd dewelopera który czytał o programowaniu równoległym i pominął rozdział o profilowaniu.
Trzy warstwy wykrywania środowisk analitycznych — skan procesów, sprawdzanie procesu nadrzędnego, zapytanie o obiekt debuggera jądra — są obecne w skompilowanym kodzie ale nigdy niewywoływane. Nie ma ani jednego miejsca w kodzie które do nich prowadzi. Analityk uruchamiający VECT pod żadnym z 44 wykrywanych narzędzi nie wyzwoli żadnej odpowiedzi ewazynej.
Połączenie z TeamPCP
Jest jeden szczegół w tym raporcie który łączy VECT bezpośrednio z tym o czym pisaliśmy przy okazji kampanii Checkmarx i Bitwarden.
VECT ogłosił partnerstwo z TeamPCP — aktorem odpowiedzialnym za ataki supply chain na KICS, LiteLLM, Telnyx i inne narzędzia deweloperskie. Logika jest prosta: TeamPCP zapewnia wejście do organizacji przez skompromitowane narzędzia deweloperskie. VECT dostarcza ładunek końcowy do tych samych organizacji. Strona wycieku VECT na onion listuje dwóch pierwszych ofiar — obie z ataków TeamPCP.
Do tego VECT ogłosił partnerstwo z BreachForums i dostarczył klucze dostępowe do swojego panelu każdemu zarejestrowanemu użytkownikowi forum przez prywatne wiadomości. CPR uzyskał dostęp do panelu przez konto na BreachForums. To oznacza że dostęp do narzędzi VECT ma potencjalnie kilkadziesiąt tysięcy osób.
Sceptyczna ocena tego układu: słaba implementacja kryptograficzna plus otwarte partnerstwo dla każdego użytkownika forum nie daje mniej ataków niż z dojrzałą grupą RaaS. Daje więcej — chaotycznych, z mniejszą szansą na jakiekolwiek odzyskanie danych i bez profesjonalnych negocjacji które czasem kończą się częściowym przywróceniem.
Wariant ESXi i jeden nieoczekiwany szczegół
CPR zwraca uwagę na jeden szczegół w wariancie ESXi który jest wart osobnego zdania.
Lista krajów wyłączonych z szyfrowania (standardowy CIS geofencing obecny w rosyjskich grupach ransomware) zawiera Ukrainę. To jest rzadkość — większość grup usunęła Ukrainę z list wykluczeń po 2022 roku. CPR ma dwie teorie co do tego anachronizmu: albo kod był generowany przez model językowy trenowany na danych gdzie Ukraina figuruje jako część bloku postsowieckiego, albo VECT skopiował starą bazę kodu bez weryfikacji zawartości.
Żadna z tych teorii nie jest korzystna z punktu widzenia oceny dojrzałości operatorów.
Co robić
Dla organizacji które zostały zaatakowane przez VECT: traktuj incydent jako zniszczenie danych, nie szyfrowanie. Przywracanie z kopii zapasowych jest jedyną ścieżką odzyskania. Płacenie okupu nie przyniesie działającego deszyfrowania dla żadnego pliku który ma rzeczywistą wartość operacyjną.
Dla organizacji które używają narzędzi DevSecOps z ekosystemu TeamPCP (KICS, LiteLLM, Telnyx i powiązanych) i nie zweryfikowały integracji po kampanii z 22 kwietnia: weryfikacja środowisk CI/CD pod kątem obecności Shai-Hulud i rotacja sekretów są krokami które mogą zapobiec temu żeby VECT w ogóle miał gdzie trafić.
IOC z raportu CPR: SHA-256 próbek Windows 8ee4ec425bc0d8db050d13bbff98f483fff020050d49f40c5055ca2b9f6b1c4d i 9c745f95a09b37bc0486bf0f92aad4a3d5548a939c086b93d6235d34648e683f, próbka ESXi 58e17dd61d4d55fa77c7f2dd28dd51875b0ce900c1e43b368b349e65f27d6fdd.
Podsumowanie
CPR kończy raport obserwacją: błąd nonce można naprawić w przyszłej wersji. Infrastruktura dystrybucji przez BreachForums i partnerstwo z TeamPCP już istnieje i działa.
VECT 2.0 to ransomware który w praktyce działa jak wiper — nie przez złą wolę ale przez to że nikt nie przetestował czy płatne deszyfrowanie faktycznie działa. Nota okupu przekonuje ofiarę żeby zapłaciła za klucz który przestał istnieć kilka sekund po tym jak VECT dotknął pliku.
Źródła
Check Point Research — pełna analiza techniczna z kodem, tabelami i IOC: https://research.checkpoint.com/2026/vect-ransomware-by-design-wiper-by-accident/
GBHackers — omówienie z kontekstem operacyjnym: https://gbhackers.com/vect-2-0-ransomware-wipes/
