Une campagne cyber vise des utilisateurs de Microsoft 365 en compromettant les passerelles Wi-Fi d’hôtels et de centres de conférences. Derrière cette attaque se cache une leçon plus profonde : protéger une identité numérique ne consiste plus seulement à sécuriser un compte ou un nom de domaine. Il faut également protéger le chemin qui permet d’y accéder.
- Attaque invisible : des passerelles Wi-Fi compromises permettent de falsifier les réponses DNS sans infecter directement les appareils des victimes.
- Identité détournée : des domaines imitant Microsoft 365 servent à récupérer des identifiants ou à détourner certains mécanismes d’authentification.
- Confiance DNS : l’utilisateur peut saisir la bonne adresse et néanmoins dépendre d’une infrastructure de résolution compromise.
- Protection étendue : VPN full-tunnel, DNS chiffré strict, surveillance des domaines similaires et gouvernance DNS doivent être pensés ensemble.
- Enjeu stratégique : la protection d’une identité numérique doit désormais couvrir le nom, le DNS, l’authentification et les infrastructures qui les relient.
Nous avons pris l’habitude de présenter le phishing comme une erreur humaine.
Un utilisateur reçoit un mauvais lien. Il clique. Il saisit son mot de passe sur un faux site. L’attaquant récupère ses identifiants.
La campagne révélée par les chercheurs de ReliaQuest en juillet 2026 raconte une histoire différente.
Ici, aucun lien malveillant n’a besoin d’arriver dans une boîte mail. Aucun fichier n’a besoin d’être téléchargé. L’ordinateur de la victime n’a même pas nécessairement besoin d’être compromis.
Il suffit de contrôler une infrastructure que nous utilisons presque machinalement : le réseau auquel nous nous connectons.
Et derrière lui, le DNS.
C’est ce qui rend cette attaque particulièrement intéressante.
Elle nous rappelle que la confiance numérique ne repose pas uniquement sur ce que nous voyons à l’écran. Elle dépend d’une succession d’infrastructures invisibles dont nous supposons, souvent à tort, qu’elles nous conduiront toujours au bon endroit.
Une passerelle compromise peut déplacer la confiance
ReliaQuest a identifié une campagne active depuis au moins juin 2026 visant notamment des passerelles Wi-Fi utilisées dans des hôtels et des centres de conférences.
Ces équipements jouent un rôle central.
Lorsqu’un ordinateur rejoint un réseau Wi-Fi, celui-ci peut lui indiquer, via DHCP, quel serveur DNS utiliser. Ce résolveur transforme ensuite des noms compréhensibles comme un domaine Microsoft en adresses IP permettant aux machines de communiquer.
En temps normal, tout cela est transparent.
Mais si la passerelle est compromise, l’attaquant peut falsifier les réponses DNS et orienter le trafic vers son propre environnement.
La victime croit prendre la route habituelle.
Quelqu’un a simplement changé les panneaux.
Dans les cas étudiés, plusieurs domaines enregistrés par les attaquants ont notamment été utilisés pour imiter les services Microsoft :
m365-owa[.]com,owa-ms365[.]com,ms365-device[.]com,ms365-live[.]com.
Le choix de ces noms n’est évidemment pas anodin.
Ils ne cherchent pas à inventer une nouvelle identité.
Ils empruntent les codes d’une identité existante.
Microsoft. Office 365. OWA. Live. Device.
Quelques caractères suffisent pour créer une impression de légitimité.
Le nom de domaine est une interface de confiance
C’est ici que cette attaque dépasse largement le seul sujet du Wi-Fi.
Nous parlons souvent du nom de domaine comme d’une adresse, d’un actif de marque ou d’un élément de propriété intellectuelle.
C’est vrai. Mais c’est incomplet.
Un nom de domaine est également une interface de confiance entre une organisation, ses utilisateurs et ses infrastructures.
Lorsque nous voyons le domaine d’une banque, d’une administration, d’une entreprise ou d’un service numérique connu, nous lui attribuons immédiatement une partie de la confiance accumulée par cette organisation.
Les attaquants l’ont parfaitement compris. Le cybersquatting moderne ne consiste donc plus uniquement à réserver une marque pour tenter de la revendre.
Un domaine ressemblant peut servir à :
- usurper une identité,
- héberger une page de phishing,
- détourner une authentification,
- envoyer des courriels frauduleux,
- distribuer un logiciel malveillant,
- ou compléter une attaque menée à un autre niveau de l’infrastructure.
La surveillance d’un portefeuille de noms de domaine doit donc progressivement devenir une surveillance de l’environnement de nommage qui entoure l’organisation.
Autrement dit : il faut protéger ses noms, mais également regarder les noms que d’autres enregistrent autour de soi.
L’identité numérique d’une organisation ne se limite pas au nom qu’elle possède. Elle dépend aussi de sa capacité à empêcher d’autres acteurs d’exploiter la confiance attachée à ce nom.
Le véritable sujet est la chaîne de confiance
L’enseignement le plus important est peut-être ailleurs.
Une identité numérique repose aujourd’hui sur une chaîne beaucoup plus large :
nom de domaine → DNS → réseau → certificat → authentification → service → utilisateur.
Chaque maillon suppose que le précédent fonctionne correctement.
Nous pouvons sécuriser parfaitement un compte Microsoft 365 et néanmoins exposer l’utilisateur au niveau du réseau.
Nous pouvons posséder le bon domaine et laisser prospérer des dizaines de variantes trompeuses.
Nous pouvons disposer d’une infrastructure DNS correctement administrée et utiliser, lors d’un déplacement, un réseau dont nous ne contrôlons absolument pas la résolution.
La sécurité doit donc être pensée en profondeur.
C’est également pour cette raison que désigner DNSSEC comme solution universelle serait une erreur.
DNSSEC joue un rôle fondamental : il permet de vérifier cryptographiquement l’authenticité et l’intégrité de données DNS signées.
Mais DNSSEC ne protège pas à lui seul l’ensemble de la chaîne. Il n’empêche notamment pas un attaquant d’enregistrer un domaine ressemblant parfaitement valide et de l’utiliser à des fins frauduleuses.
La sécurité du DNS est une couche.
Pas une forteresse isolée.
Pourquoi utiliser simplement 8.8.8.8 ne suffit pas
La campagne met également en lumière une idée reçue intéressante.
Configurer manuellement un résolveur public reconnu ne protège pas nécessairement l’utilisateur si les requêtes DNS quittent son appareil sans chiffrement.
Une passerelle contrôlée par un attaquant peut toujours observer ou falsifier ce trafic.
ReliaQuest identifie notamment deux protections beaucoup plus robustes contre ce scénario :
- un VPN permanent configuré en full-tunnel, afin que le trafic, y compris DNS, soit envoyé vers une infrastructure de confiance avant de traverser le réseau local,
- un DNS chiffré en mode strict avec DNS-over-HTTPS ou DNS-over-TLS, sans possibilité de revenir silencieusement au DNS classique en clair.
La nuance du mode strict est importante.
Une protection qui se désactive lorsque les conditions deviennent difficiles peut précisément disparaître au moment où elle devient nécessaire.
Cette logique dépasse d’ailleurs largement le DNS.
Une infrastructure de confiance doit être conçue en considérant sa dégradation, son contournement et sa compromission.
Pas seulement son fonctionnement nominal.
L’Afrique doit intégrer le DNS dans sa réflexion sur la souveraineté
Le rapport de ReliaQuest ne documente pas une campagne spécifiquement africaine. Les infrastructures compromises identifiées se situaient notamment aux États-Unis, en Inde et en Arabie saoudite.
Mais l’architecture visée est universelle.
Hôtels, aéroports, centres de conférences, universités, espaces de coworking, établissements de santé ou réseaux invités utilisent partout des mécanismes similaires.
Il serait donc dangereux de considérer cette attaque comme une curiosité étrangère.
À mesure que les économies africaines numérisent leurs administrations, leurs banques, leurs entreprises et leurs services essentiels, la question de la confiance accordée aux infrastructures de résolution devient elle aussi stratégique.
Lorsqu’un ministère africain déploie un service numérique, lorsqu’une banque généralise ses services en ligne ou lorsqu’une entreprise utilise des solutions cloud mondiales, plusieurs questions doivent progressivement entrer dans la gouvernance :
- où sont situés les résolveurs DNS utilisés ?
- qui les exploite ?
- quelles politiques de chiffrement sont appliquées ?
- les zones critiques utilisent-elles DNSSEC ?
- les domaines d’usurpation sont-ils détectés ?
- les collaborateurs en déplacement utilisent-ils une infrastructure de confiance ?
- les dépendances DNS critiques sont-elles connues et documentées ?
La souveraineté numérique commence aussi par la connaissance de ces dépendances.
Elle ne consiste pas nécessairement à tout exploiter soi-même.
Elle consiste à savoir ce que l’on contrôle, ce que l’on délègue, à qui on le délègue et comment on continue à fonctionner lorsque cette confiance est rompue.
Les ccTLD font eux aussi partie de cette architecture
Cette réflexion concerne naturellement les extensions nationales africaines.
Un ccTLD n’est pas uniquement un suffixe permettant de créer une identité nationale sur Internet.
Il constitue une infrastructure utilisée par des entreprises, des citoyens, des administrations et parfois des services essentiels.
La qualité technique de son registre, sa résilience, sa disponibilité, sa gouvernance, le déploiement de DNSSEC et la qualité de son écosystème de registrars participent donc à un environnement de confiance beaucoup plus vaste.
La souveraineté d’un espace numérique national ne peut pas reposer uniquement sur des lois, des centres de données ou des clouds souverains.
Elle repose également sur des infrastructures beaucoup plus discrètes :
les noms, les résolveurs, les serveurs DNS, les registres, les certificats et les mécanismes permettant de savoir à qui nous sommes réellement connectés.
Passer de la protection du domaine à la protection de l’identité numérique
Pendant longtemps, la protection des noms de domaine reposait essentiellement sur quelques réflexes :
enregistrer la marque principale, réserver quelques variantes, renouveler les domaines et intervenir en cas de cybersquatting.
Cette approche reste nécessaire. Mais elle ne suffit plus.
Une stratégie moderne devrait réunir plusieurs dimensions :
- cartographier les domaines, sous-domaines et dépendances DNS critiques,
- sécuriser les zones et les mécanismes de résolution,
- surveiller les nouveaux domaines susceptibles d’usurper l’organisation,
- détecter les utilisations malveillantes associées à ces domaines,
- protéger les mécanismes d’authentification,
- organiser les procédures de réaction lorsqu’une identité est détournée.
Nous passons progressivement d’une logique de propriété à une logique de confiance.
Et cette évolution est fondamentale.
Le DNS n’est plus un sujet réservé aux techniciens
Cette attaque pourrait être résumée comme une nouvelle campagne contre Microsoft 365.
Ce serait passer à côté de l’essentiel.
Elle démontre que quelques secondes de résolution DNS peuvent déterminer vers quelle infrastructure un utilisateur, une entreprise ou une administration va accorder sa confiance.
Le DNS intervient avant la page web. Avant le formulaire de connexion. Avant l’application.
Souvent avant même que l’utilisateur commence à se poser une question de sécurité.
C’est précisément pour cette raison qu’il doit progressivement entrer dans les discussions de gouvernance, de cybersécurité et de souveraineté numérique.
L’Afrique construit aujourd’hui une partie importante de son infrastructure numérique.
Elle dispose donc d’une opportunité particulière : ne pas considérer le DNS comme une couche historique qu’il suffirait de faire fonctionner, mais comme une infrastructure de confiance qu’il faut gouverner, surveiller et renforcer.
Sur Internet, nous protégeons souvent ce que l’utilisateur voit. Le véritable enjeu est désormais de protéger également les infrastructures invisibles qui lui permettent de savoir où il se trouve et à qui il fait confiance.
- ReliaQuest Threat Research DNS Poisoning Tactics Expand to Hospitality Wi-Fi 23 juillet 2026
- IT-Connect Ils piratent le Wi-Fi des hôtels pour siphonner les comptes Microsoft 365 28 juillet 2026
- ICANN DNSSEC – What Is It and Why Is It Important?
- Microsoft Conditional Access: Authentication flows 24 mars 2026
