Applications, sites et API
Particuliers et entreprisesDéfiguration de site
Website defacement
Un tiers remplace le contenu affiché par votre site.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
Une situation concrète
La page d’accueil d’une association affiche un message qu’elle n’a pas publié. Le changement est visible, mais il ne révèle pas à lui seul comment le site a été compromis ni quelles autres données ont été consultées.
Comment cela fonctionne
Une défiguration est une modification non autorisée du contenu d’un site. L’attaquant peut afficher une revendication, tromper les visiteurs ou nuire à la réputation du propriétaire. Il peut être entré par un compte d’administration volé, une faille ou un accès à l’hébergement. Restaurer la bonne page est nécessaire ; il faut aussi fermer l’accès utilisé pour empêcher son retour.
- Un accès de publication est détourné
Compte, faille ou hébergement.
- Le contenu est remplacé
Message, image ou redirection.
- Les visiteurs voient l’altération
La cause doit être corrigée avant reprise.
Les signes qui doivent attirer l’attention
- Un texte, une image ou une redirection apparaît sans publication prévue.
- Des fichiers ou contenus CMS sont modifiés par un compte inhabituel.
- Le contenu public diffère des versions validées.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Si un site connu affiche un message ou un téléchargement inattendu, interrompez votre action et avertissez son responsable. Si vous gérez ce site, contactez votre hébergeur ou prestataire.
Si vous êtes responsable du service ou de l’organisation
Préservez la page altérée et l’historique de publication. Fermez l’accès utilisé pour la modification avant de restaurer et vérifiez les autres comptes, fichiers et caches.
Restaurer la page d’accueil ne prouve pas que le site soit redevenu sûr.
À vous de décider
La bonne page est revenue après restauration. Pourquoi l’incident peut-il continuer ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Un compte ou un accès d’écriture peut toujours appartenir à l’attaquant. Tant que cet accès fonctionne, il peut modifier à nouveau le site.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Le contenu du site a changé : retrouver où la modification a été faite
Pour retrouver l’origine d’une défiguration, comparez d’abord les pages reçues aux différents points d’accès. Le contenu peut avoir changé dans le CMS, les fichiers du serveur, une publication CI ou un cache. Si le serveur d’origine envoie la page modifiée mais qu’un cache garde l’ancienne, tous les visiteurs ne voient pas la même chose.
Les empreintes de contenu aident à repérer ces différences, mais il faut tenir compte des éléments qui changent normalement : personnalisation, date ou contenu dynamique. Une différence de hash n’est donc pas automatiquement malveillante. L’historique des publications et le contenu modifié permettent de distinguer une mise à jour prévue d’une altération.
Rechercher ensuite qui pouvait écrire à cet endroit : compte CMS, clé de déploiement, accès au stockage ou compte CDN. Dans l’exemple, un compte administrateur supplémentaire doit être examiné même après restauration de la page. Sinon, l’attaquant peut republier sa modification.
La revendication affichée ne prouve pas l’identité de l’auteur. L’important pour la reprise est de connaître le chemin d’écriture utilisé et les autres ressources auxquelles il donnait accès. Remettre la page d’origine sans fermer ce chemin ne suffit pas à considérer l’incident terminé.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Modification non approuvée
Compte CMS vers Publication
Trace rev77
- Action
Publication du template
Publication vers Origine
- Action
Nouvelle réponse sur cache MISS
Origine vers CDN / visiteurs
Trace hash=ALTERED
- Action sur place
Ancienne copie encore présente
CDN / visiteurs
Trace age=1800
- Action
Création d’un accès secondaire
Compte CMS vers Publication
Trace svc-new
- Action
Restauration après fermeture des accès
Publication vers Origine
- Action
Purge et vérification multi-points
Origine vers CDN / visiteurs
Trace Référence approuvée
Comment repérer cette attaque
Indices à rechercher
Rechercher les contenus servis qui diffèrent des versions approuvées, ainsi que les nouveaux comptes, clés ou changements de configuration inexpliqués du CMS et du CDN.
Quelles informations comparer
Établir quelle version a été modifiée, laquelle est servie à l’origine et laquelle reste en cache. Rapprocher ensuite cette modification de la session et des droits du compte éditeur.
Ce que ces indices ne permettent pas de conclure
Une page redevenue correcte à l’origine peut rester altérée dans un cache. À l’inverse, une empreinte différente peut venir d’un contenu dynamique : comparer des éléments stables.
Comment réagir
Préserver les versions, retirer les accès persistants et corriger l’entrée avant restauration. Purger les caches concernés après publication d’un artefact fiable. Contrôler le site depuis plusieurs points de résolution et de diffusion, puis surveiller les modifications de compte et de contenu.
Vérifier la correction
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- L’origine et les caches doivent servir la version approuvée après restauration.
- Les accès utilisés pour la modification doivent être retirés ou sécurisés.
- Une publication métier normale doit rester possible et laisser une trace exploitable.
À vous de raisonner
La page d’origine est restaurée, mais un compte administrateur inconnu subsiste. Quelle conclusion faut-il éviter ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Évitez d’annoncer l’incident terminé : ce compte peut permettre une nouvelle publication. Retrouvez et sécurisez le chemin d’écriture, puis comparez les versions servies par l’origine et les caches. La revendication affichée ne suffit pas à attribuer l’attaque.
Consulter les détails techniques
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.
approved=false- Résultat de comparaison avec le processus d’approbation du cas, pas un champ que tous les CMS produisent.
ALTERED- Étiquette explicative remplaçant une empreinte réelle ; ce mot n’est pas une signature à rechercher dans les logs.
Chronologie de publication et de diffusion
JournalJeu fictif : les heures sont UTC et les revisions servent de clés de corrélation.
08:20Z cms actor=editor-4 login_source=198.51.100.44 session=s8
08:22Z cms actor=editor-4 action=update_template revision=rev77 approved=false
08:23Z origin path=/ hash=ALTERED revision=rev77
08:24Z cdn pop=paris path=/ hash=ALTERED cache=MISS
08:24Z cdn pop=lyon path=/ hash=BASELINE cache=HIT age=1800
08:25Z cms actor=editor-4 action=create_user role=admin user=svc-newPréparer une collecte dans votre environnement
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Dans le CMS, rechercher les révisions de pages ou modèles, l’auteur, les créations de comptes et les changements de rôle. Vérifier si un module d’audit était installé : l’historique des pages seul ne couvre pas tout.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
GitHub Actions — journaux d’exécution
- Où les trouver
- Dépôt → Actions → exécution concernée → job et étapes ; télécharger les logs encore disponibles et conserver séparément les attestations et artefacts de cette exécution.
- Quoi relever
- Si le site est déployé depuis GitHub Actions, comparer le commit, l’exécution et les artefacts publiés à la dernière version approuvée. Pour un site administré directement dans le CMS, utiliser son historique à la place.
- Accès et prérequis
- Accès au dépôt et historique non expiré. Le succès d’un job ne garantit ni l’identité de l’artefact déployé ni la légitimité de la modification qui l’a produit.
Chrome DevTools — panneau Network du navigateur
- Où les trouver
- Dans une capture déjà conservée, ou sur une reproduction autorisée en environnement de test : ouvrir Network et conserver la navigation avec Preserve log. Examiner Headers et Initiator.
- Quoi relever
- Comparer les réponses du domaine public et de l’origine via les accès autorisés, avec heure, corps de page et en-têtes de cache. Age renseigne l’âge d’une réponse en cache, pas l’heure de l’intrusion.
- Accès et prérequis
- La capture doit être active pendant l’observation : elle ne reconstitue pas le passé. Un export HAR peut contenir des données privées, même après retrait des en-têtes sensibles ; le nettoyer avant partage.
Si vous pensez être concerné
- Préservez une copie du contenu et des journaux avant restauration.
- Fermez le point d’entrée et révoquez les accès compromis.
- Restaurez une version fiable puis vérifiez les autres fichiers et données.
Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- MITRE ATT&CK — Defacement — attack.mitre.org
- OWASP — Logging — cheatsheetseries.owasp.org
