- Introduction : La brèche qui a redéfini la cybersécurité
- Comment l'attaque de SolarWinds a fonctionné
- Pourquoi la sécurité traditionnelle a raté le coche
- Comment MetaDefender aurait pu le détecter
- Comment unSandbox Adaptive doté d'une Threat Intelligence aurait permis d'arrêter l'attaque
- Les avantages de MetaDefender 2.4.0
- Exemple de cas : Comment se serait présenté le rapport de l'Sandbox
- Leçons pour les défenseurs : SolarWinds et au-delà
- Construire une défense prête pour le jour zéro
Introduction : La brèche qui a redéfini la cybersécurité
Fin 2020, l'attaque de la chaîne d'approvisionnement de SolarWinds a ébranlé la communauté de la cybersécurité.
En injectant un code malveillant dans une mise à jour signée numériquement de la plateforme Orion de SolarWinds, des adversaires ont obtenu un accès secret à des milliers d'organisations des secteurs public et privé. Ce qui semblait être une mise à jour logicielle fiable contenait une porte dérobée qui a permis l'une des campagnes de cyber-espionnage les plus dévastatrices de l'histoire.
Cet incident a mis en lumière une réalité douloureuse : les défenses basées sur les signatures et la réputation ne suffisent pas face à des menaces « zero-day » sophistiquées et furtives. Mais qu'en aurait-il été si les entreprises de la chaîne d'approvisionnement avaient déployé OPSWAT MetaDefender ?
Avec la dernière version de MetaDefender 2.4.0, OPSWAT un bac à sable adaptatif basé sur l'émulation et intégrant des informations sur les menaces, qui est le seul à pouvoir détecter les anomalies subtiles que le logiciel malveillant SolarWinds tentait de dissimuler.
Cet article explique comment l'attaque s'est déroulée et, surtout, comment MetaDefender aurait pu l'empêcher.
Comment l'attaque de SolarWinds a fonctionné
L'attaque de la chaîne d'approvisionnement de SolarWinds a été rendue possible par la compromission d'une DLL légitime utilisée dans la plateforme de gestion informatique Orion (SolarWinds.Orion.Core.BusinessLayer.dll). Les acteurs de la menace ont furtivement modifié ce composant en y intégrant directement un code malveillant.
Ce qui semblait être une modification mineure et inoffensive, avec quelques lignes discrètes dans une base de code familière, a fini par introduire une menace importante. Cette DLL faisait partie d'une plateforme largement déployée et utilisée par des organisations des secteurs public et privé, ce qui a donné à l'attaque une portée sans précédent.
La DLL compromise dissimulait une porte dérobée entièrement fonctionnelle, élaborée à partir d'environ 4 000 lignes de code. Ce code permettait aux attaquants d'accéder secrètement aux systèmes concernés et de prendre le contrôle des réseaux des victimes sans déclencher d'alarme.
L'un des aspects les plus critiques de cette attaque est qu'elle s'est déroulée dans le cadre du processus d'élaboration du logiciel lui-même. La DLL altérée portait une signature numérique valide, indiquant que les attaquants avaient infiltré l'infrastructure de développement ou de distribution de logiciels de SolarWinds. Le code malveillant semblait ainsi digne de confiance et pouvait exécuter des actions privilégiées sans déclencher les contrôles de sécurité standard.
Pour rester discrets, les attaquants ont évité de perturber la fonctionnalité originale de la DLL. La charge utile injectée consistait en une modification légère : elle lançait une nouvelle méthode dans un thread séparé, garantissant que le comportement de l'application hôte restait inchangé. L'appel de méthode a été intégré dans une fonction existante, RefreshInternal, mais exécuté en parallèle pour éviter toute détection.
La logique de la porte dérobée résidait dans une classe nommée OrionImprovementBusinessLayer, un nom choisi délibérément pour ressembler à des composants légitimes. Cette classe abritait l'intégralité de la logique malveillante, y compris 13 classes internes et 16 fonctions. Toutes les chaînes étaient obscurcies, ce qui rendait l'analyse statique beaucoup plus difficile.
Pourquoi la sécurité traditionnelle a raté le coche
- Les signatures numériques ne suffisent pas : La DLL était signée, de sorte que les outils AV et les outils pour points finaux l'ont traitée comme étant légitime.
- L'analyse statique a échoué : L'obscurcissement et les chaînes cryptées ont camouflé une logique suspecte.
- Les contrôles d'exécution ont échappé à la détection : La furtivité de la porte dérobée signifie qu'elle ne déclenche pas d'anomalies tant que des conditions très spécifiques ne sont pas remplies.
- L'angle mort de la chaîne d'approvisionnement : Les équipes de sécurité font souvent confiance aux mises à jour logicielles sans les faire exploser dans un bac à sable.
Il ne s'agissait pas d'un simple logiciel malveillant, mais d'une compromission de la chaîne d'approvisionnement conçue pour être invisible.
Comment MetaDefender aurait pu le détecter
Contrairement aux sandbox basées sur des machines virtuelles, qu'il est facile de contourner, MetaDefender utilise une émulation au niveau des instructions et une analyse adaptative des menaces. Cela lui permet de détecter les comportements cachés, même lorsque les attaquants tentent de les dissimuler.
Un bac à sable joue un rôle crucial dans la découverte de ce type d'attaque. Même si la DLL malveillante est signée numériquement et soigneusement conçue pour imiter un comportement légitime, un bac à sable peut détecter la porte dérobée insérée en analysant les anomalies au niveau binaire.
Les règles YARA et les contrôles de réputation ont été intentionnellement désactivés pour cette analyse en bac à sable afin de simuler les conditions initiales de l'attaque de SolarWinds, étant donné que ni l'une ni l'autre n'étaient disponibles à l'époque.
Rapport de DLL propre :
Filescan.IO - Plate-forme d'analyse des logiciels malveillants de nouvelle génération
Rapport sur les DLL trojanisées :
Filescan.IO - Plate-forme d'analyse des logiciels malveillants de nouvelle génération
À gauche, nous voyons le fichier SolarWinds.Orion.Core.BusinessLayer.dll légitime. À droite, on voit la version trojanisée responsable du tristement célèbre incident SolarWinds.
Passons en revue les principaux résultats révélés par l'analyse du bac à sable :
- Chiffrement des chaînes : le code utilise une technique d'obscurcissement typique de divers logiciels malveillants : la compression suivie d'un encodage base64.
Les requêtes WMI sont généralement associées à l'identification des systèmes. Dans ce cas, les chaînes de caractères correspondantes ont été cryptées pour éviter d'être détectées.
Plusieurs indicateurs liés à l'escalade des privilèges, à l'usurpation de l'identité de l'utilisateur et à la falsification du contrôle d'accès.
Un grand tableau d'octets statiques (1096 octets) est présent, généralement utilisé pour intégrer ou mettre en scène une charge utile cachée. Dans ce cas, il stocke des valeurs entières représentant des hachages de noms de processus, probablement à des fins de reconnaissance ou de filtrage. Le bac à sable ayant signalé cette anomalie, les analystes seraient en mesure d'approfondir leurs recherches.
En résumé, une classe de 4 000 lignes de code peut sembler importante, mais dans un grand projet logiciel comportant des milliers de fichiers, il est vraiment facile de passer à côté. C'est là que le bac à sable s'avère inestimable. Il met en évidence les comportements étranges et indique aux analystes où regarder, ce qui est vraiment important.
Comment unSandbox Adaptive doté d'une Threat Intelligence aurait permis d'arrêter l'attaque
1. Analyse de la structure en profondeur (ASD)
Avant l'exécution, Sandbox désassemble les binaires pour en extraire la logique intégrée. Dans le cas de SolarWinds, il l'aurait signalé :
- Le grand tableau statique de 1096 octets utilisé pour mettre en scène les hachages de processus.
- Chaînes compressées + encodées en base64, typiques des logiciels malveillants.
- La classe inhabituelle OrionImprovementBusinessLayer et ses fonctions obscurcies.
2. Moteur antiévasion de nouvelle génération
MetaDefender 2.4.0 s'attaque spécifiquement aux tactiques utilisées dans l'affaire SolarWinds :
- Exposer les charges utiles à mémoire seule → Détecter le code qui n'écrit jamais sur le disque.
- Désobfuscation du flux de contrôle pour .NET → Parfait pour décompresser les DLL obfusquées comme Orion.
- Décodage Base64 automatisé → Démasque les chaînes chiffrées utilisées par les attaquants.
3. Enrichissement du Threat Intelligence
La détection ne s'arrête pas au bac à sable. MetaDefender s'intègre à MetaDefender Threat Intelligence, offrant :
- Plus de 50 milliards d'IOC (IP, URL, domaines, hachages) pour l'enrichissement.
- Recherche de similitude pour détecter les variantes de logiciels malveillants connus, même lorsqu'ils ont été modifiés.
- Threat Scoring pour classer cette DLL dans la catégorie "high-severity".
Les avantages de MetaDefender 2.4.0
La dernière version ajoute des fonctionnalités qui correspondent directement aux menaces de type SolarWinds :
- Exposition de la charge utile en mémoire seulement → aurait révélé l'exécution furtive en mémoire de SolarWinds.
- Packed Malware Unpacking → Identifie les charges utiles mises en scène cachées dans des tableaux statiques.
- Pseudo-Reconstruction des binaires → Permet aux analystes d'avoir une vue d'ensemble des DLL obscurcies.
- Extraction améliorée de YARA et de la configuration → Extraction des configurations des logiciels malveillants malgré le chiffrement.
- .NET Loader Unpacking → Directement lié à la logique .NET obscurcie de la DLL Orion.
Alors que nous commencions à rédiger cet article, une nouvelle campagne contre la chaîne d'approvisionnement de l 'écosystème npm a été rendue publique (npm est un gestionnaire de paquets JavaScript inclus dans Node.js, qui permet à JavaScript de s'exécuter en dehors du navigateur). Cette campagne récente impliquait un ver autoreproducteur appelé "Shai-Hulud", qui a réussi à compromettre des centaines de logiciels. Cet incident a été analysé en détail dans la publication d'OPSWAT intitulée "From Dune to npm : Shai-Hulud Worm Redefines Supply Chain Risk" (De Dune à npm : le ver Shai-Hulud redéfinit le risque pour Supply Chain ).
Cette nouvelle campagne revêt toutefois un intérêt particulier dans le cadre du présent article, car elle démontre également que les capacités de détection MetaDefender sont à jour et efficaces contre les attaques visant la chaîne d'approvisionnement. Consultez notre rapport concernant le fichier malveillant bundle.js, qui détecte le téléchargement de bibliothèques à l'aide d'un code obscurci et qualifie cette activité de « probablement malveillante ».
Conformément aux bonnes pratiques décrites dans l'article mentionné ci-dessus, toutes les dépendances open source doivent être considérées comme non fiables tant que leur sécurité n'a pas été vérifiée. Si les mises à jour des paquets npm concernés avaient été analysées au préalable dans MetaDefender , tout comportement malveillant ou suspect aurait été détecté avant qu'il ne se propage.
Ensemble, ces fonctionnalités démontrent que MetaDefender a été spécialement conçu pour offrir le niveau de furtivité et d'obfuscation sur lequel se sont appuyés les auteurs des attaques SolarWinds et NPM.
Exemple de cas : Comment se serait présenté le rapport de l'Sandbox
1. Constatations statiques
a. Nom de classe obfusqué suspect (OrionImprovementBusinessLayer).
b. Grands tableaux statiques liés à des valeurs de hachage.
c. Chaînes de caractères Base64 cryptées.
2. Constatations dynamiques
a. Requêtes système WMI.
b. Tentative d'appel à l'escalade des privilèges.
c. Création de fils cachés en dehors du flux de travail principal d'Orion.
3. Corrélation des Threat Intelligence
a. La recherche de similitude montre une correspondance de plus de 95 % avec des échantillons APT connus.
b. La corrélation des CIO permet d'identifier les chevauchements d'infrastructures C2.
c. L'évaluation des menaces attribue à la DLL la mention "High Confidence Malicious".
Leçons pour les défenseurs : SolarWinds et au-delà
La faille de SolarWinds a été un signal d'alarme, mais les attaques contre la chaîne d'approvisionnement continuent d'augmenter. Selon le rapport 2025 OPSWAT Threat Landscape Report, les infrastructures critiques restent une cible privilégiée, et les chargeurs obfusqués basés sur des fichiers sont de plus en plus courants.
MetaDefender offre aux responsables de la sécurité :
Résilience zéro jour
Détection comportementale qui ne repose pas sur des connaissances préalables.
Protection de la Supply Chain
Chaque mise à jour, correctif ou fichier fourni par le fournisseur peut être déclenché.
Assurance de la conformité
Répond aux exigences NIST, NIS2, HIPAA et NERC CIP en matière de détection de zero-day.
Renseignements utiles
Des IOC de haute fidélité alimentent directement les pipelines SIEM et SOAR.
Construire une défense prête pour le jour zéro
L'attaque visant la chaîne d'approvisionnement de SolarWinds n'était pas inévitable : elle est simplement passée inaperçue. Si MetaDefender avait été en place, la DLL obfusquée aurait été déclenchée, décodée et signalée bien avant d'atteindre les environnements de production.
Aujourd'hui, alors que les attaquants affinent leurs tactiques d'évasion, le sandboxing basé sur l'émulation n'est plus optionnel. C'est le fondement de toute stratégie sérieuse de défense contre les attaques de type "zero-day".
Grâce à MetaDefender 2.4.0 et à OPSWAT Threat Intelligence, les entreprises peuvent passer d'une approche réactive face aux violations de sécurité à une approche proactive visant à les neutraliser avant même qu'elles ne se produisent.
En savoir plus sur MetaDefender .
Découvrir OPSWAT Threat Intelligence
Contactez OPSWAT pour que votre organisation soit prête pour le jour zéro.
Découvrir OPSWAT Threat Intelligence
Contactez OPSWAT pour que votre organisation soit prête pour le jour zéro.
