Quem acompanha o noticiário de segurança no Japão percebeu: desde setembro de 2026, quase toda semana aparece um novo comunicado de vazamento. Programas de fidelidade, apps de restaurante, sites de reserva, plataformas de comunidade e portais de vagas publicaram avisos em sequência — vários deles já cobertos aqui, como os casos da Lawson ID, da Bookoff, da Commune e da Baitoru.
Entre 8 e 9 de outubro, os órgãos oficiais de segurança do país reagiram em bloco. O JPCERT/CC publicou o alerta JPCERT-AT-2026-0030, a IPA (Agência de Promoção de Tecnologia da Informação) divulgou uma lista de verificações "para fazer imediatamente", e o METI (Ministério da Economia, Comércio e Indústria) enviou um pedido formal às associações empresariais. Este artigo reúne o que esses documentos dizem, em linguagem prática, para quem administra sistemas em pequenas e médias empresas.
Um aviso importante antes de começar: nenhum desses órgãos atribuiu os vazamentos de empresas específicas a um método de ataque específico. Os casos citados no início servem só como contexto da onda — não estamos dizendo que cada um deles aconteceu da forma descrita abaixo.
O que o JPCERT/CC disse
O alerta AT-2026-0030 foi publicado em 8 de outubro e atualizado em 9 de outubro de 2026. O JPCERT/CC afirma que, por volta de setembro, houve uma sequência de vazamentos de dados pessoais por acesso não autorizado em organizações japonesas, e que as informações técnicas compartilhadas ainda são "limitadas e fragmentadas". Mesmo assim, decidiu alertar por causa da expansão dos danos.
Dois pontos chamam a atenção:
- O alerta trata de um tipo de ataque diferente dos casos de ransomware que acontecem de forma esporádica o tempo todo: aqui o foco são invasões que levam ao vazamento de grandes volumes de dados pessoais.
- Não são só apps voltados ao público. Também foram atingidas ferramentas de BI (business intelligence) e sistemas de gestão usados por funcionários — sistemas que, na cabeça de quem os opera, "não ficam expostos a qualquer um".
O JPCERT/CC ressalta que nem todos os incidentes usaram o mesmo método e que a página será atualizada conforme surgirem novas informações.
Os quatro padrões de ataque observados
O alerta descreve quatro "casos" com base em relatos recebidos. Resumimos em nível defensivo, sem detalhes operacionais:
- Caso A — varredura de vulnerabilidades conhecidas. Não é uma falha única em um produto. Os atacantes testam, alvo por alvo, várias vulnerabilidades já conhecidas e também falhas de configuração, como arquivos de configuração de ambiente ou backups esquecidos em locais acessíveis.
- Caso B — abuso de APIs. Pedidos indevidos a APIs de administração de apps, com alteração de dados. Os relatos incluem análise de apps de smartphone públicos para descobrir endpoints e chaves; ataques a APIs internas que não deveriam ser acessíveis pela interface (mudança de permissões de usuário, criação de contas indevidas); testes com tokens de autenticação malformados; buscas cegas via injeção NoSQL para identificar contas; e uso de chaves de API roubadas em invasões de outros sistemas.
- Caso C — Metabase CVE-2026-72898. A vulnerabilidade de injeção de SQL na ferramenta de BI Metabase, também explorada via API, que o JPCERT/CC já havia alertado em 14 de agosto. Nós cobrimos essa falha em Metabase CVE-2026-72898.
- Caso D — web shell em servidor de aplicação. Foram encontrados arquivos WAR implantados em servidores de aplicação acessíveis a partir do servidor web público; o JSP contido neles funcionava como uma web shell simples.
O JPCERT/CC também publicou endereços IP de origem suspeitos e exemplos de User-Agent para ajudar em investigações, com a ressalva de que alguns IPs podem estar em uso legítimo hoje. Se você precisa checar seus logs, use a lista diretamente na página oficial (link nas fontes) — ela pode ser atualizada.
As medidas recomendadas para APIs
A parte mais útil do alerta é a lista de contramedidas. Para acesso via API, o JPCERT/CC recomenda:
- Limitar o número de requisições por unidade de tempo e bloquear acessos repetidos ou execução em massa.
- Criar limites específicos para funções de alto risco: login, redefinição de senha, envio de SMS e busca.
- Aplicar controle de acesso em cada endpoint, inclusive APIs não públicas, aceitando apenas usuários e métodos HTTP autorizados.
- Dar a usuários e tokens de API apenas o mínimo de permissão necessário.
- Definir validade adequada para tokens e evitar tokens de longa duração.
- Ter como revogar rapidamente tokens que não são mais usados ou que podem ter vazado.
Medidas gerais complementares: restringir a região de origem quando o serviço é usado só em um país; aplicar as atualizações de versões vulneráveis; revisar a contenção de movimento lateral após a invasão de um servidor web; revisar a detecção e a resposta inicial; orientar clientes com antecedência (por exemplo, sobre autenticação multifator); tirar da internet funções administrativas desnecessárias; e não guardar dados após o prazo legal ou o fim do propósito de uso. A referência indicada é o OWASP API Security Top 10.
A lista de verificação imediata da IPA
A IPA publicou em 9 de outubro um documento dirigido a dirigentes de empresas que guardam muitos dados. Segundo a agência, os comunicados de vazamento vêm de setores variados, incluindo instituições financeiras e operadoras de telecomunicações, e ainda não foi possível afirmar que os ataques miram uma vulnerabilidade de produto específica. Pelo padrão dos casos públicos, o ponto de partida parece ser a invasão de aplicações e serviços expostos externamente e o comprometimento de contas.
As verificações que a IPA pede para fazer já:
- Aplicações expostas externamente: levantar todos os apps e serviços próprios publicados na internet; verificar nos logs recentes sinais anormais (volume de erros, diferenças em relação ao normal), começando pelo último mês e ampliando para três meses; checar se há patches pendentes e aplicá-los o quanto antes.
- Serviços externos usados pela empresa: listar todos — nuvem, VPN e outros —, inclusive os contratados por departamentos; conferir os logs de cada serviço (falhas de login, IPs e horários de acesso fora do padrão); e procurar contas que ninguém criou ou contas desativadas que voltaram a ficar ativas.
- Dados guardados: revisar o que a empresa realmente precisa manter, porque dados roubados hoje viram extorsão e venda em fóruns.
Se aparecer qualquer log ou conta anormal, a IPA orienta tratar como incidente de segurança imediatamente e recomenda fortemente acionar uma empresa especializada para a investigação.
Depois disso, a agência lista medidas de médio prazo: revisar o que fica exposto, fortalecer a autenticação (MFA e senhas), revisar permissões e integrações via API, ampliar o conteúdo e o tempo de retenção dos logs, e reconsiderar onde e como os dados são armazenados, incluindo criptografia.
O pedido do METI
O METI repassou os alertas da NCO (Secretaria Nacional de Cibersegurança), do JPCERT/CC e da Comissão de Proteção de Informações Pessoais (PPC) às associações empresariais, como a JADMA (associação japonesa de vendas por catálogo e e-commerce) e a Câmara de Comércio e Indústria do Japão. O ministério pede três coisas: liderança direta da alta direção, acompanhamento rápido de informações sobre vulnerabilidades e migração para "zero trust", considerando toda a cadeia de fornecedores. Em caso de incidente, as empresas dos setores supervisionados devem informar o ministério com a linha do tempo, o tipo de dano e o tipo de ataque, e também considerar comunicar a polícia.
O que uma PME deveria fazer esta semana
Traduzindo os documentos para uma rotina realista:
- Faça o inventário. Liste tudo o que está na internet com o nome da empresa: site, loja online, app, painel administrativo, ferramenta de BI, VPN e serviços em nuvem contratados por cada setor.
- Olhe os logs dos últimos 30 dias. Procure picos de erro, logins de países onde vocês não atuam, chamadas de API em volume incomum e contas novas que ninguém reconhece.
- Feche o que não precisa estar aberto. Painéis de administração e ferramentas internas não deveriam responder a qualquer IP da internet.
- Revise as chaves de API. Revogue as antigas, reduza permissões e verifique se nenhuma chave está embutida em um app publicado.
- Atualize. Priorize os componentes expostos e, se usam Metabase, confirmem a versão corrigida.
- Apague o que não precisa guardar. Menos dados, menos dano.
Para empresas pequenas, a IPA lembra que existem recursos gratuitos, como o autodiagnóstico de cinco minutos e a autodeclaração SECURITY ACTION, além do serviço "Cybersecurity Otasuketai", que reúne monitoramento, atendimento e seguro.
O que ainda não se sabe
Os órgãos não ligaram os incidentes a um único grupo nem a uma única falha, e o próprio JPCERT/CC diz que seu panorama é parcial. Vamos acompanhar novas atualizações do AT-2026-0030 e dos comunicados das empresas afetadas e atualizar este artigo se houver mudanças relevantes.
Fontes
- JPCERT/CC: 直近で相次いでいる国内組織における不正アクセスに関する注意喚起 (JPCERT-AT-2026-0030)
- IPA: 不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について (2026-10-09)
- JADMA: 経済産業省の注意喚起及び情報提供に係る協力依頼 (2026-10-09)
- 日本商工会議所: 不正アクセスによる情報漏えい等の事案を踏まえたセキュリティ対策の徹底について（経済産業省）
- JPCERT/CC: MetabaseのSQLインジェクションの脆弱性（CVE-2026-72898）に関する注意喚起
- Impress Watch: 国内で情報漏えい被害が相次ぐ JPCERT/CCが攻撃手法と対策を公表
- マイナビ TECH+: 国内で不正アクセス相次ぐ、JPCERT/CCが注意喚起
- Macnica セキュリティ研究センター: 相次ぐWEBシステムからの情報漏洩事案について
- OWASP API Security Top 10 (2023)
Quer levar isso para o seu negócio?
A KGA IT ajuda pequenas e médias empresas a implantar assistentes de IA, automações e sites. A consulta é gratuita e respondemos em até 24 horas. Planos a partir de ¥5.000/mês.
- Telefone: 080-9732-1062
- E-mail: kga-it@outlook.com
- Página de contato: kga-it.com/pt/contact