Wazza colpisce banche e governi: phishing Microsoft 365 nascosto ai bot

🛡️ Executive Summary

• Wazza prende di mira organizzazioni bancarie, manifatturiere e governative negli Stati Uniti, in Europa e Australia attraverso Device Code phishing.
• Il phishkit usa controlli sulla campagna, token temporanei, telemetria del browser e redirect multipli per nascondere la pagina finale agli scanner automatici.
• Il bersaglio non è soltanto la password: l’abuso del flusso di autenticazione Microsoft sposta la difesa verso identità, sessioni e comportamento degli account.

Wazza porta il phishing Microsoft 365 un passo oltre la classica pagina falsa. Il nuovo phishkit osservato da ANY.RUN prende di mira organizzazioni bancarie, manifatturiere e governative negli Stati Uniti, in Europa e in Australia, ma il dato più importante non è il settore colpito: è il modo in cui nasconde la pagina finale ai sistemi automatici. Prima di mostrare l’esca, la campagna verifica hostname, sessione e telemetria del browser, genera token temporanei e usa più redirect. Solo dopo questi controlli la vittima raggiunge una pagina che imita Adobe Document Cloud e avvia un flusso di Device Code phishing. Il bersaglio reale diventa l’identità Microsoft 365.

Wazza filtra la vittima prima di mostrare il phishing

La ricerca originale di ANY.RUN ricostruisce una catena progettata per impedire che scanner automatici, crawler e controlli statici vedano immediatamente il contenuto malevolo. Il traffico parte da sottodomini wildcard associati alla campagna, passa per una richiesta a /api/wazza-config che controlla se l’hostname appartiene a una campagna attiva, riceve un marker attraverso infrastruttura Cloudflare Workers e ottiene quindi un token di sessione a breve durata tramite /api/mint-token. Un ulteriore passaggio verifica token e telemetria del browser prima di autorizzare i redirect intermedi /r e /meline verso la pagina finale a tema Adobe Document Cloud. Wazza non tenta soltanto di imitare un servizio legittimo: decide prima chi può vedere l’esca, riducendo l’efficacia dei sistemi che classificano un link osservando soltanto il primo livello della navigazione.

Leggi anche: N0va ruba token Microsoft 365 senza rubare password: il phishing passa dai login legittimi

Il Device Code sposta l’attacco dalla password all’autorizzazione

Una volta superati i filtri, la vittima entra in un flusso di Device Code phishing. In questo modello l’attaccante non deve necessariamente costruire una copia completa della pagina di login Microsoft né limitarsi alla raccolta diretta della password: induce l’utente a completare una procedura di autenticazione legata a un codice controllato dall’aggressore, sfruttando un processo che appartiene realmente all’ecosistema Microsoft.

La fiducia viene quindi spostata dalla pagina falsa alla procedura di autorizzazione. È il salto già osservato nei kit che hanno trasformato OAuth, device code e token di sessione in strumenti di account takeover, come ARToken ed EvilTokens contro gli account Microsoft 365. Wazza aggiunge una barriera ulteriore davanti alla fase finale, facendo sì che il ricercatore o il sistema automatico debbano riprodurre correttamente l’intera navigazione prima di poter osservare il phishing.

Banche, industria e governi sono bersagli perché vivono dentro Microsoft 365

ANY.RUN rileva attività contro organizzazioni bancarie, manifatturiere e governative negli Stati Uniti, in Europa e Australia. La selezione non sembra dipendere esclusivamente dalla verticalità economica, ma dal valore dell’identità aziendale e dalla presenza di Microsoft 365 nei processi quotidiani.

Una sessione valida può diventare il punto di partenza verso posta elettronica, documenti, applicazioni SaaS e flussi interni senza richiedere necessariamente l’esecuzione immediata di malware sull’endpoint. È la stessa economia dell’accesso che ha permesso a Kali365 e Greatness di industrializzare il furto degli account Microsoft 365: la vittima può autenticarsi davanti a un servizio apparentemente affidabile mentre l’attaccante concentra il proprio interesse sul risultato dell’autenticazione, non soltanto sulle credenziali digitate. Per una banca o un ente pubblico il rischio supera quindi la singola casella email e raggiunge l’intera identità cloud associata all’utente.

L’anti-bot rende insufficiente bloccare il primo dominio

La parte più interessante di Wazza è operativa. Se la pagina finale compare soltanto dopo una sequenza di controlli, analizzare staticamente il link ricevuto via email può non essere sufficiente a ricostruire l’intero attacco. Cloudflare Workers, marker client, token temporanei e redirect separano il punto di ingresso dal contenuto realmente pericoloso e consentono di scartare visitatori che non rispettano i parametri previsti dalla campagna.

Il SOC deve quindi osservare la navigazione come una sequenza e correlare richieste HTTP, redirect e autenticazioni. Il problema non è nuovo: il Device Code phishing contro Microsoft 365 aveva già mostrato come un flusso legittimo possa aggirare alcune delle aspettative tradizionali sulla MFA. Wazza porta questa logica dentro la detection stessa: non nasconde soltanto l’identità dell’attaccante, ma tenta di nascondere la prova dell’attacco agli strumenti che la stanno cercando.

Il vero indicatore diventa il comportamento dell’identità

Per campagne di questo tipo il controllo deve spostarsi dal solo contenuto della mail alla sequenza di autenticazione. Una richiesta Device Code inattesa, una nuova sessione, l’uso di token provenienti da contesti incoerenti o un’autorizzazione che non corrisponde al normale comportamento dell’utente possono risultare più significativi della reputazione della URL iniziale.

Bloccare i domini osservati rimane utile, ma non sufficiente quando il phishkit usa infrastrutture intermedie, token di breve durata e sistemi anti-analisi. La stessa dinamica è visibile negli attacchi che BigBear 2.0 ha utilizzato per aggirare l’MFA di Microsoft 365: quando il confine si sposta sull’identità, password e secondo fattore non sono più gli unici elementi da presidiare. La sessione autenticata diventa essa stessa un asset da difendere.

Continua con:

Microsoft smantella EvilTokens: 12.000 account violati abusando del device code

Microsoft 365 sotto attacco tra AiTM, frodi payroll e abuso di Windows Hello

Wazza trasforma il phishing in un problema di detection engineering

Wazza non dimostra una nuova vulnerabilità in Microsoft 365 e non rappresenta un bypass crittografico della MFA. Sfrutta invece un flusso legittimo di autenticazione, una sequenza di routing controllata e filtri anti-bot per rendere più difficile distinguere tempestivamente l’attività malevola.

È una differenza sostanziale: firme, blacklist e reputazione dei domini perdono efficacia quando il contenuto pericoloso viene mostrato soltanto dopo che il visitatore ha superato i controlli dell’attaccante. Campagne basate su vishing e identità cloud, come PREY-0058 contro Microsoft 365, indicano la stessa direzione. Il vantaggio operativo non consiste più soltanto nel creare pagine false più convincenti, ma nel decidere quando mostrarle, a chi mostrarle e quali sistemi automatici escludere dalla navigazione. Per i SOC il phishing diventa quindi sempre meno un problema di URL isolati e sempre più un problema di correlazione tra browser, identità e sessione.