Parce que… c’est l’épisode 0x737!

Shameless plug

• 14 au 17 avril 2026 - Botconf 2026
• 20 au 22 avril 2026 - ITSec
  • Code rabais de 15%: Seqcure15
• 28 et 29 avril 2026 - Cybereco Cyberconférence 2026
• 9 au 17 mai 2026 - NorthSec 2026
• 3 au 5 juin 2026 - SSTIC 2026
• 19 septembre 2026 - Bsides Montréal
• 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026
• 24 et 25 février 2027 - SéQCure 2027

Description

Contexte et rappel de l’épisode précédent

Dans cet épisode technique, l’animateur reçoit à nouveau François Proulx pour faire le point sur une cyberattaque majeure dont les développements ont explosé depuis leur dernière conversation. L’épisode précédent portait sur une première attaque contre Trivy, un outil d’analyse de sécurité open source développé par l’entreprise israélienne Aqua Security. Trivy est massivement utilisé par de grandes entreprises pour inventorier les composants open source d’un projet (SBOM) et identifier les vulnérabilités associées (CVE). C’est précisément cette popularité qui en a fait une cible de choix.

La deuxième vague : une réponse aux incidents incomplète

À peine 20 jours après l’attaque initiale de fin février, Trivy a été compromis une seconde fois. La raison : Aqua Security n’avait pas révoqué la totalité des jetons d’accès (tokens) lors de sa réponse aux incidents. L’entreprise a attendu plusieurs jours avant de faire appel à une firme externe (Mend), ce qui lui a valu des critiques. Dans leur communiqué, ils ont admis avoir oublié de révoquer un token — et pas n’importe lequel : il s’agissait d’un token encore plus privilégié que celui utilisé lors de la première attaque, donnant accès à des dépôts privés internes contenant potentiellement de la propriété intellectuelle sensible.

Cette deuxième attaque a été encore plus dévastatrice : non seulement Trivy a été empoisonné à nouveau, mais les GitHub Actions associées — des composants permettant d’intégrer Trivy dans des pipelines CI/CD — ont également été corrompues, y compris les versions antérieures. Ainsi, des organisations qui croyaient utiliser une version sûre et ancienne se sont retrouvées exposées sans le savoir.

Une propagation en cascade

Le vecteur initial était une vulnérabilité dans un workflow GitHub Actions du dépôt de Trivy, simple à exploiter mais peu connue. Les attaquants ont obtenu un token leur permettant de compiler et distribuer une version malveillante de Trivy sur les registres officiels — sans modifier le code source visible, ce qui rendait la détection plus difficile.

Lorsque Trivy s’exécutait dans le pipeline CI/CD d’une entreprise victime, il agissait comme un info stealer : il exfiltrait les secrets et tokens présents dans l’environnement d’exécution. Ces tokens volés ont ensuite servi à compromettre d’autres projets, créant une chaîne de contamination à plusieurs niveaux :

• Premier ordre : Trivy lui-même, compromis chez Aqua Security.
• Deuxième ordre : les entreprises utilisant Trivy dans leurs pipelines, dont Checkmarx, un autre outil de sécurité applicative.
• Troisième ordre : des projets open source très populaires comme LiteLLM, une bibliothèque d’interfaçage avec des API de modèles de langage (LLM), dont le mainteneur semble avoir été compromis directement via son poste de travail.

Environ 72 heures après l’attaque, des entreprises ont commencé à signaler publiquement que leurs tokens avaient été exfiltrés et réutilisés contre elles.

Les attaquants se dévoilent

Durant le week-end du 20 mars, le groupe responsable s’est révélé sur Twitter sous le nom Team PCP, en défaçant des dépôts GitHub pour prouver leurs accès. Ils ont ensuite établi des partenariats avec des groupes spécialisés dans les rançongiciels pour monétiser les accès obtenus — une évolution logique pour des acteurs en possession de téraoctets de secrets volés.

Le FBI a officiellement nommé ce groupe et demandé à toutes les entreprises américaines victimes de déposer plainte. Selon François Proulx, le profil comportemental des attaquants — messages puérils, communication sur Telegram, manière de se vanter publiquement — laisse fortement penser qu’il s’agit d’adolescents, probablement situés hors du territoire américain, ce qui complique les poursuites.

Pour entraver les équipes de réponse aux incidents, les attaquants ont utilisé des centaines de comptes GitHub légitimes achetés sur le marché noir (probablement issus de logs d’info stealers) pour inonder les fils de discussion d’incidents avec des commentaires génériques automatisés, rendant toute coordination difficile.

Le problème structurel des dépendances transitives

François Proulx soulève un enjeu critique lié à l’écosystème npm : la façon dont les contraintes de version sont définies dans les fichiers package.json. Lorsqu’une dépendance est déclarée de manière vague (ex. : axios: ^1.x), une mise à jour de routine peut automatiquement introduire une version compromise sans que le développeur s’en rende compte. La bibliothèque Axios, extrêmement populaire, a notamment été touchée dans cette attaque.

Même avec un fichier de verrouillage (lock file), le risque n’est pas nul : une alerte de hash incohérent pourrait être ignorée ou, pire, conduire un développeur à régénérer le lock file en gelant ainsi la version malveillante.

Ce que les développeurs peuvent faire

François Proulx recommande deux mesures concrètes :

1. Utiliser des outils de vérification en temps réel qui interceptent les téléchargements de composants npm ou PyPI pour les comparer à des listes de composants malveillants mises à jour plusieurs fois par heure.
2. Adopter une période de gel (cool-off period) avant d’utiliser une nouvelle version d’une dépendance, afin de laisser à la communauté le temps de détecter d’éventuels problèmes.

Il mentionne également Bagle, leur propre outil open source d’analyse locale, qui permet de détecter des secrets mal stockés sur un poste de travail (variables d’environnement, fichiers temporaires, etc.) sans rien envoyer à l’extérieur.

Conclusion

Au moment de l’enregistrement, le 2 avril, l’attaque était toujours en cours. Une grande partie des victimes ne sait même pas encore qu’elle a été compromise. Les semaines à venir risquent de révéler l’ampleur réelle des dégâts, notamment via les dépendances transitives. Cet épisode illustre à quel point la sécurité de la chaîne d’approvisionnement logicielle reste largement sous-estimée — et que ce réveil collectif, bien que douloureux, était peut-être nécessaire.

Notes

• Teknik - Hackerbot-claw

Collaborateurs

• Nicolas-Loïc Fortin
• François Proulx

Crédits

• Montage par Intrasecure inc
• Locaux virtuels par Riverside.fm

Tags: malware, supplychain