Backup e Recuperação contra Ransomware: plano de recuperação (runbook) para incidente real

O que é um runbook de recuperação (e por que ele precisa ser “acionável”)

Runbook de recuperação é um documento operacional que transforma uma estratégia de backup e recuperação em ações executáveis durante um incidente real de ransomware. Ele define gatilhos de ativação, papéis e responsabilidades, ordem de restauração por dependências, decisões críticas e comunicações internas, com checklists e critérios objetivos para reduzir improviso e evitar reinfecção.

Um runbook “acionável” tem três características: (1) passos curtos e verificáveis (quem faz, como faz, onde registra), (2) pontos de decisão com critérios claros (ex.: “isolar agora?” “pausar backups?”), e (3) artefatos prontos (modelos de mensagens, checklists, quadros de status, formulários de evidência).

Gatilhos de ativação e níveis de severidade

Gatilhos típicos para ativar o runbook

• Alerta de EDR/SIEM indicando criptografia em massa, comportamento de ransomware, exclusão de shadow copies, ou execução de ferramentas de exfiltração.
• Indícios no ambiente de backup: falhas súbitas e generalizadas, aumento anormal de taxa de alteração, tentativas de apagar snapshots/retention, criação de jobs suspeitos.
• Usuários reportando arquivos com extensão alterada, notas de resgate, indisponibilidade de sistemas.
• Detecção de credenciais comprometidas (contas privilegiadas, contas de serviço, chaves de API) associadas a movimentação lateral.

Classificação rápida (exemplo de severidade)

Defina no runbook: quem pode declarar SEV-1 (ex.: líder de Segurança ou Plantonista), tempo máximo para escalonamento e canal oficial para registrar a decisão.

Papéis e responsabilidades (RACI enxuto para incidente)

Evite organogramas longos. Use um RACI mínimo com substitutos (backup) para cada função.

Inclua no runbook: contatos 24x7, canal alternativo (fora do e-mail corporativo), e regra de “uma fonte de verdade” para status (ex.: documento/board de crise).

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

Fluxo operacional do runbook (modelo em 5 fases)

Visão geral do fluxo

Detecção → Triagem → Contenção → Recuperação → Validação → Retorno à operação

O runbook deve permitir executar fases em paralelo (ex.: contenção e preparação de recuperação), mas com gates claros antes de reabrir acesso.

Fase 1 — Triagem (confirmar, delimitar, decidir rápido)

Objetivos

• Confirmar se é ransomware (ou evento similar).
• Determinar escopo inicial: quais redes, identidades, sistemas, backups foram tocados.
• Definir severidade e acionar sala de crise.

Passo a passo prático

• 1) Abrir incidente e iniciar timeline: horário, quem detectou, sintomas, sistemas afetados.
• 2) Coletar sinais mínimos (sem “limpar” nada): nomes de hosts, usuários, hashes/nomes de arquivos suspeitos, notas de resgate, logs de autenticação recentes.
• 3) Checar propagação: amostrar endpoints/servidores por indicadores (processos, tarefas agendadas, serviços novos, conexões anômalas).
• 4) Verificar integridade do plano de recuperação: confirmar se repositórios de backup, consoles e credenciais de backup não foram alterados (somente leitura quando possível).
• 5) Decisão inicial: SEV-1/2/3 e escopo de contenção (isolamento seletivo vs. amplo).

Decisão crítica: quando isolar sistemas

Isolar imediatamente (rede/segmento/host) quando houver: (a) criptografia ativa, (b) evidência de movimentação lateral, (c) credenciais privilegiadas comprometidas, (d) comunicação com C2, (e) tentativa de atingir infraestrutura de backup/identidade.

Isolamento deve priorizar: identidade (controladores/IdP), plataforma de gestão (hipervisores, orquestradores), backup (servidores/proxies/repositórios), e saltos administrativos (jump servers).

Decisão crítica: quando pausar backups

Pausar backups (ou colocar em modo controlado) quando houver risco de contaminar pontos de restauração ou propagar criptografia via agentes/credenciais comprometidas. Critérios práticos:

• Backups estão capturando dados já criptografados (picos de alteração, dedupe/compressão anômala, muitos arquivos renomeados).
• Suspeita de comprometimento de contas de serviço usadas por jobs.
• Atividade suspeita no console de backup (criação/edição de jobs, exclusão de retenção, tentativas de apagar repositórios).

Como pausar sem perder evidência: registre horário, jobs ativos, estado dos repositórios, e preserve logs do sistema de backup em cópia protegida (somente leitura).

Fase 2 — Contenção (parar a hemorragia sem destruir evidências)

Objetivos

• Interromper criptografia/exfiltração e reduzir superfície de ataque.
• Preservar evidências para investigação e para evitar reinfecção.
• Preparar ambiente limpo para recuperação.

Passo a passo prático

• 1) Isolamento em camadas: bloquear tráfego leste-oeste suspeito, desabilitar compartilhamentos amplos, restringir RDP/SSH, cortar acesso de contas suspeitas.
• 2) Congelar mudanças: suspender deploys, mudanças de rede, automações e tarefas agendadas não essenciais.
• 3) Rotação emergencial de credenciais: priorizar contas privilegiadas, contas de serviço de backup, chaves de API e tokens de automação.
• 4) Preservação de evidências: coletar imagens/artefatos de hosts-chave (quando possível), exportar logs (EDR, AD/IdP, firewall, proxy, backup), e registrar hashes de arquivos relevantes.
• 5) Definir “zona limpa”: uma rede/ambiente separado para restore e validação, com acesso administrativo restrito e monitorado.

Como preservar evidências (mínimo viável)

• Não reinstalar/formatar antes de coletar o essencial (quando o tempo permitir).
• Copiar logs para repositório protegido (WORM/imutável, ou storage com controle estrito).
• Registrar: horário de isolamento, regras aplicadas, contas desabilitadas, e alterações de firewall.

Fase 3 — Recuperação (restaurar na ordem certa, com critérios de segurança)

Princípio: restaurar por dependências

Em ransomware, restaurar “o que é mais importante” sem dependências costuma falhar. O runbook deve trazer uma ordem padrão que você ajusta ao seu ambiente.

Ordem de restauração sugerida (exemplo genérico)

1. Identidade e controle de acesso: AD/IdP, DNS, NTP, MFA, PKI (se aplicável).
2. Rede e segurança: firewalls, VPN, bastions/jump servers, ferramentas de gestão de endpoints.
3. Plataforma: hipervisores, storage, clusters, orquestração, repositórios de imagens (se necessários para subir serviços).
4. Serviços compartilhados: e-mail interno (se usado para operação), mensageria, filas, cache, service discovery.
5. Bancos de dados: primeiro metadados/configs, depois dados; respeitar consistência e logs.
6. Aplicações: serviços core, integrações, por último front-ends e sistemas periféricos.
7. Arquivos e colaboração: file servers, shares departamentais, repositórios de documentos.

No runbook, para cada item acima, liste: pré-requisitos, fonte do restore, tempo estimado, responsável e teste de validação.

Decisão crítica: como escolher o ponto de restauração

Escolher o ponto de restauração é um equilíbrio entre perda aceitável de dados e risco de reinfecção. Critérios práticos para seleção:

• Momento de comprometimento estimado: use a timeline (primeiro alerta, primeiro host afetado, primeira credencial usada) e escolha um ponto anterior com margem.
• Indicadores de comprometimento: se houver IOC em um período, evite pontos dentro dessa janela.
• Validação rápida: antes de restaurar em larga escala, restaurar amostras em zona limpa e executar varreduras/checagens (EDR/antimalware, integridade de binários, revisão de contas e tarefas).
• Consistência de aplicações: para bancos e sistemas transacionais, alinhar restore de app + DB + integrações no mesmo “corte” temporal quando necessário.

Inclua no runbook um campo obrigatório: “Justificativa do restore point escolhido” (quem aprovou e com base em quais evidências).

Decisão crítica: restaurar in-place vs. restore para ambiente limpo

• Preferir ambiente limpo quando houver dúvida sobre persistência (backdoors, contas criadas, GPO maliciosa, scripts de inicialização).
• In-place só quando o escopo estiver claramente contido e houver alta confiança na erradicação, com monitoramento reforçado.

Como evitar reinfecção durante a recuperação

• Controle de acesso mínimo: apenas contas nominativas, MFA obrigatório, sem credenciais compartilhadas.
• Bloqueio de egress: permitir saída apenas para destinos necessários (atualizações, repositórios internos), com inspeção.
• Revisão de persistência: tarefas agendadas, serviços, chaves de registro, scripts de logon, GPO, contas recém-criadas, chaves SSH.
• Higiene de imagens: usar imagens “golden” verificadas para reconstrução de servidores/VDIs quando aplicável.
• Monitoramento intensivo: alertas para criação de contas, elevação de privilégio, alterações de políticas, picos de I/O e renomeação massiva.

Fase 4 — Validação (provar que voltou e que está limpo o suficiente)

Objetivos

• Confirmar integridade técnica (serviços, dados, performance).
• Confirmar critérios mínimos de segurança (sem sinais de persistência).
• Obter aceite do dono do sistema.

Checklist de validação por sistema (template)

• Disponibilidade: serviço sobe, health checks OK, portas esperadas abertas.
• Funcional: fluxos críticos testados (login, transação, relatório, integração).
• Dados: contagens/amostras, consistência, últimos registros esperados até o ponto de corte.
• Segurança: varredura EDR/AV sem detecções, contas e privilégios revisados, sem tarefas/serviços suspeitos.
• Logs: geração e envio de logs normalizados para SIEM; alertas habilitados.
• Backup pós-restore: somente após validação, reabilitar rotinas de backup com janela controlada.

Inclua um campo de aceite: App Owner: GO/NO-GO com data/hora e observações.

Fase 5 — Retorno à operação (reabrir com controle)

Passo a passo prático

• 1) Reintrodução gradual: liberar acesso por grupos (TI → usuários-chave → geral), com monitoramento.
• 2) Reativar integrações em ordem (internas antes de externas), validando filas e retries.
• 3) Reabilitar backups com política de “primeiro backup pós-incidente” monitorada (taxa de alteração, volumes, erros).
• 4) Regras temporárias: manter bloqueios de egress e restrições administrativas por período definido.

Comunicações internas: o que dizer, quando dizer, e por qual canal

Princípios

• Um canal oficial (fora do e-mail se ele estiver afetado): chat corporativo alternativo, telefone, bridge.
• Cadência: atualizações curtas em intervalos fixos (ex.: a cada 30–60 min em SEV-1).
• Sem detalhes sensíveis: evitar IOCs e informações que ajudem o atacante em canais amplos.

Modelos de mensagens (templates)

Template 1 — Alerta inicial (para liderança e TI)

Assunto: Incidente SEV-1 em andamento – possível ransomware (em investigação)  Hora: [HH:MM]  Impacto: [sistemas/serviços afetados]  Ações em curso: contenção e preservação de evidências  Próxima atualização: [HH:MM]  Canal oficial: [link/bridge]  IC: [nome]  Segurança/IR: [nome]

Template 2 — Orientação para colaboradores

Estamos tratando uma indisponibilidade de sistemas. Por precaução: 1) não conecte VPN se não for necessário; 2) não abra anexos/links suspeitos; 3) mantenha o computador ligado e conectado; 4) reporte comportamentos anormais para [canal]. Atualizações serão publicadas em [canal] a cada [intervalo].

Template 3 — Status de recuperação (para stakeholders)

Status: [Contenção/Recuperação/Validação]  Serviços restaurados: [lista]  Serviços em progresso: [lista + ETA]  Riscos/pendências: [itens]  Decisões necessárias: [itens + responsável]  Próxima atualização: [HH:MM]

Modelos de fluxos (para colocar no runbook)

Fluxo A — Triagem (10–30 minutos)

Alerta → Confirmar sinais → Definir SEV → Acionar sala de crise → Delimitar escopo inicial → Decidir isolamento e pausa de backups

Fluxo B — Contenção (paralelo à triagem)

Isolar segmentos/hosts → Desabilitar contas suspeitas → Bloquear egress → Preservar logs/evidências → Definir zona limpa

Fluxo C — Recuperação (por ondas)

Escolher restore point → Restaurar identidade → Restaurar plataforma → Restaurar dados/apps por dependência → Validar cada onda → Expandir acesso

Fluxo D — Validação e retorno

Testes técnicos → Testes funcionais → Checagens de segurança → GO/NO-GO do App Owner → Reabrir gradualmente → Reativar backups controlados

Templates de checklist para sala de crise

Checklist 1 — Abertura do incidente (IC + Scribe)

• ID do incidente: ____
• Hora de início (UTC/local): ____
• Severidade declarada: ____ (quem declarou: ____)
• Canal oficial e bridge: ____
• Participantes e papéis (IC/IR/Infra/Backup/App Owners): ____
• Escopo inicial (sistemas/segmentos): ____
• Decisões iniciais registradas (isolar? pausar backups?): ____

Checklist 2 — Contenção (Segurança + Infra)

• Hosts/segmentos isolados (lista + horário): ____
• Contas desabilitadas/resetadas (lista + horário): ____
• Bloqueios de egress aplicados (regras + horário): ____
• Ferramentas de administração remota restritas (RDP/SSH): ____
• Preservação de logs concluída (fontes + local): ____
• Ambiente/zona limpa definida e acessos concedidos: ____

Checklist 3 — Backup e restore (Líder de Backup/DR)

• Estado do ambiente de backup verificado (alterações suspeitas?): ____
• Backups pausados/controle aplicado (quando e como): ____
• Restore point candidato (data/hora): ____
• Justificativa do restore point (evidências): ____
• Restore de amostra em zona limpa executado e verificado: ____
• Ordem de restauração aprovada (dependências): ____
• Restaurações em andamento (onda 1/2/3): ____

Checklist 4 — Validação e aceite (App Owner + Segurança)

• Testes funcionais executados (casos críticos): ____
• Verificações de integridade/dados (amostras/contagens): ____
• Varredura EDR/AV pós-restore: ____
• Revisão de contas/privilégios/persistência: ____
• Logs e monitoramento ativos: ____
• GO/NO-GO do App Owner (assinatura/horário): ____

Checklist 5 — Comunicação e governança (Comms + IC)

• Mensagem inicial enviada (hora/canal): ____
• Cadência de updates definida: ____
• Status atual publicado (hora): ____
• Instruções para usuários (o que fazer/não fazer): ____
• Registro de decisões e mudanças mantido atualizado: ____

Decisões críticas resumidas (para colocar como “cartão” no runbook)