Uma empresa de e-commerce percebeu o problema às 6h12 de uma segunda-feira: pedidos não eram processados, o ERP exibia arquivos com extensões desconhecidas e um aviso de resgate ocupava a tela dos servidores. Este case de recuperação de ransomware mostra que o fator decisivo não foi apenas ter backup. Foi ter cópias isoladas, um plano acionável e infraestrutura capaz de voltar à operação sem propagar a infecção.
O episódio é representativo de um risco recorrente para lojas virtuais, agências, empresas de software e negócios que dependem de sistemas online. Ransomware não interrompe apenas um servidor. Ele pode bloquear faturamento, atendimento, logística, acesso a dados e a confiança de clientes. A recuperação precisa tratar disponibilidade, segurança e continuidade como parte do mesmo processo.
O cenário antes do ataque
A empresa operava uma loja virtual integrada ao ERP, gateway de pagamento, sistema de estoque e ferramentas de atendimento. A arquitetura tinha dois servidores virtuais para aplicações, um banco de dados separado e armazenamento destinado a arquivos e backups. Havia monitoramento de disponibilidade, mas o controle de acesso administrativo ainda dependia de credenciais compartilhadas em parte da equipe.
O ponto de entrada foi uma conta de acesso remoto comprometida. Após o invasor obter privilégios elevados, ele se movimentou pela rede, desativou serviços de proteção em uma das máquinas e iniciou a criptografia de volumes acessíveis. Também tentou atingir os backups conectados ao ambiente de produção.
Esse detalhe muda o resultado de muitos incidentes. Backup que permanece permanentemente montado, usa as mesmas credenciais da produção ou não possui controle de retenção pode ser criptografado junto com os dados principais. Nesse caso, a cópia de segurança existe no papel, mas não serve para a recuperação.
Case de recuperação de ransomware: as primeiras horas
A resposta começou antes de qualquer tentativa de restaurar arquivos. O time isolou os servidores afetados da rede, bloqueou acessos remotos, revogou sessões ativas e preservou evidências para análise. Religá-los rapidamente ou executar ferramentas sem critério poderia apagar rastros e reinfectar serviços ainda saudáveis.
Em seguida, foi feito um levantamento objetivo: quais sistemas estavam comprometidos, quando ocorreu a última atividade legítima e quais backups estavam fora do alcance do invasor. O monitoramento indicou movimentações anormais durante a madrugada. Essa informação definiu o ponto de restauração, evitando recuperar uma cópia já contaminada.
A operação seguiu quatro frentes simultâneas:
- contenção do acesso indevido e segmentação dos ativos afetados;
- validação de backups com retenção protegida e cópia externa ao ambiente de produção;
- reconstrução de servidores em uma rede separada;
- comunicação interna com responsáveis por operação, segurança, atendimento e gestão.
O objetivo não era colocar tudo no ar no menor tempo possível a qualquer custo. Era restaurar os serviços essenciais com segurança. Em incidentes desse tipo, voltar depressa para uma infraestrutura que mantém a vulnerabilidade inicial só reduz o intervalo até o próximo impacto.
Por que o backup imutável fez diferença
A empresa mantinha cópias diárias em uma camada de armazenamento com retenção definida e credenciais distintas das utilizadas nos servidores de aplicação. As versões não podiam ser alteradas ou excluídas durante o período de imutabilidade configurado. Quando o invasor tentou apagar os pontos de restauração, a ação falhou.
Imutabilidade não substitui a estratégia de backup. Ela é uma proteção adicional contra alteração acidental, exclusão maliciosa e criptografia das cópias. A política precisa considerar frequência, retenção, criptografia, localização das cópias e testes de recuperação.
Para uma loja virtual, por exemplo, perder 24 horas de dados pode significar pedidos sem registro, divergência de estoque e trabalho manual de conciliação. Para um escritório ou uma agência, o mesmo período pode afetar projetos, contratos e dados de clientes. O RPO, ou ponto objetivo de recuperação, deve refletir a perda aceitável para o negócio, e não apenas a capacidade técnica disponível.
Também existe o RTO, o tempo objetivo para retorno do serviço. Um banco de dados pode ser restaurado em uma hora, mas a aplicação pode exigir mais tempo para validação, integração e testes. Prometer recuperação imediata sem medir esses componentes cria uma falsa sensação de segurança.
A restauração ocorreu em ambiente limpo
Em vez de restaurar diretamente nas máquinas comprometidas, a equipe provisionou novos servidores, aplicou atualizações, revisou regras de firewall e recriou usuários administrativos com autenticação multifator. O banco de dados foi restaurado primeiro, seguido pelos arquivos da aplicação e pelas integrações prioritárias.
A restauração foi conduzida em uma rede isolada. Antes da liberação ao público, foram executados testes de integridade, verificação antimalware, análise de logs e validação das funções críticas: login, carrinho, pedidos, pagamentos, emissão fiscal e sincronização de estoque. Só depois disso o tráfego foi direcionado gradualmente para o novo ambiente.
Esse processo levou pouco mais de sete horas para disponibilizar a operação principal. Alguns recursos secundários ficaram temporariamente indisponíveis, uma decisão consciente para preservar segurança e reduzir o tempo de retorno do faturamento. O ambiente completo foi normalizado no dia seguinte, após novas verificações.
O pagamento do resgate não foi considerado como plano de recuperação. Além de não haver garantia de chave funcional ou de exclusão dos dados copiados, o pagamento não corrige a causa da invasão. A decisão deve envolver gestão, jurídico, segurança e, quando aplicável, autoridades competentes. Do ponto de vista operacional, a prioridade é conter, investigar e recuperar a partir de ativos confiáveis.
O que mudou após o incidente
Depois da recuperação, a empresa transformou o evento em revisão de arquitetura. Credenciais compartilhadas foram eliminadas, acessos privilegiados passaram a ser individuais e protegidos por autenticação multifator, e as permissões foram reduzidas ao mínimo necessário. A rede ganhou segmentação entre aplicação, banco de dados, backup e administração.
Os backups passaram a seguir uma política em camadas, com cópias locais para recuperação rápida, cópias externas e retenção imutável. Mais relevante do que aumentar o volume armazenado foi estabelecer testes periódicos. Um backup só é comprovadamente útil quando a empresa restaura dados em um ambiente controlado e confirma que sistemas e processos funcionam.
O monitoramento também evoluiu. Alertas de alterações em massa, falhas de backup, elevação de privilégios, desligamento de agentes de proteção e acessos fora do padrão passaram a ter tratamento definido. Monitorar apenas CPU, memória e uptime não identifica sozinho um ataque em andamento.
Para operações com alta exigência de disponibilidade, vale separar os componentes críticos em infraestrutura adequada, com recursos dimensionados, rede protegida e suporte técnico disponível 24/7. Servidores virtuais, dedicados ou ambientes híbridos podem atender essa necessidade, mas a escolha depende da carga, das integrações, do nível de isolamento e da responsabilidade operacional desejada. A Locacloud pode apoiar empresas que precisam centralizar infraestrutura, conectividade e segurança em datacenters estratégicos, com operação voltada à continuidade do negócio.
Como preparar sua infraestrutura antes do próximo ataque
A principal lição deste caso não é que ransomware pode ser resolvido por uma única ferramenta. A defesa depende de camadas que se complementam. Backups sem teste falham; firewall sem gestão de identidade falha; monitoramento sem procedimento de resposta apenas registra o incidente; infraestrutura sem redundância transforma uma falha isolada em indisponibilidade prolongada.
Comece mapeando os sistemas que não podem parar e as dependências entre eles. Defina quem pode desligar acessos, quem aprova uma restauração e qual canal será usado para comunicação se e-mail e ferramentas corporativas estiverem indisponíveis. Documente credenciais de emergência em local seguro, mas não as mantenha acessíveis dentro do mesmo ambiente que pode ser comprometido.
Depois, teste um cenário realista. Simule a perda de um servidor, restaure uma cópia de banco de dados, valide a aplicação e cronometre o processo. O teste revela gargalos que não aparecem em relatórios: permissões ausentes, chaves de integração esquecidas, DNS mal documentado, falta de capacidade computacional e equipes sem definição de responsabilidade.
Recuperar dados é essencial. Recuperar a capacidade de operar com segurança é o que protege receita, clientes e reputação quando o incidente deixa de ser uma hipótese e passa a exigir resposta imediata.