Paquet malveillant installé : contenir son exécution avant de remplacer les identifiants

Objectif

État au 25 octobre 2026. Contenir l’exécution d’un paquet malveillant et rétablir la sécurité des identités et des artefacts qu’il a pu affecter. Ce protocole proposé s’appuie sur la documentation de réponse aux incidents de GitHub et de npm, sur l’avis de Tensorlake publié le 8 octobre et sur la fiche OSV de LiteLLM modifiée le 21 octobre à 22:01:01 UTC. Revérifier les avertissements propres au paquet et les indicateurs révisés avant d’agir.

Prérequis

Une machine d’administration saine ; l’autorité nécessaire pour isoler les systèmes concernés et suspendre les publications ; l’accès aux outils d’administration des registres, des dépôts et des émetteurs d’identifiants ; et un stockage protégé pour les preuves. Désigner un responsable de l’incident et consigner les actions en UTC. Utiliser des outils fiables pour examiner les fichiers suspects sans exécuter leurs hooks d’installation, leur code de démarrage d’interpréteur ou les tâches du projet.

Étapes

1. Contenir l’exécution et la distribution. Isoler les postes et runners concernés, annuler les tâches impliquées et suspendre la publication. Conserver les journaux disponibles, les métadonnées des paquets, les fichiers de verrouillage, les empreintes des artefacts et les éléments pertinents du système de fichiers avant tout nettoyage. Utiliser des moyens d’administration extérieurs à l’environnement suspect. Ne pas placer les identifiants de remplacement sur une machine encore en cours d’investigation.
2. Rechercher immédiatement les mécanismes de persistance destructeurs. Tensorlake 0.5.144 nécessite de désactiver gh-token-monitor avant de révoquer les jetons GitHub. Sous Linux, la procédure commence par systemctl --user disable --now gh-token-monitor.service, à exécuter dans la session de l’utilisateur concerné ; effectuer ensuite l’ensemble du nettoyage prévu par l’avis pour la plateforme. Si le confinement ne peut pas être assuré, arrêter la machine concernée et examiner son stockage hors ligne avant de poursuivre. Avec LiteLLM 1.107.0, le démarrage de Python peut exécuter les fichiers malveillants : ne lancer ni Python ni pip pour analyser cet environnement.
3. Révoquer les identifiants exposés depuis la machine saine. Traiter en priorité les accès de publication et d’écriture aux dépôts, puis tous les autres secrets et sessions accessibles, auprès de leurs émetteurs respectifs. Pour npm, exécuter npm token list, identifier l’ID du jeton concerné et utiliser npm token delete TOKEN_ID en remplaçant la valeur fictive par cet ID. Afficher à nouveau la liste des jetons. La documentation npm indique qu’un délai de révocation est possible ; maintenir donc le confinement tout en vérifiant l’état auprès de l’émetteur. Ne délivrer les identifiants de remplacement qu’aux systèmes remis en état qui les utilisent.
4. Cartographier toute l’exposition. Consigner chaque machine concernée, l’heure d’installation, chaque identité accessible et chaque artefact produit par la suite. Le guide de réponse de GitHub recommande d’inventorier les workflows et identifiants touchés et de réévaluer le confinement à mesure que de nouveaux éléments apparaissent. Examiner les caches CI et des registres comme sources possibles de réinstallations ultérieures.
5. Examiner les accès et la persistance. Passer en revue les modifications de workflows, les approbations de publication, les nouveaux runners et les exécutables inconnus. Les consignes de GitHub relatives aux comptes prévoient aussi l’examen des clés de déploiement, des clés SSH, des autorisations d’applications, des webhooks, des collaborateurs et des commits récents. Comparer les constatations à l’état approuvé avant l’incident. Examiner les publications effectuées avec les identités de publication exposées et coordonner avec le registre le retrait des artefacts dont le caractère malveillant est confirmé.
6. Reconstruire et vérifier. Remplacer les environnements touchés à l’aide d’images fiables, de code source vérifié et d’un ensemble de dépendances approuvé ; ne réutiliser ni caches ni exécutables suspects. Consigner l’identité des artefacts de remplacement et tester l’application. Confirmer la révocation des identifiants et le caractère autorisé des accès, puis rétablir le service par étapes en surveillant les journaux des dépôts, de publication, d’accès au cloud et des postes.

Résultat attendu

Le dossier d’incident relie chaque identité exposée et chaque artefact touché à une action de confinement et à un contrôle de rétablissement. La publication reprend depuis un environnement approuvé avec des identifiants aux droits délimités. Un responsable reste chargé d’examiner toute activité suspecte ultérieure et toute exposition non résolue.

Limites et base de vérification

Il s’agit d’une proposition de réponse fondée sur des sources, pas d’un exercice de récupération testé. L’absence d’indicateurs ne peut pas prouver qu’aucun vol ni aucune exécution secondaire n’a eu lieu. La seule suppression du paquet ne peut pas rétablir la confiance. Les précautions contre une persistance destructrice sont propres à l’incident ; suivre les consignes actuelles de l’éditeur tout en poursuivant le confinement urgent au moyen d’outils d’administration sains.