Para: personas que administran sistemas en una empresa u organización que maneja datos personales en Japón, y la dirección a la que informan. En octubre de 2026, organismos del gobierno japonés y organizaciones de seguridad nacional emitieron una serie de advertencias sobre acceso no autorizado. Esta guía convierte esas advertencias en comprobaciones que puede realizar esta semana en sus propios sistemas. Se basa en documentos públicos de la Oficina Nacional de Ciberseguridad de la Secretaría del Gabinete, la IPA (Information-technology Promotion Agency), JPCERT/CC, la Comisión de Protección de Información Personal (PPC), la Agencia de Servicios Financieros (FSA) y la Agencia Nacional de Policía (NPA), todos en japonés. No se tratan las técnicas de ataque.
Por qué se publicaron estas advertencias ahora
Desde aproximadamente septiembre de 2026, organizaciones de Japón han comunicado una filtración de datos tras otra por acceso no autorizado. La IPA afirma que las comunicaciones proceden de una amplia variedad de empresas, entre ellas entidades financieras y proveedores de telecomunicaciones, y que se han vulnerado sistemas que dan soporte a servicios en línea y de cuentas que manejan grandes cantidades de datos personales, y que se han robado datos, incluida información personal.
Los siguientes documentos se emitieron entre el 7 y el 9 de octubre.
| Fecha | Emitido por | Documento | Contenido principal |
|---|---|---|---|
| 7 oct. (vídeo explicativo añadido el 9 oct.) | Comisión de Protección de Información Personal | Respuesta a las filtraciones de datos a gran escala (advertencia), y una «ADVERTENCIA: prevención de filtraciones de datos personales causadas por acceso no autorizado» revisada | Un primer avance de los ejemplos revisados de salvaguardas técnicas (que se ultimarán en abril de 2027); eliminación de datos personales que ya no son necesarios; nueve tipos de casos, entre ellos el abuso de API |
| 8 oct. (actualizado el 9 y el 23 oct.) | JPCERT/CC | Alerta sobre la reciente serie de incidentes de acceso no autorizado en organizaciones japonesas (JPCERT-AT-2026-0030) | Cinco patrones de ataque observados, contramedidas, indicadores para la investigación (IOC) |
| 9 oct. | Secretaría del Gabinete, Oficina Nacional de Ciberseguridad | Respuesta a las filtraciones de datos causadas por acceso no autorizado | Tres pilares: sistemas web, cadena de suministro, gestión de datos |
| 9 oct. | IPA | Medidas que deben adoptarse con prontitud ante las filtraciones de datos causadas por acceso no autorizado | Comprobaciones que deben realizarse ahora y medidas que deben tomarse (actualizado según sea necesario) |
| 9 oct. | Agencia de Servicios Financieros | Refuerzo de la ciberseguridad y tramitación de solicitudes de cuentas en la situación actual | Solicitudes a las entidades financieras para revisar los controles y reforzar la verificación de identidad |
JPCERT/CC afirma que, aunque se han visto afectados varios productos y servicios, el intercambio de información técnica ha sido insuficiente y lo que se conoce es limitado. Ninguno de los documentos nombra incidentes concretos. Entre los incidentes japoneses de acceso no autorizado que este sitio ha cubierto en septiembre y octubre figuran Times Car, Yamato Transport y Sagawa Express, la aplicación de Seicomart, la aplicación de Yakiniku King, un contratista de Daiwa Securities y Lawson ID. Lo que comunicó cada empresa figura en los artículos enlazados.
Las comprobaciones de esta semana: los tres ámbitos de la IPA
La IPA enumera tres ámbitos en «comprobaciones que deben realizarse con prontitud». A continuación se desglosan en tareas concretas. Realice todas ellas únicamente en los sistemas que usted gestiona.
Enumere sus aplicaciones expuestas a internet y revise sus registros, primero el último mes y después los últimos tres meses
Enumere todas las aplicaciones y servicios que haya desarrollado o que opere y que sean accesibles desde internet: sitios de socios, las API que llaman sus aplicaciones móviles, formularios de contacto y pantallas de administración. JPCERT/CC indica que también se han atacado sistemas no destinados al público general, como herramientas de inteligencia de negocios y sistemas de administración para empleados, así que incluya también los de uso interno.
Para cada aplicación, revise los registros en busca de cualquier anomalía. Los ejemplos de la IPA son un gran volumen de errores y patrones distintos de los normales. En la práctica, busque picos de solicitudes a pantallas de administración o API en el registro de acceso del servidor web, el mismo error repetido en el registro de la aplicación y grandes descargas de noche o en fin de semana. Empiece por el último mes y después amplíe a tres meses.
La IPA también pide que sepa quién puede investigar y de qué forma, ya que puede que necesite investigar más de una vez. Por último, revise los componentes de cada aplicación y servicio (por ejemplo, el sistema operativo, el middleware, las bibliotecas y el CMS) para detectar correcciones de seguridad no aplicadas y aplíquelas lo antes posible.
En cuanto a las API, el documento de ADVERTENCIA que la PPC revisó el 7 de octubre añade el caso 9, «abuso de API» (la primera edición, del 11 de diciembre de 2024, incluía los casos 1 a 8). Las causas que enumera son: algunas API no figuraban entre las gestionadas; cambiar un parámetro, como un ID de socio, permitía a un usuario con sesión iniciada recuperar datos de otros usuarios; las respuestas contenían información innecesaria y los ID de socio eran secuenciales; y no existía límite en el volumen de solicitudes (limitación de tasa). Sus ejemplos de contramedidas son:
- Inventariar sus API periódicamente
- Comprobar la autorización (si este usuario tiene derecho a acceder a estos datos) en cada solicitud, y no solo la autenticación (quién es el usuario)
- Excluir de las respuestas la información innecesaria y usar valores aleatorios, como UUID, para los ID de socio y los números de registro
- Implantar una limitación de tasa que detecte y bloquee grandes volúmenes de solicitudes en poco tiempo
En los servicios de nube, VPN y otros servicios externos, revise los inicios de sesión fallidos, las direcciones de origen y las cuentas desconocidas
Enumere los servicios de nube, las VPN y el SaaS que utiliza. La IPA pide que incluya los servicios que hayan contratado departamentos individuales. Pregunte a finanzas y ventas si tienen contratos que el equipo de TI desconoce.
En los registros de cada servicio, busque muchos inicios de sesión fallidos, direcciones IP de origen desconocidas e inicios de sesión a horas inusuales. La IPA señala que los periodos de conservación varían según el servicio y que el proveedor y el cliente pueden ver registros distintos. Si la consola de administración solo muestra un periodo corto, consulte al proveedor.
En cuanto a las cuentas, compruebe si se han creado cuentas que no reconoce y si alguna de las que desactivó o eliminó se ha vuelto a habilitar. La IPA indica que revisar el registro de auditoría de las operaciones con cuentas ayuda. Esta es la versión organizativa de comprobar si alguien ha accedido a su cuenta.
El caso 8 de la misma ADVERTENCIA es una filtración desde un servicio de nube que utilizaba la empresa. Se accedió sin autorización al sistema de negocio de un proveedor de nube y se cifraron datos personales de muchas empresas clientes. Una de las causas que enumera la PPC es que los clientes creían que el uso de un servicio de nube, que no era una externalización, no constituía una delegación del tratamiento de datos personales, por lo que no supervisaron cómo se gestionaban. Como contramedida, la PPC propone comprobar, a través de las condiciones del servicio y de los documentos de evaluación de seguridad del servicio, si una nube dispone de medidas de seguridad adecuadas antes de elegirla.
Inventaríe los datos personales que conserva y elimine los que no necesita
La IPA indica que los datos robados se utilizan para la extorsión y la reventa, y pide a las organizaciones que conserven solo los datos que necesitan y que sepan exactamente qué tienen. Para cada base de datos y cada almacén de archivos, anote qué datos contiene, cuántos registros tiene, por qué los conserva y hasta cuándo. Todo lo que no pueda justificar es candidato a eliminación.
La advertencia de la PPC de la misma semana recuerda a las empresas que el artículo 22 de la ley japonesa de información personal les pide esforzarse por eliminar los datos personales sin demora una vez que dejen de ser necesarios, y señala que ha visto casos en los que la situación empeoró porque no se hizo. Cuando una ley fije un periodo de conservación, anote también esa base y ese periodo.
La IPA añade también que los organismos públicos y los proveedores de seguridad pueden publicar información útil para la investigación, como direcciones IP sospechosas, y pide a las organizaciones que intensifiquen por ahora la recopilación de información.
Aunque las comprobaciones no encuentren nada, siga adelante
La IPA pide a las organizaciones que consideren medidas adicionales aunque no se detecte ninguna anomalía. En cuanto a las aplicaciones expuestas a internet y los servicios externos: revisar qué está expuesto, reforzar la autenticación, como la autenticación multifactor y las contraseñas, revisar los privilegios de las cuentas, revisar cómo se gestionan las integraciones de API, y revisar qué se registra y durante cuánto tiempo. En cuanto a los datos: reconsiderar si deben conservarse, reconsiderar dónde se almacenan, revisar los registros de acceso y su conservación, y cifrarlos.
Los tres pilares de la Oficina Nacional de Ciberseguridad, convertidos en comprobaciones concretas
El aviso de la Oficina Nacional de Ciberseguridad cita como antecedentes la explotación de vulnerabilidades de los sistemas web, el compromiso a través de la cadena de suministro y la débil gestión de datos, y expone las medidas clave para cada uno. La columna de la derecha reescribe los puntos del aviso como preguntas que puede verificar en su propia organización.
| Pilar | Puntos principales del aviso | Qué comprobar |
|---|---|---|
| 1. Gestión adecuada de los sistemas web | Aplicar parches de seguridad con prontitud (incluidos los servidores internos no expuestos a internet), dejar de usar productos sin soporte, apagar sistemas y funciones no utilizados, realizar evaluaciones periódicas de vulnerabilidades, desactivar puertos y servicios innecesarios | ¿Puede enumerar cada servidor público e interno con su fecha de fin de soporte y su última actualización? |
| 1. (cuentas y autenticación) | Autenticación multifactor, prohibir contraseñas fáciles de adivinar, mantener al mínimo las cuentas de administración, desactivar sin demora las cuentas de personas que se marchan o cambian de puesto y las cuentas no utilizadas | ¿Puede nombrar al responsable de cada cuenta de administración? ¿Hay cuentas de personas que ya se fueron que sigan activas? |
| 1. (resiliencia) | Recopilar y conservar registros, monitorizar el tráfico sospechoso y los accesos masivos, detectar intentos de autenticación anómalos desde el exterior, preparar la respuesta a incidentes | Cuando se produce una descarga masiva o inicios de sesión fallidos repetidos, ¿quién recibe la notificación? |
| 2. Cadena de suministro, incluidos los contratistas | Revisar las políticas, la estructura y el reparto de responsabilidades de los contratistas, conocer también la situación de los subcontratistas, incluir en los contratos el control de accesos, el registro y las obligaciones de notificación de brechas, dar a los contratistas solo los datos que necesitan y asegurar la eliminación al terminar el trabajo | Para cada contratista, ¿puede reunir en una sola página los datos personales que comparte, las cuentas que le concede y el contacto en caso de incidente? |
| 3. Gestión adecuada de los datos | Saber dónde está la información y quién la gestiona, definir la finalidad y la conservación, inventariar periódicamente, separar los permisos de lectura y de escritura, cifrar los datos almacenados y el tráfico, no guardar nunca credenciales en texto plano, revisar la exposición y la configuración de acceso en la nube, registrar el acceso a datos personales y vigilar las descargas masivas | ¿Puede averiguar después quién accedió a los datos personales y cuándo? |
En cuanto a la cadena de suministro, el aviso pide a las organizaciones que actúen partiendo de la idea de que «gestionan conjuntamente con los contratistas», porque los atacantes a veces utilizan a un contratista menos protegido como punto de apoyo y después amplían el acceso a la empresa objetivo. Las cuentas de contratistas y de mantenimiento también se tratan en la base de seguridad para organizaciones.
Oficina Nacional de Ciberseguridad: qué proteger
Sistemas web / cadena de suministro, incluidos los contratistas / gestión de datos
IPA: qué comprobar esta semana
Registros de aplicaciones expuestas / cuentas de servicios externos / los datos que conserva
JPCERT/CC: qué está ocurriendo
Cinco patrones de ataque / contramedidas / pistas para la investigación (IOC, actualizados)
El primer avance de la PPC sobre las salvaguardas técnicas revisadas
En un anexo a su advertencia del 7 de octubre, la PPC expuso el contenido revisado de «10-6 Salvaguardas técnicas» del anexo de sus directrices generales en virtud de la ley japonesa de información personal. Indica que la revisión está prevista para ultimarse en abril del próximo año (abril de 2027), pero que muestra el contenido previsto con antelación porque, dados los acontecimientos recientes, es probable que resulte más útil como referencia.
Lo que enumera son «ejemplos de métodos». La PPC afirma que se trata literalmente de ejemplos y que no es necesario implantar todos ellos para evitar una infracción. También indica que los métodos concretos deben ajustarse al riesgo, incluido el perjuicio para las personas si los datos se filtran, y la naturaleza y el volumen de los datos personales tratados. Las empresas que manejan grandes cantidades de datos personales deberían comparar sus propios controles con él punto por punto. El anexo también ofrece ejemplos separados para las pequeñas y medianas empresas.
| Ámbito | Ejemplos del anexo (resumidos) | Qué comprobar |
|---|---|---|
| (1) Control de acceso | Reducir al mínimo el acceso a los sistemas que tratan datos personales (por ejemplo, solo desde direcciones IP concretas aprobadas de antemano). Limitar al mínimo qué personal tiene cuentas privilegiadas, qué dispositivos utiliza y cuándo. Revisar los derechos de acceso, por ejemplo mediante auditorías periódicas. Evaluar cada solicitud de acceso según el contexto, como la ubicación de origen, la hora y el estado de seguridad del dispositivo, y decidir según el riesgo | ¿Se puede acceder a las pantallas de administración o a las bases de datos desde cualquier lugar? ¿Puede enumerar las cuentas privilegiadas y los dispositivos desde los que se usan? |
| (2) Identificación y autenticación | Usar autenticación multifactor (incluidos métodos resistentes al phishing) para el acceso desde fuera de la red de la organización, para el acceso con derechos de administración y para el acceso a datos personales importantes. Identificar y autenticar también adecuadamente a los usuarios que no son personal, por ejemplo con autenticación multifactor (igualmente) | ¿Exige la autenticación multifactor toda conexión remota e inicio de sesión de administración, sin excepciones? ¿Se ofrece a los socios y a otros usuarios? |
| (3) Prevención del acceso no autorizado desde el exterior | Cortafuegos, software de seguridad, aplicación de parches, prevención de software no autorizado. Permitir el acceso a datos personales solo desde dispositivos aprobados por la organización y que cumplan sus estándares de seguridad | ¿Los dispositivos que tocan datos personales son solo los que la empresa ha aprobado? |
| (4) Prevención de filtraciones derivadas del uso de los sistemas | Mantener al mínimo los datos personales usados como datos de prueba para comprobaciones funcionales (por ejemplo, prohibirlos o sustituir parte de ellos por otros datos). Al eliminar datos personales en la nube, usar un método que dificulte la recuperación, como el método propio del proveedor o el cifrado con borrado de claves (crypto-erase) | ¿Hay copias de datos personales de producción en entornos de prueba? ¿Se ha decidido cómo se eliminan los datos cuando se cancela o migra un servicio en la nube? |
| (5) Detección de accesos no autorizados | Conservar durante un periodo establecido los registros de autenticación, acceso, operación y red, protegerlos frente a filtraciones, manipulaciones y borrados no autorizados, y analizarlos periódicamente. Monitorizar de forma continua con IDS/IPS, EDR y herramientas similares. Limitar la propagación del daño deteniendo o aislando los sistemas que han sido o podrían haber sido comprometidos, y desactivando cuentas | ¿Guarda los registros en un lugar donde un atacante no pueda borrarlos? ¿Quién puede decidir aislar un sistema y desactivar cuentas? |
La conservación de registros de la fila (5) es también aquello de lo que depende la comprobación de la IPA de «el último mes, luego tres meses». Si la comprobación de esta semana muestra que no tiene registros suficientes, la fila (5) le da base para corregirlo.
Los cinco patrones que ha observado JPCERT/CC
La alerta de JPCERT/CC describe patrones de ataque, distintos del ransomware, que llevan a grandes filtraciones de datos y que parecen estar aumentando en particular. Aquí se resumen solo lo justo para indicar dónde mirar.
| Patrón | Resumen de la descripción de JPCERT/CC | Dónde comprobar |
|---|---|---|
| Caso A | Sondeo de vulnerabilidades conocidas e intentos de explotarlas, incluidos intentos de obtener archivos de configuración o de copia de seguridad aprovechando equipos mal gestionados | Nivel de parches de los servidores públicos; si hay archivos de configuración o copias de seguridad en carpetas públicas |
| Caso B | Solicitudes no autorizadas a la API de administración de una aplicación que provocan la alteración de datos. Los informes incluyen la identificación de API mediante el análisis de aplicaciones públicas, ataques a API internas y uso indebido de claves de API robadas de otros sistemas | Si las API de administración e internas exigen autenticación y control de acceso; permisos y caducidad de las claves de API |
| Caso C | Explotación de una vulnerabilidad de inyección SQL en Metabase (CVE-2026-72898) mediante solicitudes de API no autorizadas | Si utiliza Metabase, si está parcheado y si es accesible desde internet |
| Caso D (añadido el 9 oct.) | Un archivo WAR (una aplicación Java empaquetada) colocado en un servidor de aplicaciones accesible desde un servidor web público, con un archivo dentro que actúa como una web shell sencilla (un programa malicioso que permite a personas externas ejecutar comandos) | Si las funciones de gestión del servidor de aplicaciones son accesibles desde el lado público; si cada aplicación desplegada es una que usted instaló |
| Caso E (añadido el 23 oct.) | Intentos de ataque que abusan de plataformas de pruebas de penetración basadas en IA; los nombres de las plataformas figuran en la alerta de JPCERT/CC. Atacan sobre todo aplicaciones web expuestas a internet, sondeando y tratando de explotar diversas vulnerabilidades, y también se han visto ataques que aprovechan equipos mal gestionados (como la obtención de archivos de configuración o de copia de seguridad). Incluye intentos contra servidores WSUS (servidores que distribuyen actualizaciones de Windows dentro de una organización) expuestos a internet | Nivel de parches de las aplicaciones web públicas y qué hay en las carpetas públicas; si un servidor WSUS es accesible desde internet |
El caso C se trata en las brechas por la vulnerabilidad de Metabase y en la explicación de CVE-2026-72898. Para los archivos de configuración y las copias de seguridad en un lugar equivocado, consulte ¿dejó un archivo secreto en un directorio público?
El 15 de octubre, JPCERT/CC publicó los resultados del examen de servidores que podrían haberse utilizado en los ataques. Indica que los atacantes usaron IA para buscar vulnerabilidades conocidas y para atacar a través de API, y que había rastros de que analizaban los archivos de distribución de aplicaciones Android para identificar API y sondeaban esas API en busca de fallos como SSRF. Esto coincide con la «identificación de API mediante el análisis de aplicaciones públicas» del caso B. JPCERT/CC señala que los secretos y la lógica de autenticación de API incrustados en una aplicación pueden extraerse incluso del código compilado (las aplicaciones Flutter, por ejemplo), y recomienda lo siguiente.
- No incrustar en la aplicación claves privadas ni credenciales de larga duración utilizadas para la autenticación de API
- No confiar solo en la firma o la ofuscación dentro de la aplicación; autenticar a los usuarios en el servidor y autorizar cada operación según su destino y contenido
- Aplicar limitaciones de tasa y monitorizar las solicitudes anómalas, y asumir que habrá accesos desde clientes distintos de la aplicación oficial
- En las API que obtienen URL externas, restringir los destinos y comprobar también a dónde llevan las redirecciones
Para el acceso a través de API, JPCERT/CC recomienda limitaciones de tasa por función en el inicio de sesión, el restablecimiento de contraseña, el envío de SMS y la búsqueda; control de acceso también en las API no públicas; permisos mínimos y caducidad razonable para los usuarios y tokens de API; y la capacidad de revocar con rapidez los tokens innecesarios o que podrían haberse filtrado. Entre sus medidas generales figuran restringir las regiones de origen para servicios usados solo en determinadas zonas, actualizar las versiones afectadas por vulnerabilidades conocidas, revisar cómo limitar el movimiento lateral si se compromete un servidor web, comprobar la detección y la primera respuesta, retirar de internet las funciones de administración innecesarias, eliminar los datos que superen su periodo de conservación o su finalidad, y preparar por adelantado la advertencia a los clientes frente a daños posteriores si se produce una filtración.
Lo que han encontrado empresas de seguridad japonesas (del 7 al 19 de octubre)
Empresas de seguridad japonesas también han publicado conclusiones a partir de los casos que gestionaron y del examen de servidores de atacantes. Una empresa analizó las 81 filtraciones de sistemas web que las organizaciones de Japón comunicaron desde julio de 2026 (hasta el 6 de octubre) y encontró que 65 de ellas (80,2 %) no podían clasificarse por causa porque los avisos no explicaban lo suficiente. Los métodos que observó en los casos que gestionó incluyen API que devuelven más datos de los necesarios, falta de comprobaciones de autorización en el servidor, funciones solo para socios a las que pueden acceder usuarios anónimos y claves de API extraídas de aplicaciones de teléfonos inteligentes.
Otra empresa describe atacantes que cambian a otra dirección IP justo antes de alcanzar el umbral de bloqueo de un WAF, utilizando varios cientos de direcciones IP en total. También afirma que las versiones no incluidas en un CVE, y las versiones fuera de soporte, pueden verse afectadas por la misma vulnerabilidad. El 19 de octubre, indicó que había confirmado que un sistema autónomo de pruebas de penetración basado en IA se utilizaba en un servidor de atacantes. El 23 de octubre, JPCERT/CC también añadió a su alerta, como caso E, los intentos de ataque que abusan de plataformas de pruebas de penetración basadas en IA.
Añada estas tres comprobaciones a las anteriores.
- Confirme que las pantallas de administración y otras funciones de gestión realmente estaban incluidas en el alcance de su evaluación de vulnerabilidades (a menudo se dejan fuera las funciones no abiertas al público)
- No confíe solo en límites de solicitudes por IP ni en un WAF, y no retrase los parches porque exista un WAF
- Reduzca los datos personales que ya no necesita, incluida la información inesperada guardada en campos de notas de texto libre, y revoque las claves de API de los servicios que han finalizado
Para los indicadores (direcciones IP, User-Agent), use la página actual de JPCERT/CC
La alerta de JPCERT/CC enumera direcciones IP de origen sospechosas y ejemplos de User-Agent vistos en los ataques. La lista se amplió el 9 y el 23 de octubre y puede volver a cambiar, por lo que este sitio no la copia. Consulte la lista vigente en la alerta de JPCERT/CC (JPCERT-AT-2026-0030, en japonés).
JPCERT/CC pide a las organizaciones que comprueben si las direcciones IP enumeradas accedieron a sus sistemas, para saber si ya habían sido atacadas. Use la lista como pista para buscar en los registros pasados, no como lista de bloqueo. Esto es lo que se añadió al caso B el 23 de octubre:
- Una nueva dirección IP de origen, con la fecha en que se observó el ataque o en que se estima que la infraestructura del ataque estuvo activa (JST). JPCERT/CC señala que también puede haberse intentado atacar fuera de esas fechas. El caso E tiene su propia lista separada de direcciones IP
- Como ejemplo de User-Agent, el mismo User-Agent que la aplicación pública. Eso significa que el User-Agent por sí solo no puede distinguir el tráfico de ataque de la aplicación legítima
- Ejemplos de huellas TLS. JPCERT/CC indica que el valor JA4 listado es el mismo que el de los clientes HTTP comunes de Python, por lo que no puede identificar por sí solo al atacante y debe combinarse con otras pistas
- Además de las direcciones listadas, se ha observado acceso a través de nodos de salida de Tor y de proxies residenciales (servicios de retransmisión que encaminan el tráfico a través de conexiones domésticas a internet)
JPCERT/CC afirma que estos pueden haber sido usos legítimos en el momento de la investigación, por lo que una coincidencia por sí sola no demuestra una intrusión. Siga en sus registros lo que realmente hizo ese origen.
Si encuentra algo: siga este orden
La IPA pide a las organizaciones que declaren con prontitud un incidente de seguridad cuando encuentren registros o cuentas anómalos. Esperar a ver qué ocurre puede hacer que los registros caduquen antes de que alguien los revise.
Declare un incidente de seguridad
Traslade la anomalía a la persona responsable el mismo día y decida tratarla como un incidente. Una declaración puede retirarse después; un inicio tardío no puede adelantarse.
Conserve los registros y las pruebas
Los registros desaparecen cuando termina su periodo de conservación. Antes de eliminar o sobrescribir algo, copie a una ubicación separada los registros del servidor, los registros que pueda exportar desde las consolas de los servicios externos y los registros de auditoría de las cuentas. Pregunte a los especialistas si conviene conservar imágenes de disco antes de reconstruir un servidor. El orden de los pasos está en «Qué hacer primero si encuentra algo» en cómo comprobar si su sitio web o servidor ha sido hackeado.
Recurra a una empresa especializada
Dada la posibilidad de fuga de datos, la IPA recomienda encarecidamente contratar a una empresa especializada en seguridad para una investigación detallada. JPCERT/CC acepta solicitudes de respuesta a incidentes. No decida por su cuenta hasta dónde llegó el atacante ni qué se llevó.
El 16 de octubre de 2026, la IPA abrió una mesa especial de consulta sobre acceso no autorizado, para empresas y organizaciones que han sido o podrían haber sido afectadas. Asesora sobre si podría haber sufrido daños y sobre medidas de primeros auxilios, remite a una lista de empresas que gestionan la respuesta a incidentes y le indica otros lugares donde consultar o informar (teléfono 03-6759-5760, días laborables de 9:30 a 17:30, salvo de 12:00 a 13:00, en japonés; también se aceptan correos electrónicos). Si no sabe a qué empresa llamar, puede empezar por ahí.
Informe a la PPC y comparta información
Si se filtraron datos personales o podrían haberse filtrado, puede ser necesario informar a la PPC y notificar a las personas afectadas. Los plazos y el lugar donde informar se resumen en cómo comprobar si su sitio web o servidor ha sido hackeado. La Oficina Nacional de Ciberseguridad pide a las organizaciones afectadas que compartan con prontitud información técnica con ella, con el ministerio competente y con organismos especializados para evitar más daños. También están disponibles la ventana de notificación de la IPA y las unidades de delitos informáticos de la policía.
Qué comunicar a la dirección
El aviso de la Oficina Nacional de Ciberseguridad indica que los daños de los ciberataques ya no son solo un problema del departamento de TI, porque una filtración puede provocar la paralización del negocio, problemas en la atención a clientes y otros riesgos de gestión. Pide a la dirección que trate la ciberseguridad como un asunto de gestión y que la refuerce, incluidas la inversión y la dotación de personal necesarias. La IPA pide igualmente una revisión urgente de las medidas como responsabilidad de la gestión.
Al informar a la dirección, limítese a cuatro puntos para que pueda decidir.
- Resultados de esta semana: para cada uno de los tres ámbitos, si encontró anomalías, si no encontró ninguna o si no pudo comprobarlo
- Lo que no pudo comprobar: periodos sin registros, servicios externos o contratistas que no pudo identificar
- Decisiones necesarias: el coste de una conservación de registros más prolongada, un acuerdo permanente con una empresa especializada, solicitudes a los contratistas
- Preparación frente a clientes: el texto del aviso y el punto de contacto en caso de filtración (JPCERT/CC recomienda preparar por adelantado advertencias frente a daños posteriores)
Algunos sectores también han recibido solicitudes de su regulador. La FSA pidió a las entidades financieras que revisen sus controles, incluidas la gestión del riesgo de terceros y la respuesta a incidentes, y que actúen con prontitud ante cualquier carencia. También les pidió que comprueben si en la verificación de identidad en línea hay algo poco natural en las imágenes de documentos de identidad y en las imágenes faciales, y que pasen a leer los chips IC con antelación, antes del 1 de abril de 2027, fecha en la que deja de aceptarse como método válido el envío de imágenes de documentos de identidad.
Opinión de este sitio: «no estaban los registros» es un resultado, no una comprobación fallida
Las comprobaciones de la IPA suponen que puede revisar un mes y después tres meses. En la práctica, los equipos suelen descubrir que los registros estaban configurados para caducar a los 30 días, o que la consola de un servicio externo solo muestra dos semanas.
En ese caso, no informe de «ninguna anomalía». El informe preciso es «ninguna anomalía en el último mes; los periodos anteriores no pudieron comprobarse». Dejar por escrito qué periodos y sistemas no pudo revisar indica directamente las siguientes mejoras: conservación más prolongada, envío de registros a otro lugar, consulta al proveedor. La comprobación de esta semana sirve tanto para aprender hasta dónde puede ver como para encontrar anomalías.
Mensajes para el personal y los clientes
La NPA, al citar las filtraciones que continúan, pide a las empresas que mantengan actualizados los equipos conectados a internet y que usen contraseñas seguras, y pide a las personas que no hagan clic de forma descuidada en enlaces de correos electrónicos (pueden ser correos falsos que se hacen pasar por la empresa que filtró datos), que no reutilicen contraseñas y que usen autenticación multifactor. Después de un incidente, pueden aumentar los mensajes falsos que usan el nombre de su organización. Indique al personal y a los clientes que verifiquen cualquier contacto a través de su sitio web oficial. Consulte ¿qué es el phishing? para saber cómo detectarlo.
Fuentes (oficiales, en japonés)
- Secretaría del Gabinete, Oficina Nacional de Ciberseguridad: Respuesta a las filtraciones de datos causadas por acceso no autorizado (9 de octubre de 2026) — cyber.go.jp
- IPA: Medidas que deben adoptarse con prontitud ante las filtraciones de datos causadas por acceso no autorizado (9 de octubre de 2026, actualizado según sea necesario) — ipa.go.jp
- IPA: Apertura de una mesa especial de consulta sobre acceso no autorizado (16 de octubre de 2026, en japonés) — ipa.go.jp
- IPA: Sitio especial para hacer frente al acceso no autorizado (16 de octubre de 2026, en japonés) — ipa.go.jp
- JPCERT/CC: Alerta sobre la reciente serie de incidentes de acceso no autorizado en organizaciones japonesas (JPCERT-AT-2026-0030, publicada el 8 de octubre de 2026, actualizada el 23 de octubre) — jpcert.or.jp
- JPCERT/CC: Análisis de las técnicas de ataque utilizadas en la serie de casos de acceso no autorizado (JPCERT/CC Eyes, 15 de octubre de 2026, en japonés) — blogs.jpcert.or.jp
- Comisión de Protección de Información Personal: Respuesta a las filtraciones de datos a gran escala (advertencia) (7 de octubre de 2026; vídeo explicativo añadido el 9 de octubre) — página del aviso / advertencia y anexo (PDF) / comunicado de prensa (PDF)
- Comisión de Protección de Información Personal: ADVERTENCIA: prevención de filtraciones de datos personales causadas por acceso no autorizado (11 de diciembre de 2024, revisada el 7 de octubre de 2026) — ppc.go.jp
- Agencia de Servicios Financieros: Refuerzo de la ciberseguridad y tramitación de solicitudes de cuentas en la situación actual (9 de octubre de 2026) — fsa.go.jp
- Agencia Nacional de Policía: Cyber Police Agency Letter 2026 Vol.19 (octubre de 2026) — npa.go.jp
- JPCERT/CC: solicitud de respuesta a incidentes — jpcert.or.jp
- IPA: notificación de virus informáticos y accesos no autorizados — ipa.go.jp
Análisis de empresas de seguridad japonesas (no son documentos oficiales, en japonés):
- Macnica Security Research Center: Sobre la serie de filtraciones de datos de sistemas web (7 de octubre de 2026, adenda del 8 de octubre) — security.macnica.co.jp
- GMO Cybersecurity by IERAE: Tres puntos para prepararse ante la serie de incidentes de acceso no autorizado (15 de octubre de 2026) — gmo-cybersecurity.com
- GMO Cybersecurity by IERAE: Confirmado que la IA está detrás de muchos de los orígenes de los recientes accesos no autorizados (19 de octubre de 2026, actualizado el 21 de octubre) — gmo-cybersecurity.com
Historial de actualizaciones
2026-10-24: Se recoge la alerta de JPCERT/CC tal como se actualizó el 23 de octubre. Los patrones de ataque pasan de cuatro a cinco (caso E: intentos de ataque que abusan de plataformas de pruebas de penetración basadas en IA, incluidos los intentos contra servidores WSUS expuestos a internet). Se añaden las nuevas pistas del caso B (el mismo User-Agent que la aplicación pública, JA4 por sí solo no puede identificar al atacante, acceso a través de Tor y proxies residenciales, y uso de las direcciones IP para buscar accesos pasados). Se añade un enlace al panorama de los ataques basados en IA y al orden de la defensa.
2026-10-23: Se añaden los análisis de dos empresas de seguridad japonesas (7, 15 y 19 de octubre): el 80 % de las filtraciones comunicadas desde julio no puede clasificarse por causa a partir de los avisos, ataques que se mantienen por debajo de los umbrales del WAF, el uso de un sistema autónomo de pruebas de penetración basado en IA, y tres comprobaciones (alcance de la evaluación, no confiar en un WAF, reducción de datos y claves de API innecesarios).
2026-10-22: Se añade el examen de servidores de atacantes realizado por JPCERT/CC (publicado el 15 de octubre): API identificadas mediante el análisis de aplicaciones, y cuatro contramedidas. Se menciona Flutter como ejemplo de aplicaciones compiladas, como hace JPCERT/CC.
2026-10-19: Se añade la mesa especial de consulta de la IPA sobre acceso no autorizado (abierta el 16 de octubre) y su sitio especial. Se confirma que la alerta de la IPA del 9 de octubre no se había actualizado a 19 de octubre.
2026-10-14: Se revisó el cuerpo de la advertencia de la PPC y se resumió en una tabla su anexo sobre los ejemplos revisados de «10-6 Salvaguardas técnicas» (que se ultimarán en abril de 2027). Se añadieron al control de aplicaciones expuestas a internet las contramedidas del caso 9 (abuso de API) de la ADVERTENCIA revisada, y al control de servicios externos el caso 8 (una filtración desde un servicio de nube que se utiliza). Se actualizaron la lista de documentos y las fuentes.
2026-10-12: Primera publicación. Documentos de la Oficina Nacional de Ciberseguridad, la IPA, JPCERT/CC, la PPC, la FSA y la NPA revisados el 12 de octubre de 2026. La página de la IPA se actualiza según sea necesario y la alerta de JPCERT/CC puede recibir adiciones; este artículo se actualizará si cambian.
Lecturas recomendadas
- Panorama completo de los ataques basados en IA y orden de la defensa: Defensa frente a ciberataques basados en IA (intrusión autónoma, inyección de prompts, cadena de suministro de IA)
- Visión general para organizaciones: La base de seguridad para organizaciones (seis prioridades a partir de los incidentes de Japón de 2026)
- Comprobación de su propio sitio: Cómo comprobar si su sitio web o servidor ha sido hackeado
- Puntos de entrada: Los dispositivos VPN son la vía de entrada más habitual / Priorizar con CVSS, EPSS y KEV
- Inventario: Lista de verificación del inventario de seguridad / Exposición pública del almacenamiento en la nube
- Términos: ¿Qué es un IOC?
- Todos los incidentes de 2026: Filtraciones de datos y ciberataques de 2026