Détournement DNS Wi-Fi hôtel : comment les hackers dérobent vos comptes Microsoft 365 (et comment s'en protéger)

« Nous avons observé du trafic vers ces passerelles compromises provenant d’organisations de divers secteurs, notamment les services financiers, les services professionnels, le juridique, la santé, l’énergie et la vente au détail - confirmant qu’il ne s’agit pas d’un ciblage sectoriel, mais d’une campagne qui vise très probablement les employés en déplacement partout où ils se connectent. » - ReliaQuest

Imaginez-vous installé dans le hall d’un hôtel d’affaires, ouvrant votre ordinateur portable pour consulter vos emails professionnels. Vous vous connectez au Wi-Fi, tapez l’adresse de votre portail Microsoft 365, et une page de connexion familière apparaît. Vous entrez vos identifiants, validez une double authentification, et tout semble normal. Pourtant, sans le savoir, vous venez de remettre les clés de votre compte à un attaquant. C’est le scénario cauchemardesque que dévoile une campagne de détournement DNS Wi-Fi hôtel qui sévit depuis au moins juin 2026, selon les chercheurs de ReliaQuest. Cette attaque, qui cible les voyageurs d’affaires, a déjà compromis des comptes Microsoft 365 dans des secteurs aussi variés que la finance, la santé ou l’énergie. Dans cet article, nous allons décortiquer le mode opératoire, comprendre pourquoi les mesures de sécurité classiques échouent, et surtout, vous donner les clés pour vous protéger efficacement.

Comment fonctionne le détournement DNS des routeurs d’hôtel ?

L’accès initial aux équipements Wi-Fi

Le premier maillon de la chaîne d’attaque est l’obtention d’un accès administrateur aux passerelles Wi-Fi des hôtels et centres de conférence. Les chercheurs de ReliaQuest n’ont pas pu déterminer avec certitude comment cet accès est obtenu, mais ils avancent plusieurs hypothèses plausibles :

• Interfaces de gestion exposées : de nombreux routeurs et points d’accès possèdent des interfaces d’administration (SSH, SNMP, panneaux web) accessibles depuis le réseau local, voire depuis Internet, avec des mots de passe par défaut ou faibles.
• Vulnérabilités non corrigées : les équipements réseau des hôtels sont souvent gérés par des prestataires externes et rarement mis à jour, laissant la porte ouverte à des exploits connus.
• Ingénierie sociale : un employé de l’hôtel peut être piégé pour divulguer des identifiants, ou un attaquant peut se faire passer pour un technicien.

« L’attaquant aurait pu exploiter des interfaces de gestion faiblement protégées et exposées, ou des vulnérabilités. » - ReliaQuest

La modification des paramètres DNS

Une fois que l’attaquant dispose des droits administrateur, il modifie les serveurs DNS configurés sur la passerelle Wi-Fi. Normalement, le routeur redirige les requêtes DNS vers un résolveur légitime (par exemple, celui du fournisseur d’accès). En modifiant cette configuration, l’attaquant fait pointer les requêtes vers des serveurs DNS qu’il contrôle. Ces serveurs répondent alors avec des adresses IP frauduleuses pour des domaines spécifiques, notamment ceux de Microsoft 365 (login.microsoftonline.com, etc.).

Le leurre : des pages de phishing Microsoft 365 parfaitement imitées

Les chercheurs ont identifié au moins quatre domaines enregistrés par les attaquants pour héberger leurs pages de phishing :

• m365-owa[.]com
• owa-ms365[.]com
• ms365-device[.]com
• ms365-live[.]com

Ces domaines imitent de manière convaincante les véritables pages de connexion Microsoft 365. Lorsqu’un utilisateur, après s’être connecté au Wi-Fi de l’hôtel, tape l’adresse de son portail Microsoft 365, sa requête DNS est redirigée vers l’un de ces sites frauduleux. La page qui s’affiche est quasiment identique à l’originale, et l’utilisateur, sans méfiance, saisit ses identifiants.

Le contournement de l’authentification multi-facteurs (MFA)

Ce qui rend cette attaque particulièrement redoutable, c’est la capacité à contourner l’authentification multi-facteurs (MFA). Dans certains cas, les chercheurs ont observé un flux d’authentification par code d’appareil (device-code authentication flow). Concrètement, l’utilisateur est redirigé vers une page Microsoft 365 factice qui lui demande d’approuver une demande de connexion sur son appareil (par exemple, en saisissant un code affiché à l’écran sur son téléphone).

« Ce que l’utilisateur ne peut pas voir, c’est que l’approbation de la demande autorise une session initiée par l’attaquant. » - ReliaQuest

En approuvant cette demande, l’utilisateur délivre un jeton OAuth légitime à l’attaquant, sans que celui-ci n’ait besoin de voler les identifiants ni d’intercepter des jetons d’accès. L’authentification multi-facteurs est ainsi totalement neutralisée : l’utilisateur a bien validé une deuxième étape, mais celle-ci bénéficie à l’attaquant.

Pourquoi les mesures de sécurité classiques sont inefficaces

L’utilisation de DNS publics (8.8.8.8) ne suffit pas

Une idée reçue veut que le fait de configurer manuellement un serveur DNS public comme Google (8.8.8.8) ou Cloudflare (1.1.1.1) protège contre ce type d’attaque. En réalité, c’est faux. Les chercheurs de ReliaQuest expliquent que la passerelle Wi-Fi compromise peut forger les requêtes DNS en texte clair avant qu’elles n’atteignent le résolveur choisi. Ainsi, même avec un DNS public, la redirection frauduleuse a lieu.

Le WPAD : une surface d’attaque supplémentaire

Dans environ un tiers des cas étudiés, les attaquants ont également exploité le mécanisme Web Proxy Auto-Discovery (WPAD). Ce protocole permet aux navigateurs de détecter automatiquement un fichier de configuration de proxy (PAC) sur le réseau. En répondant à la requête WPAD avec un fichier malveillant, l’attaquant peut rediriger tout le trafic HTTP/HTTPS via un proxy qu’il contrôle. Bien que ReliaQuest n’ait pas confirmé le succès de cette technique dans les cas observés, elle représente une surface d’attaque supplémentaire préoccupante.

Les VPN d’entreprise classiques ne sont pas toujours suffisants

De nombreux employés utilisent un VPN d’entreprise pour se protéger sur les réseaux publics. Cependant, si le VPN est configuré en mode split-tunnel (seul le trafic destiné au réseau d’entreprise passe par le VPN, le reste va directement sur Internet), les requêtes DNS vers des sites publics comme Microsoft 365 peuvent être détournées avant d’être encapsulées dans le tunnel VPN. Seul un VPN en mode full-tunnel (tout le trafic passe par le VPN) garantit que les requêtes DNS sont résolues par le serveur DNS de l’entreprise, à l’abri des manipulations locales.

Tableau comparatif : mesures de protection face au détournement DNS Wi-Fi hôtel

Comment se protéger : étapes actionnables pour les entreprises et les voyageurs

Face à cette menace, les entreprises et leurs employés en déplacement doivent adopter une approche en couches. Voici les mesures concrètes recommandées par les experts de ReliaQuest et les bonnes pratiques du secteur.

1. Utiliser un VPN full-tunnel avec DNS chiffré en mode strict

C’est la mesure la plus efficace. Configurez votre VPN d’entreprise pour qu’il tunnelise tout le trafic, y compris les requêtes DNS. Activez également le DNS chiffré (DoH ou DoT) en mode strict dans le navigateur et le système d’exploitation. Cela empêche la passerelle locale de forger les réponses DNS.

2. Désactiver le flux d’authentification par code d’appareil (Device Code) dans Microsoft Entra ID

Ce flux est rarement nécessaire pour les utilisateurs standards. Sa désactivation coupe la route au contournement MFA utilisé par les attaquants. Dans le portail Azure AD, désactivez « Allow device code flow » dans les paramètres d’authentification.

3. Désactiver WPAD sur les postes de travail

Sur Windows, vous pouvez désactiver WPAD via les paramètres Internet ou la stratégie de groupe. Sur macOS, via les options réseau. Cela empêchera l’exploitation de ce protocole pour rediriger le trafic.

4. Former les utilisateurs à la vigilance

• Vérifier systématiquement l’URL dans la barre d’adresse avant de saisir des identifiants.
• Ne jamais approuver une demande de connexion Microsoft 365 qui n’a pas été initiée par soi-même.
• En cas de doute, se connecter via un réseau de confiance (point d’accès mobile personnel, VPN full-tunnel).

5. Auditer les logs pour détecter les anomalies

Les équipes sécurité doivent surveiller les connexions suspectes, notamment celles provenant d’adresses IP inhabituelles (hôtels, centres de conférence). ReliaQuest recommande de vérifier les logs de connexion Microsoft 365 pour repérer les authentifications réussies depuis des réseaux non corporatifs.

6. Appliquer une politique de sécurité stricte pour les déplacements

• Exiger l’utilisation du VPN full-tunnel pour toute connexion à des ressources d’entreprise.
• Fournir aux employés des points d’accès 4G/5G sécurisés (jetons de roaming) pour les déplacements critiques.
• Interdire l’utilisation des réseaux Wi-Fi publics non sécurisés pour l’accès aux données sensibles.

Exemple concret : le cas d’une entreprise de services financiers

Imaginons une société de conseil financier basée à Paris, dont un consultant séjourne dans un hôtel d’affaires à New York. Il se connecte au Wi-Fi de l’hôtel pour consulter ses emails et accéder à la plateforme de gestion de portefeuille. Le routeur de l’hôtel a été compromis. Lorsque le consultant tape outlook.office.com, sa requête DNS est redirigée vers m365-owa[.]com. La page de phishing s’affiche, il entre ses identifiants et valide la demande de code d’appareil sur son téléphone. En quelques secondes, l’attaquant obtient un jeton OAuth valide pour le compte Microsoft 365 du consultant. Il peut alors lire tous les emails, télécharger des documents confidentiels, et même se faire passer pour le consultant auprès de ses collègues ou clients. Le lendemain, l’entreprise découvre que des données sensibles sur des fusions-acquisitions ont fuité. Ce scénario, bien que fictif, illustre la réalité des risques, à l’instar du premier ransomware orchestré par un agent IA, auxquels sont exposées les entreprises.

Ce que disent les experts : l’avis de la communauté cybersécurité

« Cette campagne n’est pas un ciblage sectoriel, mais une menace systémique pour tous les employés en déplacement. » - ReliaQuest

Les chercheurs de ReliaQuest comparent cette activité aux campagnes attribuées au groupe russe APT28 (Fancy Bear), connu pour ses attaques contre les routeurs. Bien que les commanditaires de cette campagne ne soient pas encore identifiés, la sophistication technique et le ciblage des voyageurs d’affaires suggèrent un acteur étatique ou un groupe cybercriminel très organisé.

L’ANSSI (Agence nationale de la sécurité des systèmes d’information) rappelle régulièrement l’importance de sécuriser les connexions nomades. Dans son guide de recommandations de sécurité relatives aux déplacements professionnels, elle préconise l’utilisation systématique d’un VPN et la vérification des certificats des sites web. Cependant, cette attaque montre que même ces mesures ne suffisent pas si le VPN n’est pas configuré en full-tunnel.

Conclusion : anticiper plutôt que subir

Le détournement DNS Wi-Fi hôtel est une menace bien réelle qui cible les maillons faibles de la chaîne de sécurité : les employés en déplacement et les réseaux d’accès publics. Les techniques utilisées - modification des paramètres DNS, phishing Microsoft 365, contournement de MFA via device code - sont à la fois simples et redoutablement efficaces. La bonne nouvelle, c’est que des mesures de protection contre l’essor des ransomwares amplifiés par l’IA générative existent. En adoptant un VPN full-tunnel, en désactivant les flux d’authentification superflus et en formant vos utilisateurs, vous réduisez considérablement les risques. La vigilance ne suffit pas : il faut une architecture de sécurité qui résiste même lorsque l’utilisateur commet une erreur. N’attendez pas que votre prochain voyageur d’affaires tombe dans le piège pour agir. Revoyez dès aujourd’hui votre politique de sécurité pour les déplacements, et assurez-vous que chaque employé dispose des outils et de la formation nécessaires pour se connecter en toute sécurité, où qu’il soit.

Pour approfondir, consultez les rapports de ReliaQuest sur cette campagne, les recommandations de l’ANSSI sur les déplacements professionnels, et la documentation Microsoft sur la désactivation du flux Device Code.