KDDI confirma vazamento de 12 milhões de e-mails e 7,6 milhões de senhas em plataforma para ISPs japoneses

A KDDI, segunda maior operadora móvel do Japão, confirmou que um ataque cibernético expôs 12,2 milhões de endereços de e-mail e 7,6 milhões de senhas de clientes de cinco provedores de internet do país. A intrusão explorou uma vulnerabilidade em software de terceiros na plataforma de e-mail que a KDDI opera para os ISPs — e o incidente entra numa fila crescente de ataques a corporações japonesas de peso, incluindo Aflac Japão, Nidec e Sapporo.

O que aconteceu

Em comunicado enviado ao Ministério das Comunicações do Japão nesta segunda-feira (7), a KDDI concluiu formalmente a apuração de um incidente inicialmente reportado em junho. Os números finais são vertiginosos: 12,2 milhões de endereços de e-mail e 7,6 milhões de senhas comprometidos numa única plataforma. O sistema afetado é usado para gerenciar contas de e-mail, webmail e storage de mensagens de cinco provedores japoneses de internet — a KDDI opera o serviço em regime de white label para eles.

Segundo a operadora, os atacantes exploraram uma falha em software de terceiros embarcado na plataforma. A KDDI não revelou o fornecedor nem o CVE específico, mas afirma ter aplicado o patch e reconfigurado o sistema imediatamente após detectar a intrusão. A investigação forense, ainda segundo a empresa, não encontrou evidência de que a movimentação lateral tenha extrapolado o ambiente da vulnerabilidade explorada.

Um detalhe que a KDDI faz questão de sublinhar: o serviço de e-mail próprio, oferecido a clientes móveis e de banda larga da marca, roda em infraestrutura separada e não foi afetado. Ou seja, o rombo está do lado dos ISPs parceiros, não da base direta da operadora.

Impacto e resposta

“Muitos clientes que usam o serviço de e-mail com regularidade já trocaram suas senhas. Estamos analisando o escopo do impacto e a causa raiz, respondendo aos clientes em coordenação com os ISPs e adotando medidas para evitar reincidência.” — Comunicado oficial da KDDI

Os cinco provedores parceiros estão executando resets forçados de senha nos próximos dias. Como a proporção mostra — 7,6 milhões de senhas expostas para 12,2 milhões de endereços — significa que aproximadamente 62% dos usuários da plataforma tiveram credenciais completas vazadas. A gigante ainda não confirmou publicamente se as senhas estavam armazenadas em hash com salt ou em texto claro, ponto que costuma ditar a gravidade real de vazamentos desse porte.

Uma onda japonesa

O incidente KDDI se soma a uma sequência que virou pauta constante no país nas últimas semanas. A unidade japonesa da seguradora Aflac reportou breach; a Nidec, fabricante de motores elétricos e componente crítico de cadeias automotivas globais, também admitiu comprometimento; e a cervejaria Sapporo Holdings sofreu disrupção com origem cibernética. Nenhum dos casos foi publicamente conectado — mas o padrão de “grande empresa japonesa vira alvo em 2026” é robusto o suficiente para chamar atenção de CSIRTs regionais.

Para completar o clima, a polícia de Tóquio anunciou nesta semana a prisão de um estudante de 15 anos por explorar uma vulnerabilidade nos servidores do serviço de streaming de anime Bandai Channel para cancelar fraudulentamente mais de 46 mil assinaturas de usuários — um lembrete de que insiders adolescentes com boa curiosidade técnica continuam sendo uma superfície de ameaça subestimada.

Análise

O caso KDDI é escola em dois eixos. O primeiro é o eterno supply-chain: a operadora responsabilidade e o volume de dados são dela, mas a falha estava em software de terceiros embarcado. Isso repete o padrão dos maiores incidentes de 2024 e 2025 — MoveIt, Fortinet, Ivanti, Cleo, mais recentemente o VMware Cloud Foundation. Fornecedores de plataforma são o novo perímetro, e o comprador da plataforma paga a conta reputacional.

O segundo eixo é o modelo MSP-para-ISPs. A KDDI centraliza serviço de e-mail para cinco provedores. Quando esse tipo de arquitetura falha, o impacto é multiplicado pelo número de tenants. É a mesma dinâmica que vimos em incidentes como Kaseya, ConnectWise ScreenConnect e SolarWinds — só que agora aplicada a telco. À medida que operadoras assumem cada vez mais funções de MSP para seus revendedores de banda larga, esse tipo de incidente deve virar rotineiro.

Do lado dos usuários finais, o risco imediato não é só o e-mail. É credential stuffing: 7,6 milhões de pares e-mail-senha viram combustível para tentativas automatizadas contra bancos, exchanges, redes sociais e apps de e-commerce — no Japão e onde quer que esses e-mails tenham sido reutilizados. Historicamente, listas asiáticas grandes acabam alimentando campanhas globais em questão de semanas.

Quem deve se preocupar

• Clientes dos cinco ISPs japoneses cujo e-mail era hospedado pela plataforma da KDDI — devem forçar reset e revogar sessões ativas em qualquer serviço que use aquele e-mail como conta.
• Qualquer usuário global que tenha reutilizado credenciais compradas ou obtidas em serviços japoneses — a reciclagem de senha é o multiplicador clássico.
• Empresas B2B/SaaS globais com contas ligadas a esses domínios de e-mail — devem monitorar picos de login anômalo nos próximos 30 a 60 dias.
• CISOs de operadoras e provedores fora do Japão — o modelo de e-mail terceirizado a fornecedor único é bandeira vermelha em qualquer risk assessment de 2026.

Recomendações práticas

• Force reset de senha imediato em todas as contas que compartilham a senha comprometida — plataformas de gestão de senhas ajudam a mapear a reutilização.
• Habilite MFA em toda conta que suporte, priorizando e-mail primário, gerenciador de senhas e banco.
• Monitore listas de vazamento como Have I Been Pwned e assine notificações — a coleção KDDI deve ser publicada em pouco tempo.
• Para SOCs corporativos: configure regras de credential stuffing detection e prepare-se para picos de tentativas usando essa base nas próximas semanas.
• Para arquitetos: revise contratos com fornecedores de plataforma para incluir cláusulas de notificação em 24-72h, direito a auditoria de código e SBOM atualizado — o padrão SOC 2 sozinho não cobre o cenário.
• Para reguladores brasileiros: vale acompanhar como o comunicações-ministério japonês trata o caso; incidentes com plataformas white label estão fora da leitura corrente da LGPD, mas a ANPD deve ficar atenta ao paralelo doméstico.

Fonte: The Record