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
À 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
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
L’interception consiste à observer ou détourner une communication. Une attaque de l’homme du milieu, aussi appelée adversary-in-the-middle, cherche à s’interposer entre deux correspondants. Elle peut viser un réseau, une résolution de nom ou un mécanisme d’authentification. Le chiffrement protège surtout lorsqu’il vérifie aussi l’identité du destinataire : ignorer une alerte de certificat peut affaiblir cette garantie.
- 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.
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
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 ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Non. Le chiffrement et la vérification du serveur protègent ce contenu. Le tiers peut toutefois tenter une redirection ou présenter une fausse page pour vous tromper.
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 intermédiaire peut lire le trafic parce que le poste lui fait confiance
Le poste A reçoit un certificat signé par une autorité privée CorpRoot, tandis que le poste B voit une autorité publique. Cette différence peut correspondre à un proxy d’entreprise autorisé. Elle devient suspecte si une nouvelle autorité a été installée sans changement prévu ou si le trafic traverse un équipement inconnu.
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.
Éléments à croiser
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.
Limites de l’interprétation
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
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.
- 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 ?
Formulez votre décision et l’élément qui la justifie 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
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.
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
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 — 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
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.
- àCampagneSea Turtle
Détourner le DNS pour intercepter les connexions
Des enregistrements DNS modifiés dirigent les utilisateurs vers des serveurs contrôlés par les attaquants. Ceux-ci imitent les services attendus, capturent les identifiants puis transmettent la connexion au vrai service, ce qui rend le détournement discret.
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
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é
- 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 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 — Adversary-in-the-Middle — attack.mitre.org
- OWASP — TLS Cheat Sheet — cheatsheetseries.owasp.org
