Le scanner de vulnérabilités Trivy a été compromis lors d’une attaque de chaîne d’approvisionnement menée par un groupe de menaces connu sous le nom de TeamPCP. Cette attaque a permis la distribution de logiciels malveillants capables de dérober des identifiants via des versions officielles et des actions sur GitHub.
Utilisé par de nombreux développeurs et équipes de sécurité, Trivy est un outil essentiel pour identifier les vulnérabilités, les erreurs de configuration et les secrets exposés dans les conteneurs, les environnements Kubernetes, les dépôts de code et les infrastructures cloud, ce qui en fait une cible de choix pour les attaquants cherchant à s’emparer de données sensibles.
La découverte de cette brèche a été réalisée par le chercheur en sécurité Paul McCarty, qui a alerté sur la version 0.69.4 de Trivy, déclarée compromise avec des images de conteneurs malveillantes et des versions GitHub publiées sur le site.
Une analyse supplémentaire par Socket et par Wiz a révélé que l’attaque avait touché plusieurs actions GitHub, compromettant presque tous les tags de version du dépôt trivy-action.
Les chercheurs ont établi que les attaquants avaient réussi à altérer le processus de construction de Trivy sur GitHub, remplaçant le entrypoint.sh par une version malveillante et publiant des binaires trojanisés dans la mise à jour v0.69.4. Ces composants malveillants agissaient en tant que voleurs d’informations dans le scanner principal et ses actions associées, telles que trivy-action et setup-trivy.
Les attaquants ont exploité un identifiant compromis avec des droits d’écriture sur le dépôt, ce qui leur a permis de publier des versions malveillantes. Ces identifiants avaient été dérobés lors d’une autre brèche survenue en mars, laissant des données non maîtrisées.
Les attaquants ont remplacé 75 des 76 tags dans le dépôt aquasecurity/trivy-action, les redirigeant vers des commits malveillants. Cela a permis l’exécution automatique du code malveillant dans n’importe quel flux de travail externe utilisant les tags concernés, rendant la compromission difficile à détecter.
Selon Socket, le voleur d’informations a collecté des données de reconnaissance et a scanné les systèmes pour divers fichiers et emplacements connus pour abriter des identifiants, notamment :
- Données de reconnaissance : nom d’hôte, identifiant de l’utilisateur, configuration réseau, et variables d’environnement.
- SSH : clés privées et publiques ainsi que fichiers de configuration associés.
- Configurations cloud et infrastructures : identifiants pour Git, AWS, GCP, Azure, Kubernetes, et Docker.
- Fichiers d’environnement : .env et variantes.
- Identifiants de base de données : fichiers de configuration pour PostgreSQL, MySQL/MariaDB, MongoDB, et Redis.
- Fichiers d’identification : y compris les tokens d’authentification liés aux gestionnaires de paquets et aux services Vault.
- Configurations CI/CD : Terraform, Jenkins, GitLab CI, et fichiers similaires.
- Clés privées TLS.
- Configurations VPN.
- Webhooks : tokens Slack et Discord.
- Historique de bash.
- Fichiers systèmes : /etc/passwd, /etc/shadow, et journaux d’authentification.
- Portefeuilles de cryptomonnaies.
Source: BleepingComputer
Le script malveillant scannait également les régions de mémoire utilisées par le processus GitHub Actions Runner.Worker pour détecter les secrets d’authentification additionnels.
Sur les machines des développeurs, le binaire de Trivy trafiqué effectuait des collectes de données similaires, recueillant des variables d’environnement, scannant les fichiers locaux pour des identifiants, et répertoriant les interfaces réseau.
Les données collectées étaient cryptées et stockées dans une archive nommée tpcp.tar.gz, exfiltrée vers un serveur de commande et contrôle falsifié à scan.aquasecurtiy[.]org. En cas d’échec de l’exfiltration, le malware créait un dépôt public appelé tpcp-docs dans le compte GitHub de la victime pour y uploader les données volées.
Pour maintenir l’accès persistant sur un appareil compromis, le malware déployait également un payload Python à ~/.config/systemd/user/sysmon.py et l’enregistrait en tant que service systemd. Ce payload vérifiait la disponibilité de nouveaux payloads sur un serveur distant, permettant aux attaquants de conserver un accès constant au dispositif.
Les investigations suggèrent un lien avec TeamPCP, car l’un des payloads a une mention en commentaire de « TeamPCP Cloud stealer » à la fin du script Python. TeamPCP, également connu sous les noms de DeadCatx3, PCPcat, et ShellForce, est un acteur malveillant avéré, connu pour exploiter des API Docker mal configurées, des clusters Kubernetes, des tableaux de bord Ray, et des serveurs Redis, comme l’explique Socket.
Source: BleepingComputer
Aqua Security a confirmé l’incident, précisant qu’un acteur malveillant a utilisé des identifiants compromis d’un précédent incident non maîtrisé.
« C’était un suivi de l’incident récent (2026-03-01) qui avait impliqué l’exfiltration d’identifiants. Notre réaction à cette première brèche était incomplète, » a expliqué Aqua Security. « Nous avons remplacé des secrets et des tokens, mais le processus n’était pas atomique et les attaquants ont pu accéder à des tokens actualisés. »
La version malveillante de Trivy (v0.69.4) est restée active pendant environ trois heures, tandis que les tags GitHub compromis l’étaient jusqu’à 12 heures.
Les attaquants ont également modifié le dépôt du projet, supprimant la divulgation initiale d’Aqua Security concernant l’incident de mars.
Les organisations ayant utilisé les versions affectées au moment de l’incident doivent considérer leurs environnements comme entièrement compromis. Cela implique de remplacer tous les secrets, tels que les identifiants cloud, les clés SSH, les tokens API, et les mots de passe de base de données, et d’analyser les systèmes à la recherche de compromis supplémentaires.
Une attaque de suivi déploie CanisterWorm via npm
Des chercheurs de Aikido ont également établi un lien entre le même groupe de menaces et une campagne de suivi impliquant un nouveau ver autoréplicant nommé CanisterWorm, ciblant les paquets npm.
Ce ver compromet les paquets, installe un backdoor persistant via un service utilisateur systemd, et utilise des tokens npm dérobés pour publier des mises à jour malveillantes sur d’autres paquets.
« Venant d’un ver autoréplicant, deploy.js utilise des tokens npm, résout les noms d’utilisateur, énumère tous les paquets publiables, augmente les numéros de version, et publie le payload à travers tout le dépôt. 28 paquets en moins de 60 secondes, » soulignent les chercheurs d’Aikido.
Le malware recourt à un mécanisme décentralisé de commande et contrôle exploitant des canisters de Internet Computer (ICP), servant de résolveur de dead-drop qui fournit des URL pour d’autres payloads. Cette approche rend l’opération plus difficile à neutraliser, seul le contrôleur du canister ayant la capacité de l’éliminer, et toute tentative d’arrêt nécessitant une proposition de gouvernance et un vote réseau.
Le ver possède également la capacité de dérober des tokens d’authentification npm à partir de fichiers de configuration et de variables d’environnement, lui permettant de se répandre à travers les environnements de développement et les pipelines CI/CD.
Lors de l’analyse, une partie de l’infrastructure des payloads secondaires était inactive ou configurée avec un contenu inoffensif, mais les chercheurs avertissent que la situation pourrait évoluer à tout moment.