Trivy, KICS, LiteLLM : TeamPCP souligne les failles de la chaîne logistique logicielle

Mécanismes d’exfiltration et persistance

Le payload injecté, identifié comme le « TeamPCP Cloud stealer », est conçu pour exécuter ses fonctions avant la logique de scan légitime de Trivy. Il dispose de trois stades d’opération : la collecte, le chiffrement et l’exfiltration. Le stade de collecte vise une gamme étendue de secrets disponibles dans les environnements CI/CD et sur les postes de développement, incluant les identifiants cloud (AWS, GCP, Azure), les clés SSH, les configurations Kubernetes et les clés de portefeuilles de cryptomonnaie.

Une fois les données collectées, le maliciel les chiffre et les exfiltre via deux canaux. Le canal principal utilise une requête HTTPS vers un domaine de type « typosquat » (scan.aquasecurtiy[.]org). En cas d’échec, il exploite un jeton GitHub valide pour créer un dépôt public nommé tpcp-docs et y déposer les données volées. De plus, le binaire malveillant, lorsqu’il est exécuté hors des environnements GitHub Actions, installe un résidu de persistance sous la forme d’un script systemd nommé sysmon.py, permettant aux attaquants de maintenir un accès à long terme vers des infrastructures de commande et de contrôle (C2).

Impact opérationnel et cascade sectorielle

L’impact de cette campagne s’étend bien au-delà de la compromission initiale. Au niveau de la Commission européenne, l’incident a conduit à l’exfiltration d’environ 91,7 Go de données, incluant des informations personnelles et des contenus d’emails, affectant potentiellement jusqu’à 71 entités de l’UE hébergées sur le service web « europa.eu ». Ces données ont été publiées par le groupe ShinyHunters le 28 mars 2026.

Parallèlement, l’attaque a ciblé des infrastructures critiques d’autres grands acteurs, comme Cisco, où le vol de code source et d’identifiants CI/CD a conduit au clonage de plus de 300 dépôts Git, affectant des clients de secteurs sensibles comme la finance et le gouvernement américain. L’attaque a ensuite évolué pour viser des outils de sécurité et d’infrastructure comme KICS et LiteLLM, exploitant des tokens NPM pour propager un ver (« CanisterWorm ») dans l’écosystème npm, transformant un incident localisé en une crise sectorielle.

Évolution tactique et dimension géopolitique : la campagne de destruction ciblée

La sophistication de la campagne TeamPCP ne s’arrête pas à l’exfiltration de données. Des analyses récentes ont mis en évidence une nouvelle phase de l’attaque, intégrant des mécanismes de destruction ciblée basés sur la géolocalisation. Le malware utilise des vérifications de fuseau horaire et de localisation pour identifier les cibles iraniennes, déclenchant une destruction totale des données et un redémarrage forcé. Sur les environnements Kubernetes, l’attaquant déploie une DaemonSet nommée host-provisioner-iran pour supprimer les fichiers essentiels et briser le contrôle du cluster.

Cette évolution vers la destruction active marque un tournant dans les stratégies de TeamPCP. Comme le note une analyse d’Endor Labs : « le groupe a délibérément ciblé des outils de sécurité et d’infrastructure… exploitant leur accès privilégié par nature pour déployer du code malveillant dans des environnements de production contenant des données sensibles ». Cette stratégie permet aux attaquants d’hériter de la confiance accordée aux outils et d’accéder à des secrets de haute valeur.

Recommandations opérationnelles et mesures de réponse

La réponse à cet incident nécessite une action immédiate et structurée de la part des RSSI et des équipes d’infrastructure. Les organisations doivent auditer et supprimer toute exécution de Trivy v0.69.4 ou de trivy-action via des tags de version compromis entre le 19 et le 20 mars 2026. La rotation de tous les secrets exposés est impérative, incluant les credentials cloud, les clés SSH, les jetons de publication NPM et les configurations de bases de données.

La leçon la plus importante réside dans l’abandon du recours aux tags de version pour l’ancrage des actions GitHub. Les organisations doivent désormais ancrer strictement les actions par leur hachage complet de commit (SHA). De plus, il est crucial de mettre en place une surveillance comportementale au sein des environnements de déploiement automatisés pour détecter des activités suspectes, telles que des connexions vers des domaines de typosquatting ou des appels d’API inhabituels.

L’attaque Trivy et la campagne subséquente de TeamPCP rappellent la vulnérabilité critique des chaînes logistiques logicielles modernes et la sophistication croissante des acteurs de la menace.

Même les outils de sécurité les plus utilisés peuvent devenir des vecteurs d’attaque, transformant une compromission initiale en une campagne durable et multisectorielle. La transparence, la rapidité de réponse et une adoption stricte des pratiques de sécurisation comme l’ancrage par hachage SHA sont désormais indispensables pour protéger les infrastructures critiques contre ce type de compromission. Les décideurs doivent comprendre que la simple détection des fuites ne suffit plus ; il est impératif de tracer le rayon d’effet et de s’assurer que la remédiation est granulaire pour éviter la persistance de l’attaquant.