Réseaux et infrastructures
Particuliers et entreprisesInterception par un adversaire intermédiaire
Adversary-in-the-Middle — AiTM
Un tiers s’interpose sur le trajet d’une communication.
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
Sur un réseau compromis, un intermédiaire tente de lire ou de modifier les échanges entre une personne et un service. Si les protections cryptographiques sont correctement vérifiées, se placer sur le trajet ne suffit pas à lire les contenus.
Comment cela fonctionne
Une interception consiste à observer ou détourner une communication. Dans une attaque dite de l’homme du milieu, ou adversary-in-the-middle, un tiers s’interpose entre deux correspondants. Il peut agir sur le réseau, sur la recherche de l’adresse d’un site ou sur l’authentification. Le chiffrement protège la communication lorsqu’il vérifie aussi l’identité du destinataire. Ignorer une alerte de certificat peut affaiblir cette protection.
- Un tiers se place sur le trajet
Réseau, résolution ou relais.
- Il tente d’observer ou modifier
Le chiffrement validé limite ses capacités.
- Les échanges peuvent être détournés
Selon les protections et la confiance.
Les signes qui doivent attirer l’attention
- Des alertes de certificat apparaissent sans changement prévu.
- La passerelle ou la résolution réseau change de façon inattendue.
- Une connexion habituelle exige une procédure ou un certificat inhabituel.
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
Ne contournez pas une alerte de certificat pour accéder à un compte sensible. Changez de connexion et signalez le réseau et le message d’erreur au responsable.
Si vous êtes responsable du service ou de l’organisation
Maintenez les équipements réseau et la gestion des certificats. Recherchez les modifications de passerelle ou de résolution en les comparant aux changements autorisés.
Être connecté au même Wi-Fi ne permet pas automatiquement de déchiffrer une connexion HTTPS correctement validée.
À vous de décider
Un tiers est sur le même Wi-Fi. Lit-il automatiquement le contenu d’une connexion HTTPS correctement vérifiée ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Le chiffrement et la vérification de l’identité du serveur protègent les échanges. Le tiers peut toutefois tenter de vous rediriger ou d’afficher une fausse page.
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 intermédiaire peut lire le trafic parce que le poste lui fait confiance
Le poste A reçoit un certificat signé par l’autorité privée CorpRoot, alors que le poste B voit une autorité publique. Un proxy d’entreprise autorisé peut expliquer cet écart. Vérifiez toutefois l’installation imprévue d’une autorité ou le passage par un équipement inconnu : ces changements rendent la situation suspecte.
Avec TLS, un intermédiaire ne peut pas simplement lire une connexion correctement vérifiée. Il doit notamment obtenir une position de confiance, provoquer une dégradation du protocole ou compromettre une extrémité. Une autorité ajoutée au magasin du poste peut lui permettre de présenter des certificats acceptés par certaines applications. Toutes les applications ne consultent pas forcément le même magasin ; certaines imposent leurs propres contraintes.
L’enquête doit donc relier le chemin réseau, la chaîne de certificats et l’historique de configuration du poste. Une capture chiffrée ne révèle pas à elle seule les données lues par le proxy. Pour déterminer l’exposition, retrouver les services traversés, la période concernée et les capacités de l’intermédiaire, puis renouveler les sessions ou secrets effectivement menacés.
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
Résolution du service
Poste client vers Résolveur / réseau
Trace réponse et résolveur
- Action
Connexion via proxy
Poste client vers Proxy intermédiaire
Trace configuration PAC
- Réponse
Certificat présenté
Proxy intermédiaire vers Poste client
Trace chaîne et racine
- Action sur place
Validation locale
Poste client
Trace racine ajoutée
- Action
Nouvelle connexion TLS
Proxy intermédiaire vers Service HTTPS
Trace deux segments distincts
- Réponse
Réponse du service
Service HTTPS vers Proxy intermédiaire
Trace contenu transporté
- Réponse
Réponse relayée
Proxy intermédiaire vers Poste client
Trace périmètre exposé
Comment repérer cette attaque
Indices à rechercher
Rechercher les installations de certificats racines, les changements de proxy et les avertissements TLS qui ne correspondent pas aux configurations approuvées.
Quelles informations comparer
Rapprocher la chaîne observée du magasin de confiance du poste et d’un éventuel proxy d’inspection autorisé. Noter le réseau utilisé lors de chaque observation : changer de réseau change parfois légitimement le chemin.
Ce que ces indices ne permettent pas de conclure
Un émetteur différent n’est pas une preuve d’interception malveillante : renouvellement, CDN ou inspection d’entreprise sont possibles. Une validation TLS réussie prouve la confiance du poste dans cette chaîne, pas la légitimité de son installation.
Comment réagir
Retirer la configuration ou la racine illicite après préservation, rétablir le chemin réseau et traiter l’agent ayant modifié le poste. Révoquer les sessions exposées selon les données réellement transportées. Ne pas désactiver la validation TLS pour rétablir artificiellement le service.
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.
- Vérifier qu’un certificat non approuvé est refusé par le navigateur et les clients métier.
- Comparer les magasins de confiance et paramètres proxy après correction.
- Confirmer qu’une rotation légitime de certificat ne déclenche pas à elle seule une conclusion d’interception.
À vous de raisonner
Deux postes voient des autorités de certificat différentes pour le même service. Est-ce une preuve suffisante d’interception malveillante ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Non : l’un peut utiliser un proxy d’entreprise autorisé. Vérifiez le chemin réseau, les magasins de confiance et les changements de configuration. Une autorité ajoutée sans autorisation est une piste à examiner ; la différence seule ne permet pas de déterminer les données effectivement lues.
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.
chain_verified=true- La vérification réussit dans le contexte de confiance du poste du cas ; cela n’identifie pas qui a ajouté la racine.
actor=unknown- Limite assumée : le scénario n’attribue pas la modification faute d’audit.
Deux chemins vers un même service
JournalL’émetteur seul ne suffit pas ; comparer aussi la chaîne validée et le magasin de confiance.
poste A host=service.example peer=10.0.0.8 issuer=CorpInspection root=CorpRoot
poste B host=service.example peer=203.0.113.8 issuer=PublicCA root=PublicRoot
poste A trust_store_change=08:41 actor=unknown root_added=CorpRoot
inventaire proxy_authorized=false endpoint=A
HTTP diagnostic: scheme=https hostname_verified=true chain_verified=truePré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 — sécurité de la connexion
- Où les trouver
- Dans les outils de développement, ouvrir le panneau Privacy and security / Security selon la version, puis afficher le certificat de l’origine concernée. Conserver ses détails avec l’URL, l’heure et le réseau utilisé.
- Quoi relever
- Conserver, avec l’URL et l’heure, les informations du certificat présenté au navigateur : sujet, émetteur, chaîne et empreinte. Comparer depuis un accès de confiance sans ignorer les avertissements TLS.
- Accès et prérequis
- Observation du navigateur concerné ou capture conservée. Un certificat récupéré aujourd’hui ne reconstitue pas nécessairement la chaîne présentée pendant l’incident.
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
- Auprès de l’administrateur du poste et du réseau, demander l’historique des certificats racines déployés et des réglages proxy/VPN. Comparer ces changements aux politiques de l’organisation.
- 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.
- àCampagneSea Turtle
Détourner le DNS pour intercepter les connexions
Les attaquants modifient des enregistrements DNS pour envoyer les utilisateurs vers leurs propres serveurs. Ils y imitent les services attendus et capturent les identifiants, puis relaient la connexion au vrai service pour rendre le détournement moins visible.
Ce qu’établit la source. Cisco Talos nomme cette campagne Sea Turtle et estime avec une confiance élevée qu’elle relève d’un acteur soutenu par un État. Le rapport de 2019 ne nomme pas cet État.
Consulter le rapport DNS Hijacking Abuses Trust In Core Internet ServiceCisco Talos · 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é
- Interrompez l’opération sensible et passez par une connexion fiable.
- Signalez les alertes et notez le réseau utilisé.
- Évaluez les données et sessions réellement exposées avant de modifier les accès depuis un appareil sûr.
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 — Adversary-in-the-Middle — attack.mitre.org
- OWASP — TLS Cheat Sheet — cheatsheetseries.owasp.org
