Tre varianti del ransomware VECT 2.0 sono affette da un bug di cifratura che lo trasforma in un wiper: i file superiori a 128 KB vengono resi irrecuperabili, anche dopo il pagamento del riscatto.
Autore: Redazione SecurityOpenLab
Un ransomware che non sa cifrare i dati. È la sintesi dell'analisi pubblicata da Check Point Research su VECT 2.0, il gruppo Ransomware-as-a-Service ambizioso, con pannello di controllo, supporto multipiattaforma e un programma di affiliazione aperto a chiunque sia registrato sul forum BreachForums, che è un modello insolito, considerato che la maggior parte dei gruppi RaaS seleziona gli affiliati per reputazione o dietro pagamento. Peccato che i programmatori abbiano commesso un errore di cifratura elementare che rende permanentemente irrecuperabili quasi tutti i file colpiti, trasformando di fatto il ransomware a scopo di lucro in un wiper.
VECT è in circolazione da dicembre 2025 e le due prime vittime sono state rivendicate a gennaio 2026. Il gruppo è diventato celebre a seguito di un accordo con TeamPCP, la cui collaborazione aveva portato alla compromissione di pacchetti popolari come Trivy, Checkmarx KICS, LiteLLM e Telnyx. A febbraio 2026 ha esordito la versione 2.0, che introduce il supporto multipiattaforma (Windows, Linux e hypervisor VMware ESXi). Il codice è scritto in C++ e integra staticamente la libreria crittografica libsodium. Il gruppo ha anche annunciato l'imminente disponibilità di Cloud Locker per la cifratura di servizi di storage in cloud, con accesso riservato agli affiliati che supereranno un quiz tecnico.
Proprio con la versione 2.0 arriva anche il bug. Per capirlo bisogna partire da come VECT gestisce la cifratura. Come molti altri malware, anche questo distingue due categorie di file in base alla dimensione: quelli fino a 128 KB vengono cifrati interamente in un unico passaggio, quelli oltre quella soglia vengono suddivisi in quattro blocchi, ciascuno cifrato separatamente mediante l'algoritmo ChaCha20-IETF. Il suo funzionamento richiede due elementi per cifrare e (soprattutto) per decifrare ogni blocco: una chiave a 32 byte e un nonce a 12 byte (un valore casuale monouso, generato per ogni operazione di cifratura) senza il quale è impossibile decifrare i dati anche disponendo della chiave.
Nel caso dei file “piccoli", VECT genera un nonce, cifra il file e lo salva in fondo al file cifrato, in modo che tutto funzioni a dovere. Nel caso dei file "grandi", genera quattro nonce distinti per i quattro blocchi, ma li scrive tutti nello stesso buffer di memoria, uno sopra l'altro. Il risultato è che al termine del ciclo, nel buffer è presente solo il quarto nonce, quindi non è possibile decifrare i file. Gli esperti di CPR hanno segnalato poi un secondo problema, relativo all’algoritmo di cifratura. Al contrario di quanto pubblicizzato, quello adottato da VECT 2.0 non è ChaCha20-Poly1305 AEAD, ma ChaCha20-IETF grezzo, che non dispone di tag di autenticazione e della protezione dell'integrità dei dati.
Potremmo definire quelle accennate sopra (nel report originale ci sono tutti i dettagli con dovizia di particolari) delle sviste, se non fosse che la distruzione dei file elimina qualsiasi motivazione nelle vittime di pagare il riscatto, vanificando di fatto il guadagno degli affiliati. Ci sono poi altre piccole leggerezze che gli esperti hanno individuato, a cominciare dalla gestione del threading nella variante Windows. Il locker avvia un numero di processi paralleli sproporzionato rispetto alle CPU disponibili (su una macchina con 8 core ne lancia 48) costringendo il sistema operativo a passare continuamente il controllo da un processo all'altro invece di cifrare file. I gruppi ransomware più maturi, come LockBit, mantenengono il numero di thread vicino a quello dei core effettivi per garantirsi la massima efficienza in fase di cifratura. Il locker integra anche una suite anti-analisi capace di rilevare 44 strumenti specifici tra debugger, monitor di processo e controller sandbox, ma benché queste funzionalità siano presenti nel codice compilato, nessuna viene mai effettivamente invocata, quindi non possono essere raggiunte da nessun flusso di esecuzione.
Non è perfetta nemmeno la variante ESXi (colpisce i datastore VMware), che presenta un geofencing anacronistico: prima di cifrare verifica se il sistema si trova in un Paese della CSI e, in caso affermativo, si ferma. Questo è un approccio comune fino al 2022; dopo l'invasione dell'Ucraina la maggior parte dei gruppi ha rimosso quel controllo che VECT potrebbe avere mantenuto perché fa uso del codice generato con l'aiuto di modelli linguistici addestrati su dati datati, oppure perché gli sviluppatori hanno riciclato una codebase vecchia mai aggiornata.
Inoltre, prima di avviare la cifratura il locker disattiva il firewall ESXi, interrompe database, backup e prodotti di sicurezza, spegne le VM attive e cancella log di sistema e history delle shell. Curioso che per spegnere le macchine virtuali invochi utility di altri hypervisor oltre a VMware (VirtualBox, KVM/QEMU, Xen) suggerendo una codebase più generica di quanto il nome lasci intendere. In più, come per Windows, le opzioni di velocità di cifratura sono disponibili ma non implementate, pertanto qualunque flag venga passato dall'operatore, il malware si comporta sempre allo stesso modo.
La variante Linux condivide la codebase di quella ESXi e ne replica il comportamento: stessi servizi interrotti, stesse VM spente, stessi log cancellati, stesso bug sul nonce. Inoltre introduce un ulteriore errore. Per nascondere alcune stringhe nel codice, gli sviluppatori hanno adottato una tecnica di offuscamento, ma l'hanno applicata due volte di fila con la stessa chiave, così che si annullano a vicenda, lasciando le stringhe perfettamente leggibili, come se l'offuscamento non fosse mai stato scritto. CPR nota anche che l'ASCII art nel codice è rotta per un errore di sintassi elementare.
Il quadro che ne emerge è quello di un gruppo con aspirazioni da operatore RaaS professionale ma con una maturità crittografica e ingegneristica che non regge il confronto con i gruppi di primo piano. Certo, gli errori possono essere corretti in versioni future, anche perché tecnicamente non sono problemi insuperabili. Vale quindi la pena monitorare l'evoluzione del gruppo.