Piraté/inséré avec un code malveillant/redirigé : liste de contrôle pour la quarantaine et la récupération en toute sécurité

Lorsque le site Web est piraté/inséré avec un code malveillant/une redirection étrange, l'objectif numéro 1 n'est pas de "le rendre beau immédiatement" mais de isoler - collecter des preuves - restaurer en toute sécurité puis renforcer pour éviter une réinfection. Vous trouverez ci-dessous un véritable playbook de combat que vous pouvez appliquer immédiatement, par ordre de priorité P1 → P2 → P3.

Si vous avez besoin d'un framework de sauvetage avec SLA P1 ≤ 2–4h avec une personne responsable clairement identifiée, vous pouvez vous référer au service de maintenance du site Web d'Ho Chi Minh (playbook de dépannage, de récupération et de renforcement) : Service de maintenance du site Web d'Ho Chi Minh.

1) Identification rapide (5 à 10 minutes)

Signes courants

• Redirection automatiquement vers des pages inconnues (en particulier lors d'un accès depuis Google/di dynamique).

• Interface inhabituelle cassé, étrange popup/iframe intégré, lien japonais/pharmaceutique inséré.

• Le serveur CPU/IO augmente soudainement, l'e-mail/l'hébergement signale un malware.

• Google Search Console signale des Problèmes de sécurité (Malware/Contenu trompeur), la navigation sécurisée avertit « Site Web nuisible ».

• Le journal enregistre de nombreux 404/5xx inhabituels, connectez-vous bruteforce.

Déterminez la portée

• Site entier ou partie (blog, /wp-content/uploads, thème/plugin) ?

• Uniquement les clients Google/mobile ou tous ?

• Est-il également affecté par la production ou la mise en scène ?

2) P1 – Isoler et préserver les preuves (0 à 60 minutes)

Objectif : prévenir la propagation, préserver le statu quo pour l'enquête et la récupération phục lưu thông an toàn.

1. Vous pouvez obtenir un mot de passe pour le serveur/ngăn truy cập IP (nếu có thể).

2. La Maintenance 503 doit être configurée pour la page de maintenance (302/301).

3. Si WordPress : définissez la Page de maintenance statique (ne pas exécuter de dynamique PHP).

2. Sauvegardez les analyses avant de toucher

• Instantané de l'intégralité du code source + base de données + journaux (web, PHP-FPM, WAF/CDN) pour contrôler la vérification plus tard.

• Enregistrer la copie hors site (hors site).

3. Changer la clé et invalider la session

• Changer le mot de passe (hébergement/SSH/DB/CMS/FTP), sur 2FA.

• Révoquer le token API (CDN, paiement, SMTP), invalider les sessions (toutes se déconnecter).

4. Isoler les processus étranges

• Arrêtez temporairement le cron suspect, tuez le processus PHP/commande étrange, verrouillez temporairement l'écriture dans un répertoire facilement inséré (par ex. /uploads).

Pendant la phase P1, l'objectif est de arrêter le saignement. Ne vous précipitez pas pour "nettoyer" si vous n'avez pas de copie pour servir l'enquête.

3) P2 - Enquêter sur la cause et nettoyer (2 à 6 heures)

3.1 Déterminer le point d'entrée (vecteur d'attaque)

• Compte administrateur unique, tentative de connexion depuis un étranger IP ?

• Plugin/thème vient d'être mis à jour. Mis à jour ou téléchargé à partir d'une source peu fiable ?

• Le téléchargement de PHP dans /uploads, /temp ou .htaccess est corrompu ?

• Injection de base de données : contenu étrange dans wp_options, siteurl/home, post méta, menu.

3.2 Vérification des signatures de code malveillant (IOC – Indicators of Compromise)

• Modèles PHP courants : eval(base64_decode(...)), gzinflate, str_rot13, preg_replace('/e', ...), assert($_POST...).

• Fichiers suspects : faux wp-*.php dans /wp-includes/, nom de fichier aléatoire .ico/.jpg mais contient PHP, cron/backdoor dans /wp-content/mu-plugins/ ou /wp-content/sessions/.

• .htaccess ajouter une règle de redirection en fonction de l'agent utilisateur/référent (redirection uniquement en provenance de Google/mobile).

3.3 Nettoyer en toute sécurité

1. Geler les autorisations d'écriture (seul le technicien dispose des autorisations d'écriture autorisation).

2. Remplacer le noyau (noyau WP, noyau CMS) de la source principale

3. Supprimer les plugins/thèmes inutilisés ou suspects.

4. Installer proprement les plugins/thèmes restants (télécharger la version originale).

5. Analyser et supprimer :

   • Analyser au niveau du fichier : trouver des échantillons de code malveillant, comparer la somme de contrôle avec la version propre.

   • Analyser au niveau de la base de données : trouver des scripts étranges dans options/posts/meta/terms.

6. Supprimer le webshell/la porte dérobée (PHP caché fichiers, extensions de fichiers étranges).

7. Nettoyer la configuration .htaccess/nginx (supprimer les règles de redirection étranges, conserver les réécritures de base). version).

8. Régénérer les sels, les clés (WP AUTH_KEY, SECURE_AUTH_KEY…), changer tous les mots de passe.

3.4 Vérifier la redirection « intelligente »

• Accès depuis Google/mobile (en utilisant un autre UA) pour détecter les règles selon UA/Referrer.

• Faire correspondre les journaux avant et après le nettoyage, garantir la norme HTTP 200 pour les URL des pages d'argent.

4) P3 – Restauration du service et nettoyage du référencement (jours 1 à 3)

4.1 Ouvrir l'accès contrôlé

• Décharger la maintenance/503, activer le site partiellement si nécessaire.

• Gardez WAF/CDN en mode « strict » pendant les premières 48 à 72 heures (bloque les modèles d'attaque).

4.2 Restaurer les signaux SEO

• Dans Google Search Console, ouvrez Problèmes de sécurité et Demander un examen après le nettoyage up (brève description « code malveillant supprimé, noyau/plug-in remplacé, clés modifiées, WAF activé »).

• Supprimer l'URL indésirable (si le pirate informatique crée de nombreuses pages de spam) via l'outil de suppression ou un 410/301 raisonnable.

• Renvoyer le Plan du site propre ; vérifiez la Couverture (404/Soft 404/Alternate canonique).

• Recomparez robots.txt (assurez-vous de ne pas bloquer accidentellement après la quarantaine).

4.3 Surveillez de près 7 à 14 jours

• Graphique 5xx/CPU/IO, échec du numéro de connexion, trafic dans des pays étranges.

• Core Web Vitals (évitez les logiciels malveillants qui extraient des scripts lourds), CTR/Impressions dans GSC.

Pour les sites avec des transactions, vérifiez le webhook de paiement, testez le paiement (sandbox/vrai petit) pour vous assurer que le cycle de commande n'est pas modifié. changement.

5) Renforcement pour empêcher la réinfection (semaine 1)

Couche d'infrastructure

• WAF/CDN (Cloudflare/…) : activer Bot Fight, bloquer les pays attaquants, limite de débit /wp-login.php, /xmlrpc.php, appliquer Défi du chemin sensible.

• Activer TLS 1.2+, HSTS, HTTP/2/3.

Couche d'application

• Mise à jour du processus : préparation → test → production, oui rollback.

• Désinstallation du plugin/thème annulé ; Minimisez le nombre de plugins.

• Désactivez la modification des fichiers dans le tableau de bord (WP DISALLOW_FILE_EDIT).

• Décentralisez le moindre privilège pour FTP/DB/CMS ; comptes CI/CD séparés.

• Désactivez/limitez XML-RPC, activez 2FA pour l'administrateur, modifiez l'URL de connexion (le cas échéant).

Couche de configuration de sécurité

• Content-Security-Policy (CSP) : domaine de liste blanche script/img/font.

• Options X-Frame / Politique d'autorisations / Politique de référence.

(mise à jour, nettoyage 404/301, recherche de logiciels malveillants, CWV, journaux).

• Formez l'équipe de contenu sur le phishing, les règles de téléchargement de médias/scripts.

Si vous avez besoin d'une feuille de route de maintenance mensuelle (liste de contrôle mise à jour, nettoyage des erreurs récurrentes, audit rapide/référencement technique) pour maintenir un site Web propre et stable, voir le processus mensuel de maintenance du site Web construit par l'équipe Tan Phat Digital : Services de maintenance Web.

6) Communication et juridique (à ne pas manquer) oublier)

• Notification transparente aux utilisateurs (le niveau dépend des données concernées).

• Forcer le changement de mot de passe pour les groupes d'utilisateurs à risque ; invalider l'ancien jeton de connexion.

• Si cela est lié au paiement/PCI/PII, à la consultation juridique et à la conformité aux rapports réglementaires.

7) Foire aux questions (FAQ)

Piraté par « Japonais/Pharma », le nettoyage des fichiers est suffisant ?
Habituellement pas. Ce formulaire est souvent insérer une base de données (méta, options, menu). Vous devez analyser le fichier + la base de données, modifier le .htaccess, régénérer les clés, puis activer le WAF.

Dois-je restaurer la sauvegarde et terminer ?
La restauration permet de un point de départ propre, mais si le vecteur d'attaque n'est pas couvert (plugin défectueux, fuite de clé), le site est facile à utiliser. réinfecter. Toujours durcissement après la restauration.

Combien de temps faut-il à Google pour supprimer l'avertissement "Site Web nuisible" ?
Habituellement 24 à 72 h après la Demande d'examen et c'est vraiment propre.

Redirection uniquement lors de l'accès depuis Google/mobile, sans accès direct → est-ce un piratage ?
Très probable. Les attaquants se cachent souvent en utilisant la condition UA/Referrer ; Veuillez vérifier .htaccess, insérer le script et les journaux.

8) Liste de contrôle récapitulative (imprimez-la et collez-la sur le mur)

P1 – Quarantaine

• Activez 503/maintenance, bloquez temporairement le public

• Instantané code + DB + journaux (hors site)

formel

• Analyser et supprimer webshell/backdoor, nettoyer .htaccess/nginx

• Analyser la DB (options/posts/méta), modifier siteurl/home

• Régénérer les sels/clés, changer tous les mots de passe mot de passe

P3 – Récupération et référencement

• Ouvrir le site, activer WAF/CDN au niveau strict

• Demander un examen dans GSC, soumettre un plan du site propre

• Supprimer/410 URL indésirable, vérifier robots/couverture

Durcissement

• CSP, HSTS, en-têtes de sécurité, 2FA, moindre privilège

• Planification de mise à jour avec préparation, sauvegarde 3-2-1, test restauration

• Disponibilité du moniteur/5xx, analyse d'intégrité, audit journal