IDC Frontier desconecta la infraestructura de nube afectada
IDC Frontier ha revelado que su infraestructura IDCF Cloud sufrió un ataque de ransomware que interrumpió el servicio en East Japan Region 1 y afectó a 495 empresas y gobiernos locales.
La empresa indicó que el ataque comenzó a las 3:40 a. m. del 7 de octubre de 2026, hora local. En respuesta, aisló y apagó los componentes de red y sistemas afectados dentro del clúster regional de centros de datos. El informe sobre el incidente se publicó el 8 de octubre de 2026.
Las medidas de contención también se extendieron más allá de la región afectada. IDC Frontier suspendió el acceso de los clientes a las consolas de administración de IDCF Cloud en todas las regiones mientras realizaba comprobaciones de seguridad. El operador señaló que restablecería el acceso cuando determinara que era seguro utilizar las consolas.
IDC Frontier está investigando la causa y el alcance operativo del incidente. Entre otras tareas, intenta identificar y bloquear la vía de acceso utilizada para penetrar en el entorno y comprobar si existen problemas de seguridad en otras regiones.
IDCF Cloud es una plataforma de infraestructura como servicio que ofrece servidores virtuales, almacenamiento y redes desde centros de datos en Japón. Los clientes dependen de estos recursos para operar sitios web, aplicaciones y sistemas empresariales; por eso, una interrupción en la capa de infraestructura puede afectar a distintos tipos de servicios posteriores.
IDC Frontier es una filial de SoftBank Group, una sociedad de cartera de inversiones multinacional con sede en Tokio. La información publicada se refiere a la infraestructura operada por IDC Frontier y no atribuye el ataque a un incidente independiente que haya comprometido SoftBank Group.
Las cifras de los atacantes no están verificadas
Antes de que se suspendiera el acceso a las consolas de administración, algunos clientes hicieron capturas de pantalla de un mensaje atribuido al atacante. La captura citada en la información publicada procedía de j416dy.
El mensaje afirmaba que el actor había comprometido East Japan Region 1 en siete minutos y había causado daños en bases de datos, hipervisores, discos de máquinas virtuales y snapshots.
| Afirmación del mensaje del atacante | Alcance alegado |
|---|---|
| Tiempo necesario para vulnerar East Japan Region 1 | siete minutos |
| Bases de datos cifradas | 225 |
| Datos asociados a esas bases de datos | 3,6 PB |
| Hipervisores a los que accedió | 239 |
| Discos de máquinas virtuales cifrados | 16.000 |
| Snapshots eliminados | 554.153 |
Estas cifras son afirmaciones del atacante, no mediciones verificadas de forma independiente. IDC Frontier ha confirmado un incidente de ransomware y una interrupción del servicio, pero las cifras del mensaje no deben presentarse como conclusiones forenses confirmadas.
La distinción es especialmente importante en el caso de los 3,6 PB. El mensaje vincula esa cantidad con bases de datos cifradas, pero la información publicada no demuestra que el atacante la exfiltrara. El cifrado y el robo son acciones distintas, y un mensaje de ransomware, por sí solo, no confirma la extracción de datos.
La afirmación sobre los snapshots tampoco está verificada. No permite determinar cuántos había, cuáles eran accesibles desde el entorno comprometido ni si se completaron todos los intentos de borrado.
No se ha documentado la vía de acceso inicial ni la identidad del ransomware
La información disponible hasta el momento no permite reconstruir por completo la intrusión.
La información citada no identifica el método de acceso inicial ni ninguna CVE explotada. Tampoco señala una versión de software afectada, explica cómo obtuvo privilegios el atacante ni describe movimientos entre sistemas.
Por lo tanto, aún no es posible situar la afirmación del actor de que accedió a 239 hipervisores dentro de una secuencia de hechos validada. Si se confirmara, el acceso a esa capa podría ayudar a explicar la interrupción de numerosas cargas de trabajo alojadas. Por ahora, sin embargo, sigue siendo parte del relato del atacante.
Tampoco se ha identificado la familia de ransomware. No se ha informado del nombre de ningún operador o campaña, y estas categorías no deben tratarse como equivalentes. Una familia de malware identifica las herramientas utilizadas, mientras que atribuir un ataque a un operador exige pruebas que vinculen a personas o grupos con su despliegue. Para atribuirlo a una campaña, además, hacen falta indicios que relacionen varias operaciones.
Lo que sí se ha confirmado es más limitado: IDC Frontier detectó una interrupción relacionada con ransomware, aisló East Japan Region 1, suspendió el acceso a las consolas de administración en todas las regiones y empezó a investigar la vía de intrusión. Las pruebas disponibles no documentan una cadena completa que abarque el reconocimiento, la entrada, la escalada de privilegios, el acceso a los hipervisores, el cifrado y la supuesta destrucción de snapshots.
No hay pruebas que vinculen la interrupción de Nissui Logistics con el ataque
Nissui Corporation informó por separado de que su filial logística, Nissui Logistics, sufrió una interrupción de sus sistemas tras sospecharse un acceso no autorizado a un centro de datos de terceros.
La fuente señala que Nissui hizo el anuncio «ayer», en relación con la fecha del informe, pero no proporciona una fecha concreta aparte. Debido a la interrupción, no se pudieron enviar ni recibir mercancías, y la empresa estaba investigando si se habían filtrado datos personales o de clientes.
Nissui es un grupo japonés dedicado a los productos del mar y la alimentación que cuenta con aproximadamente 11.500 empleados. Sus operaciones internacionales abarcan la pesca, la acuicultura, el procesamiento y la venta, por lo que la interrupción de los sistemas de su filial afectó a la logística física, no solo al acceso a servicios de TI.
No hay ninguna conexión demostrada entre este incidente y el ataque de ransomware contra IDCF Cloud. La información publicada no aporta datos sobre infraestructuras compartidas, indicadores técnicos, identificación del ransomware ni conclusiones forenses que relacionen ambos incidentes. La proximidad temporal y el uso de servicios de centros de datos de terceros no bastan para atribuirlos al mismo operador o campaña.
Macnica registra un aumento más amplio de los incidentes en Japón
Yutaka Sejiyama, investigador de Macnica, situó la interrupción de IDCF Cloud en el contexto de un patrón más amplio de incidentes cibernéticos que afectan a organizaciones japonesas.
Desde principios de año, Macnica ha registrado 119 incidentes relacionados con el robo de datos personales o la exposición de información. El recuento incluye 83 incidentes entre el 1 de julio y el 6 de octubre. Con los mismos criterios, la empresa de seguridad registró 84 incidentes en 2025 y 62 en 2024.
Según el análisis resumido, los atacantes han estado buscando en sitios web y API fallos de control de acceso, configuración y autenticación. También han aprovechado vulnerabilidades conocidas o de tipo «n-day».
Sejiyama sugirió que las herramientas de IA potentes y económicas podrían reducir el esfuerzo necesario para analizar sitios web concretos en busca de debilidades específicas. Tradicionalmente, este tipo de análisis requería tiempo y mano de obra suficientes como para que los objetivos más pequeños resultaran menos atractivos.
Esta evaluación se refiere al panorama general de incidentes. No demuestra que se utilizaran herramientas de IA contra IDCF Cloud ni identifica la vulnerabilidad o el método de acceso implicados en el incidente de IDC Frontier.
Prioridades defensivas mientras continúa la investigación
Las medidas de IDC Frontier que se han hecho públicas se centran en la contención y la verificación. El operador aisló los sistemas afectados, apagó componentes de East Japan Region 1, restringió el acceso a las consolas de administración y empezó a revisar las demás regiones. También está intentando identificar y cerrar la vía de intrusión.
La información citada no ofrece parches, soluciones provisionales ni procedimientos de recuperación específicos para los clientes. Tampoco indica ninguna CVE o versión de producto que permita elegir una actualización de seguridad. Por tanto, las organizaciones no deberían dar por hecho que un parche de software no relacionado resuelve este incidente.
Mientras esperan instrucciones específicas para el servicio, los clientes pueden centrarse en evaluar su propia exposición y capacidad de recuperación. Entre otras medidas útiles, pueden identificar las cargas de trabajo alojadas en East Japan Region 1, documentar sus dependencias del almacenamiento y las redes de IDCF Cloud, y conservar los datos de telemetría pertinentes de aplicaciones, autenticación y red.
La planificación de la recuperación debería abordar por separado varias cuestiones: si se puede acceder al servicio de nube, si es posible restaurar las máquinas virtuales y si los datos de las aplicaciones mantienen su coherencia interna. Los clientes también deberían comprobar si sus copias de recuperación independientes dependen de las mismas credenciales o del mismo plano de administración. Se trata de medidas generales de resiliencia, no de pruebas de que se haya accedido a las copias de seguridad de algún cliente.
La información citada no proporciona indicadores específicos del incidente para realizar búsquedas directas de amenazas. Aun así, los equipos de defensa pueden revisar sus propios entornos para detectar actividad administrativa inusual, cambios de credenciales sin explicación y operaciones inesperadas de almacenamiento o cargas de trabajo, y contrastar cada evento con los patrones operativos habituales.
Por ahora, lo confirmado es una interrupción operativa de gran alcance y medidas de contención agresivas. Las estimaciones de daños más elevadas —incluidos 3,6 PB de datos cifrados y 554.153 snapshots eliminados— siguen siendo afirmaciones del atacante a la espera de validación forense.
