Ransomware no hipervisor do provedor: onde está a sua cópia?

Por Equipe Técnica HD Doctor

Resposta direta

Se suas VMs e bancos rodam em nuvem, mantenha ao menos uma cópia que não dependa do provedor, em outra conta, outra nuvem ou equipamento próprio, e teste a restauração. No ataque à IDCF Cloud, no Japão, o invasor obteve privilégios de administrador da virtualização e cifrou VMs de 495 empresas e governos locais. O provedor considera difícil restaurar os ambientes originais, e a entrega de dados de backup só começou dez dias depois. O snapshot do provedor ajudou parte dos clientes, mas continuou sob o controle do provedor.

O que aconteceu na IDCF Cloud e o que os comunicados confirmam

Por volta das 3h40 (horário do Japão) de 07/10/2026, clientes de parte da região East Japan Region 1 da IDCF Cloud, serviço da IDC Frontier, controlada pela SoftBank, deixaram de conseguir parar e reiniciar servidores virtuais. No mesmo dia, a empresa atribuiu a falha a ransomware e informou 495 empresas e governos locais afetados (2º comunicado, 07/10/2026: https://www.idcf.jp/news/topics/20261007002). O 7º comunicado, de 27/10/2026, conclui que o invasor explorou uma vulnerabilidade em software de código aberto usado na autenticação do portal da IDCF Cloud e, pelo console de gerenciamento, obteve privilégios de administrador da infraestrutura de virtualização. Em seguida, parou e cifrou as VMs de quatro zonas. A empresa não identificou o software nem o CVE. Fonte: https://www.idcf.jp/news/topics/20261027001. Em 08/10, o 3º comunicado afirmou que os dados dessas zonas seriam difíceis de extrair ou restaurar e que, na avaliação daquele momento, a restauração só seria possível a partir de backups mantidos pelos próprios clientes (https://www.idcf.jp/news/topics/20261008001). Em 14/10, a empresa informou que 194 clientes que usavam a função de snapshot, que salva o estado do armazenamento da VM em um ponto no tempo, tinham dados de backup passíveis de extração. A entrega começou em 17/10 e, em 20/10, o número subiu para 206. Para os 495 afetados, o provedor considera difícil restaurar os sistemas no ambiente original e oferece migração para ambiente alternativo. A IDCF diz que não fez contato com o invasor, não negociou nem pagou resgate e concluiu que dados das VMs dos clientes não foram levados para fora. Em 08/10, o BleepingComputer relatou que capturas de tela feitas por clientes no console mostravam uma mensagem do invasor alegando ter alcançado 239 hipervisores e apagado 554.153 snapshots. O site apresenta os números como alegação, e os comunicados da IDCF não mencionam exclusão de snapshots. Trate-os como afirmação do invasor, não como fato confirmado. Fonte: https://www.bleepingcomputer.com/news/security/ransomware-attack-disrupts-japans-idcf-cloud-used-by-govt-clients/. A lição não é que snapshot seja inútil: neste caso, foram justamente os clientes da função de snapshot que tiveram dados extraíveis. A questão é de quem a cópia dependia. Com o portal fora do ar, os clientes não podiam operar suas VMs por conta própria; a IDCF passou a executar comandos a pedido, pediu aos clientes das zonas e regiões não afetadas que fizessem backup por conta própria, manteve a função de snapshot suspensa para verificação e só em 18/10 reativou seu serviço de backup, que, segundo a empresa, permite restaurar dados em outra nuvem ou on-premises (6º comunicado: https://www.idcf.jp/news/topics/20261018001). O acesso veio de uma vulnerabilidade na autenticação do próprio portal e chegou à administração da infraestrutura, uma camada que nenhuma configuração da conta do cliente controla. Uma cópia fora do provedor é a camada que não depende dele para ser restaurada. Se sua empresa for afetada por incidente semelhante, guarde tudo o que o provedor entregar, como arquivos de disco virtual, exports e dumps de banco, em mídia separada, preserve o original e trabalhe sempre em cópias. Se o material entregue não abrir ou se as cópias locais estiverem danificadas, a HD Doctor pode avaliar a recuperação conforme o material preservado. Essa avaliação não alcança dados que continuam na infraestrutura do provedor, não substitui a resposta a incidentes e não garante recuperar conteúdo perdido.

Três decisões que deixam seus dados presos ao provedor

1.
Tratar o snapshot do provedor como sua única cópia. Snapshots e backups oferecidos pelo próprio provedor são úteis, mas ficam sob a mesma administração e dependem do cronograma dele para voltar. Mantenha ao menos uma cópia em outra conta, outra nuvem ou equipamento próprio.
2.
Gravar por cima do que o provedor devolver. Ao receber discos virtuais, exports ou dumps, guarde o original intocado em mídia separada e faça os testes em cópias. Uma restauração malsucedida sobre o único arquivo pode eliminar a alternativa de recuperação.
3.
Restaurar no mesmo ambiente antes de conhecer a causa. Enquanto o provedor não informar a causa e a correção, restaurar no mesmo painel pode expor a cópia ao mesmo acesso indevido. Combine com a equipe de segurança onde a restauração será feita.

Cinco passos para não depender só do provedor

Roteiro editorial para empresas com VMs, bancos ou arquivos em nuvem. Ajuste a frequência e o destino das cópias ao volume de dados e ao prazo de retorno que a operação suporta.

1
Mapeie o que depende do provedor
Para cada VM e banco, registre onde ficam as cópias, quem as administra e se elas sobrevivem à perda da conta ou do painel do provedor. Se todas as cópias dependem do mesmo provedor, esse é o primeiro ponto a corrigir.
2
Crie uma cópia fora do provedor
Exporte VMs e bancos periodicamente para outra conta, outra nuvem ou equipamento próprio, com credenciais separadas. Onde houver suporte, use retenção imutável, como Object Lock. Defina a frequência pelo volume de dados que a empresa aceita perder.
3
Teste a restauração fora do ambiente original
Restaure uma VM e um banco representativos em ambiente separado e confira se a aplicação abre e se os dados batem com a referência. Anote o tempo gasto: é o prazo realista de retorno caso o provedor fique indisponível.
4
Revise contrato e SLA de backup
Leia o que o contrato diz sobre backup, retenção, local de armazenamento e responsabilidade por perda de dados. Pergunte como o provedor entrega os dados se o painel ficar fora do ar e em que formato. Registre as respostas por escrito.
5
Se for afetado, preserve o que receber
Guarde discos virtuais, exports e dumps entregues pelo provedor em mídia separada, com data, origem e hash, e trabalhe em cópias. Se o material não abrir ou estiver incompleto, mantenha-o como recebido antes de buscar avaliação profissional.

Perguntas sobre nuvem, snapshots e cópias externas

Snapshot do provedor de nuvem é backup?

Depende de onde ele fica e de quem o controla. No caso da IDCF, clientes que usavam a função de snapshot tiveram dados extraíveis, mas a entrega dependeu do provedor e começou em 17/10. Uma cópia que você consegue restaurar sem o provedor reduz essa dependência.

Minha empresa usa AWS ou Azure, não a IDCF. Isso me afeta?

O incidente foi específico da IDCF Cloud e não indica falha em outros provedores. A questão estrutural, porém, é a mesma: se VMs e cópias dependem da mesma conta e do mesmo painel, um incidente nessa camada pode atingir as duas ao mesmo tempo.

O provedor não pagou resgate. Isso garante a recuperação?

Não. A IDCF informou que não negociou nem pagou e considera difícil restaurar os sistemas no ambiente original. A recuperação de cada cliente dependeu de haver dados de backup extraíveis, e a possibilidade de restaurá-los foi tratada caso a caso.

Quando faz sentido pedir recuperação profissional de dados?

Quando discos virtuais, exports ou dumps entregues não abrem ou estão incompletos, ou quando as cópias locais estão danificadas e não há outra cópia validada. Preserve o material como recebido. A avaliação depende do estado desse material; dados que permanecem no provedor ficam fora do alcance.

Recebeu do provedor dados que não abrem?

Preserve o material como recebido e informe datas, origem e tentativas realizadas.