Attaque par chaîne d’approvisionnement Mastra AI : comment les pirates nord-coréens ont compromis 140 paquets npm

Les chaînes d’approvisionnement logicielles sont devenues une cible privilégiée des cybercriminels, car une seule faille peut compromettre des milliers de projets en aval. Une récente attaque par chaîne d’approvisionnement a mis en lumière cette menace : des pirates nord-coréens ont compromis plus de 140 paquets npm liés à Mastra AI, un écosystème JavaScript utilisé par des développeurs pour des applications de gestion et d’automatisation. L’attaque a été attribuée au groupe Sapphire Sleet, également connu sous le nom de BlueNoroff, connu pour ses opérations ciblant principalement le secteur financier. Cette campagne illustre à quel point les attaques par chaîne d’approvisionnement peuvent être sophistiquées et dévastatrices, exploitant la confiance que les développeurs accordent aux paquets tiers.

L’attaque a commencé lorsque les pirates ont pris le contrôle d’un compte npm mainteneur nommé ehindero, qui possédait des privilèges de publication sur l’écosystème Mastra. En exploitant ce compte compromis, les attaquants ont publié des mises à jour malveillantes pour plus de 140 paquets dans l’espace de noms @mastra. Ces paquets contenaient une dépendance malveillante nommée easy-day-js, une variante trompeuse (typosquatting) de la bibliothèque légitime dayjs, largement utilisée pour la manipulation de dates en JavaScript. Lorsque les développeurs installaient ces paquets compromis, la dépendance malveillante était exécutée automatiquement via un script de post-installation, déclenchant une chaîne d’infection visant à voler des informations sensibles.

Une attaque en plusieurs étapes : de la compromission initiale au vol de données

L’attaque s’est déroulée en plusieurs phases, chacune conçue pour maximiser l’impact tout en minimisant les risques de détection. La première étape consistait à publier des paquets npm malveillants dans l’écosystème Mastra. Ces paquets semblaient légitimes, car ils reprenaient des fonctionnalités courantes, mais incluaient une dépendance cachée : easy-day-js. Une fois installé, ce module exécutait un script de post-installation qui lançait un dropper (un chargeur de malware) sur les machines des développeurs. Ce dropper désactivait la vérification des certificats TLS, une technique courante pour contourner les protections réseau et établir une communication sécurisée avec les serveurs de commande et contrôle (C2) des attaquants.

Le dropper téléchargeait ensuite une charge utile de deuxième niveau, un malware multiplateforme conçu pour cibler les systèmes Windows, Linux et macOS. Ce malware était un voleur d’informations (information stealer) capable de collecter des données sensibles sur l’hôte infecté. Il récupérait l’historique des navigateurs, les applications installées, les processus en cours d’exécution, et vérifiait la présence de 166 extensions de portefeuilles cryptomonnaies dans les navigateurs, notamment MetaMask, Phantom, Coinbase Wallet, Binance Wallet et TronLink. Ces extensions sont des cibles privilégiées, car elles contiennent souvent des clés privées et des jetons d’authentification permettant d’accéder aux fonds des utilisateurs.

Persistance et exfiltration : comment le malware s’installe et reste indétectable

Une fois installé, le malware utilisait des méthodes de persistance différentes selon le système d’exploitation pour garantir sa survie même après un redémarrage. Sous Windows, il ajoutait une clé dans la base de registre sous la clé Run, ce qui permettait au malware de s’exécuter au démarrage du système. Sur macOS, il créait un LaunchAgent, un mécanisme de démarrage automatique utilisé par les applications légitimes, tandis que sous Linux, il installait un service systemd pour assurer sa persistance. Ces techniques sont couramment utilisées par les malwares avancés pour éviter d’être supprimés lors des mises à jour ou des analyses antivirus.

Le malware établissait ensuite une communication avec les serveurs de commande et contrôle (C2) des attaquants, envoyant les données collectées et recevant des instructions supplémentaires. Dans les cas où les systèmes infectés communiquaient avec les serveurs C2, Microsoft a observé des activités ultérieures associées à des tactiques précédemment utilisées par Sapphire Sleet. Ces activités incluaient le déploiement de malwares supplémentaires, l’exfiltration de données sensibles, voire l’utilisation de l’hôte compromis comme point d’entrée pour des attaques plus larges au sein des infrastructures ciblées. Cette approche en plusieurs étapes permet aux attaquants de maximiser leur gain tout en limitant les risques d’être détectés.

Pourquoi les chaînes d’approvisionnement logicielles sont-elles si vulnérables ?

Les attaques par chaîne d’approvisionnement gagnent en popularité parmi les cybercriminels, car elles exploitent une relation de confiance entre les développeurs et les paquets tiers. Les développeurs intègrent souvent des bibliothèques et des outils tiers sans vérifier en profondeur leur intégrité, car ces paquets sont supposés sûrs. Cependant, comme le démontre cette attaque, un attaquant peut compromettre un seul point d’entrée — ici, un compte npm mainteneur — et propager des logiciels malveillants à grande échelle. Cette méthode est particulièrement efficace, car elle permet d’atteindre des milliers de projets et d’utilisateurs finaux en une seule fois.

Un autre facteur de vulnérabilité est la complexité des écosystèmes modernes. Les projets logiciels modernes dépendent de centaines, voire de milliers de dépendances, ce qui rend difficile, voire impossible, une vérification manuelle de chaque paquet. De plus, les attaquants exploitent souvent des techniques de typosquatting, comme dans le cas de easy-day-js, qui imite le nom d’une bibliothèque populaire (dayjs) pour tromper les développeurs. Ces techniques sont difficiles à détecter, car elles reposent sur des erreurs humaines ou des automatismes de saisie.

Enfin, les outils de développement automatisés (comme les scripts de post-installation) sont une porte d’entrée idéale pour les malwares. Ces scripts s’exécutent automatiquement lors de l’installation d’un paquet, ce qui permet aux attaquants d’injecter du code malveillant sans que l’utilisateur n’ait à exécuter manuellement quoi que ce soit. Cette automatisation réduit les chances de détection, car les développeurs font souvent confiance aux processus automatisés sans les examiner en détail.

Qui est Sapphire Sleet, et pourquoi cibler Mastra AI ?

Sapphire Sleet (ou BlueNoroff) est un groupe de hackers parrainé par l’État nord-coréen, connu pour ses activités cybercriminelles ciblant principalement le secteur financier. Selon Microsoft, ce groupe se concentre sur le vol de cryptomonnaies, les fraudes bancaires et l’espionnage économique. Leur mode opératoire inclut l’utilisation de malwares multiplateformes, de techniques de typosquatting, et de campagnes de phishing sophistiquées pour infiltrer les infrastructures ciblées.

Le choix de cibler Mastra AI n’est pas anodin. Mastra est une plateforme utilisée par des développeurs pour automatiser des tâches de gestion, ce qui signifie que les paquets compromis pouvaient potentiellement être intégrés dans des applications professionnelles ou des outils internes d’entreprises. En ciblant Mastra, les attaquants pouvaient accéder à des environnements de développement contenant des clés d’API, des jetons d’authentification, et d’autres informations sensibles utilisées pour accéder à des systèmes critiques. De plus, en volant des jetons de portefeuilles cryptomonnaies, le groupe pouvait directement s’enrichir, ce qui correspond à ses objectifs financiers.

Cette attaque s’inscrit dans une tendance plus large où les groupes parrainés par des États ciblent les infrastructures logicielles pour soutenir leurs activités économiques ou politiques. En compromettant des chaînes d’approvisionnement, ces groupes peuvent non seulement voler des fonds, mais aussi saboter des infrastructures critiques ou espionner des entreprises sans être directement impliqués dans l’attaque.

Comment se protéger contre les attaques par chaîne d’approvisionnement ?

Les attaques par chaîne d’approvisionnement comme celle de Mastra AI soulignent l’importance de renforcer la sécurité des dépendances logicielles. Voici les mesures concrètes que les développeurs et les entreprises peuvent mettre en place pour réduire les risques :

1. Vérifier l’intégrité des paquets tiers

Avant d’intégrer un paquet tiers dans un projet, les développeurs doivent vérifier son authenticité en plusieurs étapes :

• Vérifier l’auteur du paquet : S’assurer que le mainteneur est une entité légitime et connue.
• Examiner les métadonnées : Vérifier la date de publication, le nombre de téléchargements, et les avis des autres utilisateurs.
• Analyser le code source : Si possible, examiner le code du paquet pour détecter des anomalies ou des comportements suspects.
• Utiliser des outils d’analyse automatisée : Des outils comme npm audit, Snyk, ou GitHub Dependabot peuvent détecter des vulnérabilités ou des dépendances malveillantes.

2. Limiter les privilèges des comptes de publication

Les attaques comme celle de Mastra exploitent des comptes mainteneurs compromis. Pour réduire ce risque :

• Appliquer le principe du moindre privilège : Limiter les droits de publication des comptes npm aux seuls paquets nécessaires.
• Utiliser l’authentification multifactorielle (MFA) : Exiger une double authentification pour les comptes ayant des droits de publication.
• Surveiller les activités suspectes : Détecter les modifications inattendues dans les paquets ou les dépendances ajoutées soudainement.

3. Isoler les environnements de développement

Les environnements de développement doivent être isolés des systèmes de production pour limiter la propagation des malwares :

• Utiliser des machines virtuelles ou des conteneurs pour tester les paquets tiers avant de les intégrer dans des projets réels.
• Éviter d’exécuter des scripts de post-installation non vérifiés. Si nécessaire, examiner le code de ces scripts avant de les exécuter.
• Surveiller les processus en arrière-plan : Utiliser des outils comme Process Explorer (Windows) ou htop (Linux/macOS) pour détecter des activités suspectes.

4. Protéger les informations sensibles

Les développeurs doivent minimiser l’exposition des informations sensibles dans leurs environnements de travail :

• Ne pas stocker de clés privées ou de jetons d’authentification dans des fichiers de code ou des dépôts publics.
• Utiliser des coffres-forts de secrets (comme HashiCorp Vault, AWS Secrets Manager, ou Azure Key Vault) pour gérer les informations sensibles.
• Chiffrer les communications : Toujours utiliser des connexions TLS valides et vérifier les certificats pour éviter les attaques de type man-in-the-middle.

5. Former les équipes aux bonnes pratiques de sécurité

La sécurité des chaînes d’approvisionnement dépend aussi de la sensibilisation des équipes :

• Former les développeurs aux risques des attaques par chaîne d’approvisionnement et aux techniques de typosquatting.
• Mettre en place des politiques de sécurité claires pour l’intégration des dépendances tierces.
• Organiser des exercices de simulation d’attaques pour tester la réactivité des équipes en cas d’incident.

Que faire si vous avez été exposé à l’attaque Mastra ?

Si vous avez installé l’un des paquets compromis de l’écosystème Mastra, il est crucial d’agir rapidement pour limiter les dégâts. Voici les étapes à suivre :

1. Isoler le système infecté

• Déconnecter le système du réseau pour empêcher toute communication avec les serveurs C2 des attaquants.
• Sauvegarder les données critiques avant de procéder à une analyse ou une suppression des malwares.

2. Analyser et supprimer le malware

• Exécuter une analyse antivirus complète avec un outil réputé (comme Windows Defender, Malwarebytes, ou ClamAV).
• Vérifier les clés de registre, les LaunchAgents, et les services systemd pour détecter les traces de persistance.
• Supprimer manuellement les fichiers malveillants si l’analyse automatisée ne les détecte pas.

3. Réinitialiser les informations sensibles

• Changer tous les mots de passe stockés dans les navigateurs ou les applications.
• Révoquer et régénérer les jetons d’authentification (API keys, tokens OAuth, etc.).
• Vérifier les portefeuilles de cryptomonnaies et transférer les fonds vers un portefeuille sécurisé si nécessaire.

4. Signaler l’incident

• Signaler l’incident à votre équipe de sécurité interne ou à un CERT (Computer Emergency Response Team) si vous êtes une entreprise.
• Contacter les plateformes concernées (comme npm) pour signaler le paquet compromis et contribuer à sa suppression.

L’avenir des attaques par chaîne d’approvisionnement : vers une sécurité plus proactive

Les attaques par chaîne d’approvisionnement ne sont pas près de disparaître, et leur sophistication ne cesse de croître. Les groupes comme Sapphire Sleet continuent d’innover, exploitant des techniques toujours plus subtiles pour contourner les protections existantes. Face à cette menace, les éditeurs de logiciels, les plateformes de développement et les entreprises doivent adopter une approche proactive pour sécuriser leurs chaînes d’approvisionnement.

Une piste prometteuse est l’utilisation de signatures numériques pour valider l’intégrité des paquets. Des initiatives comme Sigstore ou The Update Framework (TUF) permettent de signer et vérifier les paquets avant leur installation, réduisant ainsi le risque d’intégration de logiciels malveillants. De plus, les plateformes de développement (comme GitHub, GitLab ou Bitbucket) commencent à intégrer des scanners de sécurité automatisés qui analysent les dépendances à la recherche de vulnérabilités ou de comportements suspects.

Les gouvernements et les organismes de normalisation jouent également un rôle clé en établissant des cadres réglementaires pour renforcer la sécurité des chaînes d’approvisionnement. Par exemple, des lois comme le Cyber Resilience Act en Europe imposent aux entreprises de sécuriser leurs produits logiciels tout au long de leur cycle de vie. Ces réglementations encouragent les entreprises à adopter des bonnes pratiques de sécurité et à investir dans des outils de détection et de réponse aux incidents.

Enfin, la collaboration entre les acteurs du secteur est essentielle pour partager des informations sur les menaces émergentes et les tactiques des attaquants. Des initiatives comme MITRE ATT&CK ou OpenSSF (Open Source Security Foundation) permettent aux entreprises et aux chercheurs de collaborer pour améliorer la sécurité des logiciels open source et des chaînes d’approvisionnement.

Conclusion : une menace persistante, mais des solutions existent

L’attaque par chaîne d’approvisionnement Mastra AI est un rappel brutal de la vulnérabilité des écosystèmes logiciels modernes. En exploitant un seul compte npm compromis, les pirates nord-coréens ont pu propager un malware à grande échelle, ciblant des développeurs et des entreprises à travers le monde. Cette attaque illustre à quel point les attaques par chaîne d’approvisionnement sont devenues une menace majeure, combinant sophistication technique, stratégie de ciblage intelligente, et exploitation de la confiance dans les outils tiers.

Pour les développeurs et les entreprises, la leçon est claire : la sécurité ne peut plus être une réflexion après coup. Elle doit être intégrée dès la conception des projets, avec des processus de vérification rigoureux, des outils automatisés de détection, et une culture de la vigilance. Les mesures de protection existent — vérification des dépendances, isolation des environnements, protection des informations sensibles — mais leur efficacité dépend de leur mise en œuvre systématique.

À l’ère où les logiciels sous-tendent presque tous les aspects de notre économie, les attaques par chaîne d’approvisionnement ne sont pas seulement une menace pour les développeurs, mais pour l’ensemble de la société. La réponse à cette menace nécessitera une collaboration étroite entre les acteurs publics, privés et communautaires, ainsi qu’un engagement continu en faveur de la sécurité. Les entreprises qui investiront dans des défenses robustes et une vigilance proactive seront les mieux placées pour résister aux attaques de demain.