Un ataque de ransomware golpea a IDC Frontier, de SoftBank, y afecta a 495 clientes

El 7 de octubre de 2026, IDC Frontier, empresa de Tokio que ofrece servicios en la nube y pertenece a SoftBank, comunicó que había sufrido un ciberataque con ransomware. La caída de su infraestructura informática afectó a 495 clientes corporativos y a administraciones locales de Japón. Según The Asahi Shimbun, a 8 de octubre los especialistas en ciberseguridad seguían ocupándose de las consecuencias del incidente. Se interrumpió el funcionamiento de la logística y de los servicios de administración electrónica.

Qué se sabe y qué no

La información pública es escasa. La compañía confirmó el hecho del ataque con ransomware y su alcance: 495 clientes. La prensa japonesa señala los ámbitos afectados: la logística y los servicios digitales del Estado. En fuentes abiertas no hay nada más.

Se desconoce qué familia de ransomware usaron los atacantes y si exigieron un rescate. No se ha aclarado si se robaron datos de los clientes o si el cifrado se limitó a la infraestructura del proveedor. Tampoco hay una estimación del plazo de recuperación completa. Estas lagunas importan: de ellas depende que el incidente quede en una caída operativa o derive en una filtración.

• Compañía: IDC Frontier Inc., Tokio, servicios en la nube y centros de datos
• Propietario: SoftBank
• Fecha del aviso del ataque: 7 de octubre de 2026
• Tipo de ataque: ransomware (cifrador)
• Afectados: 495 clientes corporativos y administraciones locales
• Ámbitos afectados: logística, servicios de administración electrónica
• Estado a 8 de octubre: la investigación y la recuperación continuaban

Por qué un ataque a un proveedor es más peligroso que uno a una sola empresa

Cuando el ransomware entra en la infraestructura de un operador de nube, golpea de una vez a todos los que viven en ella. Un único punto de entrada se convierte en cientos de paradas. Los clientes no han cometido ningún error: sus propios sistemas pueden estar perfectamente protegidos, pero simplemente no tienen dónde funcionar.

El sector ya tiene precedentes similares. En 2022, un ataque al proveedor de hosting Rackspace dejó fuera de servicio su servicio de correo Exchange alojado. En 2024, un ransomware paralizó a CDK Global, proveedor de software para concesionarios de automóviles en EE. UU., y miles de concesionarios volvieron al papel. En Japón, en 2023, un ataque al sistema del puerto de Nagoya detuvo la operación de una terminal de contenedores. La lógica es siempre la misma: cuantos más procesos dependen de una plataforma común, mayor es el coste de que falle.

Para Japón, el caso es significativo también porque entre los afectados figuran municipios. Los servicios públicos se alojan cada vez más en proveedores de nube comerciales, y la resistencia de ese modelo la determina el eslabón más débil de la cadena de contratistas.

Los centros de datos están ahora en el foco por otra razón. SoftBank invierte con fuerza en infraestructura para IA, y las cargas de entrenamiento e inferencia se trasladan a las mismas nubes y espacios de colocation donde ya operan las empresas y el Estado. Cuanto más densa se vuelve esa infraestructura, más alto es lo que está en juego en su protección.

Qué deben revisar los equipos que dependen de la nube

El motivo para una revisión no es solo este incidente, sino el propio formato del riesgo. El conjunto mínimo de preguntas para la arquitectura informática propia es el siguiente.

• ¿Están las copias de seguridad fuera de la infraestructura del proveedor principal y desconectadas de la red (almacenamiento offline o immutable)?
• ¿Cuándo fue la última vez que se probó una restauración completa desde el backup, midiendo el tiempo real?
• ¿Existe un proceso manual de emergencia para las operaciones críticas, como los envíos o la recepción de solicitudes, por si hay varios días de caída?
• ¿Qué dice el contrato con el proveedor sobre los plazos de notificación de incidentes y sobre las compensaciones?
• ¿Están los servicios críticos repartidos entre plataformas o proveedores independientes, y no solo entre zonas de un mismo operador?
• ¿Están los accesos administrativos protegidos con autenticación multifactor y están separados los privilegios?

Además, conviene decidir de antemano quién toma las decisiones en la empresa cuando falla un contratista y cómo se enterarán los clientes del problema. Las primeras horas de una caída suelen perderse en averiguar quién es responsable de qué. La evolución del caso de IDC Frontier mostrará con qué rapidez restableció el proveedor sus servicios y si los datos de los clientes se vieron afectados.