Token rubati, ticket pieni di segreti e un attaccante ben organizzato. Ma anche esempi virtuosi, come quello di OKTA, da cui imparare.
L’incidente che ha coinvolto Salesforce attraverso l’integrazione di terze parti Salesloft Drift ha messo in luce un problema che va ben oltre il singolo fornitore. Diverse aziende di primo piano, tra cui Cloudflare, Palo Alto Networks e Zscaler, hanno visto esfiltrati i dati contenuti nei propri ticket di supporto, i cosiddetti “Case” di Salesforce. Non si è trattato di una vulnerabilità della piattaforma Salesforce in sé, bensì della compromissione di token OAuth custoditi da Drift e utilizzati per collegarsi ai tenant dei clienti.
Il meccanismo è semplice quanto rischioso: un token API è, a tutti gli effetti, una chiave che apre l’accesso ai dati. A differenza di una password, non è soggetto in genere ad autenticazioni aggiuntive, non è protetto da challenge interattivi e spesso rimane valido a lungo. Se cade in mani sbagliate, consente potenzialmente di agire con gli stessi privilegi di chi l’ha generato. Nel caso di Drift, gli attaccanti hanno sfruttato i token per accedere ai Case Salesforce, sfruttando intelligentemente anche la Bulk API, lo strumento legittimo per scaricare grandi volumi di dati in modo efficiente.
Perché il bersaglio sono stati i Case? Perché gli attaccanti sanno che contengono molto più di semplici descrizioni di problemi: spesso vi finiscono log di sistema, configurazioni, screenshot e, non di rado, credenziali e chiavi di accesso che gli utenti incollano nei ticket per velocizzare la richiesta di supporto. È un archivio nascosto di informazioni preziose, che diventa oro per un attaccante ben preparato e capace di sfruttarle. Da qui l’importanza di quella che potremmo chiamare “policy dei ticket”: linee guida interne chiare su cosa può e non può essere condiviso, eventualmente supportate da controlli automatici che bloccano l’inserimento di stringhe che assomigliano a segreti.
Un dettaglio emerso nei log aiuta a capire il modus operandi degli attaccanti: in un caso è stato tentato l’uso di un token trovato nei ticket, con una richiesta alle API che ha restituito un errore 404. Non era un errore qualsiasi, ma un tentativo di validare in modo automatico credenziali rubate, effettuato con strumenti di scansione come Trufflehog. È quindi la dimostrazione che non tutti gli errori vanno trattati come rumore: un 404 su un endpoint di verifica token non ha lo stesso valore di una password sbagliata su un form di login e dovrebbe attivare un’analisi di sicurezza immediata.
In questo scenario spicca la posizione di Okta, che pur essendo un potenziale obiettivo non è stata colpita. La differenza sta in una misura apparentemente semplice ma efficace: l’applicazione di restrizioni sugli indirizzi IP da cui potevano provenire le connessioni API (che noi da tempo suggeriamo di attivare). Un token rubato, in quel contesto, non era sufficiente senza anche il giusto ambiente di esecuzione. È un esempio concreto di difesa in profondità: il controllo non si limita al possesso del token, ma richiede che siano soddisfatte altre condizioni, come l’origine della connessione o il certificato client.
Vale la pena citare anche il caso di Google, che è stato coinvolto in modo indiretto. Non sono stati compromessi i sistemi di Google Cloud o l’infrastruttura core di Mountain View, ma alcuni clienti che utilizzavano Drift avevano integrato i propri account Google Workspace. I token OAuth associati a queste integrazioni sono finiti nelle mani degli attaccanti, con il rischio di accesso a e-mail e calendari degli utenti coinvolti. Anche qui, dunque, la responsabilità non ricade sul provider principale, ma sulla catena di integrazione e sul modo in cui i token vengono conservati e protetti.
La lezione che si può trarre da questo incidente è duplice. Da un lato, le aziende devono imparare a considerare le componenti di terze parti come parte integrante della propria superficie di attacco, non come un dettaglio secondario.
Dall’altro, i token API vanno trattati con la stessa cura che si riserva alle chiavi critiche: scadenze brevi, rotazione regolare, privilegi minimi, protezione con sistemi di secret management e, dove possibile, vincoli contestuali che ne limitino l’uso adl di fuori degli ambiti applicativi.
Il caso Drift/Salesforce dimostra che la resilienza non dipende soltanto dalla solidità del cloud provider, ma anche dalle ulteriori misure di protezione che si possono prendere, come per es. le regole di firewall sugll indirizzi IP assentiti. E, come insegna l’esperienza di Okta, a volte è proprio una misura apparentemente “banale” come un filtro sugli indirizzi IP a fare la differenza tra un incidente e un tentativo bloccato sul nascere.
Il caso Drift/Salesforce ci ricorda che la sicurezza non si può più basare sul semplice possesso di una chiave digitale. Un token, da solo, non dovrebbe mai essere sufficiente per ottenere accesso a dati critici. È proprio questo il cuore del modello Zero Trust: non fidarsi mai implicitamente, verificare sempre, contestualizzare ogni richiesta.
Applicare Zero Trust significa trattare ogni integrazione come potenzialmente vulnerabile, aggiungere controlli di contesto come restrizioni di rete, autenticazioni multiple, policy dinamiche e monitoraggio continuo. Significa soprattutto non dare mai per scontato che un token, una sessione o un canale di comunicazione siano sicuri solo perché provengono da una fonte apparentemente affidabile.
Se c’è una lezione chiara offerta da questo incidente, è che la resilienza non nasce dalla fiducia, ma dalla verifica costante. Solo adottando logiche Zero Trust le aziende potranno davvero ridurre i rischi legati a un mondo in cui l’accesso ai sistemi passa sempre più da API e integrazioni.
Il caso Drift/Salesforce ha mostrato quanto sia fragile l’equilibrio tra fiducia e sicurezza quando si parla di integrazioni SaaS e token API. La risposta di Okta offre però uno spunto interessante non solo sul piano tecnico — con le restrizioni IP che hanno impedito l’abuso dei token — ma anche sul piano strategico.
Da tempo infatti Okta sostiene il framework IPSIE (Interoperability Profile for Secure Identity in the Enterprise), promosso insieme all’OpenID Foundation. L’idea è semplice e potente: creare regole comuni e condivise che obblighino i fornitori SaaS a implementare meccanismi minimi di sicurezza e interoperabilità. Tra questi, la possibilità di scambiarsi segnali in tempo reale quando viene rilevato un abuso e la capacità di revocare token compromessi in modo standardizzato, così da fermare subito l’attacco anche in ecosistemi complessi.
Se il modello Zero Trust ci ricorda che non bisogna mai fidarsi ciecamente di una singola credenziale, IPSIE rappresenta il passo successivo: garantire che le diverse applicazioni SaaS parlino la stessa lingua di sicurezza e possano difendersi insieme. È un invito a superare la logica dei silos, per costruire una resilienza collettiva che diventa sempre più necessaria in un mondo governato da API e integrazioni cloud.
UPDATE: 8 set 2025
Il breach si allarga, anche Tenable conferma di essere stata impattata.
Inoltre, dai nuovi dettagli emersi dall’indagine condotta da Mandiant per conto di Salesloft si capisce meglio l’origine del data breach che ha colpito Drift e, indirettamente, i clienti Salesforce.
Secondo il comunicato ufficiale di Salesloft , il punto di ingresso iniziale dell’attacco non è stato Salesforce né direttamente Drift, bensì il repository GitHub di Salesloft.
- Tra marzo e giugno 2025, il gruppo di minaccia UNC6395 (alias “GRUB1”) ha avuto accesso al GitHub privato di Salesloft, riuscendo a scaricare contenuti da più repository, aggiungere un utente “guest” e creare workflow malevoli.
- Da lì, gli attaccanti sono riusciti a effettuare un pivot verso l’ambiente AWS di Drift, dove erano conservati i token OAuth utilizzati dalle integrazioni con Salesforce, Google Workspace e altre piattaforme.
- Con questi token in mano, l’attacco è proseguito con attività di ricognizione (via SOQL), esfiltrazione massiva (Bulk API 2.0) e infine cancellazione dei job per tentare di cancellare le tracce (anti-forensics).
Questa catena dimostra come una compromissione iniziale in ambito sviluppo e gestione del codice (repository GitHub) possa propagarsi fino agli ambienti di produzione cloud e, da lì, colpire i clienti finali.
Salesloft e Mandiant confermano che:
- l’app Drift è stata messa offline,
- tutte le credenziali e i token sono stati revocati/ruotati,
- la segmentazione tecnica tra Salesloft e Drift ha retto, impedendo un impatto diretto sull’ambiente core di Salesloft.
Fonti aggiuntive notizie: