VECT 2.0 ransomware vibe coded – jak hakerzy zniszczyli własne ofiary błędem w kodzie AI

Cyberprzestępcy z grupy VECT zrobili coś, czego nie życzyłbyś sobie nawet wrogowi. Ich własne narzędzie do szyfrowania, czyli ransomware VECT 2.0, zamiast brać pliki w zakładnika i żądać okupu, po prostu je niszczy. Mowa o wszystkim, co waży powyżej 128 kilobajtów, czyli praktycznie każdym dokumencie, mailu czy bazie danych. Ofiara płaci okup w Bitcoinach, dostaje klucz deszyfrujący, próbuje odzyskać dane i widzi tylko cyfrowy gruz. Klucze do większości fragmentów po prostu nie istnieją, bo malware je wygenerował i cicho wyrzucił. Check Point Research rozłożył kod na czynniki pierwsze i ma dwie hipotezy. Albo VECT zbudował swój ransomware na starym, dziurawym kodzie, albo (ta wersja jest mocniej obstawiana) ten kod był po prostu “vibe coded” przy pomocy modeli językowych, bez pełnej weryfikacji. To dokładnie ta sama wpadka, na którą agent AI w Cursorze skasował produkcyjną bazę PocketOS, tylko z drugiej strony barykady.

Co dokładnie zrobił VECT 2.0 – 128 kilobajtów i dane przepadają

VECT to grupa typu Ransomware-as-a-Service (RaaS), czyli model biznesowy, w którym jeden zespół tworzy malware, a inni “klienci” przestępcy płacą za jego użycie. Pierwsza wersja VECT pojawiła się w grudniu 2025 na rosyjskojęzycznym forum cyberprzestępczym, a ofiary spadły w styczniu 2026. W lutym wyszedł VECT 2.0 z rozszerzonym zasięgiem na Windows, Linux i VMware ESXi. Brzmi groźnie, ponieważ pełna lista platform zwykle oznacza profesjonalną operację.

Tymczasem badacze z Check Point Research odkryli błąd, który zmienia całe równanie. Każdy plik większy niż 131 072 bajty (czyli 128 kilobajtów) zostaje przez ransomware nieodwracalnie zniszczony, a nie zaszyfrowany. To granica niższa niż typowy załącznik do maila albo arkusz Excela. W praktyce niemal wszystko, co ofiara chciałaby odzyskać – dokumenty, bazy danych, mailboxy, dyski wirtualne, kopie zapasowe – leży powyżej tej granicy.

Plik o rozmiarze 128 KB to mniej niż jedno zdjęcie z telefonu w średniej rozdzielczości. Wszystko większe wpada do kosza, nawet jeśli ofiara zapłaci.

Skutek dla biznesu jest brutalny. Firma, która padła ofiarą VECT 2.0, dostaje typowy komunikat “zapłać X Bitcoinów, dostaniesz klucz”. Płaci, dostaje klucz, uruchamia deszyfrator, a dane wracają w postaci pustych albo uszkodzonych plików. Reakcja przestępców? Najczęściej “to nie nasz problem”. Reakcja klienta tych przestępców? Również strata – bo zapłacił za narzędzie, które zniszczyło reputację jego “biznesu” na rynku ransomware.

Jak technicznie działa ten błąd – cztery klucze, trzy w śmietniku

Dla osób, które chcą rozumieć technicznie, błąd działa tak. Każdy duży plik (powyżej 128 KB) malware dzieli na cztery niezależne fragmenty. Następnie generuje cztery świeże, losowe 12-bajtowe nonce’y – po jednym dla każdego fragmentu. Nonce to taki “jednorazowy klucz pomocniczy” w szyfrowaniu, dzięki któremu nawet to samo hasło daje za każdym razem inny wynik szyfrowania. Każdy fragment zostaje zaszyfrowany swoim własnym nonce’em. I tu zaczyna się tragedia.

Z czterech wygenerowanych nonce’ów malware dopisuje do zaszyfrowanego pliku tylko ostatni. Pierwsze trzy są wygenerowane, użyte do szyfrowania i cicho odrzucone. Nie trafiają na dysk, nie zostają w rejestrze, ani nie są wysyłane do operatora ransomware. Po prostu przestają istnieć. Bez tych trzech nonce’ów żaden klucz deszyfrujący na świecie nie odzyska zawartości fragmentów. Z perspektywy ofiary plik wygląda jak zaszyfrowany, ale w istocie został rozdrobniony na cztery kawałki, z których trzy są niewidzialne nawet dla ich autora.

Dla atakującego to ironiczna sytuacja: zbudował maszynę do brania danych w zakładnika, ale zaprojektował ją tak, że sam zabija zakładnika przed odebraniem okupu.

Dlaczego Check Point Research podejrzewa AI w kodzie VECT

Hipotezę o “vibe codingu” stawia konkretny zespół: Check Point Research, jedna z najbardziej szanowanych firm researchu w cybersecurity. Mają dwie teorie: albo kod powstał z pomocą modeli językowych (LLM-ów), albo VECT skopiował starą, dziurawą bazę kodu i przykleił do niej nowe funkcje. Obie wersje mówią o jednym – autor nie sprawdził, czy jego mechanizm szyfrowania w ogóle ma sens dla większych plików.

Co jeszcze sugeruje udział AI w tym kodzie? Badacze znaleźli wiele innych błędów i wpadek projektowych we wszystkich trzech wariantach VECT 2.0. Lista jest długa: samowyłączające się obfuskacje stringów, fragmenty kodu antyanalitycznego, do których malware nigdy nie dociera, oraz scheduler wątków, który sam degraduje wydajność szyfrowania, którą miał poprawiać. Wszystko to wygląda jak kod sklejony z różnych podpowiedzi modelu, bez pełnego zrozumienia, jak fragmenty grają ze sobą.

Sprawa pasuje do narastającego trendu, który widzimy też w legalnym oprogramowaniu. Lovable wyciekł BOLA przez vibe coding, LiteLLM uderzył w supply chain ataków, agenty AI kasują produkcyjne bazy. Wzór jest powtarzalny: developer (lub w tym wypadku przestępca) używa modelu AI do napisania większych fragmentów kodu, akceptuje wyniki bez głębokiej weryfikacji i wypuszcza coś, co wygląda jak działający produkt. Później okazuje się, że pod spodem siedzą absurdy, których człowiek z pełnym zrozumieniem domeny by nie napisał.

Co z tej historii wynika dla legalnych developerów – granice vibe codingu

Najważniejsza lekcja jest banalna, a jednocześnie głęboka: AI dobrze radzi sobie z rzeczami, które już istnieją w jej treningu, natomiast słabo wymyśla nowe mechanizmy bezpieczeństwa od zera. Szyfrowanie to dziedzina, w której każdy szczegół ma znaczenie. Brakujący nonce, zła kolejność wywołań, niewystarczająca długość klucza – każdy z tych błędów potrafi obrócić “bezpieczne” rozwiązanie w stertę bezużytecznych bajtów. Model AI może zaproponować schemat, który wygląda dobrze, ale nie weryfikuje go w głowie tak jak doświadczony cryptograph.

Co warto wziąć z tego do swojej codziennej pracy? Po pierwsze, granicę między dziedzinami, gdzie vibe coding jest bezpieczny, a tymi, gdzie wymaga eksperckiej weryfikacji. Aplikacja CRUD, formularz, dashboard, prosty proces ETL – tu AI radzi sobie świetnie. Mechanizm szyfrowania, autoryzacja, integracja z systemem płatności, kod krytyczny dla bezpieczeństwa – tu trzeba ręcznego przeglądu i najlepiej zaangażowania osoby z głębokim zrozumieniem domeny.

Po drugie, każdy fragment kodu od AI dotyczący danych krytycznych powinien przejść test “czy działa też w przypadku brzegowym”. W przypadku VECT brzegowym przypadkiem jest plik większy niż 128 KB, którego nikt nie sprawdził. W legalnym świecie analogiczne brzegówki to: pliki większe niż dostępna pamięć RAM, nieprzewidziane formaty wejściowe, zerwane połączenie sieciowe w środku transakcji. AI rzadko sama wymyśla takie scenariusze, dlatego musisz je podsunąć w promptach albo dopisać testy.

Vibe coding to świetny akcelerator. Akcelerator bez kierunkowskazów dowiezie cię szybko, choć niekoniecznie tam, gdzie planowałeś.

W naszych projektach klienckich obowiązuje prosta zasada: AI pisze pierwszą wersję, człowiek weryfikuje całą logikę krytyczną dla bezpieczeństwa. To samo dotyczy automatyzacji w n8n, integracji płatniczych albo każdego fragmentu kodu, który dotyka danych klienta.

Pierwsza Misja AI · Kodożercy

Rozumiesz zagrożenia AI, gdy rozumiesz jak naprawdę działa

Kurs Pierwsza Misja AI ma dedykowaną lekcję o ciemnej stronie AI: halucynacje, deepfakes, manipulacja. Zanim zaczniesz się bać, zacznij rozumieć.

Poznaj pełny program →

Podsumowanie

VECT 2.0 ransomware to ironiczny dowód na to, że nawet cyberprzestępcy nie radzą sobie z granicami vibe codingu. Pliki większe niż 128 kilobajtów są przez ten malware nieodwracalnie niszczone, a nie szyfrowane, ponieważ trzy z czterech kluczy szyfrujących trafiają do śmietnika zamiast na dysk. Check Point Research podejrzewa, że za błędem stoi kod wygenerowany przez AI bez pełnej weryfikacji. Co zyskujemy z tej historii? Twardą lekcję, że AI dobrze pomaga w rzeczach standardowych, ale w dziedzinach krytycznych dla bezpieczeństwa wymaga ręcznego przeglądu eksperta. Co stracili przestępcy? Reputację i klientów, ponieważ żaden poważny operator nie będzie używał ransomware, który niszczy dane przed odebraniem okupu. Co stracił świat? Niestety nic, bo stracone dane ofiar nie wracają, a jednocześnie pojawi się kolejna wersja – VECT 3.0 – tym razem prawdopodobnie z kodem dokładniej sprawdzonym przed wypuszczeniem.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.