Ransomware en IDCF Cloud: 194 de 495 clientes de IDC Frontier podrían recuperar sus instantáneas

El 8 de octubre de 2026, IDC Frontier comunicó a 495 empresas y administraciones locales japonesas que, según su valoración de ese momento, solo podrían recuperar los datos alojados en IDCF Cloud a partir de copias de seguridad que hubieran guardado por su cuenta. El 14 de octubre corrigió esa valoración. Los 194 clientes que usaban la función de instantáneas podrían recuperar sus copias, y la empresa confirmaría a cada uno si la restauración era viable.

Detrás de ambos comunicados está un ataque de ransomware contra IDCF Cloud, la nube pública de esta filial del grupo SoftBank, que comenzó la madrugada del 7 de octubre. El atacante comprometió la plataforma compartida, y con ella quedaron detenidos los servicios de los 495 clientes.

¿Qué ocurrió en el ataque de ransomware contra IDCF Cloud?

El ataque comenzó hacia las 3:40 del 7 de octubre de 2026, hora de Japón, en la Región 1 de Japón Oriental de IDCF Cloud, según el tercer comunicado de IDC Frontier. Ese mismo día la empresa aisló de la red la región, donde están las cuatro zonas afectadas (tesla, henry, pascal y joule), y suspendió la consola de gestión de clientes en todas sus regiones. También comunicó el incidente a los ministerios competentes y a la Policía Metropolitana de Tokio.

Los servicios IDCF Cloud TypeS e IDCF Private Cloud no se vieron afectados. En su comunicado del 14 de octubre, la empresa añadió que las demás zonas y regiones no sufrieron interrupción del servicio.

El 8 de octubre, BleepingComputer informó de unas capturas difundidas en redes sociales con la nota del atacante en la consola de clientes. En ellas, los atacantes afirman haber alcanzado 239 hipervisores, cifrado 225 almacenes de datos de virtualización (datastores) con 3,6 PB y destruido 554.153 instantáneas. IDC Frontier no ha verificado esas cifras y, según la cronología del analista japonés piyolog, estaba comprobando si la imagen era auténtica. Ningún grupo ha sido identificado públicamente.

El quinto comunicado, del 14 de octubre, recoge que la investigación con una empresa de seguridad externa no ha encontrado indicios de que los datos de los clientes en las cuatro zonas se consultaran o exfiltraran. Sí ha detectado consultas no autorizadas, a través del portal de IDCF Cloud, a los datos de registro de 48 empresas: nombre, identificador de acceso, contraseña guardada como hash, direcciones de correo de aviso e importe mensual. La empresa no ha encontrado indicios de que esos datos salieran de la plataforma, y la vía de entrada sigue sin publicarse.

¿Cómo afectó el ataque a los clientes de IDCF Cloud?

¿Cuántos clientes de IDCF Cloud pueden recuperar sus instantáneas?

Hasta 194 de los 495 clientes afectados, los que usaban la función de instantáneas, podrán recuperar sus copias, según el comunicado de IDC Frontier del 14 de octubre de 2026. La empresa comunicará a cada uno si la restauración es factible y cómo se entregarán los datos, según recoge Impress Watch. En su comunicado del 8 de octubre daba por difícil extraer o restaurar los datos de las zonas afectadas.

Durante esa semana, los 194 clientes ignoraban si sus instantáneas seguían existiendo, y todavía esperan la confirmación individual. Para los 301 restantes, el comunicado no describe ninguna vía de recuperación más allá de lo que cada uno guardara por su cuenta.

¿Cómo se recuperó Six Apart con copias fuera del proveedor?

Six Apart, que ofrece la versión en la nube de Movable Type, empezó a trasladar a Sakura Cloud sus 31 servidores de la región afectada a partir de copias guardadas en otro proveedor. Según su aviso a clientes del 8 de octubre, cada servidor conservaba siete generaciones de copias diarias en Google Cloud, y la migración partió de la copia de la 1:00 del 7 de octubre.

Six Apart advierte en la misma nota de que cambian las direcciones IP, de que algunas especificaciones como el almacenamiento pueden no coincidir con el plan anterior y de que la migración lleva tiempo. Los cambios hechos entre la 1:00 y el inicio del incidente, hacia las 3:40, no están en esa copia.

¿Por qué la consola de IDCF Cloud fue un segundo punto de exposición?

La consola de clientes de IDCF Cloud expuso los datos de registro de 48 empresas. Al suspenderse, dejó sin gestión a los clientes de todas las regiones, también los de zonas que funcionaban. Según el comunicado del 8 de octubre, IDC Frontier arrancaba y detenía los servidores virtuales a petición de cada cliente mientras la consola estaba parada. El comunicado del 14 de octubre precisa que las direcciones de correo de dos de esas 48 empresas podrían incluir nombres de personas.

¿Cuándo pudo JR East descartar la fuga de datos?

JR East, cuyo proveedor de envío de correo trabajaba sobre la plataforma de IDC Frontier, comunicó el 15 de octubre que ese proveedor descartaba la fuga de datos personales, seis días después de su primer aviso. En el comunicado del 9 de octubre, la compañía ferroviaria no descartaba que se hubieran consultado las direcciones de correo de hasta 1,67 millones de socios de Eki-net. Para unos 390.000 socios del club Otona no Kyujitsu, los datos en riesgo incluían además el número de socio, la fecha de caducidad de la tarjeta de crédito y la fecha de nacimiento.

Tanto el proveedor de correo como JR East dependían de la investigación de IDC Frontier para decidir qué comunicar y cuándo. Ya analizamos este patrón en otros avisos de brecha cuya causa raíz estaba en un tercero. Cuando los datos decisivos los tiene otra empresa, cumplir plazos de notificación como los de NIS2 se complica.

¿Están los atacantes apuntando a los hipervisores de los proveedores de nube?

Los atacantes empiezan a apuntar a la capa de virtualización de los proveedores, donde un solo acceso afecta a muchos clientes. En septiembre analizamos cómo una actualización maliciosa de Virtualizor, distribuida tras un secuestro BGP, dio acceso root a hipervisores de proveedores de alojamiento. Si las cifras del atacante se confirman, IDCF Cloud sería otro caso de daño causado en el hipervisor del proveedor.

En Japón, la consultora Macnica contabiliza en 2026 119 incidentes con robo o exposición de datos personales, 83 de ellos entre el 1 de julio y el 6 de octubre, frente a 84 en todo 2025 y 62 en 2024, según BleepingComputer.

¿Por qué una instantánea en el mismo proveedor de nube no protege frente al ransomware?

Una instantánea guardada en la misma plataforma comparte con la máquina original la consola de gestión, las credenciales y a menudo la ubicación física. Por eso queda al alcance de quien controle la plataforma. Sirve para revertir un error humano o un fallo de disco. En el modelo de responsabilidad compartida de la nube pública, el proveedor protege la plataforma y la recuperabilidad de los datos corresponde al cliente.

El comunicado de IDC Frontier del 8 de octubre lo dejaba claro para este caso: «según nuestra valoración actual, la restauración de los datos solo será posible a partir de las copias de seguridad que conserve el cliente». El 14 de octubre, la empresa anunció que prepara un método más sencillo para que los clientes de las zonas no afectadas respalden sus datos.

¿Dónde guardar las copias de seguridad fuera del proveedor de nube?

Una copia que sobreviva a la caída del proveedor de nube reúne estas condiciones:

• Una copia en otra cuenta, otro proveedor u otra ubicación, con credenciales que no se puedan obtener desde el entorno de producción. La regla 3-2-1-1-0 exige esta separación, que la distingue de una réplica, como explicamos en la guía de copias de seguridad resistentes al ransomware.
• Retención bloqueada en modo de cumplimiento en esa copia externa, que la convierte en copia inmutable. Ni un administrador comprometido puede borrarla antes de tiempo.
• Infraestructura como código ensayada en un segundo proveedor, con el cambio de direcciones IP, DNS y certificados resuelto en el procedimiento.
• Un objetivo de punto de recuperación (RPO) medido y aceptado por la dirección. En el caso de Six Apart, quedaron fuera de la copia los cambios de las 2 horas y 40 minutos entre la copia de la 1:00 y el inicio del incidente, y con copias diarias el peor caso habría rozado un día entero.
• Cláusulas con el proveedor sobre plazos de comunicación y acceso a las conclusiones forenses que afecten a los datos del cliente, porque de ellas depende la notificación que el cliente deba hacer.

Estas medidas se integran en un plan de continuidad de negocio que se pueda ensayar, con un servicio de continuidad y recuperación ante desastres y con la gestión del riesgo de terceros para la parte contractual. Siguen siendo necesarias la autenticación multifactor (MFA) resistente al phishing en las consolas de nube y una segmentación de red que limite lo que un acceso puede alcanzar.

¿Equivale la redundancia del proveedor de nube a una copia de seguridad?

La replicación entre zonas de un proveedor de nube protege frente a un incendio o un corte eléctrico. Sin embargo, un adversario con acceso a la gestión puede cifrar o borrar la réplica igual que el original. Un acuerdo de nivel de servicio (SLA) mide la disponibilidad del servicio y no cubre la integridad de los datos.

¿Qué exigen DORA, NIS2 y el ENS sobre copias y planes de salida del proveedor de nube?

El artículo 12 del Reglamento DORA exige a las entidades financieras políticas de copia documentadas y pruebas periódicas de restauración. Cuando restauran con sus sistemas, estos deben estar separados física y lógicamente del sistema de origen. El artículo 28.8 les pide estrategias de salida documentadas y probadas para los servicios TIC que soportan funciones críticas o importantes.

La directiva NIS2 incluye en su artículo 21.2 la continuidad de negocio, con la gestión de copias de seguridad y la recuperación ante desastres, junto a la seguridad de la cadena de suministro. En el sector público español y sus proveedores, el ENS dedica a las copias de seguridad la medida mp.info.6.

Para las entidades sujetas a DORA, es probable que un plan de salida que nunca se ha ensayado acabe siendo un hallazgo de auditoría. En el perímetro de NIS2, cabe esperar lo mismo de unas copias que nunca se han restaurado.

¿Qué se desconoce todavía del ataque a IDCF Cloud?

IDC Frontier no ha explicado cómo entró el atacante ni ha confirmado las cifras de hipervisores e instantáneas destruidas. Tampoco consta cuántos de los 301 clientes que no usaban instantáneas guardaban copias fuera de la plataforma. A 16 de octubre de 2026, la empresa no ha dado fecha para la confirmación individual a los 194 clientes con instantáneas.

Fuentes y atribución: los hechos descritos se basan en los comunicados públicos de IDC Frontier, JR East y Six Apart y en la cobertura de medios especializados. La información está actualizada a 16 de octubre de 2026.

Ninguna mención implica un fallo de seguridad en los productos citados mientras no se publique la vía de entrada. Las cifras atribuidas al atacante no están verificadas, y la atribución a un grupo podría cambiar a medida que avance la investigación.

Aviso de análisis: este artículo interpreta datos de terceros con fines divulgativos y no constituye asesoramiento jurídico. La aplicación de DORA, NIS2 o el ENS a cada organización debe valorarse caso por caso.