Zeabur chiude dopo il data breach, SBI indaga sui dati nel dark web

🛡️ Executive Summary

• Zeabur annuncia la chiusura entro il 31 dicembre 2026 dopo due incidenti informatici: esposti 3.218.965 record di variabili d’ambiente e dati relativi a 321.810 account.
• State Bank of India segnala 3.897 record contenenti dati personali dei clienti all’interno di un dataset di circa 375.000 record individuato sul dark web.
• I due incidenti sono indipendenti e presentano livelli di accertamento differenti: Zeabur documenta accessi abusivi alla propria infrastruttura, mentre SBI sta ancora verificando origine ed estensione della perdita dei dati.

Zeabur chiude definitivamente dopo due violazioni informatiche in meno di due mesi, mentre State Bank of India conferma l’individuazione di migliaia di record dei propri clienti all’interno di un dataset pubblicato sul dark web. Due incidenti indipendenti, avvenuti in contesti tecnologici e geografici differenti, mostrano conseguenze diverse della perdita di controllo sulle informazioni digitali: nel caso della piattaforma cloud sono stati compromessi sistemi amministrativi, credenziali e infrastrutture dei clienti, fino alla decisione di cessare le attività; nel caso della banca indiana, invece, l’origine dell’esposizione è ancora oggetto di accertamento. Entrambe le vicende impongono di distinguere la sottrazione documentata dei dati, i rischi per gli utenti e l’effettiva compromissione dei servizi.

Zeabur chiude il 31 dicembre dopo il secondo incidente informatico

La piattaforma cloud Zeabur cesserà definitivamente le proprie attività il 31 dicembre 2026, dopo aver subito un secondo incidente di sicurezza il 14 e 15 ottobre, a meno di due mesi dalla precedente compromissione di agosto. Nel comunicato ufficiale del 17 ottobre, il fondatore Yuanlin Lin riconosce che la crescita della piattaforma, alimentata dalla domanda di deployment cloud per applicazioni AI, n8n e strumenti di sviluppo automatizzato, aveva reso sempre più complessa un’architettura realizzata inizialmente con risorse limitate. I due incidenti hanno evidenziato debolezze nella sicurezza e nella gestione operativa che l’azienda ritiene di non poter più affrontare garantendo continuità ai clienti. La vendita di nuovi server dedicati e domini è stata immediatamente interrotta, mentre dal 1° dicembre verranno disabilitati i rinnovi dei Dedicated Server e i servizi ospitati sui cluster condivisi saranno sospesi, pur potendo essere riavviati temporaneamente per effettuare i backup. I server dedicati si spegneranno progressivamente alle rispettive scadenze, senza necessariamente rimanere disponibili fino al 31 dicembre. Zeabur ha promesso assistenza per la migrazione, trasferimento dei domini, rimborsi dei saldi residui e valutazione delle richieste di risarcimento collegate all’incidente, ma non ha ancora comunicato le date definitive per la cancellazione dei dati e la chiusura del supporto. La vicenda introduce un rischio ulteriore rispetto alle compromissioni dei fornitori di backup cloud e dei servizi Microsoft 365: gli utenti devono affrontare contemporaneamente la bonifica delle credenziali e il trasferimento obbligatorio dell’infrastruttura verso altri operatori.

Leggi anche: Censys: infrastrutture AI esposte +63%, n8n concentra il nuovo rischio Internet

Zeabur: esposti 321.810 account e oltre 3,2 milioni di record cloud

Il rapporto tecnico preliminare pubblicato da Zeabur il 19 ottobre ricostruisce un attacco condotto attraverso due percorsi distinti, successivamente convergenti nella rete interna. Il primo è iniziato il 14 ottobre alle 01:36 UTC, quando l’intruso ha utilizzato chiavi AWS appartenenti all’azienda e token amministrativi conservati in chiaro in un repository privato di configurazione. Le credenziali consentivano di raggiungere i cluster condivisi distribuiti in nove regioni e di consultare impostazioni e variabili d’ambiente dei servizi ospitati. Gli attaccanti hanno inoltre eseguito comandi di lettura all’interno di 865 servizi database, anche se la società non può confermare quanto materiale sia stato effettivamente ottenuto da ciascuno. Il secondo percorso ha interessato i Dedicated Server gestiti su Google Cloud: attraverso una vecchia chiave GCP e password root conservate nelle impostazioni di inizializzazione, l’intruso ha ottenuto accesso privilegiato a 101 server, installando proprie chiavi SSH su 50 macchine per garantirsi la persistenza. Le due direttrici si sono ricongiunte il 15 ottobre, quando un server compromesso è stato utilizzato per aggiungere un nodo alla rete interna e raggiungere il database principale della piattaforma. L’azienda documenta 29 connessioni e 8.903 operazioni, durante le quali sono stati letti 3.218.965 record contenenti nomi e valori delle variabili d’ambiente e informazioni associate a 321.810 account. Sono state coinvolte anche 566 chiavi API zSend conservate in chiaro, successivamente revocate, mentre gli 11.536 token di accesso alla piattaforma erano memorizzati soltanto sotto forma di hash non reversibili. L’interesse degli attaccanti si è concentrato anche su credenziali AI e servizi di automazione: tra i sistemi esaminati figurano 736 istanze n8n basate su PostgreSQL, oltre ad applicazioni new-api e one-api. In centinaia di installazioni n8n la chiave di cifratura risultava conservata nelle variabili d’ambiente, rendendo recuperabili anche credenziali di servizi esterni. È uno scenario coerente con i rischi già emersi nelle campagne contro le credenziali cloud, AI e CI/CD distribuite attraverso la supply chain.

Credenziali in chiaro e correzioni incomplete: le responsabilità riconosciute da Zeabur

L’elemento più critico del rapporto riguarda le cause organizzative della compromissione. I token amministrativi utilizzati dagli attaccanti erano stati creati nel gennaio 2024 senza scadenza e non erano stati revocati dopo la violazione di agosto, mentre l’interfaccia di gestione dei cluster rimaneva raggiungibile direttamente da Internet. Anche la presenza di password root nei parametri di inizializzazione dei server GCP era stata individuata il 3 settembre, senza che la correzione fosse completata prima dell’attacco di ottobre. Zeabur ammette che la precedente dichiarazione sulla sostituzione di tutte le chiavi amministrative compromesse era incompleta: alcune credenziali presenti nel repository di configurazione erano rimaste valide, permettendo un nuovo abuso dei privilegi. L’azienda ipotizza che l’accesso iniziale possa essere collegato alla chiave privata della GitHub App esposta durante il primo incidente, ma precisa che non esistono ancora prove dirette sufficienti per confermare questo percorso. La mancanza di registrazioni complete limita inoltre la ricostruzione di alcune operazioni, mentre oltre sedici ore di attività offensiva non hanno prodotto segnalazioni automatiche, costringendo il personale ad avviare l’indagine dopo una comunicazione ricevuta da un utente. Le misure successive hanno compreso revoca dei token, rotazione delle chiavi cloud, limitazione delle interfacce amministrative, blocco degli accessi SSH pubblici e invalidazione delle sessioni. Restano però le conseguenze della sottrazione delle informazioni: una credenziale già letta dall’attaccante non torna sicura perché viene eliminata dal database originario. Le organizzazioni che utilizzavano Zeabur devono quindi sostituire API key, password, chiavi di firma e credenziali dei provider esterni, verificare le installazioni n8n e ricostruire i server sui quali è stato confermato l’accesso root. L’incidente richiama il problema delle credenziali cloud attive conservate nei repository di sviluppo, aggravato dalla presenza di privilegi amministrativi estesi e da controlli di accesso insufficienti.

State Bank of India individua 3.897 record con dati personali sul dark web

La seconda vicenda riguarda State Bank of India, che il 21 ottobre ha comunicato alle autorità di mercato indiane un incidente di perdita dei dati attraverso una nota ufficiale trasmessa a BSE e National Stock Exchange. L’istituto aveva ricevuto il 16 ottobre segnalazioni dal proprio fornitore di threat intelligence, dalla Defence Cyber Agency e dal CERT-In circa la possibile esposizione di informazioni dei clienti sul dark web. Durante l’esame preliminare di un dataset contenente circa 375.000 record, sono stati individuati 3.897 record contenenti informazioni personali identificative riconducibili ai clienti della banca. La distinzione tra i due numeri è fondamentale: il dataset complessivo rappresenta il materiale esaminato, mentre i 3.897 record indicano le informazioni riconosciute come pertinenti durante la prima analisi. Non esistono quindi elementi per affermare che siano stati compromessi 375.000 clienti SBI, né per stabilire se ogni record identificato corrisponda a una persona differente. Tra le informazioni segnalate figurano nomi, numeri telefonici registrati, date di nascita, genere, indirizzi email e residenziali, identificativi delle filiali, codici CIF, lead ID e metadati relativi a pratiche di finanziamento. La banca ha attivato i protocolli di risposta agli incidenti e incaricato un’agenzia indipendente accreditata CERT-In di verificare l’autenticità dei dati, individuare l’origine dell’esposizione e determinarne la reale estensione. A differenza di Zeabur, SBI non ha ancora documentato un percorso tecnico di intrusione nei propri sistemi, né ha attribuito la fuga a un gruppo criminale o a una specifica vulnerabilità. La vicenda presenta un problema di riservatezza comparabile, per tipologia di informazioni, al data breach TeamSystem che aveva coinvolto dati contabili, IBAN e movimenti, ma l’accertamento delle responsabilità e delle modalità di accesso resta distinto.

Dati bancari, prestiti e identità digitali aumentano il rischio di frodi mirate

La composizione del dataset individuato da SBI introduce rischi che non dipendono necessariamente dalla compromissione diretta degli account bancari. Numeri telefonici, date di nascita, riferimenti alle filiali e informazioni sulle richieste di finanziamento possono essere utilizzati per costruire comunicazioni fraudolente altamente credibili, nelle quali il criminale si presenta come un operatore della banca facendo riferimento a dati realmente associati al destinatario. La presenza degli identificativi CIF, utilizzati per collegare informazioni e rapporti alla posizione del cliente, e dei lead ID rende il materiale potenzialmente utile per attività di impersonificazione e social engineering. La comunicazione regolamentare non segnala invece il furto di password di home banking, codici OTP o numeri completi delle carte, né documenta operazioni finanziarie fraudolente già effettuate grazie ai record individuati. Un’esposizione di informazioni personali non coincide automaticamente con la sottrazione di denaro o con la compromissione del sistema bancario centrale. State Bank of India dichiara infatti che le proprie attività principali, i risultati finanziari e la continuità operativa non hanno subito conseguenze materiali, mentre proseguono gli accertamenti sull’origine dei dati. Il rischio concreto riguarda quindi anche ciò che potrebbe avvenire successivamente alla pubblicazione del dataset, quando informazioni apparentemente innocue vengono combinate per convincere una vittima a comunicare credenziali o autorizzare operazioni. È una dinamica emersa anche nelle campagne di phishing successive al caso Revolut, con richieste di selfie e procedure KYC fraudolente. Nel caso SBI non è però stata dimostrata una campagna analoga: la valutazione del rischio deve rimanere separata dai fatti già accertati.

Continua con:

Revolut, il Garante allarga il caso alle banche italiane: caccia alle PEC anomale

Data breach sempre più veloci: AI, API e credenziali rubate aprono i database

Due incidenti indipendenti mostrano i limiti della fiducia nelle infrastrutture digitali

Zeabur e State Bank of India rappresentano due livelli differenti della crisi di fiducia nei servizi digitali. Nel primo caso esiste una ricostruzione tecnica dettagliata: sono confermati gli accessi abusivi, la lettura di milioni di record, l’impiego di credenziali amministrative e la compromissione di server gestiti per conto dei clienti. L’azienda ha riconosciuto responsabilità organizzative, difetti di architettura e una risposta incompleta al precedente incidente, arrivando alla decisione di cessare le attività. Nel secondo caso sono stati identificati record contenenti dati personali all’interno di un archivio circolante sul dark web, ma non è ancora accertato il percorso che ha prodotto l’esposizione. Accostare le due notizie non significa equipararne le prove o attribuire a SBI una compromissione infrastrutturale analoga a quella di Zeabur. La conseguenza comune riguarda piuttosto la gestione delle informazioni affidate a servizi considerati attendibili: variabili d’ambiente, chiavi API e credenziali cloud possono diventare strumenti per ampliare un attacco, mentre dati anagrafici e bancari possono alimentare frodi successive anche senza interrompere i servizi finanziari. Per le imprese italiane la vicenda Zeabur ribadisce l’importanza di poter esportare dati, ruotare credenziali e trasferire applicazioni senza dipendere completamente dal fornitore; il caso SBI richiama invece la necessità di monitorare la circolazione delle informazioni personali e verificare i collegamenti tra archivi bancari, partner e servizi esterni. La continuità operativa non dimostra l’assenza di un data breach, così come la presenza di dati sul dark web non dimostra da sola una violazione del sistema centrale di un’organizzazione. È questa distinzione che permette di misurare correttamente l’impatto degli incidenti e stabilire quali responsabilità siano già documentate.