Message de rançon sur un site web : l'ordre utile

L’ordre utile, en une passe

Rancon sur un site internet : parfois un HTML de revendication (les fichiers sont encore là), parfois des extensions `.locked` / `.enc` (chiffrement), parfois les deux plus un mail « on a vos clients ». Les trois ne se traitent pas avec le même interrupteur, mais l’ordre de tête est le même : ne pas payer, isoler les accès, copier ce qui est copiable, qualifier, reprendre un état sain, fermer la porte, documenter.

La précipitation classique : restaurer tout de suite, ou formater, ou négocier sur Telegram. On perd les logs, on paie, on se réinfecte. L’article pourquoi ne pas payer développe le volet argent. Ici, le déroulé technique.

Si le chiffrement est encore en cours (fichiers qui passent à `.enc` sous vos yeux), isolez le compte (stop PHP, permissions, processus) avant la copie longue. Une copie à tiroir ouvert photographie un état à moitié mort, et le payload continue.

• 1. Ne pas payer / ne pas négocier.
• 2. Panel, FTP, SSH, sessions : tout tourner ou couper.
• 3. Copie hors serveur si encore possible.
• 4. Qualifier (message seul vs fichiers chiffrés vs fuite).
• 5. Point propre + entrée fermée.
• 6. Constat écrit.

Ne pas payer, ne pas écrire aux attaquants

Pas de Bitcoin, pas de « on discute pour réduire ». Vous financez la vague suivante, vous n’avez aucune garantie de clé, et vous devenez une cible qui paie. L’assurance cyber refuse souvent le remboursement d’une rançon, ou le conditionne ; lisez le contrat avant tout geste, pas après le virement.

Ne répondez pas sur la page, ni à l’email du note. Chaque message est une donnée de plus (votre adresse, votre niveau de panique). Si un prestataire « négociateur » se présente tout seul, ignorez. Les vrais passent par vous, un avocat, ou l’assureur, pas par un DM.

Documentez la demande (capture, wallet, montant, heure). C’est une preuve, pas le début d’une transaction.

Couper les accès, pas forcément tout le DNS

Mots de passe panel et FTP, clés SSH, sessions CMS, utilisateurs fantômes. Si le payload tourne encore, stoppez PHP ou les crons, ou demandez à l’hébergeur d’isoler le compte. C’est l’exception où une coupure courte se justifie.

Éteindre le DNS tout de suite sans copie : vous perdez parfois le dernier accès au gestionnaire de fichiers. Préférez isolation + archive. Si l’hébergeur a déjà suspendu, vous êtes déjà isolé : passez à l’archive et au motif.

Les partages (agence, stagiaire, All-in-One migration encore branché) : révoquez. Un rançongiciel « site » est souvent un PHP qui a les droits d’écriture du vhost, pas un groupe APT. Moins de comptes, moins de réécriture.

Figer ce qui est encore lisible

Si les fichiers s’ouvrent encore : zip + dump + logs + capture du message, hors serveur. Si une partie est chiffrée : copiez quand même (preuve, parfois fichiers épargnés : `wp-config`, quelques médias). Ne restez pas deux heures à zipper pendant que le script tourne — isolez d’abord.

Les backups sur le même compte sont souvent la première cible. Ne « restaurez pas pour voir » avant d’avoir téléchargé une copie ailleurs. Voir sauvegarder un site déjà piraté.

Inventaire rapide : pourcentage de fichiers illisibles, extensions nouvelles, date de début. Ça oriente restore vs reconstruction.

Évaluer : défacement, chiffrement, exfiltration

Défacement seul : message sur la home, fichiers sains. Traitez comme page défigurée, plus la discipline rançon (ne pas payer, constater). Chiffrement réel : reprise depuis un point propre hors machine, ou reconstruction. Exfiltration alléguée (« on publie vos clients ») : le texte ne prouve pas la fuite. Le constat technique (accès tables, dumps trouvés, logs) décide d’une notification.

Ne prenez pas le note pour argent comptant. « 50 000 clients » sur une vitrine de 200 contacts est un template. Ne communiquez pas ce chiffre.

Boutique : vérifiez le tunnel et les clés paiement indépendamment du message. Un rançongiciel peut cohabiter avec un skimmer, ou n’être qu’un écran.

Restaurer un point propre — pas la nuit dernière

La sauvegarde de 3 h contient souvent le dropper. Remontez avant le plus ancien fichier `.enc` ou avant le premier note. Ouvrez l’archive. Les quatre pièges du restore s’appliquent encore plus ici : restore sale = second chiffrement.

S’il n’y a pas de point propre : cœur officiel + contenus extraits de ce qui reste lisible + médias depuis un backup froid (NAS, prestataire). C’est long. C’est le métier. Payer la rançon n’est pas plus court quand la clé n’arrive pas.

Après restore : secrets tous neufs (l’attaquant a eu les anciens, par définition). Ne réinjectez pas `wp-config` de l’archive chiffrée tel quel sans changer les passwords.

Refermer l’entrée et les relais

Le note ne dit pas comment ils sont entrés. Vous le cherchez : extension, RDP/SSH, panel, voisin, backup public. Sans ça, J+2 un nouveau PHP chiffre à nouveau, ou pose juste une backdoor plus discrète.

Crons, mu-plugins, utilisateurs, clés API, Application Passwords. Autres sites du compte. Messagerie. Un rançongiciel « web » laisse souvent un mailer.

Surveillance 30 jours : dates de fichiers, CPU, nouveaux notes. La garantie utile est cette fenêtre, pas un sticker « sécurisé ».

Preuves, assurance, éventuelle CNIL

Captures du message, wallets, horodatage, copie, logs, ticket hébergeur, liste des mesures. Déclaration sinistre tôt : beaucoup de contrats imposent un délai court. Déclarer à l’assurance.

Plainte : possible, utile pour l’assureur, rarement pour « rattraper » les fichiers. Ne pas attendre la plainte pour restaurer.

CNIL : seulement si des données personnelles ont pu être lues ou exfiltrées, selon le constat — pas parce qu’un note l’affirme. La déclaration, si due, vous incombe. Nous fournissons l’analyse, pas le formulaire à votre place.