Rançongiciel sur serveur de fichiers : confiner, restaurer, déclarer

Ordre retenu : confiner → préserver → évaluer → éradiquer → restaurer.

1. Isoler le serveur de fichiers du réseau (désactivation du port switch ou passage en VLAN de quarantaine) sans l'éteindre brutalement : la mémoire vive contient des artefacts utiles à l'analyse. Objectif : stopper la propagation latérale par SMB.
2. Isoler le poste de l'assistante et le compte compromis : désactivation du compte, révocation des sessions et des jetons, réinitialisation du mot de passe, recherche d'autres machines touchées via la console EDR. Un rançongiciel utilise souvent plusieurs comptes en quelques minutes.
3. Protéger les sauvegardes : déconnecter le NAS du réseau ou le passer en lecture seule, changer les identifiants, vérifier qu'il n'est pas déjà chiffré. Le compte « backup » étant administrateur du domaine, il est une cible directe.
4. Préserver les preuves : ne pas supprimer la note de rançon, photographier l'écran, consigner les horodatages, conserver les journaux (EDR, journaux Windows, Veeam).
5. Alerter et activer la cellule de crise : direction, assureur cyber, prestataire, dépôt de plainte, signalement sur cybermalveillance.gouv.fr. Décider qui parle, à qui, et avec quel message.

Pourquoi restaurer tout de suite serait une faute

• L'attaquant est peut-être encore présent (persistance, compte de service, tâche planifiée) : restaurer avant l'éradication revient à remettre les données dans un environnement compromis, qui les rechiffrera.
• Une restauration écrase l'état de la production et détruit des preuves nécessaires à l'analyse et à la déclaration.
• On ne sait pas encore si des données ont été exfiltrées : restaurer ne répond pas à cette question, or c'est elle qui déclenche les obligations RGPD.
• Restaurer 900 Go prendra de toute façon plusieurs heures : l'utiliser comme première action ne fait pas gagner le RTO de 8 h, alors que le confinement, lui, est immédiat.

La restauration est l'avant-dernière étape, pas la première.

Constats

• 3-2-1 non respecté : on a deux copies (production et NAS) mais un seul support de sauvegarde, dans la même salle, sur le même réseau, avec un compte sauvegarde administrateur du domaine. Un rançongiciel qui obtient ce compte chiffre production et sauvegarde : c'est le scénario le plus fréquent, et il est ici presque certain.
• Pas d'immutabilité : rien n'empêche Veeam d'écraser les points de restauration. Les 4 semaines de conservation ne protègent pas si l'attaquant supprime le dépôt.
• RPO non tenu : le contrat promet 4 h, or les incrémentales sont quotidiennes. Entre deux sauvegardes il peut s'écouler jusqu'à 24 h : la perte de données réelle peut atteindre une journée entière de saisie, soit six fois le RPO contractuel. Sur un cabinet comptable en pleine période fiscale, cela peut représenter des centaines de pièces justificatives.
• Aucune mention de test de restauration : une sauvegarde non testée n'est pas une sauvegarde.

Corrections, par ordre d'efficacité contre le rançongiciel

1. Copie hors ligne / air gap ou dépôt immuable (stockage à objet avec verrouillage, dépôt Veeam durci, bande débranchée) : c'est la mesure qui traite directement le scénario, car une copie immuable ne peut être ni chiffrée ni supprimée avec les identifiants volés.
2. Compte de sauvegarde dédié, non administrateur du domaine, avec authentification multifacteur sur la console Veeam et droits limités au strict nécessaire.
3. Fréquence alignée sur le RPO 4 h : snapshots ou incrémentales toutes les 4 heures, avec rétention adaptée.
4. Test de restauration documenté au moins trimestriel, avec chronomètre : c'est le seul moyen de prouver que le RTO de 8 h est tenable pour 900 Go.
5. Copie hors site pour couvrir aussi l'incendie et le vol, pas seulement le rançongiciel.

La priorité est l'immuabilité et la séparation des identifiants : sans elles, les autres mesures n'améliorent que marginalement la résilience.

Qualification Le cabinet est responsable de traitement ; le chiffrement de données personnelles (identité, rémunération, éventuellement coordonnées bancaires) constitue une violation de données à caractère personnel au sens de l'article 4 du RGPD, qu'une exfiltration soit confirmée ou non. Le simple doute impose de traiter le sujet.

Obligations et délais

• Registre des violations : documenter l'incident (nature, données concernées, nombre de personnes, conséquences probables, mesures prises) dès la connaissance du fait.
• Notification à la CNIL sous 72 h si la violation est susceptible d'engendrer un risque pour les droits et libertés. Ici, des fiches de paie de 40 salariés rendues indisponibles ou potentiellement exfiltrées : le risque est réel, la notification est à faire. Si l'analyse n'est pas terminée à 72 h, on notifie de façon graduée et on complète ensuite.
• Information des personnes concernées si le risque est élevé (article 34) : message clair sur la nature de l'incident, les conséquences, les précautions à prendre (surveillance des prélèvements, tentative de phishing ciblé).
• Information du ou des sous-traitants éventuels (hébergeur, prestataire de sauvegarde), qui doivent eux-mêmes notifier sans délai ; vérifier les clauses du contrat.

Faut-il payer ? Non. La recommandation publique (ANSSI, CNIL, Cybermalveillance) est de ne pas payer : le paiement finance l'activité criminelle, ne garantit pas la restitution des données et fait de la victime une cible rémunératrice pour la suite. La voie retenue est la restauration depuis une sauvegarde saine après éradication, avec acceptation documentée d'une perte de données limitée.

En parallèle : dépôt de plainte, contact avec l'assureur cyber, et revue des causes (absence de MFA sur la messagerie, ouverture d'un ZIP, compte de sauvegarde trop privilégié) pour la fiche de retour d'expérience.