El operador de telecomunicaciones japonés KDDI confirmó que atacantes explotaron una vulnerabilidad de día cero en software de terceros para vulnerar una plataforma de correo compartida que gestiona para proveedores de servicios de internet. La intrusión ocurrió el 16 de mayo de 2026, y KDDI no la detectó hasta el 17 de junio. Cuando la empresa terminó su evaluación, las cifras eran contundentes: aproximadamente 12,23 millones de direcciones de correo electrónico y 7,61 millones de contraseñas expuestas en seis proveedores, incluyendo STNet, JCOM, Chubu Telecommunications, NIFTY y BIGLOBE. Un mes después, el Consejo Antiphishing de Japón publicó su informe de junio y trazó una línea directa entre esa filtración y un repunte de phishing que acababa de presenciar, uno que ninguna cantidad de aplicación de DMARC por sí sola podría haber detenido.
Una Filtración en Infraestructura Compartida, No en una Sola Empresa
KDDI no operaba directamente cuentas de correo de consumidores. Gestionaba la plataforma subyacente en la que varios de los mayores proveedores de internet de Japón se apoyaban para ofrecer servicio de correo a sus propios clientes, precisamente por eso una vulnerabilidad en un solo software de terceros se convirtió en un incidente multiproveedor en lugar de uno contenido. Cuando falla la infraestructura compartida, el radio de impacto alcanza a todos los que construyeron sobre ella, no solo al operador cuyo nombre aparece en el aviso de la filtración. KDDI reportó el incidente al Ministerio de Asuntos Internos y Comunicaciones de Japón, forzó el restablecimiento de contraseñas en los proveedores afectados, y completó una auditoría forense el 23 de junio confirmando que la vulnerabilidad había sido cerrada.
El Repunte que el Consejo Vio Coincidir
El Consejo Antiphishing de Japón publicó su informe mensual de junio de 2026 el 16 de julio, registrando 72.370 reportes de phishing y 42.241 URLs de phishing únicas durante el mes. El hallazgo principal del informe fue un fuerte aumento, a partir de aproximadamente el 10 de junio, de phishing enviado a través de cuentas de correo genuinamente comprometidas en proveedores de internet nacionales, apenas semanas después de que se expusieran credenciales de las plataformas vinculadas a KDDI. La conclusión del consejo fue directa: las credenciales de correo de un ISP filtradas no se quedan contenidas en la cuenta de la que fueron robadas. Se reutilizan en banca, comercio minorista y otros servicios, y las propias cuentas se convierten en plataformas de lanzamiento para más phishing enviado desde direcciones con un historial de envío real e intachable.
Por Qué Este Es el Phishing Que DMARC No Puede Detectar
DMARC verifica si la infraestructura de envío de un mensaje está autorizada a usar el dominio de su encabezado From. Cuando un atacante toma el control de una cuenta real con una contraseña robada, esa verificación no tiene nada que fallar. El mensaje sale a través del propio servidor de correo legítimo de la cuenta, se firma con la propia clave DKIM válida de la cuenta, y se alinea perfectamente con SPF y el dominio From, porque todo en él es genuino excepto la persona que lo escribe. Esto es estructuralmente diferente de la suplantación, donde DMARC bloquea directamente a un remitente falsificado, y también diferente del abuso de notificaciones de plataforma, donde la infraestructura real de una empresa es engañada para enviar en nombre de un atacante. Aquí no hay infraestructura que engañar. La cuenta misma ha sido entregada.
Por Qué el Consejo Recurrió a DMARC Reject de Todos Modos
Podría parecer extraño responder al phishing por toma de cuentas impulsando a los dominios remitentes hacia una aplicación más estricta de DMARC, ya que DMARC no puede ver dentro de un buzón comprometido. Pero la guía del consejo apunta a un riesgo adyacente distinto que siempre sigue a una filtración de credenciales de este tamaño: una vez que los grupos atacantes tienen credenciales funcionales de buzones de ISP, usan esos mismos dominios y patrones de inicio de sesión para probar intentos de suplantación contra cada empresa con la que esos usuarios interactúan. Un dominio en p=none o p=quarantine ofrece un lugar donde puede aterrizar ese tráfico de suplantación posterior. Pasar a p=reject no detiene que el buzón comprometido envíe phishing real bajo su propia identidad real, pero sí cierra la puerta a que los atacantes añadan tráfico falsificado similar encima del caos que crea una filtración como esta, mientras los servidores de correo receptores ya están predispuestos a desconfiar de los dominios afectados.
BIMI y Passkeys Completan la Respuesta
Las otras dos recomendaciones del consejo apuntan a lo que DMARC estructuralmente no puede hacer: BIMI da a los destinatarios una señal visual verificada para el correo legítimo una vez que la aplicación de DMARC está en marcha, haciendo marginalmente más fácil notar cuando un mensaje carece de esa señal incluso si técnicamente se autentica. Las passkeys atacan la causa raíz directamente, ya que la autenticación resistente al phishing hace que una contraseña robada no valga nada por sí sola, exactamente el tipo de credencial que esta filtración puso en circulación por millones.
Lo Que Esto Significa Más Allá de Japón
Trata cualquier exposición masiva de credenciales, ya sea propia o de un proveedor, como un evento de preparación ante phishing, no solo como una obligación de notificación. Si una plataforma de la que depende tu organización o sus usuarios revela una filtración, asume que las cuentas comprometidas se usarán para enviar phishing convincente y totalmente autenticado en cuestión de semanas.
Avanza hacia DMARC reject antes de que un incidente te obligue a acelerar el calendario. Tener la aplicación en marcha antes de una filtración significa una cosa menos a la que reaccionar cuando el tráfico falsificado empiece a sondear la reputación de tu dominio tras el incidente.
Adopta autenticación resistente al phishing en todo lo que tu organización pueda. Las contraseñas filtradas masivamente son ya una certeza en este momento de la industria; la respuesta que realmente funciona es eliminar por completo el valor de la contraseña.
Monitorea patrones de toma de cuentas, no solo fallos de autenticación. Un aumento en la tasa de aprobación de DMARC combinado con un comportamiento de envío inusual desde una fuente conocida y confiable suele ser la única señal visible de que una cuenta real ha sido secuestrada.
La Conclusión
La filtración de KDDI y el repunte de phishing que la siguió son un recordatorio de que la aplicación de DMARC y la seguridad de las cuentas resuelven problemas distintos que resultan estar justo uno al lado del otro. Una contraseña robada convierte un buzón legítimo en un arma de phishing totalmente autenticada que DMARC dejará pasar cada vez. La respuesta correcta no es abandonar la aplicación de DMARC porque no puede ver esta amenaza. Es seguir reforzándola para las amenazas que sí puede detener, de modo que cuando una filtración como esta ocurra inevitablemente en algún punto de tu cadena de proveedores, el tráfico falsificado que la sigue no sea un problema más que tengas que combatir.
Excello Mail mantiene tu dominio con DMARC en aplicación total y te da visibilidad clara de cada fuente que dice enviar en tu nombre, para que cuando ocurra una filtración en algún otro punto del ecosistema, tu propio dominio no sea un blanco fácil para el tráfico falsificado que le sigue. Regístrate gratis en Excello Mail y lleva tu dominio a reject antes de necesitarlo.