NotPetya: la cyberattaque la plus coûteuse de l'histoire

25 février 2026 • 13 min read

Fin juin 2017, quelque chose démarre en Ukraine qui ressemble, au premier regard, à du “ransomware comme d’habitude” : des machines redémarrent, des fichiers deviennent indisponibles, et une demande de rançon s’affiche à l’écran.

Quelques heures plus tard, c’est clair : ce n’est pas un incident local. C’est un brasier.

Le nom resté dans les mémoires, c’est NotPetya. Jusqu’à aujourd’hui, c’est un exemple parfait de la façon dont une “simple vague de malware” peut devenir un événement qui met des entreprises à genoux partout dans le monde, avec des dégâts chiffrés en milliards.

Dans cet article, je veux relier deux choses :

L’histoire derrière NotPetya : qu’est-ce qui s’est passé, et pourquoi ça a coûté si cher ?
Le point de vue pratique : qu’est-ce que ça signifie pour des entreprises “normales” aujourd’hui, pas seulement pour des Fortune 500 ?

Le côté désagréable de NotPetya, ce n’est pas que c’était “trop complexe”. Le côté désagréable, c’est : c’est terriblement réaliste.

Pourquoi écrire ça en 2026 ? Parce qu’aujourd’hui on parle de phishing par deepfakes pilotés par l’IA, mais en situation de crise on échoue encore sur les mêmes basiques qu’en 2017 : manque de segmentation et sauvegardes branchées au même “perf” que la prod.

NotPetya en 5 minutes : que s’est-il passé ?

Pour comprendre, il faut remettre les événements dans l’ordre.

Le 27 juin 2017, NotPetya apparaît d’abord en Ukraine puis se propage très vite à l’échelle mondiale. Un élément central : une mise à jour compromise d’un logiciel de comptabilité très répandu en Ukraine (M.E.Doc). Le malware n’est pas entré par “un mauvais clic”, mais via un mécanisme que les entreprises utilisent tous les jours : les mises à jour.

Et c’est quelque chose que beaucoup sous-estiment rétrospectivement : au fond, c’était une attaque supply chain (chaîne d’approvisionnement). M.E.Doc n’était pas un hasard : c’était le levier parfait, parce que les updates sont “trustées” par design.

La leçon pour aujourd’hui est inconfortable, mais essentielle : tu peux faire énormément de choses bien en interne ; si un logiciel d’un prestataire, de la compta, un connecteur ERP ou un outil tiers est compromis, tu es quand même dans la zone d’impact. Le risque supply chain n’est pas “un problème cloud” : c’est très concrètement un problème d’updates.

Une fois dans le réseau, NotPetya ne parle plus d’un seul poste : il s’agit de Lateral Movement (mouvement latéral) :

Via SMB et des vulnérabilités connues (dont EternalBlue / MS17-010, un exploit issu d’un leak du toolkit de la NSA), NotPetya pouvait se propager à d’autres systèmes Windows sans interaction utilisateur.
En parallèle, il utilisait du credential dumping (Mimikatz/LSASS) pour extraire des mots de passe/hashes de la RAM et se déplacer avec de vrais identifiants admin.
Pour l’exécution à distance, il s’appuyait sur des outils admin “normaux” (p. ex. PsExec/WMI). Ce mélange est dangereux parce qu’il peut ressembler à de “l’activité normale” dans les logs au début.

C’était la “recette secrète” : un exploit pour sauter vite sur de nouvelles machines, des credentials sortis de la mémoire pour obtenir les vrais privilèges, puis une montée en charge via les outils natifs.

Point important : patcher n’aurait pas suffi. Même si une machine était patchée contre EternalBlue, elle pouvait quand même tomber dès que le malware avait récupéré des credentials/hashes admin valides ailleurs dans le réseau.

NotPetya jouait aussi avec le temps : il intégrait un délai et ne forçait pas le “grand bang” (reboot/wipe) immédiatement, mais seulement après un certain temps. C’est vicieux pour la détection et, au passage, un classique contre le sandboxing : le malware ne “détonne” pas tout de suite alors qu’il scale déjà en arrière-plan.

Le résultat est exactement ce qu’on observe toujours dans ce genre de situation :

D’abord, quelques systèmes deviennent “bizarres”.
Puis un site entier bascule d’un coup.
Et si tu ne réagis pas très vite (isoler le réseau, bloquer des comptes, fermer des frontières de segmentation), l’incident peut devenir multi-sites.

Pourquoi “ransomware” n’était qu’un camouflage

NotPetya a été perçu comme du ransomware parce qu’il affichait une demande de rançon. Mais techniquement et opérationnellement, c’était autre chose.

Le point clé : NotPetya était en réalité un wiper. Un malware dont l’objectif n’est pas “faire de l’argent”, mais de détruire des systèmes et d’arrêter l’activité.

Ça peut sembler être de la sémantique. En incident, ça change tout :

Avec un ransomware classique, il y a (parfois) une chance de récupérer via des clés ou une négociation.
Avec un wiper, l’objectif est “cassé”. Envoyer du Bitcoin ne t’aide pas.

Avec NotPetya, un détail technique souligne encore plus le côté wiper : il écrasait le MBR (Master Boot Record) et chiffrait la MFT (Master File Table). Et même la mécanique “ransomware” était mal implémentée : l’ID d’installation affiché était généré aléatoirement et n’était pas correctement lié à une clé de déchiffrement utilisable. Concrètement : il n’y avait pratiquement aucun retour possible.

C’est exactement ce qui rendait NotPetya si perfide : au début, il a mis beaucoup d’entreprises sur le mauvais playbook. Tu penses “ransomware playbook”, alors que tu as besoin d’un “disaster recovery playbook”.

Le fait que l’attaque soit plus tournée vers la destruction que vers l’argent colle aussi à l’attribution ultérieure : plusieurs gouvernements ont attribué publiquement NotPetya à des acteurs étatiques russes.

10 milliards de dollars : pourquoi c’était si cher ?

Si tu ne regardes que l’étiquette “ransomware”, les dégâts sont difficiles à expliquer. “On restaure depuis les backups, non ?”

En pratique, NotPetya a surtout été si cher parce qu’il a touché un point sous-financé dans beaucoup d’entreprises : la disponibilité.

Le plus gros poste de coût n’était pas le malware, mais l’arrêt.

Les lignes de production s’arrêtent.
La logistique repasse au papier.
Les identités et domaines doivent être reconstruits.
Les applications, intégrations et dépendances tombent en cascade.
Et ça n’arrive pas sur un seul système, mais sur beaucoup en même temps.

C’est pour ça que NotPetya est souvent décrit comme “la cyberattaque la plus coûteuse de l’histoire”. Les estimations parlent d’environ 10 milliards de dollars US.

Et on le voit aussi au niveau entreprise : Merck, FedEx (incluant TNT Express) et Mondelez ont expliqué dans leurs rapports que ce n’était pas “un sujet IT”, mais un sujet business avec un impact réel sur le chiffre d’affaires, les coûts et la capacité de livraison.

NotPetya a aussi eu un énorme après-coup juridique : des entreprises se sont battues avec leurs assureurs. Certains assureurs ont tenté de refuser en qualifiant NotPetya “d’acte de guerre” (“Act of War”, donc attaque pilotée par un État). Le cas Mondelez est devenu un exemple très connu. La leçon est toujours aussi dure : est-ce que mon assurance cyber couvre les attaques étatiques, ou est-ce qu’une war exclusion s’applique au pire moment ?

Update pour les lecteurs pro : l’affaire Mondelez a été réglée en 2023. Depuis (et plus largement depuis NotPetya), le marché a durci le wording dans beaucoup de polices : dans de nombreux contrats, les attaques “state-motivated” sont définies plus strictement ou exclues explicitement. Résultat : l’assurance cyber devient un risque financier très concret si tu ne comprends pas les clauses.

À ne pas sous-estimer non plus : même si tu ne fais “que” restaurer de l’IT, tu te bats contre des dépendances.

Un exemple souvent cité : Maersk. Ce n’était pas “quelques fichiers chiffrés”, mais la reconstruction de systèmes core, d’identités et de l’IT opérationnelle pour que les ports et la logistique puissent redémarrer.

L’histoire est légendaire parce qu’elle montre à quel point les identités et les backups peuvent être fragiles : Maersk a pratiquement perdu tout son Active Directory, sauf un unique Domain Controller au Ghana qui, à cause d’une coupure de courant, était offline au moment de l’attaque. Ce “Lucky Punch” a servi de backup offline involontaire : grâce à ce seul serveur physique, ils ont pu reconstruire leur AD global et accélérer la reprise.

Au final, ça ne touche pas seulement “l’IT”, mais directement le business :

Dans l’agro : production, planification et supply chain s’arrêtent.
Dans le maritime : les conteneurs restent bloqués.
Dans la pharma : production, process qualité et capacité de livraison sont sous pression.

Voilà pourquoi la facture est si élevée : l’écran de rançon n’est qu’un symptôme. Le vrai coût, c’est l’arrêt.

Cas pratique : l’incident que j’attendrais dans une entreprise “normale”

Je veux décrire volontairement un scénario qui ne sonne pas Hollywood. Pas “state actor vs big tech”, mais un scénario plausible pour une PME/ETI.

Imagine une entreprise de taille moyenne :

Un site principal, un petit second site.
Un setup Windows classique : AD, file servers, quelques VMs, un ERP.
Et quelques systèmes qu’on évite de toucher : automates, vieux logiciels, un “Windows Server 2008 quelque chose”, parce que le vendor n’a jamais migré.
Des backups : quotidien sur un NAS, hebdo en plus sur un second système.

Et voici le point que beaucoup sous-estiment :

Cette entreprise n’a pas “trop peu de sécurité” parce que tout le monde est incompétent. C’est parce que l’exploitation et le temps gagnent toujours.

Le patching est repoussé parce que la prod est serrée. La segmentation est remise à “plus tard” parce que les VLANs, c’est du boulot. Les mots de passe admin locaux se sont construits historiquement. Et le NAS est évidemment online, parce que sinon le restore est pénible.

La chronologie (réaliste, pas dramatique)

Un mardi matin, une mise à jour arrive. Ça peut être un fournisseur, un outil de prestataire, un connecteur… n’importe quoi qui update automatiquement. Ou un système compromis chez un partenaire avec accès VPN.

08:10 : les premiers clients deviennent instables. Un reboot ici, un bug bizarre là.
08:25 : le premier file server ralentit. Les tickets helpdesk explosent.
08:40 : d’un coup, “le domaine est bizarre”. Les logins prennent du temps, les GPO déraillent.
09:00 : un admin se connecte “pour regarder vite fait”. C’est souvent là que le lateral movement accélère.
09:20 : un site entier est, en pratique, offline.

Et voici le morceau qu’on ne comprend vraiment qu’après :

Si tu ne coupes pas net à ce moment-là, les dégâts ne scalent pas linéairement : ils scalent exponentiellement.

Et évidemment vient la question qui revient toujours :

“On doit payer ?”

Avec NotPetya, la réponse amère était : même si tu voulais, ça n’aurait probablement pas été une solution. Psychologiquement, ça change tout : tu dois te mettre en mode “rebuild”, pas “décryptage”.

Plus tu attends, plus il faut reconstruire. Plus il faut reconstruire, plus longtemps tu es en mode dégradé. Et plus tu es en mode dégradé, plus ça coûte.

Ce qui fait vraiment mal

Après quelques heures, c’est clair : ce n’est pas “on restaure quelques fichiers”. C’est “on reconstruit Active Directory et les systèmes core”.

Et tu te rends compte :

Tes backups étaient online et ont été touchés.
Ta doc n’est pas à jour.
Tu n’as pas assez de “golden images” pour reimager vite.
Les credentials admin étaient partout.
Personne n’a jamais répété comment segmenter proprement un site en 30 minutes.

C’est là qu’un incident IT devient une crise d’entreprise.

Ce qu’un SOC fait différemment aujourd’hui (et ce que l’IA vient faire là)

Dans un grand Security Operations Center (SOC), des milliards d’événements provenant de très nombreuses sources arrivent chaque jour. On n’est plus sur “un admin qui lit des logs”, mais sur un process industrialisé : télémétrie, corrélation, automatisation et analyse humaine.

Ce que je trouve intéressant, c’est la répartition des rôles :

IA/automatisation en première ligne : tri, corrélation, détection de patterns, filtrage de l’évident.
Humains en deuxième/troisième ligne : quand c’est critique ou ambigu, des analystes prennent la main, décident, coordonnent la réponse.

Ça sonne “réservé aux gros”, mais la leçon est valable pour les plus petits aussi :

Tu n’as pas besoin de construire un SOC. Mais tu as besoin du même raisonnement :

Collecter des signaux (EDR, firewall, logs d’auth).
Définir ce qui est “normal”.
Avoir un process qui réagit en minutes, pas en jours.

NotPetya était déjà si rapide en 2017 qu’aucun humain n’aurait pu “réagir assez vite” une fois la propagation lancée. Le point de l’IA est donc moins “encore plus vite”, et plus : aider à détecter l’anomalie plus tôt dans le bruit (par exemple, à 03:00 du matin, 500 machines qui veulent parler SMB entre elles). Ces minutes décident : voir plus tôt, contenir plus tôt, isoler plus tôt.

Et ensuite, il y a ce mindset que je vois de plus en plus comme le défaut :

Assume breach.

Planifie comme si l’attaquant était déjà dedans. Pas par paranoïa, mais par pragmatisme.

Ce que je considère comme un minimum aujourd’hui (sans budget enterprise)

Si tu dois retenir une chose de NotPetya, c’est celle-ci :

NotPetya n’était pas “une seule faille”. C’était une chaîne de faiblesses qui se renforçaient entre elles.

La bonne nouvelle : justement, quelques basiques font baisser énormément le risque.

1) Patching et exposure management (vraiment au sérieux)

Les updates Windows critiques (notamment autour de SMB) ne peuvent pas être “plus tard”.
Tout ce qui est exposé vers l’extérieur passe en priorité.
Et si tu as du legacy : au moins segmenté, avec des règles claires.

2) Rendre le lateral movement pénible

Séparer les comptes admin (quotidien vs admin).
Mots de passe admin locaux uniques par machine (LAPS).
Ne pas laisser WMI/PsExec ouverts partout.
Restreindre SMB là où ce n’est pas indispensable.

3) Segmentation, mais pragmatique

Tu n’as pas besoin de “Zero Trust parfait” demain. Mais :

Clients, serveurs, backups, OT/prod ne doivent pas être dans un réseau plat.
Les Domain Controllers sont tier 0 : à protéger comme tels.
Le trafic est-ouest mérite autant d’attention que le trafic internet.

4) Backups : offline, immuables, testés

Je le dis comme je le vois en mission :

Un backup toujours online et toujours inscriptible n’est souvent pas un backup le jour J.

3-2-1 est un bon départ.
Le stockage immutable (ou des médias offline) change la donne.
Les tests de restore sont obligatoires. Pas “on a des backups”, mais “on a répété les restores”.

5) Runbooks d’incident et un “kill switch” pour les sites

Pas besoin d’un manuel de 80 pages. Mais il faut de la clarté :

Qui décide de couper un site ?
Comment bloquer des comptes rapidement ?
Quels systèmes doivent revenir en premier (AD, DNS, DHCP, VPN, ERP) ?

Et oui : il faut s’entraîner, sinon ça ne sert à rien en crise.

Reality check : pendant NotPetya, dans beaucoup de cas, la mesure la plus efficace n’était pas “un outil de plus”, mais la séparation physique. À propos de Maersk, on trouve des récits de personnes courant dans les bureaux pour débrancher des câbles (réseau/énergie) de switches afin de stopper la propagation. Ça paraît basique, mais parfois c’est la meilleure “high-tech security” quand chaque seconde compte.

Conclusion

NotPetya reste, pour moi, un des meilleurs exemples de pourquoi la sécurité IT ne se résume pas à “on a un antivirus”.

Ce n’était pas dévastateur parce que c’était magique. C’était dévastateur parce que ça exploitait des faiblesses très ordinaires :

confiance dans les mises à jour
trop de lateral movement
pas assez de segmentation
des backups trop proches du réseau de prod

Et c’est exactement pour ça que c’est pertinent pour des entreprises “normales”.

Si tu investis aujourd’hui, n’investis pas seulement dans des outils : investis dans la résilience (visibilité, réaction rapide, capacité à restaurer proprement). C’est la différence entre “une très mauvaise journée” et “un trimestre que tu ne rattraperas jamais”.

Sources et lectures complémentaires

À la prochaine, Joe