Para quem é: qualquer pessoa responsável pela segurança de uma empresa ou do próprio site. Este não é um relato caso a caso; é o padrão que aparece quando se alinham as divulgações de organizações japonesas em agosto de 2026. Todos os fatos vêm dessas divulgações e da imprensa; não há inferência sobre a causa.
Classificados pela via de entrada
Com base no que cada organização publicou; números e causas apenas conforme divulgados.
| Divulgado | Organização | Onde começou | Classe |
|---|---|---|---|
| 3 ago | Kodansha | Caixa de e-mail corporativa — contatos roubados, e e-mails se passando por esse funcionário foram enviados a alguns deles | Credencial |
| 4 e 7 ago | Innovation Co. | Credenciais do GitHub — a empresa divulgou duas falhas: tokens fixados em configuração e dados pessoais armazenados em repositórios | Credencial |
| 13 ago | Charm | Acesso não autorizado ao site de e-commerce (–230.000 registros, incluindo hashes de senhas) | Direto |
| 14 ago | Nichirei | Ransomware (falha de sistema em 13 de julho; dados de funcionários possivelmente expostos) | Direto |
| 17 e 19 ago | Sakura Internet | O ambiente de gestão do provedor, depois o sistema de gestão de contratos (até 1.360.563 contas de membros no escopo) | Credencial / provedor |
| 20 ago | Expo 2025 Association | Microsoft 365 de uma subcontratada, a partir de um e-mail de phishing recebido em 13 de maio | Credencial / fornecedor |
| 20 ago | VOISING | Uma ferramenta de BI (até ~170.000 pessoas) | Credencial / SaaS |
| Ago | JST (relatado) | Acesso a caixa de e-mail (~16.000 mensagens) | Credencial |
| 12 ago | OCS, ANA Group (relatado) | Uma vulnerabilidade na aplicação | Direto |
Como ler estes números
Os números acima são como publicados na época, e a maioria das investigações está em andamento. Em particular, o 1.360.563 da Sakura Internet é o número de registros de membros potencialmente no escopo, não um vazamento confirmado — a empresa afirma que nenhuma exfiltração foi confirmada. Não tratar como definitivo um número ainda em investigação é a habilidade básica para ler notícias como estas.
Por que proteger apenas os seus próprios sistemas não basta
Início: uma conta legítima fora do seu controle
o M365 de um fornecedor / uma ferramenta de BI / uma caixa de e-mail / um token do GitHub / o console de um provedor
O atacante realiza ações comuns
entra normalmente com a credencial roubada e lê os dados normalmente
Seu servidor (intacto)
correções, WAF e CSP não se aplicam a este caminho
Uma vulnerabilidade explorada significa que alguém entrou por uma falha, e corrigir a falha a impede. Uma credencial roubada significa que alguém entrou normalmente, portanto não há falha a corrigir. O que precisa de proteção é a própria credencial: quem a detém, onde está armazenada e por quanto tempo permanece válida.
O que não funciona aqui
- Correção de falhas — irrelevante para um ataque que não explora nada
- WAF / IPS — um login legítimo não parece anômalo
- “Somos pequenos demais para ser alvo” — o alvo foi um fornecedor ou provedor, e você foi afetado como cliente deles
- Trocar o modelo de hospedagem — um VPS não impede o roubo de credenciais
O que funciona
- Autenticação multifator, especialmente em e-mail, hospedagem de código e administração de SaaS
- Credenciais de curta duração e escopo restrito — desative tokens de longa duração
- Um inventário de fornecedores e SaaS que podem acessar seus dados
- Nenhum segredo fixado em configuração; nenhum dado pessoal em repositórios
- Planejar assumindo que foi lido — reduza o que existe para ser levado
O que fazer
Liste os serviços externos e as subcontratadas das quais você depende
Hospedagem, SaaS, ferramentas de BI, plataforma de e-mail, hospedagem de código — e subcontratadas. Sem essa lista, você nem consegue responder “estamos no escopo?” quando a notícia sair. Como montar uma: a lista de verificação do inventário de ativos.
Ative a autenticação multifator no e-mail e na hospedagem de código primeiro
Vários dos pontos de partida acima foram caixas de e-mail e credenciais de hospedagem de código. Ambos são contas a partir das quais tudo o mais pode ser reemitido, por isso ficam acima das demais. → como escolher a autenticação multifator
Inventarie as credenciais de longa duração e reduza sua validade e escopo
Segredos em arquivos de configuração, tokens de acesso sem expiração, chaves válidas em todos os repositórios. Presuma o roubo e faça com que o que um ladrão obtém seja pequeno e de curta duração. → o que é perigoso em .env e chaves de API / como impedir segredos no momento do commit
Defina antecipadamente o que acontece se o seu provedor for violado
Quando chegar o aviso de que seu provedor foi comprometido, o que você realmente perde? Responder a isso antecipadamente define o que você faz no dia. → o que fazer quando sua hospedagem web é violada
Presuma que virá phishing oportunista
Incidentes grandes são sempre seguidos de e-mails se passando por eles. Em um dos casos de agosto, foi divulgado que e-mails se passando pelo funcionário foram enviados aos contatos roubados. Não clique em links de um e-mail de “notificação de incidente”; acesse você mesmo o site oficial. → o que é phishing
Visão deste site: esta não é uma história de grandes empresas
A tabela lista grandes organizações, mas os pontos de partida não têm relação com o porte: uma caixa de e-mail, direitos de administração de SaaS, credenciais deixadas em um repositório. É igual para um desenvolvedor solo e, talvez, pior, porque uma operação pequena depende mais de serviços externos e uma credencial tende a dar acesso a mais coisas. Nossa posição é coerente: neste momento, não distribuir credenciais além do necessário e não deixá-las ativas sem uso faz mais do que tentar tornar os sistemas impossíveis de invadir. Mantenha a correção de falhas como base e direcione o foco para as credenciais.
Fontes
Os fatos vêm da divulgação de cada organização e da imprensa. Nenhuma atribuição de causa ou responsabilidade além do que foi publicado.
- Sakura Internet — primeiro relatório (17 ago) / segundo relatório (19 ago, atualizado em 26 ago) / FAQ
- Expo 2025 Association — relatório sobre acesso não autorizado em uma subcontratada (20 ago)
- Kodansha — aviso sobre exposição de dados pessoais (3 ago)
- Charm — aviso sobre acesso não autorizado (13 ago)
- Innovation Co. — relatório final sobre o incidente com o GitHub (7 ago)
- Reportagem sobre a Nichirei — @IT (15 ago)
- Reportagem sobre a VOISING — ITmedia NEWS (21 ago)
Leia a seguir
- Casos recentes que começaram com uma conta ou login de fornecedor: Navigate360 P3 (plataforma de denúncias Crime Stoppers) / ASOS (Reino Unido, dados de clientes)
- Um caso de site de empregos em que a chave de nuvem de um terceirizado foi usada indevidamente: MyBRANDS
- Todos os incidentes de 2026 (Japão e mundo): lista de violações e ciberataques, e como a via de entrada difere
- Comparando os principais casos de 2026: o que KDDI, Aflac, Digital Agency e Sakura Internet têm em comum
- Quando a VPN é a via de entrada: dispositivos VPN são a principal via de entrada para ransomware: defesa de acesso remoto após a violação da Digital Agency
- Preparação: a lista de verificação do inventário de ativos / como escolher a autenticação multifator
- Quando o provedor é violado: o que fazer quando sua hospedagem web é comprometida
- Quando credenciais de nuvem de desenvolvimento são roubadas: o acesso não autorizado à Nikkei (cerca de 1,83 milhão de registros)
- Quando credenciais de operação de nuvem são obtidas: acesso não autorizado aos serviços em nuvem da Digital Arts
- Roubo de credenciais: quando um único npm install rouba suas credenciais / o que é perigoso em .env e chaves de API
- Design: falhas de design na redefinição de senha — quando o próprio processo de redefinição de um serviço entrega credenciais a um atacante
- Caso: o ransomware da KADOKAWA (2024) — credenciais roubadas por phishing como ponto de entrada