Stuxnet : analyse forensic mémoire d’une cyber-arme industrielle Investigation avancée des mécanismes d’injection, de furtivité et de sabotage des infrastructures SCADA
Cet article présente une analyse forensic mémoire du malware Stuxnet à l’aide de Volatility. Il met en évidence ses mécanismes avancés d’injection, de furtivité et de persistance, ainsi que son rôle dans le sabotage des systèmes industriels SCADA.
Beta Delta
3/17/202618 min read
Stuxnet : analyse forensic mémoire d’une cyber-arme industrielle
Investigation avancée des mécanismes d’injection, de furtivité et de sabotage des infrastructures SCADA
Introduction générale
Stuxnet constitue un cas d’étude unique dans l’histoire de la cybersécurité. Là où la majorité des malwares poursuivent des objectifs financiers ou informationnels, Stuxnet s’inscrit dans une logique radicalement différente : celle du sabotage industriel ciblé.
Conçu pour interagir directement avec des systèmes de contrôle industriels, ce malware ne se contente pas d’exécuter du code malveillant sur un système informatique. Il agit sur des processus physiques, en manipulant le comportement d’équipements industriels critiques tout en maintenant une illusion de normalité du point de vue des opérateurs humains.
Les environnements ciblés incluent notamment les systèmes Siemens Step7, les automates programmables industriels (PLC), ainsi que les infrastructures SCADA. Le malware s’intègre dans la chaîne de contrôle en modifiant les instructions envoyées aux équipements tout en falsifiant les retours d’information, rendant sa détection particulièrement complexe.
Dans ce contexte, l’analyse mémoire apparaît comme une approche particulièrement pertinente. Contrairement aux journaux systèmes ou aux traces réseau, la mémoire vive capture l’état réel du système au moment de l’exécution, y compris les artefacts dissimulés par des mécanismes de furtivité avancés.
Origine de Stuxnet
Le nom « Stuxnet » n’est pas arbitraire. Il provient directement d’artefacts identifiés dans le code du malware, notamment les chaînes “.stub” et “mrxnet.sys”. La combinaison de ces éléments a donné naissance au nom utilisé aujourd’hui.
Ce détail, en apparence anecdotique, illustre une réalité plus profonde : les analystes n’ont pas nommé ce malware, ils l’ont ré assembler à partir de ses traces. Autrement dit, même son nom est un produit de l’analyse forensic.
Contexte historique et stratégique
Découvert publiquement en juin 2010, Stuxnet était en réalité déjà actif depuis plusieurs années. Les analyses indiquent un développement débuté autour de 2005, avec des premières versions opérationnelles dès 2007–2009.
L’objectif principal était le sabotage du programme nucléaire iranien, en particulier les installations de Natanz. Le malware ciblait spécifiquement des configurations industrielles précises, notamment des centrifugeuses utilisées pour l’enrichissement de l’uranium.
D’un point de vue technique, Stuxnet représente une rupture majeure. Il exploite simultanément plusieurs vulnérabilités zero-day, utilise des certificats numériques volés pour signer ses drivers, implémente un rootkit à la fois en mode utilisateur et en mode noyau, et introduit pour la première fois un rootkit directement au niveau des automates industriels.
Son mode opératoire est d’une précision chirurgicale : il infecte des systèmes Windows, identifie la présence de logiciels Siemens Step7, puis modifie les instructions envoyées aux PLC. Il altère la vitesse de rotation des centrifugeuses, provoquant leur dégradation progressive, tout en renvoyant des données normales aux systèmes de supervision.
Sources originales de l’analyse
Partie 1
http://www.behindthefirewalls.com/2013/12/stuxnet-trojan-memory-forensics-with_16.html
Partie 2
http://www.behindthefirewalls.com/2014/01/stuxnet-memory-forensics-volatility-II.html
Les travaux présentés s’appuient sur deux analyses forensic particulièrement détaillées portant sur un dump mémoire issu d’un système compromis par le malware Stuxnet. Les auteurs utilisent le framework Volatility, outil de référence dans le domaine du Digital Forensics and Incident Response (DFIR), permettant d’extraire et d’interpréter les artefacts présents en mémoire vive.
La présente étude reprend fidèlement le déroulé méthodologique des analyses originales, tout en proposant une lecture approfondie, contextualisée et enrichie des résultats observés. L’objectif est de transformer une suite de commandes techniques en une compréhension structurée du comportement réel du malware dans un environnement compromis.
Légende : Résultat de la commande imageinfo exécutée avec Volatility sur le dump mémoire analysé. Le framework identifie plusieurs profils compatibles, notamment WinXPSP2x86 et WinXPSP3x86, et propose un profil recommandé basé sur les structures mémoire détectées. Cette étape est essentielle pour garantir une interprétation correcte des objets noyau et des structures internes du système lors des analyses ultérieures.
Cette première étape constitue le socle de toute analyse mémoire. Avant même d’identifier une anomalie, l’analyste doit comprendre ce qu’il observe. La commande imageinfo permet de déterminer le système d’exploitation ainsi que le profil mémoire compatible avec le dump analysé.
Dans ce cas précis, les profils suggérés correspondent à Windows XP 32 bits. Ce point est loin d’être anodin : il confirme que l’environnement analysé correspond à une architecture industrielle classique de l’époque, dans laquelle Windows XP était largement utilisé comme interface entre les opérateurs et les systèmes de contrôle.
Sans cette identification correcte, toute l’analyse ultérieure serait biaisée, car les structures mémoire seraient interprétées de manière incorrecte.
Étape 2 : Analyse des processus
python vol.py -f stuxnet.vmem pslist
PARTIE 1 : Identification de l’infection mémoire
Étape 1 : Identification du système analysé
python vol.py -f stuxnet.vmem imageinfo
Légende : Sortie du plugin pslist affichant l’ensemble des processus actifs présents dans l’image mémoire. Les informations incluent les PID, PPID, nombre de threads, handles ouverts ainsi que les timestamps de création. Cette vue constitue une base d’analyse permettant d’identifier des incohérences comportementales ou structurelles dans l’exécution des processus.
L’analyse des processus constitue une étape fondamentale. Elle permet d’obtenir une vision globale de l’activité du système au moment de la capture mémoire. Chaque processus est décrit par son identifiant, son parent, son nombre de threads et divers indicateurs de fonctionnement.
Ce type d’analyse repose sur un principe simple mais puissant : un système compromis ne se comporte jamais exactement comme un système sain. Les anomalies, même subtiles, constituent des indices précieux.
Étape 3 : Détection d’une anomalie critique
Légende : Présence de plusieurs instances de lsass.exe.
L’observation de plusieurs instances du processus lsass.exe constitue un signal extrêmement fort. Dans un système Windows standard, ce processus est unique et joue un rôle central dans la gestion de la sécurité.
La présence de plusieurs instances indique presque systématiquement une manipulation malveillante. Cela peut correspondre à une injection de code, à la création d’un faux processus ou à une tentative de masquer une activité illicite derrière un nom légitime.
Ce type d’anomalie est typique des malwares avancés, qui exploitent des processus critiques pour se dissimuler.
Étape 4 : Analyse de l’arbre des processus
python vol.py -f stuxnet.vmem pstree
L’analyse de l’arbre des processus permet de comprendre les relations hiérarchiques entre les processus. Dans un environnement sain, lsass.exe est généralement lancé par winlogon.exe.
Dans ce cas, certaines instances de lsass.exe sont lancées par services.exe. Cette incohérence constitue un indicateur de compromission particulièrement robuste, car elle révèle une altération du comportement normal du système.
Ce type d’analyse permet de passer d’une simple observation à une compréhension causale du comportement du malware.
Étape 5 : Analyse réseau
Légende :
Sortie du plugin malfind appliqué au processus lsass.exe (PID 868), avec extraction des régions mémoire suspectes vers le répertoire evidences/. Plusieurs zones mémoire sont identifiées avec des protections de type PAGE_EXECUTE_READWRITE, indiquant des segments à la fois exécutables et modifiables, typiquement utilisés pour l’injection de code. La présence explicite de la signature MZ (en-tête PE) dans ces régions confirme que du code exécutable a été injecté directement en mémoire. Ces éléments constituent un indicateur technique fort d’une compromission active du processus, compatible avec les techniques d’injection utilisées par Stuxnet pour dissimuler et exécuter ses charges malveillantes.L’absence de connexions actives peut sembler rassurante, mais elle ne l’est pas nécessairement. Un malware sophistiqué peut être inactif au moment de la capture ou utiliser des techniques de communication non triviales.
L’analyse des sockets permet de compléter cette vision en identifiant les ports ouverts et les structures réseau présentes en mémoire. Elle offre une lecture plus fine de l’état réseau du système.
Étape 6 : Comparaison des DLL
Légende :
Comparaison du nombre de DLL chargées dans différentes instances du processus lsass.exe à l’aide du plugin dlllist de Volatility, combiné à la commande wc -l pour effectuer un comptage rapide. Les résultats montrent des écarts significatifs entre les processus (PID 680, 868 et 1928), avec un nombre de modules chargés anormalement faible pour certaines instances. Cette divergence comportementale est incohérente avec un fonctionnement normal du processus lsass.exe, qui devrait présenter une structure homogène. Elle constitue un indicateur technique fort d’altération du processus, suggérant une injection de code, une manipulation des structures de chargement des DLL ou une tentative de dissimulation de modules malveillants en mémoire.
L’étude des modules chargés permet de comparer le comportement de processus supposés identiques. Dans un système sain, deux instances légitimes d’un même processus devraient charger les mêmes bibliothèques.
Les différences observées ici suggèrent fortement une manipulation, typiquement liée à une injection de code.
Étape 7 : Analyse avancée des modules
Légende :
Sortie détaillée (-v) du plugin ldrmodules appliqué au processus lsass.exe (PID 1928), mettant en évidence les chemins de chargement (Load Path, Init Path, Mem Path) d’un module associé à KERNEL32.DLL. Le nom du module présente une structure anormale (KERNEL32.DLL.ASLR.0360b7ab), suggérant une altération ou un renommage non standard lié à des mécanismes d’obfuscation ou d’injection. Bien que les chemins semblent cohérents entre les différentes vues, cette dénomination atypique constitue un indicateur suspect, potentiellement lié à une manipulation de l’espace mémoire visant à masquer un module injecté ou à détourner le chargement légitime des bibliothèques système.
Le plugin ldrmodules permet d’identifier des incohérences dans les structures de chargement des modules. Ces divergences traduisent fréquemment la présence de modules injectés ou volontairement dissimulés en mémoire.
Ce type d’analye s’avère particulièrement efficace face aux techniques de rootkit, dont l’objectif est précisément de masquer la présence de code malveillant en altérant les mécanismes inernes du système.
Étape 8 : Détection d’injection mémoire
Légende :
Sortie du plugin malfind appliqué à plusieurs processus système, notamment csrss.exe (PID 600) et services.exe (PID 668), révélant la présence de régions mémoire marquées PAGE_EXECUTE_READWRITE. Contrairement aux cas précédents, ces segments ne présentent pas de signature explicite de type MZ, mais leur nature exécutable et modifiable dans des processus critiques du système constitue un indicateur fortement suspect. Ce type de région mémoire est typiquement utilisé pour héberger du shellcode ou des charges utiles injectées de manière furtive. La présence de telles anomalies dans des processus sensibles suggère une compromission plus large du système, avec propagation de techniques d’injection au-delà d’un seul processus cible, ce qui est cohérent avec le comportement multi-processus observé dans des malwares avancés comme Stuxnet.
La détection d’un en-tête MZ dans une zone mémoire exécutable constitue une preuve quasi irréfutable d’injection de code. Cela signifie qu’un exécutable a été chargé directement en mémoire, en contournant les mécanismes classiques du système.
C’est l’un des indicateurs techniques les plus forts dans une analyse mémoire.
Étape 9 : Validation des artefacts
L’extraction et l’analyse des artefacts permettent de confirmer les hypothèses. Le calcul des empreintes garantit l’intégrité des éléments analysés, tandis que la détection par des moteurs antivirus permet une validation externe.
L’analyse des chaînes fournit une compréhension plus fine des capacités du code malveillant.
PARTIE 2 : Analyse approfondie
Étape 1 : Hooks système
L’analyse des hooks révèle la capacité du malware à intercepter et modifier le comportement du système. Cette technique permet notamment de masquer des processus ou de falsifier des informations.
Étape 2 : Drivers malveillants
L’identification de drivers malveillants confirme une compromission au niveau du noyau. Ce niveau d’accès confère au malware un contrôle quasi total du système.
Étape 3 : Persistance
Légende :
Recherche de chaînes mémoire révélant des clés de registre associées au service malveillant MRxCls. Les entrées trouvées dans HKLM\System\CurrentControlSet\Services\MRxCls (ImagePath, Type, ObjectName) confirment la persistance du driver dans le système Windows. Cette technique met en évidence le mécanisme d’installation du rootkit, qui s’enregistre comme service pour être chargé au démarrage, illustrant une méthode classique de maintien d’accès utilisée par Stuxnet.
Conclusion finale
Cette analyse met en évidence une réalité souvent sous-estimée : les attaques les plus sophistiquées ne laissent pas nécessairement de traces visibles dans les logs ou sur le réseau.
En revanche, elles laissent presque toujours des traces en mémoire.
Stuxnet illustre parfaitement cette évolution. Il ne s’agit plus simplement de compromettre un système, mais de manipuler un environnement physique via une couche logicielle invisible.
Autrement dit, on n’est plus dans la cybersécurité classique. On est dans la cyber-physique offensive.
Et là, clairement, le terrain de jeu change complètement.
Légende :
Sortie du plugin connections de Volatility (v2.1) exécuté sur l’image mémoire stuxnet.vmem. Aucune connexion TCP active n’est identifiée dans les structures réseau au moment de la capture, ce qui suggère soit une absence d’activité réseau du malware à cet instant précis, soit l’utilisation de techniques de communication furtives ou différées non visibles via ce plugin.
Légende :
Sortie du plugin malfind appliqué au processus lsass.exe (PID 868), avec extraction des régions mémoire suspectes vers le répertoire evidences/. Deux segments mémoire distincts sont identifiés avec des permissions PAGE_EXECUTE_READWRITE, indiquant des zones simultanément exécutables et modifiables, typiquement utilisées pour l’injection de code. La présence explicite de la signature MZ au début de ces régions confirme qu’il s’agit de structures exécutables au format PE chargées directement en mémoire. Ce type de comportement est caractéristique d’une injection de payload malveillant, contournant les mécanismes classiques de chargement des exécutables et renforçant l’hypothèse d’une compromission active du processus par un malware avancé tel que Stuxnet.
Légende :
Sortie du plugin ldrmodules appliqué au processus lsass.exe (PID 1928), permettant d’analyser la cohérence des modules chargés en mémoire selon trois vues distinctes : InLoad, InInit et InMem. Plusieurs entrées présentent des incohérences, notamment des modules marqués False dans ces indicateurs tout en étant présents en mémoire, ou inversement. Ces divergences traduisent une désynchronisation entre les listes internes du loader Windows et les structures réellement présentes en mémoire. Ce comportement est caractéristique des techniques de dissimulation utilisées par les malwares avancés, notamment via l’injection de modules non déclarés ou le masquage volontaire dans les structures du système. La présence de ces anomalies dans un processus critique comme lsass.exe constitue un indicateur fort de compromission.
Légende :
Calcul des empreintes cryptographiques SHA256 des artefacts mémoire extraits (*.dmp) à l’aide de la commande sha256sum. Chaque fichier correspond à une région mémoire précédemment identifiée comme suspecte via malfind. Cette étape permet de garantir l’intégrité des données, d’assurer leur traçabilité dans le cadre de l’analyse forensic et de faciliter leur corrélation avec des bases de signatures connues (threat intelligence, antivirus, sandbox). La présence de hachages identiques pour certains fichiers suggère que plusieurs régions mémoire contiennent un même payload ou des portions identiques de code injecté, ce qui renforce l’hypothèse d’une injection répétée ou d’une propagation interne du code malveillant au sein de différents processus.
Légende :
Résultat de l’analyse d’un artefact mémoire extrait (fichier .dmp) soumis à une plateforme de détection multi-moteurs (type VirusTotal). L’empreinte SHA256 correspondante est reconnue par une large majorité de moteurs antivirus (42/48), avec des classifications explicites telles que Worm.Stuxnet, Backdoor.Generic ou variantes associées. Ce niveau de détection élevé confirme sans ambiguïté la nature malveillante de l’échantillon et permet de corréler les observations issues de l’analyse mémoire avec des signatures connues dans les bases de threat intelligence. Cette étape constitue une validation externe essentielle, transformant les indices techniques observés en preuve formelle de compromission liée à Stuxnet.
Légende :
Résultat de l’extraction des chaînes de caractères (strings) à partir des artefacts mémoire précédemment dumpés (process.*). On observe la présence répétée d’appels à des fonctions du noyau Windows de type Zw*, telles que ZwMapViewOfSection, ZwCreateSection, ZwOpenFile ou ZwQuerySection. Ces fonctions sont directement liées à la gestion des sections mémoire, à la manipulation de fichiers et à l’accès bas niveau aux ressources système. Leur présence dans les données extraites constitue un indicateur fort d’activités d’injection de code et de manipulation mémoire avancée. Ce type de primitives est couramment utilisé par les malwares sophistiqués pour charger dynamiquement du code en mémoire, contourner les mécanismes de sécurité et interagir avec le système à un niveau proche du noyau, ce qui est cohérent avec les techniques employées par Stuxnet.
Légende :
Sortie combinée des plugins malfind et apihooks appliqués au processus lsass.exe (PID 1928), mettant en évidence une région mémoire suspecte marquée PAGE_EXECUTE_READWRITE. La présence d’un en-tête PE valide (MZ) confirme qu’un code exécutable a été injecté directement en mémoire. Le désassemblage affiché révèle des instructions machine associées à ce segment, permettant d’observer le flux d’exécution du code injecté. Ce type d’analyse met en évidence non seulement la présence d’un payload malveillant, mais également son intégration dans le processus cible, potentiellement via des mécanismes de hooking API destinés à intercepter et altérer le comportement normal du système. Ces éléments constituent un indicateur technique fort d’une compromission avancée, typique des techniques utilisées par Stuxnet pour assurer furtivité et contrôle du système.
Légende :
Sortie du plugin malfind appliqué au processus lsass.exe (PID 1928), mettant en évidence une région mémoire suspecte située à l’adresse 0x680000, avec des permissions PAGE_EXECUTE_READWRITE. Contrairement aux segments contenant un en-tête PE complet, cette zone présente du code brut (shellcode) accompagné de chaînes partielles, notamment des fragments liés à des fonctions système telles que ZwMapViewOfSection. Ce type de contenu est caractéristique d’un payload injecté de manière furtive, conçu pour interagir directement avec les mécanismes bas niveau du système sans passer par un exécutable complet. L’association de code exécutable, de permissions RWX et de références à des API critiques du noyau constitue un indicateur fort d’injection malveillante avancée, typiquement observée dans des malwares sophistiqués comme Stuxnet.
Légende :
Sortie du plugin modscan de Volatility permettant d’identifier les modules noyau (drivers) présents en mémoire, y compris ceux qui ne sont plus référencés dans les structures standards du système. Le driver mrxnet.sys est ici clairement mis en évidence, avec une adresse de base (0xb21d8000), une taille mémoire associée et un chemin pointant vers C:\WINDOWS\system32\Drivers\mrxnet.sys. La présence de ce module est particulièrement suspecte, car mrxnet.sys est connu pour être un composant malveillant utilisé par Stuxnet. Le recours à modscan est crucial dans ce contexte, car il permet de détecter des modules potentiellement dissimulés par des techniques de rootkit, contournant les mécanismes classiques d’énumération des drivers.
Légende :
Extraction du module noyau mrxnet.sys à l’aide du plugin moddump de Volatility, en ciblant explicitement son adresse de base (0xb21d8000). L’opération aboutit à la création d’un fichier dump (driver.b21d8000.sys) dans le répertoire evidences/. Cette étape permet de transformer un artefact mémoire volatil en un fichier exploitable pour des analyses complémentaires, telles que le reverse engineering ou la soumission à des outils de détection. L’extraction ciblée confirme la présence effective du driver malveillant en mémoire et constitue une preuve matérielle essentielle dans le cadre de l’investigation forensic.
Légende :
Calcul de l’empreinte SHA256 du fichier extrait driver.b21d8000.sys afin de garantir son intégrité et permettre son identification unique. Ce hash constitue une signature numérique fiable, exploitable pour la corrélation avec des bases de renseignement (VirusTotal, CTI, IOC). Cette étape est essentielle en forensic pour valider que le fichier analysé n’a subi aucune altération et pour confirmer son association avec des artefacts malveillants connus, notamment dans le cadre de l’analyse de Stuxnet.
Légende :
Résultat d’analyse multi-antivirus du fichier extrait, mettant en évidence une détection majoritaire comme Stuxnet (Trojan/variant). Plusieurs moteurs (Microsoft, Norman, etc.) identifient explicitement la signature du malware, confirmant la nature malveillante du driver analysé. Cette corrélation entre empreinte SHA256 et bases antivirus renforce la preuve technique et valide l’attribution de l’échantillon à une souche connue de cyber-arme avancée.
Légende :
Filtrage des modules noyau via modscan avec grep pour isoler les drivers suspects liés à la famille MRX (mrxnet.sys, mrxcls.sys, etc.). La présence de ces modules, notamment mrxnet.sys, est fortement associée à Stuxnet, qui utilise des drivers malveillants pour s’ancrer au niveau kernel. Cette étape permet d’identifier rapidement les artefacts critiques dans la mémoire et de cibler les composants à extraire pour une analyse approfondie.
Légende :
Extraction du driver suspect mrxcls.sys à partir de la mémoire via le plugin moddump, en ciblant son adresse de base (0xf895a000). Le module est dumpé avec succès sous la forme driver.f895a000.sys dans le répertoire evidences/. Cette opération confirme la présence active du composant en mémoire et permet de l’isoler pour des analyses approfondies (reverse engineering, détection, IOC). Ce type de driver est typiquement utilisé par des malwares avancés comme Stuxnet pour opérer au niveau kernel et échapper aux mécanismes de détection classiques.
Légende :
Résultats d’analyse multi-antivirus du driver extrait mrxcls.sys, révélant une détection unanime comme Stuxnet (rootkit) par plusieurs moteurs (F-Secure, Kaspersky, Ikarus, Fortinet…). Les signatures indiquent clairement un comportement de type rootkit kernel, conçu pour dissimuler des activités malveillantes dans le système. Cette convergence de détection confirme sans ambiguïté la compromission avancée de la machine et l’utilisation d’un composant critique de Stuxnet, renforçant la validité des preuves collectées lors de l’analyse mémoire.