Por que o ransomware transforma os backups no alvo, e não na rede de segurança
Durante anos, o backup foi a exceção que tornava o ransomware sobrevivível: a produção é criptografada, restaura-se a partir do backup e a vida segue. Os atacantes se adaptaram. O 2025 Ransomware Trends report da Veeam pesquisou 1.300 organizações, 900 das quais sofreram pelo menos um ataque de ransomware nos 12 meses anteriores. A Veeam informa que 89% das organizações tiveram seus repositórios de backup visados pelo atacante e que, em média, 34% dos repositórios de backup foram modificados ou apagados. Destruir ou corromper o plano B tira da vítima o seu poder de negociação antes mesmo de a nota de resgate chegar.
O resultado aparece nos números de recuperação. O State of Ransomware 2025 da Sophos pesquisou 3.400 líderes de TI e segurança cujas organizações foram atingidas por ransomware no ano anterior. Entre as organizações que tiveram dados criptografados, apenas 54% os restauraram usando backups, a menor taxa nos seis anos em que a Sophos realiza a pesquisa. Das 151 organizações que acabaram pagando mais do que a exigência inicial do atacante, 38% disseram que seus backups tinham falhado ou estavam funcionando mal (os respondentes em geral citaram dois motivos). Um backup que existe no papel não é a mesma coisa que um backup que se restaura sem problemas sob pressão.
Essa distância, entre "temos backups" e "temos backups resilientes a ransomware", se resume a três pilares: imutabilidade, isolamento e recuperação testada. Não são controles independentes que se possam combinar à vontade. Se faltar qualquer um deles, os outros dois não compensam. Um backup imutável que o atacante não consegue alcançar só é útil se de fato restaurar, e um plano de restore bem testado não vale nada se o backup do qual ele depende foi apagado antes de o exercício sequer começar.
Os três pilares, em detalhe
1. Imutabilidade: backups que o atacante não consegue tocar
Imutabilidade significa que um backup não pode ser alterado nem apagado dentro da sua janela de retenção: nem por um script de retenção mal configurado, nem por uma conta de administrador comprometida, nem por um atacante que já tem credenciais de administrador de domínio. Na prática, ela é imposta por Object Lock em object storage, por hardware Write Once Read Many (WORM) ou por um repositório Linux protegido (hardened repository) com a retenção aplicada na camada de storage, independentemente dos controles de acesso do próprio software de backup.
A distinção importa porque os operadores de ransomware procuram backups que consigam alcançar com credenciais roubadas. O #StopRansomware Guide da CISA diz isso de forma direta: "Ransomware actors often hunt for and collect credentials stored in the targeted environment and use those credentials to attempt to access backup solutions" (os operadores de ransomware frequentemente procuram e coletam credenciais armazenadas no ambiente-alvo e as usam para tentar acessar as soluções de backup). Se a mesma conta administrativa que gerencia o seu software de backup também consegue apagar os pontos de restauração do mês passado, a imutabilidade não está de fato em vigor. É uma configuração que um atacante com privilégios suficientes consegue desligar em minutos.
A própria recomendação de backup da CISA é "maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario" (manter backups offline e criptografados dos dados críticos e testar regularmente a disponibilidade e a integridade dos backups em um cenário de recuperação de desastres). O mesmo guia é cauteloso quanto ao storage imutável na nuvem isoladamente: "Use immutable storage with caution as it does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost" (use storage imutável com cautela, pois ele não atende aos critérios de conformidade de certas regulamentações, e erros de configuração podem gerar custos significativos). A imutabilidade é um controle forte. Ela não substitui uma cópia offline nem um restore testado.
2. Isolamento: um plano de identidade separado e uma cópia que o atacante não consegue alcançar de forma alguma
A imutabilidade protege o backup contra alterações. O isolamento impede, antes de tudo, que ele seja alcançado. Os dois se complementam, não são intercambiáveis, e as empresas que implementam só um deles costumam descobrir a lacuna durante um incidente real, e não durante uma revisão de projeto.
O isolamento tem dois componentes. O primeiro é um plano de identidade separado: a infraestrutura de backup não deve confiar no mesmo domínio do Active Directory, nas mesmas credenciais administrativas nem no mesmo segmento de rede plano que a produção. Um controlador de domínio comprometido não deveria significar automaticamente um ambiente de backup comprometido; se significar, o atacante só precisou comprometer uma coisa, e não duas. O segundo é uma cópia genuinamente offline ou com air gap: pelo menos uma cópia dos dados críticos sem nenhum caminho de rede permanente a partir da produção. Pode ser uma rotação de fitas offline, um destino de replicação desconectado que só fica online brevemente para receber dados, ou uma camada de nuvem sem credenciais persistentes armazenadas em qualquer lugar alcançável a partir do ambiente de produção.
O relatório de 2025 da Veeam diz que as organizações que priorizam a resiliência de dados "can recover from attacks up to seven times faster and experience significantly lower data loss rates" (conseguem se recuperar de ataques até sete vezes mais rápido e têm taxas de perda de dados significativamente menores). A Veeam atribui isso à resiliência de dados como um todo (backup e recuperação, segurança proativa, resposta a incidentes), e não apenas ao isolamento. Ainda assim, o isolamento é uma parte grande do quadro: é a diferença entre um atacante que precisa fazer um trabalho adicional real para chegar ao seu ponto de recuperação e outro que já tem uma sessão aberta para ele, porque ele compartilha o plano de identidade com os sistemas que o atacante acabou de comprometer.
3. Recuperação testada: provar que o restore funciona antes de precisar dele
O menos glamoroso dos três pilares é também o mais fácil de deixar pela metade. No relatório de 2025 da Veeam, 98% dos respondentes tinham um playbook de ransomware, mas só 44% haviam incluído nele verificações de backup e suas frequências. O 2024 Ransomware Trends report da Veeam, baseado em 1.200 organizações atingidas por pelo menos um ataque em 2023, constatou que 63% das organizações corriam o risco de reintroduzir infecções durante a recuperação, porque as equipes, pressionadas a restaurar rápido, pulam etapas como fazer uma nova varredura dos dados em quarentena.
Restores não testados falham de maneiras que ficam invisíveis até o momento em que mais importam: cadeias de backup quebradas, dependências de consistência de aplicação ausentes, credenciais de contas de serviço que expiraram meses antes ou runbooks escritos para uma topologia de infraestrutura que já não existe. Pular a verificação de integridade e a varredura de malware traz um risco mais grave que o tempo de inatividade: restaurar o mesmo payload que causou a interrupção.
Um programa de recuperação testada de verdade significa exercícios agendados de restore completo em um ambiente de recuperação isolado, e não apenas notificações de "job de backup concluído com sucesso". Meça esses exercícios em relação aos RTOs de que o negócio realmente precisa, e não a números que apenas parecem tranquilizadores num slide.
O que os números de recuperação realmente dizem
Os dados de 2025 da Sophos trazem uma manchete que parece tranquilizadora: 97% das organizações que tiveram dados criptografados conseguiram recuperá-los. O detalhamento é menos animador. Pouco mais da metade (54%) restaurou a partir de backups, 49% pagaram o resgate e recuperaram os dados, e 29% usaram outros meios; muitas usaram mais de um caminho. Recuperar os dados e recuperá-los a partir dos seus próprios backups são resultados diferentes. É na distância entre os dois que os pilares fracos aparecem: um bloqueio de retenção que a função errada conseguia anular, uma rede de backup "separada" que ainda confiava no mesmo domínio, ou um restore que nunca tinha sido ensaiado de ponta a ponta.
O custo de errar nisso
Os três pilares não são um checklist abstrato de boas práticas. Eles se relacionam diretamente com quanto custa e quanto dura um incidente de ransomware. O relatório de 2025 da Sophos coloca o custo médio para se recuperar de um ataque de ransomware, sem contar qualquer resgate pago, em US$ 1,53 milhão, contra US$ 2,73 milhões em 2024. 53% das vítimas estavam totalmente recuperadas em até uma semana, contra 35% um ano antes. As demais passaram mais de sete dias em algum grau de interrupção, com tempo de inatividade, perda de produtividade e trabalho de resposta a incidentes se acumulando a cada dia.
A postura de backup é uma das poucas variáveis dessa equação que a organização controla por completo. Se o primeiro movimento do atacante contra o seu repositório de backup dá certo ou não é decidido em grande parte por escolhas feitas meses antes, e não durante o incidente. Quando um atacante já tem credenciais de administrador de domínio e está sondando a sua plataforma de backup, a imutabilidade, o isolamento e a recuperação testada ou já estão em vigor ou não estão; não há como implementá-los às pressas.
Erros comuns que minam os três silenciosamente
Alguns padrões aparecem repetidamente nas análises pós-incidente:
- Confundir snapshots com backups. Um snapshot do VMware é um log de alterações do disco virtual original, e não uma cópia independente. O artigo de boas práticas sobre snapshots da Broadcom é categórico: "Do not use VMware snapshots as backups" (não use snapshots do VMware como backups). O arquivo de snapshot continua crescendo quanto mais tempo é mantido, o que pode lotar o datastore e prejudicar o desempenho, e, se os discos base forem perdidos, "the snapshot files alone are not sufficient to restore a virtual machine" (os arquivos de snapshot sozinhos não são suficientes para restaurar uma máquina virtual). Snapshots são um recurso de conveniência para rollback de curta duração (a Broadcom recomenda manter um único snapshot por no máximo 72 horas), e não uma estratégia de recuperação.
- Tratar "imutável" como uma caixa de seleção, e não como uma propriedade verificada. O Object Lock e as políticas de retenção precisam ser testados contra exatamente a função administrativa que gerencia a plataforma de backup, e não apenas documentados num guia de configuração.
- Chamar de "isolada" uma segunda cópia no mesmo domínio de identidade. Se as mesmas credenciais comprometidas na produção conseguem se autenticar no repositório de backup, a separação geográfica ou de plataforma não oferece isolamento real.
- Medir o sucesso pela conclusão do backup, e não pela verificação do restore. Um check verde no job da noite passada diz que os dados foram gravados em algum lugar. Não diz que esses dados podem ser recuperados, que estão consistentes no nível da aplicação e livres do malware que tornou o restore necessário.
Onde a BackupSec entra
A BackupSec não substitui a sua plataforma de backup. Três dos nossos serviços se relacionam com os pilares acima:
- O ZeroMON monitora o Veeam Backup & Replication. Roda on-premises como OVA, conecta-se com uma conta somente leitura e não envia nada para a BackupSec nem para terceiros. Acompanha a saúde dos jobs, registra as mudanças de configuração no seu módulo Forensic & Audit (quem mudou o quê, e quando), executa um checklist do Security Analyzer, gera relatórios e envia alertas por e-mail e por notificação no próprio aplicativo. Mostra o status de imutabilidade de cada repositório conforme as próprias configurações de repositório do Veeam o informam e sinaliza quando essa configuração muda. Ele lê a configuração do Veeam; não verifica os bloqueios em nível de objeto no próprio storage.
- O ZeroTAM é um consultor dedicado de segurança de backup, e não um software: projeto de arquitetura e de isolamento, planejamento de capacidade, planejamento de recuperação contra ransomware e suporte prioritário durante uma crise.
- O ZeroPEN é um teste de penetração orientado a ameaças do Veeam Backup & Replication, do Veeam ONE e do Enterprise Manager. Simula uma kill chain de ransomware mapeada no MITRE ATT&CK em oito etapas: acesso inicial, descoberta e inventário, abuso de credenciais, comprometimento do servidor Veeam, acesso ao repositório, neutralização do backup, simulação de exfiltração e prova de capacidade de criptografia. Ele nunca apaga backups reais, nunca executa criptografia real nem interrompe serviços de produção ou de backup. Você recebe evidências prontas para auditoria, e as descobertas críticas são testadas novamente. O trabalho também inclui verificação da integridade de restore e da imutabilidade. Como é um teste pontual, os exercícios regulares de restore do pilar 3 continuam sendo necessários.
Fale com a BackupSec sobre a postura de segurança do seu backup →
Quer ver como os seus próprios backups se sairiam? O Backup Security Assessment gratuito traz 28 perguntas em sete áreas, da estratégia de backup e controle de acesso aos testes de recuperação.