Un site WordPress piraté n’est pas toujours un incident isolé.

Dans ce cas client, le premier symptôme visible était relativement classique : des erreurs 503 intermittentes et plusieurs sites devenus instables. Mais l’analyse a rapidement montré que le problème allait beaucoup plus loin.

Trois sites WordPress partageaient le même environnement d’hébergement. L’un d’eux, ancien et désormais abandonné, était fortement compromis. Plusieurs portes dérobées permettaient encore l’exécution de commandes à distance, et des traces montraient que l’attaquant avait également ciblé les deux autres sites.

Le problème n’était donc pas seulement de supprimer quelques fichiers suspects. Il fallait comprendre la chronologie de l’attaque, identifier les mécanismes de persistance, déterminer comment l’infection avait pu circuler entre les sites, puis préparer une remise en production sur des environnements réellement séparés.

Le point de départ : des erreurs 503 qui cachaient un problème plus large

La demande initiale concernait notamment des erreurs HTTP 503 apparaissant de manière intermittente.

Une erreur 503 signifie que le serveur n’est temporairement pas en mesure de traiter une requête. Sur WordPress, cela peut venir de plusieurs causes : ressources insuffisantes, saturation de PHP, requêtes trop longues, mécanisme de sécurité trop restrictif ou encore comportement anormal provoqué par une infection.

L’analyse des journaux PHP-FPM a confirmé une saturation régulière du pool PHP :

[pool www] server reached max_children setting (8)

Autrement dit, les huit processus PHP disponibles étaient régulièrement tous occupés.

Certaines requêtes WordPress restaient également actives pendant plusieurs minutes, avec des exécutions dépassant parfois largement les durées normales.

Mais augmenter simplement les ressources ou le nombre de workers PHP aurait été une mauvaise réponse au problème.

Car en poursuivant l’analyse, nous avons découvert que les trois sites étaient compromis.

Trois sites, un même environnement technique

Les trois WordPress étaient hébergés sous le même compte système.

C’est un point important : même si les sites disposent de domaines et d’installations WordPress distinctes, ils n’étaient pas réellement isolés au niveau du serveur.

Une fois qu’un attaquant parvient à exécuter du PHP sur l’un des sites, il peut potentiellement accéder aux fichiers des autres sites appartenant au même utilisateur système.

Et c’est précisément ce que nous avons observé.

L’un des sites, aujourd’hui abandonné, contenait plusieurs webshells récentes et anciennes. Une requête enregistrée dans les logs montrait qu’une de ces portes dérobées avait été utilisée en ciblant explicitement le répertoire d’un deuxième site présent sur le même hébergement.

Ce site abandonné est donc apparu comme le principal vecteur identifié de propagation de l’infection.

Des portes dérobées installées depuis plusieurs mois

L’analyse statique des fichiers a permis de reconstituer une chronologie remontant sur plusieurs mois.

Nous avons notamment retrouvé :

• plusieurs webshells PHP permettant d’exécuter des commandes système ;
• des gestionnaires de fichiers permettant d’uploader, modifier ou supprimer des fichiers ;
• des loaders capables de télécharger et exécuter du code depuis Internet ;
• une porte dérobée capable de générer directement une session administrateur WordPress sans connaître le mot de passe ;
• des fichiers PHP fortement obfusqués ;
• des plugins légitimes détournés et utilisés comme camouflage ;
• des règles .htaccess spécialement conçues pour conserver l’accès à certains fichiers malveillants.

Certaines webshells appartenaient à des familles connues comme Gecko, Maw3six ou 403Webshell.

Un des scripts recherchait automatiquement wp-load.php, chargeait WordPress, récupérait un compte administrateur existant puis générait directement un cookie d’authentification valide avec wp_set_auth_cookie().

Le pirate n’avait donc même pas besoin de connaître le mot de passe de l’administrateur pour accéder au tableau de bord.

Un mécanisme de persistance commun aux différents sites

L’un des éléments les plus intéressants de l’analyse était un fichier .htaccess malveillant retrouvé à plusieurs emplacements.

Les différents exemplaires possédaient exactement le même hash SHA-256, ce qui signifie qu’ils étaient strictement identiques.

Leur fonctionnement était particulier : ils interdisaient l’accès à la plupart des fichiers PHP, puis réautorisaient explicitement une série de noms de fichiers utilisés par l’attaquant.

Parmi ces noms figuraient notamment plusieurs scripts identifiés comme portes dérobées.

Ces fichiers .htaccess avaient également été créés au même moment que certains loaders malveillants retrouvés sur le site abandonné.

Cette corrélation permettait de confirmer qu’il ne s’agissait pas de trois infections indépendantes, mais bien d’une même campagne de compromission touchant l’ensemble de l’environnement.

Du spam SEO injecté sur l’un des sites

Sur l’un des deux sites encore exploités, nous avons également retrouvé une page parasite particulièrement révélatrice.

Le domaine et l’URL appartenaient bien au site français d’origine, mais le contenu de la page faisait la promotion d’un site de jeux d’argent indonésien.

On y retrouvait :

• des titres et meta descriptions orientés casino et jeux d’argent ;
• des liens vers plusieurs domaines externes ;
• des balises hreflang et amphtml destinées au référencement ;
• du contenu et des ressources copiés depuis un autre site e-commerce étranger ;
• un canonical pointant pourtant vers le domaine WordPress compromis.

C’est un exemple typique de SEO spam ou de parasite SEO.

Le but n’est pas nécessairement de casser le site visible. L’attaquant profite de l’autorité du domaine compromis pour faire indexer des pages destinées à promouvoir d’autres activités.

C’est justement ce qui rend certaines infections difficiles à détecter : le site peut sembler fonctionner normalement pour son propriétaire tout en servant parallèlement à une campagne de spam.

Pourquoi un simple nettoyage ne suffisait pas

Une partie des fichiers malveillants avait déjà été supprimée avant notre intervention.

Pourtant, plusieurs mécanismes de persistance étaient encore présents et de nouvelles webshells avaient été déposées plusieurs mois après les premières traces de compromission.

C’est un scénario classique : supprimer le fichier visible ne suffit pas si une autre porte dérobée reste active.

L’attaquant peut simplement revenir quelques heures ou quelques semaines plus tard.

Nous avons donc choisi une approche plus large :

• analyse des fichiers et de leur chronologie ;
• recherche des webshells et loaders ;
• vérification des .htaccess et .user.ini ;
• contrôle des utilisateurs WordPress ;
• recherche de PHP dans les emplacements inhabituels ;
• analyse des journaux Apache et PHP-FPM ;
• contrôle des fichiers du cœur WordPress, des plugins et des thèmes ;
• recherche des traces de spam SEO ;
• identification des mécanismes permettant de passer d’un site à l’autre.

La stratégie retenue : ne pas reconstruire sur un environnement compromis

Deux des trois sites devaient être conservés.

Le troisième était un ancien site abandonné et fortement infecté. Il n’avait donc aucune raison d’être repris sur le nouvel hébergement.

Pour les deux sites conservés, la stratégie retenue est la suivante :

1. conserver une sauvegarde de l’environnement initial à des fins d’analyse ;
2. désinfecter les fichiers et les bases de données ;
3. remplacer les composants WordPress par des versions propres lorsque nécessaire ;
4. vérifier les comptes administrateurs et les accès ;
5. renouveler les mots de passe et secrets sensibles ;
6. migrer uniquement les versions assainies ;
7. remettre les sites en production sur de nouveaux environnements.

Le but n’est surtout pas de copier l’hébergement compromis tel quel vers un nouveau serveur.

Une migration de sécurité doit également être une occasion de repartir sur une base propre.

Migration vers o2switch et séparation des environnements

Les deux sites conservés seront migrés vers o2switch.

Mais surtout, ils seront placés sur deux Lunes distinctes.

Cette séparation change complètement le modèle de risque.

Avant la migration :

Site A
Site B
Site abandonné compromis
        ↓
même environnement système
        ↓
possibilité de propagation entre les sites

Après migration :

Lune 1
└── Site A

Lune 2
└── Site B

Si l’un des sites devait être compromis à l’avenir, l’autre ne partagerait plus directement le même environnement technique.

La migration permet également de renouveler les différents accès :

• comptes WordPress ;
• mots de passe des bases de données ;
• accès FTP/SFTP/SSH ;
• clés de sécurité WordPress ;
• identifiants SMTP ;
• éventuelles clés API.

On évite ainsi de conserver sur le nouvel hébergement des secrets qui auraient pu être récupérés pendant la compromission.

Sécurité : éviter l’empilement des solutions

Plusieurs solutions de sécurité étaient installées simultanément sur les sites.

Cela ne signifie pas forcément davantage de protection.

Des plugins de sécurité qui se chevauchent peuvent compliquer le diagnostic, multiplier les règles et parfois bloquer des requêtes légitimes.

Wordfence, par exemple, peut volontairement retourner certaines réponses HTTP 503 lorsqu’une requête est bloquée.

Dans ce dossier, les erreurs 503 étaient vraisemblablement multifactorielles :

• hébergement relativement limité ;
• saturation de PHP-FPM ;
• traitements PHP très longs ;
• activité automatisée ;
• présence de malware ;
• blocages liés aux solutions de sécurité.

La nouvelle configuration doit donc privilégier une sécurité cohérente : protections serveur, durcissement WordPress, sauvegardes externes, surveillance et une solution applicative correctement configurée.

Le suivi après désinfection est aussi important que le nettoyage

Une désinfection permet de remettre un site en état.

Elle ne remplace pas la surveillance dans le temps.

Les deux sites seront donc accompagnés dans le cadre d’un suivi technique comprenant notamment :

• mises à jour WordPress, thèmes et extensions ;
• sauvegardes régulières et externalisées ;
• surveillance de disponibilité ;
• solutions professionnelles de sécurité ;
• contrôle des alertes ;
• suivi des modifications sensibles ;
• intervention en cas de problème.

Et si une nouvelle infection devait malgré tout survenir, sa prise en charge ferait partie du suivi technique prévu.

Ce que ce cas nous rappelle

Une infection WordPress n’est pas toujours visible depuis le tableau de bord.

Dans ce dossier, nous avons retrouvé à la fois des webshells, des loaders distants, une porte dérobée d’authentification administrateur, des règles .htaccess de persistance et du spam SEO.

Le point le plus important était pourtant ailleurs : plusieurs sites partageaient le même environnement technique.

Le site le moins important, abandonné depuis longtemps, était devenu le maillon faible permettant de mettre en danger les sites encore exploités.

C’est aussi pour cette raison qu’un site WordPress inutilisé ne devrait jamais être simplement laissé en ligne.

Il faut soit le maintenir, soit le supprimer.

Le bilan TYTAE

Cette intervention ne s’est pas limitée à lancer un scanner antivirus.

Il a fallu reconstituer l’historique de la compromission, analyser les fichiers malveillants, lire les logs serveur, identifier les mécanismes de persistance et comprendre comment les différents sites pouvaient être liés.

Le résultat est une stratégie de remise en état beaucoup plus solide :

• deux sites conservés et désinfectés ;
• un ancien site compromis qui ne sera pas repris ;
• renouvellement des accès sensibles ;
• migration vers o2switch ;
• séparation des deux WordPress sur des Lunes distinctes ;
• mise en place d’un suivi technique et de solutions professionnelles de sécurité.

Lorsqu’un site WordPress est piraté, supprimer le premier fichier suspect trouvé n’est pas suffisant.

Il faut comprendre comment l’attaquant est entré, comment il peut revenir et jusqu’où il a pu aller.

C’est cette analyse qui permet ensuite de repartir sur une architecture réellement plus sûre.

Votre site WordPress semble compromis ?

Pages inconnues dans Google, redirections, erreurs 503 inexpliquées, nouveaux administrateurs, fichiers PHP suspects ou comportement inhabituel : ce sont autant de signaux qui méritent une analyse approfondie.

TYTAE intervient pour diagnostiquer les compromissions WordPress, rechercher les mécanismes de persistance, désinfecter les sites et mettre en place une stratégie de sécurisation durable.