Stuxnet décortiqué : comment un malware a détruit des centrifugeuses

Stuxnet n'a pas volé de données. Il n'a pas chiffré de disques contre rançon. Il a fait ce qu'aucun malware n'avait fait avant lui : casser des machines physiques, dans une usine déconnectée d'Internet, pendant que les opérateurs regardaient des écrans qui affichaient « tout va bien ». C'est, encore aujourd'hui, le cas d'école de la sécurité des systèmes industriels (ICS — Industrial Control Systems). Prenons le temps de l'ouvrir.

Le contexte : une cible injoignable

Vers 2010, la cible est le site d'enrichissement d'uranium de Natanz, en Iran. Le problème, pour qui veut l'attaquer à distance, c'est qu'il n'y a pas de « à distance ». L'installation est air-gapped : ses réseaux ne touchent pas Internet. Pas de port ouvert à scanner, pas de service exposé. La porte n'existe pas.

C'est la première leçon de Stuxnet, et elle est contre-intuitive : un air-gap n'est pas un mur, c'est un fossé. Et un fossé, ça se franchit à pied. Le ver a été conçu pour voyager sur des clés USB et rebondir de machine en machine jusqu'à atteindre, par contagion, un poste à l'intérieur du périmètre. D'après les enquêtes publiées à l'époque, c'est un contractant — un sous-traitant invité comme un autre pour installer du matériel — qui a fait entrer le vecteur dans l'enceinte. Pas d'effraction. Une livraison.

Autrement dit : votre périmètre réseau peut être parfait, votre surface d'attaque réelle inclut toujours les humains et les supports amovibles qui le traversent. C'est exactement le sujet que l'on traite côté offensif dans le Bootcamp DevSecOps quand on parle de la convergence IT/OT (Information Technology / Operational Technology) : la frontière, si tant est qu'elle existe, est traversée tous les jours.

La mécanique : frapper l'automate, pas l'ordinateur

Une fois à l'intérieur, Stuxnet ne s'intéresse pas vraiment à Windows. Windows n'est qu'un moyen de transport. Sa vraie cible, ce sont les automates programmables industriels — PLC (Programmable Logic Controllers) — de marque Siemens (gamme SIMATIC S7-300 et S7-400) qui pilotent les variateurs de fréquence des centrifugeuses.

Et c'est là que le malware devient chirurgical. Il ne sabote pas tout ce qu'il touche. Il cherche une configuration très précise : un certain nombre de centrifugeuses, des variateurs de fréquence de fabricants déterminés (Vacon en Finlande, Fararo Paya en Iran), tournant dans une plage de fréquences caractéristique de l'enrichissement d'uranium. Sur n'importe quelle autre machine, il reste dormant et inoffensif. Sur la bonne, il s'arme.

Son action est diabolique de simplicité : il modifie la vitesse de rotation des centrifugeuses. Il les pousse à des régimes anormaux — survitesse autour de 1410 Hz, puis sous-vitesse autour de 2 Hz — par à-coups espacés de plusieurs semaines. Une centrifugeuse qui enrichit l'uranium est un objet mécanique d'une fragilité extrême ; la faire sortir de sa plage nominale, par intermittence, l'use et la casse sans qu'on comprenne pourquoi. Le résultat, documenté dans les analyses de Symantec (W32.Stuxnet Dossier, Falliere/O'Murchu/Chien, 2011) et Langner Communications : autour d'un millier de centrifugeuses dégradées, et le programme nucléaire iranien retardé de plusieurs années.

Le code : l'attaque qui se cache en rejouant le passé

La partie la plus élégante — et la plus instructive pour nous — n'est pas le sabotage. C'est la dissimulation.

Pour qu'une salle de contrôle ne réagisse pas pendant que les machines se détruisent, il faut que les écrans mentent. Stuxnet embarque un véritable rootkit pour PLC. Avant de lancer son attaque, il enregistre pendant 13 jours les valeurs normales remontées par les capteurs vers le SCADA (Supervisory Control And Data Acquisition) Siemens WinCC. Puis, pendant qu'il manipule les vitesses, il rejoue ces valeurs enregistrées aux opérateurs. Exactement le coup du braquage où l'on diffuse une boucle de vidéosurveillance pendant que le coffre se vide.

Le schéma logique, simplifié, ressemble à ceci :

fonction boucle_automate():
    si signature_cible_absente:
        comporte_toi_normalement()       // sur 99% des machines, rien ne se passe
        retour

    si phase == OBSERVATION:
        enregistrer(valeurs_capteurs_normales)   // ~13 jours d'écoute
    si phase == SABOTAGE:
        ecrire_consigne(survitesse_puis_sousvitesse)
        afficher_a_operateur(valeurs_capteurs_normales)  // on rejoue le passé

Trois principes de sécurité sautent aux yeux dans ce pseudo-code. D'abord, l'attaque vérifie sa cible avant d'agir : c'est de la discrétion, pas de la destruction aveugle. Ensuite, elle sépare l'observation de l'action, pour apprendre le « normal » avant de le falsifier. Enfin, et c'est le cœur, elle attaque l'intégrité de l'information autant que le processus physique. L'opérateur n'est pas aveuglé : il est trompé. Ce qu'il voit est faux, mais cohérent.

Pour franchir Windows jusqu'à ces automates, Stuxnet a par ailleurs utilisé quatre zero-days — un empilement inédit à l'époque, qui a trahi le niveau de moyens derrière le projet :

CVE-2010-2568, la vulnérabilité .lnk, mérite qu'on s'y arrête : il suffisait d'afficher une icône piégée dans l'explorateur Windows pour déclencher l'exécution. Pas de double-clic. Pas d'interaction. Le ver pouvait se propager d'une clé USB à un poste durci en moins de temps qu'il n'en fallait pour comprendre qu'elle était branchée.

Le fix : ce que ça impose côté défense

On ne « patche » pas Stuxnet ; il est daté. Mais ses enseignements défensifs, eux, sont parfaitement actuels — et c'est tout l'intérêt de le dépiauter.

Premièrement, traiter l'air-gap comme une mesure parmi d'autres, jamais comme une garantie. Tout ce qui traverse le fossé — clés USB, ordinateurs portables de maintenance, matériel de sous-traitants — doit être considéré comme un vecteur. Contrôle des supports amovibles (kiosks USB durcis, scan obligatoire), postes de maintenance dédiés et isolés, inventaire de qui entre avec quoi.

Deuxièmement, surveiller l'intégrité de la logique des automates. La leçon centrale de Stuxnet, c'est que les valeurs affichées par le SCADA peuvent être falsifiées. La parade : mesurer indépendamment. Des capteurs hors bande, une supervision qui ne dépend pas uniquement de ce que le PLC veut bien remonter, des sommes de contrôle (hash) sur le programme automate pour détecter une modification non autorisée.

Troisièmement, prendre au sérieux la convergence IT/OT. Pendant des années, les équipes industrielles vivaient dans un monde séparé de l'informatique de bureau. Stuxnet a prouvé que la frontière était une illusion. Aujourd'hui, avec des usines de plus en plus connectées (Industrie 4.0), la surface n'a fait que grandir. Segmentation stricte entre bureautique et production (modèle Purdue / ISA-95 niveaux 0-3 isolés du niveau 4+), moindre privilège sur les postes qui parlent aux automates, journalisation de ces échanges.

Quatrièmement, préparer la détection et la réponse spécifiques à l'OT, pas seulement la prévention. On ne pourra pas tout empêcher ; il faut pouvoir voir vite. Concrètement :

• Établir une référence du comportement normal d'un automate (plages de vitesses, cycles, volumes de commandes) pour repérer une dérive.
• Conserver des journaux exploitables côté process et pas seulement côté réseau.
• Écrire à l'avance le plan de réponse pour un incident qui touche le physique.

Couper un serveur compromis, on sait faire. Décider quoi faire quand c'est une ligne de production ou une vanne qui est manipulée, ça ne s'improvise pas en pleine crise. La question à se poser à froid : qui a l'autorité d'arrêter la production, et sur la foi de quel signal ?

Les limites : ce que Stuxnet ne dit pas

Soyons honnêtes sur la portée de l'exemple. Stuxnet était une opération à moyens quasi illimités, vraisemblablement étatique (attribution publique : programme « Olympic Games », États-Unis et Israël, selon les travaux journalistiques de David Sanger en 2012), taillée pour une cible unique. La très grande majorité des organisations ne feront jamais face à un adversaire de ce calibre, et calquer une défense « anti-Stuxnet » sur une PME industrielle serait une erreur d'échelle.

Mais c'est justement pour ça qu'il reste pédagogique. Les techniques de pointe d'hier deviennent les outils banals de demain. Le franchissement d'air-gap par USB, la falsification des données remontées à la supervision, le ciblage conditionnel d'un environnement précis : ce sont désormais des concepts entrés dans la boîte à outils générale, pas des secrets d'État. Comprendre l'arme de prestige permet de reconnaître ses dérivés discount quand ils frappent des cibles ordinaires.

Plusieurs descendants spirituels en témoignent : Industroyer/CrashOverride sur le réseau électrique ukrainien (2016), TRITON/Trisis sur les systèmes instrumentés de sécurité d'une raffinerie saoudienne (2017), Industroyer2 sur l'Ukraine (2022). Pas le même niveau de sophistication, mais le même schéma : traverser, identifier, falsifier, agir.

Impact : pourquoi ce cas de 2010 vous concerne encore

On pourrait ranger Stuxnet au rayon des curiosités géopolitiques. Ce serait une erreur, parce que les trois conditions qui l'ont rendu possible n'ont pas disparu — elles se sont généralisées.

La première condition, c'est la dépendance à des automates qu'on ne met presque jamais à jour. Un PLC a une durée de vie de quinze à vingt ans. Beaucoup de ceux qui tournent aujourd'hui dans des usines, des stations de traitement d'eau ou des réseaux électriques ont été conçus à une époque où la sécurité n'était pas un critère. Ils parlent des protocoles sans authentification, acceptent des reprogrammations sans vérifier qui les envoie, et n'ont aucun moyen de signaler qu'on les a modifiés. Ce n'est pas un défaut exotique : c'est l'état par défaut de l'industrie.

La deuxième, c'est la connexion croissante de ces environnements. Le mouvement « industrie 4.0 » a branché à des réseaux des machines qui vivaient jusque-là isolées, pour collecter de la donnée, faire de la maintenance à distance, optimiser la production. Chaque passerelle ajoutée est une commodité réelle — et une porte de plus. L'air-gap qui protégeait Natanz, beaucoup d'usines ne l'ont même plus.

La troisième, c'est la banalisation des techniques. En 2010, falsifier les retours d'un automate relevait du savoir-faire d'agence. Aujourd'hui, les concepts circulent en conférence (S4, CS3STHLM, Black Hat ICS Village), les outils d'analyse de protocoles industriels sont publics, et des groupes criminels — pas seulement des États — s'intéressent à l'OT parce que c'est là que la pression d'une rançon est maximale : quand c'est la production physique qui s'arrête, on paie vite.

Le résultat, c'est que la question n'est plus « est-ce qu'un adversaire de niveau étatique va me viser ? » mais « est-ce que je détecterais une manipulation de mes automates si elle arrivait, par un attaquant trois crans en dessous de celui qui a fait Stuxnet ? ». Pour beaucoup d'organisations, la réponse honnête est non.

Ce qu'il faut retenir

Stuxnet a marqué le moment où une ligne de code est devenue capable de détruire un objet en acier. Au-delà du frisson, il a posé trois questions que tout ingénieur devrait se poser sur son propre système.

1. Est-ce que je fais confiance à un périmètre que des humains et des supports traversent tous les jours ?
2. Est-ce que je crois aveuglément les valeurs que mes propres machines me remontent ?
3. Est-ce que je sépare vraiment ce qui pilote le physique de ce qui lit mes e-mails ?

La cybersécurité a longtemps été l'art de protéger de l'information. Stuxnet a rappelé qu'elle est aussi, désormais, l'art de protéger le réel. Et ce réel ne remonte pas d'alerte : il se contente de tomber en panne, lentement, pendant que l'écran affiche que tout va bien.