Adobe, 13 Milioni di Ticket Esfiltrati: Il Breach di "Mr. Raccoon" e la Lezione che Nessuno Vuole Imparare sulla Supply Chain del Supporto

Il 12 aprile 2026 un attore che si firma "Mr. Raccoon" ha pubblicato su un forum di cybercrime la rivendicazione del furto di 13 milioni di ticket di supporto di Adobe, corredati dei dati personali dei clienti che li avevano aperti. Nel lotto rivendicato ci sono anche 15.000 record di dipendenti Adobe, l'intero archivio delle submission del programma bug bounty su HackerOne, documenti interni di vario livello e una serie di screenshot che, se autentici, confermerebbero un accesso prolungato all'ambiente di supporto del vendor. Adobe, al momento della pubblicazione di questo articolo, non ha ancora rilasciato una conferma pubblica. Le analisi indipendenti di Cybernews, SecurityOnline, GBHackers e The CyberSec Guru confermano la plausibilità tecnica della rivendicazione e ricostruiscono la catena d'attacco in modo convergente.

La reazione tipica a una notizia di questo tipo è concentrarsi sul numero — 13 milioni è una cifra che fa titolo — o sull'imbarazzo del brand colpito. Noi pensiamo che la lettura utile sia un'altra. Il breach Adobe, se confermato nei termini rivendicati, è un caso di studio particolarmente pulito su tre temi che ogni organizzazione italiana dovrebbe avere già nella propria threat list ma che troppe ignorano: (1) la supply chain del supporto esternalizzato come vettore d'attacco privilegiato, (2) gli infostealer come abilitatori di breach enterprise, (3) la mancanza di rate-limit e approvazione sulle esportazioni massive di dati come vulnerabilità architetturale fatale. Vediamoli uno per uno.

La Catena d'Attacco: Phishing Laterale e BPO come Punto d'Ingresso

La prima cosa da fissare è che Mr. Raccoon non ha bucato Adobe nel senso classico — non ha compromesso un dominio Active Directory di Adobe, non ha messo piede nell'infrastruttura core del vendor. Ha bucato un fornitore di Business Process Outsourcing indiano che gestisce una parte del supporto clienti Adobe, e da lì ha sfruttato l'accesso legittimo che quel fornitore ha verso il sistema di ticketing Adobe per esfiltrare tutto ciò che quel sistema permetteva di vedere. È una distinzione cruciale: la superficie di attacco effettiva di Adobe non si ferma al perimetro di Adobe, ma si estende a ogni dipendente di ogni partner esterno che ha un account autenticato sui sistemi Adobe.

La catena tecnica ricostruita è la seguente. Primo: email malevola inviata a un dipendente del BPO, con un allegato o un link che ha installato un infostealer o un Remote Access Tool sul suo endpoint. Secondo: dall'endpoint compromesso, osservazione del flusso di lavoro dell'utente, raccolta delle credenziali memorizzate nel browser e nei gestori di password, mappatura dei suoi contatti interni. Terzo: phishing laterale dal dispositivo compromesso verso il manager del dipendente — una mail che viene da un indirizzo interno legittimo supera le difese perimetrali e ha tassi di click enormemente più alti di un phishing esterno. Quarto: compromesso il manager, espansione dell'accesso a livelli di privilegio superiore nel sistema di supporto Adobe, fino a un account agente con permessi di esportazione.

Il Pesce Grosso: Il Bug di Progettazione dell'Esportazione Massiva

Tutto il resto della catena — infostealer, phishing laterale, privilege escalation — è doloroso ma ordinario. È quello che succede dopo che rende questo caso un masterclass su cosa non fare nel design di un sistema di ticketing enterprise. Secondo le analisi pubblicate da Cybernews e SecurityOnline, un agente di supporto autenticato sulla piattaforma di ticketing Adobe poteva richiedere l'esportazione di tutti i ticket del sistema in una singola operazione, senza limiti di volume, senza rate-limit, senza approvazione di un supervisore, senza soglia di alerting su volumi anomali.

Questo è un bug di design, non di implementazione. Non è una regex mal scritta o un bound-check dimenticato: è una scelta architetturale secondo cui "un agente autorizzato può leggere tutti i ticket, quindi può anche esportarli tutti insieme". La scelta nasce probabilmente da una feature richiesta dal business — "voglio scaricare un report mensile con tutti i ticket chiusi" — e si è progressivamente allargata a qualsiasi export di qualsiasi volume senza mai essere rimessa in discussione. Il risultato è che nel momento in cui un singolo account agente è compromesso, il danno non è limitato ai ticket di quell'agente o del suo team: è l'intero storico di 13 milioni di ticket del sistema, con i dati personali di tutti i clienti che li hanno aperti.

Il principio che manca si chiama "least astonishment operativo": un'operazione che, se riuscita, compromette un ordine di grandezza di dati enormemente superiore al lavoro quotidiano di un utente, non deve essere disponibile con lo stesso click con cui si risponde a un ticket. Deve avere un rate-limit per account (es. max 1.000 ticket/giorno), un tetto assoluto di volume (es. max 10.000 ticket/export), un alerting automatico sui volumi anomali, e per volumi oltre soglia una seconda approvazione fuori banda. Nessuno di questi controlli era presente. Quando il controllo manca, basta un singolo anello debole nella catena umana per trasformare un incidente di endpoint in un data breach da titolo di giornale.

La Sorpresa Amara: Le Submission HackerOne

Tra i dati rivendicati da Mr. Raccoon c'è un elemento che dovrebbe far riflettere la comunità del vulnerability disclosure: l'intero archivio delle submission HackerOne del programma bug bounty di Adobe. Per chi non fosse familiare: quando un ricercatore di sicurezza trova una vulnerabilità e la segnala responsabilmente via HackerOne ad Adobe, genera un rapporto che contiene i dettagli tecnici completi della vulnerabilità — codice proof-of-concept, endpoint vulnerabili, indicazioni su come riprodurla. Questi rapporti includono tipicamente sia le vulnerabilità già risolte, sia quelle ancora aperte in fase di triage, patch o disclosure coordinata.

Se l'archivio HackerOne è stato effettivamente esfiltrato, il valore per attaccanti terzi è enorme: ogni vulnerabilità ancora aperta diventa immediatamente sfruttabile con i dettagli tecnici completi, saltando la fase di discovery che normalmente è la più costosa. È il motivo per cui le aziende mature mantengono i report HackerOne in un ambiente segregato dal resto dell'infrastruttura di supporto, con controlli di accesso distinti e log separati. Il fatto che l'archivio bug bounty sia finito nello stesso perimetro del ticketing clienti suggerisce che questa segregazione non era implementata, o era aggirabile con i privilegi dell'account di supporto compromesso. Per Adobe, oltre al danno reputazionale diretto, questo comporta il rischio concreto di una seconda ondata di incidenti su vulnerabilità non ancora patchate nelle settimane seguenti la pubblicazione del leak.

Perché Questo Caso Riguarda Anche le Aziende Italiane

La prima reazione di molti security team italiani a una notizia di questo tipo è: "noi non siamo Adobe, non abbiamo 13 milioni di ticket". La seconda, più acuta, è: "ma abbiamo esternalizzato il supporto clienti a Infosys / TCS / Wipro / Accenture, e loro hanno accesso ai nostri sistemi". La terza, ancora più acuta: "e abbiamo decine di altre integrazioni con partner che hanno account autenticati sui nostri ambienti". La verità è che il modello di breach Adobe è perfettamente replicabile su organizzazioni italiane di medie e grandi dimensioni che abbiano esternalizzato almeno una funzione operativa a un BPO, un partner IT o un fornitore di servizi gestiti.

Il settore pubblico italiano, in particolare, presenta un'esposizione significativa. L'Agenzia per l'Italia Digitale, il Ministero dell'Economia, l'INPS, l'Agenzia delle Entrate — ognuno di questi enti opera con una rete densa di fornitori esterni che hanno accesso autenticato a porzioni non banali dei sistemi informativi pubblici. Il caso Equalize (documentato da AEGIDA il 10 aprile) aveva già mostrato cosa succede quando questa fiducia nei fornitori viene tradita dall'interno. Il caso Adobe mostra la variante peggiore: quando la fiducia non viene tradita dall'interno, ma semplicemente sfruttata dall'esterno attraverso una catena di compromissione endpoint → laterale → privilege escalation che nessuno dei controlli tradizionali rileva in tempo.

Cosa Fare: Sette Controlli da Verificare Oggi

1. 1.Inventario aggiornato dei partner esterni con accesso autenticato ai propri sistemi, con per ciascuno: ambito di accesso, numero di account, livello di privilegio, flussi di dati accessibili. Molte organizzazioni non hanno questo inventario. Serve farlo adesso.
2. 2.Revisione dei permessi di esportazione massiva su tutti i sistemi che contengono dati personali o commercialmente sensibili: CRM, ticketing, DMS, data warehouse. Per ogni sistema, verificare esistenza di rate-limit, tetto assoluto di volume, alerting su esportazioni anomale, approvazione a due occhi sopra soglia.
3. 3.Contratti con i partner BPO e IT rivisti per includere obblighi specifici: EDR aziendale su tutti gli endpoint, MFA resistente al phishing per ogni accesso ai sistemi cliente, notifica di compromissione di singolo endpoint entro 24 ore, right-to-audit periodico.
4. 4.Segregazione degli ambienti di gestione delle vulnerabilità (bug bounty, VDP, ticket di sicurezza) dal resto delle piattaforme di supporto. Se il tuo sistema di security ticket vive nello stesso Jira/ServiceNow della help desk generalista, probabilmente è troppo accessibile.
5. 5.Threat hunting dedicato ai pattern di breach via BPO: login da geografie BPO note (India, Filippine, Europa orientale) a orari non di turno, query di export su volumi superiori alla media, movimenti laterali da account BPO ad account di manager interni.
6. 6.Formazione specifica sui dipendenti dei partner con accesso ai sistemi cliente: il phishing laterale funziona perché l'operatore che riceve una mail dal proprio manager non sospetta che il manager sia compromesso. Simulazioni ad hoc aumentano la resistenza.
7. 7.Piano di risposta a "incidente in partner": molti piani di incident response italiani non hanno runbook specifici per il caso "il fornitore ha un infostealer su un endpoint che accede ai nostri sistemi". Va scritto prima di averne bisogno.

La Fragilità Nascosta del Modello BPO Moderno

C'è un aspetto strutturale che il caso Adobe mette in luce e che merita di essere nominato esplicitamente. Il modello economico del Business Process Outsourcing, in particolare quello indiano che oggi serve una percentuale significativa del supporto clienti e dei servizi IT delle grandi aziende occidentali, è costruito sull'ottimizzazione del costo per ticket. Margini stretti, turnover elevato, formazione standardizzata, controlli di sicurezza lato dipendente tipicamente inferiori a quelli che lo stesso vendor applicherebbe sui propri dipendenti diretti. Questo non è un giudizio morale sui provider BPO: è una descrizione di un modello di mercato che per funzionare a quei prezzi deve comprimere ciò che non è strettamente necessario alla produttività misurata contrattualmente.

Quando il vendor cliente — Adobe, nel caso — delega al BPO una funzione con accesso autenticato ai suoi sistemi, sta trasferendo una parte sostanziale della propria superficie di attacco a un ambiente la cui postura di sicurezza è disegnata per un profilo di rischio diverso dal proprio. Il risultato è prevedibile: il livello di sicurezza effettivo della funzione esternalizzata è il livello di sicurezza del BPO, non quello del vendor. Il caso Adobe lo dimostra in modo particolarmente netto, ma non è un'eccezione — è la regola per tutte le funzioni esternalizzate in cui i controlli contrattuali non sono accompagnati da controlli tecnici e operativi equivalenti a quelli interni.

Conclusione: Non È il Breach di Adobe. È il Tuo Prossimo Breach.

La tentazione, leggendo una notizia come questa, è di trattarla come un evento da osservatore — "povera Adobe", "13 milioni è tanto", "chissà come reagiranno". La realtà è che il profilo di attacco di Mr. Raccoon — infostealer su partner esterno, phishing laterale, privilege escalation in ambiente cliente, export massivo sfruttando un controllo architetturale assente — è uno schema replicabile su praticamente qualsiasi organizzazione di una certa dimensione che abbia esternalizzato il supporto, la gestione IT o una qualsiasi funzione amministrativa con accesso ai sistemi interni. Significa che la probabilità che il prossimo caso abbia le iniziali di un'azienda italiana è non trascurabile.

La buona notizia è che i sette controlli elencati sopra non sono esotici né particolarmente costosi. Sono controlli noti, spesso già presenti parzialmente, che richiedono principalmente di essere estesi oltre il perimetro interno a tutto l'ecosistema dei partner con accesso autenticato. La cattiva notizia è che farlo richiede tempo — inventario, revisione contratti, integrazione con i SIEM aziendali — e che il tempo disponibile prima del prossimo caso italiano di questa categoria è probabilmente breve. Aprile 2026 è il mese in cui la geopolitica e il cybercrime hanno tutti accelerato simultaneamente. Il breach Adobe è solo uno dei segnali; ignorarlo significa aspettare di essere il prossimo caso di studio.