Quand un site WordPress est infecté, on pense d’abord au contenu, aux fichiers modifiés, aux plugins “gratuits” qui n’auraient jamais dû être installés. C’est normal. Visuellement et techniquement, on se jette sur le désinfection, on remplace des thèmes, on coupe des accès, on scanne.
Mais il y a un angle mort fréquent: la couche DNS. Après une compromission, certains attaquants ne se contentent pas de gagner la main sur WordPress. Ils cherchent à garder une porte arrière même si vous nettoyez le serveur. La configuration DNS devient alors le terrain où l’attaque continue silencieusement, via un changement de résolution, un détournement de sous-domaine, ou un flux vers une infrastructure contrôlée.
Ce qui suit n’est pas une théorie. C’est une façon de raisonner, étape par étape, basée sur ce qu’on voit le plus souvent sur des cas réels, et sur les décisions à prendre quand les signaux sont ambigus.
Pourquoi le DNS mérite votre attention après “supprimer malware WordPress”
WordPress vit souvent derrière un domaine, des sous-domaines, parfois des services tiers: CDN, messagerie, pages de support, intégrations cloud. Le DNS est ce qui relie l’adresse publique à la bonne destination.
Quand un attaquant gagne du terrain, il peut viser plusieurs objectifs:
- prolonger l’accès, sans repasser par le serveur WordPress faire exécuter du contenu malveillant côté navigation, avant même que votre page WordPress soit chargée exploiter la confusion, par exemple en donnant au domaine une résolution différente pour une partie des utilisateurs
Si vous ne vérifiez pas le DNS, vous pouvez “supprimer malware WordPress” sur l’hébergement, restaurer les fichiers, re-signer des clés, changer des mots de passe, puis constater que le problème revient. Parfois immédiatement. Parfois dans quelques minutes ou heures, une fois que la propagation a basculé. Parfois seulement pour certains pays, car l’infrastructure et les résolutions ne sont pas uniformes.
Sur un incident que j’ai vu, le site était propre après restauration, pourtant certains visiteurs tombaient encore sur des pages piégées. Le scan serveur était rassurant. Le coupable se trouvait dans une entrée DNS modifiée pour un sous-domaine de type “www” ou “app”. La charge ne venait pas de WordPress, elle contournait le serveur sain.
Les signes qui pointent vers un problème DNS (pas seulement WordPress)
Avant de toucher au DNS, il faut savoir pourquoi vous le suspectez. Voici les indices typiques, en pratique:
Vous observez du “mix content” ou des redirections vers des domaines inattendus, alors que votre code WordPress semble intact. Le navigateur affiche des redirections bizarres, ou le site charge un script externe inconnu, puis s’effondre.
Vous constatez que les logs WordPress montrent des requêtes limitées, ou au contraire des volumes étranges sur des chemins que vous n’exposez pas. Cela peut indiquer que le trafic passe par une autre destination.
Vous voyez des incohérences entre ce que vous testez en local (avec votre réseau) et ce que d’autres personnes voient sur leurs appareils. Dans le cas DNS, il suffit parfois d’un enregistrement incorrect, ou d’une couche de cache qui n’a pas le même comportement selon les résolveurs.
Enfin, vous recevez des alertes de sécurité orientées “domain” ou “DNS” (rare, mais ça arrive), ou des signalements de phishing qui mentionnent un domaine qui “n’est pas celui que l’on croit”.
Le point clé: si votre infection n’explique pas à elle seule les redirections, ou si la désinfection ne tient pas, le DNS doit entrer dans l’enquête.
Ce que “sécuriser la configuration DNS” veut dire concrètement
Sécuriser le DNS après attaque, ce n’est pas seulement remettre “A” et “CNAME” à leur valeur d’origine. C’est aussi vérifier l’ensemble des contrôles qui déterminent comment un domaine est résolu et géré.
En pratique, on pense à deux familles de paramètres:
1) ceux qui orientent la résolution, donc vers quelle IP, quel service, quel CDN, ou quel load balancer vous renvoyez
2) ceux qui déterminent la gestion du DNS, donc qui peut modifier le domaine, et quelles autorisations sont en placeSouvent, ce sont les deux qui ont été touchés.
Le piège fréquent: des changements “discrets” sur le mauvais sous-domaine
Beaucoup de gens surveillent uniquement le domaine racine. Or, une infection peut cibler “www”, “api”, “login”, “staging”, ou un sous-domaine utilisé par un service tiers (par exemple un point d’entrée pour un portail de connexion).
Il suffit d’un enregistrement “CNAME” qui pointe vers quelque chose d’étrange. Selon la manière dont votre site est configuré, “www” peut être la cible réelle, tandis que la racine renvoie “normalement”. En testant uniquement une URL, vous passez à côté.
L’autre piège: la zone est modifiée mais l’hébergement semble intact
WordPress peut être nettoyé et rester propre, mais si une redirection est faite au niveau DNS (ou via un service fronting), les visiteurs ne passeront pas par votre application comme vous l’imaginez.
Dans certains setups, le DNS est géré par un fournisseur différent (par exemple Cloudflare, Route 53, ou un autre registrar). Une compromission sur le serveur n’entraîne pas forcément une compromission de ces consoles. Mais si l’attaquant a récupéré des identifiants, il peut aussi toucher le DNS.
C’est là que l’histoire de “suppression du malware WordPress” ne suffit plus seule.
Diagnostic: comment vérifier votre DNS sans vous raconter d’histoires
La première règle, c’est de comparer. Avant toute modification, documentez l’état actuel, et surtout l’historique si vous l’avez.
Je recommande une approche simple:
- repérer les enregistrements “qui font sortir” votre domaine vers l’extérieur (A, AAAA, CNAME) vérifier les redirections probables (CNAME vers des hôtes inattendus) examiner les enregistrements qui contrôlent la “fraîcheur” de la résolution (TTL) regarder si l’autorité DNS a changé (noms de serveurs, délégation)
Vous n’avez pas besoin d’un outil complexe. L’objectif est de savoir si, au moment où vous interrogez, vous obtenez quelque chose de cohérent.
Ce que vous cherchez exactement dans les enregistrements
Pour un site WordPress standard, le cœur est souvent constitué des enregistrements liés à “A” ou “AAAA” pour la racine, et à “CNAME” pour “www”. Mais dès que vous avez un CDN, un reverse proxy, ou du multi-environnement, la lecture change.
Le point d’attention majeur après attaque, ce sont les CNAME qui pointent vers un domaine nouvellement enregistré, un sous-domaine étrange, ou une structure que vous n’utilisez pas. Dans les cas concrets, l’attaque laisse souvent des traces: noms de sous-domaines, chaines CNAME, ou un enregistrement qui ressemble à un service tiers mais qui n’est pas le vôtre.
Pensez aussi au TTL. Un TTL très bas peut être normal si vous déployez souvent, mais après une attaque, on voit parfois des TTL ajustés de manière à accélérer la bascule. Si vous observez un TTL inhabituel sur “www” ou sur des entrées que vous ne touchez jamais, c’est un signal.
Enfin, regardez la délégation. Si les “nameservers” ont été modifiés sur le registrar, même sans changer les enregistrements eux-mêmes, vous pouvez vous retrouver à gérer votre DNS ailleurs, avec une zone contrôlée par un tiers.
Étape de sécurisation: remettre le DNS au bon état, puis durcir
Une fois que vous avez la preuve ou un doute raisonnable, l’objectif est double: rétablir et empêcher la récidive.
1) Restaurez les enregistrements “cibles”, pas seulement “l’apparence”
Si “www” pointe vers un CNAME que vous n’utilisez pas, vous devez le corriger avec la destination que vous aviez avant l’incident. Si vous n’avez pas l’historique, il faut reconstruire la cible par cohérence: IP de votre serveur, nom du CDN, nom du load balancer, ou valeur attendue selon votre architecture.
Ne vous contentez pas de “remettre ce qui ressemble à la normale”. Vérifiez que cela correspond à votre réalité actuelle.
Exemple simple: si votre site passe par un CDN, l’enregistrement doit pointer vers le hostname du CDN, pas vers l’IP d’un serveur interne. Si votre architecture a changé récemment, la valeur attendue n’est peut-être pas celle d’un ancien guide.
2) Surveillez la propagation et le comportement multi-étapes
Après correction, la propagation dépend des TTL. Sur certains résolveurs, la bascule peut https://gardewp.fr/ arriver avant d’autres, et votre test peut donner l’impression que “ça marche” puis “ça revient”.
Un moyen de réduire la confusion consiste à vérifier plusieurs résolveurs (par exemple votre opérateur, un résolveur public, et éventuellement un poste sur un autre réseau). Sans faire de liste interminable, l’idée est la même: valider que la résolution est https://gardewp.fr/nettoyage-malware-wordpress/ stable et cohérente.
3) Réduisez la fenêtre pendant laquelle un attaquant peut regagner la main
Avant de “sécuriser le DNS”, je vérifie d’abord qui a la capacité de le modifier.
Deux points reviennent souvent:
- le compte qui gère la zone DNS, souvent lié au registrar ou à une plateforme de DNS la présence de règles d’authentification faible, absence de double facteur, ou accès via des API keys trop permissives
Si vous avez des accès multiples (équipe, prestataire, agence), quelqu’un a peut-être eu accès à la console pendant une période.
Une fois l’incident maîtrisé, la bonne logique consiste à retirer ce qui n’est pas nécessaire, forcer la double authentification et limiter l’accès aux membres qui en ont besoin. C’est souvent plus efficace que de “surveiller avec des scripts” en continu, surtout si les identifiants sont la racine du problème.
4) Durcissez au niveau de la zone quand c’est possible
Selon votre fournisseur, des mécanismes existent pour verrouiller les modifications. Par exemple, des paramètres de “DNS security”, des validations renforcées, ou des verrouillages de zone.
Je reste volontairement prudent ici, car les capacités varient selon les acteurs. Mais la direction est claire: limiter la surface de modification, réduire les permissions, et rendre la modification plus difficile lorsque quelqu’un n’est pas explicitement autorisé.
Couper la dépendance à WordPress: vérifier que l’attaque ne re-vient pas via un autre chemin
Sécuriser le DNS ne remplace pas la désinfection WordPress. Les deux doivent se compléter.
Après “supprimer malware WordPress”, je conseille de traiter l’hébergement comme si l’attaquant avait pu agir sur des points connexes:
- comptes admin, tokens, sessions cron, tâches planifiées fichiers uploads malicieux configuration web server (nginx/apache), règles de redirection plugins et dépendances
Mais dans votre démarche, le DNS est un “autre chemin d’entrée”. Si l’attaquant a changé la résolution, il peut continuer à exposer une page ou un script malveillant même si votre application est saine.
C’est la raison pour laquelle je fais la séquence en deux volets: d’abord, stabiliser la sortie publique (DNS), ensuite, nettoyer l’infrastructure applicative. Si vous nettoyez dans le désordre, vous risquez de poursuivre un fantôme.
Exemple de raisonnement après incident (cas typique)
Imaginez un site “exemple.com” qui semble compromis. Les visiteurs reçoivent parfois une redirection vers un domaine inconnu, et les pages de WordPress affichent des éléments inhabituels.
Vous:
1) supprimez le code malveillant, restaurez le thème, supprimez des plugins inconnus, mettez à jour WordPress et les extensions, changez les mots de passe 2) re-scanez le serveur, vous trouvez un web shell dans un dossier temporaire, vous le supprimez 3) attendez, puis vous testez avec votre navigateur, depuis votre réseau, et vous n’observez plus la redirection
Puis, deux heures après, un collègue sur son mobile signale que le problème revient. Là, vous partez du postulat que le serveur n’est pas le seul point en cause. Vous inspectez le DNS, et vous découvrez que “www.exemple.com” a un CNAME qui pointe vers un hôte de type “cdn-serveur-xxx”. Ce CNAME n’était pas présent avant. Le TTL est bas, ce qui explique les variations selon les résolveurs.
Une fois corrigé, le problème disparaît définitivement, et vous pouvez alors consolider le reste de la réponse d’incident avec des preuves propres, parce que vous savez que le trafic arrive bien à votre infrastructure.
Cette chronologie est fréquente, et elle illustre le rôle du DNS comme “multiplicateur” des effets d’attaque.
Procédure de réponse pragmatique, sans se perdre dans les outils
Je propose une démarche qui tient dans la vraie vie, celle des horaires serrés et des environnements qui changent.
Voici le cœur du processus, formulé en étapes courtes:
Documenter ce que vous avez avant action (valeurs DNS actuelles, captures, vérifications sur plusieurs résolveurs) Corriger les enregistrements incohérents (souvent un CNAME inattendu ou une délégation changée) Verrouiller l’accès aux consoles qui contrôlent le DNS (double facteur, suppression d’API keys non utilisées, réduction des droits) Seulement ensuite, finaliser la désinfection WordPress et vérifier que le site répond correctement depuis une résolution externe stableUne fois cette logique appliquée, vous évitez le piège classique: “tout est clean sur le serveur, donc on a fini”, alors que le public reçoit encore une autre destination.
Détails qui font gagner du temps: TTL, cache et tests utiles
Il y a un sujet qui déclenche beaucoup de frustration: les tests contradictoires.
Le DNS utilise des TTL. Certains résolveurs mettent en cache plus longtemps, et votre correction peut ne pas se refléter partout à la seconde. Ajoutez à cela un éventuel CDN qui a sa propre logique de cache, et une redirection au niveau applicatif, et vous obtenez facilement l’impression que “vous n’y arrivez pas”.
Dans ces cas, je fais un test contrôlé:
- vérifier la résolution via plusieurs résolveurs tester les URL avec et sans “www” vérifier les redirections HTTP (au moins les premières) regarder si les erreurs ne concernent qu’un sous-domaine
Le but n’est pas de tout automatiser. C’est d’éviter de conclure trop tôt.
Sécuriser aussi l’identité qui a accès au DNS (souvent là que se cache le vrai problème)
Le DNS peut changer sans qu’on touche au serveur. Cela signifie que l’attaquant avait un accès à une console. Il peut s’agir d’un mot de passe réutilisé, d’un jeton volé, ou d’un membre de l’équipe qui a été compromis.
Sur le plan pratique, je recommande de traiter les accès comme un inventaire:
- comptes admin du registrar et de la plateforme DNS comptes de membres, agences, prestataires clés API et intégrations permissions dans les consoles
Là où je suis pragmatique: si vous avez une liste d’anciens prestataires encore autorisés, c’est le moment de les sortir. Le coût de retirer un accès est faible comparé à la douleur d’un incident qui revient après un “nettoyage” réussi.
Je garde aussi en tête un détail: certains attaquants restent présents via des mécanismes de persistance sur WordPress, mais d’autres persistent via des modifications DNS. Dans l’un ou l’autre cas, la sécurité d’identité est le garde-fou commun.
Questions fréquentes (et réponses honnêtes)
“J’ai supprimé malware WordPress, pourquoi le trafic redirige encore?”
Parce que le trafic n’arrive peut-être plus chez vous comme vous le croyez. Une entrée DNS, un sous-domaine, ou une délégation modifiée peuvent continuer à orienter les visiteurs vers une destination contrôlée.
“Je ne vois rien d’anormal dans mes enregistrements.”
Il peut y avoir un changement temporaire, ou un comportement qui dépend du résolveur. Dans ce cas, documentez ce que vous voyez maintenant, interrogez plusieurs résolveurs, et examinez les sous-domaines utilisés moins souvent.
“Le problème ne concerne que certains pays.”
Le DNS, les CDN, et certains services peuvent avoir des comportements géographiques. Si votre solution fronting est segmentée, un enregistrement ou un point d’entrée peut varier selon la région.
“J’ai restauré WordPress, mais j’ai peur de re-casser le DNS.”
C’est justement pour cela qu’on documente avant action. Si votre restauration applicative n’impacte pas la zone DNS, vous pouvez séparer les chantiers. La clé est de ne pas improviser dans le DNS sans une base de comparaison.
Ce qu’on peut garder comme repères après l’incident
Quand tout est stable à nouveau, je pense toujours “prévention opérationnelle”, pas seulement “correction technique”.
Je garde en tête trois réflexes:
1) vérifier régulièrement la cohérence des sous-domaines, pas uniquement la racine
2) maintenir une hygiène d’accès stricte sur les consoles qui contrôlent le DNS 3) garder une copie de référence des enregistrements DNS avant modifications majeures (même une simple export ou capture interne)
Les infections WordPress partent souvent de failles applicatives, mais elles finissent parfois dans des changements DNS, car l’attaquant veut garder un levier même quand vous intervenez.
Pour aller plus loin: relier désinfection et sécurité du nom de domaine
Un nom de domaine, ce n’est pas juste une adresse. C’est une dépendance critique. “Supprimer malware WordPress” est indispensable, mais la stabilité publique passe aussi par la couche de résolution.
Une réponse d’incident mature tient les deux bouts: éliminer le code malveillant, corriger les accès, et s’assurer que l’entrée réseau vers votre application est celle que vous contrôlez réellement. Le DNS est la frontière où tout le monde se trompe au début, par manque de visibilité, puis où tout le monde apprend à regarder quand les redirections continuent de hanter les utilisateurs.
Si vous voulez une règle simple à garder en tête après une attaque: dès qu’un comportement utilisateur ne colle pas avec ce que le serveur renvoie, suspectez le DNS. Et dès que vous suspectez le DNS, traitez aussi la cause côté accès, car c’est là que la récidive se gagne ou se perd.