Il patto implicito tra un’azienda e i suoi clienti si regge su un pilastro fondamentale: la fiducia. Fiducia che i propri dati, anche quelli condivisi per risolvere un problema tecnico urgente, siano al sicuro. All’inizio di settembre, Cloudflare ha dovuto rompere quel patto, inviando una notifica sgradevole a una cerchia dei suoi clienti: un attore avanzato di minaccia, battezzato GRUB1, era riuscito a violare il suo sistema di supporto clienti, ospitato su Salesforce. E’ solo l’ultimo dei casi emersi da giugno 2025 a oggi sulla catena di compromissioni legate a Salesforce.
La storia, però, non inizia con un sofisticato zero-day o un attacco brute-force. Inizia con un chatbot. Quello di Drift, un prodotto di Salesloft, che centinaia di aziende, Cloudflare inclusa, integrano nei propri siti web per conversare in tempo reale con visitatori e potenziali clienti. Quella che doveva essere una comoda funzionalità di business si è trasformata nel cavallo di Troia perfetto per una campagna di spionaggio industriale su larga scala.
Secondo il resoconto dettagliato pubblicato da Cloudflare, GRUB1 ha sferrato il suo attacco sfruttando una falla negli sistemi di Salesloft. L’obiettivo? Le credenziali OAuth che l’integrazione di Drift utilizzava per connettersi e sincronizzarsi con Salesforce. Impadronitosi di quelle chiavi, il threat actor ha guadagnato un accesso privilegiato e non autorizzato agli ambienti Salesforce di numerose organizzazioni.
Per Cloudflare, la linea temporale dell’incidente è un racconto di meticolosa reconnaissance e esfiltrazione silenziosa. Il primo segnale d’allarme risale al 9 agosto, quando GRUB1 ha testato un token API Cloudflare (probabilmente ottenuto da un’altra vittima della campagna) contro gli endpoint di verifica, camuffando le proprie richieste con lo user-agent di TruffleHog, un noto tool open-source per il secret scanning.
Il vero accesso è avvenuto tre giorni dopo, il 12 agosto. Da un’infrastruttura AWS (44[.]215[.]108[.]109), GRUB1 ha usato le credenziali compromesse di Drift per accedere al tenant Salesforce di Cloudflare e iniziare a esplorarne la struttura, interrogando l’endpoint /services/data/v58.0/sobjects/ per mappare tutti gli oggetti presenti.
Nei giorni successivi, l’attore ha condotto una ricognizione chirurgica. Ha contato account, contatti e utenti. Ha studiato lo schema dei casi di supporto (Case/describe/), analizzato lo storico delle assegnazioni (CaseTeamMemberHistory) e persino verificato di trovarsi in un ambiente di produzione, interrogando l’oggetto Organization. Ogni mossa era calibrata per comprendere l’estensione del bottino e pianificare un’esfiltrazione massiva senza innescare allarmi.
Il 17 agosto è scattata l’operazione vera e propria. GRUB1 è tornato online, ma questa volta da un’infrastruttura diversa, su DigitalOcean (208[.]68[.]36[.]90). Dopo una rapida verifica finale sul numero di record, ha lanciato un job dell’API Bulk 2.0 di Salesforce. In poco più di tre minuti, ha prelevato l’intero set di dati testuali contenuti negli oggetti “Case”. Il colpo di scena finale: un tentativo di coprire le proprie tracce cancellando il job appena eseguito. Un tentativo andato a vuoto, grazie ai log di sistema che hanno permesso ai team di Cloudflare di ricostruire l’intera sequenza.
Il bottino? I contenuti testuali di tutti i ticket di supporto. Niente allegati, ma il danno è comunque significativo. I casi di supporto sono il cuore delle operazioni di customer care: contengono la corrispondenza tra il cliente e il supporto tecnico, informazioni di contatto, oggetti delle richieste e, soprattutto, tutto ciò che un cliente potrebbe aver incollato in un momento di frustrazione durante il troubleshooting: log di sistema, frammenti di configurazione, credential e, soprattutto, token API.
Cloudflare sottolinea di non richiedere mai ai clienti di condividere segreti, ma riconosce che nella pratica questo avviene. La loro risposta è stata immediata e articolata. Dopo la notifica ufficiale di Salesforce e Salesloft giunta il 23 agosto, hanno avviato una massiccia operazione di containment: disconnessione immediata di tutte le integrazioni third-party da Salesforce, revoca e rotazione di tutte le credenziali e i secret, rimozione del software Salesloft da tutte le workstation.
Parallelamente, i team di sicurezza hanno setacciato i dati esfiltrati con tool custom di pattern-matching e analisi dell’entropia per identificare possibili token compromessi. Ne hanno trovati e ruotati 104, senza aver rilevato attività sospette associate ad essi.
L’aspetto più inquietante di questo incidente è la sua natura di supply-chain attack. GRUB1 non ha violato direttamente Cloudflare o le altre centinaia di vittime. Ha violato un singolo fornitore, un anello della catena, e attraverso quello ha ottenuto le chiavi per entrare in tutti i suoi clienti. È un attacco moltiplicatore, che massimizza il “ROI” per il threat actor.
La lezione è chiara per ogni organizzazione che affida i propri processi core a ecosistemi SaaS interconnessi. La superficie d’attacco si estende ben oltre il proprio perimetro, includendo ogni integrazione, ogni app connessa, ogni token OAuth concesso. La postura di sicurezza deve evolversi per governare questo rischio esteso: principio del minimo privilegio applicato rigorosamente alle integrazioni third-party, rotazione frequente e obbligatoria delle credenziali, monitoraggio ossessivo delle attività anomale tra applicazioni business-to-business.
Cloudflare, da parte sua, non ha nascosto la gravità dell’accaduto. “Siamo responsabili degli strumenti che scegliamo”, hanno scritto. “Questo incidente ha deluso i nostri clienti. Per questo, ci scusiamo sinceramente”. In un panorama dove la fiducia è l’asset più prezioso, l’onestà e la trasparenza sono l’unico modo per ricucirla.