Le mythe du « meilleur antivirus » : ce qui empêche réellement les rançongiciels

Le mythe : « meilleur antivirus » comme stratégie de sécurité

L’antivirus (AV) et même les outils modernes pour endpoints ne sont pas inutiles. Ils ne constituent simplement pas un contrôle primaire contre les rançongiciels. Les considérer comme « la chose qui arrête les rançongiciels » revient à considérer la ceinture de sécurité comme un plan pour éviter les accidents de voiture. Bien d’avoir, pas suffisant pour empêcher l’accident.

Les opérateurs de rançongiciels ne misent plus l’entreprise sur un malware basique. Ils suivent des playbooks. Ils achètent des accès. Ils exploitent l’identité. Ils vivent off the land. Ils utilisent des outils signés, des outils de gestion à distance, des utilitaires d’administration légitimes et des identifiants volés. Ils prennent leur temps. Ils désactivent ce que vous avez acheté pour vous protéger, ou ils passent autour.

Le mode d’échec fondamental derrière le mythe du « meilleur AV » est une erreur de catégorie : l’AV est un contrôle/détection sur les endpoints. Le rançongiciel est une défaillance opérationnelle qui s’étend à l’identité, au réseau, aux sauvegardes, au stockage et à la réponse. Les contrôles endpoint sont une couche, mais vous avez besoin d’une défense qui résiste à un attaquant avec des privilèges admins.

Réalité sèche : si un adversaire devient administrateur de domaine et peut atteindre votre système de sauvegarde, votre score « meilleur AV » ne comptera pas beaucoup.

Une citation à accrocher au mur : « L’espoir n’est pas une stratégie. » — Vince Lombardi

Blague #1 (courte, pertinente) : L’antivirus, c’est comme le déodorant : ça aide, mais ça ne remplace pas le bain.

Faits et historique : comment on en est arrivé là (et pourquoi c’est important)

Les rançongiciels semblent modernes, mais ils évoluent depuis des décennies. Quelques points concrets qui expliquent pourquoi les défenses actuelles doivent être opérationnelles, pas seulement logicielles :

• 1989 : Le Trojan AIDS est souvent cité comme un précurseur du rançongiciel—distribué sur disquettes, utilisant un chiffrement rudimentaire et un paiement par courrier. Le modèle a fonctionné même quand la crypto ne fonctionnait pas.
• Milieu des années 2000 : Le « scareware » et les faux antivirus ont monétisé la peur. Ils ont appris aux criminels que le comportement des utilisateurs et les flux de paiement importent plus que l’élégance technique.
• 2013–2016 : CryptoLocker et ses successeurs ont industrialisé le chiffrement fort à grande échelle. L’ère « chiffrer tout rapidement » commence.
• 2017 : WannaCry et NotPetya se sont propagés via des vulnérabilités wormables et une mauvaise hygiène de patch. NotPetya était destructeur sous couvert de rançongiciel—les assurances et les playbooks de réponse ont dû s’adapter.
• 2019–2021 : La « big game hunting » a ciblé les entreprises : intrusion manuelle, escalation de privilèges et impact sur mesure. Le chiffrement n’était que l’acte de clôture.
• Double extorsion : Les attaquants ont commencé à voler les données avant de les chiffrer, transformant la « restauration depuis sauvegarde » en demi-solution.
• Ransomware-as-a-service : Les affiliés ont marchandisé les intrusions. Les compétences se sont distribuées ; le volume augmente ; les tactiques se standardisent.
• Guerres EDR : Les opérateurs testent et adaptent explicitement leurs charges contre des suites EDR populaires. L’endpoint devient un espace contesté, pas sûr.
• Torsion de l’ère cloud : L’identité et l’abus d’API peuvent effacer du stockage objet ou chiffrer des données SaaS. Votre « AV endpoint » est hors sujet face à un token OAuth volé.

Ce ne sont pas des anecdotes. Elles expliquent la règle moderne : vous ne pouvez pas compter sur un seul produit préventif, car la capacité fondamentale de l’attaquant est de s’adapter aux produits.

Ce que fait réellement un rançongiciel dans votre environnement

La plupart des incidents de rançongiciels en entreprise suivent une séquence assez banale. « Banale » n’est pas réconfortant. Cela signifie que ça arrive souvent.

Phase 1 : Accès initial

Points d’entrée courants : identifiants VPN compromis sans MFA, RDP exposé, phishing capturant des tokens, appliances périphériques non patchées, ou outils distants tiers. L’attaquant veut un point d’appui qui ressemble à un travail distant normal.

Phase 2 : Vol d’identifiants et élévation de privilèges

Dumping d’identifiants, vol de tokens, abus de Kerberos, password spraying, réutilisation d’administrateurs locaux. Si vos admins se connectent à des postes de travail avec des comptes domain admin, le travail de l’attaquant devient beaucoup plus simple.

Phase 3 : Découverte et mouvement latéral

Ils énumèrent les partages de fichiers, serveurs de sauvegarde, hyperviseurs, contrôleurs de domaine et systèmes de supervision. Ils cherchent vos joyaux de la couronne et les systèmes qui pourraient vous aider à récupérer. S’ils peuvent briser la récupération, la rançon augmente.

Phase 4 : Vol de données (optionnel, de plus en plus courant)

Ils préparent et exfiltrent des données sensibles. C’est là que les graphiques de bande passante et des connexions sortantes inattendues comptent. Si vous n’avez pas de surveillance d’egress, vous l’apprendrez au moment de la note de rançon.

Phase 5 : Impact

Chiffrement des endpoints et serveurs, suppression des shadow copies/snapshots, désactivation de services, modifications massives de GPO, et—si vous avez de la malchance—destruction des sauvegardes. C’est le moment « tout est en feu », mais ça a commencé des heures ou des jours plus tôt.

Contrôles qui empêchent réellement les rançongiciels (et pourquoi)

Notez le mot « empêcher ». Pas « détecter après que c’est partout ». La vraie prévention signifie arrêter l’attaquant avant qu’il puisse chiffrer massivement ou avant qu’il détruise votre capacité à restaurer.

1) Durcissement des identités > exploits endpoint héroïques

Si vous ne pouvez pas protéger les identités, vous ne pouvez rien protéger. Les opérateurs de rançongiciels adorent les environnements où les identifiants sont durables, sur-privilégiés et réutilisés sans précaution.

• MFA partout (VPN, email, portails admin, consoles cloud). Préférez une MFA résistante au phishing pour les rôles admin.
• Comptes admin séparés (usage quotidien vs privilégié). Aucun domain admin ne doit surfer sur le web.
• Postes d’accès privilégié (PAW) ou jump hosts durcis pour les actions administratives.
• Modèle de niveaux (les contrôleurs de domaine sont Tier 0 ; gardez les credentials Tier 0 hors des niveaux inférieurs).
• Réduire les privilèges permanents avec élévation just-in-time quand c’est possible.

2) Sauvegardes : la seule « cure », si elles ne peuvent pas être supprimées

Les sauvegardes ne sont pas une case à cocher. Ce sont des systèmes qui affrontent des adversaires. Si l’attaquant peut utiliser vos outils d’administration pour supprimer les sauvegardes, vous n’avez pas de sauvegardes. Vous avez un espoir coûteux et faux.

À quoi ressemble le « bon » :

• 3-2-1 : trois copies, deux types de médias, une hors site/isolée. Toujours une base solide.
• Immutabilité : snapshots/object lock ou politiques WORM que vos admins habituels ne peuvent pas outrepasser rapidement.
• Copie hors-ligne/air-gapped (logique ou physique). Tout n’a pas besoin d’être hors-ligne, mais quelque chose doit l’être.
• Tests de restauration : planifiés, mesurés et ennuyeux. L’objectif n’est pas une sauvegarde réussie ; c’est une restauration réussie.
• RPO/RTO conçus : ce que vous pouvez perdre (RPO) et la rapidité de remise en service (RTO). Si vous n’avez jamais chronométré une restauration, votre RTO est un vœu.

3) Segmentation réseau : rendre le mouvement latéral coûteux

Les réseaux plats accélèrent les rançongiciels. La segmentation transforme « un portable compromis » en « un portable compromis », au lieu de « toute l’entreprise compromise ».

• Isoler les sauvegardes du réseau serveur général. Limiter les ports de gestion aux jump hosts.
• Séparer les sous-réseaux utilisateurs des sous-réseaux serveurs ; séparer les sous-réseaux serveurs par fonction.
• Restreindre le trafic est-ouest. Rendre SMB et WinRM particulièrement difficiles à atteindre.
• Contrôler l’egress. La plupart des environnements surveillent l’inbound ; les attaquants aiment l’outbound.

4) Journalisation et surveillance résistantes à l’attaque

Les attaquants désactivent ce qu’ils peuvent voir. Si vos logs vivent sur le même domaine et le même stockage qui est chiffré, vous ferez la forensique à l’intuition.

• Centrer les logs vers un système avec accès durci.
• Alerter sur événements d’identité : nouveaux comptes admin, nouveaux service principals, changements d’adhésion de groupe.
• Alerter sur altération des sauvegardes : suppression de jobs, changements de rétention, suppression de snapshots.
• Alerter sur modèles massifs de renommage/écriture de fichiers et forts débits d’écriture SMB.

5) Gestion des correctifs : pas parfaite, mais essentielle

La bonne hygiène de patch n’empêchera pas le vol d’identifiants, mais elle bloquera une part importante des accès initiaux et des élévations de privilèges. Priorisez les périphériques edge, les appliances VPN, les outils RMM, les hyperviseurs et les contrôleurs de domaine. Si votre cadence de patch est « quand on a le temps », le rançongiciel planifiera ce temps pour vous.

6) EDR et AV : utiles, mais pas le chef du plan

Utilisez des solutions modernes de détection/réponse endpoint pour la visibilité, l’isolation et la contention. Mais supposez qu’au moins un endpoint sera manqué ou pourra exécuter quelque chose de toute façon. Vos autres couches doivent tenir.

7) Ingénierie du stockage : snapshots, immutabilité et contrôle du rayon d’impact

En tant que personne en stockage, voici la vérité inconfortable : le rançongiciel est une charge de travail sur le stockage. C’est une tempête d’écritures amplifiées, de manipulation des métadonnées et d’écritures petites et nombreuses avec une attitude. Vous verrez des pics d’IOPS, des latences qui grimpent et des pools soudainement « occupés » alors que le trafic métier est normal.

Contrôles de stockage importants :

• Snapshots immuables (là où supporté) ou politiques de snapshot protégées des credentials d’admin de routine.
• Séparer le stockage de sauvegarde du primaire. Identifiants différents, réseau différent, domaine de panne différent.
• Surveiller les taux de suppression et les tempêtes de renommage sur les systèmes de fichiers.
• Connaître vos chemins de restauration : restaurations au niveau VM, au niveau fichier, bare metal. Mesurez-les.

Tâches pratiques : 12+ vérifications concrètes avec commandes et décisions

Voici des tâches pratiques que vous pouvez exécuter aujourd’hui. Chacune inclut une commande, un exemple de sortie, ce que ça signifie et la décision à prendre. Supposez des serveurs Linux pour l’hôte de commande sauf indication contraire ; adaptez à votre environnement.

Task 1: Check for suspicious SMB share activity (Linux Samba server)

cr0x@server:~$ sudo smbstatus -b
Samba version 4.15.13-Ubuntu
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
-----------------------------------------------------------------------------------------------------------------------------
2314    jdoe         domain users  10.20.5.44 (ipv4:10.20.5.44:49832)       SMB3_11           -                    partial
2488    svc_backup   domain users  10.20.9.12 (ipv4:10.20.9.12:52110)       SMB3_11           -                    partial

Service      pid     Machine       Connected at                     Encryption   Signing
------------------------------------------------------------------------------------------
finance      2314    10.20.5.44    Tue Feb  5 10:12:44 2026 UTC     -            partial
profiles     2488    10.20.9.12    Tue Feb  5 09:55:03 2026 UTC     -            partial

Ce que cela signifie : Sessions SMB actives et les partages touchés. Un seul poste martelant un partage sensible en dehors des heures ouvrables est suspect.

Décision : Si un hôte inattendu est connecté à de nombreux partages ou si de nombreuses sessions apparaissent rapidement, isolez cet endpoint et lancez des vérifications d’audit de fichiers.

Task 2: Detect a rename/write storm on a filesystem (Linux)

cr0x@server:~$ sudo iostat -xz 1 3
Linux 6.5.0-15-generic (fs01)  02/05/2026  _x86_64_ (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9.12    0.00    6.44   31.88    0.00   52.56

Device            r/s     rkB/s   rrqm/s  %rrqm   r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm   w_await wareq-sz  aqu-sz  %util
nvme0n1          4.12    211.4     0.00   0.00    2.41    51.30   812.3  18244.0   120.1  12.88   38.22    22.45   31.2   99.1

Ce que cela signifie : Nombre élevé d’opérations d’écriture, iowait élevé, forte utilisation. Les rançongiciels apparaissent souvent comme une pression d’écriture soutenue avec beaucoup de petites écritures.

Décision : Si c’est anormal pour l’hôte, considérez-le comme un incident. Corrélez avec l’IO au niveau processus et les événements d’authentification récents.

Task 3: Identify top IO processes (Linux)

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ:         0.00 B/s | Total DISK WRITE:      65.12 M/s
TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
8123 be/4  root        0.00 B/s   18.22 M/s  0.00 % 98.00 %  python3 /opt/agent/tmp/enc.py
3911 be/4  nobody      0.00 B/s   12.05 M/s  0.00 % 87.00 %  smbd: notifyd

Ce que cela signifie : Un seul processus effectuant des écritures lourdes et soutenues est un signal d’alerte—surtout depuis des chemins étranges comme /opt/agent/tmp.

Décision : Tuez/isoliez l’hôte, préservez les preuves, et vérifiez si ce processus existe sur d’autres systèmes.

Task 4: Check for recently modified executable files in suspicious directories (Linux)

cr0x@server:~$ sudo find /tmp /var/tmp /dev/shm -type f -mtime -1 -maxdepth 2 -ls | head
131099  120 -rwxr-xr-x   1 root root   122880 Feb  5 09:58 /tmp/.cache/agent
131104   44 -rwxr-xr-x   1 root root    45056 Feb  5 10:01 /dev/shm/.x

Ce que cela signifie : Des exécutables frais dans des emplacements temporaires sont courants dans les chaînes d’intrusion.

Décision : Si vous voyez de nouveaux artefacts exécutables, quaranténez le système et hashez/collectez-les pour analyse.

Task 5: Verify backup repository immutability controls (example: ZFS snapshots)

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation tank/backups | tail -5
tank/backups@auto-2026-02-05_0100  Tue Feb  5 01:00 2026
tank/backups@auto-2026-02-05_0200  Tue Feb  5 02:00 2026
tank/backups@auto-2026-02-05_0300  Tue Feb  5 03:00 2026
tank/backups@auto-2026-02-05_0400  Tue Feb  5 04:00 2026
tank/backups@auto-2026-02-05_0500  Tue Feb  5 05:00 2026

Ce que cela signifie : Les snapshots existent et sont créés selon le calendrier. C’est nécessaire, mais pas suffisant.

Décision : Confirmez qui peut détruire ces snapshots. Si « domain admins peuvent SSHer et exécuter zfs destroy », vous n’avez pas d’immuabilité ; vous avez une liste de tâches.

Task 6: Check whether snapshots are protected by delegation (ZFS example)

cr0x@server:~$ sudo zfs allow tank/backups
---- Permissions on tank/backups --------------------------------------------
Local+Descendent permissions:
user backupsvc create,mount,receive,rollback,snapshot
user root create,destroy,mount,receive,rename,rollback,snapshot

Ce que cela signifie : Seul root peut détruire snapshots/datasets ; le compte de service de sauvegarde peut créer/recevoir/snapshot mais pas détruire.

Décision : C’est un bon modèle. Si votre service de sauvegarde peut détruire ou renommer, corrigez cela. Si trop d’humains peuvent devenir root facilement, corrigez aussi.

Task 7: Validate you can restore (not just back up) a file quickly (ZFS clone example)

cr0x@server:~$ sudo zfs clone tank/backups@auto-2026-02-05_0500 tank/restore-test
cr0x@server:~$ ls -lah /tank/restore-test/finance/ | head
total 64K
drwxr-xr-x  2 root root 4.0K Feb  5 05:00 .
drwxr-xr-x  8 root root 4.0K Feb  5 05:00 ..
-rw-r--r--  1 root root  18K Feb  5 04:59 invoice-2026-02.csv

Ce que cela signifie : Vous pouvez monter une vue à un point dans le temps sans toucher aux données de production. Voilà ce que signifie être prêt à restaurer.

Décision : Chronométrez cette opération et enregistrez-la. Si cela prend trop de temps, vos hypothèses RTO sont erronées.

Task 8: Check for mass file changes using audit logs (Linux auditd example)

cr0x@server:~$ sudo ausearch -ts today -k finance-share | tail -5
time->Tue Feb  5 10:03:41 2026
type=SYSCALL msg=audit(1738759421.211:1293): arch=c000003e syscall=82 success=yes exit=0 a0=ffffff9c a1=7f2a2c001b40 a2=241 a3=1b6 items=2 ppid=8123 pid=8123 auid=1002 uid=0 gid=0 exe="/usr/bin/python3" comm="python3"
type=PATH msg=audit(1738759421.211:1293): item=1 name="/srv/samba/finance/Q1/budget.xlsx.locked" inode=901232 dev=fd:00 mode=0100644 ouid=1002 ogid=1002 rdev=00:00 nametype=CREATE

Ce que cela signifie : Un processus crée des fichiers avec une nouvelle extension dans le partage finance. C’est un comportement classique de chiffrement.

Décision : Contenir immédiatement : isoler hôte/utilisateur, désactiver les credentials, bloquer SMB depuis cette source, préserver le snapshot.

Task 9: Check outbound connections for large unexpected transfers (Linux)

cr0x@server:~$ sudo ss -tpn | head -8
State Recv-Q Send-Q Local Address:Port  Peer Address:Port  Process
ESTAB 0      131072 10.20.9.22:443      185.199.110.153:52344 users:(("rclone",pid=9011,fd=7))
ESTAB 0      0      10.20.9.22:22       10.20.1.10:49822   users:(("sshd",pid=1881,fd=3))

Ce que cela signifie : Des outils comme rclone sont souvent abusés pour l’exfiltration parce qu’ils ressemblent à une synchronisation cloud normale.

Décision : Si vous n’exécutez pas rclone en production, traitez cela comme un incident. Tuez le processus, capturez la ligne de commande/l’historique et vérifiez les logs d’egress pour ce qui est parti.

Task 10: Verify domain controller replication health (Windows from a management host using WinRM is common; here’s a Linux-based check via samba-tool)

cr0x@server:~$ samba-tool drs showrepl dc01.corp.example
DSA Options: 0x00000001
DSA object GUID: 2b6b0f4b-3a2b-4d2a-9f2a-3b5a9c9aa2ad
==== INBOUND NEIGHBORS ====
DC=corp,DC=example
    dc02.corp.example via RPC
        DSA object GUID: 9d7b1c2a-1c11-4a72-ae9e-2d0b2a6a0c17
        Last attempt @ Tue Feb  5 09:55:12 2026 UTC was successful

Ce que cela signifie : Si la réplication est cassée, vous ne pouvez pas faire confiance aux changements d’adhésion de groupe, aux réinitialisations de mot de passe ou à l’état des GPO pendant la réponse à l’incident.

Décision : Si la réplication échoue, stabilisez d’abord AD. Beaucoup de récupérations échouent parce que l’identité est incohérente.

Task 11: Check for new local admin additions (Linux example via sudoers and group files)

cr0x@server:~$ sudo grep -R "ALL=(ALL)" -n /etc/sudoers /etc/sudoers.d | head
/etc/sudoers:27:%sudo   ALL=(ALL:ALL) ALL
/etc/sudoers.d/90-cloud-init-users:1:deploy ALL=(ALL) NOPASSWD:ALL

Ce que cela signifie : Un sudo sans mot de passe pour un compte général est un cadeau pour les attaquants qui atterrissent sur cet hôte.

Décision : Supprimez NOPASSWD là où ce n’est pas strictement requis, et contraignez les commandes. Si c’est nécessaire, placez-le derrière une authentification forte et une journalisation sur un jump host.

Task 12: Confirm backups are completing and not silently failing (generic: check systemd timers + logs)

cr0x@server:~$ systemctl list-timers --all | grep -E "backup|restic|borg"
Tue 2026-02-05 01:00:00 UTC  4h 59min left Tue 2026-02-04 01:00:03 UTC 19h ago  restic-backup.timer  restic-backup.service
cr0x@server:~$ sudo journalctl -u restic-backup.service -n 8 --no-pager
Feb 04 01:00:03 backup01 restic[2201]: repository 1a2b3c4d opened successfully
Feb 04 01:12:44 backup01 restic[2201]: processed 412563 files, 1.8 TiB in 12m41s
Feb 04 01:12:44 backup01 restic[2201]: snapshot 9f8e7d6c saved
Feb 04 01:12:44 backup01 systemd[1]: restic-backup.service: Succeeded.

Ce que cela signifie : Les sauvegardes ont été exécutées, complétées et ont enregistré un snapshot. Vous apprenez aussi le débit et l’échelle, ce qui compte pour les restaurations.

Décision : Si les sauvegardes échouent, corrigez cela avant d’entreprendre quoi que ce soit de « avancé ». Si elles sont lentes, planifiez des améliorations de capacité de restauration.

Task 13: Test restore integrity with a checksum comparison (example)

cr0x@server:~$ sha256sum /srv/data/finance/invoice-2026-02.csv
c8b1d7a2b2a5ef3fdddbf0d66a52f3f3d8b2d1e2f30d7c2f2e0b7b2b3a1f0a9e  /srv/data/finance/invoice-2026-02.csv
cr0x@server:~$ sha256sum /tank/restore-test/finance/invoice-2026-02.csv
c8b1d7a2b2a5ef3fdddbf0d66a52f3f3d8b2d1e2f30d7c2f2e0b7b2b3a1f0a9e  /tank/restore-test/finance/invoice-2026-02.csv

Ce que cela signifie : Votre copie restaurée correspond à la production. C’est ainsi que vous prouvez que les sauvegardes ne sont pas seulement présentes, mais correctes.

Décision : Si les sommes de contrôle ne correspondent pas, traitez cela comme une corruption de données ou une sauvegarde incomplète et enquêtez avant qu’un incident ne vous force la main.

Task 14: Quickly find processes with suspicious persistence (Linux)

cr0x@server:~$ systemctl list-unit-files --type=service | grep -E "agent|update|backup" | head
agent-updater.service                      enabled
backup-sync.service                        enabled
system-update.service                      enabled
cr0x@server:~$ systemctl status agent-updater.service --no-pager | sed -n '1,12p'
● agent-updater.service - Agent Updater
     Loaded: loaded (/etc/systemd/system/agent-updater.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-02-05 09:58:11 UTC; 7min ago
   Main PID: 8123 (python3)
     CGroup: /system.slice/agent-updater.service
             └─8123 /usr/bin/python3 /opt/agent/tmp/enc.py

Ce que cela signifie : La persistance via systemd est courante. Un service exécutant un script depuis un chemin temporaire est extrêmement suspect.

Décision : Arrêtez le service, isolez l’hôte, capturez le fichier d’unité et le script pour analyse, et recherchez cette unité sur l’ensemble du parc.

Mode d’intervention rapide

Voici la liste « entrer dans la salle de crise et être utile en cinq minutes ». L’objectif est de trouver le goulot : s’agit-il d’une épidémie d’endpoints, d’une compromission d’identité, d’un événement de saturation du stockage ou d’une tentative de destruction des sauvegardes ?

Première étape : confirmer la portée et arrêter l’hémorragie

1. Identifier le patient zéro : quel hôte/utilisateur a signalé les premiers fichiers chiffrés ? Corrélez les horodatages avec les logs d’authentification.
2. Isoler les sources probables : mettre en quarantaine les endpoints au niveau réseau quand c’est possible ; ne comptez pas sur la coopération de l’endpoint.
3. Geler les sauvegardes/snapshots : préservez immédiatement les points de restauration. Si vous avez des snapshots immuables, vérifiez qu’ils existent toujours et sont accessibles.

Deuxième étape : déterminer si l’identité est compromise

1. Vérifier les changements de comptes privilégiés : nouveaux admins, changements d’adhésion de groupes, connexions suspectes depuis des hôtes inhabituels.
2. Vérifier les réinitialisations massives de mots de passe ou la désactivation de la MFA. Les attaquants « préparent » parfois en coupant les défenseurs.
3. Confirmer la santé des DC : si AD est instable, vos actions de remédiation risquent de ne pas se propager correctement.

Troisième étape : déterminer s’il s’agit de chiffrement, d’exfiltration ou des deux

1. Télémetry de stockage : pics d’iowait, rafales d’écritures SMB, ops métadonnées élevées. Le chiffrement fait beaucoup de bruit au niveau stockage.
2. Télémetry d’egress : connexions sortantes inhabituelles, outils comme rclone, gros transferts vers IP inconnues.
3. Indicateurs de fichiers : nouvelles extensions, notes de rançon, schémas de renommage cohérents.

Quatrième étape : choisir une voie de récupération

• Si les sauvegardes sont intactes : priorisez la contention et la planification de restauration. Ne précipitez pas les restaurations dans un domaine encore compromis.
• Si les sauvegardes sont menacées : sécurisez-les immédiatement (changement de credentials, isolation réseau, révocation d’accès). Le temps compte plus que l’élégance.
• Si l’exfiltration est confirmée : impliquez tôt le juridique/compliance ; la restauration n’efface pas les obligations de divulgation.

Trois mini-récits d’entreprises depuis le terrain

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

Ils étaient fiers de leur suite endpoint. Grand fournisseur connu, marketing agressif, un tableau de bord rempli de pastilles vertes rassurantes. Le responsable sécurité pouvait montrer des rapports mensuels indiquant des malwares bloqués. La direction adorait parce que ça avait l’air d’un progrès.

L’hypothèse erronée était simple : « Si nous avons l’EDR, le rançongiciel ne peut pas se propager. » En réalité, l’EDR était déployé sur la plupart des endpoints, avec des exclusions pour performances sur un ensemble de serveurs de fichiers qui « ne pouvaient pas se permettre le surcoût ». Ces serveurs étaient l’endroit où les employés stockaient tout ce qui comptait. Les serveurs avaient aussi des réglages SMB anciens pour une application legacy que personne ne voulait toucher.

Un attaquant est entré via un compte VPN d’un sous-traitant sans MFA. Le compte avait été « temporaire » pendant six mois. Ils ont bougé latéralement, trouvé les serveurs de fichiers non protégés et lancé l’encryption directement dessus. Pas d’agent endpoint signifie pas d’isolation automatique. Au moment où le helpdesk a vu le premier ticket, le stockage était déjà saturé d’écritures et le partage était un cimetière de fichiers renommés.

Pendant le post-mortem, la prise de conscience est tombée : leur « meilleur AV » n’a pas failli. Il a fait ce qu’il pouvait sur les endpoints où il était déployé. Leur stratégie a échoué parce qu’ils avaient construit un système où les actifs les plus importants étaient les moins protégés, et où un contrôle manquant s’est transformé en crise d’entreprise.

La correction n’était pas « acheter un meilleur produit ». Ce fut un projet de segmentation, application de la MFA, suppression des accès permanents, et refonte du dépôt de sauvegarde pour qu’un compte sous-traitant ne puisse même pas y accéder.

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

Une autre entreprise avait un système de sauvegarde qui fonctionnait. Les restaurations étaient lentes, mais fonctionnaient. Quelqu’un a remarqué la facture de stockage mensuelle et a décidé « d’optimiser ». Ils ont réduit la fréquence des snapshots, raccourci la rétention, et consolidé les credentials de sauvegarde pour que l’équipe ops puisse « aller plus vite ». Ils ont aussi ouvert des règles de pare-feu pour que le serveur de sauvegarde puisse atteindre tout sans tickets.

Le changement paraissait efficace. Moins de snapshots. Moins de stockage. Moins de friction. Les métriques se sont améliorées. Le risque n’apparaissait pas sur les tableaux de bord, parce que le risque apparaît rarement.

Quand le rançongiciel est arrivé, l’attaquant a trouvé rapidement le serveur de sauvegarde. Il avait une portée réseau large et un credential trop puissant parce que « les sauvegardes ont besoin d’accès ». Ils ont utilisé le même chemin d’admin qu’ops utilisait : supprimer les anciens points de restauration, puis supprimer les récents, puis supprimer les définitions de jobs pour retarder la détection. L’environnement n’a pas seulement perdu des données de production ; il a perdu du temps, parce que personne ne pouvait dire quelles sauvegardes étaient fiables.

La récupération est devenue de l’archéologie. Ils ont dû chasser une vieille copie offsite qui n’était pas complètement synchronisée. Elle a restauré, mais elle était suffisamment ancienne pour provoquer une perturbation sérieuse. L’« optimisation » avait échangé un coût de stockage prévisible contre un coût existentiel imprévisible.

La leçon adoptée fut stricte : traiter les systèmes de sauvegarde comme un territoire hostile. Réduire la commodité. Ajouter de la friction là où cela protège contre la suppression et la falsification. Et ne jamais optimiser la rétention sans avoir d’abord prouvé les besoins de restauration.

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

Celle-ci n’est pas cinématographique. C’est pourquoi ça a marché.

Une entreprise de taille moyenne avait un rituel trimestriel ennuyeux : un test de restauration. Pas un exercice sur table. Une vraie restauration. Ils choisissaient une VM applicative au hasard, la restauraient dans un réseau isolé, vérifiaient que le service remontait, et mesuraient le temps. Ça irritait tout le monde parce que ça consommait du stockage et du travail et produisait un rapport que personne ne lisait jusqu’à ce qu’un problème survienne.

Ils maintenaient aussi un compte admin de sauvegarde séparé, stocké hors-ligne, avec MFA. Le stockage de sauvegarde vivait sur un segment réseau différent. La suppression des snapshots requérait un chemin d’approbation séparé et des credentials différents de ceux du domain admin.

Quand le rançongiciel est arrivé via une boîte mail compromise et s’est propagé à quelques serveurs, les dommages furent réels. Mais il n’a pas pu atteindre le dépôt de sauvegarde. Il n’a pas pu supprimer les snapshots. L’équipe a isolé les hôtes affectés, vérifié les derniers snapshots sains et restauré les systèmes dans un ordre contrôlé. Les runbooks de test de restauration signifiaient qu’il n’y avait pas de débat sur « comment » restaurer—seulement « quoi en premier ».

Ils ont quand même eu une mauvaise semaine, parce que les incidents ça coûte. Mais pas un trimestre catastrophique. La pratique ennuyeuse—la preuve répétée que les restaurations fonctionnent—a transformé la panique en une suite d’étapes.

Erreurs courantes : symptômes → cause racine → correction

Voici la partie où je cesse d’être diplomate. Ce sont des schémas qui reviennent dans de vrais environnements.

1) « Nos sauvegardes étaient bonnes » (jusqu’à ce qu’elles ne le soient plus)

• Symptômes : Les jobs de sauvegarde indiquent « réussi », mais les restaurations échouent ou prennent des jours ; incohérence applicative ; archives corrompues ; personne ne connaît les clés/mots de passe de chiffrement.
• Cause racine : Succès de sauvegarde mesuré par achèvement de job, pas par validation de restauration ; pas d’exercices de restauration ; credentials stockés sur des systèmes compromis.
• Correction : Planifier des tests de restauration avec RTO mesuré ; stocker les credentials admin de sauvegarde hors-ligne ; implémenter l’immuabilité ; documenter l’ordre de restauration par dépendance.

2) Le chiffrement se propage « instantanément » dans l’organisation

• Symptômes : De nombreux partages et serveurs touchés en minutes ; pics de latence stockage ; taux d’écriture SMB en flèche.
• Cause racine : Réseau plat + permissions larges sur les partages + réutilisation des credentials admin + absence de contrôles est-ouest.
• Correction : Segmenter ; restreindre SMB/WinRM ; supprimer la réutilisation des admins locaux ; implémenter un modèle d’admin par niveaux ; limiter les permissions d’écriture sur les partages.

3) L’équipe sécurité ne voit rien pendant l’incident

• Symptômes : SIEM silencieux ; agents hors-ligne ; serveurs de logs chiffrés ; aucune timeline.
• Cause racine : La supervision dépend du même plan d’identité/stockage compromis ; pas de pipeline de logs durci.
• Correction : Centraliser les logs sur une infrastructure durcie ; séparer l’authentification ; utiliser des contrôles d’écriture-une-fois ou de rétention restreinte ; tester la « journalisation pendant une panne ».

4) Les restaurations réinfectent l’environnement

• Symptômes : Les systèmes sont re-chiffrés après restauration ; l’attaquant est toujours présent ; de nouveaux comptes admin réapparaissent.
• Cause racine : Restauration dans un domaine encore compromis ; persistance non supprimée ; credentials non tournés.
• Correction : Contenir d’abord ; tourner les credentials privilégiés ; reconstruire la confiance du domaine avec précaution ; restaurer dans un réseau isolé et valider avant de rattacher.

5) « Nous avions la MFA » mais les attaquants sont passés

• Symptômes : Compromission via SSO ; consentements OAuth suspects ; tokens de session abusés ; helpdesk trompé.
• Cause racine : MFA non appliquée à tous les chemins ; méthodes vulnérables au phishing ; vol de tokens ; procédures helpdesk faibles.
• Correction : Appliquer la MFA partout ; utiliser une MFA résistante au phishing pour les administrateurs ; alerter sur les nouveaux consentements d’applications ; durcir les procédures helpdesk.

6) Les sauvegardes existent mais sont quand même supprimées

• Symptômes : Snapshots manquants ; rétention modifiée ; jobs de sauvegarde supprimés ; buckets d’object storage vidés.
• Cause racine : Les admins de sauvegarde partagent le plan d’identité avec les attaquants ; pas d’immuabilité ; absence de séparation des tâches ; absence d’alerte sur actions destructrices.
• Correction : Mettre en place une rétention immuable ; séparer les credentials ; exiger des comptes break-glass pour suppressions ; alerter immédiatement sur les changements de rétention et suppressions.

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

Checkpoint 0 : Décidez ce que « bon » signifie pour votre entreprise

• Définir le RPO par système (combien de données vous pouvez perdre).
• Définir le RTO par système (combien de temps vous pouvez rester indisponible).
• Classer les données : réglementées, confidentielles, internes, publiques.
• Identifier les 5 services prioritaires à remettre en premier (identité, DNS, applications cœur, partages de fichiers, ERP, etc.).

Semaine 1 : Empêchez les victoires faciles pour les attaquants

1. Appliquer la MFA sur VPN, email et accès privilégiés.
2. Inventorier les comptes privilégiés et séparer comptes admin et comptes quotidiens.
3. Supprimer les bombes à privilèges évidentes : sudo NOPASSWD, credentials admin partagés, comptes de sous-traitants obsolètes.
4. Baseliner l’egress : savoir à quoi ressemble le trafic sortant « normal » depuis les serveurs.

Semaine 2 : Rendre les sauvegardes résilientes face à une compromission admin

1. Implémenter l’immuabilité pour au moins une copie de sauvegarde (snapshots/object lock/rétention type WORM).
2. Segmenter les réseaux de sauvegarde : restreindre l’accès à l’infrastructure de sauvegarde depuis un jump host uniquement.
3. Séparer les credentials : les comptes admin de sauvegarde ne doivent pas être domain admins ; stocker les credentials break-glass hors-ligne.
4. Alerter sur actions destructrices : suppressions de snapshots, changements de rétention, suppressions de jobs.

Semaine 3 : Réduire le rayon d’impact par segmentation et permissions

1. Segmenter l’accès utilisateur→serveur : seuls les ports nécessaires, seuls les sous-réseaux nécessaires.
2. Renforcer les permissions sur les partages : supprimer « Everyone write » ; appliquer le moindre privilège par groupe.
3. Bloquer les protocoles de mouvement latéral quand c’est possible : SMB entre postes de travail, WinRM, WMI entre sous-réseaux.
4. Durcir les workflows admin : PAW ou jump host, pas d’administration directe depuis des postes utilisateurs.

Semaine 4 : Prouvez que vous pouvez récupérer

1. Exécuter un test de restauration dans un réseau isolé ; valider le fonctionnement applicatif, pas seulement le démarrage.
2. Chronométrer et comparer au RTO ; mettre à jour les plans ou acheter de la capacité.
3. Rédiger des runbooks pour l’ordre de restauration et les seuils de décision.
4. Répéter l’heure initiale : containment, rotation des credentials, préservation des snapshots, plan de communication.

Blague #2 (courte, pertinente) : Si votre plan de reprise est un PDF que personne ne trouve, félicitations—vous avez inventé un stockage de documentation compatible rançongiciel.

FAQ

Est-ce que l’antivirus compte du tout ?

Oui. Il réduit les infections de commodité et peut aider à la contention. Mais ce n’est pas un contrôle primaire parce que les opérateurs de rançongiciels utilisent souvent des outils légitimes et des identifiants volés.

Quel est le contrôle le plus important contre les rançongiciels ?

Des sauvegardes que vous pouvez restaurer, protégées par immuabilité et séparation des privilèges. Si les attaquants peuvent supprimer vos sauvegardes, l’incident devient existentiel.

Les sauvegardes immuables suffisent-elles ?

Non. Elles réduisent l’impact du chiffrement, pas le vol de données, la compromission d’identité ou la réinfection. Vous avez encore besoin de durcissement d’identité, de segmentation et de surveillance.

À quelle fréquence devrions-nous tester les restaurations ?

Au minimum trimestriellement pour les systèmes critiques, et après des changements majeurs (nouvel outil de sauvegarde, migration de stockage, changements d’identité). Pour les systèmes de premier plan, un test mensuel n’est pas excessif.

Que devons-nous surveiller pour détecter un rançongiciel tôt ?

Les changements d’identité (nouveaux admins, nouveaux tokens, changements de MFA), les motifs d’écriture SMB inhabituels, les pics de renommage de fichiers, les changements/régressions des rétentions de sauvegarde et les transferts sortants anormaux.

Faut-il payer la rançon ?

C’est une décision métier/juridique, pas uniquement technique, et cela dépend de la juridiction, de l’assurance et de l’impact. Opérationnellement : construisez pour ne pas avoir à payer. Sachez aussi que les outils de déchiffrement peuvent être lents, peu fiables ou incomplets.

Nous sommes principalement SaaS. Sommes-nous en sécurité ?

Non. La compromission d’identité peut chiffrer ou supprimer des données cloud, et les attaquants peuvent abuser des consentements OAuth et des consoles admin. Vous avez toujours besoin de sauvegardes/exports, de journalisation et de contrôles d’identité solides.

Quelle est la différence entre EDR et AV dans ce contexte ?

L’AV est typiquement une prévention basée sur signatures/behaviour sur les endpoints. L’EDR ajoute la télémétrie, le hunting et des actions de réponse (comme isoler un hôte). Les deux aident, aucun ne remplace la résilience des sauvegardes et les contrôles d’identité.

Comment éviter de restaurer des malwares avec les données ?

Restaurez dans un réseau isolé, scannez et validez, tournez les credentials, et assurez-vous que le chemin d’intrusion original est fermé avant de reconnecter. Traitez les restaurations comme une reconstruction contrôlée, pas comme un bouton « revenir en arrière ».

Les snapshots sur le stockage primaire comptent-ils comme des sauvegardes ?

Ce sont des outils de récupération, pas une stratégie de sauvegarde complète. Si l’attaquant compromet le plan admin du stockage, les snapshots peuvent être détruits. Utilisez les snapshots comme une couche, plus des copies séparées de sauvegarde.

Prochaines étapes réalisables cette semaine

Si vous voulez prévenir les rançongiciels, arrêtez de chercher le « meilleur antivirus » et commencez à exécuter un programme de fiabilité pour les résultats de sécurité.

1. Choisissez un service critique et mesurez le temps de restauration de bout en bout. Mettez le chiffre par écrit.
2. Protégez une copie de sauvegarde avec immuabilité et prouvez que les admins de routine ne peuvent pas la supprimer rapidement.
3. Appliquez la MFA pour tous les accès distants, puis auditez les exceptions jusqu’à ce qu’il n’en reste aucune valable.
4. Segmentez les réseaux de sauvegarde et de gestion pour qu’un poste compromis ne puisse même pas les voir.
5. Définissez trois alertes auxquelles vous répondrez réellement : changements de groupes privilégiés, changements de rétention de sauvegarde, et transferts sortants anormaux.
6. Rédigez un runbook d’une page pour la première heure et exécutez-le une fois. L’objectif est d’éliminer le débat, pas d’impressionner qui que ce soit.

Le rançongiciel est un problème systémique. Traitez-le comme de l’ingénierie de production : réduisez le rayon d’impact, appliquez le moindre privilège, concevez pour la récupération et répétez. L’antivirus peut accompagner le trajet.