Rançongiciel sur les fichiers du serveur web : restaurer proprement

Ce qu'est un rançongiciel sur un hébergement web

Des fichiers illisibles (extensions étranges, noms chiffrés), parfois une page `README` ou un index remplacé par une demande en bitcoin. Ce n'est pas la même affaire qu'une défiguration « hacked by ». Le guide rançongiciel site web pose le cadre ; ici l'ordre de reprise des fichiers.

Sur un mutualisé, le périmètre est souvent le compte : sites voisins, mails si stockés là, sauvegardes Updraft dans le même arbre. Sur un VPS, ça peut être le disque. VPS compromis. Distinguez tôt : web seulement, ou système.

Parfois seul un dossier est touché (uploads, un vhost). L'inventaire évite de tout jeter. Parfois la page de rançon est un bluff sur un site encore lisible : constatez avant de croire le message.

Ne pas payer, ne pas négocier seul

Le paiement n'assure ni le déchiffrement ni l'absence de fuite (double extorsion). Il ne referme pas l'entrée. Pourquoi ne pas payer. Documentez le message, l'heure, l'adresse indiquée, pour l'assureur et le constat — pas pour discuter.

Un « négociateur » improvisé allonge et expose. Si vous avez une cyber-assurance, ouvrez le dossier selon leur protocole. Déclarer à l'assurance.

Recréer un nom de domaine « pour repartir » perd le SEO et n'empêche pas le même attaquant. Nouveau domaine.

Figer : accès coupés, copie hors du compte

Panel d'abord, puis FTP/SFTP/SSH, admin CMS, clés. Mot de passe panel distinct ensuite. Si la rançon tourne encore, l'attaquant a la main. Mots de passe à changer.

Copiez ce qui est encore copiable vers un disque hors ligne (pas un zip dans le même cPanel). Si le FTP est coupé, demandez l'archive : elle sera l'état au moment T, infection et rançon comprises. Archive sale.

Ne restaurez rien tant que les accès n'ont pas tourné. Restaurer sur un compte encore ouvert, c'est offrir une seconde passe.

• Panel, FTP, SSH, CMS, bases.
• Copie hors serveur, pas « backup » dans uploads.
• Ticket hébergeur factuel, adresse perso si mail coupé.

Inventaire : ce qui est encore lisible

Cœur CMS, médias, `wp-content/uploads`, base (souvent ailleurs, parfois intacte), e-mails. Un inventaire en tableau évite la politique de la terre brûlée. Beaucoup de reprises tiennent sur une base saine + médias partiels + cœur réinstallé propre.

Les fichiers chiffrés se voient (entropie, extension). Les backdoors non chiffrées peuvent rester à côté. Un « restore » qui rapplique aussi le PHP pirate recommence. Comparez.

Site PHP sur mesure : sans zip officiel, l'inventaire est encore plus vital. Site PHP. CMS oublié : SPIP / TYPO3.

Trouver un point propre, pas « la dernière sauvegarde »

La sauvegarde la plus récente est souvent déjà touchée, ou contient déjà la porte. On remonte jusqu'à un point où les fichiers métier s'ouvrent ET où les dates / hashes ne montrent pas l'entrée. Puis on réapplique les contenus légitimes postérieurs (commandes, articles) avec prudence.

Updraft, cPanel, Akeeba, snapshots VPS : ouvrez-les hors prod. Sauvegarde Updraft infectée, restaurer après piratage.

Pas de point propre : reconstruction contrôlée (cœur officiel + contenus exportés). C'est plus long. Ce n'est pas une raison de payer.

Fermer l'entrée avant de rerendre public

Le rançongiciel est entré quelque part : extension, RDP/SSH, panel, voisin, mot de passe. Republier sans ça, c'est le second chiffrement. Revue des comptes, isolation, PHP médias, maj après propreté. Isolation, extensions abandonnées.

Tests visiteurs avant d'annoncer la reprise. Tests.

WAF ensuite, pas comme substitut. WAF.

Hébergeur, tickets d'abus, archive déjà sale

Motif parfois « malware », parfois resource abuse si un process tourne encore. Lisez le ticket. Demandez journaux et archive. Ne demandez pas « rouvrez » tant que l'entrée n'est pas fermée — une réouverture trop tôt recouvre le chiffrement. Guide suspension, compte suspendu.

OVH, o2switch, LWS : même ordre, files différentes. Adresse perso si la messagerie du domaine est dans le compte chiffré. Mail coupé.

Relancer toutes les heures n'accélère pas. Un constat : périmètre, point de restore, entrée fermée.

Données, clients, et ce que le paiement n'achète pas

Chiffrement n'égale pas automatiquement exfiltration, et inversement. Le constat tranche. Fuite. Boutique, santé, dossiers : calibre la communication. Avocat / médecin.

Payer n'achète pas la preuve qu'aucune copie n'existe. Ne communiquez pas « aucune donnée sortie » tant que l'analyse n'est pas close.

Créer un espace : intervention de reprise, pas une négociation de rançon. Choisir un prestataire : fuyez qui propose d'« aider à payer ». Ce n'est pas un critère de « réalisme » ; c'est un critère d'exclusion.

Ne communiquez pas « aucune donnée sortie » tant que l'analyse n'est pas close. Chiffrement ≠ exfiltration, et inversement. Fuite.

Point propre introuvable : reconstruire sans payer

Cœur officiel + médias encore lisibles + base ailleurs intacte : beaucoup de reprises tiennent là. Site PHP sans zip : l'inventaire est encore plus vital, le métier se conserve en retirant les ajouts, pas en réécrivant l'appli le soir J. Site PHP. CMS oublié : copiez avant toute bravoure, même chiffré en partie.

Snapshots VPS du matin : parfois déjà chiffrés. Demandez un antérieur. VPS. Updraft / cPanel « dernière » : souvent déjà porte. Updraft. Archive hébergeur du jour J : preuve, déjà sale. Archive.

Fermez l'entrée avant de rerendre public. Republier sur un panel encore ancien, c'est le second chiffrement. cPanel. Ticket : périmètre, point de restore, entrée, pas « rouvrez ». Guide.