Marcus Chen, YuSMP Group
Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · sicurezza delle infrastrutture per aziende negli Stati Uniti e nell'UE
Scrivania buia di notte: smartphone con un banner di allarme rosso, lucchetto aperto, chiavi e badge aziendale davanti a un monitor con righe di dati dei clienti e uno schema cloud

In sintesi

ASOS non è stata violata tramite una falla software: un solo login di un dipendente, rubato con il phishing, ha aperto gli strumenti di terze parti che custodiscono i dati dei clienti e permettono di scrivere loro. L'8 ottobre 2026 il retailer di moda britannico ha confermato che gli attaccanti si erano spacciati per un contatto fidato, avevano ottenuto le credenziali e le avevano usate su piattaforme di fornitori, due giorni dopo che la sua app aveva inviato un falso avviso.

Secondo ASOS, carte di pagamento e password non sono state sottratte. Il punto debole era lo strato da cui oggi dipende la maggior parte delle piattaforme e-commerce e retail: servizi di marketing, personalizzazione e messaggistica che stanno fuori dal sistema centrale ma custodiscono profili clienti ricchi e possono raggiungere lo smartphone di ogni utente.

Come sono arrivati gli attaccanti ai dati dei clienti ASOS?

Secondo la comunicazione di ASOS, l'attacco è partito dall'ingegneria sociale, non da un malware. Qualcuno spacciandosi per un contatto fidato ha convinto un dipendente a consegnare il login di un account di lavoro. Quelle credenziali funzionavano poi sulle piattaforme di terze parti che il retailer usa per conservare le informazioni dei clienti e comunicare con loro.

È proprio questa seconda capacità ad aver reso pubblico l'incidente. Invece di esfiltrare i dati in silenzio, gli attaccanti hanno usato l'accesso alla messaggistica per inviare un avviso nell'app ufficiale ASOS, indirizzato al responsabile della protezione dei dati e al team IT, con l'invito a «mettersi in contatto». I clienti hanno saputo della violazione dagli attaccanti, ore prima della prima dichiarazione dell'azienda. Secondo Malwarebytes, il gruppo ha concesso ad ASOS due settimane per rispondere a una richiesta di pagamento.

Il messaggio degli attaccanti attribuiva la colpa a un'istanza Snowflake compromessa. Snowflake dice di non aver rilevato alcuna compromissione della propria piattaforma, e TechCrunch osserva che non è chiaro se l'account coinvolto fosse protetto da autenticazione a più fattori. Lo schema ricorda l'ondata di violazioni ai danni di clienti Snowflake del 2024: credenziali valide, nessuna MFA sulla porta giusta e un data warehouse che serviva fedelmente chiunque effettuasse l'accesso.

Perché i fornitori di personalizzazione e messaggistica sono così esposti?

Gli strumenti di marketing e personalizzazione vengono di solito acquistati e gestiti fuori dal team di sviluppo. Ricevono ampie esportazioni di dati dei clienti, perché i modelli possano ordinare i prodotti e segmentare il pubblico, e diritti di invio, perché le campagne partano senza un rilascio. Gli account sono spesso creati fornitore per fornitore invece che tramite l'SSO aziendale, e rivisti molto meno spesso degli accessi di produzione.

Il risultato è un secondo database clienti con serrature più deboli. Nel caso ASOS i dati segnalati includono le ricerche dei clienti, esattamente il contesto che serve a un truffatore per scrivere un messaggio di follow-up convincente. L'acquisizione di Simon AI da parte di Monetate a luglio aggiunge un altro rischio tipico: durante l'integrazione di un fornitore acquisito, titolarità degli account e regole di accesso possono cambiare senza che il cliente se ne accorga.

Cosa cambia per i team software negli Stati Uniti e nell'UE

Primo: trattare le console dei fornitori come produzione. Ogni strumento di terze parti che conserva dati dei clienti o può scrivere loro deve stare dietro il vostro identity provider, con MFA resistente al phishing (passkey o chiavi hardware), accesso condizionale e revoca automatica degli account. Una password che funziona da sola in un punto qualsiasi della catena è esattamente la falla sfruttata in questo attacco.

Secondo: separare «leggere i dati» da «scrivere a tutti gli utenti». Gli invii massivi via push, SMS ed e-mail sono una capacità ad alto impatto. Richiedete un secondo approvatore per gli invii all'intera audience, limitate il volume per utente e per ora e generate un allarme per le campagne create fuori dagli orari abituali. I team mobile dovrebbero anche verificare che le chiavi del provider push non siano condivise tra più strumenti.

Terzo: ridurre ciò che esce dal vostro sistema. I fornitori di personalizzazione raramente hanno bisogno insieme di nomi completi, indirizzi di casa e cronologia di ricerca grezza. ID pseudonimi e condivisioni di dati mirate e a scadenza riducono ciò che un solo login rubato può esporre. Per le attività in UE e nel Regno Unito è anche la minimizzazione dei dati del GDPR messa in pratica, e una violazione da notificare deve arrivare all'autorità di controllo entro 72 ore da quando l'azienda ne è venuta a conoscenza.

Cosa significa per gli e-commerce italiani?

Il caso tocca un'abitudine diffusa anche nell'e-commerce italiano: piattaforme di e-mail marketing, personalizzazione, CDP e notifiche push vengono spesso attivate dal marketing o da un'agenzia, con account propri invece dell'SSO aziendale, e non compaiono nella mappa dei sistemi dell'IT. Per i brand del fashion e del retail che puntano sull'app come canale di fidelizzazione, una falsa notifica inviata all'intera base clienti è un danno reputazionale che può pesare più della fuga di dati in sé. E il fattore umano resta l'anello debole: l'attacco a ASOS è partito da una telefonata, non da una vulnerabilità.

Sul piano normativo i riferimenti sono chiari: il fornitore che tratta i dati dei clienti è un responsabile del trattamento ai sensi dell'art. 28 del GDPR, e il titolare deve verificarne le misure di sicurezza; un accesso senza MFA è un punto debole difficile da giustificare. Una violazione dei dati personali va notificata al Garante per la protezione dei dati personali entro 72 ore, e se il rischio per le persone è elevato va comunicata anche ai clienti. In pratica: incrociate l'elenco dei fornitori ricavato dalla contabilità con i log dell'SSO, date priorità agli account con diritti di invio e provate in anticipo la procedura di notifica.

Cosa controllare questa settimana?

  1. Elencare ogni strumento SaaS con dati dei clienti o diritti di invio. Compresi personalizzazione, CDP, CRM, push, e-mail e piattaforme di assistenza, con il responsabile di ogni account amministratore.
  2. Eliminare gli account isolati. Portare ogni strumento dietro l'SSO con MFA resistente al phishing o, dove l'SSO non è disponibile, limitarlo per IP e criteri di rete.
  3. Blindare gli invii massivi. Aggiungere passaggi di approvazione e limiti di volume agli invii push, SMS ed e-mail a tutta l'app, e avvisare il team di sicurezza in caso di campagne anomale.
  4. Ridurre i dati condivisi. Rivedere i campi esportati verso ogni fornitore ed eliminare tutto ciò che il caso d'uso non richiede, in particolare indirizzi e cronologia di ricerca grezza.
  5. Provare la prima ora. Preparare un messaggio ai clienti, un canale in-app sotto il vostro controllo e una checklist per la notifica al Garante prima che servano.

Domande frequenti

Cosa è successo nel data breach di ASOS?

Il 6 ottobre 2026 gli utenti dell'app ASOS hanno ricevuto dagli attaccanti una notifica push secondo cui l'azienda era stata violata. L'8 ottobre ASOS ha confermato che qualcuno, spacciandosi per un contatto fidato, aveva ottenuto il login di un dipendente e lo aveva usato per accedere ad alcune piattaforme di terze parti utilizzate dal retailer, sottraendo nomi, recapiti e alcune informazioni legate agli account.

Sono stati rubati dati delle carte di pagamento o password?

ASOS afferma che non sono stati consultati dati delle carte di pagamento né password degli account e che sito e app sono rimasti sempre sicuri da usare. Secondo un campione di dati condiviso con la BBC, i record sottratti includono indirizzi di casa, numeri di telefono, indirizzi e-mail e ricerche effettuate sul sito.

Snowflake è stata violata?

Non ci sono prove in tal senso. Gli attaccanti hanno dichiarato di aver compromesso un'istanza ospitata su Snowflake, ma Snowflake non ha rilevato alcuna compromissione della propria piattaforma. L'accesso è avvenuto tramite una credenziale rubata a un dipendente e usata su piattaforme di terze parti, non tramite una falla di Snowflake.

Che ruolo ha Simon AI?

Gli attaccanti sostengono di aver raggiunto i dati tramite Simon AI, una piattaforma di personalizzazione dei clienti basata su Snowflake e usata da ASOS. Monetate ha acquisito Simon AI a luglio 2026. Al momento degli articoli nessuna delle due aziende aveva commentato pubblicamente, quindi il collegamento con il fornitore resta un'affermazione degli attaccanti.

Cosa devono fare ora retailer e aziende SaaS?

Portare ogni console di fornitore con dati dei clienti o diritti di invio dietro l'SSO aziendale con MFA resistente al phishing, eliminare i login isolati, ridurre i dati dei clienti inviati agli strumenti di marketing e personalizzazione, aggiungere approvazioni e limiti alle campagne push ed e-mail e provare la comunicazione di crisi, così che i clienti sentano prima voi.

Fonti

TechCrunch — Asos confirms breach of customer data after hackers send rogue app notification
Bloomberg — Hackers tricked Asos employee to steal work account login
Bloomberg — Asos shares slump after app users receive hack notification
The Record — ASOS: Hackers tricked way into employee account before sending rogue push notification
Malwarebytes — ASOS breach update: hackers stole customer details and shopping searches