# Hackeo de Onamae Desktop Cloud expone más de 26 mil servidores > GMO Internet confirma el acceso no autorizado a Onamae Desktop Cloud, apaga todos los planes y admite que las credenciales de trading pudieron ser vistas > Por José Maldonado · Ciberseguridad · 2026-10-24 Una consulta de un cliente acabó con miles de servidores apagados en Japón. GMO Internet confirmó que un tercero había instalado programas ajenos en entornos de clientes de Onamae Desktop Cloud, el servicio de servidores virtuales que vende para dejar bots de trading funcionando sin interrupciones. Su primer aviso [cifró en 26.739 los equipos que podrían estar afectados](https://www.onamae.com/news/article/11584), una cifra que mide exposición posible y no infecciones confirmadas. El apagado arrancó el 21 de octubre a las 04:00 hora local y alcanzó a todos los planes del servicio, que sigue sin fecha de reapertura. Detrás de Onamae.com está GMO Internet, uno de los mayores registradores de dominios de Japón, que también vende alojamiento web y DNS. El producto comprometido no era un hosting cualquiera: [la propia empresa lo anunciaba](https://www.bleepingcomputer.com/news/security/japans-onamae-desktop-cloud-hacked-up-to-27-000-servers-affected/) como la opción ideal para mantener MetaTrader 4 en marcha de forma continua, y ahí estaba el problema. Ahí estaban también las credenciales. El segundo aviso de la compañía, publicado el 22 de octubre, admite que los accesos guardados en esas máquinas, incluidos los de las herramientas MT4 y MT5 y los de las cuentas de trading, podrían haber sido vistos por el intruso, y que ya hay clientes que reportan operaciones que no reconocen. Los datos de tarjeta no estaban en esos servidores, un alivio parcial para quien confiaba su dinero a un robot. ## Un simple programa externo y el caos que causa La secuencia cabe en cuatro fechas. El 19 llegó la consulta del cliente, el 20 se confirmó el programa ajeno y se cortaron las nuevas altas junto al panel de control, y el 21 empezó el apagado a las 04:00 hora local. GMO Internet ha explicado que la investigación arrancó al recibir una consulta de un cliente, y que el 22 de octubre acudió a la policía. El recorrido de la intrusión lo revisa ahora una firma externa de ciberseguridad, y la compañía ha dicho que compartirá los detalles conforme los confirme. Lo que ya está cerrado es el calendario: de la consulta inicial al apagado pasaron dos días. Lo que no ha publicado la empresa es qué programa era ni cómo entró. Ni el primer aviso del 21 de octubre ni el segundo identificaban la familia del software malicioso o el vector de entrada. Tampoco hay un recuento de máquinas con infección verificada: [la actualización del 23 de octubre](https://internet.gmo/ir/pdf/irlibrary/gmointernet_j_disclose_20261023.pdf) describe los 26.739 como «servidores que podrían estar afectados», no como equipos con un programa ya instalado. Con ese dato en la mano, ningún cliente puede saber aun, si su máquina estaba comprometida o solo expuesta. Esa distinción decide si el aviso habla de un incidente sufrido o de un riesgo por confirmar, y la duda durará más que el apagado. ## Las credenciales de trading, en el centro del incidente La segunda nota de la empresa, publicada el 22 de octubre, cambió el tono del mensaje: [reconoce que las credenciales de las herramientas de trading](https://internet.gmo/en/news/article/247/), MT4 y MT5 incluidas, y las de las cuentas de operación guardadas en esos servidores podrían haber quedado al descubierto. También confirma que ha recibido reportes de operaciones no autorizadas en cuentas de clientes y que ha compartido la situación con las firmas afectadas. MetaTrader 4 y MetaTrader 5 son las plataformas con las que buena parte del comercio minorista de divisas lanza órdenes, y dejarlas en un servidor remoto permite que la estrategia siga trabajando con el ordenador del cliente apagado. Esa comodidad concentra dos secretos en la misma máquina: la contraseña de la plataforma y la de la cuenta en el bróker. Quien compromete una, se lleva las dos si el usuario repitió la clave o la dejó escrita en el mismo sitio. El detalle que más pesa es que ese servidor hacía de caja fuerte. Quien dejó allí la contraseña del bróker para no reescribirla cada mañana entregó la llave con la máquina, y el intruso no necesitaba nada más para operar. La petición de la compañía es concreta y tiene una condición que muchos pasan por alto. El cambio de contraseña debe hacerse desde un equipo distinto al servidor afectado, y después hay que cerrar sesión para cortar cualquier conexión abierta. A eso se suman la revisión del historial y del saldo, la activación del doble factor si el bróker la ofrece y la rotación de cualquier credencial almacenada en la máquina. ## ¿Qué revisar si tenías servicios en esos servidores? Cualquiera que haya usado Desktop Cloud para algo más que un bot de divisas afronta el mismo problema en otra escala, porque todo secreto que viviera en esas máquinas debe darse por leído. Las claves de API de un exchange y los tokens de acceso a un panel de control compartieron disco con el intruso, y rotar lo guardado allí es la única respuesta sensata mientras no exista un análisis forense que detalle qué se llevaron. * Cambia las contraseñas desde otro equipo y cierra la sesión del servidor antes de volver a conectarte a él. * Revisa el historial de operaciones y el saldo de cada cuenta cuyas credenciales estuvieran en la máquina. * Activa el doble factor en el bróker y en cualquier panel que lo permita, aunque el proveedor no lo exija. * Desconfía de correos y llamadas que se apoyen en este incidente, porque la empresa avisa de que nunca pide contraseñas ni datos de tarjeta por esa vía. El apagado juega a favor de los clientes en un punto y en contra en otro. Mientras las máquinas sigan apagadas nadie puede entrar con credenciales robadas para borrar rastros, pero también se queda sin acceso el dueño legítimo que necesita revisar registros y copias de seguridad. GMO no ha dado fecha de reapertura y ha dicho que avisará cuando verifique que la infraestructura es segura. ## ¿Quién responde cuando el proveedor es el comprometido? Un servidor virtual es un contrato de delegación: otro parchea el hipervisor, otro vigila la red y otro responde cuando algo entra por donde no debía. Cuando el fallo ocurre en ese lado, el cliente descubre que su control sobre el entorno empieza justo donde termina el del proveedor, y que las credenciales que guardó allí dejan de depender de su propia higiene. El historial de la cadena de suministro tecnológica deja pocas dudas sobre el patrón. Los fallos que se cobran caros rara vez están en el extremo del usuario, si no en la capa que todo el mundo da por resuelta, como mostró [la cadena de fallos que rodeó a Ledger](https://observatorioblockchain.com/ciberseguridad/que-falla-seguridad-ledger-implantes-espia-filtraciones/) entre filtraciones, implantes y vulnerabilidades del ecosistema. La seguridad de una cuenta acaba valiendo lo que valga la máquina donde se teclea. La alternativa tampoco sale gratis. Mudar el servicio a un equipo propio traslada el problema al cliente, que pasa a ocuparse de lo que antes gestionaba un tercero con más medios para cerrar el incidente. Montar el servicio en casa o en un servidor contratado por separado deja en manos del usuario las actualizaciones y las copias, y [quien monta su propio servidor en 2026](https://observatorioblockchain.com/tecnologia/autohospedaje-2026-que-montar/) asume ese trabajo con método y con tiempo. Ninguna de las dos opciones elimina el riesgo: solo decide quién lo sufre cuando llega. ## Un servicio crítico sin fecha de reapertura GMO ha dicho que la vuelta del servicio se anunciará cuando esté confirmada la seguridad de la infraestructura y que el impacto en sus resultados consolidados sigue en evaluación. Para el cliente el calendario pesa más que el comunicado, porque cada jornada de apagón es una estrategia parada y quien operaba con dinero real necesita saber si su cuenta estuvo expuesta antes de reconectarse. El punto débil de esta historia no fue la contraseña de un usuario despistado, sino la máquina donde esa contraseña dormía. Quien vuelva a montar un servicio así hará bien en preguntar qué guarda el proveedor, qué registra y cuánto tarda en avisar, porque la próxima vez el reloj empezará a correr en su cuenta de trading y no en el panel de Onamae.