Para: pessoas que administram sistemas em empresas ou organizações que tratam dados pessoais no Japão, e a liderança a quem elas se reportam. Em outubro de 2026, órgãos do governo japonês e organizações de segurança nacional emitiram uma série de alertas sobre acesso não autorizado. Este guia transforma esses alertas em verificações a executar em seus próprios sistemas esta semana. Ele se baseia em documentos públicos do Escritório Nacional de Cibersegurança da Secretaria do Gabinete, da IPA (Information-technology Promotion Agency), da JPCERT/CC, da Comissão de Proteção de Informações Pessoais (PPC), da Agência de Serviços Financeiros (FSA) e da Agência Nacional de Polícia (NPA), todos em japonês. Técnicas de ataque não são abordadas.
Por que estes alertas saíram agora
Desde cerca de setembro de 2026, organizações no Japão divulgaram vazamentos de dados por acesso não autorizado, um após o outro. A IPA afirma que as divulgações vieram de uma ampla gama de empresas, incluindo instituições financeiras e provedores de telecomunicações, e que sistemas por trás de serviços online e de contas que tratam grandes volumes de dados pessoais foram invadidos e dados, incluindo informações pessoais, foram roubados.
Os documentos a seguir foram emitidos entre 7 e 9 de outubro.
| Data | Emitido por | Documento | Conteúdo principal |
|---|---|---|---|
| 7 out. (vídeo explicativo adicionado em 9 out.) | Comissão de Proteção de Informações Pessoais | Responding to large-scale data leaks (warning), e a revisão de "WARNING: preventing personal data leaks caused by unauthorized access" | Uma prévia dos exemplos revisados de salvaguardas técnicas (a serem finalizados em abril de 2027); exclusão de dados pessoais que não são mais necessários; nove tipos de caso, incluindo APIs sendo abusadas |
| 8 out. (atualizado em 9 e 23 out.) | JPCERT/CC | Alerta sobre a recente série de incidentes de acesso não autorizado em organizações japonesas (JPCERT-AT-2026-0030) | Cinco padrões de ataque observados, contramedidas, indicadores para investigação (IOCs) |
| 9 out. | Secretaria do Gabinete, Escritório Nacional de Cibersegurança | Responding to data leaks caused by unauthorized access | Três pilares: sistemas web, cadeia de suprimentos, gestão de dados |
| 9 out. | IPA | Measures to take promptly in light of data leaks caused by unauthorized access | Verificações a executar agora e medidas a tomar (atualizado conforme necessário) |
| 9 out. | Agência de Serviços Financeiros | Strengthening cybersecurity and handling account applications in the current situation | Solicitações às instituições financeiras para revisar controles e reforçar verificações de identidade |
A JPCERT/CC afirma que, embora vários produtos e serviços tenham sido afetados, o compartilhamento de informações técnicas tem sido insuficiente e o que se sabe é limitado. Nenhum dos documentos nomeia incidentes individuais. Incidentes japoneses de acesso não autorizado que este site cobriu em setembro e outubro incluem Times Car, Yamato Transport e Sagawa Express, o aplicativo Seicomart, o aplicativo Yakiniku King, um terceirizado da Daiwa Securities e Lawson ID. O que cada empresa divulgou está nos artigos vinculados.
Verificações desta semana: as três áreas da IPA
A IPA lista três áreas em "verificações a executar prontamente". A seguir, elas são divididas em tarefas concretas. Execute todas apenas em sistemas que você administra.
Liste suas aplicações expostas à internet e revise seus logs, primeiro o último mês e depois três meses
Liste cada aplicação e serviço que você desenvolveu ou opera e que pode ser acessado pela internet: sites de membros, as APIs que seus aplicativos móveis chamam, formulários de contato e telas administrativas. A JPCERT/CC afirma que sistemas não destinados ao público geral, como ferramentas de BI e sistemas administrativos para funcionários, também foram atingidos, então inclua os voltados para uso interno.
Para cada aplicação, verifique os logs em busca de algo anormal. Os exemplos da IPA são um grande volume de erros e padrões diferentes do normal. Na prática, procure picos de requisições a telas administrativas ou APIs no log de acesso do servidor web, o mesmo erro se repetindo no log da aplicação e grandes recuperações de dados à noite ou nos fins de semana. Comece pelo último mês e depois amplie para três meses.
A IPA também pede que você saiba quem pode investigar e como, já que talvez seja necessário investigar mais de uma vez. Por fim, verifique os componentes de cada aplicação e serviço (por exemplo, sistema operacional, middleware, bibliotecas e CMS) em busca de correções de segurança não aplicadas e aplique-as o quanto antes.
Para APIs, o documento WARNING que a PPC revisou em 7 de outubro acrescenta o caso 9, "APIs sendo abusadas" (a primeira edição, de 11 de dezembro de 2024, tinha os casos 1 a 8). As causas listadas são: algumas APIs não constavam na lista do que era gerenciado; a alteração de um parâmetro, como um ID de membro, permitiu que um usuário autenticado obtivesse dados de outros usuários; as respostas continham informações desnecessárias e os IDs de membros eram sequenciais; e não havia limite de volume de requisições (rate limiting). Seus exemplos de contramedidas:
- Faça um inventário das suas APIs regularmente
- Verifique a autorização (se este usuário tem direito de acessar este dado) em cada requisição, e não apenas a autenticação (quem é o usuário)
- Não inclua informações desnecessárias nas respostas e use valores aleatórios, como UUIDs, para IDs de membros e números de registro
- Implemente limitação de taxa que detecte e bloqueie grandes volumes de requisições em pouco tempo
Em serviços de nuvem, VPN e outros serviços externos, verifique falhas de login, endereços de origem e contas desconhecidas
Liste os serviços de nuvem, VPNs e SaaS que você usa. A IPA pede que você inclua os serviços que departamentos individuais contrataram. Pergunte às áreas financeira e comercial se elas têm contratos que a equipe de TI desconhece.
Nos logs de cada serviço, procure muitas falhas de login, endereços IP de origem desconhecidos e logins em horários incomuns. A IPA observa que os períodos de retenção variam conforme o serviço e que o fornecedor e o cliente podem ver logs diferentes. Se o console administrativo mostrar apenas um período curto, pergunte ao fornecedor.
Para contas, verifique se foram criadas contas que você não reconhece e se alguma que você desativou ou excluiu foi reativada. A IPA afirma que revisar o log de auditoria das operações de contas ajuda. Esta é a versão organizacional de verificar se alguém acessou a sua conta.
O caso 8 do mesmo WARNING é um vazamento de um serviço de nuvem usado pela empresa. O sistema de negócios de um fornecedor de nuvem foi acessado sem autorização e dados pessoais pertencentes a muitas empresas clientes foram criptografados. Uma das causas listadas pela PPC é que os clientes acreditavam que usar um serviço de nuvem, que não era uma terceirização, não caracterizava a entrega de dados pessoais a terceiros, por isso não supervisionaram como eles eram tratados. Como contramedida, a PPC indica verificar, pelos termos de serviço e pelos documentos de avaliação de segurança do serviço, se a nuvem possui medidas de segurança adequadas antes de escolhê-la.
Faça o inventário dos dados pessoais que você mantém e exclua o que não precisa
A IPA observa que dados roubados estão sendo usados para extorsão e revenda, e pede que as organizações mantenham apenas os dados de que precisam e saibam exatamente o que possuem. Para cada banco de dados e repositório de arquivos, anote quais dados ele contém, quantos registros, por que e até quando. O que você não consegue explicar é candidato à exclusão.
O alerta da PPC da mesma semana lembra às empresas que o Artigo 22 da lei japonesa de informações pessoais pede que elas façam esforços para excluir dados pessoais sem demora quando não forem mais necessários, e afirma que já viu casos agravados porque isso não foi feito. Quando uma lei fixa um período de retenção, anote também essa base e esse período.
A IPA também afirma que órgãos públicos e fornecedores de segurança podem publicar informações úteis para investigação, como endereços IP suspeitos, e pede que as organizações intensifiquem a coleta de informações por enquanto.
Mesmo que as verificações não encontrem nada, continue
A IPA pede que as organizações considerem medidas adicionais mesmo quando nenhuma anomalia é encontrada. Para aplicações expostas à internet e serviços externos: revisar o que está exposto, reforçar a autenticação, como a autenticação multifator e as senhas, revisar os privilégios das contas, revisar como as integrações de API são gerenciadas e revisar o que é registrado e por quanto tempo. Para os dados: reconsiderar se devem ser mantidos, reconsiderar onde são armazenados, revisar os registros de acesso e sua retenção, e criptografá-los.
Os três pilares do Escritório Nacional de Cibersegurança, como verificações concretas
O comunicado do Escritório Nacional de Cibersegurança cita a exploração de vulnerabilidades em sistemas web, o comprometimento pela cadeia de suprimentos e a gestão fraca de dados como pano de fundo, e define medidas-chave para cada um. A coluna da direita reescreve os itens do comunicado como perguntas que você pode verificar na sua organização.
| Pilar | Itens principais do comunicado | O que verificar |
|---|---|---|
| 1. Gestão adequada de sistemas web | Aplicar correções de segurança prontamente (inclusive em servidores internos não expostos à internet), deixar de usar produtos sem suporte, desativar sistemas e funções não utilizados, realizar avaliações de vulnerabilidade regulares, desativar portas e serviços desnecessários | Você consegue listar cada servidor público e interno com a data de fim de suporte e a última atualização? |
| 1. (contas e autenticação) | Autenticação multifator, proibir senhas fáceis de adivinhar, manter as contas administrativas no mínimo, desativar prontamente contas de desligados, transferidos e contas não utilizadas | Você consegue indicar o responsável por cada conta administrativa? Alguma conta de ex-funcionário ainda está ativa? |
| 1. (resiliência) | Coletar e manter logs, monitorar tráfego suspeito e acessos em massa, detectar tentativas anormais de autenticação vindas de fora, preparar a resposta a incidentes | Quando ocorrem recuperações em massa ou falhas repetidas de login, quem é notificado? |
| 2. Cadeia de suprimentos, incluindo terceirizados | Verificar as políticas, a estrutura e a divisão de responsabilidades dos terceirizados, conhecer também a situação dos subcontratados, incluir em contratos o controle de acesso, o registro de logs e os deveres de comunicação de violações, dar aos terceirizados apenas os dados de que precisam, garantir a exclusão ao fim do trabalho | Para cada terceirizado, você consegue reunir em uma página os dados pessoais compartilhados, as contas concedidas e o contato de incidentes? |
| 3. Gestão adequada de dados | Saber onde estão as informações e quem as gerencia, definir finalidade e retenção, fazer inventário regularmente, separar permissões de leitura e de escrita, criptografar dados armazenados e tráfego, nunca armazenar credenciais em texto simples, verificar a exposição na nuvem e as configurações de acesso, registrar o acesso a dados pessoais e monitorar recuperações em massa | Você consegue descobrir depois quem acessou dados pessoais e quando? |
Sobre a cadeia de suprimentos, o comunicado pede que as organizações ajam com base no entendimento de que elas "gerenciam em conjunto com os terceirizados", porque atacantes às vezes usam um terceirizado menos protegido como ponto de apoio e depois ampliam o acesso à empresa-alvo. Contas de terceirizados e de manutenção também são tratadas em a linha de base de segurança para organizações.
Escritório Nacional de Cibersegurança: o que proteger
Sistemas web / cadeia de suprimentos, incluindo terceirizados / gestão de dados
IPA: o que verificar esta semana
Logs de aplicações expostas / contas de serviços externos / os dados que você mantém
JPCERT/CC: o que está acontecendo
Cinco padrões de ataque / contramedidas / pistas para investigação (IOCs, atualizados)
A prévia da PPC sobre as salvaguardas técnicas revisadas
Em um anexo ao seu alerta de 7 de outubro, a PPC apresentou o conteúdo revisado de "10-6 Salvaguardas técnicas", no anexo de suas diretrizes gerais sob a lei japonesa de informações pessoais. Ela afirma que a revisão deve ser finalizada em abril (abril de 2027), mas que está divulgando antecipadamente o conteúdo planejado porque, diante dos acontecimentos recentes, ele tende a ser mais útil como referência.
O que ela lista são "exemplos de métodos". A PPC diz que esses são literalmente exemplos, e que nem todos precisam estar implementados para evitar uma violação. Também afirma que os métodos específicos devem corresponder ao risco, incluindo o dano às pessoas em caso de vazamento e a natureza e o volume dos dados pessoais tratados. Empresas que mantêm grandes volumes de dados pessoais devem comparar seus próprios controles com ele item por item. O anexo também traz exemplos separados para pequenas e médias empresas.
| Área | Exemplos no anexo (resumidos) | O que verificar |
|---|---|---|
| (1) Controle de acesso | Minimizar o acesso a sistemas que tratam dados pessoais (por exemplo, somente a partir de endereços IP específicos aprovados previamente). Manter no mínimo quais funcionários têm contas privilegiadas, quais dispositivos usam e quando. Revisar os direitos de acesso, por exemplo por meio de auditorias regulares. Avaliar cada solicitação de acesso com base em contexto, como localização de origem, horário e estado de segurança do dispositivo, e decidir com base no risco | Telas administrativas ou bancos de dados podem ser acessados de qualquer lugar? Você consegue listar as contas privilegiadas e os dispositivos a partir dos quais são usadas? |
| (2) Identificação e autenticação | Usar autenticação multifator (incluindo métodos resistentes a phishing) para acesso de fora da rede da organização, acesso com direitos administrativos e acesso a dados pessoais importantes. Identificar e autenticar adequadamente também usuários que não são funcionários, por exemplo com autenticação multifator (igualmente) | Todo acesso remoto e todo login administrativo exige autenticação multifator, sem exceções? Ela é oferecida a membros e outros usuários? |
| (3) Prevenção de acesso não autorizado a partir de fora | Firewalls, software de segurança, aplicação de correções, prevenção de software não aprovado. Permitir acesso a dados pessoais apenas a partir de dispositivos aprovados pela organização e que atendam aos seus padrões de segurança | Os dispositivos que tocam dados pessoais são apenas os aprovados pela empresa? |
| (4) Prevenção de vazamentos pelo uso do sistema | Manter dados pessoais usados como dados de teste para verificações funcionais no mínimo (por exemplo, proibi-los ou substituir parte deles por outros dados). Ao excluir dados pessoais na nuvem, usar um método que dificulte a recuperação, como o método próprio do fornecedor ou crypto-erase | Há cópias de dados pessoais de produção em ambientes de teste? Está definido como os dados serão excluídos quando um serviço de nuvem for cancelado ou migrado? |
| (5) Detecção de acesso não autorizado | Manter logs de autenticação, acesso, operação e rede por um período definido, protegê-los contra vazamentos, adulteração e exclusão não autorizada, e analisá-los regularmente. Monitorar continuamente com IDS/IPS, EDR e similares. Limitar a propagação de danos interrompendo ou isolando sistemas que foram ou podem ter sido comprometidos e desativando contas | Você mantém logs em um lugar onde um atacante não consegue apagá-los? Quem pode decidir isolar um sistema e desativar contas? |
A retenção de logs na linha (5) também é o que sustenta a verificação "último mês, depois três meses" da IPA. Se a verificação desta semana mostrar que você não tem logs suficientes, a linha (5) oferece fundamento para corrigir isso.
Os cinco padrões que a JPCERT/CC observou
O alerta da JPCERT/CC descreve padrões de ataque, separados de ransomware, que levam a grandes vazamentos de dados e parecem estar aumentando em particular. Eles são resumidos aqui apenas o suficiente para indicar onde procurar.
| Padrão | Resumo da descrição da JPCERT/CC | Onde verificar |
|---|---|---|
| Caso A | Sondagem de vulnerabilidades conhecidas e tentativas de explorá-las, incluindo tentativas de obter arquivos de configuração ou de backup explorando equipamentos mal gerenciados | Nível de correção de servidores públicos; se arquivos de configuração ou backups estão em pastas públicas |
| Caso B | Requisições não autorizadas à API administrativa de uma aplicação, levando à alteração de dados. Os relatos incluem a identificação de APIs pela análise de aplicações públicas, ataques a APIs internas e uso indevido de chaves de API roubadas de outros sistemas | Se as APIs administrativas e internas exigem autenticação e controle de acesso; permissões e validade das chaves de API |
| Caso C | Exploração de uma vulnerabilidade de injeção de SQL no Metabase (CVE-2026-72898) por meio de requisições de API não autorizadas | Se você usa o Metabase, se ele está corrigido e se é acessível pela internet |
| Caso D (acrescentado em 9 out.) | Um arquivo WAR (uma aplicação Java empacotada) colocado em um servidor de aplicação acessível a partir de um servidor web público, com um arquivo dentro atuando como uma web shell simples (um programa malicioso que permite a pessoas externas executar comandos) | Se as funções de gerenciamento do servidor de aplicação são acessíveis pelo lado público; se cada aplicação implantada foi colocada por você |
| Caso E (acrescentado em 23 out.) | Tentativas de ataque que usam indevidamente plataformas de teste de penetração baseadas em IA; os nomes das plataformas constam no alerta da JPCERT/CC. Elas têm como alvo principalmente aplicações web expostas à internet, sondando e tentando explorar diversas vulnerabilidades, e também foram observados ataques que exploram equipamentos mal gerenciados (como a obtenção de arquivos de configuração ou de backup). Inclui tentativas contra servidores WSUS (servidores que distribuem atualizações do Windows dentro de uma organização) expostos à internet | Nível de correção de aplicações web públicas e o que está em pastas públicas; se um servidor WSUS é acessível pela internet |
O caso C é tratado em as violações por vulnerabilidade do Metabase e em a explicação sobre o CVE-2026-72898. Para arquivos de configuração e backups em local errado, veja você deixou um arquivo secreto em um diretório público?
Em 15 de outubro, a JPCERT/CC publicou os resultados da análise de servidores que podem ter sido usados nos ataques. Ela afirma que os atacantes usaram IA para varrer vulnerabilidades conhecidas e atacar por meio de APIs, e que havia indícios de que analisaram arquivos de distribuição de aplicativos Android para identificar APIs e sondar essas APIs em busca de falhas como SSRF. Isso corresponde ao item "identificação de APIs pela análise de aplicações públicas" do caso B. A JPCERT/CC observa que segredos e a lógica de autenticação de API embutidos em um aplicativo podem ser extraídos mesmo de código compilado (aplicativos Flutter, por exemplo), e recomenda o seguinte.
- Não incorporar chaves privadas ou credenciais de longa duração usadas para autenticação de API no aplicativo
- Não confiar apenas em assinatura ou ofuscação dentro do aplicativo; autenticar usuários no servidor e autorizar cada operação pelo seu alvo e conteúdo
- Aplicar limites de taxa e monitorar requisições anormais, e presumir acesso a partir de clientes diferentes do aplicativo oficial
- Para APIs que buscam URLs externas, restringir os destinos e também verificar para onde os redirecionamentos levam
Para acesso por meio de APIs, a JPCERT/CC recomenda limites de taxa por função em login, redefinição de senha, envio de SMS e busca; controle de acesso, inclusive em APIs não públicas; permissões mínimas e validade adequada para usuários e tokens de API; e a capacidade de revogar rapidamente tokens desnecessários ou possivelmente vazados. Suas medidas gerais incluem restringir regiões de origem para serviços usados apenas em certas áreas, atualizar versões afetadas por vulnerabilidades conhecidas, revisar como limitar o movimento lateral caso um servidor web seja comprometido, verificar a detecção e a primeira resposta, retirar da internet funções administrativas desnecessárias, excluir dados além do período de retenção ou da finalidade, e preparar-se antecipadamente para alertar clientes sobre danos posteriores caso haja vazamento.
O que empresas de segurança japonesas descobriram (7 a 19 de outubro)
Empresas de segurança japonesas também publicaram constatações dos casos que atenderam e da análise de servidores de atacantes. Uma delas examinou os 81 vazamentos de sistemas web que organizações no Japão divulgaram desde julho de 2026 (até 6 de outubro) e constatou que 65 deles (80,2%) não puderam ser classificados por causa, porque os comunicados não explicavam o suficiente. Os métodos observados nos casos atendidos incluem APIs que retornam mais dados do que o necessário, ausência de verificações de autorização no servidor, funções exclusivas de membros acessíveis a usuários anônimos e chaves de API extraídas de aplicativos de smartphone.
Outra empresa descreve atacantes que trocam de endereço IP logo antes de atingir o limiar de bloqueio de um WAF, usando várias centenas de endereços IP no total. Ela também afirma que versões não listadas em um CVE, e versões fora do suporte, podem ser afetadas pela mesma vulnerabilidade. Em 19 de outubro, afirmou ter confirmado que um sistema autônomo de teste de penetração baseado em IA estava em uso em um servidor de atacante. Em 23 de outubro, a JPCERT/CC também acrescentou ao seu alerta, como caso E, as tentativas de ataque que usam indevidamente plataformas de teste de penetração baseadas em IA.
Acrescente estas três verificações às anteriores.
- Confirme que telas administrativas e outras funções de gestão realmente estavam no escopo da sua avaliação de vulnerabilidades (funções não abertas ao público costumam ficar de fora)
- Não confie apenas em limites de requisições por IP ou em um WAF, e não adie correções por haver um WAF em uso
- Reduza os dados pessoais que você não precisa mais, inclusive informações inesperadas armazenadas em campos de notas de texto livre, e revogue as chaves de API de serviços encerrados
Para os indicadores (endereços IP, User-Agents), use a página atual da JPCERT/CC
O alerta da JPCERT/CC lista endereços IP de origem suspeitos e exemplos de User-Agents vistos nos ataques. A lista foi ampliada em 9 e 23 de outubro e pode mudar novamente, por isso este site não a copia. Consulte a lista atual em alerta da JPCERT/CC (JPCERT-AT-2026-0030, em japonês).
A JPCERT/CC pede que as organizações verifiquem se os endereços IP listados acessaram seus sistemas, para descobrir se já houve ataque. Use a lista como ponto de partida para pesquisar logs antigos, não como lista de bloqueio. O que foi acrescentado ao caso B em 23 de outubro:
- Um novo endereço IP de origem, com a data em que o ataque foi observado ou em que a infraestrutura de ataque é estimada como ativa (JST). A JPCERT/CC observa que tentativas de ataque também podem ter ocorrido fora dessas datas. O caso E tem sua própria lista separada de endereços IP
- Como exemplo de User-Agent, o mesmo User-Agent do aplicativo público. Isso significa que o User-Agent sozinho não permite distinguir o tráfego de ataque do aplicativo genuíno
- Exemplos de impressões digitais TLS. A JPCERT/CC escreve que o valor JA4 listado é o mesmo de clientes HTTP comuns em Python, por isso não identifica o atacante sozinho e deve ser combinado com outras pistas
- Além dos endereços listados, foi observado acesso por meio de nós de saída da rede Tor e de proxies residenciais (serviços de retransmissão que encaminham o tráfego por conexões de internet domésticas)
A JPCERT/CC afirma que esses podem ter sido usos legítimos no momento da investigação, portanto uma correspondência isolada não prova uma invasão. Siga o que aquela origem efetivamente fez nos seus logs.
Se você encontrar algo: siga esta ordem
A IPA pede que as organizações declarem prontamente um incidente de segurança quando encontrarem logs ou contas anormais. Esperar para ver o que acontece pode fazer os logs expirarem antes que alguém os examine.
Declare um incidente de segurança
Encaminhe a anomalia ao responsável no mesmo dia e decida tratá-la como incidente. Uma declaração pode ser retirada depois; um início tardio não pode ser antecipado.
Preserve logs e evidências
Os logs desaparecem quando o período de retenção termina. Antes de excluir ou sobrescrever qualquer coisa, copie os logs de servidores, os logs que você pode exportar dos consoles de serviços externos e os logs de auditoria das contas para um local separado. Pergunte a especialistas se devem preservar imagens de disco antes de reconstruir um servidor. A ordem dos passos está em "O que fazer primeiro se você encontrar algo" em como verificar se seu site ou servidor foi invadido.
Acione uma empresa especializada
Dada a possibilidade de vazamento de dados, a IPA recomenda fortemente contratar uma empresa especializada em segurança para uma investigação detalhada. A JPCERT/CC aceita solicitações de resposta a incidentes. Não decida sozinho até onde o atacante chegou ou o que foi levado.
Em 16 de outubro de 2026, a IPA abriu uma central especial de consultas sobre acesso não autorizado, para empresas e organizações que foram ou podem ter sido afetadas. Ela orienta sobre a possibilidade de danos e sobre medidas emergenciais, encaminha para uma lista de empresas que atuam em resposta a incidentes e indica outros locais para consulta ou denúncia (telefone 03-6759-5760, dias úteis das 9h30 às 17h30, exceto das 12h00 às 13h00, em japonês; também são aceitos e-mails). Se você não sabe a qual empresa recorrer, pode começar por ali.
Comunique à PPC e compartilhe informações
Se dados pessoais vazaram ou podem ter vazado, pode ser exigida uma comunicação à PPC e um aviso às pessoas afetadas. Os prazos e onde comunicar estão resumidos em como verificar se seu site ou servidor foi invadido. O Escritório Nacional de Cibersegurança pede que as organizações afetadas compartilhem prontamente informações técnicas com ele, com o ministério competente e com órgãos especializados, para evitar mais danos. A janela de notificação da IPA e as delegacias de crimes cibernéticos da polícia também estão disponíveis.
O que comunicar à liderança
O comunicado do Escritório Nacional de Cibersegurança afirma que os danos de ciberataques não são mais apenas um problema do departamento de TI, porque um vazamento pode levar à paralisação de negócios, ao tratamento de clientes e a outros riscos de gestão. Ele pede que a liderança trate a cibersegurança como questão de gestão e a fortaleça, incluindo o investimento e a equipe necessários. A IPA igualmente pede uma revisão urgente das medidas como questão de responsabilidade gerencial.
Ao reportar à liderança, limite-se a quatro pontos para que ela possa decidir.
- Resultados desta semana: para cada uma das três áreas, se você encontrou anomalias, não encontrou nenhuma ou não conseguiu verificar
- O que você não conseguiu verificar: períodos sem logs, serviços externos ou terceirizados que você não conseguiu mapear
- Decisões necessárias: o custo de uma retenção de logs mais longa, um acordo permanente com uma empresa especializada, solicitações aos terceirizados
- Preparo para clientes: o texto de comunicação e o ponto de contato em caso de vazamento (a JPCERT/CC recomenda preparar antecipadamente avisos contra danos posteriores)
Alguns setores também receberam solicitações de seus reguladores. A FSA pediu que as instituições financeiras revisem seus controles, incluindo a gestão de riscos de terceiros e a resposta a incidentes, e que atuem prontamente sobre quaisquer lacunas. Também pediu que verifiquem, na identificação online, se há algo não natural nas imagens de documentos de identidade e nas imagens faciais, e que migrem cedo para a leitura de chips IC, antes de 1º de abril de 2027, data em que o envio de imagens de documentos de identidade deixa de ser um método aceito.
A visão deste site: 'os logs não estavam lá' é um resultado, não uma verificação malsucedida
As verificações da IPA pressupõem que você consegue olhar um mês para trás e depois três meses. Na prática, as equipes costumam descobrir que os logs estavam configurados para expirar após 30 dias, ou que o console de um serviço externo mostra apenas duas semanas.
Nesse caso, não relate "nenhuma anomalia". O relato preciso é "nenhuma anomalia no último mês; períodos anteriores não puderam ser verificados". Registrar quais períodos e sistemas você não conseguiu verificar indica diretamente as próximas correções: retenção mais longa, envio dos logs para outro local, pedido ao fornecedor. A verificação desta semana serve tanto para descobrir até onde você consegue enxergar quanto para encontrar anomalias.
Mensagens para funcionários e clientes
A NPA, citando os vazamentos contínuos, pede às empresas que mantenham os equipamentos conectados à internet atualizados e usem senhas fortes, e pede às pessoas que não cliquem em links de e-mails de forma descuidada (podem ser e-mails falsos que se passam pela empresa que vazou dados), que não reutilizem senhas e que usem autenticação multifator. Após um incidente, mensagens falsas usando o nome da sua organização podem aumentar. Oriente funcionários e clientes a verificar qualquer contato pelo site oficial. Veja o que é phishing? para saber como identificá-los.
Fontes (oficiais, em japonês)
- Secretaria do Gabinete, Escritório Nacional de Cibersegurança: Responding to data leaks caused by unauthorized access (9 de outubro de 2026) — cyber.go.jp
- IPA: Measures to take promptly in light of data leaks caused by unauthorized access (9 de outubro de 2026, atualizado conforme necessário) — ipa.go.jp
- IPA: Opening of a special consultation desk for unauthorized access (16 de outubro de 2026, em japonês) — ipa.go.jp
- IPA: Special site on countering unauthorized access (16 de outubro de 2026, em japonês) — ipa.go.jp
- JPCERT/CC: Alert on the recent series of unauthorized access incidents at Japanese organizations (JPCERT-AT-2026-0030, publicado em 8 de outubro de 2026, atualizado em 23 de outubro) — jpcert.or.jp
- JPCERT/CC: Investigation of the attack techniques used in the series of unauthorized access cases (JPCERT/CC Eyes, 15 de outubro de 2026, em japonês) — blogs.jpcert.or.jp
- Comissão de Proteção de Informações Pessoais: Responding to large-scale data leaks (warning) (7 de outubro de 2026; vídeo explicativo adicionado em 9 de outubro) — página do comunicado / alerta e anexo (PDF) / comunicado à imprensa (PDF)
- Comissão de Proteção de Informações Pessoais: WARNING: preventing personal data leaks caused by unauthorized access (11 de dezembro de 2024, revisado em 7 de outubro de 2026) — ppc.go.jp
- Agência de Serviços Financeiros: Strengthening cybersecurity and handling account applications in the current situation (9 de outubro de 2026) — fsa.go.jp
- Agência Nacional de Polícia: Cyber Police Agency Letter 2026 Vol.19 (outubro de 2026) — npa.go.jp
- JPCERT/CC: solicitação de resposta a incidentes — jpcert.or.jp
- IPA: notificação de vírus de computador e acesso não autorizado — ipa.go.jp
Análises de empresas japonesas de segurança (não são documentos oficiais, em japonês):
- Macnica Security Research Center: On the series of data leaks from web systems (7 de outubro de 2026, adendo de 8 de outubro) — security.macnica.co.jp
- GMO Cybersecurity by IERAE: Three points to prepare for the series of unauthorized access incidents (15 de outubro de 2026) — gmo-cybersecurity.com
- GMO Cybersecurity by IERAE: Confirmed that AI is behind many of the sources of the recent unauthorized access (19 de outubro de 2026, atualizado em 21 de outubro) — gmo-cybersecurity.com
Histórico de atualizações
2026-10-24: Incorporado o alerta da JPCERT/CC conforme atualizado em 23 de outubro. Os padrões de ataque passam de quatro para cinco (caso E: tentativas de ataque que usam indevidamente plataformas de teste de penetração baseadas em IA, incluindo tentativas contra servidores WSUS expostos à internet). Acrescentadas as novas pistas do caso B (o mesmo User-Agent do aplicativo público, o JA4 sozinho não identifica o atacante, acesso por Tor e proxies residenciais, e o uso dos endereços IP para pesquisar acessos passados). Acrescentado um link para a visão geral dos ataques conduzidos por IA e a ordem de defesa.
2026-10-23: Acrescentadas as análises de duas empresas japonesas de segurança (7, 15 e 19 de outubro): 80% dos vazamentos divulgados desde julho não podem ser classificados por causa a partir dos comunicados, ataques que permanecem abaixo dos limiares de WAF, o uso de um sistema autônomo de teste de penetração baseado em IA, e três verificações (escopo da avaliação, não depender de um WAF, reduzir dados e chaves de API desnecessários).
2026-10-22: Acrescentada a análise de servidores de atacantes feita pela JPCERT/CC (publicada em 15 de outubro): APIs identificadas pela análise de aplicativos, e quatro contramedidas. Citado o Flutter como exemplo de aplicativos compilados, como faz a JPCERT/CC.
2026-10-19: Acrescentada a central especial de consultas da IPA sobre acesso não autorizado (aberta em 16 de outubro) e seu site especial. Confirmado que o alerta da IPA de 9 de outubro não havia sido atualizado até 19 de outubro.
2026-10-14: Verificado o texto do alerta da PPC e resumido, em uma tabela, seu anexo com exemplos revisados de "10-6 Salvaguardas técnicas" (a ser finalizado em abril de 2027). Acrescentadas as contramedidas do caso 9 (APIs sendo abusadas) do WARNING revisado à verificação de aplicações expostas à internet, e o caso 8 (vazamento de um serviço de nuvem usado) à verificação de serviços externos. Atualizada a lista de documentos e fontes.
2026-10-12: Publicação original. Documentos do Escritório Nacional de Cibersegurança, IPA, JPCERT/CC, PPC, FSA e NPA verificados em 12 de outubro de 2026. A página da IPA é atualizada conforme necessário e o alerta da JPCERT/CC pode receber acréscimos; este artigo será atualizado caso haja mudanças.
Leia em seguida
- Panorama completo dos ataques conduzidos por IA e a ordem de defesa: Defesa contra ciberataques conduzidos por IA (intrusão autônoma, prompt injection, cadeia de suprimentos de IA)
- Visão mais ampla para organizações: A linha de base de segurança para organizações (seis prioridades a partir dos incidentes de 2026 no Japão)
- Verificando o seu próprio site: Como verificar se seu site ou servidor foi invadido
- Pontos de entrada: Dispositivos VPN são a maior porta de entrada / Priorizando com CVSS, EPSS e KEV
- Inventário: Checklist de inventário de segurança / Exposição pública de armazenamento em nuvem
- Termos: O que é um IOC?
- Todos os incidentes de 2026: Vazamentos de dados e ciberataques de 2026