Quand les remparts deviennent des armes : l’attaque multi-étapes de TeamPCP contre l’infrastructure de sécurité

Avant-propos

Entre la fin février et mars 2026, TeamPCP s’en est pris à la supply chain via une série d’attaques aussi méthodiques qu’offensives. Le groupe a compromis de façon systématique plusieurs outils open source de sécurité très répandus et réputés fiables, dont les scanners de vulnérabilités Trivy et KICS, ainsi que LiteLLM, une passerelle IA très appréciée. Le SDK Python officiel de Telnyx figure lui aussi parmi les logiciels touchés.

Dans le cadre de cette campagne, des payloads malveillants d’infostealer ont été injectés directement dans des registres GitHub Actions et Python Package Index (PyPI). Une fois exécuté au sein de workflows automatisés, ce code malveillant exfiltre en toute discrétion des données hautement sensibles, parmi lesquelles :

• Des jetons d’accès au cloud
• Des clés SSH
• Des secrets Kubernetes

Ces attaques permettent également de mettre en place des backdoors persistantes, ouvrant la voie à la latéralisation entre clusters.

Parmi les logiciels concernés, citons notamment :

• BerriAI LiteLLM, une bibliothèque open source utilisée pour acheminer les requêtes entre différents fournisseurs de LLM (sa documentation fait état de plus de 95 millions de téléchargements mensuels)
• Aqua Security Trivy et Checkmarx KICS (Keeping Infrastructure as Code Secure), intégrés dans des millions de pipelines CI/CD d’entreprise
• Le SDK Python officiel de Telnyx, une plateforme mondiale de communication très répandue fournissant des API programmables pour la voix et la messagerie

D’après certaines sources, dont vx-underground, les attaquants auraient déjà exfiltré plus de 300 Go de données et de secrets depuis 500 000 machines infectées. Et de grandes organisations, tous secteurs confondus, sont ainsi confrontées à de graves attaques de second niveau.

À la différence des précédentes attaques sur la supply chain, cette opération transforme délibérément en armes des infrastructures de sécurité et de développement qui, par nature, exigent des privilèges élevés. Les attaquants accèdent ainsi sans entrave aux secrets de production, avec, à la clé, la capacité de rançonner les organisations compromises et d’exiger des paiements d’extorsion.

Le périmètre actuel de l’attaque est considérable :

• Ampleur de l’impact : l’acteur aurait exfiltré plus de 300 Go de données et 500 000 identifiants, parmi lesquels des jetons cloud et des secrets Kubernetes.
• Étendue de la compromission : au-delà des cibles initiales, TeamPCP a exploité les jetons dérobés pour infecter 48 packages supplémentaires. Le groupe a également identifié, puis divulgué, au moins 16 organisations victimes sur des sites de fuite publics.
• Sophistication : les attaquants ont déployé CanisterWorm, qui repose à la fois sur une architecture CnC décentralisée et sur des composants destructeurs ciblés de type wiper. Un mode opératoire qui illustre une montée en gamme technique, résolument tournée vers les opérations cloud natives.

Au 27 mars 2026, Palo Alto Networks Cortex Xpanse avait identifié la présence de trois certificats autosignés distincts, associés aux trois vagues d’opérations.

Les clients de Palo Alto Networks sont mieux protégés contre les menaces décrites dans cet article grâce aux produits et services suivants :

• Advanced Threat Prevention
• Cortex XDR et XSIAM
• Cortex Cloud
• Cortex Xpanse
• Cortex Agentix Threat Intel Agent

Palo Alto Networks recommande également de prendre les mesures nécessaires pour identifier les packages vulnérables et renforcer les politiques CI/CD, comme indiqué dans la section Recommandations provisoires.

L’offre Unit 42 Cloud Security Assessment est un service d’évaluation qui examine l’infrastructure cloud afin d’identifier les erreurs de configuration et les failles de sécurité.

L’équipe de réponse à incident d’Unit 42 peut également intervenir en cas de compromission ou réaliser une évaluation proactive afin de réduire votre niveau de risque.

Étendue actuelle de l’attaque sur la supply chain

TeamPCP (également suivi sous les noms PCPcat, ShellForce et DeadCatx3) mène des opérations depuis au moins septembre 2025. Le groupe s’est fait connaître en décembre 2025, dans le sillage de la vaste campagne React2Shell visant les environnements cloud.

Cette campagne exploitait la vulnérabilité React2Shell (CVE-2025-55182), permettant au groupe de tirer parti d’une exécution de code à distance (RCE) sur des terminaux cloud vulnérables. Au cours de ces opérations, l’un des artefacts de détection les plus révélateurs du groupe, aux côtés des indicateurs d’exploitation React2Shell déjà bien documentés, résidait dans l’utilisation du port 666 pour la quasi-totalité de ses activités d’exploitation.

La trajectoire du groupe a ensuite rapidement évolué. D’abord centré sur le ransomware, TeamPCP puise aussi ses origines dans le mining et le vol de cryptos. Depuis la mi-mars 2026, il s’est plus récemment orienté vers des opérations opportunistes de compromission de la supply chain, menées selon une logique « smash-and-grab ».

Récemment, le rythme des activités du groupe s’est accéléré. TeamPCP a multiplié ses publications, aussi bien sur sa chaîne Telegram que sur son site de fuite hébergé sur le dark web.

Dans ses annonces les plus récentes, le groupe affirme unir ses forces à CipherForce, un autre groupe de ransomware, pour publier des informations relatives à des compromissions. Par ailleurs, un message publié sur BreachForums – site fréquenté par les cybercriminels pour échanger sur les activités de piratage et les violations de données – indique que le groupe s’est également associé au groupe de ransomware Vect (voir la figure 1).

Ce partenariat devrait permettre à TeamPCP de concentrer davantage ses efforts sur les opérations de supply chain. Fin mars, le groupe revendiquait déjà la compromission d’au moins 16 organisations, comme le montre la figure 2.

Aqua Security Trivy

Cette dernière campagne a débuté le 19 mars 2026, lorsque TeamPCP a exploité une rotation incomplète des identifiants à la suite d’une compromission mineure survenue fin février dans le dépôt GitHub d’Aqua Security Trivy.

TeamPCP a compromis le compte de service aqua-bot et mené une attaque par imposter commit. Le groupe a ainsi injecté, via force-push, du code malveillant dans 76 des 77 tags de version du dépôt aquasecurity/trivy-action, ainsi que dans l’ensemble des tags d’aquasecurity/setup-trivy.

Cette première vague a introduit le payload principal de TeamPCP, baptisé « TeamPCP cloud stealer ». Celui-ci s’exécutait par l’intermédiaire du script kamikaze.sh, qui a ensuite évolué en trois versions distinctes :

• Version 1 – Architecture monolithique : un script bash de 150 lignes centré sur le fingerprinting de l’environnement et la collecte immédiate d’identifiants AWS/GCP/Azure via l’instance metadata service (IMDS) du terminal compromis. Pour contourner le masquage des secrets de GitHub, le script lisait directement la mémoire du processus runner.worker via /proc/<pid>/mem afin d’extraire les jetons en clair.
• Version 2 – Architecture modulaire : deux heures après le premier déploiement de la v1, TeamPCP a remplacé ce script initial par un loader allégé de 15 lignes. Cette version utilisait une méthode pull pour télécharger, en deuxième étape, un payload nommé « kube.py ». Les acteurs pouvaient ainsi faire évoluer le payload sans avoir à réempoisonner les tags GitHub. La version 2 introduisait également une commande d’auto-suppression, rm – “$0”, destinée à s’effacer après exécution.
• Version 3 – Le ver et le wiper : dans cette dernière version connue, le script a évolué vers un code malveillant doté de capacités d’auto-réplication, dans le cadre d’une campagne baptisée « CanisterWorm ». Nous reviendrons plus en détail sur CanisterWorm plus loin. La version 3 permettait de scanner les API Docker exposées, le port 2375 ainsi que le sous-réseau local. Elle permettait également de collecter des clés SSH.

Cette opération se distingue par un degré de tromperie particulièrement abouti. Le code malveillant s’exécutait, par exemple, avant même que la logique légitime d’analyse de Trivy n’entre en jeu – tout en laissant simultanément le scanner poursuivre son fonctionnement normal. Résultat : les opérations d’analyse affichaient un statut apparemment sain alors qu’en coulisses, le malware exfiltrait discrètement des données vers le domaine typosquatté scan.aquasecurtiy[.]org. En cas de défaillance du serveur CnC principal, le payload basculait sur le domaine de secours tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0[.]io.

En parallèle, à l’aide de jetons de publication npm récupérés lors de la première vague de compromissions visant Trivy, les acteurs liés à TeamPCP ont déclenché un script automatisé qui a identifié puis infecté 47 packages supplémentaires au sein des espaces de noms @emilgroup, @opengov et @v7. D’après l’ensemble des éléments disponibles, ces opérations se seraient déroulées en moins de 60 secondes.

L’infection reposait sur l’injection d’un script malveillant de type pre-install ou post-install dans le fichier package.json de chaque bibliothèque. Ce mécanisme garantissait l’exécution immédiate du payload TeamPCP cloud stealer dès lors qu’un développeur ou un runner CI/CD lançait un npm install incluant l’un de ces packages npm empoisonnés. Un runner CI/CD est un agent léger, ou une application légère, chargé d’exécuter les tâches d’un pipeline logiciel.

Cette vague s’est largement appuyée sur une technique dite de « SDK-squatting », en ciblant des kits de développement internes utilisés pour des services de facturation, d’assurance et de comptabilité. Une approche qui augmentait fortement les chances de voir le malware s’introduire dans des environnements d’entreprise à privilèges élevés.

Chaque package infecté agissait alors comme un nouveau nœud de télémétrie, procédant au fingerprinting de l’environnement et tentant d’exfiltrer les données contenues dans les fichiers .env locaux ainsi que dans les répertoires de configuration AWS et Azure vers l’infrastructure CnC du groupe. En pratique, une compromission initialement circonscrite à un seul fournisseur s’est ainsi muée en risque systémique de la supply chain, potentiellement à grande échelle, pour tous les utilisateurs en aval de ces SDK privés comme publics.

Checkmarx KICS

À la suite de la compromission initiale d’Aqua Security Trivy, TeamPCP a utilisé, le 21 mars 2026, des GitHub Personal Access Tokens (PAT) dérobés pour cibler Checkmarx KICS. KICS est un scanner open source d’infrastructure as code (IaC).

Les attaquants ont injecté, via force-push, des commits malveillants dans l’ensemble des 35 tags de version du dépôt checkmarx/kics-github-action, et empoisonné la version 2.3.28 de checkmarx/ast-github-action. Sur le plan technique, l’opération a consisté à détourner l’entrypoint officiel du conteneur (setup.sh) pour y substituer un payload en trois étapes baptisé « TeamPCP cloud stealer ».

Ce payload présente des fonctionnalités similaires à celles observées lors de la vague visant Trivy. Afin d’échapper à une détection manuelle, le malware exfiltrait les données volées vers le domaine typosquatté checkmarx[.]zone, construit dans l’univers de marque du fournisseur. Il intégrait également un mécanisme de repli secondaire : en cas d’échec des communications CnC principales, le payload utilisait le propre GITHUB_TOKEN de la victime pour créer un dépôt caché, nommé « docs-tpcp », au sein de son organisation GitHub.

LiteLLM

Le 23 mars 2026, TeamPCP a délaissé les GitHub Personal Access Tokens (PAT) pour cibler, via BerriAI LiteLLM, des jetons de publication PyPI. Le groupe aurait vraisemblablement récupéré ces jetons lors d’une compromission antérieure du scanner de vulnérabilités Trivy. Les attaquants ont empoisonné le pipeline CI/CD de LiteLLM afin de permettre la publication sur PyPI de versions malveillantes, les v1.82.7 et v1.82.8.

Cette vague a introduit une méthode d’exécution particulièrement furtive, reposant sur un fichier .pth nommé « litellm_init.pth » dans la version 1.82.8. Dans la mesure où l’interpréteur Python traite automatiquement les fichiers .pth au démarrage, le malware s’exécutait à chaque initialisation d’un processus Python sur un hôte – que LiteLLM ait été importé ou non. Une mécanique qui a permis à TeamPCP d’élargir sensiblement le champ des victimes potentielles.

Le payload, conçu en plusieurs étapes, reposait sur un script doublement encodé en Base64 afin de déjouer l’analyse statique. Il agissait comme un véritable outil de ratissage des secrets, en collectant notamment :

• des clés SSH ;
• les identifiants cloud (AWS, Google Cloud, Azure) ;
• les fichiers de configuration Kubernetes ;
• et, fait particulièrement critique, les variables d’environnement contenant des clés d’API de LLM (par exemple OPENAI_API_KEY, ANTHROPIC_API_KEY)

La figure 3 ci-dessous en présente un exemple sous la forme d’un extrait de code.

Au sein de ce premier encodage Base64 se trouvait un second bloc, lui aussi encodé en Base64, qui fournissait le terminal CnC destiné aux commandes de commande et contrôle. La figure 4 montre le code écrit dans le chemin /host/root/.config/sysmon/sysmon.py.

Les données exfiltrées étaient traitées selon le même schéma que lors de la vague Checkmarx : elles étaient chiffrées à l’aide d’une clé de session AES-256-CBC, elle-même protégée par une clé publique RSA 4096 bits codée en dur. Pour le terminal CnC d’exfiltration lié à LiteLLM, les attaquants ont utilisé le domaine typosquatté models.litellm[.]cloud. Le code présenté dans la figure 5 illustre le sous-processus chargé de l’exfiltration des données collectées.

La liste ci-dessous recense l’ensemble des domaines CnC d’exfiltration connus au 27 mars 2026 :

• scan.aquasecurtiy[.]org
• checkmarx[.]zone
• models.litellm[.]cloud
• tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0[.]io

Telnyx

Le 27 mars 2026, TeamPCP a compromis le SDK Python de Telnyx. L’opération s’inscrit dans une logique proche de celle observée avec LiteLLM : l’acteur de la menace a détourné des identifiants de publication PyPI afin de mettre en ligne les versions malveillantes 4.87.1 et 4.87.2 du package telnyx.

Ces versions embarquent, dans la bibliothèque cliente, un injecteur furtif qui s’exécute dès l’import afin d’exfiltrer des identifiants cloud et des secrets système. L’attaque utilise la stéganographie dans des fichiers WAV pour dissimuler des payloads chiffrés de deuxième étape au sein de fichiers audio légitimes, permettant ainsi au malware de contourner les filtres réseau tout en établissant sa persistance sur des systèmes Windows, Linux et macOS.

Le fichier audio Windows portait le nom hangup.wav, codé en dur, tandis que le fichier audio Linux utilisait le nom « ringtone.wav », lui aussi codé en dur. Cette campagne cible plus particulièrement les outils d’infrastructure et de communication afin de dérober des jetons d’accès à forte valeur et des clés de compte de service, en vue d’une exploitation plus large des clusters.

CanisterWorm

CanisterWorm s’appuie, pour son C2, sur un canister décentralisé fondé sur l’Internet Computer Protocol (ICP), offrant ainsi un dead-drop inviolable pour la livraison des payloads et résistant aux opérations classiques de démantèlement visant les vers informatiques. Au-delà du vol d’identifiants et de l’établissement d’une persistance, les acteurs de la menace ont également maquillé leur activité en services légitimes tels que systemd, tout en dissimulant la menace sous l’apparence d’un utilitaire PostgreSQL baptisé pgmon.

La campagne a récemment intégré un composant destructeur de type wiper, observé le 23 mars 2026 dans des opérations visant l’Iran. Celui-ci apparaît dans les blocs de code extraits du fichier kube.py présentés dans les figures 6 et 7.

Ce payload de deuxième étape procède au fingerprinting de l’environnement afin d’identifier les clusters Kubernetes, puis déploie des DaemonSets privilégiés capables de neutraliser des clusters entiers, ou exécute des suppressions récursives de fichiers sur des hôtes non conteneurisés. La combinaison de cette propagation automatisée, d’une infrastructure décentralisée et d’une capacité de destruction ciblée fait de CanisterWorm l’une des menaces cloud natives les plus complexes identifiées à ce jour – en dépit d’un historique opérationnel aussi bruyant qu’éphémère.

Recommandations provisoires

Renforcer les actifs cloud face aux attaques de la supply chain

Cortex Cloud propose de vastes capacités de gestion de la posture de sécurité des applications (ASPM) et de sécurisation de la supply chain, afin d’aider les organisations à identifier les vulnérabilités et les erreurs de configuration sur lesquelles TeamPCP s’appuie. Les recommandations ci-dessous comportent également certaines indications propres aux produits Palo Alto Networks. Nous recommandons à toutes les organisations de mettre en place un dispositif adapté pour renforcer leurs actifs cloud selon les principes décrits ici.

(Remarque : les clients Prisma Cloud qui n’ont pas encore migré vers Cortex Cloud doivent appliquer les mêmes mesures de précaution.)

1. Identifier les packages vulnérables : analyse de composition logicielle (SCA) et nomenclature logicielle (SBOM)

Dans la mesure où l’attribution de CVE à ces packages malveillants peut intervenir après le début de l’attaque, les organisations doivent s’appuyer sur une visibilité en temps réel de leur SBOM.

• Modèle de risque opérationnel : pour les packages dépourvus de CVE publiées, le modèle propriétaire Operational Risk de Palo Alto Networks apporte un niveau de protection supplémentaire. Il évalue les packages open source à partir de critères tels que l’activité des mainteneurs, le statut d’obsolescence et le niveau d’adoption par la communauté, ce qui permet d’identifier les composants à risque même en l’absence de vulnérabilités connues.
• Interrogation de la SBOM : Cortex Cloud permet d’interroger la SBOM de votre organisation à partir de la liste des packages malveillants connus afin d’identifier immédiatement l’impact.

2. Renforcer les politiques CI/CD : règles prêtes à l’emploi

TeamPCP prospère dans les environnements insuffisamment sécurisés et exposés. Les clients Palo Alto Networks peuvent s’appuyer sur les règles CI/CD prêtes à l’emploi (OotB) de Cortex Cloud ci-dessous, conçues pour prévenir ce type d’attaques. Ces règles s’alignent sur des référentiels du secteur tels que les 10 principaux risques de sécurité CI/CD identfiés par l’OWASP et le Guide CIS de la sécurité de la supply chain logicielle.

• Packages installés de manière non sécurisée : dans des configurations courantes, GitHub comme npm peuvent distribuer des versions mises à jour de packages sans en vérifier l’intégrité. Cette faille ouvre la voie à des attaquants ayant pris le contrôle d’un dépôt, qui peuvent alors publier une version malveillante d’un package autorisé pour le téléchargement automatique. Il est donc essentiel, pour les organisations, d’accorder leur confiance tout en vérifiant systématiquement chaque package. Dans les pipelines CI/CD modernes, l’analyse de l’ensemble des packages avant leur mise en œuvre est indispensable.
• Package npm téléchargé depuis git sans référence à un hash de commit : en l’absence de hash de commit précis, l’intégrité d’un package téléchargé depuis une URL git ne peut pas être garantie, ce qui peut conduire un serveur de build à récupérer une version malveillante.
• Projet npm contenant des dépendances inutilisées : des dépendances inutilisées élargissent inutilement la surface d’attaque. Si l’une d’elles est compromise par TeamPCP, le projet se retrouve exposé – même si le code concerné n’est jamais utilisé activement.

Requêtes de l'équipe threat hunting managé d’Unit 42

L’équipe de services managés de traque des menaces (MTH) d’Unit 42 recommande les requêtes XQL ci-dessous. Les clients Cortex XDR et XSIAM peuvent utiliser ces requêtes pour rechercher d’éventuels indicateurs d’exploitation.

Conclusion

Face à l’escalade rapide des opérations de supply chain menées par TeamPCP, Palo Alto Networks recommande vivement aux organisations d’auditer sans délai, dans leurs environnements de développement comme de production, les éléments suivants :

• Les pipelines CI/CD
• Les GitHub Personal Access Tokens (PAT)
• Les identifiants des fournisseurs cloud
• Les jetons de compte de service Kubernetes (SAT)
• Les clés SSH utilisées dans les environnements conteneurisés

Entre février et mars 2026, cet acteur est passé du ransomware et du cryptominage à un modèle de compromission de la supply chain ciblé et structuré. Cette opération a déjà permis de compromettre des outils de sécurité de confiance comme Aqua Security Trivy et Checkmarx KICS, ainsi que la passerelle BerriAI LiteLLM.

Les organisations doivent accorder la priorité à la mise en œuvre des recommandations immédiates formulées dans ce bulletin, en particulier celles relatives à la visibilité sur la SBOM et au renforcement des politiques CI/CD, afin de réduire les risques de latéralisation et d’exfiltration de données.

Les clients Palo Alto Networks bénéficient d’une protection renforcée grâce à nos solutions, comme détaillé ci-dessous. Nous mettrons à jour ce Bulletin sécurité au fur et à mesure de l’évolution de la situation et de l’arrivée de nouvelles informations pertinentes.

Protections des produits Palo Alto Networks contre l’attaque en plusieurs étapes de la supply chain de TeamPCP

Les clients Palo Alto Networks peuvent s’appuyer sur un large éventail de protections intégrées aux produits et de mises à jour pour identifier et contrer cette menace.

Les bonnes pratiques prêtes à l’emploi (OotB) de Cortex Cloud en matière de sécurité de la supply chain sont conçues pour détecter, au sein d’un environnement, l’utilisation de pipelines CI/CD Trivy et LiteLLM non épinglés, et générer les alertes appropriées. Nous encourageons les organisations à épingler des versions de packages précises et connues pour leurs applications de supply chain.

La figure 8 montre ce que la plateforme Cortex Cloud affiche lors de la consultation des catalogues Supply Chain pour Trivy, Checkmarx et LiteLLM. La figure 9 présente l’affichage de la couverture Application Security pour les actifs d’un environnement. La figure 10 met en évidence des détections notables de secrets présents dans des ressources cloud potentiellement vulnérables.

L’offre Unit 42 Cloud Security Assessment est un service d’évaluation qui examine l’infrastructure cloud afin d’identifier les erreurs de configuration et les failles de sécurité.

Vous pensez que votre entreprise a été compromise ? Vous devez faire face à une urgence ? Contactez l’équipe Unit 42 de réponse à incident ou composez l’un des numéros suivants :

• Amérique du Nord : Gratuit : +1 (866) 486-4842 (866.4.UNIT42)
• Royaume-Uni : +44 20 3743 3660
• Europe et Moyen-Orient : +31.20.299.3130
• Asie : +65.6983.8730
• Japon : +81 50 1790 0200
• Australie : +61.2.4062.7950
• Inde : 000 800 050 45107
• Corée du Sud : +82.080.467.8774

Cloud-Delivered Security Services pour les Next-Generation Firewall

Advanced URL Filtering et Advanced DNS Security permettent d’identifier les domaines et URL associés à cette activité comme étant malveillants.

Cortex AgentiX

Les analystes sécurité peuvent utiliser le langage naturel pour interroger l’agent Cortex AgentiX Threat Intel et lui demander d’extraire, à partir de ce briefing sécurité, les indicateurs de compromission (IoC) liés aux fichiers. Les organisations devront ensuite enrichir le dossier et maintenir une vigilance active dans leur tenant Cortex vis-à-vis des alertes associées. L’agent AgentiX fournira une synthèse rapide de l’impact potentiel pour l’organisation. Les analystes peuvent également s’appuyer sur l’agent Case Investigation pour obtenir davantage de détails sur les dossiers et artefacts liés à cette campagne et, le cas échéant, élaborer un plan de réponse.

Cortex XDR et XSIAM

Cortex XDR et XSIAM offrent une défense multicouche – incluant Behavioral Threat Protection (BTP), Advanced WildFire et Cortex Analytics – pour aider à protéger contre l’accès initial, le C2 et le mouvement latéral potentiel décrits dans cet article.

Cortex Xpanse

Cortex Xpanse permet d’identifier les appareils LiteLLM exposés sur Internet et d’alerter les équipes de défense. Les clients peuvent activer l’alerte associée à ce risque en veillant à ce que la règle LiteLLM Attack Surface Rule soit bien activée. Les incidents identifiés peuvent être consultés dans le Threat Response Center ou dans la vue incident d’Expander. Ces résultats sont également disponibles pour les clients Cortex XSIAM ayant souscrit au module ASM.

Cortex Cloud

• Les clients Cortex Cloud bénéficient d’une meilleure protection contre les abus présentés dans cet article grâce au déploiement approprié de l’agent de terminaux XDR de Cortex Cloud et des agents serverless au sein de leur environnement cloud. Conçu pour protéger la posture de sécurité du cloud et ses opérations en exécution face à ces menaces, Cortex Cloud aide à détecter et à prévenir les opérations malveillantes, les modifications de configuration ou les exploitations évoquées dans cet article.
• Cortex Cloud Identity Security, qui regroupe les fonctions de gestion des droits sur l’infrastructure cloud (CIEM), de gestion de la posture de sécurité des identités (ISPM), de gouvernance des accès aux données (DAG) ainsi que la détection et réponse aux menaces sur les identités (ITDR). Cette solution offre aux organisations les capacités nécessaires pour renforcer la sécurité liée aux identités : Les modules d’Identity Security offrent visibilité complète sur les identités et leurs permissions dans les environnements cloud, détection précise des configurations erronées et identification des accès indésirables aux données sensibles Ils fournissent également une analyse en temps réel des usages et des schémas d’accès, au service d’une surveillance de sécurité continue.
• Le module Application Security de Cortex Cloud (ASPM) prend en charge l’ingestion des journaux d’audit de sécurité et des détections issus de fournisseurs SaaS tiers mentionnés dans cet article, tout en permettant de prioriser les alertes, incidents, politiques et actifs en fonction des applications ingérées. Les équipes sécurité peuvent ainsi renforcer leur visibilité globale sur leurs environnements on-prem et cloud – et être alertées sur les menaces décrites ici.

Next-Generation Firewall avec Advanced Threat Prevention

La fonctionnalité Advanced Threat Prevention des Next-Generation Firewall (NGFW) peut aider à prévenir l'exfiltration de données via la signature Threat Prevention 87120.

Indicateurs de compromission

Adresses IP

• 23.142.184[.]129
• 45.148.10[.]212
• 63.251.162[.]11
• 83.142.209[.]11
• 83.142.209[.]203
• 195.5.171[.]242
• 209.34.235[.]18
• 212.71.124[.]188

Domaines

• checkmarx[.]zone
• models.litellm[.]cloud
• scan.aquasecurtiy[.]org
• tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0[.]io

URL de tunneling

• championships-peoples-point-cassette.trycloudflare[.]com
• create-sensitivity-grad-sequence.trycloudflare[.]com
• investigation-launches-hearings-copying.trycloudflare[.]com
• plug-tab-protective-relay.trycloudflare[.]com
• souls-entire-defined-routes.trycloudflare[.]com

Hacchages SHA256 des certificats autosignés utilisés par le malware

• 30015DD1E2CF4DBD49FFF9DDEF2AD4622DA2E60E5C0B6228595325532E948F14
• 41C4F2F37C0B257D1E20FE167F2098DA9D2E0A939B09ED3F63BC4FE010F8365C
• D8CAF4581C9F0000C7568D78FB7D2E595AB36134E2346297D78615942CBBD727

Noms de fichiers

• kamikaze[.]sh
• kube[.]py
• prop[.]py
• proxy_server[.]py
• tpcp.tar[.]gz

Hachages SHA256 des fichiers malveillants

• 0880819ef821cff918960a39c1c1aada55a5593c61c608ea9215da858a86e349
• 0c0d206d5e68c0cf64d57ffa8bc5b1dad54f2dda52f24e96e02e237498cb9c3a
• 0c6a3555c4eb49f240d7e0e3edbfbb3c900f123033b4f6e99ac3724b9b76278f
• 18a24f83e807479438dcab7a1804c51a00dafc1d526698a66e0640d1e5dd671a
• 1e559c51f19972e96fcc5a92d710732159cdae72f407864607a513b20729decb
• 5e2ba7c4c53fa6e0cef58011acdd50682cf83fb7b989712d2fcf1b5173bad956
• 61ff00a81b19624adaad425b9129ba2f312f4ab76fb5ddc2c628a5037d31a4ba
• 6328a34b26a63423b555a61f89a6a0525a534e9c88584c815d937910f1ddd538
• 7321caa303fe96ded0492c747d2f353c4f7d17185656fe292ab0a59e2bd0b8d9
• 7b5cc85e82249b0c452c66563edca498ce9d0c70badef04ab2c52acef4d629ca
• 7df6cef7ab9aae2ea08f2f872f6456b5d51d896ddda907a238cd6668ccdc4bb7
• 822dd269ec10459572dfaaefe163dae693c344249a0161953f0d5cdd110bd2a0
• 887e1f5b5b50162a60bd03b66269e0ae545d0aef0583c1c5b00972152ad7e073
• bef7e2c5a92c4fa4af17791efc1e46311c0f304796f1172fce192f5efc40f5d7
• c37c0ae9641d2e5329fcdee847a756bf1140fdb7f0b7c78a40fdc39055e7d926
• cd08115806662469bbedec4b03f8427b97c8a4b3bc1442dc18b72b4e19395fe3
• d5edd791021b966fb6af0ace09319ace7b97d6642363ef27b3d5056ca654a94c
• e4edd126e139493d2721d50c3a8c49d3a23ad7766d0b90bc45979ba675f35fea
• e6310d8a003d7ac101a6b1cd39ff6c6a88ee454b767c1bdce143e04bc1113243
• e64e152afe2c722d750f10259626f357cdea40420c5eedae37969fbf13abbecf
• e87a55d3ba1c47e84207678b88cacb631a32d0cb3798610e7ef2d15307303c49
• e9b1e069efc778c1e77fb3f5fcc3bd3580bbc810604cbf4347897ddb4b8c163b
• ecce7ae5ffc9f57bb70efd3ea136a2923f701334a8cd47d4fbf01a97fd22859c
• f398f06eefcd3558c38820a397e3193856e4e6e7c67f81ecc8e533275284b152
• f7084b0229dce605ccc5506b14acd4d954a496da4b6134a294844ca8d601970d

Mis à jour le 9 avril 2026 à 8h00 PT pour ajouter la couverture Advanced Threat Prevention.