Exemplo de recuperação de ransomware em 7 fases

Uma segunda-feira, às 08:15, pode ser o pior momento para descobrir que os servidores de ficheiros, o ERP e parte do Microsoft 365 estão inacessíveis. É neste cenário que um exemplo de recuperação de ransomware deixa de ser um exercício teórico e passa a ser uma prova à arquitetura, aos processos e às responsabilidades definidas antes do incidente. A questão não é apenas restaurar dados. É retomar a operação sem reintroduzir o atacante no ambiente.

Para uma empresa portuguesa de média dimensão, um ataque pode interromper faturação, logística, atendimento, produção e obrigações contratuais no espaço de minutos. Ter cópias de segurança é necessário, mas não assegura, por si só, recuperação. É preciso saber quais os sistemas prioritários, quem decide, que backups estão limpos e como validar o ambiente antes de o devolver aos utilizadores.

Exemplo de recuperação de ransomware: o cenário

Imagine uma empresa de distribuição com 180 colaboradores, dois escritórios, infraestrutura híbrida e um ERP alojado em máquinas virtuais. Às 07:40, a monitorização deteta encriptação anómala em partilhas de rede. Pouco depois, surgem notas de resgate e vários utilizadores deixam de conseguir abrir ficheiros. A equipa de IT confirma também tentativas de acesso privilegiado a partir de uma conta comprometida.

O erro frequente seria começar imediatamente a restaurar servidores. Isso pode destruir evidência, manter a propagação ativa e restaurar dados para uma infraestrutura ainda comprometida. A recuperação deve seguir uma sequência disciplinada, orientada por RTO, RPO e impacto no negócio.

Neste exemplo, a empresa definiu um RTO de quatro horas para o ERP e de oito horas para os serviços de ficheiros. O RPO é de uma hora para as bases de dados transacionais e de 24 horas para documentos de trabalho. Estes valores não são detalhes técnicos: representam o nível de interrupção e de perda de dados que a direção aceita suportar.

1. Conter antes de recuperar

A primeira decisão operacional é isolar. A equipa desliga da rede os equipamentos afetados, bloqueia contas suspeitas, remove ligações VPN em risco e segmenta os segmentos onde há atividade maliciosa. Não se desliga tudo indiscriminadamente se isso colocar em risco serviços críticos ou apagar evidência volátil. Mas também não se mantém a rede aberta por receio de parar a operação.

O responsável pelo incidente deve ativar uma estrutura de decisão clara. IT, segurança, direção e, quando aplicável, jurídico e comunicação, precisam de trabalhar sobre a mesma informação. Registar horas, ações, sistemas afetados e decisões é essencial tanto para a análise forense como para requisitos de governance, seguros e comunicação com clientes.

A contenção inclui verificar se o atacante alcançou repositórios de backup, consolas de gestão, identidades privilegiadas ou plataformas cloud. Um backup ligado permanentemente ao domínio e acessível com credenciais administrativas comuns não é uma última linha de defesa credível.

2. Determinar o alcance real do incidente

Depois de limitar a propagação, começa o diagnóstico. A equipa analisa logs de autenticação, EDR, firewall, hypervisor, Active Directory, armazenamento e aplicações críticas. O objetivo é perceber o vetor de entrada, a duração da permanência do atacante e a lista de ativos comprometidos.

É comum encontrar uma diferença entre o primeiro alerta e o início real da intrusão. O ransomware pode ser a fase final de um acesso que começou dias ou semanas antes através de phishing, credenciais expostas, uma VPN sem MFA ou um equipamento sem atualizações críticas.

Neste caso, a investigação conclui que uma conta com privilégios elevados foi usada fora do horário normal e que o atacante procurou apagar cópias de segurança. As cópias imutáveis mantidas fora do domínio resistiram. Este facto altera completamente a capacidade de negociação da empresa: há uma via técnica de recuperação, em vez de uma dependência do pagamento de resgate.

3. Escolher um ponto de restauro limpo

Recuperar o backup mais recente nem sempre é a decisão correta. Se a infeção já estava presente, esse ponto pode conter mecanismos de persistência, contas criadas pelo atacante ou ficheiros adulterados. A equipa deve selecionar o último ponto conhecido como limpo, cruzando indicadores de compromisso com a cronologia dos backups.

No exemplo, a base de dados do ERP é restaurada para um ponto com 90 minutos de antiguidade, enquanto os ficheiros partilhados são recuperados da noite anterior. Há perda de trabalho, mas limitada e quantificada. Os departamentos afetados recebem instruções para identificar e reenviar documentação criada depois desse ponto, em vez de se tentar uma reconstrução descontrolada.

A regra 3-2-1-1-0 continua a ser uma referência útil: três cópias dos dados, em dois tipos de suporte, uma fora do local, uma imutável ou offline e zero erros verificados nos backups. Porém, a regra só funciona quando há testes regulares de restauro e evidência de que as cópias são recuperáveis.

4. Reconstruir a base de confiança

Antes de restaurar aplicações, a organização reconstrói os elementos que suportam a confiança do ambiente. Isso inclui identidades, privilégios, políticas de acesso, MFA, certificados, regras de firewall, configurações de VPN e ferramentas de gestão remota.

No cenário apresentado, o Active Directory não é restaurado sem validação. A empresa cria um ambiente controlado, revê contas administrativas, roda palavras-passe privilegiadas, elimina contas obsoletas e aplica MFA onde ainda não existia. Os endpoints afetados são reimaginados ou reconstruídos, não apenas limpos superficialmente.

Esta fase pode parecer mais lenta do que ligar os sistemas rapidamente. Na prática, evita que a recuperação se transforme num segundo incidente. Recuperar servidores sem corrigir o acesso inicial é voltar a abrir a porta ao atacante.

5. Restaurar por ordem de impacto no negócio

A sequência de recuperação deve seguir dependências reais, não a ordem em que os servidores aparecem na consola. Primeiro, serviços de identidade, rede, DNS e segurança. Depois, plataformas de virtualização, bases de dados e aplicações que suportam processos críticos. Só então chegam os serviços menos prioritários e os postos de trabalho em massa.

No nosso exemplo, o ERP é disponibilizado primeiro a uma equipa restrita de finanças, logística e operações. Durante duas horas, valida-se a integridade de transações, acessos e integrações antes de abrir o serviço à restante organização. A partilha de ficheiros regressa em modo controlado, com permissões revistas e monitorização reforçada.

A recuperação de Microsoft 365, aplicações SaaS ou workloads cloud exige o mesmo rigor. O facto de um serviço estar na cloud não significa que os dados, as configurações ou as permissões estejam automaticamente protegidos contra encriptação, eliminação maliciosa ou abuso de contas.

6. Validar, monitorizar e comunicar

Um sistema restaurado não é necessariamente um sistema seguro. Antes de declarar o regresso à normalidade, a equipa confirma a consistência dos dados, os fluxos de negócio, as integrações, as permissões e os controlos de segurança. A monitorização deve manter-se reforçada nos dias seguintes, com atenção a novas autenticações suspeitas, tarefas agendadas e tráfego anómalo.

A comunicação interna deve ser factual. Os colaboradores precisam de saber que serviços estão disponíveis, que comportamentos devem evitar e onde reportar sinais de anomalia. Para clientes, parceiros e autoridades, a comunicação depende do impacto, dos dados envolvidos e das obrigações aplicáveis, incluindo RGPD e enquadramentos como NIS2.

Prometer uma hora de recuperação sem evidência técnica cria um segundo problema. É preferível comunicar uma janela realista, atualizada por responsáveis identificados, do que fornecer previsões otimistas que falham a meio do processo.

7. Transformar o incidente numa melhoria operacional

Depois da recuperação, há um trabalho que muitas empresas adiam: rever o que falhou e o que funcionou. O relatório pós-incidente deve ligar cada decisão a uma ação concreta, com responsável, prazo e orçamento. Pode ser necessário segmentar a rede, substituir equipamento sem suporte, implementar EDR, proteger backups com imutabilidade, reduzir privilégios ou formalizar um plano de resposta a incidentes.

Também é o momento de testar o plano com cenários credíveis. Não basta confirmar que um ficheiro pode ser restaurado. É necessário simular a indisponibilidade de um serviço crítico, medir o tempo até à recuperação, validar dependências e confirmar que os contactos de emergência funcionam fora do horário normal. Um SLA contratual e uma equipa de operação 24/7 fazem diferença quando o incidente acontece às 03:00, não durante uma demonstração.

A ITPOINT trabalha esta realidade como um ciclo de diagnóstico, arquitetura, implementação e operação contínua. O objetivo não é vender mais uma camada isolada de tecnologia. É assegurar que armazenamento, backup, identidade, cibersegurança e suporte funcionam como uma arquitetura recuperável, com responsabilidades claras.

O melhor exemplo de recuperação de ransomware é aquele que a organização consegue executar sem improviso: backups validados, RTO/RPO acordados com o negócio, acessos controlados e uma equipa que sabe exatamente quem decide e o que fazer a seguir. Esse trabalho começa muito antes da nota de resgate aparecer no ecrã.