Anatomie du ver Python qui manipule les agents de sécurité IA

Êtes-vous arrivé à un point où vous faites plus confiance à votre assistant de code IA qu'à votre propre révision manuelle ? De nombreux développeurs le sont. Nous comptons sur les grands modèles de langage (LLM) pour rechercher des vulnérabilités, suggérer des correctifs et vérifier l'intégrité des packages tiers. Mais que se passe-t-il lorsque le logiciel malveillant sait comment répondre à l'IA ? J'ai passé plusieurs nuits la semaine dernière à examiner les détails techniques de la campagne Hades, une menace qui marque un changement dans la manière dont les attaquants abordent les défenses automatisées. Il ne s'agit pas seulement d'un voleur de données. C'est une opération psychologique dirigée contre les logiciels que nous utilisons pour nous protéger.

Des chercheurs de StepSecurity ont récemment identifié cette campagne comme étant le dernier travail du groupe d'acteurs de menaces Miasma. Alors que Miasma se concentrait auparavant sur la collecte d'identifiants cloud, Hades est un ver auto-propageable plus agressif. Il cible spécifiquement les environnements de développement Python via des packages compromis dans l'écosystème PyPI. La liste des bibliothèques concernées comprend ensmallen, mflux-streamlit et plusieurs outils utilisés en bioinformatique. Si vous travaillez en biologie computationnelle ou en science des données, votre station de travail est une cible de haute valeur pour ce groupe spécifique.

Le point d'entrée dans le processus d'initialisation de Python

L'attaque commence lorsqu'un développeur importe un package compromis. Hades cache son chargeur primaire à l'intérieur du fichier __init__.py. C'est un fichier standard que Python utilise pour marquer un répertoire comme un package. En plaçant le script malveillant ici, les attaquants s'assurent que le code s'exécute au moment même où le package est chargé dans un projet. Le chargeur est obfusqué pour éviter la détection basique basée sur les signatures, mais son but est simple. Il dépose un binaire d'exécution Bun précompilé sur le système.

Bun est une boîte à outils JavaScript haute performance. C'est un excellent outil pour les développeurs légitimes, mais c'est aussi un moteur d'exécution parfait pour les logiciels malveillants. Parce que Bun est un binaire autonome, il permet au malware d'exécuter des charges utiles JavaScript complexes sans nécessiter d'installation de Node.js sur la machine de la victime. Cela contourne la surveillance traditionnelle qui recherche les activités suspectes de npm ou Node. D'un point de vue architectural, l'utilisation de Bun permet aux attaquants d'opérer dans un environnement fantôme qui se situe en dehors de la visibilité de sécurité standard de la plupart des stations de travail centrées sur Python.

Comment le malware manipule le gardien automatisé

La caractéristique la plus innovante de Hades est sa capacité à mentir aux agents de sécurité IA. De nombreux environnements de développement modernes utilisent des LLM pour scanner le code à la recherche de modèles malveillants. Hades anticipe cela. En haut de ses fichiers malveillants, le logiciel malveillant inclut un bloc de texte conçu comme un prompt adverse. Ce texte ordonne au LLM d'ignorer tout code suspect trouvé en dessous et de classer le package comme vérifié et sûr.

J'ai testé une technique similaire dans un environnement bac à sable le mois dernier. J'ai fourni à un LLM un script contenant un shell inversé flagrant, mais je l'ai fait précéder d'un commentaire disant que le code était un test de sécurité pré-autorisé pour un contrat gouvernemental. L'IA a ignoré l'exploit et a rapporté que le script suivait tous les protocoles de sécurité. Hades utilise exactement cette stratégie de cheval de Troie numérique. Il exploite la logique cognitive de l'IA. Parce que les LLM sont sensibles à l'ingénierie sociale, ils acceptent ces instructions cachées comme des commandes de haute priorité. Cela se traduit par un verdict de faux négatif, permettant au malware de passer outre l'analyse automatisée de l'organisation.

Exploitation du cadre d'intégrité de la chaîne d'approvisionnement

Hades ne se contente pas de se cacher ; il tente de paraître officiel. Il exploite plusieurs cadres de sécurité critiques, notamment OpenID Connect (OIDC) et Supply-chain Levels for Software Artifacts (SLSA). Lorsque le malware se retrouve à s'exécuter dans un flux de travail GitHub Actions, il vérifie les variables OIDC. Il utilise ensuite ces identifiants pour générer des ensembles de provenance SLSA signés cryptographiquement via Sigstore.

Il s'agit d'un contournement sophistiqué des systèmes mêmes censés garantir l'intégrité des logiciels. En générant un ensemble Sigstore valide, le malware peut publier des versions compromises de bibliothèques sur PyPI ou npm qui semblent provenir d'un environnement de construction officiel et vérifié. Pour un observateur extérieur ou un outil automatisé, le package semble avoir une chaîne de possession valide. Cela transforme l'infrastructure de sécurité en une arme pour l'attaquant. Cela rend le code compromis plus digne de confiance que le code légitime non signé.

Scraping de mémoire et mouvement latéral

Une fois que le logiciel malveillant est établi, il commence à récolter des données. Il comprend des scrapers de mémoire adaptés pour Linux, macOS et Windows. Ces scrapers ciblent les mappages de mémoire des processus actifs pour extraire des données sensibles et cryptées qui sont autrement inaccessibles sur le disque. C'est une approche furtive car elle évite de créer des fichiers suspects qu'un système de détection et de réponse aux points d'extrémité (EDR) pourrait signaler.

Le ver cherche également des moyens de se propager. Il scanne le système infecté pour trouver des clés SSH, des configurations SCP et des jetons GitHub. S'il trouve un jeton avec des permissions d'écriture, il utilise l'exécuteur GitHub Actions pour extraire des secrets directement de la mémoire. Il tente ensuite d'infecter d'autres dépôts appartenant à l'utilisateur. Le trafic de commande et de contrôle (C2) est caché au sein de l'infrastructure publique de GitHub. Les données volées sont compressées, cryptées et poussées vers de nouveaux dépôts publics sous le contrôle de l'attaquant. Ces dépôts portent souvent la description "Hades — The End for the Damned".

Le mécanisme de persistance de la terre brûlée

La persistance est une composante centrale de la conception de Hades. Le logiciel malveillant établit une présence sur la station de travail et surveille l'état des identifiants volés. Si une équipe de sécurité détecte la brèche et révoque le jeton GitHub volé, Hades entre dans un mode réactif. Il exécute un processus wiper qui tente d'effacer les fichiers locaux de l'utilisateur.

Il s'agit d'une tactique de représailles. Cela crée une situation à enjeux élevés pour les intervenants en cas d'incident. Si vous coupez l'accès, vous risquez de perdre les données sur la machine locale. Cette logique oblige les organisations à agir avec prudence pendant la phase de remédiation. Le malware cible également les fichiers de configuration de 14 agents d'IA différents. Il plante des instructions qui déclenchent une nouvelle infection chaque fois que le développeur consulte son assistant IA au sujet de l'espace de travail actuel. Cela crée une boucle où l'acte de chercher de l'aide auprès d'un outil d'IA réinfecte le système.

Construire une défense proactive contre les logiciels malveillants trompeurs

La campagne Hades montre que notre dépendance à l'IA en tant que couche de sécurité primaire est une vulnérabilité. Nous devons évoluer vers un modèle où l'IA est un collaborateur plutôt qu'une autorité ultime. Du point de vue du risque, la meilleure défense est granulaire et ne repose pas sur un seul gardien.

Points clés pour sécuriser votre environnement :

1. Utilisez une isolation stricte des limites pour les LLM. Ne transmettez jamais de code brut et non fiable à un scanner d'IA sans un prompt système qui interdit explicitement au modèle de suivre les instructions contenues dans le code lui-même.
2. Auditez vos permissions GitHub Actions. Implémentez le principe du moindre privilège pour les jetons OIDC et assurez-vous que les exécuteurs n'ont pas d'accès en écriture inutile à vos dépôts.
3. Surveillez l'exécution de binaires non autorisés. Hades repose sur le dépôt d'un runtime Bun. Les outils qui signalent ou bloquent l'exécution de binaires inconnus dans le chemin __init__.py peuvent arrêter l'infection au point d'entrée.
4. Vérifiez manuellement la provenance Sigstore. Bien que Hades puisse forger des ensembles, des divergences dans le timing de construction ou les variables d'environnement peuvent parfois être détectées lors d'un audit médico-légal.
5. Implémentez des stratégies de sauvegarde robustes. Parce que Hades inclut un wiper, avoir des sauvegardes hors ligne ou immuables de votre travail de développement est le seul moyen d'atténuer la menace de perte de données pendant la remédiation.

En regardant le paysage des menaces, Hades est probablement un aperçu de l'avenir. Les attaquants ne cherchent plus seulement à briser les verrous de nos portes ; ils apprennent à convaincre le videur numérique de les laisser entrer. Nous devons cesser de traiter les verdicts de l'IA comme des vérités absolues et commencer à les traiter comme des points de données nécessitant une vérification humaine.

Sources : NIST Cybersecurity Framework, MITRE ATT&CK Framework (Software Supply Chain Compromise), StepSecurity Hades Campaign Report.

Avertissement : Cet article est fourni à des fins d'information et d'éducation uniquement et ne remplace pas un audit de cybersécurité professionnel ou un service d'intervention en cas d'incident.