Às 7h40, a equipe financeira não consegue abrir o ERP. Em minutos, usuários de outros setores relatam arquivos com extensões desconhecidas e uma mensagem exigindo pagamento em criptomoedas. Este exemplo de recuperação de ransomware mostra por que a continuidade do negócio não depende apenas de ter backup: depende de detectar, conter, validar e restaurar sob controle técnico.
Em um ambiente corporativo, ransomware não é somente um incidente de arquivos indisponíveis. Ele pode interromper faturamento, logística, atendimento, comunicação interna e acesso a sistemas em nuvem. A pressão por retomar a operação rapidamente é real, mas restaurar dados sem eliminar a causa da invasão pode levar a uma segunda criptografia poucas horas depois.
Exemplo de recuperação de ransomware: o cenário
Considere uma empresa de distribuição com 180 usuários, operação em duas unidades e um ambiente híbrido. O ERP está hospedado em servidores virtuais, os documentos comerciais ficam em compartilhamentos de rede e parte da equipe usa Microsoft 365. A empresa possui firewall, antivírus e backup remoto, mas ainda não havia testado formalmente a restauração completa de sistemas críticos.
O incidente começa com uma credencial de VPN comprometida. O invasor acessa a rede fora do horário comercial, identifica contas com privilégios elevados e desativa mecanismos de proteção em algumas máquinas. Em seguida, movimenta-se lateralmente até os servidores de arquivos e o ambiente do ERP. Antes de criptografar os dados, também tenta excluir cópias de backup acessíveis pela rede.
Na segunda-feira, os compartilhamentos, o banco de dados do ERP e parte das estações de trabalho estão indisponíveis. A nota de resgate informa que dados foram exfiltrados e ameaça divulgar informações caso não haja pagamento. Esse detalhe muda a dimensão do caso: além da recuperação operacional, a empresa precisa avaliar privacidade, obrigações contratuais e possível comunicação a autoridades e titulares de dados.
A primeira decisão: conter antes de restaurar
A reação intuitiva é ligar tudo novamente e recuperar o que parou. Em ransomware, essa escolha pode ampliar o dano. A prioridade inicial é impedir que o agente malicioso mantenha acesso ao ambiente ou alcance cópias de dados ainda preservadas.
A equipe de resposta isola servidores afetados, bloqueia a VPN comprometida, revoga sessões ativas e desabilita contas suspeitas. Também restringe o tráfego entre segmentos de rede que não precisam se comunicar para manter atividades essenciais. Estações com indícios de comprometimento são retiradas da rede, sem serem formatadas de imediato, pois podem conter evidências úteis para identificar o vetor de entrada e a extensão do ataque.
Esse isolamento exige equilíbrio. Desconectar toda a operação pode proteger ativos, mas também pode paralisar serviços que não foram afetados. Por isso, a decisão deve ser baseada em visibilidade: logs de firewall, eventos de autenticação, alertas de endpoint, monitoramento de rede e inventário de ativos. Sem esses registros, a organização trabalha com hipóteses e tende a demorar mais para recuperar o controle.
Diagnóstico técnico define a recuperação
Depois da contenção, a empresa monta uma linha do tempo do incidente. A análise identifica o primeiro login anômalo, as máquinas acessadas, as contas utilizadas, os comandos executados e os repositórios que podem ter sido atingidos. O objetivo não é apenas descobrir quem atacou, mas responder com segurança a perguntas operacionais.
Quais servidores podem ser restaurados? Quais backups foram acessados pelo invasor? Houve roubo de dados? Existem persistências, como tarefas agendadas, contas criadas ou alterações em políticas de grupo? O domínio foi comprometido? Essas respostas determinam se a recuperação pode ocorrer no ambiente original ou se será necessário reconstruir componentes essenciais em uma área segregada.
No cenário apresentado, a investigação confirma que o controlador de domínio não foi criptografado, mas apresenta sinais de uso indevido de credenciais administrativas. A decisão é não confiar nele sem validação. A equipe cria contas administrativas temporárias, revisa privilégios, força a troca de senhas e verifica políticas de acesso antes de recolocar serviços críticos em produção.
Backup disponível não significa backup recuperável
A empresa descobre que o repositório principal de backup foi parcialmente afetado porque permanecia acessível com credenciais administrativas utilizadas no ambiente de produção. Porém, uma cópia imutável e isolada, mantida fora do domínio, permanece íntegra. Ela se torna o ponto de recuperação.
Essa diferença é decisiva. Backup convencional pode atender a falhas acidentais, mas ataques de ransomware procuram justamente cópias que possam ser apagadas, corrompidas ou criptografadas. Para ambientes corporativos, a estratégia precisa combinar retenção adequada, segregação de credenciais, cópias fora do ambiente principal e mecanismos que impeçam alteração ou exclusão durante um período definido.
Também é necessário validar a data do backup. Restaurar a cópia mais recente nem sempre é a melhor opção se ela já contém arquivos maliciosos, credenciais comprometidas ou alterações realizadas pelo atacante. A equipe compara pontos de restauração, cruza eventos de segurança e seleciona uma cópia anterior à primeira evidência de invasão.
Recuperação em ambiente controlado
Em vez de restaurar diretamente nos servidores de produção, a empresa monta uma zona de recuperação isolada. Nela, o backup do ERP é restaurado e testado sem conectividade livre com a rede corporativa. São verificados a integridade do banco de dados, os aplicativos dependentes, os certificados, os serviços de autenticação e as integrações com faturamento e logística.
Essa etapa consome tempo, mas evita que arquivos contaminados ou configurações inseguras retornem ao ambiente operacional. Em paralelo, a equipe realiza varreduras antimalware, revisa indicadores de comprometimento e valida configurações de segurança em cada ativo que será reintroduzido.
A ordem de retorno segue a criticidade do negócio. Primeiro, identidade e autenticação seguras. Depois, conectividade, DNS, bancos de dados e servidores de aplicação. Na sequência, ERP, sistemas de emissão fiscal, compartilhamentos de documentos e recursos de usuários. Serviços menos críticos podem aguardar se isso reduzir risco e acelerar a retomada do faturamento.
Comunicação reduz decisões sob pressão
Durante o incidente, a diretoria precisa receber informações frequentes, objetivas e verificáveis. Informar apenas que “a TI está trabalhando” não permite decidir sobre contingência comercial, atendimento ao cliente ou obrigações legais. Por outro lado, divulgar conclusões sem confirmação cria ruído e pode aumentar a exposição da empresa.
No caso analisado, um comitê de crise reúne TI, segurança, jurídico, compliance, comunicação e liderança executiva. A cada ciclo, o grupo acompanha impacto, sistemas indisponíveis, dados potencialmente expostos, previsão de restauração e decisões pendentes. O jurídico avalia os requisitos da LGPD e os contratos com clientes e fornecedores diante da suspeita de exfiltração.
A comunicação com usuários também precisa ser direta. Eles recebem orientação para não conectar dispositivos pessoais, não reutilizar senhas anteriores e encaminhar qualquer comportamento suspeito. Usuários são parte relevante da recuperação porque credenciais, e-mails e dispositivos podem manter o vetor de acesso ativo.
O que a empresa corrigiu após a retomada
Após três dias, o ERP volta a operar com dados restaurados e validados. A empresa não efetua o pagamento do resgate, pois recupera sua base a partir da cópia isolada. Ainda assim, a retomada não encerra o incidente. O período posterior serve para corrigir falhas que permitiram o ataque e reduzir a chance de recorrência.
As ações prioritárias incluíram:
- autenticação multifator para VPN, e-mail, contas administrativas e acessos remotos;
- segmentação de rede entre usuários, servidores, backup e ambientes de gestão;
- revisão de privilégios, contas de serviço e credenciais administrativas;
- monitoramento contínuo de eventos de segurança e detecção de comportamentos anômalos;
- testes periódicos de restauração com metas de tempo e ponto de recuperação definidos;
- plano de resposta a incidentes com responsáveis, contatos e critérios claros de escalonamento.
O principal aprendizado foi que proteção e disponibilidade precisam ser tratadas como capacidades operacionais permanentes. Firewall, backup e antivírus entregam resultados limitados quando são administrados de forma isolada, sem monitoramento, testes e processos de resposta.
Como transformar o exemplo em um plano aplicável
Cada empresa terá sistemas, riscos e exigências de disponibilidade diferentes. Uma operação com e-commerce pode priorizar pedidos e meios de pagamento; uma indústria pode precisar recuperar sistemas de produção; uma empresa de serviços pode depender de telefonia IP, e-mail e documentos compartilhados. O plano deve refletir essa realidade, com responsáveis definidos e critérios objetivos para decidir o que recuperar primeiro.
A Altermedios apoia empresas que precisam manter infraestrutura, conectividade e segurança sob acompanhamento especializado, com foco em continuidade operacional e resposta estruturada a eventos críticos. O valor está em preparar o ambiente antes do incidente, não apenas atuar quando a operação já está parada.
O melhor momento para testar uma recuperação de ransomware é quando não há uma nota de resgate na tela. Validar backups, acessos, segmentação e tempo de retomada agora dá à empresa algo que nenhum pagamento garante: controle sobre a própria operação.