Para quién es esto: para cualquier persona responsable de la seguridad de una empresa o de su propio sitio. No es un análisis de un incidente concreto; es el patrón que aparece al alinear lo que las organizaciones japonesas divulgaron en agosto de 2026. Todos los datos proceden de esas divulgaciones y de la cobertura periodística; no hay inferencias sobre la causa.
Clasificados por vía de entrada
Según lo que publicó cada organización; cifras y causas solo tal como fueron divulgadas.
| Divulgado | Organización | Punto de partida | Clase |
|---|---|---|---|
| 3 ago | Kodansha | Buzón corporativo: contactos robados, y se envió correo suplantando a ese empleado a algunos de ellos | Credencial |
| 4 y 7 ago | Innovation Co. | Credenciales de GitHub: la empresa divulgó dos fallos: tokens codificados en la configuración y datos personales almacenados en repositorios | Credencial |
| 13 ago | Charm | Acceso no autorizado a la tienda en línea (–230.000 registros, incluidos hashes de contraseñas) | Directo |
| 14 ago | Nichirei | Ransomware (fallo del sistema el 13 de julio; datos de empleados posiblemente expuestos) | Directo |
| 17 y 19 ago | Sakura Internet | El entorno de gestión del proveedor, luego el sistema de gestión de contratos (hasta 1.360.563 cuentas de miembros en el alcance) | Credencial / proveedor |
| 20 ago | Expo 2025 Association | El Microsoft 365 de un subcontratista, a partir de un correo de phishing recibido el 13 de mayo | Credencial / proveedor |
| 20 ago | VOISING | Una herramienta de BI (hasta ~170.000 personas) | Credencial / SaaS |
| Ago | JST (según informes) | Acceso a buzón (~16.000 mensajes) | Credencial |
| 12 ago | OCS, ANA Group (según informes) | Una vulnerabilidad en la aplicación | Directo |
Cómo leer estas cifras
Las cifras anteriores son las publicadas en su momento, y la mayoría de las investigaciones siguen en curso. En particular, los 1.360.563 de Sakura Internet son el número de registros de miembros potencialmente en el alcance, no una filtración confirmada; la empresa afirma que no se ha confirmado ninguna exfiltración. No tomar como definitiva una cifra bajo investigación es la habilidad básica para leer coberturas como esta.
Por qué asegurar sus propios sistemas no basta
Inicio: una cuenta legítima fuera de su control
el M365 de un proveedor / una herramienta de BI / un buzón / un token de GitHub / la consola de un proveedor
El atacante realiza acciones ordinarias
inicia sesión normalmente con la credencial robada y lee datos con normalidad
Su servidor (sin tocar)
los parches, el WAF y la CSP no se aplican a esta vía
Una vulnerabilidad explotada significa que alguien entró por un fallo, así que corregir el fallo lo detiene. Una credencial robada significa que alguien inició sesión normalmente, así que no hay ningún fallo que corregir. Lo que hay que proteger es la propia credencial: quién la tiene, dónde se almacena y cuánto tiempo sigue siendo válida.
Lo que no funciona aquí
- Parcheo: irrelevante para un ataque que no explota nada
- WAF / IPS: un inicio de sesión legítimo no parece anómalo
- «Somos demasiado pequeños para ser objetivo»: el objetivo fue un proveedor, y usted resultó afectado como cliente suyo
- Cambiar el modelo de alojamiento: un VPS no evita el robo de credenciales
Lo que sí funciona
- Autenticación multifactor, especialmente en correo, alojamiento de código y administración de SaaS
- Credenciales de vida corta y alcance acotado: retire los tokens de larga duración
- Un inventario de proveedores y SaaS que pueden acceder a sus datos
- Ningún secreto codificado en la configuración; ningún dato personal en repositorios
- Planificar suponiendo que fue leído: reduzca lo que hay que robar
Qué hacer
Enumere los servicios externos y subcontratistas de los que depende
Alojamiento, SaaS, herramientas de BI, plataforma de correo, alojamiento de código y subcontratistas. Sin esa lista ni siquiera puede responder «¿estamos en el alcance?» cuando salta la noticia. Cómo elaborarla: la lista de comprobación de inventario de activos.
Active primero la autenticación multifactor en el correo y el alojamiento de código
Varios de los puntos de partida anteriores fueron buzones y credenciales de alojamiento de código. Ambas son cuentas desde las que se puede volver a emitir todo lo demás, así que tienen prioridad sobre el resto. → cómo elegir la autenticación multifactor
Inventaríe las credenciales de larga duración y acorte su vida útil y alcance
Secretos en archivos de configuración, tokens de acceso sin caducidad, claves válidas en todos los repositorios. Suponga que serán robadas, y haga que lo que un ladrón obtenga sea pequeño y de corta duración. → qué es peligroso en .env y las claves de API / cómo evitar secretos en el momento del commit
Determine de antemano qué ocurre si su proveedor sufre una brecha
Cuando llegue el aviso de que su proveedor fue comprometido, ¿qué pierde realmente? Responder a eso de antemano decide qué hace el día en que ocurra. → qué hacer cuando se produce una brecha en su proveedor de alojamiento web
Suponga que seguirá el phishing oportunista
Los grandes incidentes siempre van seguidos de correos que los suplantan. En un caso de agosto se divulgó que se envió correo suplantando al empleado a los contactos robados. No haga clic en enlaces de un correo de «notificación de incidente»; abra usted mismo el sitio oficial. → qué es el phishing
Opinión de este sitio: esto no es una historia de grandes empresas
La tabla enumera grandes organizaciones, pero los lugares donde empezó no tienen nada que ver con el tamaño: un buzón, derechos de administrador de SaaS, credenciales dejadas en un repositorio. Es igual para un desarrollador independiente, e incluso peor, porque una operación pequeña depende más de servicios externos y una sola credencial suele dar acceso a más. Nuestra postura es coherente: ahora mismo, no entregar credenciales más allá de lo necesario y no dejarlas sin uso, aporta más que intentar que los sistemas sean imposibles de vulnerar. Mantenga el parcheo como base y centre el foco en las credenciales.
Fuentes
Los datos proceden de la divulgación de cada organización y de la cobertura periodística. No hay atribución de causa ni de responsabilidad más allá de lo publicado.
- Sakura Internet — primer informe (17 de agosto) / segundo informe (19 de agosto, actualizado el 26 de agosto) / preguntas frecuentes
- Expo 2025 Association — informe sobre el acceso no autorizado en un subcontratista (20 de agosto)
- Kodansha — aviso sobre la exposición de datos personales (3 de agosto)
- Charm — aviso sobre acceso no autorizado (13 de agosto)
- Innovation Co. — informe final sobre el incidente de GitHub (7 de agosto)
- Cobertura sobre Nichirei — @IT (15 de agosto)
- Cobertura sobre VOISING — ITmedia NEWS (21 de agosto)
Lea a continuación
- Casos recientes que partieron de una cuenta o de un acceso de proveedor: Navigate360 P3 (plataforma de denuncias Crime Stoppers) / ASOS (Reino Unido, datos de clientes)
- Un caso de un sitio de empleo en el que se usó indebidamente una clave en la nube de un contratista: MyBRANDS
- Todos los incidentes de 2026 (Japón y en el mundo): lista de brechas y ciberataques, y cómo difiere la vía de entrada
- Comparación de los principales casos de 2026: qué tienen en común KDDI, Aflac, la Digital Agency y Sakura Internet
- Cuando la VPN es la vía de entrada: los dispositivos VPN son la principal vía de entrada del ransomware: defensa del acceso remoto tras la brecha de la Digital Agency
- Preparación: la lista de comprobación de inventario de activos / cómo elegir la autenticación multifactor
- Cuando el proveedor sufre una brecha: qué hacer cuando su alojamiento web es comprometido
- Cuando se roban credenciales de nube de desarrollo: el acceso no autorizado a Nikkei (unos 1,83 millones de registros)
- Cuando se obtienen credenciales de operación en la nube: el acceso no autorizado a los servicios en la nube de Digital Arts
- Robo de credenciales: cuando una sola instalación de npm roba sus credenciales / qué es peligroso en .env y las claves de API
- Diseño: fallos de diseño en el restablecimiento de contraseñas, donde el propio proceso de restablecimiento de un servicio entrega credenciales a un atacante
- Caso: el ransomware de KADOKAWA (2024), con credenciales robadas mediante phishing como punto de entrada