Para quem é este texto: pessoas responsáveis pela proteção de um serviço ou de sistemas internos, e qualquer pessoa que tenha visto esses nomes nas notícias e queira os fatos corretos. Este artigo compara as próprias divulgações oficiais de cada organização como fontes primárias e não contém técnicas de ataque.
Primeiro: você foi afetado?
Se você chegou aqui depois de ver um desses nomes nas notícias, a pergunta é se você está no escopo e o que fazer a respeito. Esta seção responde a isso; o restante do artigo é para quem defende um sistema. Os números de escopo são de cada organização; as ações são o que um cliente ou funcionário pode fazer hoje.
- KDDI (plataforma de e-mail vendida a provedores)
- Quem: qualquer pessoa cuja caixa de e-mail funcionava em um provedor afetado (seu provedor entrará em contato). Hoje: as senhas foram redefinidas à força pelos provedores, então o trabalho real é alterar qualquer outro serviço em que você tenha reutilizado essa senha. O Ministério das Comunicações do Japão afirmou que o conteúdo das caixas de e-mail de cerca de 7,62 milhões de usuários poderia ter sido lido; por isso, trate como expostos os avisos de senha e os códigos de uso único que ainda estejam nessa caixa, e gere novos.
- Aflac Life Insurance Japan
- Quem: segurados e agências. Hoje: os dados de transferência bancária estão no escopo de cerca de 220.000 pessoas. Verifique a atividade da sua conta e entre em contato com o banco e com a empresa se algo parecer errado. Para qualquer mensagem que alegue vir da empresa, acesse o site oficial por conta própria, em vez de usar um link ou número que esteja na mensagem.
- Agência Digital (GSS)
- Quem: servidores públicos e os terceirizados que trabalharam nesses sistemas; a agência afirma que não estão incluídos dados gerais do público. Hoje: espere tentativas de falsificação de identidade baseadas em nomes, endereços e números de telefone (veja o artigo sobre VPN).
- Sakura Internet
- Quem: qualquer pessoa com cadastro de membro, cliente de hospedagem ou não. Hoje: altere qualquer senha reutilizada, e se você ainda usa a senha inicial emitida no cadastro, troque-a hoje (passos no artigo sobre violação de provedor de hospedagem).
Se você é quem defende um serviço, o restante é mais importante: os quatro pontos de entrada não têm nada em comum, mas os planos de correção apontam para a mesma coisa.
Os quatro casos lado a lado (conforme as divulgações de cada organização)
| Organização (divulgada) | Escopo (conforme divulgado) | Forma de entrada (conforme divulgado) | Do início à descoberta |
|---|---|---|---|
| KDDI (a partir de 23 jun) | Exposição confirmada: endereços de e-mail de 12.231.954 pessoas, senhas de 7.616.173 | Vulnerabilidade em software de terceiros incorporado ao sistema — desconhecida pelo fornecedor quando foi encontrada | Início em 16 mai → confirmado em 17 jun (cerca de um mês) |
| Aflac Life Insurance Japan (a partir de 30 jun) | Cerca de 4,4 milhões de clientes (cerca de 220.000 com dados bancários), cerca de 40.000 agências | Controles insuficientes sobre os métodos de acesso e de consulta de dados em "Online Consultation" e "Yorisou Net" | Primeiro vazamento em 10 jun → encontrado em 25 jun (15 dias) |
| Agência Digital (11 set) | Cerca de 246.000 registros de servidores e outras pessoas possivelmente expostos | Vulnerabilidade em appliance de VPN (já conhecida, segundo o ministro; CVSS "Médio" segundo o Q&A da agência) | O início não consta no comunicado; reportagens apontam acesso em massa a partir de fim de maio → detectado em 25 jun |
| Sakura Internet (a partir de 17 ago) | 1.360.563 contas de membros possivelmente no escopo, 951 contas de hospedagem | Omitido para evitar a criação de ataques imitadores | Sistema de vendas: abr 2023 – mar 2026 → detectado em 9 ago 2026 por meio de outra anomalia (cerca de três anos) |
Não leia esta tabela como um ranking de quem foi pior
Os números desta tabela não têm o mesmo grau de certeza. KDDI e Aflac relatam pessoas cujos dados tiveram exposição confirmada; a Agência Digital relata dados possivelmente expostos; a Sakura Internet informa o total possivelmente no escopo. Os sistemas são diferentes, e também o tipo de dado que armazenavam.
Ordenar por quantidade de pessoas não significa nada, e este site não faz isso. O que vale a pena comparar é o que cada organização disse ter aprendido: seu plano de correção.
O que cada organização divulgou
- O que
- Acesso não autorizado a uma plataforma de e-mail que a KDDI desenvolveu para provedores (gerenciamento de contas, envio e recebimento, webmail e armazenamento de e-mails em um único sistema). A KDDI afirma que seus próprios serviços de e-mail au e relacionados rodam em equipamentos separados e não foram afetados
- Causa
- "Exploração de uma vulnerabilidade em software de terceiros instalado como parte deste sistema". Quando foi confirmada, em 17 de junho, tratava-se de "uma vulnerabilidade que o fornecedor do software desconhecia"
- Escopo
- O primeiro aviso (23 de junho) indicava um possível máximo de 14,22 milhões. O relatório de 6 de julho (corrigido em 21 de julho) confirmou exposição de endereços de e-mail de 12.231.954 pessoas, incluindo senhas de 7.616.173
- Ação regulatória
- Em 29 de julho de 2026, o Ministério de Assuntos Internos e Comunicações emitiu orientação sobre a proteção do sigilo das comunicações em relação a este incidente. Seu comunicado afirma que "constatou-se que o conteúdo das caixas de e-mail de aproximadamente 7,62 milhões de usuários estava em estado que permitia sua visualização"
- Resposta
- Alterações de senha coordenadas com os provedores, incluindo redefinições forçadas pelos provedores em contas pouco usadas. EDR implantado em todos os servidores que controlam a comunicação externa até 21 de junho. Daqui em diante, migração para padrões de comunicação mais seguros
- O que
- Acesso não autorizado a "Online Consultation", usada por agentes para elaboração remota de apólices e propostas, e ao serviço web para segurados "Aflac Yorisou Net". A Aflac afirma ter confirmado que não houve vazamento semelhante em seus outros sistemas
- Causa (resultados de 31 de julho)
- "Os controles contra os métodos de acesso e de consulta de dados usados neste ataque foram insuficientes". Existiam funções de detecção e bloqueio, mas "como o formato do acesso era o mesmo do uso normal, não pôde ser detectado imediatamente como acesso não autorizado". Além disso, "faltavam funções para monitorar e controlar grandes volumes de consultas de dados em curto período"
- Medidas anteriores
- Revisões de segurança na fase de projeto e testes de penetração antes do lançamento haviam sido realizados, mas "o risco dos métodos usados neste ataque não havia sido previsto"
- Escopo
- Cerca de 4,4 milhões de clientes (cerca de 220.000 incluindo dados bancários para pagamento de prêmios) e cerca de 40.000 agências. Número My Number, dados de cartão e endereços de e-mail não foram incluídos
- O que
- Acesso não autorizado a um ambiente de trabalho compartilhado por servidores de vários ministérios e agências. A agência afirma ter confirmado que não foram incluídos dados pessoais do público em geral
- Causa
- "Um terceiro explorou uma vulnerabilidade em um dispositivo de conexão de rede (VPN) para entrar no sistema". O produto e o identificador da vulnerabilidade não foram divulgados
- Acompanhamento (resumo da entrevista coletiva)
- No resumo da entrevista coletiva de 11 de setembro publicado pela agência, o ministro da área digital disse "tínhamos conhecimento da vulnerabilidade; era uma já conhecida", que ela "não foi classificada como de alta urgência" e estava sendo tratada conforme sua classificação de gravidade, e que "há trabalho para aplicar correções em ordem, e fomos invadidos durante esse processo"; a correção já foi aplicada. O CVSS "Médio" consta no Q&A da agência (atualizado em 12 de setembro). O início de acesso em massa no fim de maio vem de reportagens e não aparece no resumo, no comunicado nem no Q&A
- Detecção
- Em 25 de junho, foi detectado acesso em massa a arquivos em servidores usando a conta de um operador de manutenção. Tratado em detalhes em Appliances de VPN são a principal porta de entrada do ransomware
- O que
- Acesso não autorizado ao sistema de gestão de vendas, que armazena registros de contratos, e a parte do ambiente de hospedagem compartilhada. A empresa afirma que não há motivos claros que liguem os dois
- Duração
- O acesso não autorizado ao sistema de gestão de vendas ocorreu "entre abril de 2023 e março de 2026". A detecção ocorreu em 9 de agosto de 2026, a partir de uma anomalia em um servidor de manutenção de hospedagem
- Causa
- O caminho da invasão é omitido para evitar a criação de ataques imitadores. A empresa também divulgou que algumas senhas iniciais não estavam com hash. O que os clientes devem fazer está em o que fazer quando seu provedor de hospedagem é invadido
A correção que os quatro tiveram em comum: detecção mais forte
Comparados pela forma como os atacantes entraram, os quatro casos não têm nada em comum. Mas, ao observar os planos de correção que cada organização redigiu para si mesma, as mesmas palavras aparecem repetidamente.
As medidas de detecção que cada uma citou
- KDDI: para reforçar a detecção de acessos não autorizados, EDR em todos os servidores que controlam a comunicação externa (concluído em 21 de junho)
- Aflac: monitoramento e controle mais rigorosos de acessos em massa em aplicações e dispositivos de segurança
- Sakura Internet: monitoramento e detecção ampliados para detecção precoce, e revisão do escopo, da retenção e da análise de logs de segurança
A Agência Digital foi o caso em que a detecção funcionou
- O que deu o alerta foi o acesso em massa a arquivos usando a conta de um operador de manutenção
- A invasão não foi evitada, mas a anomalia de volume permitiu à agência delimitar o alcance, suspender a conta e cortar a comunicação
- Sua correção — "revisão da gestão de vulnerabilidades" e "melhoria das conexões externas" — visa evitar a invasão
Uso legítimo
Login → consulta da própria apólice → visualização de alguns registros
Um ataque com forma de uso legítimo
Login → consulta → visualização (idênticos até aqui)
Volume
Alguns registros por pessoa, ou dezenas de milhares?
Velocidade
Ritmo humano ou ritmo de máquina?
Período
Existem logs que remontam tempo suficiente?
O que fazer hoje na sua própria organização
Coloque um limite de volume, e um alerta, em qualquer operação que retorne dados
Uma das causas apontadas pela Aflac foi que "faltavam funções para monitorar e controlar grandes volumes de consultas de dados em curto período". Dê a cada API ou tela que retorne dados de clientes um limite de registros por requisição e por hora, além de um alerta para uma pessoa quando o uso se aproximar do limite. Mesmo com um login válido, extrair dezenas de milhares de registros em pouco tempo não se parece com a forma como as pessoas usam um sistema. Como decidir o que contar, por quem e até qual número está em limitação de taxa e controle de abuso.
Há três camadas onde você pode medir.
Na aplicação: conte registros por conta nos caminhos de busca, listagem e exportação; esta é a única camada que sabe quem extraiu quanto.
Na frente dela: limit_req do nginx ou uma regra de limitação de taxa em CDN, limitando requisições por segundo ou minuto por endpoint.
Na plataforma: o centro de alertas do Google Workspace e o log de auditoria e as políticas de alerta do Microsoft 365 podem notificar sobre downloads e exportações em massa (o que está disponível depende do seu plano).
Comece com um endpoint: aquele que retorna o maior número de registros. Defina para ele um limite horário por conta e um alerta em 80% desse limite. Um único endpoint que de fato acione uma pessoa vale mais do que um projeto completo que ainda está sendo escrito.
Verifique, em cada consulta, se esta pessoa pode ver este registro
A primeira medida na correção da Aflac é uma "autenticação no acesso e autorização na consulta de dados" mais forte. Se alguém pode fazer login (autenticação) e se pode ver um registro específico (autorização) são perguntas separadas, e se a segunda não for verificada registro por registro, um usuário devidamente autenticado pode consultar dados de outras pessoas. A diferença é explicada em autenticação versus autorização, e a falha clássica em IDOR.
Mantenha logs pelo tempo em que você precisaria olhar para trás
No caso da Sakura Internet, o acesso ao sistema de gestão de vendas começou cerca de três anos antes de vir à tona. Se os logs desse período já não existirem quando você perceber o problema, você não conseguirá dizer nem o que aconteceu nem o que não aconteceu. A Sakura também incluiu na lista uma revisão do escopo e da retenção dos logs. Se o armazenamento permite apenas algumas semanas, uma divisão realista é manter por muito mais tempo pelo menos os logs de autenticação e de consulta de dados.
Um número de referência: o padrão de cartões de pagamento (PCI DSS) exige retenção de 12 meses, com os três meses mais recentes imediatamente disponíveis. Mesmo fora de pagamentos, isso é um ponto de partida útil.
Mantenha ao menos três tipos: autenticação (sucessos e falhas), consultas e exportações de dados, e ações administrativas. Os logs de acesso do servidor web, sozinhos, não dirão quem levou quantos registros.
Presuma que existam vulnerabilidades desconhecidas e planeje perceber a invasão depois da entrada
A falha explorada no caso da KDDI era uma que o próprio fornecedor não conhecia quando foi encontrada. Não havia correção na época. Como algumas invasões não podem ser evitadas mesmo com correções perfeitas, a capacidade de perceber atividade suspeita e tráfego de saída nos servidores — o EDR que a KDDI implantou em todos os servidores é um exemplo — é o que resta.
E ainda mantenha corrigidos os dispositivos expostos à internet
Nada disso significa que evitar a invasão seja menos importante. O caso da Agência Digital entrou por meio de uma vulnerabilidade em appliance de VPN. Não deixar vulnerabilidades conhecidas abertas continua sendo a defesa mais custo-efetiva que existe. Para appliances de VPN, veja Appliances de VPN são a principal porta de entrada do ransomware; para ordenar o trabalho, veja priorização com CVSS, EPSS e KEV.
Visão deste site: um teste de penetração só encontra os métodos que alguém imaginou
Na leitura deste site, a frase mais importante dos resultados da Aflac não é a causa em si, mas esta: "Realizamos revisões de segurança no projeto do sistema e testes de penetração antes do lançamento, mas não havíamos previsto o risco dos métodos usados neste ataque." Não é que as medidas não tenham sido feitas; elas foram feitas, e o ataque usou um método que ninguém havia previsto. Isso pode acontecer com qualquer organização.
Verificações antes do lançamento só podem testar os métodos que o testador imaginou. Por isso, o que resta é perceber, em produção, volume, velocidade e horário incomuns. Três das quatro organizações citaram detecção em seus planos, o que se pode ler como sinal de que cada uma esbarrou no mesmo limite em seu próprio incidente.
Revisões e testes reduzem as formas de entrada; a detecção reduz o tempo até que uma invasão seja percebida. Eles cumprem funções diferentes, e nenhum substitui o outro.
Três coisas que todo indivíduo deve fazer, qualquer que seja o caso
O risco real para você é menos o vazamento em si do que as mensagens de acompanhamento que ele provoca
(1) Não reutilize senhas. As senhas foram confirmadas como expostas no caso da KDDI, e uma senha reutilizada permite que atacantes entrem também em suas outras contas (um gerenciador de senhas é a solução prática).
(2) Não use links ou números de telefone de mensagens que invoquem o nome da organização. A Agência Digital e a Sakura Internet alertaram explicitamente sobre mensagens que se passam por elas, e a Aflac pede que quem receber um contato suspeito ligue para a linha oficial da empresa. Confirme acessando o site oficial por conta própria.
(3) Se dados bancários estiverem envolvidos, verifique a atividade da sua conta. A Aflac afirma que está trabalhando com os bancos relevantes para os segurados cujos dados de conta foram expostos. Se algo parecer errado, entre em contato com o seu banco e com a organização.
Fontes
Os fatos acima vêm das divulgações oficiais de cada organização. Não há especulação sobre nomes de produtos ou caminhos de invasão não publicados.
- KDDI Corporation, aviso sobre acesso não autorizado à plataforma de e-mail para provedores (23 de junho de 2026, em japonês) — newsroom.kddi.com
- KDDI Corporation, pedido de desculpas e relatório sobre o acesso não autorizado à plataforma de e-mail para provedores (6 de julho de 2026, atualizado em 21 de julho; em japonês) — newsroom.kddi.com
- Aflac Life Insurance Japan, segundo relatório sobre o acesso não autorizado e o vazamento de informações (13 de julho de 2026, em japonês) — aflac.co.jp
- Aflac Life Insurance Japan, resultados da investigação e medidas de correção (31 de julho de 2026, em japonês) — aflac.co.jp
- Ministério de Assuntos Internos e Comunicações (Japão), orientação à KDDI sobre a proteção do sigilo das comunicações (29 de julho de 2026, em japonês) — soumu.go.jp
- Agência Digital (Japão), sobre o possível vazamento de informações pessoais por meio de acesso não autorizado ao Government Solution Service (11 de setembro de 2026, em japonês) — digital.go.jp
- Agência Digital (Japão), resumo da entrevista coletiva do ministro da área digital de 11 de setembro de 2026 (em japonês) — digital.go.jp
- Agência Digital (Japão), Q&A sobre o possível vazamento de informações pessoais por meio de acesso não autorizado ao Government Solution Service (atualizado em 12 de setembro de 2026, em japonês) — digital.go.jp
- Nikkei xTECH (11 de setembro de 2026, em japonês) — a gravidade da vulnerabilidade e o início do acesso em massa vêm dessa reportagem — xtech.nikkei.com
- Sakura Internet Inc., resultados da investigação e medidas de correção (terceiro relatório, 10 de setembro de 2026, em japonês) — sakura.ad.jp
Registro de atualizações
2026-10-11: Correção. A classificação CVSS "Médio" da vulnerabilidade explorada não é apenas reportada: o Q&A da agência (atualizado em 12 de setembro) afirma que ela foi classificada como "Médio" (nível CVSS Médio). A atribuição agora é ao Q&A da agência. O início do acesso em massa no fim de maio continua atribuído a reportagens.
2026-09-19: Os pontos da Agência Digital foram confirmados em relação ao resumo publicado da entrevista coletiva; "já conhecida, e sendo corrigida em ordem de gravidade avaliada quando a invasão ocorreu" agora é citada do resumo oficial, e não de reportagens. CVSS "Médio" e "fim de maio" continuam atribuídos a reportagens. A Sakura Internet não publicou nada novo desde o terceiro relatório de 10 de setembro (verificado em 19 de setembro).
2026-09-12: Duas inclusões. (1) No caso da KDDI, o Ministério de Assuntos Internos e Comunicações emitiu, em 29 de julho de 2026, orientação sobre o sigilo das comunicações (o conteúdo das caixas de e-mail de cerca de 7,62 milhões de usuários poderia ter sido visualizado). (2) No caso da Agência Digital, relata-se que a vulnerabilidade explorada já era conhecida e foi classificada como "Médio" — atribuído a reportagens, já que não consta no comunicado da agência. A Sakura Internet não publicou nada novo desde o terceiro relatório de 10 de setembro (seu FAQ também ainda mostra 10 de setembro; verificado em 12 de setembro de 2026).
2026-09-11: Primeira versão, com base nas divulgações oficiais das quatro organizações.
Leia em seguida
- Grandes casos de 2026: Yellow Hat (até 1,8 milhão de pessoas)
- Grandes casos de 2026: Murauchi.com (7,7 milhões de registros)
- Grandes casos de 2026: EPARK Relax & Esthe (22 milhões de registros)
- Grandes casos, ago–set 2026: ShopServe (8,85 milhões de registros)
- Transformando isso em controles organizacionais: Seis prioridades extraídas das violações do Japão em 2026
- Invasão por agente de IA: A invasão ao Hugging Face (2026): um ataque de agente de IA autônomo
- A violação do Gyazo (setembro de 2026): o que vazou e o que os usuários devem fazer hoje
- Todos os incidentes de 2026 (Japão e mundo): uma linha do tempo de violações e ciberataques com classificações de impacto
- Outros incidentes no Japão, setembro–outubro de 2026: o aplicativo da Seicomart (cerca de 570.000 pessoas) / Yamato Transport e Sagawa Express (remetentes e destinatários de encomendas) / Abahouse (dados de pedidos e e-mails falsos de reembolso)
- A violação da Times Car (setembro de 2026): imagens de carteiras de motorista vazadas — o que os membros devem fazer
- Cada caso em detalhe: o caso da Agência Digital e a defesa de appliances de VPN / o caso da Sakura Internet e o que os clientes devem fazer
- Detecção e controle: limitação de taxa e controle de abuso / o que é EDR / indicadores de ataque (IoA)
- Projeto: autenticação versus autorização / o que é IDOR
- O padrão: uma leitura cruzada das divulgações de agosto de 2026 por forma de entrada