Passkey usate come esca: ShinyHunters e Helix rubano dati Microsoft 365

🛡️ Executive Summary

• Le passkey non vengono violate: gli attaccanti usano il tema della loro registrazione per convincere le vittime a completare login AiTM o Device Code.
• Dopo l’accesso, ShinyHunters, Helix e cluster collegati enumerano Microsoft 365 tramite Graph ed esfiltrano dati da SharePoint, OneDrive ed Exchange.
• La difesa richiede passkey realmente phishing-resistant, device trust, controllo dei nuovi metodi MFA e revoca completa di sessioni e token dopo il compromesso.

Le passkey sono diventate contemporaneamente una delle migliori difese contro il phishing e una delle esche più efficaci per convincere un dipendente a consegnare l’accesso al proprio account. Microsoft ha osservato campagne collegate agli ecosistemi criminali ShinyHunters, Helix e Falcon nelle quali falsi operatori IT chiedono alle vittime di aggiornare passkey, MFA o configurazioni SSO. Il punto cruciale è che gli attaccanti non stanno violando la crittografia delle passkey. Utilizzano invece il cambiamento delle procedure di autenticazione come pretesto per indirizzare la vittima verso un proxy AiTM o un flusso Device Code legittimo, ottenere una sessione Microsoft 365 valida e procedere direttamente al furto dei dati cloud.

La passkey è l’esca ma il vero bersaglio resta la sessione Microsoft 365

Microsoft descrive una campagna attiva almeno da maggio 2026 nella quale gli operatori investono tempo nella ricognizione preliminare dell’organizzazione, individuando dipendenti, ruoli e struttura aziendale attraverso fonti pubbliche e social professionali. La vittima viene quindi contattata telefonicamente o tramite messaggio da qualcuno che si presenta come componente dell’help desk interno. La richiesta appare plausibile: aggiornare urgentemente una passkey, riallineare l’MFA o completare una nuova configurazione Single Sign-On per evitare la perdita dell’accesso aziendale. Nella ricostruzione tecnica pubblicata da Microsoft emerge però che l’enrollment della passkey non costituisce normalmente l’obiettivo reale.

L’utente viene portato verso una pagina AiTM oppure invitato a completare un Device Code Flow; nel primo caso l’attaccante intercetta credenziali e token della sessione autenticata, nel secondo convince la vittima ad autorizzare direttamente un client sotto il controllo dell’operatore criminale attraverso la vera infrastruttura Microsoft. È la stessa evoluzione degli attacchi identity-based già osservata nelle campagne PREY-0058 contro Microsoft 365, dove vishing e proxy residenziali permettevano l’esfiltrazione cloud senza malware.

I domini imitano la nuova terminologia passwordless delle aziende

La preparazione non riguarda soltanto il dipendente da contattare. Microsoft ha osservato domini costruiti appositamente attorno a termini come passkey, SSO, key synchronization, identity verification e account setup, con nomi quali secure-passkey, setupmypasskey, integratedsso o oktasession. Il nome dell’azienda bersaglio può essere inserito come sottodominio per rendere ulteriormente credibile la pagina. La tecnica sfrutta un problema di familiarità: molte imprese stanno introducendo proprio ora nuove procedure passwordless e l’utente può non sapere con precisione quale dominio, schermata o passaggio debba aspettarsi durante una registrazione reale. Microsoft ha iniziato dal 1° settembre 2026 a rendere le passkey il metodo phishing-resistant predefinito nell’esperienza Entra ID, quindi la finestra operativa scelta dagli aggressori coincide con una fase nella quale numerose organizzazioni stanno modificando concretamente i propri flussi di autenticazione. La stessa sicurezza introdotta dalle passkey diventa così materiale per il social engineering, senza che l’attaccante debba spezzare WebAuthn o impossessarsi della chiave privata.

Leggi anche: Microsoft 365 era già sotto attacco attraverso AiTM, furto delle sessioni e abuso di Windows Hello

Dopo il login gli attaccanti mappano l’intero tenant con Microsoft Graph

L’elemento più importante della nuova analisi Microsoft è ciò che avviene dopo il primo accesso. In un incidente ricostruito dalla società, un dispositivo non gestito ha effettuato l’accesso a Microsoft 365 attraverso un servizio identificato nei log Entra come OfficeHome. Dopo il completamento dell’MFA, la sessione ha iniziato in pochi minuti a interrogare My Apps, My Profile, strumenti di gestione dell’account, servizi di approvazione, SharePoint Online, Outlook Web e applicazioni aziendali interne. In un altro caso il Device Code Flow ha consegnato all’attaccante un token associato al client controllato dall’operatore, consentendo l’accesso alle risorse dell’utente senza richiedere una seconda sfida MFA. Quando l’account utilizza SSO, il raggio d’azione può inoltre estendersi oltre Microsoft 365 verso applicazioni collegate come Salesforce, Slack, Adobe, Dropbox, SAP o Atlassian.

La fase successiva viene automatizzata attraverso Microsoft Graph. Gli attaccanti enumerano utenti, gruppi, ruoli, applicazioni, service principal, metodi di autenticazione, permessi OAuth, siti SharePoint, directory OneDrive, email e allegati. Il problema difensivo è che molte delle singole richieste Graph sono del tutto normali in un ambiente enterprise. Query verso /users, /groups o /sites non costituiscono da sole un indicatore affidabile di compromissione. Diventano sospette quando la stessa identità o lo stesso token attraversano rapidamente aree differenti del tenant, controllano privilegi e metodi di autenticazione e poco dopo iniziano a scaricare documenti o messaggi. È un comportamento già evidente nelle campagne Helix e Forg365, che avevano trasformato Device Code, token e proxy AiTM in strumenti industrializzati contro Microsoft 365.

SharePoint e OneDrive vengono svuotati lentamente per ridurre gli allarmi

Una volta costruita la mappa dell’ambiente, l’obiettivo diventa l’esfiltrazione. Microsoft ha osservato volumi elevati di eventi FileAccessed e FileDownloaded su SharePoint Online e OneDrive for Business, con alcune operazioni estese anche a Exchange Online attraverso API REST. L’attività appare automatizzata e in alcuni casi utilizza python-httpx come user agent. Gli operatori non puntano necessariamente a un’esfiltrazione immediata e rumorosa: possono distribuire il download su diverse ore o giorni e mantenersi sotto 1.000 file o email all’ora, tentando di mimetizzarsi con l’attività ordinaria. Questa modalità rende meno efficace un controllo basato esclusivamente su soglie volumetriche. Diventa più utile correlare l’inizio della raccolta con eventi precedenti quali accesso da nuovo dispositivo, autenticazione da infrastruttura insolita, aggiunta di un nuovo metodo MFA e improvvisa enumerazione tramite Graph.

L’obiettivo finale è il data extortion. Non serve cifrare server né distribuire ransomware se SharePoint, OneDrive ed Exchange contengono abbastanza materiale sensibile da poter essere utilizzato per ricattare l’organizzazione. La strategia è coerente con l’evoluzione dei gruppi collegati a ShinyHunters, nei quali l’accesso iniziale tramite identità compromessa permette di saltare completamente le fasi tradizionali di deployment del malware.

Gli attaccanti registrano nuovi fattori MFA per costruire persistenza

Una sessione rubata ha una durata limitata, quindi gli operatori cercano rapidamente di trasformare l’accesso temporaneo in persistenza sull’identità. Microsoft ha osservato l’aggiunta di nuovi numeri telefonici, applicazioni Authenticator e token OTP software agli account compromessi. Una volta registrato un fattore sotto il loro controllo, gli attaccanti possono soddisfare autonomamente le successive richieste MFA senza dover richiamare la vittima. Il comportamento rappresenta uno degli indicatori più forti da monitorare: una nuova autenticazione seguita in tempi brevi dalla registrazione o modifica dei metodi MFA dovrebbe essere trattata come sequenza ad alto rischio, soprattutto se proviene da un dispositivo mai visto.

La persistenza non sopravvive però a una bonifica completa. Microsoft raccomanda, dopo un compromesso confermato, di revocare tutte le sessioni e i token, cambiare le credenziali, rimuovere i fattori di autenticazione aggiunti dagli attaccanti e obbligare l’utente a registrare nuovamente i propri metodi. Devono essere controllate anche mailbox rule, forwarding, grant OAuth e dispositivi associati. Limitarsi al cambio password può lasciare in vita precisamente gli artefatti che permettono all’operatore di rientrare.

Le passkey restano una difesa ma devono essere realmente usate

L’apparente paradosso della campagna è che Microsoft continua a raccomandare proprio le passkey phishing-resistant. Non c’è contraddizione. Una passkey FIDO2 correttamente utilizzata verifica l’origine del sito e non autentica un dominio di phishing, quindi impedisce al proxy AiTM di riprodurre lo stesso schema efficace contro password, OTP o approvazioni push. Il problema nasce quando l’utente viene convinto a non utilizzare realmente la passkey, ma a completare un’altra procedura di autenticazione presentata falsamente come parte della sua configurazione. Lo stesso vale per il Device Code Flow: la vittima opera sulla pagina autentica Microsoft, ma sta autorizzando l’applicazione dell’attaccante.

Il precedente NovaCookies aveva già mostrato come i servizi AiTM possano rubare sessioni Microsoft 365 anche dopo il completamento dell’MFA, mentre la nuova campagna aggiunge una componente psicologica più sofisticata: sfruttare proprio la transizione verso sistemi passwordless. Le organizzazioni devono quindi accompagnare il rollout tecnico con procedure estremamente riconoscibili. L’utente deve sapere se l’help desk possa chiedere una nuova registrazione, attraverso quale portale, con quali canali e soprattutto quali operazioni non debbano mai essere completate sulla base di una telefonata non richiesta.

Continua con:

• ShinyHunters ha già dimostrato come il device trust possa bloccare il furto dei dati dopo password e MFA compromessi
• Jalisco industrializza il Device Code phishing contro Entra ID e Microsoft 365

Il vero controllo deve arrivare dopo l’autenticazione

La campagna conferma infine che un login riuscito non può più essere considerato automaticamente un login affidabile. Il modello più efficace combina autenticazione resistente al phishing, Conditional Access, device compliance e analisi del comportamento successivo. Un account che si autentica correttamente ma proviene improvvisamente da un dispositivo non gestito, enumera applicazioni e privilegi, aggiunge un fattore MFA e avvia centinaia di richieste su SharePoint dovrebbe generare una risposta anche se ogni singolo passaggio utilizza API e protocolli legittimi.

Le passkey riducono radicalmente il rischio del phishing tradizionale, ma non eliminano il social engineering contro il processo di autenticazione. ShinyHunters, Helix e gli altri operatori stanno semplicemente spostando l’attacco nel punto in cui resta ancora un essere umano da convincere. La differenza decisiva è che, una volta ottenuta una sessione valida, non serve più violare Microsoft 365: sono le normali funzioni di Microsoft 365 a diventare gli strumenti con cui vengono individuati e sottratti i dati.