Seguranca

Primeiras 24 horas de um incidente de segurança: o que fazer na ordem

Publicado em 08 de setembro de 2026 | 8 min de leitura

Por que a ordem importa mais que a velocidade

Quando um ataque é detectado, o instinto natural de qualquer equipe técnica é agir imediatamente para restaurar o serviço. Servidor criptografado por ransomware? Restaura o backup. Conta comprometida? Troca a senha. Máquina infectada? Formata. Esse instinto é compreensível — a pressão comercial é real e cada hora parada custa dinheiro. Mas agir fora de ordem nas primeiras horas é a principal causa de incidentes que se repetem duas semanas depois, com o mesmo vetor de entrada intacto.

A resposta a incidente tem uma sequência consagrada por décadas de prática forense: conter, preservar evidência, comunicar, erradicar e só então restaurar. Invertê-la significa, na prática, destruir a única chance de descobrir como o invasor entrou. Um servidor formatado às pressas leva embora os logs de acesso, os artefatos deixados pelo atacante e a linha do tempo da invasão. Sem isso, a empresa restaura o ambiente exatamente como estava — inclusive com a vulnerabilidade que permitiu o ataque.

Há também um componente jurídico que muita gente descobre tarde demais. A LGPD estabelece prazo para comunicação à ANPD e aos titulares em caso de incidente com dados pessoais, e a empresa precisa ser capaz de demonstrar o que aconteceu, quando, quais dados foram afetados e quais medidas foram tomadas. Uma resposta improvisada, sem registro do que foi feito e quando, transforma um problema técnico em exposição regulatória e contratual.

Hora 0 a 2: detectar e conter sem destruir

As duas primeiras horas definem o tamanho do estrago. O objetivo aqui é único: impedir que o incidente se espalhe. Contenção não é o mesmo que erradicação — não se trata de eliminar o invasor ainda, apenas de limitar o raio de alcance. Isolamento de rede é a ferramenta principal: desconectar o host comprometido do switch, bloquear a VLAN afetada no firewall, revogar sessões ativas no Microsoft 365 ou no Entra ID.

Existe uma distinção crítica que separa uma resposta competente de uma amadora: isolar não é desligar. Uma máquina desligada perde toda a memória RAM, e é justamente na memória que ficam as chaves de criptografia usadas pelo ransomware, os processos maliciosos em execução, as conexões de rede ativas com o servidor de comando e controle do atacante. Em vários casos documentados de ransomware, a chave de descriptografia foi recuperada de um dump de memória de uma máquina que foi isolada, mas não desligada.

  1. Identificar o escopo inicial: quais máquinas, contas e serviços apresentam comportamento anômalo
  2. Isolar em nível de rede — cabo, porta do switch ou regra de firewall — mantendo os equipamentos ligados
  3. Revogar tokens e sessões de contas suspeitas no diretório de identidade
  4. Bloquear a exfiltração: cortar saída para IPs e domínios suspeitos na borda
  5. Suspender rotinas automatizadas que possam propagar o dano — sincronizações de nuvem, replicação e, principalmente, jobs de backup

Esse último item merece destaque. Backups que rodam durante um incidente ativo podem sobrescrever cópias limpas com dados já criptografados ou adulterados. Pausar imediatamente as rotinas de backup e proteger os repositórios existentes — de preferência com imutabilidade ou cópia offline — costuma ser a diferença entre restaurar em oito horas e negociar com criminosos.

Regra prática: isole a máquina da rede, mas mantenha ligada. Memória volátil é evidência que não volta. Desligar é uma decisão que só se toma depois de coletar.

Hora 2 a 6: preservar evidência e montar a linha do tempo

Com o incidente contido, começa o trabalho de entender o que aconteceu. Preservação de evidência não é burocracia — é o que permite responder às três perguntas que todo cliente, seguradora e órgão regulador vai fazer: como entraram, o que acessaram e se ainda estão dentro. Sem evidência preservada nas primeiras horas, essas perguntas ficam sem resposta e a empresa fica sem defesa.

A coleta deve seguir a ordem de volatilidade: o que se perde primeiro se coleta primeiro. Memória RAM, conexões de rede ativas e processos em execução vêm antes de disco. Depois, imagens forenses dos discos afetados, feitas em cópia — nunca trabalhar no original. Logs de firewall, VPN, servidor de e-mail, controlador de domínio, EDR e provedor de nuvem devem ser exportados e guardados em local separado, porque muitos sistemas têm retenção curta e sobrescrevem em dias.

Paralelamente à coleta técnica, alguém precisa manter um registro cronológico do próprio atendimento: que horas o alerta chegou, quem foi acionado, qual ação foi tomada em cada momento e por quem. Esse log de resposta parece detalhe operacional, mas é exatamente o documento que sustenta a posição da empresa perante a ANPD, a seguradora cibernética e eventuais contratos com cláusula de segurança. Uma planilha compartilhada com carimbo de horário resolve — o importante é existir e ser preenchida em tempo real, não reconstruída de memória três dias depois.

Hora 6 a 12: comunicar com clareza e sem improviso

Comunicação mal feita amplia o dano. Silêncio absoluto gera boato interno e vazamento descontrolado para fora; comunicação apressada e imprecisa gera retratação constrangedora depois. O caminho é comunicar cedo, mas comunicar apenas o que está confirmado, deixando explícito o que ainda está sendo apurado.

Cada público precisa de uma mensagem diferente. A diretoria precisa saber impacto operacional, prazo estimado de retomada e exposição jurídica. As equipes internas precisam de instruções concretas: não desligar máquinas, não tentar restaurar nada por conta própria, não abrir anexos, canal único para reportar comportamento estranho. Clientes e parceiros afetados precisam de um comunicado factual e sóbrio. E, quando há dados pessoais envolvidos, entra o dever legal de notificação previsto na LGPD, com prazo e conteúdo mínimo definidos pela ANPD.

Uma decisão delicada dessa fase é o acionamento de terceiros: seguradora cibernética — que costuma exigir notificação em prazo curto sob pena de perda de cobertura —, assessoria jurídica e, dependendo da gravidade, autoridade policial. Vale registrar também que qualquer contato do atacante, em caso de ransomware, deve ser tratado exclusivamente por quem foi designado para isso. Negociação improvisada por um técnico ansioso já custou caro a muita empresa.

Comunique o que sabe, admita o que ainda não sabe e diga quando vai atualizar. Prometer certeza que não existe é o erro mais comum das primeiras horas.

Hora 12 a 24: erradicar e restaurar na ordem certa

Só agora — com contenção feita, evidência preservada e comunicação em curso — faz sentido falar em restauração. E o pré-requisito é a erradicação: eliminar a presença do atacante e fechar o vetor de entrada. Restaurar antes de erradicar é reinfectar. É comum que o invasor tenha estabelecido persistência em mais de um ponto: uma conta de serviço criada, uma tarefa agendada, uma regra de encaminhamento de e-mail, uma chave SSH adicionada, um aplicativo com consentimento indevido no tenant do Microsoft 365.

A erradicação envolve redefinir credenciais de forma abrangente — incluindo contas de serviço, contas administrativas e, em ambientes Active Directory comprometidos, a conta krbtgt, com o procedimento correto de dupla redefinição. Envolve também aplicar as correções que fecham a porta usada: patch do sistema exposto, desativação do serviço vulnerável, revisão das regras de firewall, ativação de MFA onde faltava.

A restauração deve ser gradual e verificada, nunca em bloco. Restaura-se primeiro em ambiente isolado, valida-se a integridade do backup escolhido — atenção à data: o backup precisa ser anterior ao comprometimento inicial, não apenas anterior à detecção —, verifica-se ausência de artefatos maliciosos e só então o sistema volta à rede produtiva, sob monitoramento reforçado. As primeiras 72 horas após a retomada são o período de maior risco de reincidência e exigem vigilância ativa sobre autenticações, tráfego de saída e criação de contas.

  1. Erradicar persistência: contas, tarefas agendadas, regras de e-mail, apps consentidos, chaves
  2. Redefinir credenciais em escopo amplo, incluindo contas de serviço e krbtgt quando aplicável
  3. Corrigir o vetor de entrada — patch, configuração ou controle de acesso ausente
  4. Escolher backup anterior ao comprometimento, não apenas anterior à detecção
  5. Restaurar em ambiente isolado, validar integridade e reintegrar por etapas
  6. Monitorar de forma reforçada por, no mínimo, 72 horas após a retomada

Quem responde no dia do incidente

Nenhum plano de crise funciona se for lido pela primeira vez durante a crise. As primeiras 24 horas exigem papéis definidos com antecedência: quem decide isolar, quem coleta evidência, quem fala com a diretoria, quem aciona a seguradora, quem autoriza a restauração. Exige também contatos atualizados e acessíveis fora do ambiente comprometido — uma lista telefônica salva apenas no servidor de arquivos criptografado não ajuda ninguém.

Na prática, a maioria das empresas de médio porte não sustenta uma equipe de resposta a incidentes própria, disponível 24 horas, com competência forense e conhecimento profundo do ambiente. É justamente por isso que a preparação prévia com um parceiro de TI que já conhece a topologia, os backups, as identidades e os pontos críticos do negócio muda o resultado. Quem precisa descobrir a arquitetura durante o incidente perde as horas mais valiosas.

A Duk Informática & Cloud atende mais de 550 empresas há mais de 18 anos, com estrutura de monitoramento, backup gerenciado e resposta a incidentes integrada à operação de suporte. Como Microsoft Gold Partner, atuamos com profundidade em ambientes Microsoft 365, Entra ID e infraestrutura híbrida — os cenários onde a maior parte dos incidentes corporativos hoje começa. Nosso trabalho não é aparecer no dia do desastre: é ter contenção, evidência e restauração já ensaiadas antes que a hora zero chegue.

Quer proteger e otimizar a TI da sua empresa?

Agende um diagnostico gratuito com nossos especialistas certificados.

Falar com Especialista