Nikkei: credenziali rubate, esposti 1,83 milioni di record

Nikkei Inc., il gruppo giapponese di informazione economica e finanziaria che pubblica il quotidiano Nikkei e il Financial Times, ha comunicato una nuova violazione di dati: con credenziali rubate in precedenza, qualcuno è entrato in un servizio cloud usato per lo sviluppo dei sistemi e ha avuto accesso a circa 1,83 milioni di record. Secondo BleepingComputer è il terzo incidente di sicurezza reso noto dall’azienda in circa un mese.

Cosa è successo

Secondo l’avviso pubblicato da Nikkei, riportato da BleepingComputer, SecurityWeek e Security Affairs, l’accesso non autorizzato è avvenuto nelle prime ore del mattino del 7 ottobre 2026. Chi ha attaccato ha usato credenziali di accesso già compromesse; l’azienda le ha revocate dopo aver scoperto l’accesso e l’11 ottobre ha notificato la violazione alla Personal Information Protection Commission, l’autorità giapponese per la protezione dei dati.

Le fonti descrivono il sistema colpito in modo leggermente diverso: per SecurityWeek e Security Affairs, che citano l’avviso, si tratta di un servizio cloud usato da Nikkei per lo sviluppo dei sistemi; per BleepingComputer di un sistema di sviluppo nella rete dell’azienda, attraverso il quale sono stati esposti dati personali conservati nel cloud. Nikkei non ha indicato quale servizio sia, né come siano state rubate le credenziali.

Dati coinvolti

Secondo l’avviso, al 16 ottobre risultano coinvolti circa 1,83 milioni di elementi di informazioni personali:

• circa 150.000 contengono almeno uno di questi dati: nome, indirizzo email, indirizzo postale, numero di telefono, data di nascita;
• di questi, circa 120.000 comprendono un indirizzo email;
• circa 1,68 milioni contengono solo informazioni che, da sole, non identificano una persona;
• nessun record contiene dati di carte di credito.

Al 16 ottobre Nikkei dichiara di non aver trovato prove di uso illecito dei dati né, secondo BleepingComputer, della loro pubblicazione online; non ci sono stati disservizi né modifiche ai dati. L’indagine sulla portata dell’incidente e sulla causa è ancora in corso e le persone coinvolte saranno avvisate una per una.

Gli incidenti precedenti

Secondo BleepingComputer, all’inizio di ottobre Nikkei aveva già reso nota una violazione avvenuta a fine luglio: era stato compromesso l’account Google Workspace di un dipendente, con accesso a dati personali di dipendenti e partner commerciali. A settembre l’azienda aveva comunicato che l’account Microsoft 365 di un altro dipendente era stato usato per mandare email di spear phishing al personale. SecurityWeek e Security Affairs ricordano anche una violazione partita da un account Slack compromesso, resa nota, secondo Security Affairs, nel novembre 2025.

Nikkei non ha detto se le credenziali usate il 7 ottobre provengano da uno degli incidenti precedenti: con le informazioni pubbliche il collegamento non si può stabilire.

Dettagli tecnici

Non ci sono CVE né malware: l’ingresso è avvenuto con credenziali valide. Con quanto noto, lo schema rientra nelle tecniche MITRE ATT&CK Valid Accounts: Cloud Accounts (T1078.004) e, per la raccolta dei dati, Data from Cloud Storage (T1530). Non sono stati pubblicati indicatori di compromissione.

Il punto che interessa chi gestisce sistemi è il luogo dell’incidente: un ambiente di sviluppo che conteneva dati personali reali, 1,83 milioni di record. Gli ambienti di sviluppo e di prova hanno spesso controlli più deboli di quelli di produzione (account condivisi, chiavi di lunga durata, meno monitoraggio), ma possono contenere copie degli stessi dati.

Impatto per le aziende europee e italiane

Per il GDPR, i dati personali negli ambienti di sviluppo sono trattati come quelli di produzione: servono le stesse misure di sicurezza (art. 32) e la protezione dei dati fin dalla progettazione (art. 25), cioè dati minimi, pseudonimizzati o sintetici. Un accesso non autorizzato a quei dati è una violazione da valutare per la notifica all’autorità di controllo entro 72 ore.

Per i soggetti NIS2 (in Italia il d.lgs. 138/2024) la gestione degli accessi, l’autenticazione a più fattori e la sicurezza nello sviluppo dei sistemi sono tra le misure di gestione del rischio previste.

C’è poi il rischio indiretto: 120.000 indirizzi email associati a nomi e recapiti permettono phishing credibile a nome di Nikkei o del Financial Times, anche verso dipendenti di aziende europee abbonate.

Cosa fare subito

1. Censisci gli ambienti di sviluppo e di prova nel cloud: quali servizi, chi vi accede, quali dati contengono. Tratta allo stesso modo repository, database di prova e archivi di oggetti.
2. Togli i dati personali reali dagli ambienti di sviluppo: usa dati sintetici o mascherati; dove servono dati reali, solo il minimo, con scadenza e cancellazione.
3. Proteggi gli accessi come in produzione: single sign-on aziendale, autenticazione a più fattori resistente al phishing (FIDO2 o passkey), niente account condivisi, chiavi API e token di breve durata.
4. Dopo ogni account compromesso, ruota tutto quello che poteva vedere: password, token, chiavi e segreti salvati in email, chat e documenti, non solo la password dell’account colpito.
5. Porta i log del cloud nel monitoraggio: accessi da paesi o dispositivi nuovi, accessi fuori orario, esportazioni massicce di dati, nuove chiavi di accesso.
6. Cerca le credenziali aziendali finite nelle violazioni e nei mercati di credenziali rubate, e disattiva quelle trovate.

Come aiuta ARXDOME

ARX Expose segnala gli account aziendali finiti in violazioni note, così le credenziali compromesse si possono disattivare prima che qualcuno le usi. ARX Sentry raccoglie log ed eventi di computer, server e firewall e li raggruppa in famiglie come accessi falliti, uso di credenziali esplicite e modifiche agli account. ARX Retain conserva i log per ricostruire, in caso di indagine, chi ha avuto accesso e quando.

Ultimo aggiornamento: 20 ottobre 2026