Des chercheurs de Socket ont identifié une campagne sophistiquée d’attaque de la chaîne d’approvisionnement, dans laquelle neuf packages NuGet malveillants intègrent des routines de sabotage probabilistes à déclenchement différé dans des bibliothèques .NET par ailleurs légitimes.
Les packages, téléchargés 9 488 fois avant leur signalement, utilisent des déclencheurs dissimulés pour arrêter les processus hôtes et, dans un cas, corrompre les opérations d’écriture de systèmes de contrôle industriels.
De la bibliothèque au risque juridique
Les packages malveillants ont été publiés sous l’alias shanhai666 entre 2023 et 2024.
Chaque package malveillant fournit des fonctionnalités authentiques et opérationnelles afin d’instaurer la confiance et d’échapper à un examen superficiel, tout en dissimulant une vingtaine de lignes de code malveillant.
L’auteur détourne les méthodes d’extension C# (par exemple, .Exec() pour les commandes de base de données et .BeginTran() pour les clients d’automates S7), de sorte que chaque requête de base de données ou opération sur un automate exécute implicitement la logique injectée.
Après des dates de déclenchement codées en dur (ou chiffrées), la charge utile calcule un nombre aléatoire et appelle Process.GetCurrentProcess().Kill(), mettant brutalement fin à l’application.
Les dates de déclenchement sont échelonnées — certains packages ne s’activent qu’en 2027 ou 2028 —, ce qui élargit la fenêtre dont dispose l’auteur pour faire des victimes avant sa détection.
Sharp7Extend, le package le plus dangereux de la campagne, combine deux modes de sabotage.
- Un arrêt probabiliste immédiat du processus à chaque opération sur l’automate (actif jusqu’au 6 juin 2028)
- Un mécanisme différé d’échec des écritures qui renvoie silencieusement des résultats en échec pour jusqu’à 80 % des tentatives d’écriture après un délai de grâce de 30 à 90 minutes.
Ce dernier comportement corrompt les écritures de l’automate sans messages d’erreur évidents, au risque d’entraîner une absence de réponse des actionneurs, des déclenchements de sécurité défaillants et une dérive de production non détectée — des effets qui évoquent des problèmes matériels intermittents plutôt qu’une attaque délibérée.
Pourquoi la détection est difficile
Plusieurs facteurs rendent ces packages difficiles à détecter :
- La majeure partie du code est légitime et utile, ce qui lui permet de passer les tests fonctionnels et la revue de code.
- Le typosquattage (Sharp7 → Sharp7Extend) augmente le nombre d’installations accidentelles dans les environnements OT.
- Les bibliothèques légitimes incluses éliminent les signaux d’alerte évidents lors des tests d’intégration.
- L’activation aléatoire et probabiliste fait passer une interférence systématique pour des défaillances aléatoires.
- Les longs délais entre l’installation et l’activation brouillent la chronologie des investigations au moment où les impacts sont observés.
L’attaquant a délibérément varié les métadonnées de l’auteur et falsifié des éléments de signature afin de déjouer les heuristiques automatisées.
Renforcer la résilience de la chaîne d’approvisionnement
Se défendre contre la campagne NuGet exige une action immédiate et une résilience de la chaîne d’approvisionnement à long terme.
- Auditez les dépendances dès maintenant : Inventoriez les packages .NET et supprimez ou remplacez immédiatement chacun des neuf packages identifiés.
- Imposez une gestion rigoureuse des dépendances : Exigez des métadonnées d’éditeur vérifiées, refusez les noms typosquattés et limitez les sources de packages aux registres approuvés.
- Analysez lors de la compilation et avant la fusion : Intégrez des contrôles SBOM et de l’analyse statique dans les pipelines CI/CD afin de signaler la logique basée sur le temps, les méthodes d’extension inhabituelles ou le code de déclenchement obfusqué.
- Surveillez la logique probabiliste ou basée sur le temps : Déclenchez des alertes en cas de vérifications de dates, de flux de contrôle aléatoires ou d’utilisation inhabituelle de Process.Kill() et des méthodes d’extension dans les dépendances.
- Validez l’intégrité des ICS : Dans les environnements industriels, mettez en place une vérification des écritures pour les commandes d’automates, établissez des taux de réussite de référence pour les automates et surveillez toute baisse soudaine de la confirmation des écritures.
- Renforcez les politiques de la chaîne d’approvisionnement : Appliquez le principe du moindre privilège pour l’installation des packages, exigez des revues de code pour les bibliothèques tierces et imposez un contrôle strict des changements pour les composants OT.
En intégrant ces pratiques, les organisations peuvent renforcer leur chaîne d’approvisionnement logicielle et réduire leur exposition à une logique malveillante dissimulée.
Cette campagne montre comment les attaques de la chaîne d’approvisionnement peuvent transformer du code de confiance et des délais en armes afin de produire des effets destructeurs tout en échappant à la détection.