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
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
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
La défiguration remplace ou modifie sans autorisation le contenu d’un site. Elle peut servir à afficher une revendication, tromper les visiteurs ou nuire à la réputation. L’entrée peut être un compte d’administration volé, une faille ou un accès d’hébergement compromis. Remettre la bonne page est nécessaire, mais ne suffit pas si l’accès malveillant existe encore.
- 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.
Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous 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 ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
L’attaquant peut encore disposer d’un compte ou d’un accès d’écriture. Sans retrait de cet accès, il peut modifier de nouveau le site.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Le contenu du site a changé : retrouver où la modification a été faite
Une défiguration peut venir du CMS, des fichiers du serveur, d’une publication CI ou d’un cache. Commencer par comparer les versions reçues selon les points d’accès. Si l’origine sert une page altérée tandis qu’un cache conserve l’ancienne version, les visiteurs ne voient pas tous le même résultat.
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.
Éléments à croiser
É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.
Limites de l’interprétation
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
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- 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 ?
Formulez votre décision et l’élément qui la justifie 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
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-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
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des 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 qualifier votre situation et être orienté : 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
