Preservação de evidências em incidentes cibernéticos: como não “apagar a cena do crime” sem querer

Tempo de leitura: 11 minutos

Incidente cibernético não é só “TI com problema”. Em muitos casos, é fraude, extorsão, vazamento de dados, sabotagem, violação de privacidade e até risco físico (ex.: invasão de câmeras, controle de acesso, perseguição a colaboradores). Quando algo acontece, a empresa costuma correr para “voltar ao normal” — e é aí que mora o perigo: na pressa, muita evidência é destruída.

Preservar evidências significa manter, coletar e documentar informações digitais (e às vezes físicas) de forma íntegra e rastreável, permitindo:

  • ✅ Entender o que ocorreu (vetor de ataque, impacto real, persistência)
  • ✅ Conter e erradicar com precisão (sem “remédio errado”)
  • ✅ Apoiar decisões legais e regulatórias (LGPD/ANPD, contratos, seguros)
  • ✅ Sustentar investigações internas e criminais (quando aplicável)
  • ✅ Reduzir reincidência (lições aprendidas com base em fatos)

Em termos simples: preservação de evidência é o equivalente corporativo a isolar o local, não mexer nos objetos e registrar tudo — só que no mundo digital.

1) O que é “evidência” em cibersegurança (na prática)

Evidência não é apenas “o arquivo malicioso”. Em empresas, normalmente inclui:

🧾 Evidências técnicas

  • Logs de firewall, proxy, EDR/antivírus, SIEM, DNS, AD/LDAP, VPN
  • Logs e trilhas de auditoria em nuvem (Microsoft 365, Google Workspace, AWS/Azure/GCP)
  • E-mails (com cabeçalhos), mensagens, tickets, registros de alterações
  • Imagens de disco (ou snapshots), hashes e artefatos do sistema
  • Memória RAM (quando viável), conexões de rede, processos em execução
  • Amostras de malware e indicadores (IOCs)

🏢 Evidências administrativas e de negócio

  • Linha do tempo do que foi percebido e feito (quem, quando, por quê)
  • Aprovações, comunicações, decisões de contenção
  • Relatórios do SOC/fornecedor, ocorrências do suporte, chamados

🧍 Evidências humanas e físicas (sim, isso conta)

  • Depoimentos internos (anotações de entrevista)
  • CFTV, controle de acesso, registros de entrada/saída
  • Equipamentos apreendidos (notebooks, celulares corporativos, tokens)

2) Por que a preservação falha (e como isso prejudica a empresa)

Erros comuns que “contaminam” evidências:

  • Formatar máquina ou “reinstalar para resolver”
  • Reiniciar servidor sem coletar dados voláteis (processos/conexões)
  • Rodar ferramentas não padronizadas que alteram arquivos e timestamps
  • Usar a conta comprometida para “investigar”
  • Não sincronizar horário (sem NTP, a linha do tempo vira um quebra-cabeça sem borda)
  • Não registrar cadeia de custódia (quem teve posse do quê e quando)

Impactos típicos:

  • Perda do vetor inicial (phishing? credencial vazada? RDP exposto?)
  • Impossibilidade de provar autoria, extensão do dano ou negligência/boa-fé
  • Dificuldade para acionar seguro cibernético e suportar medidas judiciais
  • Multas, litígios e dano reputacional por resposta mal documentada

3) Princípios essenciais: integridade, rastreabilidade e mínimo impacto

Uma preservação bem-feita se apoia em 5 princípios:

  1. Integridade: garantir que o dado não foi alterado (uso de hashes, cópias forenses quando necessário).
  2. Rastreabilidade (cadeia de custódia): registrar quem coletou, onde estava, como foi guardado e quem acessou.
  3. Reprodutibilidade: outro analista deve conseguir validar o mesmo achado com o mesmo material.
  4. Proporcionalidade: coletar o necessário sem paralisar a empresa indevidamente.
  5. Segurança: evidência é sensível; precisa de controle de acesso, criptografia e armazenamento adequado.

4) Antes do incidente: prevenção que torna a evidência “existente e utilizável”

Preservação começa antes do problema. Se não há logs, não há história confiável.

🛡️ 4.1 Política de logs (o “CFTV” do digital)

  • Defina o que logar, por quanto tempo e onde centralizar (ex.: SIEM ou repositório imutável).
  • Garanta sincronização de horário (NTP) em servidores, endpoints, rede e cloud.
  • Proteja logs contra alteração (WORM/imutabilidade quando possível).
  • Estabeleça retenção compatível com riscos, contratos e exigências internas.

Mínimo recomendado (alto valor investigativo):

  • Autenticação (AD/IdP), VPN, e-mail, endpoints (EDR), firewall, DNS, aplicações críticas, cloud audit logs.

🔐 4.2 Prontidão forense (“forensic readiness”)

  • Procedimentos escritos para coleta básica (sem improviso).
  • Contas de emergência (“break-glass”) bem protegidas para resposta.
  • Inventário de ativos e criticidade (sem isso você “investiga no escuro”).
  • Backups testados + estratégia contra ransomware (offline/imutável quando possível).

🧰 4.3 Treinamento e papéis

Defina (e treine) quem faz o quê:

  • TI / Segurança (contenção e coleta)
  • Jurídico (preservação, legal hold, interface com autoridades quando aplicável)
  • DPO/Privacidade (LGPD e comunicação de incidentes)
  • RH (quando há suspeita de insider)
  • Comunicação (mensagens internas/externas para reduzir boatos e golpes secundários)

5) No momento do incidente: o que fazer (e o que NÃO fazer)

⛔ O que NÃO fazer (primeiros minutos)

  • Não formatar, não “limpar”, não sair apagando e-mails e arquivos “suspeitos”.
  • Não reiniciar sistemas críticos sem avaliar coleta de dados voláteis.
  • Não usar a mesma máquina comprometida para investigar com sua conta administrativa.
  • Não compartilhar prints e dados do incidente em grupos informais.

✅ O que fazer (sequência prática)

Abaixo um roteiro aplicável para a maioria dos cenários (ransomware, fraude de e-mail, invasão de conta, vazamento):

1) Estabilize e contenha sem destruir evidência

  • Isole o ativo suspeito da rede (quando possível), preservando o estado.
  • Em ambientes virtuais/cloud: priorize snapshot e captura de trilhas de auditoria.
  • Se o incidente estiver em andamento (exfiltração): avalie bloqueios no perímetro (firewall/IdP) com registro das mudanças.

2) Registre tudo (log do incidente)

Crie um “diário” com:

  • Horário (com fuso), quem identificou, sintomas, sistemas afetados
  • Ações tomadas, comandos executados, mudanças de regras
  • Evidências coletadas e onde foram armazenadas

3) Preserve o essencial (triagem)

Colete, conforme aplicável:

  • Logs centralizados e do período (antes/durante/depois)
  • Identidades: logins, alterações de MFA, resets de senha, criação de usuários
  • E-mails suspeitos com cabeçalho completo
  • Artefatos do endpoint (alertas EDR, processos, conexões)
  • Indicadores: IPs, domínios, hashes, URLs, nomes de arquivos

4) Ative cadeia de custódia

Para cada item:

  • Identificador do item (ID)
  • Descrição
  • Origem (host, conta, pasta, sistema)
  • Data/hora de coleta
  • Responsável pela coleta
  • Método/ferramenta
  • Hash (quando aplicável)
  • Local de armazenamento (cripto + controle de acesso)
  • Histórico de acesso/transferências

6) Coleta e preservação: exemplos práticos por tipo de incidente

🧨 6.1 Ransomware em servidor/estação

Objetivo: entender vetor inicial, extensão e persistência.

Preservar:

  • Amostras da nota de resgate e arquivos criptografados (sem alterar)
  • Logs do EDR/antivírus e eventos do sistema
  • Logs de autenticação (AD/IdP), especialmente privilégios elevados
  • Conexões remotas (RDP/VPN), criação de contas e alterações de GPO
  • Snapshots de VMs, se disponíveis

Evite:

  • Restaurar backup “por cima” sem guardar cópias do estado original
  • Desligar tudo de forma indiscriminada (pode perder rastros úteis)

📩 6.2 Comprometimento de e-mail corporativo (BEC / falso fornecedor)

Objetivo: provar fraude, identificar regra maliciosa e contas afetadas.

Preservar:

  • Mensagens fraudulentas e respostas (incluindo cabeçalhos)
  • Regras de encaminhamento/caixa postal, delegações, acessos
  • Logs do provedor (M365/Google): logins, MFA, dispositivos
  • Evidência de alteração de dados bancários e trilha de aprovação interna

Ação de contenção com preservação:

  • Reset de senha + revogação de sessões após exportar/registrar evidências relevantes
  • Remoção de regras maliciosas documentando o “antes e depois”

🕵️ 6.3 Vazamento de dados por insider (funcionário/terceirizado)

Objetivo: determinar o que saiu, como saiu e se houve violação de política.

Preservar:

  • Logs de acesso a pastas, repositórios, CRM/ERP
  • Movimentação de arquivos (DLP, EDR, auditoria de arquivos)
  • Dispositivos corporativos (com procedimento e autorização interna adequada)
  • E-mails, chats corporativos, tickets e autorizações

Atenção:

  • Envolva Jurídico e RH cedo: isso vira disputa trabalhista e/ou criminal com facilidade.

7) Nuvem e SaaS: evidência some rápido (e é aí que mora o “apagão”)

Em Microsoft 365/Google Workspace e clouds:

  • Trilhas de auditoria podem ter retenção limitada dependendo do licenciamento e configuração.
  • Ataques criam regras de encaminhamento, OAuth apps maliciosos, tokens persistentes.

Boas práticas:

  • Ativar e revisar auditoria e alertas
  • Exportar logs relevantes rapidamente quando houver incidente
  • Proteger contas administrativas com MFA forte e contas “break-glass”

8) LGPD, ANPD e governança: preservação também é conformidade

Quando há possibilidade de incidente com dados pessoais, a empresa precisa:

  • Avaliar impacto e risco aos titulares
  • Documentar decisões (o “por que” e “o que foi feito”)
  • Manter evidências para auditoria, investigação e prestação de contas (accountability)

Importante: preservação não significa “guardar tudo para sempre”. Significa guardar o necessário, com base legal, segurança e controle, e por tempo compatível com obrigações e riscos.

9) Kit rápido: modelo de procedimento (simples e eficaz)

📌 Política interna mínima (1 página)

  • Objetivo: preservar evidências de incidentes
  • Escopo: sistemas críticos, e-mail, endpoints, cloud, rede
  • Autoridades: quem autoriza coleta, quem acessa evidências
  • Armazenamento: repositório seguro, criptografado, com logs de acesso
  • Cadeia de custódia: formulário padrão
  • Retenção: prazos (ex.: 90/180/365 dias conforme criticidade)
  • Acionamento: quando chamar jurídico, DPO, fornecedor, seguro, autoridade

🧾 Campos do “Registro de Evidências”

  • ID | Tipo | Sistema | Período | Coletor | Método | Hash | Local | Observações

10) Conclusão: responder rápido é bom — responder certo é melhor

Empresas que lidam bem com incidentes não são as que “nunca tiveram problema”; são as que conseguem provar o que aconteceu, conter sem destruir rastros, recuperar com segurança e aprender sem achismo. Preservação de evidências é o alicerce disso tudo.

Se a sua organização já tem antivírus e firewall, ótimo — mas sem políticas de logs, cadeia de custódia e um roteiro de resposta, é como ter câmera na porta… desligada.

Links úteis e recursos para aprofundamento

📚 Guias e cartilhas (referências nacionais)

  • CERT.br (Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil) — conteúdos e recomendações:
    https://www.cert.br/
  • Cartilha de Segurança para Internet (CERT.br/NIC.br) — base excelente para políticas e resposta a incidentes:
    https://cartilha.cert.br/
  • NIC.br — materiais e iniciativas sobre segurança e infraestrutura da Internet no Brasil:
    https://www.nic.br/

🏛️ Privacidade e incidentes com dados pessoais (LGPD)

  • ANPD (Autoridade Nacional de Proteção de Dados) — orientações e publicações (inclui temas de incidentes de segurança):
    https://www.gov.br/anpd/pt-br

🧾 Registro de ocorrência e apoio institucional (quando aplicável)

🔐 Boas práticas de segurança para ambientes corporativos

  • CGI.br (Comitê Gestor da Internet no Brasil) — publicações e referências do ecossistema brasileiro:
    https://cgi.br/

Recursos adicionais (internacionais, técnicos — para aprofundar metodologia)

(Úteis para padronizar procedimentos e linguagem técnica; apesar de não serem brasileiros, são muito usados em perícia e resposta a incidentes.)

Observação responsável: este conteúdo é educacional e não substitui assessoria jurídica, perícia especializada ou orientação formal do seu time de privacidade/compliance em casos reais — especialmente quando houver dados pessoais, extorsão, fraude financeira ou risco a pessoas.