Threat Landscape: Vishing contro Identity & SaaS

Mandiant (Google Cloud Threat Intelligence) ha identificato una campagna di vishing attiva e in rapida escalation, attribuita a threat actor correlati al sindacato criminale ShinyHunters e tracciati sotto i cluster UNC6661, UNC6671 e UNC6240. La campagna è attiva da gennaio 2026 e ha colpito organizzazioni enterprise in più settori verticali.

Il vettore è puramente sociale: gli attaccanti impersonano personale IT interno tramite telefonate, convincono i dipendenti a inserire credenziali SSO e codici MFA su portali di phishing costruiti ad hoc, e ottengono sessioni autenticate sulle piattaforme SaaS aziendali senza sfruttare alcuna vulnerabilità software.

Il finding centrale di questo advisory è che la campagna bypassa qualsiasi protezione MFA non phishing-resistant, TOTP, push, SMS. Nessun aggiornamento software risolve il vettore. L'unico meccanismo che neutralizza il portale clone è FIDO2/Passkey, che verifica crittograficamente il dominio prima di rilasciare il token di autenticazione.

Chi sono i ShinyHunters

ShinyHunters è un sindacato criminale emerso pubblicamente nel maggio 2020, con motivazione finanziaria e operatori anglofoni e francofoni. In sei anni ha attraversato tre fasi operative distinte, con una traiettoria che va dalla vendita di database rubati fino all'ingegneria sociale su scala enterprise.

• Fase 1: Data Broker (2020–2022). Il gruppo si afferma su BreachForums vendendo database contenenti credenziali, dati PII e informazioni finanziarie. In due settimane dal suo esordio pubblico vende oltre 200 milioni di record sottratti a Tokopedia e Unacademy. Tra il 2021 e il 2023 colpisce Microsoft, AT&T, Wattpad e Santander, accumulando oltre un miliardo di record esfiltrati.
• Fase 2: Cloud Extortion (2023–2024). Il gruppo pivota verso le piattaforme cloud. La campagna Snowflake del 2024 porta alla compromissione di Ticketmaster (560 milioni di record), AT&T (110 milioni di metadati di chiamate, con pagamento di 370.000 USD in bitcoin) e Santander Bank (30 milioni di clienti). Il modello operativo diventa "pay or leak": esfiltrazione di dati sensibili e richiesta di riscatto sotto minaccia di pubblicazione.
• Fase 3: Vishing e RaaS (2025–oggi). Il gruppo abbandona progressivamente lo sfruttamento tecnico e adotta l'ingegneria sociale come vettore primario. Lancia il brand autonomo "shinysp1d3r" con un modello RaaS che coinvolge affiliati terzi. Nel 2025 colpisce PowerSchool (62 milioni di studenti, 9,5 milioni di insegnanti, 6.505 distretti scolastici), LVMH, Kering, Qantas. Nel 2026 la campagna vishing enterprise diventa il vettore dominante.

La direzione di questa evoluzione è controintuitiva: un gruppo tecnicamente capace di compromettere infrastrutture cloud a livello infrastrutturale ha scelto di diventare più semplice, non più complesso. Il perimetro tecnico si è indurito abbastanza da rendere l'essere umano il percorso di minore resistenza.

Kill chain dettagliata

Fase 1: Ricognizione e preparazione

Gli attaccanti conducono una fase OSINT strutturata sulla struttura organizzativa della vittima: stack tecnologico, nomi del personale IT e helpdesk, fornitori di identità in uso. Sulla base di queste informazioni registrano domini typosquat con il branding della vittima, seguendo pattern ricorrenti come companyname-sso.com o ithelp-companyname.com. Il portale clone replica con precisione logo, colori e struttura della pagina di login SSO originale.

Fase 2: Vishing

L'attaccante chiama il dipendente target impersonando il supporto IT interno o un vendor (Okta, Microsoft). Il pretesto standard è la segnalazione di attività sospetta sull'account. Il dipendente viene tenuto in linea durante tutto l'attacco per impedire qualsiasi verifica indipendente. Il tono è professionale, la voce credibile, il branding coerente con l'identità impersonata.

Fase 3: Credential e MFA harvest in tempo reale

Le credenziali inserite dal dipendente sul portale clone vengono ritrasmesse in tempo reale sul portale SSO legittimo. Il flusso operativo è il seguente:

Il flusso operativo è il seguente:

• Vittima → inserisce credenziali su portale clone → Attaccante cattura le credenziali
• Attaccante → usa le credenziali sul portale legittimo → riceve la MFA challenge
• Vittima → inserisce il codice MFA sul clone → Attaccante usa il token
• Attaccante → sessione autenticata attiva prima della scadenza del codice

Il relay in tempo reale rende inutili tutti i meccanismi MFA basati su shared secret: OTP, TOTP e push notification. Solo FIDO2/WebAuthn verifica crittograficamente il dominio, rendendo il portale clone tecnicamente inerte anche in possesso delle credenziali corrette.

Fase 4: Device enrollment e accesso persistente

Con la sessione attiva, l'attaccante registra un dispositivo controllato nel tenant della vittima tramite Okta Device Trust o Microsoft Entra Registered Device. Questo garantisce accesso persistente alle risorse cloud anche dopo la scadenza della sessione originale, indipendentemente da eventuali reset delle credenziali che non includano la rimozione esplicita dei dispositivi registrati.

Fase 5: Esfiltrazione e monetizzazione

L'attaccante procede con esportazioni bulk di email, file, dati CRM e comunicazioni interne. Per le istanze Salesforce è documentato l'uso di tool derivati da Aura Inspector per esportazioni massive senza attivare i controlli DLP. I dati vengono utilizzati per estorsione diretta o rivenduti su forum underground.

Indicatori di compromissione

La campagna non lascia tracce di exploit sui log di sistema o sui WAF. Gli unici segnali visibili sono anomalie comportamentali. I detection use case prioritari sono i seguenti:

• Login da nuovo device combinato con geolocalizzazione anomala sullo stesso account
• Device enrollment inatteso successivo a un reset MFA
• Download massivo da SharePoint, OneDrive o export Salesforce nelle 72 ore successive a un reset credenziali
• Token OAuth emessi a lungo termine per applicazioni cloud non precedentemente autorizzate

Organizzazioni prive di UEBA o Conditional Access con policy stringenti risultano cieche rispetto a questo pattern.

Mitigazioni prioritarie

Protezione dell'identità

MFA phishing-resistant (FIDO2/Passkey hardware). Eliminare SMS, push notification e OTP come fattori primari di autenticazione. FIDO2 è l'unico meccanismo che verifica crittograficamente il dominio, rendendo i portali clone tecnicamente inoffensivi. Questa è l'azione di maggiore impatto e deve essere considerata prioritaria.

Audit degli enrollment MFA attivi. Rimuovere dispositivi sospetti o non riconosciuti nei tenant Okta, Azure AD e Google Workspace. Configurare alert automatici su ogni nuovo device enrollment, con approvazione esplicita richiesta per qualsiasi registrazione successiva a un reset delle credenziali.

Conditional Access Policy. Richiedere device compliance e coerenza della geolocalizzazione prima di concedere accesso alle risorse cloud. Bloccare l'accesso da Paesi non operativi per l'organizzazione.

Verifica obbligatoria delle richieste MFA. Introdurre un processo di callback via canale separato prima di qualsiasi reset MFA, con verifica dell'identità del richiedente attraverso un secondo canale indipendente dalla chiamata in corso.

Rilevamento e risposta

SIEM e UEBA. Implementare il rilevamento di login anomali cross-platform, nuovo device e nuova geolocalizzazione sullo stesso account in finestre temporali ravvicinate.

Least privilege e segmentazione. Limitare l'accesso a CRM, email e file share ai soli utenti autorizzati per funzione operativa. Ridurre la superficie di esfiltrazione in caso di compromissione dell'identità.

Conservazione dei log. Okta System Log, Azure AD Sign-in Logs e Salesforce Event Log devono essere conservati per un minimo di 12 mesi e integrati nel SIEM con alert attivi sulle anomalie di comportamento.

Piano di risposta agli incidenti. In caso di compromissione confermata: revocare immediatamente tutte le sessioni attive, rimuovere i dispositivi registrati, reissue delle credenziali con FIDO2, analisi del lateral movement su API, OAuth token, SharePoint, OneDrive e Salesforce export nelle 72 ore precedenti alla rilevazione.

Simulazioni di vishing. Condurre esercitazioni mirate ai team IT, HR e Finance, che rappresentano i ruoli più frequentemente colpiti. La simulazione deve includere scenari di impersonificazione di vendor e supporto tecnico interno.

Note sull'attribuzione

I cluster UNC6661, UNC6671 e UNC6240 sono tracciati da Mandiant come distinti ma operativamente correlati all'ecosistema ShinyHunters. L'attribuzione definitiva non è pubblica al momento dell'emissione di questo advisory. I dati quantitativi sulle vittime si basano sulla reportistica pubblica disponibile e devono essere considerati stime conservative.

Fonti

• Mandiant / Google Cloud Threat Intelligence — analisi campagna vishing 2026
• Cybernews — ShinyHunters link to SSO vishing attacks on Okta
• The Hacker News — Mandiant finds ShinyHunters using vishing, January 2026
• Push Security — How three techniques are behind ShinyHunters' 2026 campaigns
• Computer Weekly — Wave of ShinyHunters vishing attacks spreading fast
• Allure Security — How ShinyHunters breached 400 companies by impersonating them
• KBI Media — Mandiant warns of active ShinyHunters vishing campaign targeting enterprise identity