Attori minacciosi compromettono i gateway Wi-Fi captive portal di alberghi e centri conferenze in più città statunitensi, India e Arabia Saudita per intercettare e manipolare le query DNS degli ospiti. La campagna è attiva da almeno giugno 2026. L'obiettivo non è un malware sul dispositivo, ma il controllo della rete stessa: da lì, il reindirizzamento verso pagine Microsoft 365 false consente il furto di credenziali, token di sessione e autorizzazioni OAuth, spesso aggirando l'autenticazione a più fattori senza che la vittima abbia mai cliccato un link sospetto.
- I gateway captive portal sono stati compromessi attraverso interfacce di gestione esposte con credenziali deboli o riutilizzate, in una campagna documentata da ReliaQuest Threat Research.
- Il DNS poisoning è "blunt", non selettivo: tutte le query DNS vengono dirottate verso infrastruttura malevola, non solo quelle Microsoft.
- Quattro domini identificati ospitano le pagine di phishing: m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com e ms365-live[.]com, su almeno gli IP 31.57.243[.]154 e 104.194.159[.]150.
- L'abuso del flusso device-code authentication consente di bypassare la MFA: la vittima inserisce un codice su una pagina Microsoft autentica, ma autorizza una sessione avviata dall'attaccante.
Come funziona l'attacco: il captive portal come arbitro di fiducia
Gli aggressori ottengono l'accesso iniziale ai gateway Wi-Fi attraverso interfacce di amministrazione esposte — SSH, SNMP o pannelli web — protette da credenziali deboli o riutilizzate. ReliaQuest assegna a questa ricostruzione un confidence level low-medium, data la visibilità limitata sui singoli dispositivi compromessi. Una volta sul gateway, controllano il server DHCP e il resolver DNS locale.
A differenza del DNS poisoning selettivo, questa campagna opera in modalità "blunt": ogni query DNS viene risolta attraverso infrastruttura malevola. I domini Microsoft vengono dirottati verso server controllati dagli attaccanti. La vittima apre il browser, digita outlook.office365.com e viene reindirizzata a m365-owa[.]com o a uno degli altri domini identificati. La pagina è visivamente identica al portale Microsoft.
In circa un terzo dei casi investigati, gli attaccanti hanno tentato anche l'abuso del protocollo Web Proxy Auto-Discovery (WPAD): attraverso l'opzione DHCP 252 e record DNS 'wpad' contraffatti, forzano il browser a caricare un file PAC malevolo che instrada il traffico attraverso un proxy ostile. ReliaQuest non ha potuto confermare il successo effettivo di questi tentativi di WPAD abuse.
Il bypass della MFA: il trucco del device-code flow
Il meccanismo più insidioso non è il phishing delle credenziali, ma l'abuso del flusso di autenticazione Microsoft basato su device code. L'attaccante inizia autonomamente il flusso OAuth su un dispositivo controllato. Microsoft genera un codice alfanumerico e una URL di verifica. L'attaccante presenta alla vittima — attraverso il captive portal manipolato o altri canali — una pagina che richiede l'inserimento di quel codice.
La vittima accede a login.microsoftonline.com autentico, inserisce il codice e conferma la richiesta di autenticazione. Ciò che non vede è che sta autorizzando una sessione avviata dall'attaccante. Il token OAuth, con i claim MFA inclusi, viene consegnato all'infrastruttura malevola. L'attore minaccioso ottiene accesso persistente all'account senza mai possedere password né dispositivo di secondo fattore. Secondo la citazione di ReliaQuest riportata da BleepingComputer: "What the user can't see is that approving the prompt authorizes a session initiated by the attacker".
Questo meccanismo trasforma l'MFA da ostacolo in acceleratore: il token rilasciato è già arricchito dei claim di autenticazione forte, rendendo le sessioni più difficili da rilevare per i sistemi di monitoring tradizionali.
Perché le difese DNS comuni falliscono
L'illusione di sicurezza parte dalle configurazioni standard. Molti utenti configurano manualmente resolver pubblici come 8.8.8.8 di Google, ritenendoli protettivi. Le fonti convergenti documentano il contrario: il traffico DNS verso questi indirizzi è in chiaro, transita attraverso il gateway compromesso e può essere intercettato e alterato prima di lasciare la rete locale.
Anche l'adozione di DNS over HTTPS (DoH) o DNS over TLS (DoT) nella configurazione di default degli strumenti più comuni offre protezione insufficiente. La modalità "opportunistica" — quella predefinita nella maggior parte delle implementazioni — permette il fallback al plaintext quando la risoluzione crittografata fallisce. Il gateway compromesso può forzare questo fallimento: blocca o degradare la connessione DoH/DoT, il client ricade su DNS in chiaro, il poisoning riprende.
"Two configurations do stop it. A full-tunnel VPN routes all DNS through the corporate tunnel before the gateway can touch the request. Encrypted DNS in strict mode... ensures the gateway can't forge a response" — ReliaQuest, in SecurityAffairs
Solo due configurazioni interrompono la catena: una VPN full-tunnel che instradi tutto il traffico — DNS incluso — attraverso il tunnel aziendale prima che raggiunga il gateway alberghiero; oppure il DNS crittografato in strict mode, esplicitamente configurato per non consentire mai fallback al plaintext.
Chi è nel mirino: dipendenti in viaggio, non settori specifici
I settori colpiti dall'attività rilevata sui gateway compromessi coprono servizi finanziari, professional services, legale, sanità, energia e retail. La convergenza delle fonti è chiara: non si tratta di targeting settoriale, ma di una campagna che insegue i dipendenti in viaggio ovunque si connettano. Secondo ReliaQuest, citato da BleepingComputer: "We observed traffic to these compromised gateways from organizations in a range of industries... confirming this isn't sector-specific targeting, but a campaign that highly likely goes after traveling employees wherever they connect".
Il settore hospitality emerge così come attack surface di prima classe. I captive portal gateway — tradizionalmente considerati amenity tecnologica secondaria — diventano perno di una catena di compromissione che può propagarsi all'intero tenant Microsoft 365 dell'organizzazione colpita. La responsabilità di protezione non ricade solo sull'utente finale, ma sulla postura di sicurezza dell'infrastruttura alberghiera.
Sovrapposizioni e distinzioni: il confronto con FrostArmada
Il report ReliaQuest segnala sovrapposizioni tecniche con le tattiche documentate per FrostArmada, campagna associata ad APT28, in particolare nell'uso di router compromessi come piattaforma di intercettazione. Tuttavia, due elementi distinguono questa attività: il targeting specifico di appliance captive portal nell'ambito hospitality, non documentato nei report precedenti su FrostArmada; e l'impiego del WPAD abuse come tecnica complementare.
Non emergono sovrapposizioni infrastrutturali o riutilizzo di codice che colleghino direttamente questa campagna ad APT28 allo stato attuale. L'attribuzione rimane non confermata: il TTP overlap indica affinità operative, non identità dell'attore.
Cosa fare adesso
- Imporre VPN full-tunnel sempre attiva sui dispositivi aziendali prima della connessione a qualsiasi rete Wi-Fi ospite: tutto il traffico DNS deve transitare attraverso il tunnel corporativo prima di raggiungere il gateway locale.
- Configurare DNS over HTTPS o DNS over TLS in strict mode, con fallback alplaintext esplicitamente disabilitato: il client deve rifiutare qualsiasi risoluzione non crittografata.
- Rivedere le policy di autenticazione Microsoft 365 per limitare o disabilitare il flusso device-code authentication dove non strettamente necessario, o applicare condizioni di accesso basate sulla conformità del dispositivo.
- Valutare audit periodici delle configurazioni gateway captive portal nel portfolio alberghiero e dei partner eventi, con verifica delle interfacce di gestione esposte e delle credenziali di accesso.
Il perimetro si è spostato: dalla postazione al pacchetto DNS
Questa campagna rende esplicito un paradosso della sicurezza contemporanea: il dispositivo può essere aggiornato, l'utente può essere addestrato, la MFA può essere attiva — e comunque l'account cade. Il perimetro non è più la workstation o il telefono, ma il pacchetto DNS che esce dalla scheda di rete. Chiunque controlli quel pacchetto prima che venga crittografato controlla la verità della navigazione. L'hotel non è più un luogo neutro: è un nodo di transito che può arbitrare la fiducia tra utente e servizio.
La lezione per le aziende è strutturale. Non basta distribuire laptop hardenati e licenze MFA: serve una politica di connettività che consideri ogni rete non corporativa come ostile per default, fino a prova crittografica contraria. Per il settore hospitality, la posta in gioco è la fiducia stessa del cliente business: un captive portal compromesso non ruba solo password, ma la reputazione dell'infrastruttura.
FAQ
Perché il DNS 8.8.8.8 non protegge in questo scenario?
Il traffico verso 8.8.8.8 è in chiaro e transita attraverso il gateway compromesso, che può intercettarlo e alterare le risposte prima che raggiungano il resolver di Google.
Il device-code flow è una vulnerabilità di Microsoft?
No, è un flusso OAuth legittimo progettato per dispositivi senza browser. L'abuso sfrutta la mancata verifica del contesto in cui l'utente inserisce il codice, non un difetto del protocollo stesso.
Perché opportunistic DoH/DoT non basta?
La modalità opportunistica permette il fallback a DNS plaintext quando la connessione crittografata fallisce. Il gateway compromesso può forzare artificialmente quel fallimento, inducendo il client a rivelare query in chiaro.
Fonti
- https://www.secnews.gr/en/723700/hotel-wifi-dns-microsoft-365-poisoning/
- https://www.bleepingcomputer.com/news/security/hackers-hijack-hotel-wi-fi-dns-to-steal-microsoft-365-accounts/
- https://securityaffairs.com/196017/security/hackers-hijack-hotel-wi-fi-to-steal-microsoft-365-credentials.html
- https://cyberinsider.com/hackers-use-dns-poisoning-on-hotel-wi-fi-to-steal-microsoft-365-accounts/
- https://reliaquest.com/blog/threat-spotlight-dns-poisoning-tactics-expand-to-hospitality/
- https://www.bleepingcomputer.com/
- https://www.bleepingcomputer.com/tutorials/
- https://www.bleepingcomputer.com/download/
- https://deals.bleepingcomputer.com/
- https://www.bleepingcomputer.com/vpn/
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.