- 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 Sandbox aurait pu le détecter
- Comment unSandbox Adaptive doté d'une Threat Intelligence aurait permis d'arrêter l'attaque
- L'avantage de MetaDefender Sandbox 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 révélé une vérité douloureuse : les défenses basées sur les signatures et la réputation ne sont pas suffisantes contre les menaces zero-day sophistiquées et furtives. Mais qu'en serait-il si les organisations de la chaîne d'approvisionnement avaient déployé OPSWAT MetaDefender™ Sandbox?
Avec la dernière version de MetaDefender Sandbox 2.4.0, OPSWAT propose un bac à sable adaptatif basé sur l'émulation avec intégration de renseignements sur les menaces, capable de détecter les anomalies subtiles que le malware SolarWinds a tenté de dissimuler.
Ce blog explique comment l'attaque s'est déroulée et, plus important encore, comment MetaDefender Sandbox aurait pu l'arrêter.
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 Sandbox aurait pu le détecter
Contrairement aux bacs à sable basés sur des VM qui sont faciles à contourner, MetaDefender Sandbox utilise l'émulation au niveau des instructions et l'analyse adaptative des menaces. Cela lui permet de découvrir des 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 Sandbox 2.4.0 s'attaque spécifiquement aux tactiques utilisées par 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 Sandbox s'intègre à MetaDefender Threat Intelligencequi fournit :
- 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".
L'avantage de MetaDefender Sandbox 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 ).
Cependant, cette nouvelle campagne est particulièrement pertinente dans le contexte de cet article, car elle démontre également que les capacités de détection de MetaDefender Sandbox sont à jour et efficaces contre les compromissions de la chaîne d'approvisionnement. Voir notre rapport sur le fichier malveillant bundle.js, qui détecte le téléchargement de bibliothèques utilisant un code obscurci et qualifie cette activité de "Probablement malveillante".
En suivant les bonnes pratiques décrites dans l'article mentionné ci-dessus, toutes les dépendances open-source devraient être considérées comme indignes de confiance jusqu'à ce que leur sécurité ait été prouvée. Si les mises à jour des paquets npm concernés avaient été analysées au préalable dans MetaDefender Sandbox, les comportements malveillants et suspects auraient été identifiés avant qu'ils ne se propagent.
L'ensemble de ces fonctionnalités montre que MetaDefender Sandbox est spécialement conçu pour le type de furtivité et d'obscurcissement sur lequel s'appuient les attaquants de SolarWinds et de 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 Sandbox fournit aux défenseurs les éléments suivants :
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 de la chaîne d'approvisionnement de SolarWinds n'était pas imparable, elle n'a pas été détectée. Si MetaDefender Sandbox avait été en place, la DLL obfusquée aurait été détonée, décodée et repérée bien avant qu'elle n'atteigne 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".
Avec MetaDefender Sandbox 2.4.0 et OPSWAT Threat Intelligence, les entreprises peuvent passer de la réaction aux brèches à la neutralisation proactive de celles-ci, avant qu'elles ne se produisent.
En savoir plus sur MetaDefender Sandbox.
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.
