Microsoft: attacchi a tema passkey compromettono account 365 con vishing e

Microsoft Security Research ha divulgato il 10 settembre 2026 due campagne di threat actors che sfruttano infrastrutture email di terze parti e ingegneria sociale a tema passkey per compromettere account Microsoft 365 e violare ambienti cloud. La campagna principale, attiva da maggio 2026, non attacca i passkey come tecnologia: usa la confusione della transizione passwordless come superficie di ingegneria sociale, inducendo le vittime a credere di dover "aggiornare" un sistema che spesso non hanno ancora adottato. Il risultato è un accesso iniziale che aggira le difese MFA tradizionali e si espande tramite abuso di API legittime, rendendo la detection particolarmente insidiosa.

Il vishing passkey: come funziona il flusso di compromissione

Il meccanismo iniziale è il voice phishing, o vishing, con un twist tematico. Secondo Microsoft Security Research, gli attaccanti contattano direttamente i dipendenti al numero di telefono personale, impersonando il reparto IT interno o un help desk esterno. Il pretesto è sempre la stessa urgenza: l'organizzazione sta migrando ai passkey, è necessario aggiornare l'autenticazione a più fattori, o c'è un problema con il single sign-on che richiede immediata verifica.

La precisione del targeting sorprende. Come ha documentato Microsoft: "The actor appears to invest heavily in pre-attack research, likely gathering information about employees and organizational structure from public sources such as social networking and professional profiling platforms". Gli attaccanti conoscono nomi, ruoli, gerarchie aziendali: non sparano nel mucchio, ma costruiscono narrazioni credibili per ogni vittima.

Da qui la vittima viene spinta verso un sito contraffatto. I domini registrati dagli attaccanti seguono pattern deliberati: sottodomini che includono il nome dell'azienda bersaglio su base generica a tema passkey, SSO o identity verification. BleepingComputer ha documentato esempi come company-name.secure-passkey[.]com, passkeyhelpdesk[.]com, setupmypasskey[.]com, integratedsso[.]com. Una volta sul sito, la vittima viene guidata attraverso due possibili flussi: un proxy AitM che intercetta credenziali e token di sessione, o un flusso device-code in cui l'utente inserisce un codice su microsoft.com/devicelogin legittimo, concedendo l'accesso alla sessione dell'attaccante.

Il passkey, in tutto questo, è solo un pretesto. Come ha precisato Microsoft, citato da BleepingComputer: "while the lures frequently revolve around passkeys, the attackers are not attempting to enroll a passkey". La tecnologia non è l'obiettivo: è il momento di transizione a essere sfruttato, il gap di comprensione tra ciò che l'utente sente dire in conferenze e ciò che effettivamente usa nel proprio flusso quotidiano.

MFA persistence: quando la difesa diventa il punto debole

Una volta ottenuto l'accesso iniziale, gli attaccanti non si muovono lateralmente con exploit o malware endpoint. Agiscono all'interno del perimetro dell'identità compromessa, sfruttando le funzionalità stesse del tenant Microsoft 365. La prima operazione è l'enrollment di nuovi metodi di autenticazione sotto controllo dell'attaccante: un numero di telefono alternativo, un'applicazione authenticator su dispositivo proprio, un token OTP software.

Questo meccanismo di persistenza è particolarmente efficace perché rende la compromissione resistente a contromisure parziali. Se la vittima nota l'accesso anomalo e cambia password, l'attaccante può comunque rientrare attraverso il metodo MFA aggiunto. Se l'amministratore resetta la password senza controllare i metodi di autenticazione registrati, la backdoor rimane attiva. Microsoft ha documentato accessi anomali a Microsoft Office Home da dispositivi unmanaged, seguiti da espansione verso SharePoint e OneDrive tramite Graph API, con sessioni attive per circa un'ora con accesso a multiple applicazioni connesse.

Il device-code phishing, in particolare, amplifica la superficie di impatto. Secondo BleepingComputer, il flusso compromesso consente accesso non solo alle risorse Microsoft 365, ma a tutte le applicazioni SSO connesse: Salesforce, Google Workspace, Dropbox, Adobe, SAP, Slack, Zendesk, Atlassian. Una singola credenziale ingannata diventa chiave per un ecosistema aziendale esteso.

Graph API abuse: il blind spot della cloud detection

La fase di esfiltrazione rivela il vero problema strutturale di questa campagna. Gli attaccanti non usano tool di transfer file anomali, non generano traffico verso IP sospetti noti, non installano malware. Usano Microsoft Graph API, la stessa interfaccia che le applicazioni legittime utilizzano per leggere email, accedere a documenti SharePoint, sincronizzare file OneDrive.

"The attack underscores a critical detection challenge: Microsoft Graph abuse rarely appears suspicious when viewed through a single API call" — Microsoft Security Research

Microsoft ha osservato attività Graph ad alto volume su tre servizi core: SharePoint Online, OneDrive for Business, e Exchange Online, tutti accessibili tramite REST API. Il pattern operativo include rotazione deliberata dell'infrastruttura IP tra autenticazione, ricognizione ed esfiltrazione, con durata complessiva dell'operazione da alcune ore a diversi giorni. Gli attaccanti si autolimitano a meno di 1000 file o email per ora, un rate che non scatta nei threshold tradizionali di anomaly detection.

L'automazione è evidente. BleepingComputer ha rilevato user agent python-httpx nelle chiamate di esfiltrazione, indicando script customizzati piuttosto interattività manuale. La ricognizione preliminare tramite Graph API è estesa: utenti, gruppi, permessi, risorse, contenuti accessibili. Gli attaccanti mappano l'ambiente prima di selezionare i target di esfiltrazione, operando con la pazienza dell'insider threat piuttosto che con la fretta del ransomware tradizionale.

Microsoft ha sottolineato l'implicazione metodologica: "This attack serves as a strong example of why Graph activity must be assessed holistically, with emphasis on behavioral progression and cross-event correlation rather than individual API requests in isolation". La sfida non è tecnica nel senso di signature o IOC: è analitica, richiedendo correlazione tra autenticazione, enrollment MFA, pattern di accesso a risorse, e sequenza temporale delle chiamate API.

Chi c'è dietro: Storm-3121, Storm-3032 e l'ombra di UNC6671

Microsoft attribuisce l'attività di initial access a due attori threat: Storm-3121, associato al collettivo ShinyHunters e al brand Falcon, e Storm-3032, noto anche come UNC6671 o Helix. La designazione "Storm" indica gruppi emergenti o in via di attribuzione consolidata nel taxonomy Microsoft; la sovrapposizione con UNC6671 suggerisce tradecraft condiviso o possibile affiliate network piuttosto che struttura unitaria.

UNC6671 è un'entità già documentata per campagne vishing con pannelli di raccolta credenziali su domini generici a tema passkey, con sottodomini specifici per targeting mirato. Microsoft ha rilevato sovrapposizioni infrastrutturali tra i domini usati in questa campagna e l'apparato phishing precedentemente associato a UNC6671, anche se non emergono evidenze che colleghino definitivamente Storm-3032 all'entità storica allo stato attuale. L'incertezza rimane: gruppo unitario, rete di affiliate, o infrastruttura condivisa tra multiple crew è non documentato nel brief.

Va sottolineata una distinzione operativa importante. Nello stesso disclosure del 10 settembre 2026, Microsoft ha documentato anche una prima campagna distinta, attiva il 3-5 agosto 2026: un'operazione di CEO impersonation con frodi ACH che ha generato circa 1 milione di email fraudolente. Quella campagna è diversa per vettore iniziale (email massiva, non vishing mirato), per obiettivo (fraud ACH, non esfiltrazione dati cloud) e probabilmente per attori. Le fonti non chiariscono se l'uso di AI generativa documentato nella prima campagna si estenda anche alla campagna passkey vishing: questa rimane un punto aperto.

Cosa fare adesso

La risposta difensiva richiede riallineamento su tre fronti, tutti derivanti dai fatti documentati da Microsoft e BleepingComputer.

Primo: il training anti-phishing deve evolversi oltre il mantra "non cliccare link sospetti". Quando l'attacco inizia con una chiamata telefonica a un numero personale, nessun link è stato ancora cliccato. La consapevolezza deve includere verifica indipendente: contattare il reparto IT tramite canale noto, mai usare i riferimenti forniti dal chiamante.

Secondo: i controlli post-autenticazione sui metodi MFA registrati devono diventare standard operativo. Review periodica dei dispositivi e dei metodi associati agli account, con alert su enrollment di nuovi authenticator o numeri telefonici non preautorizzati. Il reset password senza verifica metodi MFA è insufficiente.

Terzo: il monitoring di Microsoft Graph API deve passare da threshold isolati a analisi comportamentale sequenziale. Correlare autenticazione anomala, accesso a directory service, ricognizione utenti/gruppi, e accesso massiccio a SharePoint/OneDrive/Exchange nello stesso arco temporale. Le singole chiamate API appaiono legittime: la progressione comportamentale rivela l'attacco.

Quarto: accelerare la transizione verso MFA phishing-resistant, in particolare FIDO2 security keys, riduce la vulnerabilità ai flussi AitM e device-code che aggirano push notification, SMS e TOTP. La tecnologia esiste; il gap è organizzativo e di deployment.

Il paradosso della transizione: quando la soluzione diventa il pretesto

Questa campagna inverte la logica tradizionale del phishing delle credenziali. Non è un attacco alla password: è un attacco al momento in cui l'organizzazione cerca di eliminare la password. Gli attaccanti non compromettono i passkey, che restano più sicuri delle credenziali tradizionali; compromettono la confusione della migrazione, l'urgenza comunicativa, la pressione per essere "compliant" con una nuova policy IT.

Il settore della sicurezza informatica ha investito anni a educare gli utenti a riconoscere email sospette sui passkey. Ora deve educarli a riconoscere chi li chiama per parlare di passkey. La superficie di attacco si sposta dal canale asincrono a quello sincrono, dal testo alla voce, dal link al dialogo. Le difese devono seguire lo stesso spostamento, o la transizione passwordless rischia di essere il periodo di massima esposizione, non di massima sicurezza.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://thehackernews.com/2026/09/attackers-use-passkey-phishing-to.html
• https://www.bleepingcomputer.com/news/security/passkey-themed-phishing-attacks-lead-to-microsoft-365-data-theft/
• https://www.darkreading.com/cyberattacks-data-breaches/1m-personalized-fraud-emails-3-days
• https://cyberscoop.com/anthropic-report-ai-enabled-cyber-attacks/
• https://cyberpress.org/passkey-phishing-hijacks-microsoft-365/
• https://www.microsoft.com/en-us/security/blog/2026/05/18/storm-2949-turned-compromised-identity-into-cloud-wide-breach/
• https://thehackernews.com/2026/07/debull-tooling-abuses-microsoft-device.html
• https://thehackernews.com/2026/08/unc6671-vishing-attacks-target-personal.html
• https://thehackernews.com/2026/09/microsoft-365-attackers-use-help-desk.html
• https://thehackernews.com/2026/01/mandiant-finds-shinyhunters-using.html
• https://thehackernews.uk/trust-world-update-d