Comment prévenir son hébergeur qu'un site est piraté
Annoncez qu’une intervention est en cours et demandez les journaux, pas la réouverture immédiate. Un ticket factuel — référence, ce que vous voyez, que vous ne rouvrez pas à la main — évite souvent une suspension automatique au moment où vous avez le plus besoin du FTP.
Annoncez qu'une intervention est en cours et demandez les journaux, pas la réouverture immédiate. Un ticket factuel évite une suspension automatique.
Pourquoi écrire maintenant, pas « une fois propre »
Prévenir son hébergeur qu’un site est piraté n’est pas une aveu qui « fait fermer le compte ». C’est souvent l’inverse : les suspensions automatiques partent d’un scan interne ou d’un rapport d’un tiers, sans que vous soyez dans la boucle. Un ticket ouvert (« intervention en cours, ne pas wipe, besoin des logs ») pose un drapeau humain sur le dossier.
Sans ticket, le robot d’abus voit encore le fichier demain matin et coupe le FTP pendant que vous comparez les thèmes. Avec ticket, vous avez une référence à citer, et parfois un délai de quelques heures. Ce n’est pas garanti. C’est mieux que le silence.
Vous n’attendez pas d’avoir « tout nettoyé » pour écrire. Le nettoyage peut prendre un jour ; la rétention des logs, 24 heures. L’email d’aujourd’hui sauve des fichiers que celui de mercredi ne retrouvera plus. L’ordre reste : copie, panel, puis ce ticket. Voir premiers gestes.
- Annoncer l’intervention (pas « c’est grave aidez-moi »).
- Demander logs + chemin déjà signalé s’il existe.
- Donner une adresse de secours hors domaine.
- Ne pas demander « rouvrez » si le site l’est encore.
Ce que vous demandez vraiment
Trois choses utiles : les journaux (accès, erreurs PHP, FTP, mail) sur 7 jours si possible ; le chemin exact déjà flaggé par leur antivirus ; une archive si le FTP est instable. Une chose inutile à ce stade : « remettez le site, nos clients attendent ». Le service abus n’est pas le service commercial. Il lève une suspension quand la cause a disparu, pas quand le chiffre d’affaires souffre.
Demandez aussi s’il s’agit d’un signalement interne (scan Imunify, ClamAV, leur WAF) ou d’un tiers (Google, PhishTank, un autre hébergeur). Le traitement n’est pas le même. Un chemin nommé (`public_html/wp-core.php`) oriente en dix minutes. Un « malware detected » sans chemin oriente vers une pêche au PHP à la racine.
N’exigez pas qu’ils « nettoient pour vous » dans le premier message. La plupart ne le font pas, ou le font au Kärcher (permissions 000, fichiers mis en .suspect). Vous voulez les pièces, pas une surprise dans le tree.
Le message factuel (et ce qu’il ne contient pas)
Sujet : nom de domaine + « intervention malware en cours » + référence d’abus si vous l’avez. Corps : qui vous êtes (titulaire, code client), ce qui est visible (redirection mobile, email de scan, URL), ce que vous avez déjà fait (copie, mot de passe panel), ce que vous demandez (logs, chemin, archive). Dates et heures, fuseau.
N’y mettez pas : un roman sur l’agence, des accusations, « on va changer d’hébergeur », des captures illisibles de 50 Ko, un « c’est urgent » répété. N’y mettez pas non plus un mot de passe. Si vous devez partager un accès, un compte FTP lecture seule temporaire, révocable, annoncé comme tel.
Modèle court : « Compte X, domaine exemple.fr. Redirection constatée sur iPhone depuis les résultats Google le 27/08 14:12. Mot de passe panel changé à 14:30. Merci de nous transmettre access/error des 7 jours et tout chemin déjà signalé. Copie en cours. Nous ne demandons pas de réouverture. Contact hors domaine : moi@gmail.com ».
Motif d’abus : malware, phishing, resource abuse
Malware / virus : fichier servi ou déposé. Vous traiterez chemins et signatures. Phishing : page qui imite une banque ou un login. Priorité à l’URL en 200, souvent motif de suspension le plus rapide. Resource abuse / CPU : minage ou générateur de pages — prévenez avant que le voisin de serveur se plaigne, voir site lent, minage.
Spam mail : ce n’est pas le même bureau, parfois. Le site peut être propre et la boîte relais ouverte. Donnez le journal d’envoi, pas seulement « on a Wordfence ».
Si le motif est faux (certificat, quota, fausse alerte Imunify sur un cache), restez factuel : « le chemin cité est tel plugin, voici le hash officiel ». Se battre sur le ton n’accélère pas. Fournir le hash et le lien du zip WordPress, parfois si.
Si la messagerie du domaine est déjà coupée
C’est le piège le plus fréquent des suspensions OVH, LWS, mutualisé générique. Vous ouvrez le ticket depuis `contact@votre-domaine.fr`, la réponse part vers cette boîte, vous ne la voyez jamais, vous relancez, on vous accuse de ne pas répondre.
Indiquez une adresse personnelle dès le premier message, et dans la fiche client du manager si le champ existe. Relancez une fois : « merci de répondre sur gmail, la MX du domaine est hors ligne ». Pas cinq tickets parallèles.
Gardez les numéros de ticket. Ils iront dans le constat d’assurance et dans la réponse au prochain abus.
Ce qui déclenche une suspension pendant que vous travaillez
Laisser le phishing en 200 « le temps de copier ». Recréer le fichier en restaurant la dernière Updraft. Envoyer un mailing de masse « notre site a un problème » depuis le SMTP local déjà blacklisté. Scanner le site avec vingt outils en ligne qui le hitent comme un botnet.
Rouvrir à la main un vhost que l’hébergeur a fermé (changer de dossier, de sous-domaine, de PHP) est lu comme une contournement. Ça convertit un malware ticket en clôture de compte. Travaillez sur l’archive, demandez un accès lecture si besoin.
Un ticket « je migre chez le concurrent ce soir » n’aide pas le tech de 22 h à vous laisser le FTP. Gardez la migration pour après, documentée. Voir migrer encore infecté.
Relancer : utile ou nuisible
Utile : une fois, J+1, avec une pièce nouvelle (chemin trouvé, constat, logs de votre côté). Nuisible : toutes les heures, plusieurs canaux (chat + ticket + Twitter), majuscules. Les files abus sont des queues. Relancer sans matière vous remet parfois au bout.
Si le site n’est pas encore suspendu, une relance « toujours en cours, voici ce qui a été retiré » calme parfois le scan interne. Si déjà suspendu, la relance sans constat n’ouvre rien. Passez sur le modèle répondre à un ticket d’abus.
Téléphoner au standard grand public ne débloque pas Imunify. Demandez le service abuse / sécurité, avec le numéro de ticket. Préparez le code client. Un appel sans référence = on vous dit d’écrire.
Après leur réponse : journaux en main
Téléchargez tout de suite. Les liens d’archives expirent. Classez : `logs/`, `abus-ref.txt`, chemins cités. Croisez avec les dates de fichiers. Le premier hit vers `wp-core.php` est souvent plus parlant que le scan Wordfence.
Répondez que vous avez bien reçu, une ligne. Quand le nettoyage est réel, un second message : trouvé, retiré, corrigé (entrée). Pas « c’est bon ». Le détail est dans le guide compte suspendu.
Si on ne vous donne ni logs ni chemin, vous n’êtes pas bloqué : copie, dates, `site:`, inspection Search Console. L’hébergeur est une source, pas la seule. Vous pouvez ouvrir un dossier en parallèle ; le ticket reste utile dans tous les cas.