Attaque de la chaîne d'approvisionnement SAP NPM. Les outils de détection et de réponse hérités laissent vos portes grandes ouvertes

AccuKnox Proactive Runtime offre une sécurité Zero Trust

Le 29 avril 2026, chercheurs d'Aikido Security j'ai découvert que quatre packages SAP npm — @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service, et mbt avait été empoisonné avec une charge utile qui jetons npm récoltés, informations d'identification GitHub, clés SSH, secrets AWS/Azure/GCP et configurations Kubernetes de chaque machine qui fonctionnait installation de npm. Aucun clic requis. L'attaque a exploité la collecte d'informations d'identification via des variables d'environnement dans le système de fichiers proc pour extraire des données sensibles que les développeurs ont involontairement exposées lors d'installations de routine.  

Surnommé “Mini Shai-Hulud” par le groupe menaçant Équipe PCP, l'attaque a chevauché celle de npm préinstaller hook pour télécharger le runtime JavaScript Bun et exécuter un voleur d'informations d'identification obscurci de 11 Mo. Les données volées ont été cryptées et exfiltrées dans des dépôts GitHub créés sous le compte de la victime — puis les jetons npm volés ont été utilisés pour empoisonner davantage de packages, transformant chaque développeur compromis en prochain vecteur d'attaque.

La plupart des outils de sécurité auraient pu observer tout cela se produire.

Le problème avec “Détecter et répondre”

La plupart des outils de sécurité des points de terminaison et de la charge de travail suivent le même manuel : observez les comportements suspects, générez une alerte, déclenchez une réponse. Tuez le processus. Mettre le fichier en quarantaine. Page le SOC.

Face à cette attaque, ce manuel s’effondre. Voici pourquoi.

Le voleur d'informations d'identification lit à partir de chemins bien connus (~/.ssh/, ~/.aws/informations d'identification, ~/.npmrc) et effectue la collecte des informations d'identification via les variables d'environnement dans le système de fichiers proc via/proc/self/environ, ciblant également les jetons de compte de service Kubernetes dans/run/secrets/kubernetes.io/serviceaccount/ — crypte les données et les envoie vers un référentiel distant. La chaîne entière se termine en quelques secondes. Au moment où un outil basé sur la détection signale l’anomalie et lance une réponse, les informations d’identification ont déjà disparu. L'attaquant possède votre jeton npm. Le ver publie des paquets empoisonnés sous votre nom.

La détection après exfiltration est une autopsie et non une défense.

Trois points d’application qui comptent réellement

L'arrêt de cette attaque nécessite des contrôles qui fonctionnent avant l'exécution se termine — pas après. Cela signifie une application au niveau du noyau, où les appels système sont interceptés et les décisions politiques sont prises en ligne, avant que l'opération ne renvoie un résultat. Voici comment Sécurité d'exécution d'AccuKnox, propulsé par Armure de Kube et appliqué via eBPF et Linux Security Modules, aborde chaque étape de la chaîne de destruction.

1. Récolte des informations d'identification : bloquée lors de l'accès aux fichiers

Le premier objectif de la charge utile est de lire les fichiers d'informations d'identification et d'effectuer la collecte d'informations d'identification via des variables d'environnement dans le système de fichiers proc. Clés SSH. Configurations du fournisseur de cloud. Jetons de compte de service Kubernetes. Jetons d'authentification npm et GitHub stockés sur le disque ou exposés dans des variables d'environnement.  

AccuKnox applique politiques d'accès aux fichiers au niveau du noyau en utilisant des hooks LSM. Les politiques définissent exactement quels processus sont autorisés à lire des chemins sensibles comme :/etc/shadow, /run/secrets/kubernetes.io/serviceaccount/, ~/.ssh/, et les fichiers de configuration des informations d'identification. AccuKnox bloque également l'accès non autorisé à/proc/self/environ et aux chemins de système de fichiers proc similaires où la collecte d'informations d'identification via des variables d'environnement se produirait. Tout processus non autorisé — y compris un runtime Bun fraîchement téléchargé exécutant une charge utile JavaScript obscurcie — obtient un déni ferme au niveau SYS_OUVRIR appel système. La lecture ne se termine jamais. Les informations d’identification restent là où elles sont.

Il ne s’agit pas simplement d’une entrée de journal ; il s’agit d’une action d’application qui se produit avant que le contenu du fichier n’atteigne le code de l’attaquant.

2. Exécution de processus non autorisée : bloquée lors de l'apparition

Le mécanisme de livraison de l'attaque télécharge le runtime Bun et l'utilise pour exécuter exécution.js. Dans un environnement d’autorisation par défaut, cela fonctionne car rien n’empêche l’exécution d’un binaire inconnu.

AccuKnox politiques de liste blanche des processus retourner le modèle. Dans une charge de travail forcée, seuls les processus explicitement autorisés — le serveur d'applications, ses dépendances connues, les utilitaires système spécifiques— sont autorisés à s'exécuter. Tout le reste est nié au SYS_EXECVE appel système.

Le binaire Bun téléchargé ? Bloqué. Le configuration.mjs chargeur essayant de le faire apparaître ? Bloqué. L'ensemble de la chaîne d'exécution de l'attaquant meurt lors du premier processus non autorisé, avant qu'un seul fichier d'informations d'identification ne soit touché.

3. Atténuation préventive : pourquoi les secondes comptent

La distinction entre l’atténuation en ligne et la détection et la réponse n’est pas académique lorsque l’exfiltration se produit en quelques secondes.

AccuKnox applique des politiques au niveau de la couche noyau via des modules de sécurité Linux tels que AppArmor et BPF-LSM — ce qui signifie que les décisions politiques s'exécutent au même niveau de privilège que le système d'exploitation lui-même. Il n’y a aucun agent de l’espace utilisateur qui court contre l’attaquant. Il n’y a pas de fenêtre entre la détection et la réponse. L'appel système est intercepté, la politique est évaluée et l'opération est autorisée ou refusée avant son retour.

La correction post-attaque (tuer un processus après son exécution) donne à l'attaquant une fenêtre pour désactiver la journalisation, crypter les données ou exfiltrer les secrets. L’atténuation en ligne ferme entièrement cette fenêtre.

Ce que cela signifie pour vos pipelines CI/CD et la sécurité de votre chaîne d'approvisionnement

1. L’attaque SAP npm ciblait spécifiquement les environnements CI/CD, car c’est là que la densité d’informations d’identification est la plus élevée et que la surveillance est la plus limitée. Les exécuteurs de build contiennent des jetons npm, des informations d'identification du fournisseur de cloud, des secrets GitHub Actions et des configurations Kubernetes —, le tout en mémoire ou sur disque, le tout accessible à tout processus exécuté dans cet environnement.
2. Si vos exécuteurs CI/CD fonctionnent dans Kubernetes, les politiques AccuKnox peuvent y appliquer la même posture de confiance zéro : processus de construction sur liste blanche uniquement, accès aux fichiers d'informations d'identification limité aux outils autorisés et politiques réseau qui empêchent l'exfiltration vers des points de terminaison non autorisés.
3. Si vos coureurs sont des machines virtuelles ou du métal nu, KubeArmor prend en charge les environnements non Kubernetes avec le même modèle d’application eBPF et LSM.
4. Le principe reste constant : exécution par défaut refusée, accès aux fichiers avec le moins de privilèges et application qui fonctionne à la vitesse du noyau.

L'essentiel

Les attaques contre la chaîne d’approvisionnement qui instrumentalisent les gestionnaires de colis de confiance ne vont pas disparaître. Le Groupe TeamPCP derrière cette campagne a frappé Bitwarden, Checkmarx et maintenant SAP et le mécanisme de propagation semblable à un ver signifie que chaque développeur compromis devient un vecteur pour la prochaine attaque.

Les outils de détection vous diront ce qui s'est passé. L'application du temps d'exécution empêche que cela se produise. Lorsque l’exfiltration des informations d’identification se termine en quelques secondes, cette distinction est tout le jeu. Réservez une démo si vous souhaitez voir l'application du temps d'exécution en action.  

FAQ