Quien sigue las noticias de seguridad en Japón lo ha notado: desde septiembre de 2026 aparece casi cada semana un nuevo aviso de filtración. Programas de fidelización, apps de restaurantes, sitios de reservas, plataformas de comunidad y portales de empleo publicaron avisos uno tras otro — varios ya cubiertos aquí, como los casos de Lawson ID, Bookoff, Commune y Baitoru.
Entre el 8 y el 9 de octubre, los organismos oficiales de seguridad del país reaccionaron en bloque. JPCERT/CC publicó la alerta JPCERT-AT-2026-0030, la IPA (Agencia de Promoción de Tecnologías de la Información) difundió una lista de comprobaciones "para hacer de inmediato" y el METI (Ministerio de Economía, Comercio e Industria) envió una solicitud formal a las asociaciones empresariales. Este artículo resume lo que dicen esos documentos, en lenguaje práctico, para quien administra sistemas en pequeñas y medianas empresas.
Una advertencia importante antes de empezar: ninguno de estos organismos ha atribuido la filtración de una empresa concreta a un método de ataque concreto. Los casos citados arriba solo sirven de contexto de la ola — no decimos que cada uno haya ocurrido como se describe abajo.
Qué dijo JPCERT/CC
La alerta AT-2026-0030 se publicó el 8 de octubre y se actualizó el 9 de octubre de 2026. JPCERT/CC afirma que, hacia septiembre, hubo una serie de filtraciones de datos personales por acceso no autorizado en organizaciones japonesas, y que la información técnica compartida todavía es "limitada y fragmentaria". Aun así, decidió alertar por la expansión de los daños.
Dos puntos destacan:
- La alerta trata un tipo de ataque distinto de los casos de ransomware que ocurren de forma esporádica todo el tiempo: aquí el foco son intrusiones que llevan a filtrar grandes volúmenes de datos personales.
- No son solo apps para el público. También fueron afectadas herramientas de BI (inteligencia de negocio) y sistemas de gestión para empleados — sistemas que, para quien los opera, "no están expuestos a cualquiera".
JPCERT/CC subraya que no todos los incidentes usaron el mismo método y que la página se actualizará según surja nueva información.
Los cuatro patrones de ataque observados
La alerta describe cuatro "casos" basados en los informes recibidos. Los resumimos a nivel defensivo, sin detalles operativos:
- Caso A — escaneo de vulnerabilidades conocidas. No es un fallo único de un producto. Los atacantes prueban, objetivo por objetivo, muchas vulnerabilidades ya conocidas y también errores de configuración, como archivos de configuración del entorno o copias de seguridad olvidadas en lugares accesibles.
- Caso B — abuso de APIs. Peticiones indebidas a APIs de administración de apps, con alteración de datos. Los informes incluyen análisis de apps móviles públicas para descubrir endpoints y claves; ataques a APIs internas que no deberían ser accesibles desde la interfaz (cambio de permisos de usuario, creación de cuentas indebidas); pruebas con tokens de autenticación malformados; búsquedas ciegas mediante inyección NoSQL para identificar cuentas; y uso de claves de API robadas en intrusiones a otros sistemas.
- Caso C — Metabase CVE-2026-72898. La vulnerabilidad de inyección SQL en la herramienta de BI Metabase, también explotada vía API, sobre la que JPCERT/CC ya había alertado el 14 de agosto. La cubrimos en Metabase CVE-2026-72898.
- Caso D — web shell en servidor de aplicaciones. Se encontraron archivos WAR desplegados en servidores de aplicaciones accesibles desde el servidor web público; el JSP que contenían funcionaba como una web shell simple.
JPCERT/CC también publicó direcciones IP de origen sospechosas y ejemplos de User-Agent para ayudar en las investigaciones, con la advertencia de que algunas IP pueden estar hoy en uso legítimo. Si necesita revisar sus logs, use la lista directamente en la página oficial (enlace en las fuentes): puede actualizarse.
Las medidas recomendadas para APIs
La parte más útil de la alerta es la lista de contramedidas. Para el acceso vía API, JPCERT/CC recomienda:
- Limitar el número de peticiones por unidad de tiempo y bloquear accesos repetidos o ejecución masiva.
- Fijar límites específicos para funciones de alto riesgo: inicio de sesión, restablecimiento de contraseña, envío de SMS y búsqueda.
- Aplicar control de acceso en cada endpoint, incluidas las APIs no públicas, aceptando solo usuarios y métodos HTTP autorizados.
- Dar a usuarios y tokens de API solo los permisos mínimos necesarios.
- Definir una caducidad adecuada para los tokens y evitar tokens de larga duración.
- Poder revocar rápidamente los tokens que ya no se usan o que pueden haberse filtrado.
Medidas generales complementarias: restringir la región de origen cuando el servicio se usa en un solo país; aplicar actualizaciones de versiones vulnerables; revisar la contención del movimiento lateral tras la intrusión en un servidor web; revisar la detección y la respuesta inicial; orientar a los clientes con antelación (por ejemplo, sobre la autenticación multifactor); sacar de internet funciones de administración innecesarias; y no conservar datos después del plazo legal o del fin de su propósito. La referencia indicada es el OWASP API Security Top 10.
La lista de comprobación inmediata de la IPA
El 9 de octubre, la IPA publicó un documento dirigido a directivos de empresas que guardan muchos datos. Según la agencia, los avisos de filtración llegan de sectores variados, incluidas entidades financieras y operadoras de telecomunicaciones, y todavía no puede afirmarse que los ataques apunten a una vulnerabilidad de producto concreta. Por el patrón de los casos públicos, el punto de partida parece ser la intrusión en aplicaciones y servicios expuestos al exterior y el compromiso de cuentas.
Las comprobaciones que la IPA pide hacer ya:
- Aplicaciones expuestas: inventariar todas las apps y servicios propios publicados en internet; revisar en los logs recientes señales anómalas (volumen de errores, diferencias con lo habitual), empezando por el último mes y ampliando a tres meses; comprobar si hay parches pendientes y aplicarlos cuanto antes.
- Servicios externos que usa la empresa: listarlos todos — nube, VPN y otros —, incluidos los contratados por departamentos; revisar los logs de cada servicio (inicios de sesión fallidos, IP y horarios de acceso inusuales); y buscar cuentas que nadie creó o cuentas desactivadas que volvieron a estar activas.
- Datos almacenados: revisar lo que la empresa realmente necesita conservar, porque los datos robados hoy se convierten en extorsión y venta en foros.
Si aparece cualquier log o cuenta anómala, la IPA indica tratarlo de inmediato como incidente de seguridad y recomienda encarecidamente contratar a una empresa especializada para la investigación.
Después, la agencia enumera medidas a medio plazo: revisar lo que queda expuesto, reforzar la autenticación (MFA y contraseñas), revisar permisos e integraciones vía API, ampliar el contenido y el tiempo de retención de los logs, y replantear dónde y cómo se almacenan los datos, incluido el cifrado.
La solicitud del METI
El METI trasladó las alertas de la NCO (Oficina Nacional de Ciberseguridad), de JPCERT/CC y de la Comisión de Protección de Información Personal (PPC) a asociaciones empresariales como JADMA (asociación japonesa de venta por catálogo y comercio electrónico) y la Cámara de Comercio e Industria de Japón. El ministerio pide tres cosas: liderazgo directo de la alta dirección, seguimiento rápido de la información sobre vulnerabilidades y migración a "zero trust", teniendo en cuenta toda la cadena de suministro. Si hay un incidente, las empresas de los sectores supervisados deben informar al ministerio con la cronología, el tipo de daño y el tipo de ataque, y considerar también avisar a la policía.
Qué debería hacer una pyme esta semana
Traduciendo los documentos a una rutina realista:
- Haga inventario. Liste todo lo que está en internet con el nombre de la empresa: web, tienda online, app, panel de administración, herramienta de BI, VPN y servicios en la nube contratados por cada área.
- Revise los logs de los últimos 30 días. Busque picos de errores, inicios de sesión desde países donde no opera, volúmenes inusuales de llamadas a la API y cuentas nuevas que nadie reconoce.
- Cierre lo que no necesita estar abierto. Los paneles de administración y las herramientas internas no deberían responder a cualquier IP de internet.
- Revise las claves de API. Revoque las antiguas, reduzca permisos y compruebe que ninguna clave esté incrustada en una app publicada.
- Actualice. Priorice los componentes expuestos y, si usan Metabase, confirmen la versión corregida.
- Borre lo que no necesita guardar. Menos datos, menos daño.
Para empresas pequeñas, la IPA recuerda que hay recursos gratuitos, como el autodiagnóstico de cinco minutos y la autodeclaración SECURITY ACTION, además del servicio "Cybersecurity Otasuketai", que reúne monitorización, atención in situ y seguro.
Lo que aún no se sabe
Los organismos no han vinculado los incidentes a un único grupo ni a un único fallo, y el propio JPCERT/CC dice que su panorama es parcial. Seguiremos las nuevas actualizaciones de AT-2026-0030 y los avisos de las empresas afectadas, y actualizaremos este artículo si hay cambios relevantes.
Fuentes
- JPCERT/CC: 直近で相次いでいる国内組織における不正アクセスに関する注意喚起 (JPCERT-AT-2026-0030)
- IPA: 不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について (2026-10-09)
- JADMA: 経済産業省の注意喚起及び情報提供に係る協力依頼 (2026-10-09)
- 日本商工会議所: 不正アクセスによる情報漏えい等の事案を踏まえたセキュリティ対策の徹底について（経済産業省）
- JPCERT/CC: MetabaseのSQLインジェクションの脆弱性（CVE-2026-72898）に関する注意喚起
- Impress Watch: 国内で情報漏えい被害が相次ぐ JPCERT/CCが攻撃手法と対策を公表
- マイナビ TECH+: 国内で不正アクセス相次ぐ、JPCERT/CCが注意喚起
- Macnica セキュリティ研究センター: 相次ぐWEBシステムからの情報漏洩事案について
- OWASP API Security Top 10 (2023)
¿Quieres llevar esto a tu negocio?
KGA IT ayuda a pequeñas y medianas empresas a implementar asistentes de IA, automatizaciones y sitios web. La consulta es gratuita y respondemos en menos de 24 horas. Planes desde ¥5.000/mes.
- Teléfono: 080-9732-1062
- Correo: kga-it@outlook.com
- Página de contacto: kga-it.com/es/contact