ShinyHunters all’attacco di Salesforce: come gli hacker rubano i dati CRM sfruttando OAuth e finte chiamate IT

🛡️ Executive Summary

• ShinyHunters induce gli utenti ad autorizzare applicazioni OAuth malevole camuffate da strumenti Salesforce legittimi attraverso campagne di vishing.
• Token validi, integrazioni compromesse e accessi guest configurati male consentono persistenza ed esfiltrazione senza malware o autenticazioni anomale.
• La difesa richiede governance OAuth, revisione delle integrazioni, controllo degli utenti guest e monitoraggio continuo delle attività API Salesforce.

ShinyHunters ha intensificato gli attacchi contro Salesforce e altre applicazioni SaaS, sfruttando flussi OAuth legittimi, campagne di vishing, compromissioni della supply chain e configurazioni errate degli accessi guest. Le attività osservate da Microsoft tra la metà del 2025 e la metà del 2026 mostrano un’evoluzione rispetto alle intrusioni basate sul furto tradizionale delle credenziali: gli attaccanti ottengono token validi, ereditano privilegi già concessi e interrogano direttamente le API dei servizi cloud. Il risultato è un’attività che può apparire compatibile con il normale funzionamento delle integrazioni aziendali, mentre account, contatti, casi di assistenza e altri record CRM vengono enumerati ed esfiltrati su larga scala.

ShinyHunters trasforma OAuth in un vettore di accesso fidato

La strategia di ShinyHunters si basa su tre percorsi principali che convergono verso lo stesso obiettivo: ottenere un’identità o un’applicazione già considerata affidabile dalla piattaforma SaaS. Il primo percorso impiega il vishing, con telefonate nelle quali gli attaccanti si presentano come tecnici del supporto IT e guidano la vittima nell’autorizzazione di una connected app controllata dal gruppo. Il secondo sfrutta la compromissione di integrazioni di terze parti per recuperare segreti, token e autorizzazioni già distribuiti su numerosi tenant. Il terzo utilizza configurazioni errate degli accessi guest di Salesforce per interrogare dati senza un’autenticazione ordinaria. In tutti e tre i casi gli aggressori evitano di introdurre malware tradizionale, non devono necessariamente riutilizzare una password rubata e riducono la probabilità di generare alert basati su accessi da località inconsuete o tentativi falliti.

Il principio è quello dell’abuso di fiducia delegata: OAuth consente a un’applicazione di operare per conto dell’utente senza conoscere direttamente la sua password, ma la stessa delega diventa pericolosa quando il consenso viene ottenuto con l’inganno o quando il token appartiene a un’integrazione compromessa. La campagna rappresenta un’evoluzione coerente con le attività già attribuite a gruppi specializzati nella compromissione di ambienti cloud, come osservato negli attacchi di Scattered Spider contro applicazioni SaaS e account aziendali, dove l’identità e il supporto tecnico sostituiscono l’exploit come principale porta di ingresso.

Il vishing induce gli utenti ad autorizzare applicazioni Salesforce malevole

Nelle campagne vocali gli operatori contattano dipendenti e amministratori fingendosi membri del reparto IT, del supporto Salesforce o di un fornitore incaricato di risolvere un problema tecnico. La vittima viene accompagnata nel processo di autorizzazione OAuth e invitata a concedere permessi a un’applicazione che può essere presentata con nomi e icone simili a strumenti legittimi, compreso Salesforce Data Loader. Una volta completato il consenso, l’app controllata dagli attaccanti riceve un token con il quale può eseguire chiamate API secondo i privilegi dell’utente compromesso. Il gruppo può quindi enumerare oggetti, profili, account, contatti, opportunità commerciali e casi di assistenza, senza dover interagire nuovamente con la vittima. L’accesso può rimanere valido anche dopo la chiusura della telefonata e non genera necessariamente un nuovo login visibile nei normali registri di autenticazione, perché le richieste provengono dall’applicazione già autorizzata. La persistenza è quindi incorporata nel rapporto di fiducia tra Salesforce, l’identità e la connected app. I dati recuperati possono inoltre contenere password, token o informazioni operative utili per muoversi verso altri servizi SaaS, estendendo la compromissione oltre il CRM iniziale. Tecniche simili erano già emerse negli abusi di applicazioni OAuth diffuse attraverso notifiche GitHub, ma ShinyHunters le applica a contesti enterprise nei quali un singolo consenso può aprire l’accesso a milioni di record aziendali.

Le integrazioni compromesse ampliano l’attacco a più tenant Salesforce

La supply chain SaaS rappresenta il secondo pilastro dell’operazione. Le aziende collegano Salesforce a piattaforme di marketing, sales intelligence, supporto, analisi e collaborazione, concedendo a queste applicazioni token e permessi necessari per sincronizzare automaticamente i dati. Quando una singola integrazione viene compromessa, l’attaccante può ereditare l’accesso a numerosi tenant downstream senza dover violare separatamente ogni organizzazione. Nel 2025 le credenziali associate a integrazioni come Salesloft e Drift hanno consentito il recupero di segreti OAuth distribuiti su più istanze Salesforce; nel novembre dello stesso anno sono state coinvolte applicazioni pubblicate da Gainsight, mentre nel giugno 2026 la compromissione di Klue ha permesso attività di discovery, interrogazione ed esfiltrazione.

In ciascun episodio gli attaccanti hanno cercato di imitare il comportamento normale dell’integrazione, utilizzando token validi e API previste dal servizio invece di introdurre processi estranei. L’incidente Klue ha mostrato concretamente l’effetto domino di questo modello, con il furto di dati Salesforce appartenenti a diverse aziende della cybersecurity attraverso un’applicazione già autorizzata. Il problema non riguarda quindi soltanto la sicurezza interna del tenant, ma anche il livello di fiducia accordato ai partner: un’integrazione con privilegi estesi può diventare un punto di compromissione condiviso e trasformare una singola violazione in un incidente multi-organizzazione.

I token OAuth validi rendono l’esfiltrazione simile al traffico normale

L’elemento che rende queste campagne particolarmente difficili da rilevare è l’assenza di segnali tipici dell’intrusione. Non compaiono necessariamente autenticazioni fallite, brute force, password riutilizzate o malware sui dispositivi degli utenti. Le richieste API vengono firmate con token validi e possono provenire da applicazioni regolarmente registrate, rendendo il traffico formalmente conforme al modello operativo del servizio. ShinyHunters utilizza questo vantaggio per effettuare discovery degli oggetti disponibili, interrogare tabelle CRM, esportare report e raccogliere grandi quantità di record in tempi brevi.

L’anomalia non risiede quindi nell’autenticazione, ma nel comportamento successivo: aumento improvviso del numero di query, accesso a oggetti mai consultati, letture massive, esportazioni inconsuete o utilizzo di applicazioni inattive da mesi. La tradizionale distinzione tra attività legittima e malevola perde efficacia quando l’attaccante opera con la stessa identità e gli stessi strumenti di un’integrazione affidabile. Questa dinamica è particolarmente pericolosa nei CRM, dove i dati possono comprendere informazioni personali, dettagli commerciali, contratti, ticket di assistenza e note interne. Gli incidenti già attribuiti al gruppo, compresa l’offensiva contro Oracle PeopleSoft e le criticità delle API ServiceNow, confermano una strategia orientata alle piattaforme aziendali capaci di concentrare grandi volumi di informazioni in un unico ambiente.

Gli accessi guest errati espongono gli endpoint Aura senza autenticazione

Un ulteriore vettore riguarda gli utenti guest delle implementazioni Salesforce Experience Cloud e gli endpoint del framework Aura. Le organizzazioni utilizzano questi componenti per pubblicare portali, siti di supporto e servizi destinati a clienti o partner esterni, ma configurazioni troppo permissive possono rendere accessibili oggetti e campi che dovrebbero rimanere riservati. ShinyHunters ha sfruttato queste impostazioni per inviare richieste basate su GraphQL e recuperare dati senza possedere un account autenticato. Gli attaccanti concatenano più richieste per superare i limiti applicati al numero di record restituibili agli utenti guest, trasformando un’esposizione apparentemente contenuta in un’esfiltrazione su larga scala. Non viene sfruttata una vulnerabilità del software nel senso tradizionale: il problema nasce dalla combinazione tra permessi concessi, oggetti esposti e controlli insufficienti sulle query. Questa caratteristica rende l’incidente più difficile da trattare, perché una patch non è sufficiente e ogni organizzazione deve verificare direttamente le proprie configurazioni. Gli endpoint Aura possono inoltre essere analizzati con strumenti specializzati come AuraInspector, capaci di enumerare componenti, metodi e dati accessibili. Il monitoraggio deve quindi comprendere richieste guest anomale, volumi elevati, sequenze GraphQL ripetitive e accessi a oggetti non coerenti con la funzione pubblica del portale.

I record CRM alimentano estorsioni e movimenti laterali nel cloud

Le campagne hanno interessato aziende dei settori retail, education e manifatturiero, con accesso non autorizzato a tenant Salesforce e furto di dati CRM su larga scala. Account, contatti, opportunità, note di vendita e casi di assistenza possono offrire una mappa dettagliata delle relazioni commerciali di un’organizzazione, identificando clienti strategici, fornitori, dirigenti e processi interni. Queste informazioni possono essere utilizzate per estorsioni dirette, rivendita sui forum criminali, phishing altamente personalizzato o compromissioni successive. Nei ticket di supporto e nelle note operative possono inoltre comparire URL interni, credenziali temporanee, configurazioni, dettagli su vulnerabilità e procedure di ripristino. Il valore del breach cresce quando Salesforce è collegato ad altre piattaforme mediante automazioni e identità non umane: una chiave o un token recuperato dal CRM può consentire di accedere a strumenti di marketing, archivi cloud, piattaforme di assistenza o sistemi di collaborazione. L’incidente non resta quindi confinato al singolo tenant ma può propagarsi all’intero ecosistema SaaS dell’impresa. La persistenza silenziosa aumenta il rischio perché i token possono continuare a funzionare fino alla revoca, anche dopo la modifica della password dell’utente, rendendo inefficaci le risposte limitate al reset delle credenziali.

La governance OAuth deve includere app, token e identità non umane

La difesa richiede una visibilità completa sulle applicazioni connesse e sulle identità che operano senza interazione umana. Le organizzazioni devono censire tutte le connected app autorizzate, verificare i relativi owner, analizzare i permessi concessi e revocare applicazioni inutilizzate, sconosciute o inattive da oltre 90 giorni. Particolare attenzione deve essere riservata ai token con privilegi elevati, alle integrazioni capaci di esportare record e alle applicazioni autorizzate da utenti con ruoli amministrativi. Il consenso OAuth dovrebbe essere limitato attraverso policy che impediscano agli utenti ordinari di approvare autonomamente applicazioni non verificate, mentre le nuove integrazioni devono essere sottoposte a revisione di sicurezza prima dell’accesso ai dati produttivi. È inoltre necessario considerare service account, bot e connettori come identità a tutti gli effetti, applicando principi di minimo privilegio, rotazione dei segreti e revoca automatica quando il servizio non è più utilizzato. Per ridurre il rischio di vishing, le aziende devono stabilire procedure secondo cui il supporto IT non chiede mai di autorizzare applicazioni durante una telefonata non richiesta e deve confermare ogni operazione attraverso canali interni verificabili.

Microsoft Defender monitora query massive, app anomale ed esportazioni

Microsoft raccomanda di collegare Salesforce a Microsoft Defender for Cloud Apps e di utilizzare Salesforce Shield Event Monitoring attraverso il connettore aggiornato per ottenere una visibilità prossima al tempo reale. Le regole di rilevamento devono concentrarsi sulle attività successive all’autenticazione: sessioni dirottate, connected app sconosciute, accessi SSO ad alto rischio, query API intensive, esportazioni di report, scraping di oggetti e comportamenti incompatibili con il normale profilo dell’utente o dell’integrazione.

Le query di advanced hunting possono correlare attività API, utenti, applicazioni, indirizzi IP e volumi di record, evidenziando picchi improvvisi o accessi a oggetti sensibili. Devono essere monitorate anche le app che iniziano a utilizzare permessi mai sfruttati in precedenza e quelle che operano dopo lunghi periodi di inattività. Microsoft Security Copilot può supportare la ricostruzione temporale dell’incidente e la ricerca di pattern comuni tra tenant, ma l’efficacia dipende dalla qualità dei log e dalla loro conservazione. Senza telemetria dettagliata sulle API, molte operazioni di ShinyHunters possono apparire come attività lecite svolte da un’app autorizzata.

La sicurezza SaaS non può dipendere soltanto dal login

Le tecniche di ShinyHunters dimostrano che la protezione delle piattaforme cloud non può fermarsi a password robuste, autenticazione multifattore e controllo dei login. Quando un token OAuth viene concesso volontariamente, sottratto a un’integrazione o utilizzato attraverso una configurazione guest errata, l’attaccante può evitare completamente i meccanismi che normalmente identificano il furto di credenziali. La nuova superficie di attacco comprende consensi, applicazioni connesse, service account, API, portali pubblici e fornitori della supply chain. Ogni relazione di fiducia deve quindi essere trattata come un possibile percorso di compromissione e sottoposta a controlli continui. Le organizzazioni devono verificare periodicamente i permessi guest, simulare interrogazioni sugli endpoint Aura, controllare le integrazioni di terze parti e mantenere procedure rapide per revocare token e applicazioni. La capacità del gruppo di sottrarre dati senza distribuire malware mostra come il cybercrime stia spostando l’attenzione dall’infrastruttura locale verso il piano di identità e autorizzazione del cloud. In questo scenario, l’accesso formalmente valido non equivale più a un’attività legittima: la distinzione dipende dal contesto, dal volume, dagli oggetti consultati e dal comportamento complessivo dell’identità.