Microsoft: vishing sui telefoni personali dei dipendenti per violare M365

Microsoft Security Research sta tracciando almeno due threat actor — Storm-3032 e Storm-3121 — in campagne di vishing attive da maggio 2026. Gli attaccanti chiamano o inviano SMS direttamente ai telefoni personali dei dipendenti, impersonando l'IT help-desk interno, per indurre autenticazione su pagine di phishing controllate e rubare credenziali e session token di Microsoft 365.

La novità tattica non sta nel phishing in sé, ma nel blind spot investigativo che ne consegue: il telefono personale del dipendente è un dispositivo BYOD (Bring Your Own Device) su cui l'azienda non ha visibilità. Quando l'unica prova dell'intrusione è il ricordo di una telefonata, il rilevamento tradizionale — EDR, gateway email, log di rete — resta muto.

Il vettore BYOD: perché il telefono personi è il percorso di minore resistenza

La catena di attacco inizia su un canale che le difese aziendali non possono monitorare: il telefono cellulare personale del dipendente. Microsoft Security Research documenta che gli attaccanti "phishingano i dipendenti chiamandoli o scrivendo SMS sui loro dispositivi personali" [Fonte 1]. Il pretesto è sempre un aggiornamento urgente — passkey, multifactor authentication o single sign-on — necessario per evitare la perdita di accesso agli account aziendali.

La pagina di phishing replica il Microsoft sign-in, ospitata su domini come company[.]add-passkey[.]com [Fonte 1]. Qui si innesca il meccanismo AiTM: l'attaccante intercetta credenziali e, in alcuni casi, completa flussi di device code phishing che bypassano l'autenticazione tradizionale. In scenari documentati, account già compromessi vengono utilizzati per phishingare colleghi via Microsoft Teams, estendendo lateralmente l'accesso [Fonte 1].

Il BYOD crea un'asimmetria strutturale. L'azienda controlla endpoint managed, email gateway, web proxy e EDR; non controlla il telefono del dipendente, né le chiamate vocali che riceve, né i link su cui clicca al di fuori dei canali aziendali. Come nota Robert Coles di Black Duck: "Le organizzazioni otterranno più valore rafforzando i controlli su identità e autenticazione che cercando di eliminare il BYOD. Restringere l'uso di dispositivi personali può ridurre qualche rischio, ma non è realistico per la maggior parte delle organizzazioni e non avrebbe fermato l'ingegneria sociale descritta qui" [Fonte 1].

"In molte indagini, il ricordo del dipendente di una telefonata o di un messaggio di testo diventa la prova più antica e a volte l'unica che spieghi come il compromesso sia iniziato" — Microsoft Security Research (via Dark Reading) [Fonte 1]

AiTM, device code e la persistenza silenziosa tramite MFA attacker-registrata

Il nucleo tecnico dell'attacco si articola in due tecniche convergenti. L'adversary-in-the-middle (AiTM) permette di catturare non solo le credenziali, ma i session token attivi, bypassando l'autenticazione a più fattori senza necessità di compromettere l'infrastruttura MFA legittima [Fonte 1]. Parallelamente, i device code phishing flows sfruttano flussi di autenticazione alternativi meno visibili agli utenti.

Critico per la persistenza: una volta ottenuto l'accesso, gli attaccanti registrano un proprio numero di telefono, app authenticator o token OTP software-based sotto l'identità compromessa. Microsoft definisce questo meccanismo una "durable persistence mechanism" [Fonte 2]. Il risultato è che l'attaccante mantiene accesso duraturo anche se la vittima cambia password, poiché il secondo fattore è ora sotto il suo controllo.

Help Net Security chiarisce che, "nonostante il frequente uso di esche tematizzate passkey, l'enrollment passkey non è spesso l'obiettivo vero dell'attore. Invece, la narrazione passkey serve come pretesto convincente" per guidare le vittime attraverso flussi AiTM o device-code authentication [Fonte 2]. Il passkey è il travestimento, non il fine.

L'abuso della Graph API: quando le API legittime diventano armi

Dopo la compromissione iniziale, gli attaccanti migrano verso l'abuso della Microsoft Graph API. Questa interfaccia, legittima e ampiamente utilizzata, consente di enumerare utenti, gruppi, siti, permessi, ruoli amministrativi e metodi di autenticazione registrati [Fonte 1, Fonte 2]. Singole chiamate a endpoint come /users, /groups o /sites appaiono innocue: sono operazioni quotidiane in ambienti enterprise.

Come osserva Microsoft: "L'abuso della Graph API appare raramente sospetto quando visto attraverso una singola chiamata API. Le richieste a endpoint come /users, /groups, o /sites sono comuni in ambienti enterprise" [Fonte 1]. Il segnale d'intrusione emerge solo da pattern comportamentali progressivi, non da eventi isolati.

La fase di esfiltrazione si realizza tramite accessi elevati a file e download da SharePoint Online, OneDrive for Business e Exchange Online, utilizzando REST APIs [Fonte 2]. Il ritmo è calibrato: gli attaccanti si autoimpongono un limite inferiore a 1.000 file o email all'ora, una soglia che mantiene il traffico mescolato all'uso normale dell'account [Fonte 2]. L'user agent python-httpx indica accesso automatizzato ad alto volume, confermando l'orchestrazione programmatica [Fonte 2].

Microsoft Security Research sottolinea: "Questo attacco serve come forte esempio del perché l'attività Graph debba essere valutata olisticamente, con enfasi sulla progressione comportamentale e sulla correlazione cross-evento piuttosto che su singole richieste API isolate" [Fonte 2].

Attribuzione: Storm-3032, Storm-3121 e la galassia dell'estorsione

Microsoft Threat Intelligence attribuisce l'attività di accesso iniziale a due actor specifici. Storm-3121 alimenta operazioni di estorsione ShinyHunters e Falcon. Storm-3032, evoluto dal gruppo BlackFile, opera autonomamente sotto il nome Helix [Fonte 2]. Entrambi convergono sul medesimo modello di business: accesso iniziale tramite vishing, monetizzazione tramite estorsione o rivendita.

Arctic Wolf traccia parallelamente il cluster PREY-0058, con tattiche sovrapponibili — vishing targeting executive, uso di residential proxy NodeMaven — ma non conferma identità tra questo cluster e Storm-3032/3121 [Fonte 8]. La relazione precisa resta non determinata: stesso gruppo, affiliate indipendenti, o convergenza tattica senza coordinamento operativo.

Fonte 4 documenta un cluster separato, UNC3753, con escalation fisica in uffici legali e finanziari americani. Sebbene anch'esso utilizzi tattiche vishing, si differenzia per settore target, metodi di accesso (RMM piuttosto che AiTM/device code) e assenza di collegamento con i gruppi Microsoft. Non va confuso con la campagna Storm.

Cosa fare adesso

• Bloccare i device code flows per gli scenari di autenticazione non necessari: Microsoft indica questa restrizione come mitigazione prioritaria contro la catena di attacco documentata [Fonte 1].
• Richiedere MFA phishing-resistant su dispositivi managed, riducendo la superficie di attacco dei flussi di autenticazione su endpoint non controllati dall'organizzazione [Fonte 1].
• Valutare la Graph API olisticamente, con enfasi su progressione comportamentale e correlazione cross-evento, piuttosto che su soglie statiche per singola chiamata API [Fonte 2].
• Rivedere i metodi di autenticazione registrati per identità sensibili: la registrazione non autorizzata di dispositivi MFA rappresenta il meccanismo di persistenza chiave documentato nella campagna [Fonte 2].

Il blind spot che le difese tradizionali non colmano

La campagna Storm-3032/3121 espone un fallimento architetturale della cybersecurity aziendale: la sovrapposizione tra identità lavorativa e dispositivo personale crea una zona grigia senza log né visibilità. L'attaccante non compromette reti né installa malware: convince l'utente, cattura token, opera interamente dentro le API legittime.

Il rilevamento post-compromissione è reso estremamente difficile dalla tripla caratteristica dell'attacco: canale iniziale non monitorato (telefono personale), persistenza indistinguibile da uso legittimo (MFA attacker-registrata), operatività nel rumore normale delle API (Graph con rate limiting autoimposto). La difesa si sposta inevitabilmente dalla rete all'identità, dal dispositivo al comportamento.

Microsoft non ha quantificato il numero di organizzazioni interessate né collegato breach specifici a queste campagne [Fonte 1]. Il dato mancante non attenua la rilevanza tattica: il modello è replicabile, scalabile, e sfrutta una dipendenza strutturale — il BYOD — che nessuna organizzazione realisticamente eliminerà.

Fonti

• https://www.darkreading.com/threat-intelligence/voice-callers-exploit-byod-microsoft-365-corporate-data
• https://www.helpnetsecurity.com/2026/09/10/microsoft-365-social-engineering-personal-phones/
• https://nvd.nist.gov/vuln/detail/cve-2026-21509
• https://securityaffairs.com/193315/cyber-crime/unc3753-escalates-from-vishing-calls-to-physical-office-intrusions-at-us-legal-and-financial-firms.html
• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-21509
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-21509
• https://www.helpnetsecurity.com/2025/05/06/social-engineering-human-behavior/
• https://www.helpnetsecurity.com/2026/09/08/vishing-microsoft-365-data-theft-extortion/

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

Fonti