Comment détecter une attaque ou un malware sur son site web ?

On va être clair dès le début :
ߑ頳i vous vous demandez comment détecter une attaque ou un malware sur votre site, c’est rarement pour le plaisir.

En général, c’est parce qu’un truc cloche… et souvent, ça sent la fumée.

J’ai vu assez de sites piratés dans ma carrière — du WordPress bricolé au PrestaShop surchargé, en passant par des Joomla qui dataient de l’âge de pierre — pour reconnaître les signes avant même d’ouvrir un FTP.
Et je vous rassure : ce n’est pas toujours subtil.

Parfois, l’attaque ressemble à un braquage discret.
Parfois… c’est comme retrouver quelqu’un dans votre salon en train de manger des chips.

par Laurent Lacoste — Architecte Web & Responsable Cybersécurité

Les symptômes “évidents” que beaucoup ignorent (jusqu’au drame)

Avant de parler de malware sophistiqué, il y a des signes basiques que tout le monde devrait remarquer.
Je vous mets ça dans un tableau simple :

Note de l’auteur :

Oui, si votre site vend des fleurs et qu’on trouve des pages sur le “casino en ligne”, vous avez un problème. Pas besoin d’un audit de la NASA ou sinon vous avez un drôle de concept de vente.

Pourquoi cette introduction est importante ?

Parce que la plupart des propriétaires de site réagissent trop tard.
Ils pensent que :

• “ça va passer”,
  
  
• “c’est peut-être un bug temporaire”,
  
  
• “on verra ça demain”,
  … et pendant ce temps, le pirate, lui, ne dort pas.
  
  

La vérité est simple :
ߑ頕n site compromis se repère vite… si on sait où regarder.

Et si vous êtes ici, c’est probablement le bon moment pour vérifier.

Les signes évidents que votre site a été compromis

Avant de sortir les gros outils d’analyse, on commence par le b.a.-ba :
ߑ頬es symptômes visibles, ceux que je retrouve dans 80 % des sites compromis que j’audite.

Et sincèrement…
beaucoup de propriétaires de site auraient pu éviter la catastrophe rien qu’en jetant un œil à ces signaux-là.

1. Les pages bizarres qui apparaissent “comme par magie”

Vous tapez votresite.com dans Google…
…et vous découvrez des pages :

• qui parlent de Viagra,
• de casino,
• de crypto,
• de streaming illégal.
• ou d'autres choses mais je ne veux pas de problème avec Google.

Oui, ce n’est pas Google qui hallucine :
ߑ頣e sont des pages générées par le pirate.

Exemple : Le site d'un Lycée sous Wordpress et qui a été piraté à cause d'un plugin non mis à jour et qui proposé des services d'escortes.

Tableau — Ce que vous voyez vs Ce que ça signifie

Note de Laurent :

Si Google indexe des pages que vous n’avez jamais créées,
je vous garantis à 99 % que ce n’est pas un stagiaire qui a mal cliqué. (et pourtant c'est si simple de désigner le stagiare)

2. Redirections étranges (surtout sur mobile)

Les attaques “sournoises” redirigent :

• uniquement les visiteurs mobiles,
• uniquement les nouveaux visiteurs,
• uniquement depuis Google.
  
  

Pourquoi ?
Pour que vous ne le voyez jamais car vous vous connectez directement sur votre site web sans passer par une recherche Google.

Signes typiques :

• redirection vers un site de paris
• page blanche puis pub
• popup agressive
• ou pire : téléchargement automatique…
  
  

ߑ頦Ccedil;a, c’est presque toujours une infection JavaScript ou une injection dans le thème.

3. Votre site devient lent du jour au lendemain

Un site infecté :

• charge du code externe,
• se fait crawler par des bots parasites,
• exécute des scripts malveillants.
  
  

Symptôme classique :

Page d'accueil : 400ms → 3,5s en 24h

 C’est LE signe d’un malware actif. Les pages ne prennent pas subitement du poids par magie.

4. Chute brutale du SEO ou alertes dans Google Search Console

Search Console ne ment jamais.

Les alertes typiques :

• “Votre site contient du contenu dangereux”
• “Des pages renvoient des erreurs de type soft 404”
• “Augmentation anormale d’URLs exclues”
  
  

Graphique typique :

Une courbe d’impressions qui tombe comme une falaise.

ߑ頕n malware peut faire perdre 100 % du trafic Google en quelques jours.

5. Connexions admin ou FTP que vous ne connaissez pas

On parle ici :

• d’un compte admin inconnu,
• d’un utilisateur créé sans raison,
• d’un accès FTP / SFTP suspect,
• d’un email de réinitialisation de mot de passe non demandé.
  
  

Tableau — Ce que ça signifie

6. Le fichier .htaccess a changé tout seul

Si vous voyez dans votre .htaccess des lignes comme :

RewriteRule ^(.*)$ http://site-frauduleux.com/$1 [L,R=302]

 ou

eval(base64_decode(…))

 … je vous confirme que ce n’est pas un bug de l’hébergeur.

7. Envoi massif d’emails depuis votre site

Votre serveur envoie :

• 1 000 mails / minute
• des spams
• des tentatives de phishing
  
  

Votre domaine sera blacklisté.
Et parfois, c’est déjà trop tard.

Webographie sur la cybersécurité

• Comment protéger son site WordPress contre les attaques SEO
• Configurer un pare-feu WAF sur un site Joomla e-commerce
• Comment éviter le phishing : guide de protection contre les arnaques en ligne
• Sécuriser un site Joomla en 2025 : bonnes pratiques & extensions
• Mettre de l’IA, c’est bien… mettre de la sécurité, c’est mieux !

Les signaux techniques qui ne trompent pas

Les signes visibles, c’était l’échauffement.
Maintenant, on passe au moment où j’enfile les gants en latex et où j’ouvre les logs, le FTP et les entrailles du site.
ߑ頦lt;strong>C’est là que les vrais symptômes apparaissent.
Ceux qui ne se voient pas depuis la surface, mais qui ne mentent jamais.

Et je te préviens : si tu retrouves l’un de ces signaux, tu n’as plus un site “suspect”.
Tu as un site compromis.

1. Des fichiers inconnus dans le FTP (le grand classique)

Tu ouvres ton FTP et tu vois des choses comme :

• /tmp/.cache/xyz.php
• /img/.thumbs/upload_443.php
• config44.php
• wp-lock.php (sur un site qui n’a rien de WordPress…)
  
  

ߑ頃e sont souvent des webshells, des portes d’entrée laissées par un pirate.

Tableau — Types de fichiers suspects

Note de Laurent :

Oui, un fichier PHP dans /img/ c’est comme trouver une valise de billets dans votre salle de bain : non, ce n’est pas normal. (enfin pour moi)

2. Modifications anormales du thème ou des fichiers core

Tu vérifies les dates de modification et là…
ߑ頴on thème a été modifié hier à 03h12, alors que toi, tu dormais paisiblement.

Les zones sensibles

• /themes/mon-theme/templates/
• /js/
• /override/
• /modules/
• fichiers core (index.php, init.php, header.tpl…)
  
  

Indices :

• code ajouté en fin de fichier
• fonctions eval(), base64_decode, gzuncompress
• iframes invisibles
• includes externes vers des serveurs inconnus
  
  

3. Pics de trafic anormaux (surtout venant de pays improbables)

Un petit coup d'œil dans Matomo, GA4 ou votre hébergeur.
Si vous voyez :

• un pic massif de trafic venant du Brésil, de Russie, d’Indonésie à 4h du matin
• un taux de rebond à 99%
• pages inconnues consultées par des bots
  
  

ߑ頃’est un signe d’attaque brute-force ou scan automatisé.

Tableau — Types de pics anormaux

4. Événements anormaux dans les logs serveur (Apache/Nginx)

Les logs ne mentent jamais.
Et il y a certains patterns qui crient “attaque” à 10 km.

Requêtes suspectes

• tentatives eval()
• injections SQL (ex: UNION SELECT)
• tentatives d’upload .php
• attaques XSS
• accès à /tmp/, /backup/, /private/
  
  

Exemple réel

POST /upload.php HTTP/1.1

Content-Type: multipart/form-data

filename="shell.php"

ߑ頌à… ce n’est pas un simple visiteur curieux.

5. Comptes administrateurs inconnus

Rien de tel qu’un petit tour dans l’administration.

Si tu vois :

• un admin nommé “test”, “support”, “backup-user”
• un rôle inconnu
• un mail suspect (ex: Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.)
• des permissions modifiées
  
  

ߑ頴u peux être certain que quelqu’un a installé un siège à ton insu.

6. Votre serveur envoie des emails tout seul

Si l’hébergeur t’annonce :
“Votre site envoie du spam”,
ce n’est pas une hypothèse.
C’est la réalité.

Causes fréquentes

• fichier PHP transformé en bot mail
• formulaire détourné
• compte SMTP compromis
• malware qui envoie des milliers de mails / heure
  
  

Résultat : blacklist du domaine → fin de la délivrabilité.

7. Signatures malveillantes dans le code

Les pirates utilisent des techniques de camouflage.
Voici les patterns classiques :

eval(base64_decode(…))

gzinflate(…)

shell_exec(…)

passthru(…)

$payload = …

Si tu vois un de ces mots, tu arrêtes tout.
Ce n’est jamais légitime dans un site vitrine.

Comment vérifier concrètement si votre site contient un malware ?

À ce stade, on a vu :

• les signes visibles (phase 2),
• les symptômes techniques (phase 3).
  
  

Maintenant on attaque ce qui vous intéresse vraiment :
ߑ頦lt;strong>comment vérifier, preuves à l’appui, si votre site est infecté.
Pas d’intuition, pas de “je pense que…”, pas de panique :
on fait un diagnostic propre, exact, étape par étape.

1. Lancer un scan externe (les rayons X pour votre site)

C’est la première étape.
Un scan externe détecte :

• les scripts injectés
• les redirections
• les malwares connus
• les pages zombies
• les signatures malveillantes
  
  

Outils fiables (et gratuits pour commencer)

Note de Laurent :

Si Sucuri vous dit que votre site est infecté…
vous pouvez ranger l’espoir au placard. C’est vrai.

2. Vérifier les fichiers sensibles (FTP / File Manager)

On passe en mode chirurgien.
Les malwares se cachent souvent dans les zones suivantes :

Zones à inspecter en priorité

• /img/ (s’il y a du PHP ici = infection)
• /upload/
• /cache/
• /modules/ (PrestaShop, Joomla)
• /wp-content/uploads/ (WordPress)
• les fichiers .php modifiés récemment

Indices d’infection

• fichiers encodés (base64, gzuncompress)
• fichiers avec nom aléatoire (x7H2.php)
• contenu suspect dans index.php, header.php, footer.php
  
  

3. Scanner le code à la recherche de signatures malveillantes

Les pirates ne sont pas toujours subtils.
Leurs outils laissent des signatures reconnaissables.

À rechercher dans le code :

eval(

base64_decode(

gzinflate(

shell_exec(

touch("

/tmp/

<?php

Si vous trouvez ça :
ߑ頶ous avez un malware actif.

4. Vérifier les scripts et appels externes (analyse front-end)

C’est souvent là que se cachent les redirections silencieuses.

Méthode simple

1. Ouvrir votre site dans Chrome
   
   
2. Inspecter → onglet “Network”
   
   
3. Recharger en mode privé
   
   
4. Rechercher des appels vers :
   
   
   • des domaines inconnus
     
     
   • des .js externes suspects
     
     
   • des CDN exotiques
     
     
   • des scripts minifiés jamais installés
     
     

Exemple

cdn-jquery-update.ru/jquery.min.js

 … je vous garantis que ce n’est pas normal. (et je n'ai rien contre nos amis russes)

5. Vérifier votre base de données

Les pirates injectent parfois directement dans la base.

Recherches dangereuses :

• <script>
• onload=
• iframe
• base64 dans les champs de contenu
• utilisateurs admin inconnus

C'est plus simple si vous connaissez le language Sql pour trouver ces éléments.

Tables à inspecter

• ps_employee / ps_user
• ps_configuration
• wp_users (sur WordPress)
• content et modules (Joomla)

6. Vérifier les accès administrateurs & permissions

Un pirate laisse toujours un accès derrière lui.

À vérifier :

7. Faire un test via Google Safe Browsing

Google vous dira si votre site est :

• hacké
• dangereux
• redirigeant
• hébergeant du code malveillant

ߑ頌ien : https://transparencyreport.google.com/safe-browsing/search

8. Vérifier l’intégrité de votre CMS

Comparez vos fichiers avec :

• une version propre du CMS
• ou une installation neuve

Si des fichiers diffèrent alors que vous n’avez rien touché → infection probable.

Particulièrement sensible :

• WordPress : /wp-includes/ & /wp-admin/
• PrestaShop : controllers/, override/, modules/
• Joomla : /libraries/, /templates/

Que faire si une attaque est confirmée ? (la procédure d’urgence, sans panique)

Bon.
Si vous êtes ici, c’est que les phases précédentes ont confirmé le verdict :
ߑ頦lt;strong>votre site est bel et bien compromis.
Pas besoin de dramatiser, mais pas de déni non plus.
On respire, on garde la tête froide, et on applique une procédure propre, étape par étape.

Voici la méthode que j’utilise réellement en intervention, chez TooNetCreation ou sur des missions d’urgence cyber : simple, efficace, sans perte de temps.

1. Mettre le site en maintenance (immédiatement)

L’objectif :

• bloquer les visiteurs,
• éviter la propagation du malware,
• empêcher Google d’indexer encore plus de pages toxiques,
• et surtout empêcher le pirate de continuer à opérer.

Conseils :

• activer le mode maintenance du CMS ou de l’hébergeur
• jamais de “maintenance via plugin douteux” si on suspecte une infection
• sauvegarder l’état actuel du site pour analyse (oui, on garde la version infectée pour l’autopsie)

2. Changer TOUS les accès (sans exception)

J’insiste : TOUT.
Pas seulement le compte admin.

Liste complète :

• accès admin (CMS)
• FTP / SFTP
• base de données
• compte hébergeur
• API (si existantes)
• accès au back-office PrestaShop / WordPress / Joomla
• clés du CDN
• mots de passe e-mail liés au site

Note de Laurent :

Si vous changez un seul mot de passe et laissez le reste,
c’est comme changer la serrure… en laissant la fenêtre ouverte. (j'espère pour vous que vous n'utilisez pas ce mots passe ailleurs que sur votre site web)

3. Nettoyer les fichiers infectés ou restaurer une sauvegarde saine

Deux stratégies possibles :

✔ Option A — Nettoyer fichier par fichier

Indiqué si :

• peu de fichiers compromis
• pas d’accès root perdu
• site non critique

✔ Option B — Restaurer une sauvegarde propre

Indiqué si :

• infection profonde
• piratage massif
• fichiers système altérés
• site e-commerce (pour minimiser la casse)

À vérifier avant restauration :

• la date (ne jamais restaurer une sauvegarde déjà infectée)
• la BDD (les pirates adorent s’y cacher)

4. Supprimer les portes dérobées (backdoors)

Les backdoors sont souvent plus dangereuses que le malware lui-même.
Si vous ne les supprimez pas, le pirate reviendra… parfois en quelques heures.

Localisations fréquentes :

• /modules/, /plugins/, /components/
• /uploads/
• /img/ (oui, ça arrive)
• fichiers au nom étrange : cache.php, tmp12.php, config-new.php
• fichiers encodés ou chiffrés

Méthode :

• rechercher les fonctions eval, base64_decode, gzinflate
• comparer les fichiers du CMS avec une version propre
• supprimer tout fichier inconnu ou modifié sans raison

5. Réparer les fichiers core du CMS

Il faut restaurer :

• fichiers système originaux
• templates corrompus
• scripts JS légitimes
• fichiers override (PrestaShop)
• fichiers du thème (WordPress / Joomla)

Astuce :
ߑ頳ouvent, remplacer entièrement /wp-admin/, /wp-includes/, /controllers/, /classes/ resolve 80 % des dégâts.

6. Analyser la base de données (là où se cachent les injections)

Ce que je cherche dans chaque audit :

• <script> dans les champs texte
• iframe
• base64
• comptes admin inconnus
• paramètres système modifiés
• modules injectés

Tables sensibles :

• ps_configuration, ps_employee, ps_module (PrestaShop)
• wp_users, wp_options (WordPress)
• #__users, #__extensions (Joomla)

et oui c'est toujours les mêmes qui sont les cibles des attaques.

7. Réinstaller les plugins / modules propres

Beaucoup d’infections viennent :

• d’un plugin nul
• d’un module gratuit instable
• d’un module cracké (oui, ça existe…)
• d’une mise à jour non appliquée

ߑ頏n désinstalle et on réinstalle uniquement ce qui est propre.

8. Vérifier et réparer les fichiers .htaccess

Un .htaccess infecté = injections et redirections malveillantes.

À faire :

• supprimer toutes les lignes suspectes

• recharger un .htaccess propre depuis le CMS

• vérifier redirections, rewrite rules, headers

• s’assurer que les filtres SEO non indexables sont bien bloqués

9. Scanner à nouveau (double vérification)

Comme pour une infection médicale, on vérifie deux fois.
Un dernier scan :

• Sucuri
• ClamAV (si accès SSH)
• Malcare (WordPress)
• VirusTotal
• sécurité hébergeur (OVH / o2switch / Infomaniak)
  
  

10. Lever la maintenance et demander un nouveau crawl Google

Une fois la boutique propre :

• retirer le mode maintenance
• tester navigation & paiement
• vérifier Search Console
• soumettre un sitemap propre
• demander une exploration
• surveiller pendant 1 semaine

Comment éviter que ça recommence ? (la sécurité durable, simple et efficace)

Une fois un site nettoyé, on arrive au moment le plus important :
ߑ馬t;strong> empêcher la prochaine attaque.
Parce que oui, un pirate adore revenir là où il est déjà passé.
Et un site déjà compromis est souvent plus fragile.

Voici le plan de sécurisation durable que j’applique dans toutes mes missions TooNetCreation.

1. Mettre en place un système de mises à jour régulier

Le premier facteur d’infection ?
ߑ頕n CMS ou un plugin pas à jour.

À appliquer :

Note de Laurent :

Un site pas mis à jour, c’est comme une porte blindée… mais ouverte.

2. Sécuriser les accès (admin, FTP, base de données)

Un pirate n’a pas besoin d’un tunnel sous-terrain.
Un mauvais mot de passe suffit.

Checklist obligatoire :

• mot de passe complexe (12+ caractères, unique)
• double authentification (si disponible)
• renommer l’URL admin (WordPress)
• désactiver l’accès admin via /wp-admin/ pour les IP tierces
• désactiver lister les fichiers via .htaccess
• limiter les connexions admin (firewall, whitelist IP)
  
  

3. Installer un firewall applicatif (WAF)

C’est LA barrière contre :

• injections
• bots qui scannent vos fichiers
• brute-force
• scripts malveillants
• accès non désirés

Solutions fiables :

• Cloudflare – WAF + Rate Limiting pour protéger votre site web
• Sucuri Firewall – Pare-feu applicatif et protection anti-DDoS
• Wordfence – Firewall et anti-malware dédié à WordPress
• RSFirewall – Protection avancée pour les sites Joomla

Effet immédiat :
→ 80 % des attaques stoppées.

4. Scanner le site automatiquement (surveillance continue)

Parce qu’on ne peut pas surveiller un site toutes les heures.

À mettre en place :

• scan quotidien des fichiers
• alertes en cas de modification
• détection de fichiers suspects
• monitoring uptime + comportements anormaux

Outils recommandés (selon CMS) :

• Sucuri Monitoring – Surveillance de sécurité complète pour sites web
• MalCare – Protection WordPress avec monitoring et nettoyage automatique
• WP Cerber – Sécurité avancée pour WordPress (anti-malware & firewall)
• PrestaShop Security Suite – Extension officielle pour sécuriser un site PrestaShop
• Monitoring hébergeur – Outils de surveillance proposés par les hébergeurs

5. Sécuriser correctement vos modules / extensions

Dans 60 % des attaques que je vois, le problème venait d’un module.
Parfois gratuit.
Parfois cracké.
Parfois juste mal développé.

Règle stricte :

Astuce :
→ Vérifier la dernière mise à jour du module avant installation.

6. Gérer les sauvegardes intelligemment (sauvegarde ≠ sécurité)

Une sauvegarde qui dort sur le même serveur que votre site…
ߑ頮e vous protégera jamais.

Best practices :

• sauvegardes automatiques quotidiennes
• stockage externe (S3, Dropbox pro, serveur déporté)
• versioning sur 30 jours
• test de restauration tous les 2–3 mois

Note de Laurent :

Une sauvegarde non testée = une sauvegarde inexistante.

7. Sécuriser le serveur & l’hébergement

Les pirates ne passent pas toujours par le site.
Parfois, c’est le serveur qui est faible.

Points critiques à sécuriser :

• désactiver les fonctions PHP dangereuses (exec, passthru, system)
• activer ModSecurity (Apache) ou Naxsi (Nginx)
• configurer Fail2Ban
• limiter les droits en écriture
• désindexer les environnements de staging
• SSL partout, HSTS activé

8. Mettre en place une surveillance SEO (Google Search Console)

Parce qu’un site hacké lègue toujours des traces dans :

• les pages indexées
• les erreurs
• les exclusions
• les impressions SEO
  
  

À surveiller chaque semaine :

9. Désinstaller tout ce qui ne sert pas (règle d’or cyber)

Chaque module ou plugin inutilisé = une porte potentielle.
Moins il y en a, plus vous êtes en sécurité.

À supprimer :

• modules inactifs
• plugins non utilisés
• vieilles sauvegardes
• thèmes inutilisés
• extensions abandonnées

Quoi retenir au final ?

On arrive au bout de ce guide… et si vous êtes encore là, c’est que :

1. votre site vous inquiète vraiment,
2. ou vous avez compris qu’en matière de sécurité, attendre = se faire avoir,
3. ou vous aimez me lire.

Soyons honnêtes deux secondes :
ߑ頬a plupart des sites piratés auraient pu être protégés avec trois bonnes pratiques appliquées au bon moment.
Mais par manque de temps, par négligence, ou juste parce que “on verra ça plus tard”, le problème arrive.
Et il arrive toujours quand vous avez autre chose à gérer.

La bonne nouvelle ?
Vous avez maintenant toute la méthode pour :

• repérer une attaque,
• diagnostiquer une infection,
• nettoyer proprement,
• sécuriser durablement,
• et éviter que ça recommence.
  
  

C’est la même méthode que j’applique chez TooNetCreation, en audit comme en intervention d’urgence.

Mais soyons francs :
ߑ頔outes ces étapes, vous pouvez les faire seul…
ߑ頭ais vous pouvez aussi me laisser le faire proprement, rapidement, et sans stress.

Parce que c’est mon métier, et que je passe mes journées dans les entrailles de sites WordPress, Joomla, PrestaShop et autres frameworks qui n’aiment pas qu’on les laisse vieillir.

Votre site tourne bizarrement ? Vous pensez qu’il a pris un coup ?

Ne restez pas dans le doute.
Plus on agit tôt, moins il y a de dégâts.

Chez TooNetCreation, je peux :

• analyser votre site en profondeur,
• détecter précisément l’origine de l’infection,
• nettoyer fichiers + base + accès,
• supprimer toutes les backdoors (les plus vicieuses),
• remettre le site d’équerre,
• renforcer durablement la sécurité,
• mettre en place monitoring + backups + firewall,
• et vous accompagner sur la suite.
  
  

Un site sécurisé, c’est un site qui continue de travailler pour vous.
Un site hacké… travaille pour quelqu’un d’autre.

Si vous voulez remettre les choses dans le bon sens :
ߑ頦lt;a href="/contact.html" target="_self">Contactez TooNetCreation
On fait un point, on regarde ensemble, et je vous dis exactement ce qu’il faut faire — sans bla-bla, sans vente forcée, juste du travail propre.

Laurent Lacoste — Architecte Web & Responsable Cybersécurité

Webographie des ressources qui ont été utilisé pour rédiger cet article

• Cybermalveillance.gouv.fr – Identifier un virus ou une attaque
• ANSSI – Bonnes pratiques de sécurité informatique
• Google Safe Browsing – Vérifier la sécurité d’un site
• Sucuri – Scanner de malware et diagnostic de sécurité
• OWASP – Documentation et ressources sur la sécurité web