Incidentes e Vulnerabilidades
Ransomware na KADOKAWA / Niconico (2024) — por que se espalhou por toda a empresa, e segmentação de rede & BCP
Em junho de 2024, o grupo KADOKAWA foi atingido por ransomware: serviços como o Niconico ficaram meses fora do ar e dados de ~250.000 pessoas vazaram. A entrada foi descrita como phishing; segundo relatos, espalhou-se pela falta de segmentação de rede. Defenda-se com login resistente a phishing, segmentação e um BCP.
Lemos brechas reais e públicas não como notícias reprisadas, mas como "como você se defende disto?" Este artigo se baseia no registro público (comunicados da empresa, reportagens confiáveis). As fontes estão listadas no final; nenhum passo a passo de ataque e nenhum detalhe identificável de qualquer pessoa está incluído.
- Alvo
- Sistemas internos do grupo KADOKAWA e dados pessoais de associados, alunos e funcionários (operadoras: KADOKAWA Corporation / Dwango, etc.)
- Detectado
- Madrugada de 8 de junho de 2024 (interrupções nos serviços do grupo notadas; serviços parados naquele dia)
- Padrão
- Phishing de um funcionário para roubar credenciais → entrada na rede interna → execução de ransomware e roubo de dados (dupla extorsão)
- Escala
- Dados pessoais de ~250.000 pessoas vazaram; muitos serviços, incluindo o Niconico, fora do ar por meses, com efeitos em cascata sobre publicação e distribuição
- Causa-raiz (segundo relatos / análises)
- Roubo de credenciais via phishing + sistemas de criticidade diferente em uma rede (pouca segmentação) que, segundo relatos, o deixou se espalhar por toda a empresa + contenção e preparação de continuidade de negócios apontadas como desafios
- Principais correções
- Autenticação resistente a phishing (MFA, passkeys); segmentação de rede + privilégio mínimo; continuidade de negócios (BCP), backups e ensaios de recuperação
O que aconteceu (em termos simples)
Ransomware criptografa os sistemas de uma organização em troca de resgate e, cada vez mais, também ameaça publicar os dados roubados. Na KADOKAWA, a primeira entrada foi phishing mirado num funcionário. Um login falso e afins roubaram credenciais, que foram usadas para entrar na rede interna.
Mas o que tornou este incidente tão grande não foi como os atacantes entraram, e sim como o dano se espalhou. O serviço de vídeo, os sistemas centrais de publicação, os sistemas escolares e o site corporativo, sistemas de criticidade e propósito muito diferentes, dividiam a mesma rede, segundo relatos. Sem separação suficiente, uma brecha em um ponto aparentemente se espalhou por tudo. Como resultado, muitos serviços, incluindo o Niconico, ficaram fora do ar por meses, com efeitos sobre publicação e distribuição. Mais do que a invasão em si, uma rede pouco segmentada é o que relatos e análises apontam como o que ampliou o dano à escala da empresa inteira.
Divida sua rede em zonas por criticidade
Grandes navios dividem o casco em compartimentos estanques. Se um é rompido e inunda, a água fica naquele compartimento e o navio não afunda. As redes são iguais: divida sistemas de criticidade e papel diferentes em zonas separadas (segmentos) e limite o tráfego entre zonas, e um comprometimento pode ser parado ali. Coloque tudo em uma rede e um único comprometimento pode se espalhar por toda ela.
Cada etapa do ataque e como detê-la
Foi uma cadeia com um lugar para pará-la em cada etapa. Leia-a como onde ela poderia ter sido quebrada, não como um passo a passo.
1. Phishing rouba as credenciais de um funcionário
Um login falso e afins pegaram o ID e a senha de um membro da equipe.
Parada: autenticação resistente a phishing (MFA, passkeys); antiphishing
2. Credenciais usadas para entrar na rede interna
As credenciais roubadas foram usadas para entrar.
Parada: autenticação multifator; controle de acesso; detecção de login suspeito
3. Pouca segmentação: o dano se espalhou por toda a empresa
Sistemas de criticidade diferente, segundo relatos, dividiam uma rede, então o ataque continuou se espalhando.
Parada: segmentação de rede; isolar por criticidade; privilégio mínimo
4. Longa interrupção do negócio, dados vazados (dupla extorsão)
Os principais serviços ficaram fora do ar por meses e os dados roubados foram publicados.
Parada: continuidade de negócios (BCP); backups + ensaios de recuperação; não depender de pagar
Linha do tempo divulgada
2024-06-08
Na madrugada, serviços do grupo, incluindo o Niconico, saem do ar; a operadora (Dwango) para os serviços afetados e inicia a manutenção.2024-06
Confirmado como ataque de ransomware. Mesmo após desligar servidores remotamente, o atacante os reiniciava para continuar se espalhando, então os cabos de energia e comunicação foram fisicamente desconectados para conter.2024-07
Um grupo de ransomware assume a autoria e vaza dados (dupla extorsão). A KADOKAWA divulga a situação em etapas.2024-08-05
Resultados da investigação divulgados: dados de ~250.000 pessoas (alunos, responsáveis, funcionários, associados). A causa é descrita como phishing de um funcionário. A recuperação dos principais serviços avança.2024-08–10
Recuperação em etapas (site corporativo e área de livros em agosto; Niconico e portais em outubro). A recuperação ampla levou vários meses.
Causa-raiz: não só a entrada, mas como o dano se espalhou
Descartar isto como "eles caíram num phishing" perde o ponto. Impedir a invasão importa, mas a questão central é se o dano fica limitado depois que os atacantes estão dentro, e isso depende de segmentação e continuidade de negócios.
Os pontos fracos apontados (à época)
- Autenticação da equipe quebrada por phishing (proteção multifator fraca)
- Sistemas de criticidade diferente em uma rede (pouca segmentação), segundo relatos
- Uma estrutura em que um comprometimento poderia se espalhar por tudo
- Preparação de continuidade de negócios para uma interrupção longa apontada como insuficiente
A configuração que aguenta
- Autenticação resistente a phishing (MFA, passkeys) dificulta a invasão
- Segmentação de rede por criticidade, mais privilégio mínimo
- Contenha um comprometimento em sua zona; impeça a propagação por toda a empresa
- BCP, backups e ensaios de recuperação para uma interrupção longa
Um resgate não substitui um plano de continuidade de negócios
O pagamento de resgate vira manchete, mas pagar não garante nem a recuperação nem que o vazamento pare (reportagens notam casos em que, mesmo quando um resgate teria sido pago, os dados não foram totalmente recuperados). No que você confia não é no pagamento, e sim em segmentação de rede, backups e um plano de continuidade de negócios (BCP) feitos com antecedência. Decidir "como o negócio continua e se recupera se os sistemas centrais ficarem fora do ar por semanas ou meses" em tempos calmos é o que deixa opções em uma crise. (Relacionado: a entrada por dispositivo VPN antigo no incidente da Capcom.)
Como você se defende disto
Ransomware mira organizações de todo tamanho. Em ordem de prioridade:
Dificulte a invasão (autenticação resistente a phishing)
A entrada é frequentemente phishing. Dê à equipe autenticação multifator e, onde puder, um método resistente a phishing como passkeys, para que uma senha roubada por um login falso não deixe ninguém entrar.
Segmente a rede por criticidade
Divida sistemas de criticidade e papel diferentes (vídeo, publicação, escola, corporativo) em zonas separadas, e limite o tráfego entre zonas. Se uma for comprometida, pare ali. Incorpore isso à sua base de segurança da organização.
Prepare continuidade de negócios (BCP), backups e recuperação
Decida em tempos calmos "como o negócio continua e se recupera se os sistemas centrais ficarem fora do ar por muito tempo." Mantenha backups offline / versionados e ensaie a recuperação. Assuma que pagar não garante a recuperação.
Tenha os meios de conter um comprometimento rapidamente
Seja capaz de isolar uma zona rapidamente e parar a propagação (monitoramento, EDR, procedimentos). Com a segmentação no lugar, a contenção é mais rápida e mais eficaz.
Onde isto se sobrepõe a como este site é construído
No fundo, quando tudo fica em uma única rede, um comprometimento pode se espalhar por toda a empresa, que é o que este incidente, segundo relatos, ilustra. Isso é o oposto dos próprios princípios deste site: limitar até onde o dano pode se espalhar se uma parte for violada, isolar o que importa e defender em camadas. Uma rede não segmentada carrega o mesmo perigo que uma única chave de API que alcança todos os dados, ou um ponto único de falha. "Dificulte a invasão, divida por criticidade e prepare-se para continuar operando mesmo quando algo para" é uma defesa que qualquer um pode implementar em qualquer escala.
Fontes (registro público)
Os fatos aqui se baseiam nas seguintes informações públicas. Nenhum passo a passo de ataque e nenhum detalhe identificável de qualquer pessoa está incluído — apenas as lições defensivas.
- Comunicados oficiais da KADOKAWA Corporation / Dwango (avisos sobre o ataque de ransomware e o vazamento de dados, 2024) — group.kadokawa.co.jp
- Reportagens da época (entrada via phishing, a questão da segmentação de rede e a linha do tempo de recuperação, 2024), baseadas nas divulgações primárias
Leia a seguir
- Glossário: o que é ransomware (como funciona e defender-se para dizer "não") / o que é phishing (como bloquear a entrada)
- Prática: fundamentos de backup (a regra 3-2-1) / a base de segurança da organização (segmentação, privilégio mínimo)
- Caso: o ataque de ransomware à Capcom (2020) (um dispositivo VPN antigo e dupla extorsão — um ângulo diferente)
FAQ
QPor que a brecha na KADOKAWA se espalhou por toda a empresa?
Sistemas de criticidade e propósito muito diferentes (o serviço de vídeo Niconico, os sistemas centrais de publicação, os sistemas escolares, o site corporativo) segundo relatos dividiam a mesma rede e não estavam devidamente segmentados. Sem separação suficiente, uma brecha em um ponto aparentemente se espalhou por todo o grupo. A porta de entrada foi descrita como phishing que roubou as credenciais de um funcionário.
QO que significa 'segmentar' uma rede e por que ajuda?
Significa dividir sistemas de criticidade e papel diferentes em <strong>zonas separadas (segmentos)</strong> e limitar o tráfego que cruza entre eles. Quando segmentado, um servidor comprometido não se espalha facilmente para outras zonas. Limitar até onde um único comprometimento pode chegar é uma defesa básica e muito eficaz.
QUma organização menor pode aprender com isso?
Sim: (1) coloque seus sistemas importantes em uma rede / fronteira de privilégio diferente do resto; (2) use autenticação resistente a phishing (MFA, passkeys) para a equipe; (3) tenha um plano de 'como o negócio continua se os sistemas centrais ficarem fora do ar por muito tempo' (BCP), mais backups e ensaios de recuperação; (4) assuma que pagar um resgate não garante a recuperação. Mesmo em pequena escala, colocar tudo em uma rede não segmentada carrega o mesmo perigo.