Le bande di vishing usano telefoni personali per violare Microsoft 365 senza toccare i dispositivi aziendali

Gli attori delle minacce chiamano e inviano SMS ai dipendenti sui loro telefoni personali, spacciandosi per il personale IT interno per sottrarre identità e sessioni di autenticazione Microsoft 365. Una volta entrati, usano interfacce cloud legittime per mappare gli ambienti aziendali ed estrarre silenziosamente dati da SharePoint, OneDrive ed Exchange.

L’attività è stata segnalata il 10 settembre 2026. Microsoft monitora queste campagne rivolte ai dispositivi personali da maggio e tiene traccia degli operatori con i nomi Storm-3032 e Storm-3121.

La tecnica è particolarmente pericolosa perché la prima fase avviene al di fuori della visibilità di molti strumenti di sicurezza aziendali. Gli aggressori non devono necessariamente compromettere un laptop gestito, distribuire malware o inviare un messaggio attraverso il sistema di posta elettronica dell’azienda.

Sfruttano invece la fiducia del dipendente.

L’attacco inizia al di fuori del perimetro aziendale

Gli obiettivi includono dirigenti, amministratori e dipendenti con privilegi elevati in Microsoft 365. Account di questo tipo possono esporre più utenti, gruppi, siti, applicazioni, autorizzazioni, comunicazioni e file aziendali rispetto all’identità di un dipendente ordinario.

L’aggressore contatta il numero di cellulare personale della vittima tramite una chiamata o un SMS. Fingendosi il servizio di help desk dell’organizzazione, sostiene che il dipendente debba aggiornare un’impostazione di autenticazione, altrimenti rischierà di perdere l’accesso ai servizi di lavoro.

I pretesti più comuni includono:

• Registrazione o sostituzione di una passkey
• Modifica di una configurazione MFA
• Aggiornamento delle impostazioni di single sign-on
• Ripristino di un accesso all’account che si presume interrotto

La vittima riceve quindi un link che conduce a una pagina contraffatta di accesso Microsoft. I domini malevoli possono combinare il nome del datore di lavoro con termini legati all’autenticazione, seguendo schemi come company[.]add-passkey[.]com.

La campagna può utilizzare un sistema di phishing adversary-in-the-middle, o AiTM, per intercettare le credenziali e i token di sessione autenticati. Può inoltre abusare dell’autenticazione tramite codice dispositivo, convincendo la vittima ad autorizzare una sessione avviata altrove dall’aggressore.

In un numero più limitato di casi, gli operatori usano un account di un dipendente compromesso per contattarne un altro. I messaggi provenienti da un’identità interna familiare possono rendere più credibile la richiesta di autenticazione.

Il telefono può rimanere completamente integro. L’attacco riesce perché l’utente segue istruzioni fraudolente e completa un’azione di autenticazione legittima a favore della persona sbagliata.

Perché il BYOD crea una lacuna nel monitoraggio

I gateway di posta aziendali, le piattaforme di endpoint detection and response e i controlli sui browser gestiti potrebbero non vedere mai l’esca originale. La chiamata o l’SMS arriva su un dispositivo personale che non è registrato nell’infrastruttura di sicurezza dell’organizzazione.

Per gli investigatori, questo significa partire da una posizione difficile. Le prime prove potrebbero consistere nel ricordo del dipendente di una conversazione telefonica o di un SMS, anziché in un’e-mail conservata, un avviso dell’endpoint o un allegato acquisito.

Gli addetti alla risposta devono quindi collegare quella segnalazione agli eventi successivi relativi all’identità e al cloud. I dati di telemetria rilevanti includono:

• Accessi insoliti
• Tentativi di autenticazione tramite codice dispositivo
• Utilizzo di token da posizioni o client imprevisti
• Modifiche ai metodi di autenticazione registrati
• Registrazione di nuovi dispositivi MFA
• Enumerazione tramite Microsoft Graph
• Accesso a SharePoint, OneDrive o Exchange
• Download ripetuti di piccole quantità di dati dai repository cloud

Dopo aver assunto il controllo di un’identità, l’aggressore può registrare un dispositivo MFA sotto il proprio controllo. Questo passaggio garantisce la persistenza e può far apparire gli accessi successivi più coerenti con il normale utilizzo dell’account.

Un divieto generalizzato delle configurazioni bring-your-own-device non risolverebbe completamente il problema. La debolezza risiede soprattutto nei flussi di autenticazione, nelle autorizzazioni degli account e nella fiducia degli utenti, non nel malware in esecuzione sul telefono del dipendente.

Microsoft Graph trasforma un’identità rubata in uno strumento di ricognizione

Dopo l’autenticazione, è stato osservato che Storm-3032 e Storm-3121 usano l’API Microsoft Graph per esaminare gli ambienti Microsoft 365. Graph è un’interfaccia programmatica standard, quindi gli aggressori non devono installare strumenti di ricognizione all’interno della rete aziendale.

A seconda delle autorizzazioni dell’identità compromessa, le richieste Graph possono rivelare:

• Utenti e gruppi
• Siti SharePoint
• Applicazioni e altre risorse
• Posizioni dei contenuti
• Diritti di accesso e relazioni tra autorizzazioni
• Altri dettagli di configurazione di Microsoft 365

Le richieste a endpoint come /users, /groups e /sites non sono intrinsecamente malevole. Le aziende e le applicazioni autorizzate li usano regolarmente, riducendo così il valore degli avvisi basati su una singola chiamata API.

Conta più il modello di attività che l’endpoint.

Un utente o un’applicazione che interroga improvvisamente numerose parti dell’ambiente, segue una sequenza insolita di richieste di enumerazione o combina attività di ricognizione con comportamenti di autenticazione sospetti merita un’indagine. Le baseline devono tenere conto del ruolo di ciascuna identità, perché un’attività Graph normale per un account di automazione può essere altamente anomala per un dirigente.

Gli aggressori usano questo inventario per individuare file, messaggi e percorsi di accesso di valore. Microsoft ha osservato il furto di dati da SharePoint, OneDrive ed Exchange, oltre che da repository Microsoft 365 più ampi.

L’esfiltrazione è progettata per non attirare l’attenzione. Anziché scaricare un archivio di grandi dimensioni in un’unica operazione, gli attori recuperano periodicamente piccoli lotti di dati nell’arco di un periodo prolungato. In questo modo possono eludere le soglie incentrate su improvvisi volumi di trasferimento e confondersi con il normale utilizzo del cloud.

Gli access broker potrebbero cedere gli account a bande di estorsori

Microsoft ritiene che gli operatori possano vendere o trasferire gli accessi acquisiti a gruppi di estorsione attivi nelle fasi successive, tra cui ShinyHunters. Tuttavia, nessuna violazione aziendale nota è stata attribuita direttamente a una di queste campagne di accesso iniziale.

Questa distinzione limita le conclusioni che si possono trarre al momento. L’attività osservata dimostra l’esistenza di un percorso concreto verso la ricognizione, l’accesso persistente e il furto di dati, ma non dimostra che Storm-3032 o Storm-3121 abbiano causato una specifica intrusione resa pubblica.

Il potenziale impatto aziendale resta significativo. Un’identità compromessa di amministratore o dirigente potrebbe esporre comunicazioni interne, documenti sensibili, relazioni organizzative e configurazioni di sicurezza. L’accesso potrebbe inoltre favorire successive attività di estorsione, se le informazioni rubate venissero usate per fare pressione sull’azienda vittima.

Non si tratta di una vulnerabilità software. Non esistono un CVE associato, una versione di prodotto interessata, una patch di sicurezza o una scadenza CISA Known Exploited Vulnerabilities. La campagna abusa dell’ingegneria sociale, di funzioni di autenticazione valide, di autorizzazioni eccessive e delle lacune nel monitoraggio del cloud.

Il report sui risultati di Microsoft descrive le campagne come una minaccia a livello di identità, non come una compromissione che richieda il controllo di un endpoint aziendale.

Le difese devono seguire l’identità tra dispositivi e servizi cloud

La raccomandazione centrale di Microsoft è rendere obbligatoria la MFA resistente al phishing per ogni accesso. Se applicata correttamente all’utente preso di mira, dovrebbe impedire questa catena d’attacco, anziché limitarsi a generare un’ulteriore richiesta che il chiamante possa convincere la vittima ad approvare.

Le organizzazioni dovrebbero inoltre bloccare l’autenticazione tramite codice dispositivo ovunque non esista una necessità operativa documentata. Se alcuni flussi di lavoro la richiedono, i criteri di Conditional Access dovrebbero limitare chi può usare il flusso, da quali dispositivi e a quali condizioni.

Altre misure prioritarie includono:

1. Limitare le applicazioni sensibili ai dispositivi gestiti. Applicare questo controllo dove il valore dei dati giustifica il costo operativo.
2. Ridurre le autorizzazioni Microsoft Graph. Utenti e applicazioni dovrebbero ricevere solo gli ambiti necessari alle rispettive funzioni.
3. Monitorare le modifiche ai metodi di autenticazione. Le nuove registrazioni MFA successive a chiamate, SMS o accessi insoliti devono essere esaminate immediatamente.
4. Correlare i dati di telemetria relativi a identità e cloud. Eventi di autenticazione tramite codice dispositivo, attività dei token, query Graph e download sono più rivelatori quando vengono analizzati insieme.
5. Rilevare l’esfiltrazione a basso volume. Il monitoraggio deve esaminare gli accessi cumulativi e ripetuti, non solo i grandi trasferimenti singoli.
6. Esaminare gli account privilegiati. Il principio del privilegio minimo riduce la quantità di informazioni e contenuti disponibili dopo la compromissione di un’identità.
7. Definire una procedura di verifica per l’help desk. I dipendenti devono disporre di un canale affidabile per confermare richieste inattese relative a passkey, MFA o SSO.

La formazione dovrebbe concentrarsi su una regola chiara: un chiamante non richiesto non deve mai indirizzare un dipendente verso un’autenticazione tramite un link ricevuto sul telefono personale. Gli utenti devono interrompere la conversazione e contattare l’IT attraverso un numero interno o un portale conosciuto.

Interrompere la chiamata è solo il primo livello di difesa. I responsabili della sicurezza devono anche partire dal presupposto che alcuni dipendenti seguiranno le istruzioni e adottare controlli in grado di contenere la conseguente compromissione dell’identità prima che la ricognizione tramite Graph si trasformi in un furto di dati prolungato.