Nikkei: credenciales robadas exponen 1,83 millones de registros

Nikkei Inc., el grupo japonés de información económica y financiera que publica el diario Nikkei y el Financial Times, ha comunicado una nueva brecha de datos: con credenciales robadas previamente, alguien entró en un servicio en la nube usado para el desarrollo de sistemas y accedió a unos 1,83 millones de registros. Según BleepingComputer, es el tercer incidente de seguridad que la empresa da a conocer en aproximadamente un mes.

Qué ha pasado

Según el aviso publicado por Nikkei, recogido por BleepingComputer, SecurityWeek y Security Affairs, el acceso no autorizado se produjo en las primeras horas de la mañana del 7 de octubre de 2026. Los atacantes usaron credenciales de acceso ya comprometidas; la empresa las revocó tras descubrir el acceso y el 11 de octubre notificó la brecha a la Personal Information Protection Commission, la autoridad japonesa de protección de datos.

Las fuentes describen el sistema afectado de forma algo distinta: para SecurityWeek y Security Affairs, que citan el aviso, se trata de un servicio en la nube que Nikkei usa para el desarrollo de sistemas; para BleepingComputer, de un sistema de desarrollo dentro de la red de la empresa, a través del cual quedaron expuestos datos personales almacenados en la nube. Nikkei no ha indicado de qué servicio se trata ni cómo se robaron las credenciales.

Datos afectados

Según el aviso, a 16 de octubre están afectados unos 1,83 millones de elementos de información personal:

• unos 150.000 contienen al menos uno de estos datos: nombre, dirección de correo electrónico, dirección postal, número de teléfono, fecha de nacimiento;
• de ellos, unos 120.000 incluyen una dirección de correo electrónico;
• unos 1,68 millones contienen solo información que, por sí sola, no identifica a una persona;
• ningún registro contiene datos de tarjetas de crédito.

A 16 de octubre, Nikkei declara no haber encontrado pruebas de uso ilícito de los datos ni, según BleepingComputer, de su publicación en internet; no ha habido interrupciones del servicio ni modificaciones de los datos. La investigación sobre el alcance y la causa del incidente sigue en curso, y las personas afectadas recibirán un aviso individual.

Los incidentes anteriores

Según BleepingComputer, a principios de octubre Nikkei ya había dado a conocer una brecha ocurrida a finales de julio: se había comprometido la cuenta de Google Workspace de un empleado, con acceso a datos personales de empleados y socios comerciales. En septiembre, la empresa comunicó que la cuenta de Microsoft 365 de otro empleado se había usado para enviar correos de spear phishing a la plantilla. SecurityWeek y Security Affairs recuerdan también una brecha originada en una cuenta de Slack comprometida, comunicada, según Security Affairs, en noviembre de 2025.

Nikkei no ha dicho si las credenciales usadas el 7 de octubre proceden de alguno de los incidentes anteriores: con la información pública, la relación no se puede establecer.

Detalles técnicos

No hay CVE ni malware: la entrada se produjo con credenciales válidas. Con lo que se sabe, el esquema encaja en las técnicas de MITRE ATT&CK Valid Accounts: Cloud Accounts (T1078.004) y, para la recogida de datos, Data from Cloud Storage (T1530). No se han publicado indicadores de compromiso.

Lo que interesa a quien gestiona sistemas es el lugar del incidente: un entorno de desarrollo que contenía datos personales reales, 1,83 millones de registros. Los entornos de desarrollo y de pruebas suelen tener controles más débiles que los de producción (cuentas compartidas, claves de larga duración, menos supervisión), pero pueden contener copias de los mismos datos.

Impacto para las empresas europeas e italianas

Para el RGPD, los datos personales en los entornos de desarrollo se tratan como los de producción: requieren las mismas medidas de seguridad (art. 32) y la protección de datos desde el diseño (art. 25), es decir, datos mínimos, seudonimizados o sintéticos. Un acceso no autorizado a esos datos es una brecha que debe evaluarse para su notificación a la autoridad de control en un plazo de 72 horas.

Para las entidades sujetas a NIS2 (en Italia, el Decreto Legislativo 138/2024), la gestión de accesos, la autenticación multifactor y la seguridad en el desarrollo de sistemas figuran entre las medidas de gestión de riesgos previstas.

Existe además un riesgo indirecto: 120.000 direcciones de correo asociadas a nombres y datos de contacto permiten un phishing creíble en nombre de Nikkei o del Financial Times, también contra empleados de empresas europeas suscriptoras.

Qué hacer ya

1. Haz inventario de los entornos de desarrollo y de pruebas en la nube: qué servicios, quién accede, qué datos contienen. Trata igual los repositorios, las bases de datos de pruebas y el almacenamiento de objetos.
2. Quita los datos personales reales de los entornos de desarrollo: usa datos sintéticos o enmascarados; donde hagan falta datos reales, solo el mínimo, con caducidad y borrado.
3. Protege los accesos como en producción: inicio de sesión único corporativo, autenticación multifactor resistente al phishing (FIDO2 o passkeys), nada de cuentas compartidas, claves de API y tokens de corta duración.
4. Tras cada cuenta comprometida, rota todo lo que podía ver: contraseñas, tokens, claves y secretos guardados en correo, chats y documentos, no solo la contraseña de la cuenta afectada.
5. Lleva los registros de la nube a la supervisión: accesos desde países o dispositivos nuevos, accesos fuera de horario, exportaciones masivas de datos, nuevas claves de acceso.
6. Busca credenciales de la empresa expuestas en brechas y en mercados de credenciales robadas, y desactiva las que encuentres.

Cómo ayuda ARXDOME

ARX Expose señala las cuentas de la empresa expuestas en brechas conocidas, para que las credenciales comprometidas puedan desactivarse antes de que alguien las use. ARX Sentry recoge registros y eventos de ordenadores, servidores y cortafuegos y los agrupa en familias como accesos fallidos, uso de credenciales explícitas y cambios en las cuentas. ARX Retain conserva los registros para reconstruir, en caso de investigación, quién tuvo acceso y cuándo.

Última actualización: 20 de octubre de 2026