Site PHP sur mesure piraté : sans boutique d'extensions, par où chercher
Pas de boutique d'extensions, pas de « cœur officiel » à comparer. L'entrée passe par un upload, un formulaire, une librairie vieille de cinq ans ou un mot de passe FTP. Cartographiez avant d'effacer : le métier n'est souvent documenté nulle part. Réécrire l'application pour « être sûr » coûte plus cher que l'incident.
Upload, formulaire, librairie vieille de cinq ans, mot de passe FTP. Cartographiez avant d'effacer : il n'y a pas de « cœur officiel » à comparer.
Pourquoi le réflexe CMS ne marche pas ici
Sur WordPress, on compare au zip. Sur un site PHP métier, ce zip n'existe pas. Installer Wordfence « pour scanner » ne s'applique pas. Réinstaller un framework par-dessus un `app/` custom laisse l'entrée et casse les factures. Le guide site PHP piraté tient ce cap ; cet article déroule la recherche.
Les symptômes, eux, sont banals : redirection, spam SEO, phishing hébergé, minage, ticket d'abus. Le protocole de copie et de mots de passe est le même que pour un CMS. Premiers gestes. Ce qui change : on ne « désinstalle pas l'extension ». On lit du code que personne n'a commenté depuis 2017.
Laravel, Symfony, CodeIgniter, Fat-Free, ou 200 fichiers à la racine sans autoload : l'étiquette rassure le commercial. Elle ne dit pas où est l'upload. Cartographiez.
Cartographier avant d'effacer
Listez les dossiers, les points d'entrée HTTP (front controller unique ou dix `*.php` publics), les crons du panel, les bases, les utilisateurs FTP. Dates de modification : un cluster de PHP touchés la même heure oriente plus qu'un scan de signatures.
Git s'il existe : `status` et l'historique aident — sauf si `.git` est en ligne, ce qui est une fuite en soi. Dossier .git exposé. Pas de Git : la copie d'avant toute suppression est votre seul filet. Sans elle, retirer un « suspect » casse une fonction de devis que le client utilisait ce matin.
Documentez au fur et à mesure (même un tableur). Le prestataire suivant, ou vous dans trois semaines, en aura besoin. C'est aussi le constat pour l'hébergeur. Compte suspendu.
- Arborescence et document root réel.
- Cron panel + cron Unix.
- Secrets : `.env`, configs, pas seulement « le FTP ».
Uploads, formulaires, dossiers publics inscriptibles
Champ de CV, dépôt de pièces, « importer un CSV », éditeur riche qui accepte un fichier : portes fréquentes. On ne donne pas ici de méthode d'attaque. On dit : tout dossier web inscriptible par PHP doit être inspecté (dates, extensions étranges), puis l'exécution PHP y être interdite après nettoyage.
Un formulaire qui construit une commande shell ou une requête avec l'entrée utilisateur est une porte classique, même sans « CMS ». Le correctif est dans le code métier, pas dans un plugin. Si personne ne sait le lire, déléguez avant d'ouvrir les permissions en 777 « pour tester ».
Adminer / phpMyAdmin / un `install.php` oublié : surfaces d'admin hors métier. Adminer public, phpinfo.
Librairies, Composer, cron, webservices
Une lib PDF, un old PHPMailer, un SDK oublié dans `/lib` : cinq ans sans maj. `composer.lock` s'il existe. Ne réinstallez pas `vendor` depuis le même cache douteux. Dépendances compromises.
Cron : un script « synchro » toutes les nuits, un wget interne, un mailer. C'est là que le minage et le spam se relancent. Tâches cron inconnues, cryptominage.
Webservice, webhook, old API key dans le code : révoquez. SSRF et webhooks — le principe s'applique hors CMS.
Laravel, Symfony, « maison » : des indices, pas une recette unique
Laravel : `.env`, `storage` (logs + parfois uploads), `public`, routes, users dans la base. Un `APP_DEBUG` resté vrai. Symfony : `.env`, `var/`, `public/`, bundles morts. Maison : tout est public tant que le vhost pointe sur le mauvais dossier.
Ces indices accélèrent. Ils ne remplacent pas la carte de CE site. Un Laravel « propre » avec un `public/uploads` exécutable PHP n'est pas propre.
Front npm / Vite : le piratage peut être un script tiers, pas le PHP. CDN JS compromis. Le CMS n'existe pas ; le navigateur des clients, si.
Ce que l'hébergeur voit (et ce qu'il faut lui demander)
Journaux d'accès, d'erreur PHP, FTP, archive du compte. Sur alwaysdata, SSH est souvent déjà là : utilisez-le pour dater, pas pour tout rm. alwaysdata. Mutualisé générique : Amen, Hosteur, mutualisé.
Motif d'abus : malware, phishing, resource abuse. Un site sur mesure coupé pour minage ne se « réinstalle » pas comme un WordPress. Traitez le process, puis le fichier, puis l'entrée. o2switch cite souvent un chemin : partez-en, élargissez.
Adresse perso dans le ticket si le mail du domaine est sur le même compte. Mail coupé.
Reconstruire sans tout perdre
On retire les ajouts, on corrige l'entrée, on conserve le métier. Réécrire « proprement » est un projet de mois, pas un forfait de nettoyage. Melanger les deux le soir de l'alerte Chrome perd des règles de facturation non documentées.
Point propre : sauvegarde hors compte, datée d'avant les premières dates suspectes — encore faut-il qu'elle existe. Sinon on chirurgicale. Restaurer un zip d'hébergeur du jour de la suspension remet l'infection. Archive sale.
Rançon sur les fichiers : inventaire de ce qui est encore lisible, pas paiement. Rançongiciel.
Refermer : le minimum qui tient sans plugin de sécu
Secrets tournés (panel, FTP/SSH, `.env`, base, API). PHP interdit dans les dossiers d'upload. Moins de comptes admin maison. Dépendances listées. Cron relu. Isolation si d'autres sites partagent le compte. Sauvegardes hors serveur.
Un WAF après, comme filet. WAF. Tests visiteurs et 48 h. Tests.
Si le développeur a disparu, prestataire web parti. Créer un compte pour un constat ; personne ne « s'occupe de la CNIL à votre place » si des données ont pu sortir. Fuite.