Le 28 avril 2026, Check Point Research a publié une analyse technique du chiffrement de VECT 2.0 (CPR-2026-0428). La conclusion est claire : le chiffrement de VECT présente une faille spécifique. Pour tout fichier de plus de 128 Ko, le processus censé générer une clé de chiffrement unique pour chaque bloc de données réutilise en réalité une seule et même valeur, et seule cette valeur finale est enregistrée. Les trois quarts des données de chaque fichier volumineux sont ainsi brouillés de manière irréversible. Ils ne peuvent être récupérés ni par la victime, ni par VECT.
Le paiement de la rançon ne permet pas de récupérer les fichiers volumineux. La clé de déchiffrement est bien réelle. La perte des données survient avant même que cette clé ne puisse être utilisée.
Ce constat est important en soi. Il découle également d’un problème plus structurel qui a suscité beaucoup moins d’attention.
Comment les cibles sont-elles sélectionnées ?
La plupart des opérations de ransomware suivent le même schéma de ciblage. Un groupe identifie une organisation, se procure ou achète un accès, puis lance son attaque. La sélection de la cible intervient avant même que l'accès ne soit établi. Votre vulnérabilité face à un groupe de ransomware donné dépend du fait que ce groupe ait décidé ou non de s'en prendre à des organisations comme la vôtre.
VECT ne fonctionne pas ainsi. Son partenaire de la chaîne d'approvisionnement, TeamPCP, non plus.
Le bulletin IC3 FLASH-20260702-01 du FBI, publié le 2 juillet 2026, fait état d’une campagne axée sur l’ampleur plutôt que sur le ciblage. Entre février et mars 2026, le groupe TeamPCP a altéré quatre logiciels open source largement utilisés, sur lesquels s’appuient les organisations pour le développement et les analyses de sécurité :
- Trivy, un outil servant à analyser les conteneurs à la recherche de failles de sécurité : TeamPCP a exploité une vulnérabilité (CVE-2026-33634) pour remplacer 76 des 77 versions du workflow automatisé de Trivy par une copie malveillante, en utilisant les identifiants volés d'un développeur disposant d'un accès en écriture au dépôt de code.
- Checkmarx KICS, un outil qui analyse le code de l'infrastructure à la recherche d'erreurs de configuration : TeamPCP a également écrasé 35 versions. Ils ont également utilisé les identifiants d'automatisation propres à chaque organisation victime pour créer un référentiel caché appelé
docs-tpcpdans le compte GitHub de la victime. - LiteLLM v1.82.8, une bibliothèque logicielle comptant environ 95 millions de téléchargements par mois : TeamPCP a ajouté un fichier nommé
litellm_init.pthà l'installation. Les fichiers portant l'extension.pthLes extensions sont automatiquement lues et exécutées par Python à chaque démarrage, quel que soit le logiciel que vous utilisez. Cela a permis à TeamPCP exécution persistante de code sur toute machine sur laquelle le paquet avait été installé. - Versions 4.87.1 et 4.87.2 du SDK Python de Telnyx : un cheval de Troie d'accès à distance en trois étapes, c'est-à-dire un logiciel qui permet aux pirates de prendre discrètement le contrôle de la machine infectée.
TeamPCP est le même groupe à l'origine du worm de chaîne logistique Shai-Hulud, qui utilise des paquets compromis pour se propager automatiquement dans les environnements de développement et les pipelines CI/CD. La campagne menée en février-mars 2026 contre Trivy et LiteLLM a utilisé le même mécanisme sous-jacent : paquet de confiance, exécution automatique, collecte d’identifiants. La deuxième partie de Shai-Hulud traite de la campagne TanStack de mai 2026, au cours de laquelle le worm plus loin en générant des certificats de signature cryptographique valides afin de passer les contrôles de vérification des paquets.
Résultat : plus de 500 000 identifiants volés provenant de plus de 10 000 pipelines CI/CD (intégration et déploiement continus), ces systèmes automatisés qui permettent de développer, de tester et de déployer des logiciels. Des jetons AWS, Azure et GCP. Des secrets Kubernetes. Des identifiants de registres de conteneurs. Des jetons d'accès GitHub et GitLab.
TeamPCP n'a pas sélectionné de cibles, mais des paquets. En mars 2026, l'archive des identifiants existait déjà. VECT l'a parcourue et a sélectionné des victimes de ransomware parmi les données qu'elle contenait.
La sélection de la cible a eu lieu après l'accès, et non avant.
« Ensemble, nous sommes prêts à déployer des ransomwares dans toutes les entreprises touchées par ces attaques, et nous ne nous arrêterons pas là. »
« Nous enchaînerons ces failles de sécurité pour mener des campagnes de ransomware dévastatrices. »
En quoi cela change-t-il la situation en matière d'exposition aux ransomwares ?
L'exercice classique de planification face aux ransomwares pose la question suivante : « Que devrait faire un attaquant pour s'introduire dans notre environnement ? » Cette question part du principe que l'attaquant n'a pas encore pris sa décision. Le modèle TeamPCP suggère que la réponse à cette question a peut-être déjà été donnée, il y a plusieurs mois, par l'installation de routine d'un paquet dans un pipeline de développement que votre équipe a depuis oublié.
La Counter Threat Unit de Sophos a confirmé au moins un déploiement de VECT utilisant des identifiants provenant de TeamPCP. Le FBI prévient que ces identifiants volés « seront utilisés à des fins malveillantes bien après la compromission initiale ». Votre exposition à VECT ne dépend pas du fait que le groupe cible ou non votre secteur d'activité. Elle dépend uniquement de la présence ou non cloud vos cloud dans cette archive.
Pourquoi cela n'apparaît-il pas dans vos journaux ?
Voici le point n° 3 : le mouvement n'est pas visible.
Le litellm_init.pth Le fichier de persistance s'exécute automatiquement à chaque démarrage de Python dans l'environnement concerné. Le gestionnaire de paquets logiciels enregistre une installation. Le pipeline CI/CD enregistre l'exécution d'un workflow attribué à un compte de service connu. Le cloud enregistre un appel API authentifié provenant d'une identité reconnue. Trois journaux d'audit, trois tickets du Centre des opérations de sécurité (SOC), une violation.
Aucun fichier journal ne retrace à lui seul le parcours d’un paquet compromis jusqu’à cloud de production. Pour reconstituer ce parcours, il faut recouper l’horodatage de l’installation, l’exécution du workflow et l’appel API sortant avec une liste des versions de paquets concernées — liste que la plupart des organisations ne tiennent pas à jour et que la plupart des systèmes de surveillance de la sécurité ne vérifient pas automatiquement. Ce même problème de fragmentation des journaux est apparu lors de l’incident de chaîne d’approvisionnement Anodot/Snowflake en avril 2026, où des jetons volés à un fournisseur d’intégration SaaS ont été réutilisés dans plusieurs environnements clients, chaque système validant sa propre partie de l’activité sans qu’aucun ne fasse le lien entre elles. Le cas VECT/TeamPCP suit le même schéma, mais via la couche CI/CD plutôt que via la couche d’intégration SaaS.
Le vecteur Checkmarx KICS ajoute une couche supplémentaire. TeamPCP a utilisé les identifiants d'automatisation de la victime pour créer docs-tpcp au sein de l'organisation GitHub de la victime. L'événement de création du dépôt apparaît dans le journal d'audit de GitHub, attribué au compte de service de la victime. Tout semblait normal. C'est le « Gap 1 ».
Le déficit de compétences au sein de l'entreprise
L'analyse du code de VECT 2.0 réalisée par Check Point a révélé des signes évidents d'un développement amateur : du code destiné à contourner les mesures de sécurité qui est écrit mais ne s'exécute jamais, une couche d'obfuscation qui s'annule d'elle-même, des paramètres de configuration qui semblent flexibles mais qui sont en réalité codés en dur, ainsi que du texte décoratif erroné dans le programme. La faille de chiffrement qui pousse VECT à détruire définitivement les fichiers de ses victimes suit le même schéma. Ce malware l'œuvre d'amateurs.
Ce n'est pas le cas de l'infrastructure qui l'entoure. Le programme d'affiliation de VECT comprend des comptes de dépôt fiduciaire en Monero (une cryptomonnaie axée sur la confidentialité), une intégration avec BreachForums, un système de commissions à plusieurs niveaux et des négociateurs dédiés qui gèrent les discussions relatives aux rançons. Le modèle d’affiliation de masse de BreachForums, officialisé le 16 avril 2026, permet aux opérateurs d’accéder à cette infrastructure sans avoir à la mettre en place eux-mêmes. L’archive d’identifiants de TeamPCP remplace les compétences techniques d’exploitation: il n’est pas nécessaire de trouver une faille dans les défenses de la cible si l’on dispose déjà de ses cloud .
Cela a une incidence sur la planification de la défense. Un logiciel Endpoint fonctionnant correctement identifiera le malware. Le chemin de diffusion via les chaînes d'approvisionnement logicielles et les pipelines automatisés ne le déclenchera pas. La détection n'est pas défaillante. Elle est simplement incomplète.
Ce qu'il faut vérifier dès maintenant
Si votre environnement a exécuté l'un de ces paquets avant avril 2026, considérez que vos cloud du pipeline ont été compromis jusqu'à ce que vous puissiez confirmer le contraire:
- LiteLLM, plus précisément la version 1.82.8. Recherchez également
litellm_init.pthdans les répertoires d'installation de Python sur toutes les machines ayant exécuté LiteLLM en février et mars 2026. - Action GitHub « Trivy », toute version associée aux balises 0.76.x ou 0.77.x pendant cette période.
- Action GitHub Checkmarx KICS, l'une des 35 balises concernées.
- SDK Python Telnyx 4.87.1 ou 4.87.2.
Recherchez dans la liste des dépôts de votre organisation GitHub : docs-tpcp. Sa présence signifie que TeamPCP a utilisé vos propres identifiants d'automatisation pour le créer. Renouvelez cloud (comptes de service AWS, Azure et GCP, jetons de registre de conteneurs, jetons d'accès GitHub et GitLab) émis avant avril 2026 dans les environnements concernés. Vérifiez les journaux AWS CloudTrail, Azure Monitor et GCP Cloud Logs pour repérer les appels API effectués depuis les comptes de service des pipelines vers les environnements de production entre février et avril 2026, en particulier ceux antérieurs aux déploiements connus.
Le chapitre « Gap 3 » dans Mind Your Attack Gaps traite d’une étude de cascloud , où le même problème de fragmentation des journaux se retrouve dans une chaîne d’attaque différente. Chez Vectra AI, nous modélisons les mouvements inter-environnements entre les identités, cloud et les services SaaS sans dépendre de la corrélation entre trois systèmes d’audit distincts. La campagne TeamPCP/VECT illustre clairement pourquoi une visibilité limitée à un seul environnement ne permet pas de couvrir ce type d’attaque.
Les archives d'identifiants existent. Si votre pipeline a exécuté les paquets concernés avant avril 2026, la question qui se pose désormais n'est pas de savoir si vous pourriez être pris pour cible, mais si vos jetons s'y trouvent déjà.