Wi-Fi degli hotel sotto attacco: così rubano gli account Microsoft 365

La rete Wi-Fi di un hotel può purtroppo trasformarsi nel primo anello di un attacco costruito per rubare account Microsoft 365, sottrarre token di sessione e installare malware sui dispositivi dei clienti. Microsoft ha infatti ricondotto una campagna internazionale di questo tipo a Storm-2945, sottogruppo operativo di Midnight Blizzard, il collettivo russo noto anche come APT29 e associato dai governi statunitense e britannico al servizio d’intelligence estero SVR.

L’operazione, chiamata CaptiveCrunch, sfrutta un elemento familiare a chi viaggia per lavoro: il captive portal, cioè la pagina che appare quando ci si collega alla rete di un albergo, di un centro congressi o di un’altra struttura condivisa. Nata per raccogliere un consenso, un numero di camera o un indirizzo email, tale interfaccia diventa nelle mani degli aggressori un punto privilegiato dal quale manipolare il traffico.

Microsoft osserva attività riconducibili al gruppo criminale almeno da febbraio 2026, inizialmente attraverso campagne di phishing basate sui flussi OAuth e sui codici dispositivo. Dall’inizio di maggio gli attacchi hanno però cominciato ad assumere una forma più invasiva: compromissione delle infrastrutture Wi-Fi, modifica delle risposte DNS e HTTP, pagine Microsoft contraffatte, falsi aggiornamenti e distribuzione di malware.

Perché il captive portal offre agli aggressori una posizione ideale

Quando un computer si collega a una rete Wi-Fi, Windows, Android, iOS e gli altri sistemi operativi eseguono controlli automatici per capire se la connessione Internet risulta disponibile o se occorre completare una procedura di registrazione. Il gateway può intercettare tali richieste e presentare la pagina di accesso della struttura ricettiva: è un comportamento normale, ma presuppone che l’infrastruttura della struttura sia integra.

Nel caso di CaptiveCrunch, gli aggressori conquistano una posizione adversary-in-the-middle: si collocano lungo il percorso seguito dal traffico e decidono dove indirizzare alcune richieste. Microsoft non ha ancora stabilito con certezza il vettore iniziale usato per compromettere i sistemi di gestione. La presenza di apparecchiature e piattaforme amministrative comuni tra strutture differenti lascia però ipotizzare un accesso a servizi condivisi, fornitori o componenti centralizzati, anziché una lunga serie di intrusioni isolate.

ReliaQuest, azienda americana specializzata in tecnologie per la sicurezza informatica, aveva indicato anche scenari più tradizionali: interfacce amministrative SSH, SNMP o web esposte su Internet, credenziali deboli, firmware vulnerabili oppure pannelli non aggiornati. Una volta ottenuti i privilegi di amministrazione, modificare gli indirizzi dei server DNS distribuiti ai client o alterare le risposte del gateway diventa relativamente semplice.

Perché impostare 8.8.8.8 non risolve il problema

Un consiglio ricorrente suggerisce di configurare manualmente un DNS pubblico, per esempio Google 8.8.8.8 o Cloudflare 1.1.1.1, quando non ci si fida della rete locale. Nel caso preso in esame, la misura può risultare insufficiente.

Le normali interrogazioni DNS viaggiano spesso in chiaro sulla porta 53 UDP o TCP: il gateway compromesso può intercettarle e falsificare la risposta prima ancora che le richieste di risoluzione dei nomi di dominio raggiungano il resolver pubblico scelto dall’utente. In pratica, il computer crede di aver interrogato 8.8.8.8, ma riceve un pacchetto costruito dall’infrastruttura ostile.

Una protezione più robusta richiede l’uso di DNS cifrati in modalità rigorosa tramite DNS over HTTPS o DNS over TLS, con un client configurato per non ripiegare silenziosamente sul DNS tradizionale quando il servizio sicuro non risponde. Windows 11, ad esempio, consente di abilitare l’uso di DNS over HTTPS a livello dell’intero sistema operativo.

Nemmeno l’uso del protocollo HTTPS elimina ogni rischio: un aggressore non può generare facilmente un certificato valido per login.microsoftonline.com, ma può indirizzare la vittima verso un dominio simile dotato di un proprio certificato TLS legittimo. Il lucchetto indica soltanto che la comunicazione con quel dominio risulta cifrata; non certifica che il sito appartenga davvero a Microsoft.

Gli artefici della campagna CaptiveCrunch usavano nomi di dominio come m365-owa[.]com, owa-ms365[.]com, ms365-device[.]com e ms365-live[.]com: nomi progettati per sembrare plausibili a una lettura frettolosa.

Dal furto della password all’abuso del codice dispositivo

La versione più semplice dell’attacco presenta una copia del portale Microsoft 365 e raccoglie nome utente, password e altri dati inseriti dalla vittima. CaptiveCrunch comprende però una tecnica più insidiosa, basata sul device code flow di Microsoft Entra ID.

Il flusso del codice dispositivo nasce per autenticare apparecchi privi di una tastiera completa o di un browser adatto, come smart TV, terminali a riga di comando e dispositivi IoT. L’applicazione richiede a Microsoft un codice temporaneo; l’utente apre da un altro apparecchio una pagina Microsoft autentica, inserisce il codice e approva l’accesso.

L’aggressore avvia la procedura per proprio conto, poi convince la vittima a inserire il codice generato per la sessione ostile: completando l’operazione, la vittima autorizza il client dell’attaccante, che riceve un token OAuth valido.

La tecnica non “viola” l’autenticazione a due fattori: ne aggira lo scopo attraverso l’ingegneria sociale. L’utente conferma personalmente la richiesta sbagliata, convinto che serva per accedere alla rete dell’hotel o ripristinare la connessione. L’inserimento di questo passaggio dentro un captive portal rende la richiesta più credibile rispetto a un messaggio ricevuto via email.

Vi ricordate la truffa della ballerina su WhatsApp? L’approccio utilizzato dagli autori di CaptiveCrunch è molto simile.

ClickFix trasforma un falso controllo in esecuzione di codice

Microsoft ha scoperto una terza diramazione della campagna. Alcune pagine simulano aggiornamenti del browser, riparazioni di Windows, verifiche antivirus o problemi di rete e mostrano istruzioni che spingono l’utente a eseguire manualmente un comando.

È la tecnica ClickFix della quale abbiamo già ampiamente parlato: invece di sfruttare una vulnerabilità software, si induce la vittima a copiare e incollare codice in una finestra PowerShell, nel Prompt dei comandi, nel Terminale di Windows o più semplicemente nella finestra di dialogo Esegui richiamabile con Windows+R.

L’approccio funziona perché molti utenti associano il captive portal a un piccolo inconveniente tecnico. Una schermata che afferma di dover aggiornare il browser o riparare un driver prima di ottenere l’accesso a Internet può sembrare plausibile, soprattutto dopo un volo, durante una conferenza o mentre si tenta di partecipare a una riunione urgente.

Va detto però che nessuna rete Wi-Fi legittima dovrebbe chiedere di avviare PowerShell, rundll32.exe, mshta.exe o uno script copiato negli appunti. Allo stesso modo, un hotel non deve distribuire aggiornamenti di Windows, certificati, codec, strumenti antivirus o utility per sistemare i driver. Gli aggiornamenti vanno avviati dalle impostazioni del sistema operativo, dal Microsoft Store o dal meccanismo integrato nel browser.

Microsoft ha trovato inoltre indicazioni relative ad Android: alcune pagine ClickFix offrivano un file APK. Su uno smartphone aziendale, l’installazione manuale di un pacchetto proveniente dal (falso) portale Wi-Fi dovrebbe far scattare immediatamente un allarme.

CornFlake: un RAT in Go nascosto dietro un falso aggiornamento

Il principale impianto persistente usato nella campagna si chiama CornFlake. Si tratta di un trojan di accesso remoto (RAT) scritto in Go, sviluppato in più varianti e dotato di funzioni che vanno ben oltre il semplice furto di password.

CornFlake registra un servizio chiamato svchost32, con il nome visualizzato Cloud Sync Service e una descrizione che parla di sincronizzazione con un provider cloud. L’obiettivo consiste nel confondersi con i normali componenti Windows, senza copiare esattamente il nome svchost.exe e rischiare anomalie troppo evidenti.

Il malware usa quindi servizi Windows, chiavi Run del Registro e attività pianificate; una routine watchdog controlla gli elementi e tenta di ripristinarli quando un amministratore o un prodotto di sicurezza ne rimuove uno.

Le capacità del componente malevolo includono accesso remoto, keylogging tramite Raw Input API, controllo degli appunti, cattura dello schermo, registrazione audio con Windows Audio Session API e acquisizione di immagini dalla webcam attraverso Media Foundation. Il RAT può inoltre sorvegliare le unità USB, cercare documenti in tempo reale e inviare file classificati per estensione: archivi, immagini, sorgenti, database, email e chiavi crittografiche.

Particolarmente delicato è il modulo dedicato ai browser: Microsoft segnala funzioni derivate da ChromeKatz, capaci di estrarre cookie dalla memoria dei processi Chromium e recuperare password dai database locali.

Il malware effettua anche una ricognizione dettagliata: software installati, prodotti antivirus ed EDR, esclusioni di Microsoft Defender, livello UAC, cronologia RDP, documenti recenti di Office, appartenenza al dominio, caratteristiche hardware e presenza di webcam o microfono.

ChocoShell punta a cookie, token Microsoft 365 e credenziali Wi-Fi

Accanto al RAT compare ChocoShell, uno stealer PowerShell eseguito interamente in memoria. CornFlake garantisce il controllo persistente del computer; ChocoShell concentra invece le proprie funzioni sulla raccolta rapida di password, cookie, token Single Sign-On (SSO), credenziali delle reti wireless e materiale utile per accedere ai servizi cloud.

Lo script tenta innanzitutto di ostacolare l’analisi: manipola Antimalware Scan Interface, evita alcuni comandi PowerShell facilmente riconoscibili e usa controlli temporali per individuare sandbox o macchine virtuali.

Per le operazioni più invasive servono privilegi amministrativi: ChocoShell prova tre tecniche di bypass UAC in sequenza. Se nessun metodo funziona, può mostrare la normale richiesta di elevazione con Start-Process -Verb RunAs.

Una volta acquisiti privilegi elevati, lo stealer accede alle chiavi di cifratura dei profili Chromium, usa token appartenenti a processi SYSTEM e tenta di leggere database SQLite bloccati tramite condivisione, copia diretta o snapshot del Volume Shadow Copy Service.

ChocoShell cerca anche token di accesso e informazioni conservate in cache: per un’impresa, il rischio supera il furto della casella email. Replicare una sessione SSO, per un aggressore remoto, può significare aprire SharePoint, OneDrive, Teams, applicazioni Azure e risorse collegate all’identità Entra. Le password Wi-Fi, invece, sono estratte con il comando netsh wlan show profile con l’opzione key=clear.

Come ridurre il rischio durante un viaggio

La misura più efficace resta evitare la rete dell’hotel quando si devono consultare dati aziendali critici. Un hotspot personale, una eSIM dati o un collegamento cellulare gestito riducono l’esposizione all’infrastruttura locale.

Quando il Wi-Fi condiviso risulta indispensabile, un tunnel VPN full always-on deve attivarsi prima di consentire l’accesso alle risorse aziendali. “Full tunnel” significa che tutto il traffico, non soltanto quello diretto alla rete interna, attraversa il canale cifrato.

Molti captive portal devono essere raggiunti prima che la VPN possa collegarsi: durante quella breve fase bisogna evitare l’uso di credenziali aziendali, download e comandi suggeriti dalla pagina. Completata la registrazione, il tunnel va attivato immediatamente.

ReliaQuest ha rilevato anche tentativi di sfruttare WPAD, la funzione con cui Windows e alcune applicazioni cercano automaticamente le impostazioni di un proxy. In pratica, il sistema prova a individuare nella rete un host chiamato wpad e a scaricare da lì un file PAC, cioè uno script che stabilisce attraverso quale proxy instradare le connessioni web.

Un aggressore che controlla il DNS o il gateway dell’hotel può rispondere a tale ricerca e fornire un file PAC manipolato, facendo passare parte del traffico della vittima attraverso un proxy sotto il proprio controllo. ReliaQuest ha osservato il comportamento in circa un terzo dei casi analizzati, senza però riuscire a dimostrare che il dirottamento sia andato sempre a buon fine.

Le immagini nell’articolo sono tratte da “CaptiveCrunch: Midnight Blizzard targets travelers worldwide for malware delivery and credential theft” (Microsoft)