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

🛡️ Executive Summary

• Una campagna AiTM compromette Microsoft 365 tramite falsi messaggi vocali, proxy residenziali e sessioni rubate mantenute automaticamente ogni otto ore.
• Gli operatori cercano utenti payroll, HR e finanza, raccolgono email sensibili e preparano potenziali frodi BEC senza modificare subito gli account compromessi.
• Malware già presente su Windows può usare chiavi Windows Hello for Business senza PIN o biometria per autenticarsi a Entra ID e creare persistenza.

Tre sviluppi mostrano come Microsoft 365 ed Entra ID siano sempre più attaccati attraverso identità e sessioni anziché mediante exploit tradizionali. Arctic Wolf Labs osserva una vasta campagna di phishing Adversary-in-the-Middle che ruba sessioni Microsoft 365, usa proxy residenziali e raccoglie messaggi relativi a stipendi, fatture e pagamenti. L’attività presenta forti sovrapposizioni con i Payroll Pirates tracciati da Microsoft come Storm-2755. Parallelamente, il ricercatore Dirk-jan Mollema dimostra che malware già eseguito nella sessione Windows di una vittima può utilizzare le chiavi Windows Hello for Business senza rubarle dal TPM, trasformandole in un mezzo per autenticarsi al cloud e costruire persistenza su Entra ID.

Il phishing AiTM entra negli account Microsoft 365 senza fermarsi all’MFA

La campagna analizzata da Arctic Wolf Labs utilizza email che simulano notifiche di messaggi vocali e indirizzano la vittima verso una catena di redirect che termina su un proxy AiTM controllato dagli attaccanti. La pagina malevola non riproduce semplicemente l’interfaccia Microsoft: inoltra in tempo reale il processo di autenticazione verso il servizio legittimo, acquisendo credenziali e sessione dopo che l’utente ha completato anche il secondo fattore.

Nel solo luglio 2026 Arctic Wolf ha osservato centinaia di organizzazioni bersaglio tra Stati Uniti, Canada ed Europa, con compromissioni confermate nei settori sanitario, educativo, manifatturiero, governativo e dei servizi professionali. La tecnica prosegue l’evoluzione già vista con Kali365 e Greatness contro gli account Microsoft 365, con il device code phishing capace di conquistare account protetti da MFA e con gli attacchi che dirottano il DNS degli hotel per raggiungere Microsoft 365. La differenza fondamentale rispetto al phishing tradizionale è che l’attaccante punta alla sessione autenticata, rendendo insufficiente la semplice presenza di una MFA ancora basata su fattori suscettibili al phishing.

Google Meet, Google Ads e AWS S3 nascondono la catena di redirect

Il collegamento contenuto nell’email attraversa una sequenza di servizi legittimi prima di raggiungere l’infrastruttura criminale. Arctic Wolf ha ricostruito una catena che sfrutta Google Meet, il sistema di redirect di Google, tracker di Google Campaign Manager e Google Ads e infine un oggetto HTML ospitato su Amazon S3. Soltanto dopo questi passaggi il browser raggiunge il dominio AiTM.

L’obiettivo è aumentare la probabilità di superare filtri che attribuiscono reputazione positiva ai domini intermedi. La pagina finale esegue inoltre fingerprinting del dispositivo, raccogliendo browser, sistema operativo, dimensioni dello schermo, lingua, timezone, supporto cookie, WebDriver, vendor WebGL e altre caratteristiche del client. Recupera anche il Paese della vittima per consentire agli operatori di selezionare successivamente proxy residenziali geograficamente compatibili con l’utente compromesso. È un’evoluzione rispetto alle campagne che già utilizzano servizi affidabili come infrastruttura intermedia, fenomeno osservato con Operation BlueDash e i falsi Teams e Zoom e nelle campagne italiane rilevate dal CERT-AGID con centinaia di operazioni malevole concentrate in poche settimane. Il dominio finale può cambiare rapidamente, mentre i passaggi iniziali continuano a sembrare traffico verso infrastrutture note e normalmente consentite.

Le sessioni rubate vengono riattivate automaticamente ogni otto ore

Dopo la compromissione, gli operatori adottano una strategia particolarmente prudente. Le connessioni malevole compaiono inizialmente pochi minuti dopo il phishing attraverso un proxy residenziale localizzato nello stesso Paese della vittima; tra 11 e 24 ore più tardi iniziano accessi ricorrenti a intervalli di circa otto ore, provenienti da indirizzi IP e ASN differenti ma associati allo stesso SessionID.

Arctic Wolf ritiene che un’infrastruttura automatizzata mantenga quindi attive le sessioni compromesse indipendentemente dall’intervento manuale degli operatori. In alcuni eventi compaiono combinazioni anomale, come Outlook associato a Firefox o Python Requests, oppure browser mobili dichiarati su Windows 10. Questo comportamento differisce dal classico account takeover seguito immediatamente da modifica della password o registrazione di un nuovo metodo MFA: la maggior parte delle intrusioni resta silenziosa e si concentra su ricognizione e raccolta. Il modello deve essere letto insieme alle campagne Evilginx che aggirano l’MFA attraverso proxy di autenticazione e al phishing AI Jalisco contro gli accessi passwordless di Entra, perché conferma che IP, geolocalizzazione e singolo evento MFA non bastano più a identificare una sessione affidabile.

Payroll Pirates cerca le persone che controllano stipendi e pagamenti

Una volta ottenuto l’accesso, gli attaccanti interrogano Microsoft Graph per identificare utenti collegati a payroll, risorse umane, amministrazione e finanza. Successivamente accedono alle mailbox e cercano messaggi contenenti informazioni su stipendi, fatture, coordinate bancarie, pagamenti, benefit e documentazione interna. L’attività presenta forti sovrapposizioni con Storm-2755, cluster indicato da Microsoft come Payroll Pirates e già associato al dirottamento degli stipendi dei dipendenti verso conti controllati dagli attaccanti. Matrice Digitale aveva seguito il gruppo nell’analisi sui Payroll Pirates che dirottano i pagamenti bypassando la MFA, mentre l’uso di identità aziendali per preparare frodi finanziarie si collega alle operazioni dei cloni aziendali che sottraggono anticipi alle imprese. La nuova attività osservata da Arctic Wolf è però più discreta: nella maggior parte dei casi non vengono create immediatamente regole nella posta, inviati nuovi messaggi di phishing o modificati i metodi di autenticazione. In pochi incidenti gli operatori sono intervenuti manualmente per spostare determinate email nei messaggi eliminati e marcarle come già lette, ma il comportamento dominante rimane la raccolta silenziosa di intelligence finanziaria.

Windows Hello può essere usato dal malware senza rubare la chiave TPM

Il secondo fronte riguarda Windows Hello for Business, normalmente considerato uno dei sistemi di autenticazione resistenti al phishing più robusti dell’ecosistema Microsoft. Il ricercatore Dirk-jan Mollema dimostra però un limite importante nel suo studio sull’utilizzo delle chiavi Windows Hello per autenticazione e persistenza.

Quando l’utente è già autenticato interattivamente a Windows, il sistema utilizza un meccanismo di ticketing che mantiene disponibili alcune operazioni con la chiave privata senza chiedere nuovamente PIN o biometria. La chiave resta correttamente protetta nel TPM e non viene estratta, ma codice eseguito con i normali privilegi dell’utente può chiedere a Windows di utilizzarla per firmare dati. È coerente con quanto Microsoft documenta sul caching dei ticket di Windows Hello for Business: le chiavi Entra ID rimangono disponibili mentre l’utente è interattivamente connesso. Il rischio è diverso da quello affrontato con Pass-ta-key contro le passkey sincronizzate o dal furto tradizionale delle password: l’attaccante non deve esportare il segreto crittografico se riesce a utilizzare il sistema operativo come intermediario per farlo firmare.

Windows Hello viene trasformato in una passkey FIDO2 per Entra ID

Mollema ha esteso una tecnica già presentata nel 2024 utilizzando la chiave WHFB come credenziale FIDO2/WebAuthn. La procedura sfrutta il fatto che la challenge generata da Entra ID ha una durata di cinque minuti e, secondo la ricerca, non è vincolata alla sessione, all’utente o al tenant che l’ha richiesta. L’attaccante può quindi richiedere la challenge dalla propria infrastruttura, trasferirla sul computer compromesso e fare in modo che Windows Hello firmi l’asserzione senza richiedere nuova presenza dell’utente. L’asserzione può essere restituita all’host dell’attaccante e utilizzata attraverso ROADtools per ottenere token o una sessione browser autenticata come la vittima. Il dato più importante è che il token ottenuto tramite questo percorso non contiene il device ID: può quindi essere utilizzato, dove le policy lo consentono, per registrare un nuovo dispositivo e successivamente ottenere un Primary Refresh Token. La scoperta completa il quadro dei rischi già visto con Microsoft Self-Service Password Reset abusato per il furto di dati Azure e con le campagne che trasformano credenziali e accessi aziendali in punti di persistenza. Il requisito fondamentale resta però importante: il malware deve già essere in esecuzione nella sessione Windows della vittima.

Una credenziale phishing-resistant non protegge un endpoint già compromesso

La tecnica può soddisfare anche policy di Conditional Access che richiedono autenticazione resistente al phishing, perché Entra ID vede una autentica operazione Windows Hello/WebAuthn firmata dalla chiave legittima. L’autenticazione viene inoltre considerata una MFA recente e può, nelle configurazioni che lo permettono, consentire la registrazione di ulteriori passkey o chiavi Windows Hello sul dispositivo controllato dall’attaccante. Questo non significa che ogni tenant Entra sia automaticamente vulnerabile alla catena completa: policy che richiedono device compliance, stato gestito del dispositivo o altre condizioni legate alla macchina possono interrompere il percorso. Microsoft stessa sta spingendo gli utenti verso metodi passwordless e passkey resistenti al phishing, ma la ricerca evidenzia il limite concettuale di qualsiasi credenziale hardware quando l’endpoint che può invocarne le operazioni è già sotto controllo ostile. È una distinzione fondamentale rispetto alle campagne AiTM: le passkey e Windows Hello contrastano efficacemente il phishing remoto, ma non sostituiscono la sicurezza dell’endpoint. Il problema richiama le campagne nelle quali Midnight Blizzard sfrutta infrastrutture intermedie per raggiungere identità Microsoft e dimostra perché identity security ed endpoint detection debbano essere trattate come un unico dominio operativo.

Le difese devono correlare sessioni, dispositivi e comportamenti finanziari

I tre filoni convergono sulla necessità di abbandonare il modello nel quale un’autenticazione MFA riuscita equivale automaticamente a una sessione attendibile. Arctic Wolf suggerisce di cercare accessi ricorrenti a intervalli regolari, SessionID mantenuti attraverso IP e ASN differenti, user-agent incoerenti, query Graph rivolte a funzioni payroll e accessi improvvisi a mailbox finanziarie. Per Windows Hello, Mollema propone invece di individuare autenticazioni WHFB nelle quali il device ID risulta vuoto, tenendo conto che lo stesso comportamento può verificarsi legittimamente in browser incognito o non integrati con SSO, e di controllare registrazioni inattese di nuovi dispositivi. La guida Microsoft alla risposta agli incidenti di phishing raccomanda inoltre revoca delle sessioni e dei token, verifica dei log Entra, analisi delle modifiche alle mailbox e controllo dei dispositivi coinvolti. L’evoluzione osservata dopo il phishing Microsoft 365 basato sul Device Code Flow mostra però che il segnale più importante non è più soltanto come l’utente si autentica, ma cosa accade alla sua identità subito dopo: dove si sposta la sessione, quali API consulta, quali mailbox apre e quali nuovi dispositivi vengono associati all’account.