WannaCry : le rançongiciel qui a rappelé à tous l’importance des correctifs

Ce qui s’est réellement passé (et pourquoi ça a fonctionné)

WannaCry a frappé en mai 2017 et a fait ce que tout SRE redoute : transformer un problème d’hygiène interne en une catastrophe visible par les clients à vitesse Internet.
Le cœur de l’épidémie n’était pas un e-mail de phishing avec un ingénierie sociale parfaite. C’était un exploit SMB enchaîné à un ver.
Si un hôte Windows était vulnérable et joignable via TCP/445, il pouvait être touché, chiffré, et utilisé comme tremplin pour atteindre le suivant.

Cela a des conséquences opérationnelles parce que ça a changé la forme de la réponse aux incidents. Avec un rançongiciel typique, on chasse l’accès initial, les identifiants volés et la progression latérale via les outils d’administration.
Avec WannaCry, il fallait aussi traiter le réseau comme une boîte de Petri : n’importe quel endpoint vulnérable pouvait être patient zéro dans son propre sous-réseau.
La « contention » n’était pas seulement la désactivation de comptes et le blocage de C2. C’était empêcher un exploit auto‑propagé de transformer votre réseau plat en combustible.

Voici la partie que l’on minimise : Microsoft a livré un correctif pour la vulnérabilité SMB (MS17-010) avant l’épidémie. L’industrie s’est tout de même fait déborder.
Ce n’est pas « parce que patcher est difficile ». C’est parce que beaucoup d’entreprises avaient construit des processus qui rendaient le patching optionnel, lent ou politiquement dangereux.
Des systèmes qui ne pouvaient pas redémarrer. Des applications « trop fragiles » à tester. Des versions Windows héritées que personne n’osait admettre. Des réseaux qui supposaient « intérieur = de confiance ».

WannaCry n’a pas gagné parce qu’il était brillant. Il a gagné parce qu’il a trouvé l’exacte faille entre « on sait qu’il faut le faire » et « on le fera plus tard ».

Faits rapides et contexte historique (les éléments qu’on oublie)

• MS17-010 (mars 2017) corrigeait des vulnérabilités SMB critiques exploitées plus tard par WannaCry ; le patch existait avant l’épidémie.
• EternalBlue était le nom de l’exploit largement associé à la vulnérabilité SMB ; il faisait partie d’une trousse d’outils divulguée publiquement.
• WannaCry incluait une propagation de type ver, se propageant automatiquement via SMB vers d’autres machines vulnérables sans interaction utilisateur.
• Un domaine kill switch intégré dans le malware a réduit la propagation lorsqu’il a été enregistré et joignable ; de nombreuses infections ont malgré tout eu lieu dans des environnements segmentés ou avec DNS bloqué.
• SMBv1 était un amplificateur de risque majeur ; désactiver SMBv1 et durcir SMB réduisent la surface d’attaque et le rayon d’explosion.
• Les versions Windows héritées (notamment les releases plus anciennes et non supportées à l’époque) ont été fortement impactées ; des patches d’urgence ont été publiés pour certaines.
• Les secteurs de la santé et les services publics ont été notablement perturbés ; ces environnements ont souvent des appareils longévifs et des fenêtres de changement restreintes.
• Le paiement de la rançon n’était pas le coût principal ; les temps d’arrêt, le travail de récupération, la perte de productivité et le préjudice réputationnel ont largement dominé la facture.
• Les réseaux internes plats ont transformé des infections localisées en pannes d’ensemble du campus parce que SMB était routable et largement autorisé.

Mécanique : EternalBlue, SMB et le comportement du ver

Pourquoi SMB a rendu cela si explosif

SMB est le protocole par lequel Windows partage fichiers, imprimantes et diverses « commodités d’entreprise ». C’est aussi le laissez-passer dont bénéficie un malware si vous laissez TCP/445 circuler librement.
Dans de nombreux environnements, SMB est autorisé partout parce que les partages existent partout et « ça a toujours été comme ça ».
Cette hypothèse est un cadeau pour les attaquants : une hôte compromis peut atteindre beaucoup d’autres via un protocole que l’OS traite comme natif.

La propagation de WannaCry s’appuyait sur une faille d’implémentation SMB. L’exploit réussit, l’exécution de code suit, puis le payload rançongiciel s’exécute et le composant ver continue de scanner.
Le résultat : de la vitesse. Pas la patience d’un APT. De la vitesse.

Le kill switch : pas un bouclier magique

La vérification de domaine intégrée agissait comme un verrou de sécurité rudimentaire : si le domaine résolvait et était joignable, le malware arrêtait son exécution.
Cela a considérablement ralenti l’épidémie une fois le domaine enregistré et joignable pour de nombreuses victimes.
Mais « joignable » implique beaucoup de choses ici.

Les réseaux avec DNS restreint, HTTP sortant bloqué, sinkholing, ou connectivité partielle pouvaient malgré tout voir des infections.
De plus, des variantes et des imitateurs ont rapidement émergé. Compter sur un kill switch n’est pas une stratégie ; c’est une coïncidence que vous pourriez ne pas retrouver.

Enseignement opérationnel : patcher est nécessaire mais pas suffisant

Oui, l’application du patch MS17-010 compte. Mais il vous fallait aussi : un inventaire précis, la capacité d’isoler rapidement des endpoints, des contrôles sur le mouvement latéral, et des sauvegardes qui n’étaient pas inscriptibles par les mêmes machines chiffrées.
WannaCry a puni les maillons faibles dans chacun de ces domaines.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : « Tout échoue, tout le temps — concevez pour ça. »
WannaCry est ce à quoi ressemble une conception qui suppose que le patching interviendra éventuellement, et que « éventuellement » n’arrive jamais.

Les véritables modes de défaillance : correctifs, inventaire et confiance

Mode de défaillance 1 : « Nous avons patché… en grande partie »

Dans la réalité d’entreprise, « patché » signifie souvent : un sous-ensemble de systèmes sous gestion centrale, plus une poignée d’exclusions, plus un arriéré de serveurs « spéciaux », plus des portables qui ratent le VPN.
Le malware se fiche de votre intention. Il s’intéresse à la seule machine non patchée avec TCP/445 ouvert.

La correction n’est pas « essayer plus fort ». La correction est la conformité mesurable aux correctifs avec conséquences : tableaux de bord, délais et application incluant les exceptions comme citoyens de première classe.

Mode de défaillance 2 : « Nous n’exposons pas SMB à Internet »

Très bien. Internet n’est pas le seul modèle de menace. La propagation interne est ce qui a transformé WannaCry en générateur de pannes.
Un réseau plat avec un trafic est-ouest permissif fait de chaque endpoint un attaquant interne une fois compromis.

Mode de défaillance 3 : « Il y a des sauvegardes »

Beaucoup de victimes avaient des sauvegardes. Certaines étaient en ligne et inscriptibles, ce qui signifie qu’elles ont été chiffrées aussi. D’autres étaient hors ligne mais non testées, ce qui signifie que les restaurations ont échoué au pire moment.
Si vous ne pouvez pas restaurer un serveur de fichiers à un état propre en un clin d’œil, vous n’avez pas de sauvegardes ; vous avez une histoire rassurante.

Mode de défaillance 4 : « Les systèmes hérités sont inévitables »

Certains le sont. Ce n’est pas une permission de les laisser nus sur le LAN d’entreprise.
Si vous devez garder un ancien OS ou appareil, encapsulez-le : segmentez-le, restreignez son trafic, contrôlez l’accès admin et surveillez‑le comme s’il était radioactif. Parce que c’est le cas.

Blague 1 : « Notre politique de patching était ‘si ce n’est pas en feu, ne le touchez pas.’ WannaCry a apporté le feu. »

Playbook de diagnostic rapide : quoi vérifier en premier/deuxième/troisième

C’est le playbook « vous avez 30 minutes avant que le rayon d’explosion double ». Il privilégie la contention et le triage plutôt que l’attribution parfaite.

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

1. Identifier les hôtes infectés par symptômes : fichiers de note de rançon, extensions de fichiers soudaines, balayage SMB élevé, alertes endpoint.
2. Isoler les machines suspectes du réseau (arrêt de port sur le switch, VLAN de quarantaine NAC, isolation via EDR). Ne « redémarrez pas juste pour voir ».
3. Bloquer le mouvement latéral : restreindre temporairement TCP/445 entre sous-réseaux au niveau des firewalls centraux. Si vous devez garder SMB, n’autorisez que des serveurs de fichiers connus vers des clients connus.
4. Confirmer l’état des correctifs sur le reste du parc, en particulier tout ce qui est joignable sur 445.

Deuxième : déterminer l’exposition (où ça peut se propager ensuite ?)

1. Scanner en interne pour les écouteurs TCP/445 et les mapper à des propriétaires/rôles.
2. Vérifier la présence de SMBv1 et son usage ; planifier de le désactiver largement.
3. Trouver les systèmes non patchés et prioriser ceux avec une connectivité large (jump boxes, hôtes de services partagés, brokers VDI, serveurs de fichiers, systèmes proches du domaine).

Troisième : décisions de restauration (restore vs rebuild)

1. Décider reconstruire vs restaurer : les endpoints sont généralement reconstruits ; les serveurs dépendent du rôle et de la maturité des backups.
2. Valider les sauvegardes hors ligne et s’assurer que les cibles de restauration sont propres et patchées.
3. Hygiène des identifiants : supposer que les identifiants admin locaux et les identifiants de domaine en cache peuvent être exposés sur des endpoints infectés ; les faire tourner si approprié.

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

Ces tâches sont écrites comme si vous étiez sur un hôte admin Linux effectuant un triage réseau et interrogeant Windows via des outils standards quand c’est possible.
En incidents réels, vous utiliserez aussi EDR/MDM, Windows event forwarding et votre CMDB. Mais les commandes ne mentent pas, et elles sont rapides.

1) Découvrir rapidement l’exposition SMB interne

cr0x@server:~$ nmap -n -Pn -p 445 --open 10.20.0.0/16 -oG smb-445.gnmap
Starting Nmap 7.94 ( https://nmap.org ) at 2026-01-22 10:17 UTC
Nmap scan report for 10.20.12.34
Host is up (0.0031s latency).
PORT    STATE SERVICE
445/tcp open  microsoft-ds
Nmap scan report for 10.20.55.10
Host is up (0.0020s latency).
PORT    STATE SERVICE
445/tcp open  microsoft-ds
Nmap done: 65536 IP addresses (4212 hosts up) scanned in 98.40 seconds

Ce que cela signifie : Ces hôtes acceptent des connexions SMB. Ils sont des cibles potentielles et des vecteurs de propagation.
Décision : Prioriser la vérification des correctifs et les règles de segmentation pour ces IP en premier. Ne commencez pas par les machines qui « semblent risquées » ; commencez par celles qui sont joignables.

2) Vérifier si SMBv1 est supporté par une cible (signal rapide)

cr0x@server:~$ smbclient -L //10.20.12.34 -N
protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

Ce que cela signifie : Cela peut indiquer des réglages SMB durcis, une interférence de firewall, ou que la négociation SMBv1 est bloquée/désactivée.
Décision : Ne présumez pas que c’est « bon ». Validez en vérifiant la configuration du serveur centralement. Si vous autorisez encore SMBv1 ailleurs, continuez à chercher.

3) Identifier les versions de Windows depuis SMB (quand autorisé)

cr0x@server:~$ crackmapexec smb 10.20.55.10
SMB         10.20.55.10     445    FS-LEGACY01       [*] Windows 7 Professional 7601 Service Pack 1 (name:FS-LEGACY01) (domain:WORKGROUP) (signing:False) (SMBv1:True)

Ce que cela signifie : Le signing SMB est désactivé et SMBv1 est activé, ce qui augmente le risque ; l’OS est assez ancien pour mériter une attention particulière.
Décision : Si ce système est critique et ne peut pas être mis à jour rapidement, isolez-le dans un VLAN strict et restreignez l’accès SMB au strict nécessaire.

4) Détecter un balayage actif pour SMB (comportement de type ver)

cr0x@server:~$ sudo tcpdump -ni eth0 'tcp dst port 445 and (tcp[tcpflags] & (tcp-syn) != 0)' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:21:11.102938 IP 10.20.88.44.51532 > 10.20.12.34.445: Flags [S], seq 10293812, win 64240, options [mss 1460,sackOK,TS val 89123 ecr 0,nop,wscale 7], length 0
10:21:11.103114 IP 10.20.88.44.51533 > 10.20.55.10.445: Flags [S], seq 7736123, win 64240, options [mss 1460,sackOK,TS val 89123 ecr 0,nop,wscale 7], length 0
10:21:11.103290 IP 10.20.88.44.51534 > 10.20.101.9.445: Flags [S], seq 5512312, win 64240, options [mss 1460,sackOK,TS val 89123 ecr 0,nop,wscale 7], length 0
10 packets captured

Ce que cela signifie : Un hôte envoie des SYNs vers de nombreuses cibles SMB. C’est un comportement classique de propagation de ver.
Décision : Isoler immédiatement 10.20.88.44. Puis rechercher d’autres scanners ; les vers voyagent rarement seuls sur un grand réseau.

5) Mapper l’hôte scannant à une MAC et un port de switch (prêt pour confinement)

cr0x@server:~$ arp -n | grep 10.20.88.44
10.20.88.44 ether 00:25:90:ab:12:ef C eth0

Ce que cela signifie : Vous avez l’adresse MAC de l’hôte suspect.
Décision : Utilisez votre switch/contrôleur pour fermer le port ou le déplacer dans un VLAN de quarantaine. Ne perdez pas de temps à envoyer des mails à l’équipe poste de travail.

6) Vérifier si vos serveurs de fichiers Linux sont surchargés (nombre de connexions SMB)

cr0x@server:~$ sudo ss -tn sport = :445 | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port
ESTAB  0      0      10.20.55.200:445   10.20.88.44:51533
ESTAB  0      0      10.20.55.200:445   10.20.88.44:51534
ESTAB  0      0      10.20.55.200:445   10.20.88.44:51535

Ce que cela signifie : Un seul client ouvre de nombreuses connexions SMB vers votre serveur. Ça peut être légitime, un balayage, un logiciel de sauvegarde, ou un malware.
Décision : Corrélez avec tcpdump et les logs Windows. Si le pair est suspect, bloquez-le au pare-feu de l’hôte pendant que la contention réseau se met en place.

7) Confirmer le patch Windows MS17-010 via la présence de paquets (vérification d’artefacts hors ligne)

cr0x@server:~$ strings WS2012R2-C_drive/Windows/Logs/CBS/CBS.log | grep -E 'KB4012213|KB4012216|KB4012598' | tail -n 3
2017-04-02 08:14:09, Info                  CBS    Package: Package_for_KB4012213~31bf3856ad364e35~amd64~~6.3.1.0, state: Installed
2017-04-02 08:14:10, Info                  CBS    Mark store corruption flag because of package: Package_for_KB4012213~31bf3856ad364e35~amd64~~6.3.1.0
2017-04-02 08:14:15, Info                  CBS    Session: 30712533_1972450825 finalized. Reboot required: no

Ce que cela signifie : L’hôte semble avoir installé un KB pertinent (le KB exact dépend de l’OS).
Décision : Considérez cela comme une preuve d’appui, pas comme une preuve définitive. Validez toujours l’état SMBv1 et la posture de vulnérabilité ; des rollbacks partiels existent.

8) Vérifier l’état SMBv1 sur un hôte Windows via une requête distante (lorsque WinRM est disponible)

cr0x@server:~$ evil-winrm -i 10.20.55.10 -u 'ops' -p 'REDACTED' -s . -c "powershell -NoProfile -Command \"Get-SmbServerConfiguration | Select EnableSMB1Protocol,EnableSMB2Protocol\""
EnableSMB1Protocol EnableSMB2Protocol
------------------ ------------------
True               True

Ce que cela signifie : SMBv1 est activé. C’est un problème que vous pouvez résoudre aujourd’hui, pas « dans un programme ».
Décision : Planifiez un changement d’urgence pour désactiver SMBv1, en commençant par les endpoints et les serveurs non critiques, puis en élargissant. Validez les dépendances applicatives plutôt que de deviner.

9) Vérifier si TCP/445 est autorisé est-ouest via un firewall (test de réalité rapide)

cr0x@server:~$ sudo traceroute -T -p 445 10.20.12.34
traceroute to 10.20.12.34 (10.20.12.34), 30 hops max, 60 byte packets
 1  10.20.88.1 (10.20.88.1)  0.421 ms  0.388 ms  0.361 ms
 2  10.20.0.1 (10.20.0.1)    0.910 ms  0.899 ms  0.885 ms
 3  10.20.12.34 (10.20.12.34)  1.914 ms  1.902 ms  1.890 ms

Ce que cela signifie : Rien ne bloque le chemin pour TCP/445 entre les réseaux ; le trafic circule probablement librement.
Décision : Implémentez des ACL temporaires au niveau central pour restreindre le port 445. Un changement à court terme qui « casse certains workflows » coûte moins cher qu’une panne de reconstruction totale.

10) Rechercher des artefacts de note de rançon sur un snapshot de partage (triage sans toucher aux endpoints)

cr0x@server:~$ find /srv/samba/shares -maxdepth 4 -type f -iname '@Please_Read_Me@.txt' -o -iname '*WanaDecryptor*' | head
/srv/samba/shares/finance/@Please_Read_Me@.txt
/srv/samba/shares/hr/@Please_Read_Me@.txt

Ce que cela signifie : Une activité de chiffrement a probablement touché ces répertoires. Vous pouvez évaluer l’impact sans vous connecter aux machines Windows suspectes.
Décision : Geler le partage (lecture seule) si possible et préserver les preuves. Commencer la planification de restauration depuis le dernier snapshot ou backup connu propre.

11) Valider que les sauvegardes ne sont pas montées en lecture-écriture en production (classique auto-attaque)

cr0x@server:~$ mount | grep -E 'backup|repo|vault'
backup01:/repo on /mnt/backup_repo type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.55.200,local_lock=none,addr=10.20.1.50)

Ce que cela signifie : Votre dépôt de sauvegarde est monté en écriture sur un serveur de production. C’est une invitation à chiffrer votre filet de sécurité.
Décision : Passez à un modèle pull ou montez en lecture seule quand c’est faisable. Imposer l’immutabilité/WORM sur les cibles de sauvegarde. Si vous ne pouvez pas, au moins isolez les identifiants et les chemins réseau.

12) Vérifier la disponibilité des snapshots pour une restauration rapide (question du storage engineer)

cr0x@server:~$ zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank/shares@2026-01-22_0000  Wed Jan 22 00:00 2026
tank/shares@2026-01-22_0100  Wed Jan 22 01:00 2026
tank/shares@2026-01-22_0200  Wed Jan 22 02:00 2026
tank/shares@2026-01-22_0300  Wed Jan 22 03:00 2026
tank/shares@2026-01-22_0400  Wed Jan 22 04:00 2026

Ce que cela signifie : Vous avez des snapshots fréquents. C’est votre meilleur allié lors d’événements de ransomware parce que c’est rapide et granulaire.
Décision : Identifier le dernier snapshot propre (avant chiffrement). Planifier une stratégie de clone/rollback qui évite d’écraser les preuves et minimise le downtime.

13) Identifier quel client a modifié des fichiers chiffrés (logs d’audit Samba)

cr0x@server:~$ sudo journalctl -u smbd --since "2026-01-22 03:00" | grep -E 'rename|unlink|pwrite' | head -n 6
Jan 22 03:07:12 fileserver smbd[1823]: [2026/01/22 03:07:12.221] rename finance/q1.xlsx -> finance/q1.xlsx.WNCRY
Jan 22 03:07:12 fileserver smbd[1823]: [2026/01/22 03:07:12.223] pwrite finance/q1.xlsx.WNCRY (client 10.20.88.44)
Jan 22 03:07:13 fileserver smbd[1823]: [2026/01/22 03:07:13.004] rename finance/payroll.csv -> finance/payroll.csv.WNCRY
Jan 22 03:07:13 fileserver smbd[1823]: [2026/01/22 03:07:13.009] pwrite finance/payroll.csv.WNCRY (client 10.20.88.44)

Ce que cela signifie : Vous avez identifié l’IP client effectuant les écritures destructrices.
Décision : Cette IP est une cible de confinement immédiat. Envisagez aussi de révoquer temporairement le token utilisateur/session si vous pouvez le rattacher à une identité.

14) Vérifier que votre DNS n’agit pas de façon « utile » et ne casse pas le comportement du kill-switch

cr0x@server:~$ dig +short -t a example-killswitch-domain.invalid @10.20.0.53
10.20.0.10

Ce que cela signifie : Votre DNS interne transforme les NXDOMAIN en une IP locale. Ce genre de « serviabilité » peut modifier le comportement d’un malware de façon imprévisible.
Décision : Désactivez le wildcarding pour les domaines inconnus dans le DNS d’entreprise. Les contrôles de sécurité doivent être explicites, pas basés sur des surprises.

Blague 2 : « Rien ne construit la collaboration inter-équipes comme un ransomware. Soudain tout le monde sait où est l’équipe firewall. »

Trois micro-récits d’entreprise depuis le terrain

Micro-récit 1 : L’incident causé par une hypothèse fausse

Une entreprise de taille moyenne exploitait un mélange de serveurs Windows modernes et un ensemble tenace de vieux postes de bureau utilisés pour la supervision de contrôle industriel.
Tout le monde « savait » que ces postes étaient isolés. Ils étaient sur un VLAN dédié, après tout. Le schéma réseau le disait, et le schéma avait un logo.

Lors d’une session de support à distance de routine, un technicien a branché l’un de ces postes sur une prise murale pratique dans une zone de bureau général.
Le port était configuré pour le VLAN utilisateur par défaut à cause du « hoteling ». Le poste a obtenu une IP normale, un routage normal, tout normal. Il pouvait voir des partages de fichiers, des imprimantes et d’autres postes.
Personne n’a remarqué, parce que rien n’a cassé immédiatement.

Quand un balayage SMB de type WannaCry a frappé l’environnement (pas nécessairement la souche originale de 2017 — des variantes et ver similaires existent), ce poste était vulnérable et joignable.
Il est devenu une source de tentatives d’infection latérale, et il avait aussi des identifiants mis en cache provenant de travaux d’administration antérieurs.
L’épidémie n’a pas été arrêtée par « le VLAN » parce que le VLAN n’était réel qu’en fonction de la configuration du port switch à ce moment-là.

Le post-mortem a été sans concession : l’hypothèse fausse était « les dispositifs restent là où nous pensons qu’ils sont ».
Les corrections ont été tout aussi nettes : enforcement NAC pour les classes de dispositifs, politiques de sécurité de port qui correspondent au schéma, et règle que les machines héritées vivent derrière un firewall, pas derrière de bonnes intentions.

La leçon : si votre confinement dépend des humains qui branchent des câbles correctement pour toujours, vous n’avez pas de confinement. Vous avez un plan en forme d’espoir.

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

Une autre organisation était fière de son IT « lean ». Ils avaient réduit les fenêtres de maintenance « gaspillées » en étirant les cycles de patch.
Au lieu de lots fréquents et petits, ils faisaient d’importants événements trimestriels de patch. Moins de reboots, moins de tests d’apps, moins d’e-mails mécontents.
Le tableau de bord avait belle allure. Le registre des risques semblait théorique.

Ils avaient aussi optimisé les opérations réseau : large connectivité est-ouest, firewall interne minimal, parce que la segmentation interne était « complexe » et « difficile à dépanner ».
Ils se disaient que l’antivirus endpoint attraperait tout ce qui compte. C’était une belle histoire — jusqu’à ce que ça ne le soit plus.

Quand le comportement de ver SMB est apparu, l’environnement a fonctionné exactement comme conçu : comme un réseau de livraison interne rapide.
Le fossé de patch se comptait en semaines à mois. La connectivité interne était « tout peut parler à tout ».
Au moment où les gens ont réalisé que ce n’était pas une alerte malware normale, une partie du parc de postes était déjà irrécupérable sans reconstruction.

L’optimisation n’était pas seulement la cadence de patch ; c’était la croyance institutionnelle que « moins de changements = plus de stabilité ».
En sécurité, moins de changements équivaut souvent à une douleur retardée avec intérêts.
Ils sont passés à des patchs mensuels, ont imposé des expirations d’exception, et ont introduit des restrictions SMB entre réseaux utilisateurs et réseaux serveurs.

La leçon : optimiser pour moins de changements va bien — jusqu’à ce que le monde change pour vous. Les vers adorent le changement.

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

Une troisième entreprise avait la réputation d’être irritante de discipline. Ils faisaient des revues de conformité aux patchs hebdomadaires. Pas excitant.
Ils avaient une fenêtre de changement régulière. Également pas excitant.
Ils utilisaient des admins en niveaux : les identifiants admin postes ne touchaient pas les serveurs, et les identifiants admin serveurs ne touchaient pas les contrôleurs de domaine sauf si nécessaire. Très pas excitant.

Ils traitaient aussi les partages de fichiers comme des systèmes de production. Snapshots horaires pour les datasets critiques, copies offsite quotidiennes avec contrôles d’immutabilité, et un exercice de restauration trimestriel.
L’exercice de restauration était impopulaire. Il occupait des weekends et produisait le genre de tickets pour lesquels personne n’est promu.

Quand un rançongiciel a touché un segment d’utilisateurs, il a chiffré du contenu de lecteurs mappés depuis une poignée de clients.
Mais SMB vers le réseau serveur était restreint, donc ça ne s’est pas propagé via des chemins serveur-à-serveur.
Les endpoints infectés ont été isolés par l’EDR en quelques minutes, et les partages ont été restaurés depuis un snapshot propre avec une perte de données minimale.

L’incident a quand même coûté du temps et du stress — pas de conte de fées ici — mais il n’est pas devenu une panne d’entreprise.
Les contrôles « ennuyeux » ont transformé une crise existentielle en un mercredi désagréable.

La leçon : les pratiques ennuyeuses s’accumulent. Elles ne font pas la une. Elles rendent la survie normale.

Erreurs fréquentes : symptôme → cause profonde → correction

1) « Nous avons patché MS17-010, donc on est safe »

Symptôme : Vous voyez toujours des scans SMB et des infections sur certains hôtes.
Cause profonde : La conformité au patch était incomplète (portables manqués, sous-réseaux isolés, serveurs manuels, dérive d’image), ou SMBv1 restait activé et exposé.
Correction : Mesurez la conformité par vérification active (scan et checks de configuration), pas par « WSUS dit approuvé ». Désactivez SMBv1. Restreignez TCP/445 est-ouest.

2) « On a bloqué SMB en périphérie, pourquoi ça se propage ? »

Symptôme : L’épidémie est entièrement interne et continue d’augmenter.
Cause profonde : Réseau interne plat avec TCP/445 non restreint ; modèle de menace interne ignoré.
Correction : Segmentation : autoriser SMB uniquement entre clients et serveurs de fichiers désignés. Bloquer le SMB poste-à-poste. Utiliser des règles firewall qui reflètent les flux métiers, pas les sous-réseaux-politique.

3) « L’EDR dit contenu, mais les partages continuent d’être chiffrés »

Symptôme : Les alertes endpoint cessent, mais les fichiers continuent d’être renommés en extensions chiffrées ou des notes de rançon apparaissent.
Cause profonde : Un hôte infecté mais non isolé a toujours accès aux partages ; ou un second hôte est compromis ; ou un compte de service est abusé.
Correction : Utiliser les logs des serveurs de fichiers pour identifier les IP clientes modifiant le contenu. Mettre temporairement les partages en lecture seule. Révoquer des tokens en désactivant des comptes si nécessaire, puis faire tourner les identifiants.

4) « Les restaurations échouent »

Symptôme : Des jobs de backup existent, mais la restauration est lente, incomplète ou corrompue.
Cause profonde : Les sauvegardes étaient en ligne et chiffrées ; les sauvegardes n’ont jamais été testées ; le serveur de sauvegarde utilisait des identifiants domain admin exposés aux endpoints.
Correction : Mettre en place des sauvegardes immuables et des identifiants séparés. Exécuter des tests de restauration réguliers. Garder les dépôts de sauvegarde hors des mêmes frontières de confiance que les endpoints.

5) « On ne peut pas désactiver SMBv1 parce que ça peut casser quelque chose »

Symptôme : Exceptions et délais sans fin ; SMBv1 reste activé par défaut.
Cause profonde : Dépendances inconnues et absence de propriétaires pour les applications/devices hérités.
Correction : Inventorier l’utilisation de SMBv1, nommer des responsables, et imposer des délais. Si un appareil nécessite SMBv1, isolez-le et mettez un plan de remplacement avec une date sur papier.

6) « On ne peut pas redémarrer les serveurs pour appliquer des patches »

Symptôme : Les systèmes critiques accumulent des mois de mises à jour manquantes.
Cause profonde : Services fragiles sans HA, pas de fenêtre de maintenance, ou peur du changement due à des pannes passées.
Correction : Construire de la HA ou reconsidérer l’architecture pour rendre les reboots routiniers. Si vous ne pouvez pas redémarrer un serveur Windows, ce n’est pas « critique », c’est « un point de défaillance unique que vous refusez d’admettre ».

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

1) Checklist réponse d’urgence (premières 4 heures)

1. Contenir : Isoler les endpoints infectés ; bloquer TCP/445 entre segments utilisateurs immédiatement.
2. Délimiter : Identifier les partages touchés ; identifier les hôtes scannants ; lister tous les écouteurs SMB en interne.
3. Stabiliser : Protéger les sauvegardes : démonter les dépôts de backup inscriptibles depuis la production ; s’assurer que les identifiants de backup ne sont pas utilisés sur les endpoints.
4. Vérifier les correctifs : Prioriser la couverture MS17-010 sur les hôtes exposés SMB et tout ce qui a une portée large.
5. Communiquer : Indiquer au business ce qui sera perturbé (restrictions SMB, reboots forcés) et pourquoi. La clarté bat l’optimisme.
6. Préserver les preuves : Snapshots/export de logs des partages affectés ; collecter des artefacts endpoint si vous disposez de capacité forensique.

2) Checklist durcissement (jours suivants, 7 jours)

1. Désactiver SMBv1 largement ; suivre et isoler les exceptions.
2. Imposer le SMB signing quand c’est faisable, surtout sur les serveurs.
3. Segmenter les réseaux : bloquer le SMB poste-à-poste ; autoriser uniquement le SMB client→serveur requis.
4. Conformité aux patches : définir un SLA (p.ex. critique sous quelques jours) et appliquer via reporting + automatisation.
5. Moindre privilège admin : comptes admin par niveau ; pas d’utilisation de domain admin sur les endpoints.
6. Renforcement des backups : copies immuables, option offline/air-gapped et tests de restauration.
7. Journalisation : centraliser les logs d’événements Windows et les logs d’audit des serveurs de fichiers pour une attribution client rapide.

3) Checklist ingénierie (30–90 jours)

1. Reconstruire la pipeline de patching comme un système de production : rings phasés, canaris, rollback, métriques.
2. Précision de l’inventaire des actifs : réconcilier DHCP, AD, EDR et scans réseau ; les dispositifs inconnus deviennent des incidents.
3. Concevoir pour les reboots : HA là où c’est nécessaire ; fenêtres de maintenance réelles ; éliminer le folklore du « pas de reboot ».
4. Comptes de service : rotation régulière ; restreindre les droits de connexion ; surveiller l’activité SMB anormale et les changements massifs de fichiers.
5. Exercices tabletop : exécuter un drill de wormable-ransomware, pas un slide deck. Valider le temps d’isolation et de restauration.

FAQ

1) WannaCry était-il majoritairement une attaque par phishing ?

La caractéristique définissante était la propagation de type ver via SMB exploitant des vulnérabilités de la classe MS17-010. L’interaction utilisateur n’était pas requise pour la propagation entre hôtes vulnérables.

2) Si nous patchons MS17-010 aujourd’hui, est-ce que c’est fini ?

Non. Patch, puis restreindre l’exposition SMB, désactiver SMBv1 et durcir les sauvegardes. Les épidémies wormables prospèrent sur la joignabilité et une segmentation interne faible, pas seulement sur l’absence de KB.

3) Pourquoi SMBv1 est-il encore présent dans les entreprises ?

Parce que des appareils anciens et des applications héritées persistent, et que l’on craint de les casser. Le bon mouvement est d’isoler strictement les dépendances SMBv1 et de les remplacer selon une échéance.

4) Faut-il payer la rançon ?

Opérationnellement, payer ne garantit pas la récupération et peut créer d’autres problèmes (y compris un ciblage répété). Le meilleur investissement est la capacité de restauration : snapshots, sauvegardes immuables et récupération pratiquée.

5) Quelle est la mesure de confinement la plus rapide pour un événement de type WannaCry ?

Bloquer TCP/445 est-ouest (surtout poste-à-poste) et isoler les hôtes scannants. Vous coupez les jambes du ver.

6) Comment trouver rapidement « la seule machine non patchée » ?

Commencez par la vérité réseau : scanner pour les écouteurs TCP/445, puis vérifier l’état des patches/configuration de ces hôtes. Les CMDB sont utiles, mais le flux de paquets est la réalité.

7) Les sauvegardes peuvent-elles aussi être chiffrées ?

Oui, si elles sont montées en lecture-écriture, joignables avec des identifiants compromis, ou stockées sur des partages accessibles depuis des endpoints infectés. Les sauvegardes immuables et la séparation des frontières de confiance sont non négociables.

8) Désactiver SMB casse-t-il le partage Windows ?

Désactiver SMB complètement le ferait, mais on désactive typiquement SMBv1 (ancien, risqué) et on conserve SMBv2/v3. On restreint aussi les emplacements où SMB est autorisé, au lieu de le laisser circuler.

9) Pourquoi les « fenêtres de patch » échouent-elles en pratique ?

Parce que le patching est traité comme un projet, pas comme une boucle opérationnelle. Les organisations qui réussissent le gèrent comme des déploiements : rings, monitoring, rollback rapide et responsabilité pour les exceptions.

Prochaines étapes réalisables cette semaine

Si WannaCry a enseigné quelque chose à l’industrie, c’est que « nous avions l’intention de patcher » n’est pas un contrôle d’incident. C’est une confession.
L’objectif n’est pas d’être parfait. L’objectif est de ne plus être surpris par quelque chose que vous pouvez mesurer.

1. Lancer un scan interne TCP/445 et remettre la liste aux personnes qui peuvent réellement modifier les politiques firewall.
2. Choisir une date pour désactiver SMBv1 à l’échelle de l’entreprise. Commencer par une ring pilote, puis accélérer. Les exceptions vont dans des VLANs d’isolation avec approbation du propriétaire.
3. Mesurer la conformité aux patches de l’extérieur (scans réseau + vérifications de configuration), pas seulement depuis l’outil de patch.
4. Corriger les sauvegardes sérieusement : copie immuable, copie offsite, et un exercice de restauration qui produit un temps de restauration réel, pas un PowerPoint.
5. Mettre en place un interrupteur de confinement : un jeu de règles firewall d’urgence pour restreindre SMB est-ouest que vous pouvez activer en minutes, pas en heures.

Faites cela, et la prochaine vague de rançongiciels wormables restera encore agaçante. Elle ne sera juste pas existentielle. Voilà l’objectif. Atteignez-le.