L'hébergeur fournit une archive : elle est déjà infectée
L'archive que l'hébergeur envoie après une suspension est déjà infectée. C'est normal : c'est l'état du compte. Traitez-la comme une preuve et un filet, pas comme une source de restauration. La remettre telle quelle replace le site à l'heure du ticket, infection comprise. Ouvrez-la hors production, comparez, republiez uniquement ce qui a été trié — jamais le bouton « restore » vers le même document root.
C'est normal : c'est l'état du compte. Traitez-la comme une preuve, pas comme une source de restauration. Restaurer cette archive telle quelle remet le site à l'heure de la suspension.
Pourquoi cette archive est sale — et précieuse
L'hébergeur zipe ce qu'il a au moment T : fichiers, parfois bases, parfois logs. Le malware y est. Les preuves aussi (dates, shells, pages de phishing). Sans elle, vous n'avez plus rien si le FTP reste coupé. Avec elle mal utilisée, vous republiez le malware.
OVH, o2switch, LWS, IONOS : même objet, autre nom (backup, dump, snapshot). OVH, o2switch.
Cadre : compte suspendu, guide. Notez la date de réception du zip : une archive « perdue dans les mails » n'existe plus pour l'assureur.
Ce qu'on y cherche (sans tout extraire en prod)
Ouvrez-la sur une machine hors production (PC local, VPS jetable). Listez les PHP isolés, dates, `wp-config`, cron si inclus. Ne l'explosez pas dans `public_html` « pour que le site revienne ».
Base SQL dans le zip : ouvrez-la hors ligne. Admins fantômes, options JS. N'importez pas dans la prod encore ouverte.
On ne donne pas de signatures d'exploit. On compare à un zip officiel de CMS ensuite, sur une copie de travail.
Ne pas restaurer « pour voir » sur le compte
Le bouton « restore » du panel vers le même document root est le geste qui remet le ticket d'abus à zéro. Travaillez sur une copie. Republiez uniquement des fichiers comparés / un point propre antérieur.
Restaurer une sauvegarde. Sauvegarde Updraft.
Cloudflare / cache : même si vous restorez sale, le cache resservira sale. Cloudflare.
S'en servir comme point de comparaison
L'archive T0 + un zip WordPress / Joomla / Drupal officiel = diff. Le métier (uploads, thème enfant) se trie. Site PHP : l'archive EST le référentiel, on retire les ajouts. Site PHP.
Chronologie pour l'assureur et le constat. Preuves.
Gardez l'archive hors ligne après le dossier (quelques semaines), pas en HTTP dans un dossier `backup`.
Sauvegardes panel, Updraft, snapshots : même piège
La « dernière » est la plus pratique et la plus souvent déjà porteuse. On remonte. Un snapshot VPS du matin de la rançon est déjà chiffré. Rançongiciel. VPS.
Swiss Backup / NAS : vérifier qu'ils n'étaient pas en sync écriture. Infomaniak.
Pas de point propre : reconstruction cœur officiel + contenus exportés. Plus long. Moins cher qu'une réinfection hebdomadaire.
Rançon et archive : deux copies, un hors-ligne
Si le compte se chiffre encore, l'archive demandée maintenant peut être déjà illisible. Demandez aussi un snapshot antérieur. Ne payez pas pour « déchiffrer l'archive ». Pourquoi ne pas payer.
Stockez la copie reçue hors du compte (disque, autre cloud). Un zip dans le même cPanel part avec le reste.
Isolation : l'archive du COMPTE contient les voisins. Inspectez-les. Isolation.
Ce que vous écrivez dans le ticket ensuite
« Archive reçue le …, traitée hors ligne, cause X retirée, entrée Y fermée, nous ne restaurons pas l'archive brute. » Référence d'abus. Répondre à un abus.
Si l'archive manquait de logs, demandez-les séparément. Logs.
Adresse perso. Mail coupé.
Quand l'archive est illisible ou incomplète
Zip corrompu, sans base, sans le bon vhost : relancez une fois, factuel. Gardez la preuve de ce qui manquait. C'est un motif de changement d'hébergeur — après avoir tout tenté par écrit.
Trop lourde à télécharger : lien temporaire, découpage, SSH (alwaysdata, Gandi). alwaysdata.
Créer un compte : on traite souvent à partir de ces archives, sans les remettre en ligne telles quelles. C'est précisément le métier : lire un zip sale, en extraire un site tenable.
Un zip trop gros pour la boîte mail : lien temporaire de l'hébergeur, découpage, SFTP. Notez la date de réception dans le constat. Une archive « perdue dans les allers-retours » n'existe plus pour l'assureur.
Travailler hors prod sans se perdre
Machine locale ou VPS jetable, pas le `public_html` encore ouvert. Extraire, lister les PHP isolés, comparer le cœur au zip officiel, noter les dates. Le métier (uploads, thème enfant, `app/`) se trie ensuite. On ne « lance pas le site » sur cette copie pour voir : on ouvre des fichiers. Un WAMP public sur votre box n'est pas hors prod s'il est joignable.
Base SQL : import local, liste des users, options de scripts. N'importez pas dans la base encore attachée au panel compromis. Secrets neufs au moment de republier, pas les mots de passe du dump. Mots de passe.
Plusieurs vhosts dans l'archive : c'est tout le compte. Isolation. Le mail d'abus n'en citait qu'un. Traitez la liste. Puis seulement un ticket « archive traitée hors ligne, cause fermée, nous ne restorons pas le zip brut ». Guide.