Une organisation mentionnée dans l'archive d'identifiants TeamPCP a indiqué à Kevin Beaumont que la faille avait été corrigée et que tous les identifiants avaient été renouvelés. Il a consulté leur politique de divulgation responsable, s'est assuré qu'elle autorisait les tests d'identifiants, puis les a testés.
Il s'agit d'un seul message, d'une seule organisation, et Beaumont n'en a pas précisé le nom. Considérez cela comme un simple élément d'information. Mais c'est un élément d'information concernant le délai entre la clôture d'un ticket de correction et la révocation d'un identifiant, et il en existe un deuxième, provenant de la première victime de la chaîne.
Ce qu'ont apporté les révélations du mois d'août
En juillet, j'ai évoqué les archives de données d' cloud s de TeamPCP et j' ai expliqué que votre vulnérabilité face au ransomware VECT dépendait de la présence ou non de vos identifiants d' s dans ces archives. En août, ces archives ont pris de l'ampleur et ont permis d'établir une liste de victimes.
- CloudSEK, 11 août: plus de 2 500 organisations et environ 434 000 pipelines CI/CD.
- Hudson Rock, 12 août: une archive de 153 Go contenant 433 909 fichiers, récupérée et analysée, comprenant 118 829 dumps de CI Runner attribués à 2 488 domaines d'entreprises.
Lisez la mise en garde de CloudSEK avant le titre. Ses chiffres « décrivent une exposition reconstituée » et « ne doivent pas être interprétés comme la preuve que chaque organisation répertoriée a bel et bien été compromise ou que chaque identifiant a été volé ». Le fait d'apparaître dans l'ensemble de données constitue un motif d'enquête, et non une violation confirmée. L'article de Hudson Rock ne comporte aucune mise en garde équivalente, ce qu'il est bon de savoir lorsque l'on compare les deux listes.
Les deux cabinets citent les organisations avec lesquelles ils ont établi une correspondance. Je ne répéterai pas ces noms ici. Une correspondance d’exposition reconstituée n’équivaut pas à une compromission confirmée, et cette distinction ne tient pas la route lorsqu’on la transpose sous la forme d’une liste de noms d’entreprises.
Aucune des deux entreprises n'a publié ces archives. Hudson Rock les a intégrées à sa plateforme Cavalier et met en œuvre un processus de divulgation au cas par cas ; CloudSEK propose quant à elle une recherche dans le domaine public. On ignore si ce corpus circule plus largement, et les personnes les plus proches du dossier ont des avis divergents :
- Alon Gal, de Hudson Rock, a déclaré à Help Net Security que « cette information n'a pour l'instant fait l'objet d'aucune fuite et ne circule pas à grande échelle ».
- Beaumont a déclaré, la même semaine, que « des téraoctets de données d'identification circulent actuellement sur Internet ».
- SOCRadar a constaté qu’un intermédiaire proposait sur Telegram un ensemble de données comprenant LiteLLM, Trivy et CanisterWorm, d’un volume de plus de 150 Go une fois compressées, ce qui laisse penser qu’il s’agit d’un seul vendeur détenant cette collection plutôt que d’une large diffusion.
Cette distinction détermine à quelle vitesse vous devez vous attendre à ce que ces identifiants soient utilisés. Elle n'a aucune incidence sur le fait qu'ils aient été copiés en mars.
La fenêtre est plus large que celle dont tout le monde a parlé
Cela corrige autant mon article de juillet que les autres articles publiés sur le sujet.
Cette campagne a été qualifiée de « faille LiteLLM » et s'est déroulée pendant environ 40 minutes le 24 mars, période durant laquelle les paquets corrompus sont restés sur PyPI. SOCRadar a analysé les horodatages des 2 188 enregistrements d'organisations et a constaté que l'exposition avait commencé plus tôt :
- Première donnée enregistrée : 19 mars, 18 h 05 UTC
- Dernière mise à jour : 24 mars, 20 h 09 UTC
- Données faisant état d'activités de recouvrement antérieures au 24 mars, soit avant la mise en service des modules LiteLLM : 2 085 sur 2 188, soit 95 %
Selon SOCRadar, cette chronologie semble indiquer que la compromission de Trivy s'est produite en amont, plutôt que pendant la fenêtre d'installation de LiteLLM, et SecurityWeek a présenté les choses de la même manière le 14 août. C'est la formulation de SOCRadar qu'il convient de retenir : ces 40 minutes constituaient le dénouement, et non l'ensemble de l'opération.
Une recherche dans les journaux limitée au 24 mars était donc trop restrictive. Cette date reste importante si vous avez installé les versions corrompues, mais la majeure partie de l'exposition est antérieure à celle-ci.
La mise en œuvre des mesures correctives par Trivy constitue l'étude de cas
L'une des raisons pour lesquelles la rotation échoue est illustrée par le cas de la première victime.
Le 1er mars, Aqua a révoqué les identifiants correspondant aux identités d’automatisation dont les enquêteurs savaient qu’elles avaient été compromises. La chronologie établie par CloudSEK, lue conjointement avec celle d’Aqua et la fiche NVD relative à la vulnérabilité CVE-2026-33634, décrit la suite des événements. L'activité s'est poursuivie via un autre utilisateur et un autre jeton. Le jeton observé au cours de la période du 1er mars est réapparu dans le cadre d'une activité malveillante le 19 mars. Le 22 mars, un compte de service que personne ne soupçonnait d'être compromis a accédé à 43 dépôts au sein d'une autre organisation. CloudSEK reconstitue une période d'environ 20 jours durant laquelle un jeton d'automatisation est resté utilisable après sa rotation, et précise que ce chiffre correspond à sa propre reconstitution et non à un intervalle vérifié par analyse forensic.
Flare le dit plus crûment: « Aqua a renouvelé les identifiants, mais en a oublié certains. Les accès restants ont été conservés. »
Les identifiants n'ont pas été invalidés simultanément, ce qui a permis à au moins une identité de rester utilisable pendant la délivrance des secrets de remplacement. CloudSEK en a tiré la conclusion suivante : si une identité encore active pouvait accéder aux secrets récemment renouvelés, le renouvellement individuel des jetons ne permettrait pas nécessairement d'éliminer l'intrus. En tant que séquence de remplacements de jetons plutôt que comme un événement de confinement unique touchant toutes les identités du chemin de diffusion, la rotation risque de fournir à l'attaquant ses propres résultats.
« Nous avons tout fait tourner » et « les identifiants ne fonctionnent plus » sont deux affirmations différentes. Seule la seconde est vérifiable, et celle de Beaumont est la seule vérification publique que j'ai vue à ce sujet.
La moitié que personne ne peut atteindre
Le deuxième mode de défaillance relève du modèle de divulgation plutôt que d'une victime en particulier.
Hudson Rock a résolu 118 829 « runner dumps » vers des domaines identifiés, et indique clairement ce qu’il n’a pas pu résoudre : un grand nombre de fichiers « contiennent des secrets hautement sensibles mais ne comportent aucune attribution organisationnelle claire ». Ces organisations ont des secrets actifs dans le corpus et n’ont aucun moyen de le savoir. GitGuardian a clairement exposé les conséquences le 14 août : aucune des deux entreprises ne peut avertir une société dont elle ne peut révéler le nom ; une divulgation responsable nécessite une adresse, et un exécuteur CI configuré de manière générique n’en fournit pas.
L'absence d'un outil de recherche constitue donc un indice peu probant. Si vous avez exécuté les actions Trivy concernées ou LiteLLM 1.82.7 ou 1.82.8 dans cette fenêtre, ce sont vos propres enregistrements de pipeline qui permettent de déterminer s'il y a eu exposition, et non pas la capacité d'un chercheur à associer votre exécuteur à un domaine.
Pourquoi s'agit-il de l'écart n° 2 ?
Une clé AWS, un jeton de référentiel, un compte de service Kubernetes ou une clé de fournisseur de modèles volés s’authentifient via la même interface que celle utilisée par le pipeline, à partir d’une infrastructure qui ressemble à un système d’automatisation, et effectuent les opérations que l’identité est autorisée à réaliser. Le fournisseur d’ cloud s enregistre un appel API réussi provenant d’un entité reconnue. L’authentification aboutit. Aucune exploitation n’intervient à aucun moment dans l’activité qui s’ensuit.
Lorsque les identifiants sont encore valides, le résultat de l’authentification ne vous apporte aucune information, car il s’agit d’une authentification réussie. Des signaux subsistent toutefois lors de la connexion, notamment la présence d’un réseau inconnu ou d’un client inhabituel, et il convient de signaler ces éléments. Les signaux persistants sont d’ordre comportemental : un compte de service accédant à une ressource qu’il n’a jamais utilisée, ou un jeton expiré qui continue d’être présenté et accepté. Chacun de ces éléments peut s’expliquer individuellement, mais pas dans leur ensemble.
Que faire cette semaine ?
Vérifiez la rotation plutôt que le ticket. Pour chaque classe d'informations d'identification accessible par le processus concerné, assurez-vous que l'ancienne valeur est désormais rejetée :
- Cloud clés, ainsi que tout élément lisible à partir du service de métadonnées de l'instance
- Jeton de référentiel, de registre et de publication de paquets
- Clés SSH et comptes de service Kubernetes
.envcontenus, URL de bases de données et clés des fournisseurs d'IA
L'approche proposée par Flare est celle qu'il convient d'adopter dans le cadre d'un examen de remédiation : considérer la rotation comme un exercice d'inventaire, et non comme une tâche liée à un incident. Cela ne fonctionne que si l'on dispose de l'ensemble complet des informations et, comme le souligne CloudSEK, l'absence de traces dans les journaux ne prouve pas qu'un identifiant n'ait jamais été copié.
Élargissez ensuite votre recherche à la période allant du 27 février à fin mars :
- Comptes de service Pipeline s'authentifiant sur l'environnement de production
- Répôts nommés
docs-tpcpoutpcp-docsau sein de votre propre organisation - Tout jeton émis avant avril 2026 et toujours en circulation
Le chapitre « Gap 2 » dans Mind Your Attack Gaps traite du même mode de défaillance à travers la chaîne du service d’assistance d’ Scattered Spider , où les identifiants étaient valides et la connexion s’est déroulée sans incident. Sur Vectra AI , nous modélisons le comportement d’une identité après son authentification, à travers l’ cloud, l’identité et le réseau, là où un jeton volé mais valide devient visible.
Ces archives datent du mois de mars. Pour savoir si elles sont toujours d'actualité en septembre, il suffit de consulter votre répertoire de certificats.
---
Avertissement : Vectra AI figure dans l'ensemble de données de CloudSEK. Une action GitHub Trivy compromise a été exécutée dans un sous-ensemble restreint de nos workflows CI/CD les 19 et 20 mars, exposant ainsi les métadonnées de compilation et des identifiants à durée de vie limitée propres à chaque tâche. Nous avons identifié le problème en interne, remplacé l'outil et renouvelé les identifiants concernés en quelques heures, puis nous avons revérifié nos registres à la lumière des conclusions de CloudSEK en août. Notre communiqué complet est ici.