NotPetya : quand le « malware » se comportait comme un marteau-pilon

NotPetya en une page : ce qu’il a fait et pourquoi cela importait

NotPetya a été largement rapporté comme un ransomware. Opérationnellement, traitez-le comme un wiper avec une excellente capacité de distribution.
Il a utilisé plusieurs méthodes de propagation, volé des identifiants, exécuté via des outils d’administration Windows standard, puis
sabordé le démarrage du système en écrasant des parties du processus de démarrage disque et en chiffrant des structures nécessaires au montage du système de fichiers.

L’implication pratique : payer ne permettrait pas de récupérer de manière fiable quoi que ce soit parce que le flux de « rançon » était fonctionnellement cassé.
Les dégâts n’étaient pas « des fichiers verrouillés » ; c’était « des machines qui ne démarrent pas, et la récupération est reconstruction + restauration ».
Si votre modèle de reprise supposait « on va désinfecter les postes », NotPetya a transformé cela en « il faut réimager des parcs et reconstituer l’identité ».

NotPetya a aussi révélé une vérité discrète : beaucoup d’entreprises fonctionnent comme un appartement partagé avec une clé maîtresse.
Le mouvement latéral devient trivial quand les mots de passe admin locaux sont réutilisés, que les admins de domaine se connectent sur des postes aléatoires,
et que l’exécution à distance est laissée grande ouverte.

Un axiome d’ingénierie reste pertinent, et c’est la citation à garder au mur :
L’espoir n’est pas une stratégie. — idée paraphrasée attribuée au général Gordon R. Sullivan

Blague n°1 : NotPetya était un « ransomware » comme un bulldozer est du « paysagisme ». Vous pouvez le payer ; le jardin est toujours détruit.

Faits et contexte à retenir

Ce ne sont pas des trivia ; ce sont les leviers qui expliquent pourquoi l’incident a enchainé comme il l’a fait.

• Il a frappé en juin 2017, se propageant rapidement sur des réseaux d’entreprise et provoquant des interruptions mondiales.
• Il est souvent entré via un mécanisme de mise à jour compromis (compromission de la chaîne d’approvisionnement), pas seulement par du phishing ciblé.
• Il a abusé des outils d’administration Windows comme PSExec et WMIC—des outils que vos admins utilisent déjà tous les jours.
• Il a utilisé le vol d’identifiants (scraping de mémoire / credential dumping) pour se déplacer latéralement là où le patching ne suffisait pas.
• Il s’est aussi propagé via SMB en utilisant plusieurs techniques, y compris l’exploitation d’hôtes non patchés et l’utilisation d’identifiants valides.
• Il a endommagé la capacité de démarrage en manipulant les enregistrements de démarrage et en chiffrant des structures disque clés ; la récupération signifiait souvent réimagerie.
• Le canal de paiement de la rançon était effectivement non fonctionnel, ce qui signifie que même un « paiement réussi » n’était pas synonyme de déchiffrement organisé.
• Il a été mal étiqueté tôt comme « Petya ransomware », ce qui a embrouillé des playbooks de réponse pensés pour des ransomware à motivation financière.
• Il a mis en lumière les risques des réseaux plats : une fois à l’intérieur, il a trouvé des chemins d’administration partagés comme l’eau trouve des fissures.

Si vous ne retenez qu’une chose : le vecteur d’accès initial importe moins que les contrôles internes qui vous faisaient défaut.
NotPetya n’était pas un tour de magie ; c’était un audit des raccourcis quotidiens.

Comment NotPetya fonctionnait : la mécanique d’un « wiper déguisé en ransomware »

1) Entrée : la chaîne d’approvisionnement bat le théâtre du périmètre

Des organisations « pas ciblées » ont été touchées parce que le point d’entrée n’était pas un spearphishing personnalisé dans de nombreux cas.
Un mécanisme de mise à jour compromis fournit à l’attaquant un binaire à l’apparence signée avec un canal de distribution que vous autorisez déjà.
Voilà pourquoi « on bloque les exécutables par e‑mail » est nécessaire mais pas suffisant ; c’est aussi pourquoi le filtrage de sortie et l’allowlisting applicatif
deviennent de vrais contrôles de sécurité, pas du théâtre de conformité.

2) Propagation : exploit + identifiants + outils d’administration

NotPetya n’a pas misé sur une seule technique. Il a combiné plusieurs voies pour se déplacer :

• Propagation de type exploit contre des implémentations SMB vulnérables sur des systèmes Windows non patchés.
• Propagation basée sur les identifiants une fois qu’il a obtenu mots de passe/hashes, transformant vos propres droits d’admin en transport.
• Exécution à distance via PSExec/WMIC, qui passait souvent parce que « c’est interne » et « les admins en ont besoin ».

Cette approche multi-bras compte opérationnellement. La gestion des correctifs seule ne vous sauve pas si votre hygiène des identifiants est catastrophique.
Inversement, des mots de passe parfaits ne vous sauvent pas si vous avez laissé des machines legacy non patchées dans le même domaine de diffusion que tout le reste.
La défense doit être en couches parce que l’attaquant l’est déjà.

3) Charge utile : casser la chaîne de démarrage, pas seulement les fichiers

La famille « Petya-ish » est connue pour bricoler le processus de démarrage. NotPetya ciblait des structures disque bas niveau.
C’est la partie qui transforme un incident malware en incident logistique : pipelines d’imagerie, fiabilité du boot PXE USB,
packs de pilotes, clés BitLocker de récupération, et dérive des images maîtresses deviennent soudainement critiques.

Vous apprenez aussi vite lesquelles des « sauvegardes » n’étaient que des snapshots de données déjà chiffrées et lesquelles étaient réellement immuables,
hors ligne et restaurables sous pression.

4) Timing et comportement de redémarrage : pourquoi on a eu l’impression que le sol s’est effondré

NotPetya déclenchait couramment un redémarrage pour exécuter sa sabotage au démarrage. C’est psychologiquement important : un utilisateur voit un redémarrage,
hausse les épaules, prend un café, revient sur un écran avec un symbole de mort. Puis le help desk appelle l’IT. Puis l’IT appelle tout le monde.
Pendant ce temps, le mouvement latéral a déjà eu lieu.

Voilà pourquoi « on l’éteindra quand on le verra » arrive généralement trop tard. Si votre détection dépend de la vigilance des utilisateurs,
vous construisez un système de sécurité à base d’espoir et de caféine.

5) L’impact réel : identité, DNS et services partagés

NotPetya n’a pas seulement tué des postes. Il a cassé les choses que ces postes utilisaient : contrôleurs de domaine, serveurs de fichiers, serveurs de déploiement,
points de distribution de logiciels, collecteurs de supervision. Quand ceux‑ci tombent, l’entreprise découvre qu’elle ne peut même pas coordonner la reprise.

Si votre plan de réponse exige « pousser un agent sur tous les hôtes », et que votre distribution logicielle est hors service, félicitations :
votre plan est un document, pas une capacité.

Où les organisations ont échoué : points faibles prévisibles

Réseaux plats : l’architecture par défaut du regret

Beaucoup de LAN d’entreprise se comportent encore comme un village amical où chaque maison partage le même couloir.
Quand NotPetya arrive sur un endpoint, il voit les partages de fichiers, les ports de gestion et les chemins d’exécution à distance partout.
La segmentation n’est pas glamour. C’est aussi le moyen le moins cher de transformer une « panne globale » en « incident local ».

Prolifération des identifiants : un admin de domaine sur un poste est une arme chargée

NotPetya aimait les identifiants parce que les identifiants sont universels. Les exploits sont pointilleux ; les mots de passe ne le sont pas.
Si les admins de domaine ou des comptes de service à haut privilège se connectent sur des postes, ces secrets se retrouvent en mémoire, et la mémoire est un buffet.
La correction est ennuyeuse et stricte : modèle d’administration par niveaux, postes d’accès privilégiés, LAPS/Windows LAPS, et suppression des droits d’admin pour les utilisateurs.

Exécution à distance laissée ouverte : PSExec n’est pas le méchant, vos contrôles le sont

PSExec et WMIC sont répandus parce qu’ils fonctionnent. NotPetya les a utilisés parce que vous les aviez laissés fonctionner partout.
Vous pouvez conserver la gestion à distance et réduire la zone de choc : restreindre qui peut l’appeler, d’où cela peut être appelé,
journaliser l’usage, et isoler les outils d’admin sur des sous‑réseaux de gestion.

Sauvegardes non restaurables à grande échelle

« On a des sauvegardes » est une phrase qui ne signifie rien à moins que vous puissiez répondre : restaurer quoi, à quelle vitesse, dans quel ordre,
et sans AD.
NotPetya a forcé les entreprises à découvrir que leur processus de restauration dépendait de l’AD de production, du DNS de production et des partages de fichiers de production.
Quand ceux‑ci sont hors service, le runbook de restauration devient une danse interprétative.

Supervision qui tombe avec le réseau

La journalisation centralisée et la supervision sont excellentes—jusqu’à ce qu’elles soient sur le même réseau qui vient d’être briqué.
Il vous faut au moins une vue hors bande : un tap, un réseau de gestion séparé, ou une télémétrie cloud qui survit au chaos interne.
Si vous ne voyez pas, vous ne pouvez pas trier et vous ne pouvez pas prouver la contention.

Mode d’analyse rapide : quoi vérifier en premier/deuxième/troisième pour trouver le goulot rapidement

C’est pour la première heure, quand tout le monde crie et que votre travail est de transformer la panique en file d’attente.
L’objectif est d’identifier : (1) est‑ce qu’on se propage encore, (2) quel service partagé est le goulot, (3) que peut‑on restaurer en premier.

Premier : arrêter l’hémorragie (propagation)

1. Confirmer le mouvement latéral actif en recherchant des pics de trafic SMB/RPC, des tempêtes d’authentification et la création de services distants.
2. Tirer les freins réseau stratégiquement : bloquer SMB (445) entre segments ; restreindre les protocoles d’admin aux sous‑réseaux de gestion.
3. Désactiver temporairement les chemins d’outils connus abusés : création de services PSExec, WMI à distance, et partages admin entre VLANs utilisateurs.

Second : protéger et valider les services d’identité

1. Vérifier les contrôleurs de domaine : sont‑ils accessibles, sains, synchronisés en horaire, et ne redémarrent‑ils pas dans du n’importe quoi ?
2. Geler les comptes privilégiés : désactiver ou réinitialiser les comptes à haut risque, faire pivoter les identifiants de service si possible.
3. Confirmer l’intégrité DNS et DHCP : si la résolution de noms est empoisonnée ou en panne, les outils de reprise échoueront de manière étrange.

Troisième : décider la stratégie de reprise (rebuild vs restore)

1. Choisir une « île dorée » : un segment réseau propre avec postes d’administration propres et outils fiables.
2. Prioriser les services métiers : ERP, expéditions, production, identité, messagerie—ce qui maintient l’activité vitale.
3. Valider les sauvegardes en restaurant un système représentatif dans l’île dorée. Ne débattez pas ; restaurez.

Votre victoire la plus rapide est souvent de restaurer la capacité (identité + applis minimales) plutôt que de courir après la perfection forensique.
La forensique compte. La paie du vendredi aussi.

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont des tâches pratiques à exécuter pendant un incident de type NotPetya ou lors d’exercices de durcissement. Les sorties sont des exemples.
Le but n’est pas de les mémoriser ; c’est de développer la mémoire musculaire sur ce que la sortie signifie et ce que vous faites ensuite.

Tâche 1 : Identifier des tempêtes de connexions SMB sur une passerelle Linux

cr0x@server:~$ sudo ss -tnp '( sport = :445 or dport = :445 )' | head
ESTAB 0 0 10.10.20.5:51234 10.10.30.12:445 users:(("smbd",pid=2140,fd=45))
SYN-SENT 0 1 10.10.20.5:51301 10.10.30.19:445 users:(("smbclient",pid=9921,fd=3))
ESTAB 0 0 10.10.20.8:49822 10.10.30.12:445 users:(("smbd",pid=2140,fd=52))
...

Ce que cela signifie : Une rafale de nouvelles tentatives SMB (SYN-SENT) ainsi que de nombreuses sessions établies peut indiquer un balayage de type ver ou un accès massif aux partages.

Décision : Si c’est anormal, bloquez immédiatement le port 445 entre VLANs utilisateurs et restreignez SMB aux sous‑réseaux de serveurs de fichiers uniquement.

Tâche 2 : Voir les principaux émetteurs vers le port 445 sur un routeur/pare-feu

cr0x@server:~$ sudo conntrack -L | grep dport=445 | awk '{print $5}' | cut -d= -f2 | sort | uniq -c | sort -nr | head
  482 src=10.10.20.5
  219 src=10.10.20.8
   77 src=10.10.21.33
...

Ce que cela signifie : Un petit nombre de sources générant des centaines de flux SMB est suspect dans des réseaux de bureau.

Décision : Isolez les principaux émetteurs au niveau du port de commutateur ou du VLAN. N’attendez pas que les outils endpoint coopèrent.

Tâche 3 : Vérifier la santé de la réplication de domaine Windows depuis un hôte de gestion (via WinRM)

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"repadmin /replsummary\""
Replication Summary Start Time: 1/22/2026 02:14:50

Source DSA          largest delta    fails/total %%   error
DC1                 00:01:12         0 / 20    0
DC2                 00:00:58         0 / 20    0

Destination DSA     largest delta    fails/total %%   error
DC1                 00:01:12         0 / 20    0
DC2                 00:00:58         0 / 20    0

Ce que cela signifie : Une réplication saine suggère que l’AD ne s’effondre pas actuellement. Pendant un événement wiper, la stabilité de l’AD est vitale.

Décision : Si les échecs de réplication augmentent ou les deltas s’accroissent, priorisez l’isolation et la récupération des DC plutôt que les serveurs applicatifs. Tout en dépend.

Tâche 4 : Détecter la création inattendue de services distants (commun avec PSExec)

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045; StartTime=(Get-Date).AddHours(-2)} | Select-Object -First 5 | Format-List\""
ProviderName : Service Control Manager
Id           : 7045
Message      : A service was installed in the system. Service Name: PSEXESVC Display Name: PSEXESVC
...

Ce que cela signifie : L’ID d’événement 7045 avec PSEXESVC indique une exécution à distance de type PSExec.

Décision : Si c’est inattendu, bloquez les partages admin entrants et les appels SCM distants entre segments de postes ; investiguez immédiatement les hôtes sources.

Tâche 5 : Vérifier les traces d’exécution distante WMIC

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddHours(-2)} | Where-Object { $_.Message -match 'wmic.exe' } | Select-Object -First 3 | Format-Table -Auto\""
TimeCreated           Id Message
-----------           -- -------
1/22/2026 01:42:10 4688 A new process has been created... New Process Name: C:\Windows\System32\wbem\WMIC.exe ...

Ce que cela signifie : Les événements de création de processus mentionnant WMIC peuvent indiquer une exécution de commandes à distance ou un outil d’inventaire. Le contexte compte.

Décision : Si cela apparaît sur des postes utilisateurs ou depuis des processus parents inhabituels, traitez comme une compromission active et isolez l’hôte.

Tâche 6 : Confirmer si SMBv1 est encore activé sur les hôtes Windows

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol\""
FeatureName      : SMB1Protocol
State            : Enabled

Ce que cela signifie : SMBv1 activé est un amplificateur de risque persistant ; ce n’est pas « la cause », mais cela accélère les mauvaises journées.

Décision : Désactivez SMBv1 largement, mais faites‑le par étapes : identifiez les dépendances legacy d’abord, puis isolez‑les. Ne laissez pas un vieil imprimante dicter la sécurité du réseau.

Tâche 7 : Voir quels hôtes exposent des partages admin depuis une machine Linux de scan

cr0x@server:~$ for ip in 10.10.20.{1..20}; do timeout 1 bash -c "echo >/dev/tcp/$ip/445" 2>/dev/null && echo "$ip:445 open"; done
10.10.20.5:445 open
10.10.20.8:445 open
10.10.20.12:445 open

Ce que cela signifie : Beaucoup d’expositions 445 poste-à-poste signifie que le mouvement latéral a des voies faciles.

Décision : Mettez en œuvre des règles de pare‑feu hôte ou des ACL réseau pour empêcher les postes d’accepter SMB depuis des postes pairs.

Tâche 8 : Identifier les machines qui redémarrent de façon inattendue (point de vue hôte de virtualisation Linux)

cr0x@server:~$ sudo journalctl -u libvirtd --since "2 hours ago" | grep -E "shutdown|reboot|destroy" | head
Jan 22 01:31:02 hv01 libvirtd[1120]: Domain win-app-03 destroyed
Jan 22 01:31:18 hv01 libvirtd[1120]: Domain win-app-03 started
...

Ce que cela signifie : Des motifs de redémarrage soudains sur des VM Windows peuvent correspondre à un malware déclenchant des redémarrages pour appliquer des changements au niveau du boot.

Décision : Suspendez les redémarrages automatisés ; prenez des snapshots forensiques des disques si pertinent ; isolez la connectivité réseau des VM suspectes.

Tâche 9 : Vérifier la visibilité du MBR/table de partition depuis un environnement de secours Linux

cr0x@server:~$ sudo fdisk -l /dev/sda | head -n 15
Disk /dev/sda: 240 GiB, 257698037760 bytes, 503316480 sectors
Disk model: SSD 860 EVO
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start       End   Sectors   Size Id Type
/dev/sda1  *     2048 503316479 503314432   240G  7 HPFS/NTFS/exFAT

Ce que cela signifie : Si fdisk montre des données corrompues, un type de table inconnu, ou des partitions manquantes, la manipulation du registre de démarrage est probable.

Décision : N’essayez pas de « réparations rapides » sur des disques de production. Préservez des images pour l’enquête ; procédez à une reconstruction + restauration à moins d’avoir un plan de récupération éprouvé.

Tâche 10 : Valider l’immuabilité / l’hypothèse air-gap des sauvegardes (exemple stockage objet via s3cmd)

cr0x@server:~$ s3cmd info s3://corp-backups/windows/DC1-2026-01-22.vhdx
File size: 68719476736
Last mod: Tue, 22 Jan 2026 01:10:02 GMT
MIME type: application/octet-stream
MD5 sum: 1b2c3d4e5f...
Server side encryption: AES256

Ce que cela signifie : La sauvegarde existe et les métadonnées semblent cohérentes. Cela ne prouve pas qu’elle est non modifiée ou restaurable, mais c’est la première porte.

Décision : Tentez immédiatement une restauration dans un réseau isolé. Si la restauration échoue lors d’un test contrôlé, considérez les sauvegardes comme non fiables.

Tâche 11 : Vérifier la dérive « tout le monde est admin local » sur Windows

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-LocalGroupMember -Group 'Administrators' | Select-Object Name\""
Name
----
BUILTIN\Administrator
CORP\Domain Admins
CORP\Helpdesk
CORP\someuser

Ce que cela signifie : Groupes de domaine et utilisateurs aléatoires dans Administrators locaux rendent le vol d’identifiants bien plus précieux.

Décision : Retirez les groupes larges des admins locaux ; adoptez LAPS ; appliquez l’accès privilégié via comptes et appareils dédiés.

Tâche 12 : Confirmer si les politiques de mise en cache d’identifiants sont trop permissives

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"reg query 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' /v CachedLogonsCount\""
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    CachedLogonsCount    REG_SZ    10

Ce que cela signifie : Les logons mis en cache aident les portables à fonctionner hors ligne, mais cela signifie aussi plus de matériel d’identifiants sur les endpoints.

Décision : Ajustez la mise en cache selon le besoin métier. Pour les segments à haut risque (finance, admins), réduisez la mise en cache et imposez MFA + postes privilégiés.

Tâche 13 : Trouver des tempêtes d’authentification Kerberos qui suggèrent un abus d’identifiants

cr0x@server:~$ ssh admin@mgmt-bastion "powershell -NoProfile -Command \"Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddMinutes(-30)} | Measure-Object\""
Count    : 18423
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

Ce que cela signifie : Un pic soudain d’événements de délivrance de tickets peut correspondre à des tentatives d’authentification généralisées et au mouvement latéral.

Décision : Limitez en taux et isolez les sous‑réseaux suspects ; investiguez les hôtes demandant le plus ; envisagez des réinitialisations d’urgence de mots de passe pour les comptes de service exposés.

Tâche 14 : Vérifier que votre « image dorée » est réellement récupérable et à jour

cr0x@server:~$ ls -lh /srv/images/windows-2019-golden.wim
-rw-r--r-- 1 root root 5.3G Jan 10 03:12 /srv/images/windows-2019-golden.wim

Ce que cela signifie : Vous avez un fichier d’image. L’horodatage suggère qu’il peut être obsolète par rapport au rythme des patchs.

Décision : Si l’image est vieille, reconstruisez‑la maintenant en période calme. Lors d’une épidémie, des images obsolètes créent un second incident : un déploiement massif dans des vulnérabilités connues.

Blague n°2 : Votre runbook d’incident qui dépend de « se connecter à l’hôte infecté et lancer l’outil » est adorable.
C’est comme planifier d’éteindre un feu en envoyant un e‑mail à la fumée.

Trois mini-récits d’entreprise depuis le rayon d’impact

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne dans l’industrie avait un environnement Windows mixte : un réseau de bureau moderne plus des machines OT‑adjacentes legacy
qui « ne pouvaient pas être touchées » parce qu’elles contrôlaient les lignes d’emballage. L’équipe sécurité supposait que les machines OT‑like étaient isolées
parce qu’elles étaient sur une plage IP différente. Elles n’étaient pas isolées. Elles étaient simplement numérotées différemment.

Quand l’infection initiale est apparue dans la comptabilité, la première réponse a été classique : bloquer les pièces jointes email, bloquer quelques hash,
et dire aux utilisateurs d’arrêter de cliquer. L’équipe croyait que la menace resterait là où elle avait commencé, parce que « c’est un ransomware ».
En une heure, les tickets help desk ont explosé : partages de fichiers indisponibles, connexions qui expirent, redémarrages aléatoires.

La mauvaise hypothèse s’est révélée dans le pare‑feu : presque aucune règle interne est‑est‑ouest n’existait. SMB, RPC et partages admin circulaient librement.
La « plage OT » était entièrement joignable depuis les postes de bureau parce que quelqu’un avait jadis besoin de pousser une mise à jour et n’avait jamais retiré la règle.
Cette vieille règle était maintenant une autoroute.

La récupération a été brutale mais éclairante. Ils ont dû réimaginer des endpoints à grande échelle, puis reconstruire la confiance : tiering AD, LAPS, segmentation par fonction,
et interdiction explicite de SMB poste-à-poste. La leçon douloureuse n’était pas que le malware est intelligent. La leçon était que les réseaux sont honnêtes :
si c’est routable, c’est atteignable.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une entreprise de retail avait optimisé son administration Windows pour la vitesse. L’équipe de gestion des endpoints utilisait un seul compte de service très privilégié
pour déployer du logiciel via exécution à distance sur des milliers de machines. C’était efficace, cohérent, et adoré.
« Un compte pour les gouverner tous », disaient‑ils en réunion, avec exactement le mauvais niveau de confiance.

Pendant l’épidémie, le credential dumping a transformé cette optimisation en multiplicateur de catastrophe.
Une fois le matériel d’identifiants du compte de service récolté sur une seule machine, il est devenu une clé squelette pour le parc.
Le malware n’a pas eu besoin de brute force. Il s’est contenté d’usurper exactement ce sur quoi la société s’appuyait pour le contrôle.

L’équipe a tenté de contenir en arrêtant la plateforme de gestion, mais la plateforme n’était pas le seul problème—le credential l’était.
Désactiver le compte a arrêté une partie de la propagation, mais a aussi cassé des workflows légitimes de reprise à distance.
Ils avaient accidentellement conçu un environnement où le même mécanisme qui facilitait les opérations rendait l’attaquant rapide.

La solution n’a pas été « ne jamais centraliser ». C’était centraliser avec des frontières : comptes de déploiement par segment,
délégation contrainte, administration juste‑ce‑qu’il‑faut, et forte séparation entre plans de gestion et postes utilisateurs.
Ils déploient toujours rapidement aujourd’hui. Ils ne le font juste plus avec un mot de passe maître qui peut être récupéré depuis la RAM.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Un cabinet de services professionnels avait une habitude dont personne ne se vantait : des exercices trimestriels de restauration qui supposaient que l’AD était indisponible.
Ce n’était pas un exercice sur table. C’était pratique, avec un réseau propre, un ordre d’opérations documenté,
et une insistance agaçante à noter ce qui cassait.

Quand un comportement de type NotPetya a frappé (entrée via chaîne d’approvisionnement, propagation rapide, défaut de boot), leur supervision s’est allumée,
et ils ont fait quelque chose d’unsexy immédiatement : ils ont stoppé le SMB est‑est‑ouest au cœur, puis aménagé un sous‑réseau de gestion propre.
Ils ont accepté que certains hôtes étaient perdus et sont passés directement à la reconstruction.

Les drills de restauration ont rapporté de manière très spécifique : ils avaient des copies hors ligne du matériel de récupération AD et savaient comment dresser
un service d’identité minimal sans compter sur le domaine infecté. Ils savaient aussi quelles sauvegardes étaient « agréables à avoir » et lesquelles
étaient essentielles pour la facturation et les livrables clients.

Ils ont quand même vécu une mauvaise semaine. Mais c’était une semaine, pas un mois. La « sauce secrète » n’était pas un produit.
C’était la discipline de tester les parties ennuyeuses : restaurations, accès privilégié, et règles de segmentation qui font bâiller les architectes.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : « Nous avons isolé le premier portable infecté, mais d’autres machines continuent de mourir. »

Cause racine : Le mouvement latéral avait déjà eu lieu via des identifiants et des outils d’administration ; l’hôte initial n’était pas le seul propagateur.

Correction : Bloquer SMB et les protocoles admin distants entre segments de postes ; faire pivoter les identifiants à haute valeur ; chasser l’activité PSExec/WMIC à grande échelle.

2) Symptom : « Le patching n’a pas aidé ; nous étions patchés et avons quand même été touchés. »

Cause racine : Le statut des patchs réduit l’exploitabilité mais n’empêche pas la propagation basée sur les identifiants ou l’entrée par la chaîne d’approvisionnement.

Correction : Appliquer le principe du moindre privilège, LAPS, tiering des admins, et segmentation réseau. Traitez l’hygiène des identifiants comme un contrôle primaire, pas comme un « plus tard ».

3) Symptom : « Des sauvegardes existent, mais la restauration est impossible maintenant. »

Cause racine : Le processus de restauration dépend de l’AD/DNS/partages de production, qui sont hors service ou non fiables.

Correction : Construire un environnement de restauration en clean‑room ; conserver des identifiants/clés hors ligne ; répéter les restaurations AD‑down ; garder des copies immuables/hors ligne.

4) Symptom : « Nous ne pouvons nous connecter nulle part ; l’authentification échoue partout. »

Cause racine : Contrôleurs de domaine affectés, dérive horaire, problèmes DNS, ou réinitialisations massives de mots de passe faites sans séquençage.

Correction : Stabiliser les DC en premier ; vérifier la synchronisation horaire ; valider le DNS ; effectuer une rotation contrôlée des identifiants en commençant par les comptes de niveau 0.

5) Symptom : « Les outils endpoint disent tout est vert, mais les utilisateurs signalent des boucles de redémarrage et des écrans non amorçables. »

Cause racine : Manipulation du registre de démarrage et dégâts au niveau disque ; les agents ne peuvent pas rapporter si l’OS ne se charge pas.

Correction : Passer à un workflow d’imagerie/reconstruction ; préserver des images forensiques des disques ; ne perdez pas des heures à tenter de « nettoyer » des systèmes non amorçables.

6) Symptom : « La contention a échoué parce que nous n’avons pas pu pousser des règles de pare‑feu assez vite. »

Cause racine : Dépendance excessive à une gestion centralisée qui partage le sort du réseau infecté.

Correction : Préparer des playbooks ACL réseau pré‑stagés sur les switchs/pare‑feux centraux ; maintenir un accès hors bande ; tester les chemins de changement d’urgence.

7) Symptom : « Une seule succursale a reçu la mise à jour, pourtant le siège a aussi été touché. »

Cause racine : Connectivité hub‑and‑spoke avec confiance large ; identifiants admin partagés ou services partagés reliant les réseaux.

Correction : Segmenter par frontières de confiance ; restreindre l’usage des identifiants admin entre sites ; utiliser des domaines de gestion séparés ou des jump hosts PAM.

Listes de contrôle / plan étape par étape

Phase 0 (maintenant, avant la prochaine épidémie) : réduire la zone d’impact

1. Segmenter le réseau : bloquer SMB/RPC poste-à-poste par défaut. Autoriser uniquement vers les serveurs requis.
2. Désactiver SMBv1 largement ; isoler les exceptions derrière des ACL strictes.
3. Déployer LAPS/Windows LAPS pour que les mots de passe admin locaux soient uniques et tournés.
4. Trier vos comptes admin : pas de connexions domain admin sur les postes ; utiliser des postes d’accès privilégiés.
5. Verrouiller PSExec/WMIC : restreindre qui peut exécuter à distance ; surveiller la création de services et les appels WMI suspects.
6. Rendre les sauvegardes survivables : copies immuables, hors ligne/air‑gapped si possible, et drills de restauration en supposant AD hors ligne.
7. Préparer une île dorée : jump hosts propres, outils propres, et un sous‑réseau de gestion opérationnel pendant un incident.
8. Instrumenter le trafic est‑est‑ouest : si vous ne voyez pas le mouvement latéral, vous ne pouvez pas le contenir.

Phase 1 (première heure) : contenir

1. Déclarer l’incident tôt et geler les changements risqués. Vous avez besoin d’un commandant technique unique, pas d’un comité.
2. Bloquer SMB (445) et l’admin à distance (ex. RPC/partages admin) à travers les VLANs postes au cœur du réseau.
3. Isoler les principaux émetteurs identifiés via la télémétrie réseau (tempêtes SMB, tempêtes d’authentification).
4. Protéger les DC : les isoler logiquement ; s’assurer que seuls les sous‑réseaux de gestion peuvent atteindre les ports admin.
5. Désactiver ou réinitialiser les comptes à haute valeur si une compromission est suspectée (domain admins, comptes de déploiement).

Phase 2 (jour 1–3) : récupérer la capacité, puis la confiance

1. Dresser un environnement de gestion propre (jump host, imagerie, journalisation) séparé des segments infectés.
2. Reconstruire à partir d’images connues saines plutôt que de « nettoyer » les endpoints. Les wipers punissent l’optimisme.
3. Restaurer les services prioritaires dans l’ordre de dépendance : identité/DNS/DHCP → applis cœur → services de fichiers → endpoints.
4. Faire pivoter systématiquement les identifiants en commençant par le niveau‑0. Documenter ce qui a été tourné et quand.
5. Prouver la contention avec des preuves réseau et journaux d’événements avant de reconnecter les segments.

Phase 3 (semaine 2+) : ne pas gaspiller la douleur

1. Écrire la chronologie tant que les souvenirs sont frais : accès initial, propagation, détection, contention, récupération.
2. Mesurer honnêtement le MTTR : pas quand les serveurs ont démarré, mais quand l’activité métier a repris.
3. Transformer les enseignements en contrôles : règles de segmentation, tiering des comptes, drills de sauvegarde, et supervision qui survit aux pannes.

FAQ

NotPetya est‑il un ransomware ou un wiper ?

Traitez‑le opérationnellement comme un wiper. Il présentait une note de rançon, mais la récupération par paiement n’était pas fiable.
L’effet était destructeur et systémique.

Pourquoi s’est‑il propagé si vite à l’intérieur des entreprises ?

Parce qu’il combinait plusieurs méthodes : exploitation SMB, vol d’identifiants, et exécution distante via des outils d’administration standards.
Les réseaux plats et les identifiants partagés ont fait que l’environnement interne se comportait comme une grande zone de confiance.

Désactiver SMBv1 l’aurait‑il empêché ?

Cela aurait réduit une voie de propagation à haut risque, mais n’aurait pas éliminé la propagation basée sur les identifiants ni l’abus des outils d’administration.
Il faut de la segmentation, du moindre privilège et une hygiène des identifiants en plus du patching et du durcissement des protocoles.

Quel est le geste de contention le plus important ?

Stopper le mouvement est‑est‑ouest : bloquer SMB et les protocoles d’admin distants entre segments de postes au niveau réseau.
L’isolation d’un endpoint marche quand elle marche ; les contrôles réseau fonctionnent quand les endpoints sont déjà en feu.

Faut‑il éteindre les machines infectées ?

Parfois. Si vous avez des preuves de propagation active depuis un hôte, le retirer du réseau aide.
Mais ne perdez pas de temps à jouer au whack‑a‑mole ; concentrez‑vous sur la contention réseau et la rotation des identifiants. Préservez aussi les preuves forensiques si nécessaire.

Comment les sauvegardes échouent‑elles dans des événements comme celui‑ci ?

Souvent à cause des dépendances : les restaurations nécessitent l’AD/DNS de production, le catalogue de sauvegarde est sur un partage infecté, ou les sauvegardes ne sont pas immuables et sont effacées aussi.
Le remède est des drills de restauration en clean‑room et au moins une copie hors ligne/immuable.

Que devrions‑nous surveiller pour détecter un mouvement latéral de type NotPetya ?

Pics de connexions SMB, journaux d’événements pour la création de services distants (ex. PSEXESVC), exécution WMI inhabituelle, tempêtes d’authentification (Kerberos/NTLM),
et redémarrages soudains sur de nombreux hôtes.

L’allowlisting applicatif aide‑t‑il ?

Oui, surtout contre des binaires inattendus et des exécutions suspectes depuis des chemins écrits par l’utilisateur.
Mais l’allowlisting ne vous sauvera pas si l’attaquant exécute avec des outils d’admin légitimes et des identifiants volés. Utilisez‑le comme une couche, pas un talisman.

Comment récupérer Active Directory en toute sécurité si les DC ont été impactés ?

Avec un plan documenté et répété : isoler les DC suspectés, valider la réplication/santé, décider de restaurer depuis des sauvegardes connues saines,
et faire pivoter les identifiants privilégiés après avoir rétabli la confiance. Si vous n’avez jamais pratiqué la récupération AD, ne commencez pas à improviser en crise.

Quelle est la meilleure défense long terme contre une entrée par la chaîne d’approvisionnement ?

Vous ne pouvez pas « pare‑feu » votre sortie de confiance envers les fournisseurs. Réduisez l’impact par la segmentation, le moindre privilège, et une supervision solide.
Durcissez aussi les workflows de mise à jour : vérifier les chaînes de signature, restreindre où les systèmes de mise à jour peuvent s’exécuter, et isoler ces systèmes des postes utilisateurs.

Prochaines étapes pratiques

NotPetya n’était pas impressionnant parce qu’il était nouveau. Il était impressionnant parce qu’il était compatible avec le comportement réel des entreprises :
identifiants partagés, large accessibilité réseau, et une confiance excessive que « interne » = « sûr ».

Si vous administrez des systèmes de production, faites trois choses ce trimestre :

1. Implémentez une segmentation qui bloque SMB/RPC poste-à-poste et validez‑la par des tests.
2. Corrigez l’hygiène des identifiants : LAPS, tiering des admins, et interdiction de sessions domain admin sur des postes.
3. Faites un drill de restauration en supposant l’AD hors ligne, en utilisant un réseau clean‑room et un objectif chronométré.

Vous n’avez pas besoin de prédire le prochain NotPetya. Vous devez rendre votre environnement ennuyeux à détruire : lent à se propager, difficile pour le saut d’identifiants,
et facile à reconstruire à partir de parties propres. Voilà à quoi ressemble la résilience quand le « malware » arrive avec un marteau‑pilon.