IDCF Cloud ransomware: 495 clienti e dati recuperabili solo dai backup

🛡️ Executive Summary

• IDC Frontier conferma un ransomware contro quattro zone di East Japan Region 1, con 495 aziende ed enti locali interessati.
• Il provider considera difficile recuperare i dati presenti nell’ambiente colpito e indica come strada di ripristino i backup conservati autonomamente dai clienti.
• L’attaccante rivendica cifratura di database, dischi VM e cancellazione di snapshot, ma queste quantità non sono state confermate da IDC Frontier.

Il ransomware che ha colpito IDCF Cloud non è più soltanto un’interruzione di servizio. IDC Frontier ha comunicato che i dati conservati in quattro zone della propria East Japan Region 1 risultano difficili da estrarre o ripristinare e che, secondo la valutazione attuale, il recupero è possibile attraverso le copie di backup mantenute autonomamente dai clienti. Sono coinvolte 495 aziende ed enti locali. È questo il punto che trasforma l’incidente in un caso rilevante per l’intero mercato cloud: la concentrazione dell’infrastruttura permette a un singolo attacco di colpire contemporaneamente centinaia di tenant e rende decisiva la separazione reale tra ambiente di produzione e sistema di recovery.

Quattro zone IDCF sono ferme e i dati risultano difficili da recuperare

Nella terza comunicazione ufficiale sull’incidente IDC Frontier identifica come colpite le zone tesla, henry, pascal e joule di East Japan Region 1. L’attacco è iniziato intorno alle 3:40 del 7 ottobre e ha provocato l’arresto delle macchine virtuali e l’impossibilità di riavviarle. Il provider ha isolato East Japan Region 1 dalla rete, fermato i sistemi e sospeso il management console anche nelle altre regioni mentre continua le verifiche. La novità più grave riguarda però lo storage: IDC Frontier afferma che, allo stato attuale dell’indagine, i dati conservati nelle quattro zone compromesse hanno prospettive difficili di estrazione e recupero. Ai clienti viene quindi indicata la ricostruzione in un ambiente differente utilizzando backup conservati dal cliente, mentre il vettore iniziale e l’eventuale sottrazione di informazioni restano ancora sotto indagine.

Leggi anche: VMware vCenter sotto attacco: due campagne su CVE-2026-59310 e CVE-2026-59309

Il ransomware colpisce il livello dove centinaia di macchine condividono il destino

L’effetto moltiplicatore è la parte più importante dell’incidente. IDCF Cloud fornisce macchine virtuali, storage e rete a organizzazioni che non hanno necessariamente rapporti tra loro, ma dipendono dalla stessa infrastruttura sottostante. Compromettere quel livello permette quindi di provocare conseguenze su numerosi servizi senza violare separatamente ciascuna azienda o amministrazione. Questo non significa che tutti i 495 clienti abbiano subito una compromissione individuale o una sottrazione di dati: il numero indica gli utilizzatori dell’ambiente interessato, non 495 intrusioni distinte. Il rischio sistemico è però evidente e richiama la logica osservata negli attacchi contro gli ambienti VMware, dove raggiungere vCenter ed ESXi consente di agire contemporaneamente su molte macchine virtuali invece di cifrare server uno alla volta.

L’attaccante rivendica 3,6 petabyte cifrati ma i numeri non sono confermati

Il quadro tecnico diventa ancora più aggressivo nelle informazioni ottenute da che ha documentato screenshot della nota mostrata nel console ai clienti, nella quale l’attore sostiene di avere impiegato sette minuti per compromettere l’ambiente, cifrato 225 database per complessivi 3,6 PB, raggiunto 239 hypervisor, bloccato 16.000 dischi di macchine virtuali e cancellato 554.153 snapshot.

Sono dichiarazioni dell’aggressore e non risultano confermate da IDC Frontier, quindi non possono essere utilizzate come misura accertata dell’impatto. La comunicazione del provider conferma però due elementi compatibili con un danno profondo al livello di virtualizzazione e storage: le VM delle zone interessate non possono essere riavviate e il recupero dei dati presenti nell’ambiente è considerato difficoltoso.

Gli snapshot nel cloud non possono sostituire un backup realmente separato

L’incidente mette sotto pressione una delle assunzioni più pericolose nelle strategie di continuità: considerare automaticamente una copia presente nello stesso ambiente cloud come un backup indipendente. IDC Frontier non ha confermato la cancellazione dei 554.153 snapshot rivendicata dall’attaccante, quindi quel numero deve restare fuori dai fatti accertati.

La richiesta ai clienti di ricostruire utilizzando copie detenute autonomamente dimostra però perché il recovery non possa dipendere esclusivamente dallo stesso dominio infrastrutturale che ospita produzione e workload. Il problema è analogo a quello che rende Veeam un bersaglio privilegiato nelle intrusioni ransomware: neutralizzare o rendere inaccessibile il livello di recupero aumenta drasticamente il danno operativo anche quando l’organizzazione dispone formalmente di procedure di backup.

Il blast radius raggiunge aziende e amministrazioni senza colpire direttamente le loro reti

L’impatto non resta confinato al provider. La sospensione delle macchine virtuali può rendere indisponibili siti, applicazioni e servizi ospitati dai clienti pur senza alcuna compromissione diretta delle rispettive reti interne. È la natura stessa dell’IaaS a creare questa dipendenza: applicazione, sistema operativo e organizzazione possono essere separati, ma storage, hypervisor, rete e piano di gestione rappresentano punti di concentrazione. Il Giappone aveva già affrontato incidenti nei quali la sicurezza di un fornitore diventava immediatamente un problema per una platea molto più ampia, come nel caso di Sakura Internet e delle verifiche su oltre un milione di account potenzialmente interessati. Nel caso IDCF la differenza è che l’indisponibilità della piattaforma è già confermata e il provider sta chiedendo una vera ricostruzione degli ambienti colpiti.

Continua con:

Veeam, Terraform MCP e n8n espongono credenziali e accessi aziendali

Keio affronta un ransomware contenuto dalla separazione delle reti

Il cloud non elimina il disaster recovery ma obbliga a separarlo dal provider

IDCF Cloud offre regioni e zone differenti proprio per costruire architetture distribuite, ma l’incidente mostra che la disponibilità geografica non coincide automaticamente con l’indipendenza del recovery. IDC Frontier non ha rilevato accessi non autorizzati nelle altre regioni al momento dell’ultimo aggiornamento, ma ne ha comunque sospeso temporaneamente il console amministrativo durante le verifiche. Per i clienti coinvolti la priorità non è attendere semplicemente che il provider riaccenda le VM: la società stessa indica la costruzione di un nuovo ambiente e il ripristino dai backup autonomamente disponibili. Il principio operativo è netto. Un workload ospitato nel cloud resta vulnerabile alla compromissione del livello che lo sostiene e un backup efficace deve sopravvivere anche all’ipotesi che provider, console, snapshot e storage primario diventino contemporaneamente indisponibili. È questo, più delle quantità rivendicate dal ransomware, il dato strategico lasciato dall’incidente giapponese.