VECT 2.0 échoue dans les nonces et transforme l'ansomware en effacement irréversible des données

Une erreur VECT 2.0 transforme l'ansomware supposé en un projet irréversible: Les chercheurs de Check Point ont découvert que la version 2.0 de VECT ne gère pas les nonces lors du cryptage de blocs, ce qui fait que les gros fichiers sont définitivement inutiles plutôt que simplement chiffrés. Cet échec n'est pas un détail d'implémentation mineur : il affecte le mécanisme cryptographique de base qui garantit que chaque bloc chiffré peut être récupéré indépendamment.

En termes techniques, VECT tente d'accélérer le cryptage des grands fichiers en les divisant en parties (chunks) et en générant un nonce pour chaque partie. Cependant, tous les nonces sont générés dans le même tampon mémoire et sont écrasés dans chaque itération; à la fin de l'opération, seul le dernier nonce est écrit dans le disque. L'effet est que, dans la pratique, seule la dernière partie du fichier (environ 25% selon l'analyse) conserve le nonce nécessaire pour le déchiffrer. Le reste est irréversiblement mutilé parce que les nonces ci-dessus ne sont jamais envoyés à l'opérateur ou conservés sur le disque.

Les conséquences pour les milieux d'affaires sont graves. Check Point souligne que le seuil que VECT considère comme "grand fichier" est seulement 128 KB, beaucoup plus bas que d'habitude dans les disques virtuels, sauvegardes, bases de données et de nombreux documents d'affaires; ce qui rend le comportement "effacement accidentel" affecter la plupart des actifs critiques. En outre, la même logique défectueuse est présente dans les variantes pour Windows, Linux et ESXi, de sorte que les serveurs et les systèmes de virtualisation sont également exposés. Plus de détails techniques sont disponibles dans le rapport Check Point: Vérifiez la recherche en points sur VECT 2.0.

Le contexte opérationnel augmente la gravité du problème: VECT a été promu dans des forums secrets de type BreachForums avec un modèle d'affiliation et, selon les rapports, les opérateurs ont annoncé une association avec le groupe TeamPCP, impliqué dans les engagements récents de chaînes d'approvisionnement qui ont affecté des projets tels que Trivy ou LiteLLM et des services tels que Telnyx. Cette collaboration suggère que le VECT a peut-être été conçu pour être déployé après les engagements du fournisseur ou du logiciel, un vecteur qui multiplie les dommages potentiels et complique la réponse.

Il est important de comprendre pourquoi payer la rançon peut ne pas servir: comme les nonces perdus ne sont pas renvoyés à l'agresseur, même si une victime répondait aux exigences il n'y aurait pas assez de clés pour reconstruire les blocs avant le dernier. Dans la pratique, cela transforme une attaque ransomware (où il y a espoir de récupération après paiement) en un acte de destruction irréversible de données pour la plupart des fichiers touchés.

Pour les organisations et les responsables de la sécurité, la priorité immédiate est de contenir et de préserver : isoler les machines touchées, arrêter la propagation, prendre des images médico-légales des dossiers et de la mémoire et se connecter avec une équipe d'intervention spécialisée. Bien que les nonces aient pu être écrasés en mémoire, la capture d'une image RAM dès que possible reste une mesure précieuse pour les enquêtes médico-légales et pour déterminer la séquence de l'attaque et le point d'entrée.

La meilleure défense reste la prévention des données et la résilience. Cela comprend le maintien de sauvegardes robustes, avec des contrôles d'intégrité et des tests de restauration réguliers; l'utilisation de versions de sauvegardes immuables ou décomposées d'air@@ dans la mesure du possible; le segmentage des réseaux et la hiérarchisation du principe d'un privilège moindre pour réduire la portée des mouvements latéraux; et le déploiement de la détection dans les terminaux et la télémétrie du réseau pour identifier les premières activités suspectes.

De plus, il est essentiel de renforcer les contrôles de sécurité dans la chaîne d'approvisionnement : vérifier et surveiller les unités, assurer les pipelines CI/CD, signer et vérifier les artefacts et exiger des fournisseurs des pratiques de sécurité. La littérature cryptographique rappelle également l'importance de manipuler rigoureusement les nonces et les vecteurs d'initialisation; pour une référence technique sur l'utilisation correcte des modes AEAD (comme GCM) et la gestion des nonces, voir le guide technique du NIST: NIST SP 800-38D.

Du point de vue de la réponse publique-privée, les organisations concernées devraient notifier les autorités et les régulateurs conformément à leurs obligations légales et de confidentialité, et communiquer l'ampleur de l'impact aux clients et aux partenaires de manière transparente. Étant donné que le VECT est distribué par les participants et les forums, le partage d'indicateurs d'engagement avec les points focaux communautaires et sectoriels peut aider à identifier de nouveaux déploiements et à atténuer les risques.

Un message pour le CISUS et l'équipement technique: d'examiner d'urgence les politiques de sauvegarde et de conservation, d'activer les tests de restauration sur différents scénarios, de mettre en quarantaine les systèmes suspects et d'élaborer des plans de continuité qui envisagent la possibilité de perte partielle ou totale d'actifs critiques. Si votre organisation dépend de fournisseurs de logiciels ou de services sous-traités, prioriser l'évaluation de ces fournisseurs et la vérification de l'intégrité des artefacts.

En bref, l'incident VECT 2.0 est un rappel que les erreurs d'implémentation cryptographique peuvent transformer un malware de chiffrement en un destroyer de données et que la combinaison des modèles d'affiliation criminelle et des attaques de chaîne d'approvisionnement amplifie le risque systémique. La défense exige des contrôles techniques précis et des pratiques opérationnelles et contractuelles qui réduisent la probabilité d'intrusion et augmentent la possibilité réelle de récupération en cas d'engagement.