A operadora de telecomunicações japonesa KDDI confirmou que atacantes exploraram uma vulnerabilidade zero-day em software de terceiros para invadir uma plataforma de e-mail compartilhada que administra para provedores de serviços de internet. A invasão ocorreu em 16 de maio de 2026, e a KDDI só a detectou em 17 de junho. Quando a empresa concluiu sua avaliação, os números eram contundentes: aproximadamente 12,23 milhões de endereços de e-mail e 7,61 milhões de senhas expostos em seis provedores, incluindo STNet, JCOM, Chubu Telecommunications, NIFTY e BIGLOBE. Um mês depois, o Conselho Antiphishing do Japão publicou seu relatório de junho e traçou uma linha direta entre esse vazamento e um aumento de phishing que acabara de testemunhar, um aumento que nenhuma quantidade de aplicação de DMARC sozinha poderia ter impedido.
Um Vazamento em Infraestrutura Compartilhada, Não em Uma Única Empresa
A KDDI não operava diretamente contas de e-mail de consumidores. Ela gerenciava a plataforma subjacente da qual vários dos maiores provedores de internet do Japão dependiam para oferecer serviço de e-mail aos próprios clientes, e é exatamente por isso que uma vulnerabilidade em um único software de terceiros se transformou em um incidente multiprovedor em vez de um incidente contido. Quando a infraestrutura compartilhada falha, o raio de impacto atinge todos que construíram sobre ela, não apenas o operador cujo nome aparece no aviso do vazamento. A KDDI reportou o incidente ao Ministério dos Assuntos Internos e Comunicações do Japão, forçou a redefinição de senhas nos provedores afetados e concluiu uma auditoria forense em 23 de junho confirmando que a vulnerabilidade havia sido corrigida.
O Aumento que o Conselho Viu Coincidir
O Conselho Antiphishing do Japão publicou seu relatório mensal de junho de 2026 em 16 de julho, registrando 72.370 denúncias de phishing e 42.241 URLs de phishing únicas no mês. A principal conclusão do relatório foi um forte aumento, a partir de aproximadamente 10 de junho, de phishing enviado por meio de contas de e-mail genuinamente comprometidas em provedores de internet nacionais, surgindo poucas semanas depois que credenciais das plataformas ligadas à KDDI foram expostas. A conclusão do conselho foi direta: credenciais de e-mail de um ISP vazadas não ficam restritas à conta da qual foram roubadas. Elas são reutilizadas em bancos, varejo e outros serviços, e as próprias contas se tornam plataformas de lançamento para mais phishing enviado a partir de endereços com um histórico de envio real e impecável.
Por Que Este É o Phishing que o DMARC Não Consegue Detectar
O DMARC verifica se a infraestrutura de envio de uma mensagem está autorizada a usar o domínio em seu cabeçalho From. Quando um atacante assume o controle de uma caixa de entrada real com uma senha roubada, essa verificação não tem nada para falhar. A mensagem sai pelo próprio servidor de e-mail legítimo da conta, é assinada com a própria chave DKIM válida da conta, e se alinha perfeitamente com o SPF e o domínio From, porque tudo nela é genuíno, exceto a pessoa que a digita. Isso é estruturalmente diferente da falsificação, em que o DMARC bloqueia diretamente um remetente forjado, e também diferente do abuso de notificações de plataforma, em que a infraestrutura real de uma empresa é enganada para enviar em nome de um atacante. Aqui não há infraestrutura para enganar. A própria conta foi entregue.
Por Que o Conselho Recorreu ao DMARC Reject Mesmo Assim
Pode parecer estranho responder ao phishing por sequestro de conta pressionando os domínios remetentes a adotar uma aplicação mais rígida do DMARC, já que o DMARC não consegue ver dentro de uma caixa de entrada comprometida. Mas a orientação do conselho mira em um risco adjacente diferente que sempre acompanha um vazamento de credenciais desse tamanho: assim que grupos atacantes têm logins funcionais de caixas de entrada de ISPs, eles usam esses mesmos domínios e padrões de login para testar tentativas de falsificação contra todas as empresas com as quais esses usuários interagem. Um domínio em p=none ou p=quarantine oferece um lugar para esse tráfego de falsificação subsequente pousar. Migrar para p=reject não impede que a caixa de entrada comprometida envie phishing real sob sua própria identidade real, mas fecha a porta para que atacantes sobreponham tráfego falsificado semelhante ao caos criado por um vazamento como esse, enquanto os servidores de e-mail receptores já estão preparados para desconfiar dos domínios afetados.
BIMI e Passkeys Completam a Resposta
As outras duas recomendações do conselho miram no que o DMARC estruturalmente não consegue fazer: o BIMI dá aos destinatários um sinal visual verificado para e-mails legítimos quando a aplicação do DMARC já está em vigor, tornando marginalmente mais fácil perceber quando uma mensagem carece desse sinal mesmo que tecnicamente se autentique. As passkeys atacam a causa raiz diretamente, já que a autenticação resistente a phishing torna uma senha roubada sem nenhum valor sozinha, exatamente o tipo de credencial que esse vazamento colocou em circulação aos milhões.
O Que Isso Significa Além do Japão
Trate qualquer exposição massiva de credenciais, seja sua ou de um fornecedor, como um evento de preparação contra phishing, não apenas como uma obrigação de notificação. Se uma plataforma da qual sua organização ou seus usuários dependem revelar um vazamento, presuma que contas comprometidas serão usadas para enviar phishing convincente e totalmente autenticado em questão de semanas.
Avance rumo ao DMARC reject antes que um incidente force o cronograma. Ter a aplicação em vigor antes de um vazamento significa uma preocupação a menos quando o tráfego forjado começar a testar a reputação do seu domínio após o incidente.
Adote autenticação resistente a phishing em tudo que sua organização puder. Senhas vazadas em massa já são uma certeza neste momento da indústria; a resposta que realmente funciona é eliminar por completo o valor da senha.
Monitore padrões de sequestro de conta, não apenas falhas de autenticação. Um aumento na taxa de aprovação do DMARC combinado com comportamento de envio incomum vindo de uma fonte conhecida e confiável costuma ser o único sinal visível de que uma conta real foi sequestrada.
A Conclusão
O vazamento da KDDI e o aumento de phishing que se seguiu são um lembrete de que a aplicação do DMARC e a segurança de contas resolvem problemas diferentes que, por acaso, ficam bem próximos um do outro. Uma senha roubada transforma uma caixa de entrada legítima em uma arma de phishing totalmente autenticada que o DMARC deixará passar sempre. A resposta correta não é abandonar a aplicação do DMARC porque ela não consegue ver essa ameaça. É continuar reforçando-a para as ameaças que ela consegue impedir, para que, quando um vazamento como esse inevitavelmente ocorrer em algum ponto da sua cadeia de fornecedores, o tráfego forjado que o acompanha não seja mais um problema para você enfrentar.
A Excello Mail mantém seu domínio com aplicação total do DMARC e oferece visibilidade clara de cada fonte que afirma enviar em seu nome, para que, quando ocorrer um vazamento em outro ponto do ecossistema, seu domínio não seja um alvo fácil para o tráfego forjado que se segue. Cadastre-se gratuitamente na Excello Mail e leve seu domínio ao reject antes de precisar dele.