Manipulation et diffusion
Particuliers et entreprisesPiégeage d’un site fréquenté
Watering-hole attack
Un site que vous consultez régulièrement est piégé pour atteindre ses visiteurs.
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
Les membres d’un secteur professionnel consultent régulièrement le même site de ressources. Un attaquant compromet ce site ou un composant qu’il charge. Les visiteurs continuent à utiliser leur favori habituel ; certains reçoivent désormais un faux téléchargement ou une redirection malveillante.
Comment cela fonctionne
L’attaquant piège un site que ses cibles ont l’habitude de consulter. Le site peut garder presque la même apparence, ce qui rend le changement difficile à remarquer. Une visite ne provoque pas toujours une infection : dans certains cas, il faut télécharger un fichier ou accomplir une action. Dans d’autres, l’attaque exploite une faiblesse du navigateur ou d’un de ses composants.
- Un site connu est piégé
Il est fréquenté par les cibles.
- La visite reste habituelle
Le contenu malveillant apparaît discrètement.
- Une action ou une faille est exploitée
L’objectif dépend de la campagne.
Les signes qui doivent attirer l’attention
- Un site connu exige soudain une mise à jour à télécharger depuis sa page.
- Des visiteurs observent des redirections différentes selon leur appareil.
- Une alerte de sécurité apparaît uniquement après la consultation d’une ressource habituelle.
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 vous impose une mise à jour, fermez cette invitation. Mettez le navigateur à jour depuis ses propres paramètres.
Si vous êtes responsable du service ou de l’organisation
Surveillez les modifications du site, y compris ses extensions et scripts externes. Après une alerte, cherchez quels visiteurs ont téléchargé ou exécuté le contenu distribué.
Un favori protège contre certaines fautes d’adresse, mais pas contre la compromission du vrai site.
À vous de décider
Le site est dans vos favoris depuis trois ans. Son téléchargement est-il forcément sûr ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Votre favori vous conduit à la bonne adresse, mais le vrai site peut avoir été piraté. Vérifiez l’installation inattendue même si vous connaissez le site depuis longtemps.
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
Un site habituellement fiable redirige seulement certains visiteurs
La page principale paraît identique. En revanche, une nouvelle version d’un composant tiers redirige certains visiteurs. L’attaquant atteint ainsi ses cibles sur un site qu’elles fréquentent déjà, sans devoir envoyer un message à chacune.
Le comportement peut dépendre du navigateur, de l’adresse réseau ou de la provenance du visiteur. Une simple requête de contrôle depuis le serveur de supervision peut donc ne rien montrer. Il faut examiner les ressources réellement chargées par un navigateur et reproduire les conditions observées sur un poste concerné, dans un environnement isolé.
Comparer les versions des scripts, leur provenance et les comptes qui ont permis leur publication. Une redirection établit un contact avec une autre ressource ; elle ne prouve pas qu’une exploitation ou une installation a réussi. Pour mesurer l’impact, relier les visites aux téléchargements, processus et connexions ultérieurs. Si le composant provient d’un fournisseur, l’enquête doit aussi déterminer quels autres sites ont chargé la même version.
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
Visite habituelle
Visiteur ciblé vers Site métier
Trace R2
- Réponse
Document légitime
Site métier vers Visiteur ciblé
Trace main-v4
- Action
Chargement du widget
Visiteur ciblé vers Ressource tierce
Trace révision 17
- Réponse
Code reçu
Ressource tierce vers Visiteur ciblé
Trace hash conservé
- Action
Navigation secondaire
Visiteur ciblé vers Destination secondaire
Trace initiateur widget.js
- Réponse
Fausse mise à jour éventuelle
Destination secondaire vers Visiteur ciblé
Trace exécution à prouver
- Action
Correction et purge
Site métier vers Ressource tierce
Trace chemin de publication
Comment repérer cette attaque
Indices à rechercher
Surveiller les changements de ressources et de destinations chargées sur un site fréquenté, y compris dans ses composants tiers, ainsi que les redirections et téléchargements inattendus.
Quelles informations comparer
Comparer les visiteurs affectés et non affectés, le composant chargé et la révision publiée. Une redirection conditionnelle peut dépendre du navigateur, du réseau ou de l’heure.
Ce que ces indices ne permettent pas de conclure
Ne pas conclure qu’un site est sain parce qu’une visite actuelle ne reproduit rien. Inversement, une différence entre visiteurs peut venir d’une personnalisation légitime : identifier la modification précise.
Comment réagir
Conserver les versions servies, retirer la ressource compromise et sécuriser son chemin de publication. Informer les populations exposées avec la période et les indices utiles, puis rechercher l’effet sur les postes. Purger les caches après correction de l’origine.
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.
- Comparer plusieurs contextes de navigation et révisions de cache dans un environnement contrôlé.
- Vérifier que la ressource corrigée est réellement servie par les points CDN concernés.
- Distinguer visiteurs exposés et terminaux dont l’exécution malveillante est confirmée.
À vous de raisonner
La supervision ne voit aucune redirection, mais un partenaire en observe une. Quelle comparaison permet d’avancer sans écarter son signalement ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Comparez les ressources et leurs versions dans les contextes de navigation concernés, en environnement isolé. Un composant peut cibler certains visiteurs et les caches servir des versions différentes. La redirection établit une exposition ; une exécution sur le poste reste à vérifier séparément.
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.
visitor_context- Contexte du visiteur reconstitué pour expliquer le ciblage ; un access.log ne contient pas toute l’empreinte du navigateur.
revision- Version du composant à relier à son historique de publication, pas à déduire du seul statut HTTP.
Deux visiteurs, deux réponses
JournalJeu synthétique : aucune règle de ciblage offensive n’est fournie.
request=R1 visitor_context=lab route=/documentation response=200 asset=main-v4.js
request=R2 visitor_context=partner route=/documentation response=200 asset=main-v4.js
browser R1 secondary_navigation=none
browser R2 secondary_navigation=https://update-demo.example/ source_script=widget.js
cdn widget.js revision=17 origin_changed=09:10 approved_change=falsePré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.
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
- Dans une capture du poste touché, suivre les scripts, leurs initiateurs et les redirections de la page habituelle. Comparer à une capture de référence faite dans un environnement autorisé.
- 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.
nginx — journal d’accès HTTP
- Où les trouver
- Sur le frontal, dans le fichier désigné par access_log ; son contenu dépend de log_format. L’hébergeur peut devoir fournir cet export.
- Quoi relever
- Du côté du site, comparer les accès et versions servies autour de l’incident. Les réponses HTTP 200 ne révèlent pas à elles seules une redirection déclenchée ensuite par JavaScript dans le navigateur.
- Accès et prérequis
- Lecture des journaux serveur. Vérifier que la route est journalisée : les temps de réponse et identifiants de requête ne figurent pas forcément dans le format configuré.
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, le gestionnaire de balises ou le déploiement du site, chercher l’auteur et la révision du composant tiers modifié. Demander ces pièces au propriétaire du site si vous ne l’administrez pas.
- 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.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- àGroupeOceanLotus
Noms et appellations : APT32
Des sites fréquentés par les cibles deviennent des pièges
ESET revient sur des campagnes associées à OceanLotus en Asie du Sud-Est. Les attaquants piratent des sites habituellement consultés par leurs cibles, une méthode appelée watering hole. Les personnes rencontrent ainsi le piège au cours de leurs visites ordinaires.
Ce qu’établit la source. Rétrospective publiée par ESET en 2026. L’entreprise rattache ces campagnes à OceanLotus, également nommé APT32 ; elle distingue cet historique des opérations plus récentes analysées dans le même rapport.
Consulter le rapport OceanLotus: From external espionage to domestic targetingESET Research · Publié le
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’aucun de ces groupes.
Si vous pensez être concerné
- Conservez l’URL et l’heure de consultation ; n’ouvrez pas de nouveau la page pour vérifier.
- Si un fichier a été exécuté, faites examiner le terminal.
- Prévenez l’exploitant par un canal distinct, sans supposer qu’il est lui-même l’attaquant.
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 — Drive-by Compromise — attack.mitre.org
- MDN — Subresource Integrity — developer.mozilla.org
