La parte que de verdad duele del informe que IDC Frontier publicó hoy no es el ransomware. Es el orden de las frases. Explotaron una vulnerabilidad de un software de código abierto que usaba el sistema de autenticación de su portal de clientes. Desde el sistema de autenticación llegaron a la consola de gestión. Y desde la consola de gestión obtuvieron permisos de administrador sobre el plano de virtualización. Cuatro saltos, y en el último estaban las máquinas de 495 empresas y administraciones. La pregunta que deja encima de la mesa no va de Japón: ¿cuántos saltos hay, en tu caso, entre un formulario de login publicado en internet y la credencial que puede borrar tus copias?
Qué dice el informe, con sus palabras
IDC Frontier es un proveedor japonés de datacenter y cloud, filial de SoftBank. El 7 de octubre de 2026, sobre las 3:40 de la madrugada, los servidores virtuales de parte de su «región Este de Japón 1» —las zonas tesla, henry, pascal y joule— dejaron de funcionar y no se podían rearrancar. El recuento de afectados no ha cambiado desde entonces: 495 empresas y administraciones. Lo que ha ido cambiando, informe a informe, es la explicación. Hoy, 27 de octubre, han publicado el séptimo, con el que dan por cerrada la investigación y con la causa confirmada.
Dos frases. En la primera estamos en el borde público, en un formulario de login que cualquiera puede cargar. En la segunda ya estamos en la capa que arranca y para las máquinas de todo el mundo. Entre una y otra no había nada que el informe considere digno de mención. Dos cosas sí las descarta, y conviene decirlas antes de seguir: la investigación no encontró salida de datos desde los servidores virtuales de los clientes, y la empresa afirma no haber contactado con el atacante ni haber pagado ni negociado ningún rescate.
Los cuatro saltos
Vale la pena desmontarlo en tramos, porque cada tramo tiene un equivalente exacto en una infraestructura de veinte máquinas. Dos avisos antes de la tabla. La tercera columna no sale del informe: es lo que nosotros miramos cuando revisamos una plataforma. Y el cuarto salto tampoco sale: el informe describe tres fronteras y confirma que las máquinas se pararon y se cifraron. Que el ataque llegara además a los puntos de restauración lo dice el atacante, no la empresa; lo ponemos en la tabla porque es la frontera que a nosotros nos parece decisiva, no porque esté acreditada ahí.
El salto cuatro es el que convierte un incidente en una catástrofe. Los tres primeros te dejan sin servicio; el cuarto te deja sin vuelta atrás. Y es, con diferencia, el más barato de romper, porque en la mayoría de plataformas la copia la hace la misma consola que gestiona la máquina, con la misma cuenta, y vive en el mismo cacharro. Es la variante de infraestructura de algo que ya hemos contado en su versión de identidad: el servidor de copias metido en el mismo dominio es la misma dependencia circular con otro traje.
El número que importa no es 495
Los 495 son los afectados. La cifra interesante es otra, y ha tardado tres semanas en estabilizarse. El 8 de octubre, en el tercer informe, el proveedor dijo que los datos de las cuatro zonas eran difícilmente recuperables o restaurables. El 14 de octubre, en el quinto, matizó: se había confirmado que los datos de copia estaban a salvo y se podían extraer los de 194 clientes. El informe de hoy recoge que el 20 de octubre esa cifra subió a 206.
Doscientos seis de cuatrocientos noventa y cinco. Cuatro de cada diez. Para los otros seis de cada diez, lo que el proveedor puso por escrito ya el 8 de octubre es que preparen un entorno aparte y reconstruyan allí con la copia que tenga cada cliente por su cuenta. No es una frase cruel ni un intento de escurrir el bulto: es, literalmente, la única salida que queda cuando el punto de restauración vive dentro del radio del incidente. Hoy, con SoftBank detrás, acompañan ese traslado y están operando ellos mismos la plataforma por cuenta del cliente mientras el portal sigue cerrado; pero la restauración sigue saliendo de la copia que cada uno tuviera.
Conviene ser honesto con lo que ese 206 no dice. No sabemos cuántos de los 289 restantes tenían contratado el servicio de snapshot y lo perdieron, y cuántos sencillamente no lo tenían. El informe no lo desglosa. Pero para la decisión que hay que tomar da exactamente igual: desde la silla del cliente, «mi copia no existía» y «mi copia existía y se fue con lo demás» son el mismo lunes por la mañana.
Y luego está el reloj. Hoy mismo publicábamos que, de más de ochocientas intervenciones con clientes medidas en campo, solo cuatro se acercaron al objetivo de 24 a 48 horas que cada empresa atacada tenía documentado: lo que de verdad tarda una recuperación. Aquí, tres semanas después, la entrega de los datos de copia empezó el 17 de octubre y el portal de gestión todavía no ha reabierto: de momento las operaciones las ejecuta el propio proveedor por cuenta del cliente. Los dos relojes cuentan la misma historia desde extremos distintos.
Lo que el atacante escribió en la consola
Un paréntesis, con la etiqueta bien puesta. Desde el 7 de octubre circularon por X capturas de lo que parecía la propia consola de IDCF, con un mensaje en inglés del atacante que ITmedia vierte al japonés como «hemos tomado la infraestructura» y «vuestra nube es nuestra», y un inventario del daño: 239 hipervisores alcanzados, 225 almacenes de datos cifrados, más de 16.600 discos de máquina virtual, 3,6 PB de almacenamiento primario, 41,5 PB de capacidad de copia perdida y 554.153 snapshots destruidos, todo ello en siete minutos. Preguntada por ello, la empresa respondió que había visto varias imágenes que parecen coincidir con lo que llegó a mostrarse en su consola, pero no ha confirmado ninguna de las cifras, y el informe de hoy tampoco las recoge.
Las tratamos como lo que son: la versión del atacante, sin verificar, y con todo el interés del mundo en sonar enorme. Pero hay un detalle que no depende de si el número es 554.153 o la mitad. Si el borrado de los puntos de restauración se hace desde la capa que los crea, el tiempo que tarda no tiene nada que ver con la cantidad: es una operación de catálogo. Da igual que sean quinientos mil o cinco mil. Por eso ninguna estrategia que consista en «lo veremos en la monitorización y lo pararemos» resiste el planteamiento. No hay ventana de detección que valga contra una llamada a una API de borrado masivo. Lo único que funciona es que esa llamada no pueda alcanzar la copia.
La frase que no está en el informe
El informe dice «una vulnerabilidad de un software de código abierto». No dice cuál. No hay nombre de producto, ni versión, ni identificador de vulnerabilidad. Es una decisión defendible mientras quede alguien sin parchear, y tampoco es obligación suya publicarlo. Pero deja un hueco con consecuencias: ningún lector puede comprobar si ese mismo componente corre también en su casa.
Lo cual tiene su ironía, porque la segunda medida que anuncian para que no se repita es exactamente eso: centralizar en toda la compañía la información de composición del software, que hasta ahora gestionaba cada departamento por su cuenta, y automatizar el cruce con los boletines de vulnerabilidades. Un inventario de dependencias, vamos. El mismo que hace falta para responder a la pregunta de si una biblioteca concreta está dentro de algo que tú instalaste sin saberlo: el inventario que no tiene una línea para la biblioteca que te importa.
El plan de prevención lo ha escrito la víctima
Esta es la parte aprovechable de verdad. Un plan de medidas publicado después de pagar el incidente vale más que cualquier catálogo de buenas prácticas, porque está escrito por alguien que ya sabe qué le falló. Estas son las suyas, resumidas del informe de hoy, convertidas en preguntas que puedes hacerle a tu proveedor —o hacerte a ti mismo si el proveedor eres tú:
- Quién manda en seguridad. Ellos han creado una organización independiente dedicada solo a eso, con expertos externos y la gente de seguridad que ya tenían, reunida. La pregunta trasladada: en tu casa, ¿la seguridad es el trabajo de alguien, o el rato que le sobra a quien mantiene la producción?
- Plan y frecuencia del análisis de vulnerabilidades, por escrito en la normativa interna, y con el alcance ampliado al software de código abierto. Lo segundo es lo relevante: el análisis que no mira las dependencias de terceros no habría encontrado esto.
- Inventario de composición del software unificado (lo llaman SBOM) y cruzado automáticamente con los avisos de vulnerabilidad. Sin esto, la pregunta «¿nos afecta?» se responde a mano y tarde.
- Sustituir el sistema de autenticación propio por un proveedor de identidad externo. Textualmente, «renovar el sistema de autenticación que fue la causa de la intrusión». Mantener tu propio login es mantener tu propia superficie de ataque, con tu propio calendario de parches.
- Restringir el acceso al portal a las direcciones IP del cliente y hacer obligatorio el segundo factor. Dos controles de manual que, aplicados al plano de gestión y no solo al correo, habrían encarecido muchísimo el salto número dos.
Fíjate en lo que no está en esa lista: ni una sola tecnología nueva, ni un producto que comprar. Es una lista de fronteras y de dueños. Lo caro de verdad no era la herramienta; era decidir que el portal de clientes y el plano de virtualización no se tocan.
Cuándo esto NO significa contratar un segundo proveedor
El reflejo de estos días es «hay que estar en dos nubes». Casi siempre es la respuesta equivocada, y es carísima. Duplicar proveedor duplica contratos, equipos, procedimientos y superficie de ataque, y no resuelve el problema si las dos nubes cuelgan de la misma fuente de identidad o se administran desde el mismo portátil: eso es un único dominio de fallo con dos facturas.
Lo que sí cambia el final de la historia es mucho más barato, y cabe en una frase: una copia que viva fuera del plano de control que gestiona la máquina. Otra cuenta, otro sitio, retención que no se pueda acortar desde dentro, y restaurada entera al menos una vez sobre hierro distinto del original. Esa copia es la diferencia entre ser uno de los 206 y ser uno de los otros. No hace falta un segundo proveedor para tenerla; hace falta que no la haga la misma credencial que puede borrarla.
Y una aclaración que nos toca de lleno: nosotros también somos el proveedor de alguien. Tenemos hierro propio en datacenter, consolas de gestión y portales. Esta lista de cinco puntos no es algo que miremos solo hacia fuera cuando auditamos a un tercero; es la que nos aplicamos, y la frontera entre el salto tres y el salto cuatro es la que más nos ha hecho repensar cosas. Escribir un post señalando a un proveedor caído sin decir esto sería bastante barato.
Dónde encaja esto en lo que hacemos
La parte de nuestro trabajo que habla de esto es disaster recovery: dónde está la segunda copia, con qué credencial se escribe, cuánto se tarda en levantarla y sobre qué hierro. Llevamos copias gestionadas con Proxmox Backup Server y Veeam, con filosofía 3-2-1 y retención inmutable, precisamente para que el salto cuatro no exista. La otra mitad es zero trust, que es como llamamos a lo de los saltos dos y tres: que el plano de gestión no sea alcanzable por haber pasado un login, que las identidades del portal y de la plataforma no sean la misma, y que ningún permiso escale solo. Si quieres que dibujemos contigo esos cuatro saltos sobre tu infraestructura concreta —y especialmente el cuarto—, escríbenos.
Fuentes. Los hechos confirmados (fecha y hora del ataque, las cuatro zonas, los 495 clientes, la vulnerabilidad en el software de código abierto del sistema de autenticación del portal, la escalada a administrador del plano de virtualización pasando por la consola de gestión, los 206 clientes con datos de copia extraíbles, la ausencia de fuga de datos de los servidores virtuales de clientes, las consultas indebidas a información de registro de hasta 71 empresas —con nombres o correos de hasta 31— y las 4 contraseñas de acceso modificadas) proceden del séptimo informe oficial de IDC Frontier, publicado el 27 de octubre de 2026; la cifra intermedia de 194 clientes y la valoración de «difícilmente recuperable» son de sus informes del 14 y del 8 de octubre, recogidos en el mismo documento. El plan de medidas está resumido de los apartados 4 (organización de seguridad independiente, análisis de vulnerabilidades ampliado al código abierto y SBOM centralizado) y 5 (reapertura del portal: proveedor de identidad externo y restricción por IP del cliente con MFA obligatoria) de ese informe. La indicación de preparar otro entorno y restaurar desde la copia que conserve cada cliente es del tercer informe, del 8 de octubre. Las cifras del atacante (239 hipervisores, 225 almacenes de datos, más de 16.600 discos de VM, 3,6 PB, 41,5 PB de capacidad de copia, 554.153 snapshots y siete minutos) proceden de capturas difundidas en redes sociales, recogidas por ITmedia NEWS el 9 de octubre de 2026: no están verificadas, la empresa solo ha dicho haber visto imágenes que parecen coincidir con lo mostrado en su consola y no ha confirmado los números; las citamos como versión del atacante y el argumento del post no depende de ellas. El dato del 7 de octubre a las 3:40 y el recuento de 495 aparecen también en la cobertura de Security NEXT. Lo nuestro —la tabla de los cuatro saltos, la lectura del plan de la víctima como lista de preguntas y el criterio sobre el segundo proveedor— es nuestra forma de trabajar, no una recomendación del informe citado. Foto: «Cage Quelle EMC HostCo GmbH» de Virtuo Doc, Wikimedia Commons, CC BY-SA 4.0.
Microsoft 365
ES 
CAT 
EN