ReliaQuest Threat Research ha divulgato il 24 luglio 2026 una campagna di attacchi che compromette gateway Wi-Fi di hotel e centri conferenze per intercettare login a Microsoft 365. L'operazione è attiva da almeno giugno 2026 in almeno tre paesi e colpisce sei settori economici, con una variante tecnica che rende inefficaci sia le password che l'autenticazione a più fattori.
- ReliaQuest ha tracciato gateway Wi-Fi compromessi in città statunitensi, in India e in Arabia Saudita, con vittime nei settori finanziario, legale, sanitario, energetico, dei servizi professionali e del retail.
- Gli attaccanti usano il DNS poisoning su captive portal appliance per reindirizzare le richieste a Microsoft verso domini malevoli: m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com, ms365-live[.]com.
- In un sottoinsieme di casi, il device code flow OAuth consente di bypassare l'MFA senza intercettare password: la vittima inserisce su microsoft.com/devicelogin un codice generato dal dispositivo dell'attaccante, e Microsoft emette un token valido al client avversario.
- Le protezioni standard — DNS pubblico come 8.8.8.8 e DNS over HTTPS/TLS in modalità opportunistica — non bloccano l'attacco perché il gateway compromesso intercetta il traffico in plaintext prima del resolver.
Come funziona il trappolone nel captive portal
L'attacco sfrutta una posizione di man-in-the-middle che il gateway Wi-Fi occupa per definizione. Quando un ospite si connette alla rete dell'hotel, il captive portal appliance controlla la risoluzione DNS per tutti i dispositivi. Gli attaccanti, che hanno ottenuto accesso amministrativo al gateway, alterano le risposte DNS per i domini Microsoft: login.microsoftonline.com e affini risolvono verso server controllati dall'avversario invece che verso l'infrastruttura reale.
La pagina malevola replica l'interfaccia di login di Microsoft 365 con fedeltà sufficiente a catturare credenziali. Ma ReliaQuest ha documentato una seconda modalità, più insidiosa, che non richiede il furto di password. L'attaccante genera un codice di device code flow sul proprio client, poi induce la vittima a visitare microsoft.com/devicelogin — pagina autentica di Microsoft — e a inserire quel codice. Come ha riportato TechTimes citando ReliaQuest: "Multi-factor authentication was not defeated; it was used correctly — against the victim."
Il meccanismo è tecnicamente lecito: il device code flow è un percorso OAuth 2.0 progettato per dispositivi senza tastiera. Microsoft lo riconosce come vettore ad alto rischio dal 2021 e raccomanda di bloccarlo via Conditional Access. La raccomandazione resta largamente disattesa.
Il fallimento delle difese abituali
La campagna mette in luce un divario tra consapevolezza teorica e implementazione pratica. Molte aziende raccomandano ai dipendenti in viaggio di usare DNS pubblici come 8.8.8.8 o di attivare DNS over HTTPS/TLS. Secondo ReliaQuest, entrambe le contromisure sono insufficienti contro questo specifico scenario.
Il gateway compromesso intercetta le richieste DNS in plaintext prima che raggiungano qualsiasi resolver esterno. Anche il DNS over HTTPS/TLS in modalità opportunistica fallisce: il gateway può interferire con l'handshake crittografico, forzando il fallback a comunicazioni in chiaro che tornano vulnerabili al poisoning. Come ha sintetizzato SecurityAffairs citando ReliaQuest, "Two configurations do stop it": la VPN full-tunnel, che instrada tutto il traffico DNS attraverso il tunnel aziendale prima che il gateway possa toccarlo, e il DNS over HTTPS/TLS in strict mode senza fallback plaintext.
Il problema è che gran parte delle VPN enterprise usa lo split tunneling per ridurre il carico sulla rete aziendale. In quella configurazione, il traffico DNS per i servizi cloud — Microsoft 365 incluso — esce direttamente dal gateway locale, esponendolo alla manipolazione.
WPAD e il pannello di comando degli attaccanti
ReliaQuest ha osservato tentativi di abuso del protocollo WPAD (Web Proxy Auto-Discovery) in circa un terzo dei casi analizzati. Il gateway risponde a query WPAD con un file PAC malevolo che reindirizza il traffico attraverso proxy controllati dall'attaccante. Il successo effettivo di questa manovra non è stato confermato: i tentativi sono documentati, ma ReliaQuest non ha verificato che l'intercettazione proxy sia risultata produttiva.
Più significativo è il ritrovamento di un pannello di gestione sul dominio attaccante, con funzionalità di staging, rotazione delle esche, telemetria e IP allowlist. Questo indica un'operazione strutturata e continuativa, non un exploit occasionale. L'accesso iniziale ai gateway è valutato con "low-to-medium confidence" come conseguenza di interfacce di gestione esposte — SSH, SNMP, pannelli web admin — protette da credenziali deboli o riutilizzate, ma ReliaQuest non ha confermato questo vettore.
Il confronto con FrostArmada e i limiti dell'attribuzione
Le tecniche documentate da ReliaQuest richiamano una campagna precedente, nota come FrostArmada e associata ad APT28, che tra marzo e aprile 2026 compromise circa 18.000 router SOHO per DNS hijacking verso portali Microsoft falsi. Le differenze sono tuttavia decisive: FrostArmada colpì apparecchiature residenziali e di piccolo ufficio (MikroTik, TP-Link), non gateway di hotel; usava reindirizzamento DNS selettivo, mentre questa campagna impiega il reindirizzamento totale; e operava su scala numericamente diversa.
"not currently assessed to be FrostArmada itself, but shares enough tactics, techniques, and procedures to suggest tradecraft reuse at a minimum" — ReliaQuest Threat Research
L'identità degli operatori resta sconosciuta. Non emergono sovrapposizioni infrastrutturali che colleghino l'attore a gruppi attributi noti allo stato attuale, e il numero esatto di vittime o account compromessi non è quantificato nelle fonti disponibili.
Cosa fare adesso
- Disabilitare il device code flow OAuth tramite Microsoft Conditional Access, seguendo la raccomandazione che Microsoft formula dal 2021 per gli ambienti aziendali.
- Passare le VPN enterprise da split tunneling a full-tunnel per i dipendenti in viaggio, in modo che tutte le richieste DNS — non solo quelle per risorse interne — transitino attraverso l'infrastruttura aziendale protetta.
- Configurare il DNS over HTTPS/TLS in strict mode sui dispositivi mobili aziendali, eliminando il fallback a plaintext che il gateway compromesso può sfruttare per forzare la degradazione della connessione.
- Disabilitare WPAD sui sistemi gestiti aziendali, rimuovendo un vettore di proxy auto-discovery che ReliaQuest ha documentato come attivamente sondato in questa campagna.
Il paradosso del viaggiatore d'affari
La campagna ReliaQuest rivela una categoria di rischio che le policy aziendali standard non coprono efficacemente. Non serve un clic su link sospetto, non serve aprire un allegato malevolo: basta connettersi a una rete apparentemente legittima e seguire la procedura di autenticazione corretta, su pagine autentiche di Microsoft, per consegnare all'attaccante un token MFA-validato. La fiducia implicita nelle infrastrutture di ospitalità — hotel, centri conferenze, lounge aeroportuali — diventa il punto di ingresso.
Le mitigazioni esistono e sono documentate da anni. Che la maggior parte delle organizzazioni non le abbia ancora implementate suggerisce un problema di governance più che di conoscenza: il divario non è su cosa fare, ma su chi è responsabile di farlo quando il perimetro si allarga a reti che l'azienda non controlla.
Fonti
- https://www.techtimes.com/articles/321566/20260725/hotel-wi-fi-gateways-weaponized-steal-microsoft-365-logins-mfa-bypassed.htm
- https://www.foxnews.com/tech/hotel-wi-fi-phishing-attack-targets-microsoft-logins
- https://securityaffairs.com/196017/security/hackers-hijack-hotel-wi-fi-to-steal-microsoft-365-credentials.html
- https://www.bleepingcomputer.com/news/security/hackers-hijack-hotel-wi-fi-dns-to-steal-microsoft-365-accounts/
- https://cyberpress.org/weekly-cybersecurity-newsletter-roundup-july-20-24-2026/
- https://www.bleepingcomputer.com/news/security/authorities-disrupt-dns-hijacks-used-to-steal-microsoft-365-logins/
- https://www.bleepingcomputer.com/
- https://www.bleepingcomputer.com/tutorials/
- https://www.bleepingcomputer.com/download/
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.