Backup e Recuperação contra Ransomware: exercícios práticos e simulação de recuperação completa

Objetivo do exercício guiado

Este capítulo consolida o que você já preparou nos capítulos anteriores em um exercício prático de ponta a ponta: simular um ataque de ransomware (criptografia + tentativa de exclusão de backups) e executar uma recuperação completa com decisões justificadas e evidências. O foco aqui não é “aprender conceitos do zero”, e sim praticar a execução: escolher pontos de restauração, isolar, restaurar na ordem correta e validar a funcionalidade dentro de metas de RPO/RTO.

O que você vai entregar ao final

• Um registro do incidente (linha do tempo) com evidências.
• Seleção documentada de pontos de restauração (por sistema/dado) e justificativa.
• Execução de isolamento e contenção (checklist preenchido).
• Restauração completa por ordem de dependências (com tempos medidos).
• Validação funcional (testes e resultados).
• Rubrica preenchida (RPO/RTO, testes, credenciais, runbook).
• Revisão das decisões e um plano de melhorias contínuas (lições aprendidas).

Cenário da simulação (laboratório)

Você é responsável por recuperar um ambiente pequeno, mas realista, após um ransomware que criptografou servidores e tentou sabotar o ambiente de backup.

Arquitetura do cenário

• AD/DNS: 1 controlador de domínio (DC1).
• Aplicação: 1 servidor de aplicação (APP1) que depende de AD/DNS.
• Banco de dados: 1 servidor (DB1) usado pelo APP1.
• Arquivos: 1 servidor de arquivos (FS1) com compartilhamentos críticos.
• Backup: 1 servidor/proxy de backup (BKP1) e um repositório com retenção protegida/imutável (REPO1).
• Clientes: 2 estações (PC1, PC2) para simular impacto no usuário.

Premissas do ataque

• O ransomware criptografou volumes de APP1, DB1 e FS1.
• Houve tentativa de apagar snapshots/versões locais e excluir jobs/restore points no BKP1.
• Algumas credenciais podem ter sido expostas (por exemplo, conta de serviço usada por agentes).
• Você ainda tem acesso ao REPO1 com pontos de restauração protegidos.

Metas do exercício (defina antes de começar)

Defina metas numéricas para medir sucesso. Exemplo (ajuste ao seu laboratório):

• RPO: FS1 até 4 horas; DB1 até 1 hora; APP1 até 4 horas.
• RTO: serviços essenciais (AD/DNS) até 1 hora; APP+DB até 4 horas; arquivos críticos até 6 horas.

Registre essas metas no seu runbook do exercício, pois elas serão usadas na rubrica de avaliação.

Materiais e evidências exigidas

Durante a simulação, colete evidências mínimas para auditoria e aprendizado. Use uma pasta “EVIDENCIAS-INCIDENTE” (fora do ambiente comprometido) e salve:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Capturas de tela/exports de alertas (detecção de criptografia, falhas de backup, tentativas de exclusão).
• Logs do backup (tentativas de deleção, falhas, auditoria de acesso).
• Lista de sistemas afetados e horário estimado do início (T0).
• Decisões de restauração (qual ponto, por quê, e risco assumido).
• Tempos: início/fim de cada etapa (para medir RTO).
• Resultados de testes (funcionais e integridade).

Exercício prático: passo a passo (com checkpoints)

Passo 1 — Triagem e inventário rápido do impacto (15–30 min)

Objetivo: confirmar escopo, priorizar e evitar decisões “no escuro”.

• Liste ativos e estado: DC1, APP1, DB1, FS1, BKP1, REPO1, PC1/PC2.
• Identifique sintomas: extensões alteradas, notas de resgate, serviços parados, CPU/disco anormal.
• Marque o que está criptografado, o que está suspeito e o que parece íntegro.
• Defina um “T0” (horário aproximado do início) com base em logs/alertas.

Checkpoint de evidência: uma tabela simples com status e observações.

Passo 2 — Contenção e isolamento (30–60 min)

Objetivo: interromper propagação e impedir que o atacante continue destruindo evidências e backups.

• Isole APP1/DB1/FS1 da rede (quarentena): desabilite NIC, mova para VLAN de isolamento ou aplique regras de firewall.
• Bloqueie comunicações laterais suspeitas (SMB/RDP/WinRM) entre servidores comprometidos.
• Congele mudanças no BKP1: remova acesso administrativo amplo, limite logins, preserve logs.
• Se houver suspeita de comprometimento de credenciais: inicie procedimento de troca/rotação (contas de serviço e administrativas) conforme seu runbook.

Checkpoint de evidência: registro do que foi isolado, quando e como (comandos, prints ou tickets).

Exemplo de registro (runbook):
T+00:35 Isolado APP1 via regra FW: bloqueio inbound/outbound exceto console.
T+00:42 Isolado DB1 (NIC desabilitada no hypervisor).
T+00:50 Bloqueado acesso RDP a FS1 (exceto jump host).

Passo 3 — Verificação de sabotagem no backup e preservação do “cofre” (30–60 min)

Objetivo: confirmar que você tem pontos de restauração utilizáveis e que o repositório não foi adulterado.

• Verifique tentativas de exclusão de jobs, catálogos, restore points e alterações de retenção.
• Confirme que o REPO1 mantém pontos protegidos (imutáveis/WORM) no período necessário para RPO.
• Se o BKP1 estiver suspeito, planeje operar a restauração a partir de um host limpo/jump host e com credenciais mínimas.

Checkpoint de evidência: export de auditoria/relatório do backup mostrando pontos disponíveis e tentativas de deleção.

Passo 4 — Seleção dos pontos de restauração (decisão guiada)

Objetivo: escolher “cópias limpas” com base em sinais de comprometimento e no RPO.

Critérios práticos para escolher o ponto

• Janela de infecção: selecione um ponto anterior ao T0 com margem (ex.: 2–6 horas antes, conforme sinais).
• Consistência: para DB1, prefira ponto consistente (app-aware) e valide logs/estado.
• Coerência entre camadas: APP1 e DB1 devem estar alinhados para evitar incompatibilidade de schema/config.
• Risco aceito: se o RPO exigir ponto muito próximo de T0, documente o risco de reinfecção.

Atividade: preencha a matriz de decisão abaixo para cada componente.

Passo 5 — Definição da ordem de restauração (dependências)

Objetivo: restaurar na sequência que reduz retrabalho e acelera retorno do serviço.

Ordem recomendada (ajuste ao seu ambiente)

1. Infra de identidade e nome: DC1 (AD/DNS) ou validar que está íntegro. Se houver dúvida, restaure primeiro.
2. Banco de dados: DB1 (base para APP1).
3. Aplicação: APP1 (aponta para DB1 e depende de AD/DNS).
4. Arquivos: FS1 (dados de usuários/áreas).
5. Clientes: PC1/PC2 (após serviços centrais estáveis).

Checkpoint: um diagrama simples de dependências (pode ser texto) anexado ao runbook.

Dependências:
APP1 -> DB1
APP1 -> AD/DNS (DC1)
FS1 -> AD/DNS (autenticação e permissões)

Passo 6 — Restauração controlada (execução)

Objetivo: restaurar sem reintroduzir o malware e sem abrir o ambiente antes da hora.

6.1 Preparar “zona limpa” para restauração

• Use um jump host limpo para operar o console de backup.
• Garanta que as credenciais usadas para restore sejam de privilégio mínimo e temporárias (quando possível).
• Mantenha sistemas restaurados inicialmente em rede isolada (sem acesso pleno à produção).

6.2 Restaurar DB1

• Restaure o volume/VM do DB1 para uma rede de quarentena.
• Suba o serviço do banco e valide integridade básica (ex.: checagem de consistência, montagem de base).
• Registre tempo total de restore e tempo até “DB pronto”.

Evidência: log do job de restore + print do serviço do banco em execução + resultado do teste de consistência.

6.3 Restaurar APP1

• Restaure APP1 para quarentena.
• Atualize configurações de conexão (se necessário) para apontar para DB1 restaurado.
• Inicie serviços e valide endpoints internos (health checks).

Evidência: health check OK, logs sem erro crítico, tempo até “APP pronto”.

6.4 Restaurar FS1

• Restaure dados/volumes do FS1 para quarentena.
• Valide permissões e acesso (amostras de pastas críticas).
• Faça varredura offline/antimalware antes de reabrir compartilhamentos.

Evidência: amostra de arquivos acessíveis, permissões corretas, relatório de varredura.

6.5 Reintrodução gradual na rede

Somente após validações mínimas, mova DB1/APP1/FS1 da quarentena para a rede de produção (ou reabra fluxos). Faça em etapas, monitorando alertas e comportamento.

• Abra primeiro os fluxos estritamente necessários (ex.: APP1→DB1, clientes→APP1).
• Mantenha bloqueios laterais amplos até estabilização.
• Monitore tentativas de autenticação anômalas e picos de alteração de arquivos.

Validação pós-recuperação (funcional e integridade)

Objetivo: provar que “voltou” de verdade, não apenas que “ligou”.

Checklist de validação mínima

• Identidade: autenticação e resolução DNS funcionando (usuário de teste).
• Aplicação: login, operação principal (criar/consultar registro), logs sem erro crítico.
• Banco: consultas básicas, integridade/consistência, espaço e performance aceitáveis.
• Arquivos: acesso a 10 arquivos amostrados em 3 áreas críticas; permissões corretas; sem arquivos recém-criptografados.
• Backup: capacidade de executar novo backup após incidente (em modo controlado) e registrar sucesso.

Atividade: registre os testes em uma tabela com resultado e evidência.

Rubricas de avaliação (autoavaliação ou avaliação do instrutor)

1) Atendimento a RPO/RTO

2) Evidências de testes e validação

3) Proteção de credenciais durante o incidente

4) Registros do runbook (execução e rastreabilidade)

Revisão das principais decisões (o que justificar no relatório)

Ao final do exercício, revise e registre as decisões que mais impactam tempo, risco e qualidade da recuperação. Use as perguntas abaixo como guia de revisão (sem transformar em “encerramento”, e sim em checklist de análise):

• Como você determinou a janela de infecção (T0)? Quais evidências sustentam?
• Por que escolheu cada ponto de restauração? Qual risco de reinfecção foi aceito?
• Qual foi a ordem de restauração e por quê? Houve retrabalho por dependências?
• Quais controles impediram sabotagem adicional? O que teria acontecido sem isolamento?
• Quais validações provaram funcionalidade? Quais testes faltaram?
• Onde o tempo estourou? Restore, cópia, validação, rede, credenciais, aprovações?

Plano de melhorias contínuas (lições aprendidas → backlog)

Transforme o que ocorreu na simulação em melhorias acionáveis. Crie um backlog com prioridade, esforço e impacto em RPO/RTO.

Modelo de backlog

Itens típicos para considerar (se apareceram no seu exercício)

• Automatizar coleta de logs e geração de relatório do incidente.
• Reduzir dependência de uma única pessoa para executar restores (procedimento e permissões).
• Melhorar tempo de provisionamento de ambiente limpo (jump host, rede de quarentena).
• Aprimorar testes de aplicação (health checks automatizados e dados de teste).
• Revisar tempos reais versus estimados no runbook e ajustar metas/estratégias.
• Padronizar rotação emergencial de credenciais e validação de acessos administrativos.