Manipulation et diffusion
Particuliers et entreprisesPiégeage d’un site fréquenté
Watering-hole attack
Un site habituellement consulté devient un point de passage piégé.
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
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 lieu numérique fréquenté par ses cibles plutôt que de contacter chacune d’elles. Le site peut rester presque identique. La confiance acquise au fil des visites rend le changement moins visible. Une simple visite n’entraîne pas toujours une infection : certains scénarios réclament un téléchargement ou une action, d’autres exploitent une faiblesse du navigateur ou d’un composant.
- 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.
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 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 ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Non. Le favori retrouve la bonne adresse, mais le vrai site peut avoir été compromis. La provenance habituelle ne suffit pas à autoriser une installation inattendue.
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
Un site habituellement fiable redirige seulement certains visiteurs
La page principale du site est inchangée, mais une nouvelle version d’un composant tiers redirige certains visiteurs vers une autre destination. L’attaquant profite ici d’un site fréquenté par sa cible. Il n’a pas besoin d’envoyer un message directement à chaque victime.
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.
Éléments à croiser
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.
Limites de l’interprétation
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
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.
- 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 ?
Formulez votre décision et l’élément qui la justifie 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
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.
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
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.
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
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- àGroupeOceanLotus
Repères de nommage : APT32
Des sites fréquentés par les cibles deviennent des pièges
ESET rappelle les campagnes de watering hole associées à OceanLotus en Asie du Sud-Est. La méthode consiste à compromettre des sites que les personnes visées ont l’habitude de consulter : le piège s’appuie sur leurs usages 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
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à 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 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 — Drive-by Compromise — attack.mitre.org
- MDN — Subresource Integrity — developer.mozilla.org
