Ransomware não avisa que está chegando. Ele aparece numa segunda-feira às 7h, quando o primeiro analista abre o notebook e encontra arquivos renomeados com extensões estranhas. Ou no meio da madrugada, quando o monitoramento dispara alertas que ninguém lê a tempo. O ponto é: quando você percebe, o estrago já começou.

Se você é gestor de TI, CIO ou DPO, saber o que fazer em caso de ransomware nas primeiras 24 horas pode ser a diferença entre um incidente controlado e uma crise que arrasta a empresa por semanas. Não é exagero. Já vi operações inteiras pararem por mais de dez dias porque as primeiras decisões foram tomadas no improviso.

Este artigo é um roteiro por fases. Primeira hora, primeiras horas, primeiro dia. Cada bloco traz o que precisa acontecer, quem precisa ser acionado e onde a maioria das empresas tropeça. No final, a parte que quase ninguém quer ouvir: por que o plano precisava existir antes do ataque.

Primeira hora: conter sem destruir

Isolar as máquinas, não desligar tudo

O primeiro impulso de quem descobre um ataque ransomware na empresa é desligar tudo. Parece lógico, mas é um erro que custa caro. Desligar uma máquina infectada pode apagar evidências voláteis da memória RAM, como chaves de criptografia que, em alguns casos, permitem recuperar arquivos sem pagar resgate.

O que fazer: desconectar o cabo de rede. Desativar o Wi-Fi. Tirar a máquina da rede, mas mantê-la ligada. Se o ambiente usa segmentação de rede (e deveria usar), isole o segmento afetado no switch ou no firewall. Quem opera com firewall FortiGate, por exemplo, consegue criar regras de bloqueio emergencial em minutos.

Parece simples escrito assim. Na prática, com gente nervosa e telefone tocando, é fácil alguém apertar o botão errado.

Preservar evidências desde o minuto zero

Tudo que acontecer a partir de agora pode virar evidência para investigação forense, para a seguradora e para a ANPD. Anote horários. Tire prints das telas com a mensagem de resgate. Registre quais máquinas foram afetadas e quais ainda parecem normais.

Se a empresa tem contrato com um fornecedor de resposta a incidentes, este é o momento de ligar. Não depois de tentar resolver sozinho por três horas.

Acionar o time certo (e só o time certo)

Nas empresas que já têm um plano de resposta a incidentes documentado, existe uma lista clara de quem é acionado primeiro. Normalmente: líder de segurança, gestor de TI, DPO, jurídico e um executivo com poder de decisão.

Nas empresas que não têm esse plano (a maioria, sendo honesto), o que acontece é um telefone sem fio caótico. O estagiário avisa o coordenador, que manda um e-mail para o diretor, que liga para o fornecedor errado. Enquanto isso, o ransomware continua se espalhando.

Uma coisa que aprendi observando incidentes reais: não coloque gente demais na sala no primeiro momento. Cinco pessoas focadas resolvem mais que vinte em pânico.

Primeiras horas: entender o tamanho do problema

Mapear o alcance da infecção

Passado o primeiro choque, a pergunta que importa é: até onde isso foi? O ransomware pegou só uma estação de trabalho? Chegou no servidor de arquivos? Comprometeu o Active Directory? Alcançou o ambiente de nuvem?

Essa investigação precisa ser metódica. Verifique logs do firewall, do antivírus, do EDR (Endpoint Detection and Response, a evolução do antivírus tradicional que monitora comportamento em tempo real). Se a empresa usa SIEM (sistema que centraliza logs de segurança), esse é o momento em que ele se paga.

O mapeamento do alcance define tudo que vem depois. Se o comprometimento foi localizado, a recuperação pode levar horas. Se o atacante teve acesso privilegiado ao domínio, prepare-se para dias.

Verificar os backups (e rezar para que sejam imutáveis)

Aqui é onde muita empresa descobre, da pior forma possível, que o backup não funciona como imaginava.

Ransomware moderno tem como alvo declarado os backups. Os atacantes procuram snapshots, volumes de backup em rede, consoles de gerenciamento. Se seus backups estão no mesmo domínio que foi comprometido, há uma chance real de que também foram criptografados.

Backups imutáveis (aqueles que não podem ser alterados ou apagados durante um período definido, nem pelo administrador) são a diferença entre uma recuperação de ransomware viável e um cenário de desespero. Se sua empresa usa Azure, AWS ou uma solução on-premises com suporte a imutabilidade, verifique agora, antes de precisar, se essa configuração está ativa de verdade.

Já vi caso em que o backup existia, estava íntegro, mas ninguém sabia a senha do cofre de chaves porque o analista que configurou tinha saído da empresa seis meses antes. Parece piada, mas não é.

Não negociar por impulso

A mensagem de resgate vai ter um valor, um prazo e, muitas vezes, um chat amigável com o atacante. Sim, muitos grupos de ransomware operam com suporte ao cliente. É surreal, mas é o mundo em que estamos.

Minha recomendação clara: não responda nas primeiras horas. Não pague sem antes entender o cenário completo. Pagar não garante que você vai receber a chave de descriptografia. E mesmo quando recebe, a taxa de recuperação completa dos dados costuma ficar bem abaixo dos 100%.

A decisão de pagar ou não é complexa e envolve jurídico, seguradora e, em alguns casos, forças de lei. Não é uma decisão que o analista de TI toma sozinho num domingo de madrugada.

Ah, e um detalhe que pouca gente menciona: pagar resgate pode, dependendo da jurisdição e do grupo criminoso envolvido, colocar a empresa em situação legal delicada com relação a sanções internacionais.

Primeiro dia: comunicação, registro e conformidade

Comunicação interna: transparência controlada

Os colaboradores vão perceber que algo aconteceu. Sistemas fora do ar, e-mail sem funcionar, acesso bloqueado. O pior que você pode fazer é não dizer nada, porque o vácuo de informação se preenche com boatos.

Prepare um comunicado interno curto, honesto e sem tecniquês. Algo como: ‘Identificamos um incidente de segurança que afetou parte dos nossos sistemas. O time de TI está trabalhando na contenção e recuperação. Pedimos que não conectem dispositivos pessoais à rede e que reportem qualquer comportamento estranho.’

Não prometa prazo de retorno se você não tem certeza. Prometer ‘volta tudo amanhã’ e não cumprir destrói a confiança mais do que o próprio ataque.

Clientes e parceiros: o que dizer e quando

Se o ataque comprometeu dados de clientes ou afetou a prestação de serviço, a comunicação externa precisa acontecer rápido. Mas não precisa ser um comunicado de imprensa na primeira hora.

O timing importa. Comunique quando tiver informação suficiente para dizer o que aconteceu, o que está sendo feito e qual o impacto esperado. Comunicar cedo demais, sem fatos, gera mais pânico do que confiança.

Seguradora de risco cibernético: acione antes de tomar decisões caras

Se a empresa tem seguro cyber (e se não tem, essa conversa precisa entrar na próxima reunião de orçamento), o momento de acionar a seguradora é agora. A maioria das apólices exige notificação dentro de prazos curtos, e muitas decisões, como contratar uma empresa de forense ou negociar com os atacantes, precisam passar pela seguradora para não invalidar a cobertura.

Esse é um ponto onde vi empresas perderem direito à indenização: tomaram decisões sozinhas, contrataram fornecedores por conta própria e depois a seguradora alegou que não foi consultada conforme o contrato.

Boletim de ocorrência: sim, é necessário

Registre um boletim de ocorrência. Parece burocracia, mas tem utilidade prática: documenta o incidente formalmente, pode ser exigido pela seguradora e serve como evidência caso a empresa precise acionar a Justiça depois. Em São Paulo, por exemplo, existe a Delegacia de Crimes Cibernéticos (DCCIBER) que recebe esse tipo de ocorrência.

Comunicação de incidente à ANPD: o que a lei exige

Se o ataque ransomware envolveu dados pessoais (e na maioria dos casos envolve, porque servidores de arquivo e bancos de dados quase sempre contêm informações de clientes, funcionários ou fornecedores), a empresa tem obrigação legal de avaliar a comunicação do incidente à ANPD.

O Regulamento de Comunicação de Incidente de Segurança, estabelecido pela Resolução CD/ANPD nº 15/2024, define regras claras:

• O controlador deve comunicar à ANPD e aos titulares afetados quando o incidente de segurança puder acarretar risco ou dano relevante aos titulares dos dados
• O prazo para comunicação à ANPD é de 3 dias úteis a partir do conhecimento de que o incidente afetou dados pessoais
• A comunicação aos titulares deve ocorrer em prazo igual, de forma clara e acessível
• A comunicação deve incluir a descrição da natureza dos dados afetados, as medidas técnicas e de segurança adotadas, os riscos relacionados ao incidente e as medidas que foram ou serão tomadas para reverter ou mitigar os efeitos

Três dias úteis passam rápido quando você está no meio de uma crise. Por isso o DPO precisa estar na sala desde a primeira hora, não ser avisado na quinta-feira que o incidente aconteceu na segunda.

Um erro comum: achar que ‘como os dados foram criptografados e não vazaram, não precisa comunicar’. A ANPD considera que a indisponibilidade de dados pessoais causada por ransomware pode, sim, configurar um incidente comunicável, dependendo do impacto. Confira sempre o texto oficial da Resolução para confirmar prazos e critérios atualizados.

A recuperação: mais lenta do que você gostaria

Mesmo com backups íntegros, a recuperação de um ambiente comprometido por ransomware não é apertar um botão de ‘restore’. Antes de restaurar qualquer coisa, você precisa ter certeza de que o vetor de entrada foi identificado e fechado. Caso contrário, o atacante volta.

A sequência típica de recuperação de ransomware passa por:

1. Confirmar que o ambiente está limpo (ou reconstruir o que for necessário do zero)
2. Restaurar sistemas críticos primeiro, priorizando o que mantém a operação de pé
3. Validar a integridade dos dados restaurados
4. Monitorar intensivamente nas semanas seguintes, porque reinfecção acontece

Empresas que operam com ambientes híbridos (parte on-premises, parte em nuvem) costumam ter uma recuperação mais rápida no lado cloud, desde que a segmentação esteja bem feita. Quem tem workloads em Microsoft Azure ou AWS com políticas de backup separadas do domínio local geralmente consegue subir os serviços prioritários em menos tempo.

Mas aqui vai a verdade inconveniente: dependendo do tamanho do estrago, a recuperação completa pode levar semanas. E durante esse período, a empresa opera no improviso, com processos manuais, planilhas emergenciais e muita hora extra.

Por que o plano precisava existir antes do ataque

Tudo que descrevi até aqui pressupõe que alguém, em algum momento, pensou nessas coisas antes. Que existe uma lista de contatos de emergência. Que alguém sabe onde estão os backups e como acessá-los. Que o DPO conhece os prazos da ANPD. Que a seguradora foi contratada e a apólice está em dia.

A realidade? Grande parte das empresas brasileiras de médio porte não tem um plano de resposta a incidentes documentado. Têm, no máximo, uma noção vaga de ‘se acontecer, a gente chama o fornecedor de TI’. Isso não é um plano.

Um plano de resposta a incidentes de verdade inclui:

• Definição clara de papéis (quem decide o quê, quem comunica o quê)
• Contatos de emergência atualizados: fornecedores de segurança, seguradora, jurídico, DPO, forense
• Procedimentos técnicos de contenção e isolamento por tipo de incidente
• Localização e procedimento de acesso aos backups, incluindo backups offline e imutáveis
• Templates de comunicação interna e externa (ninguém quer redigir um comunicado de crise no meio do pânico)
• Cronograma de testes. Um plano que nunca foi testado é um documento decorativo

O plano não precisa ter cinquenta páginas. Já vi planos eficientes com dez páginas bem escritas. O que importa é que as pessoas certas saibam que ele existe e onde encontrá-lo (dica: não deixe o plano só no servidor de arquivos que pode ser criptografado; tenha uma cópia impressa ou num repositório externo).

Se a sua empresa ainda não estruturou esse plano, a Omega Brasil trabalha com cibersegurança corporativa e ajuda a construir tanto as camadas de defesa quanto o plano de resposta. É o tipo de investimento que parece abstrato até o dia em que você precisa dele.

O que reforçar depois que a poeira baixar

Passada a crise, existe uma janela de atenção da diretoria que raramente se abre. Aproveite. É o momento de conseguir orçamento para o que antes era ‘gasto desnecessário’.

Priorize três frentes. Primeiro, segmentação de rede real, não aquela que existe no diagrama mas não no switch. Segundo, proteção de endpoint com EDR, porque antivírus corporativo tradicional sozinho não segura ransomware moderno. Terceiro, backup com imutabilidade testada, não configurada e esquecida.

E faça o post-mortem do incidente. Documente tudo: como o atacante entrou, o que funcionou na resposta, o que falhou, quanto tempo levou cada etapa. Esse documento é ouro para a próxima vez. Porque, estatisticamente, empresas que sofreram um ataque têm chance elevada de sofrer outro.

Uma observação que costuma incomodar, mas precisa ser dita: se o vetor de entrada foi um e-mail de phishing (e frequentemente é), o problema não se resolve só com tecnologia. Treinamento de usuários, aquele que todo mundo acha chato e pula, é parte da defesa. Não o treinamento genérico anual que ninguém leva a sério, mas simulações práticas e recorrentes.

Preciso comunicar a ANPD mesmo se os dados não vazaram?

Depende. A Resolução CD/ANPD nº 15/2024 fala em ‘risco ou dano relevante aos titulares’. A indisponibilidade prolongada de dados pessoais causada por ransomware pode se enquadrar nesse critério, mesmo que os dados não tenham sido exfiltrados. Na dúvida, a orientação segura é comunicar. A ANPD tende a ser mais compreensiva com quem comunica proativamente do que com quem tenta esconder e é descoberto depois.

Quanto tempo leva para recuperar o ambiente após ransomware?

Não existe resposta única. Uma estação isolada com backup recente pode voltar em horas. Um ambiente corporativo inteiro com Active Directory comprometido pode levar de uma a quatro semanas. O fator que mais acelera a recuperação é a qualidade dos backups e a existência prévia de um plano testado. Empresas que investiram em disaster recovery estruturado se recuperam significativamente mais rápido.

As primeiras 24 horas definem o resto

Não tem como dourar a pílula. Um ataque de ransomware é uma das piores experiências que um time de TI pode enfrentar. Pressão de todos os lados, sistemas fora, diretoria cobrando resposta, advogados preocupados, clientes ligando.

Mas a diferença entre uma crise gerenciável e um desastre total está nas decisões tomadas nas primeiras horas. Isolar sem destruir evidências. Verificar backups antes de prometer prazos. Acionar as pessoas certas na ordem certa. Comunicar a ANPD dentro do prazo. Não pagar resgate por impulso.

E acima de tudo: ter pensado nisso antes. O plano de resposta a incidentes não é um documento para passar em auditoria. É o roteiro que mantém a empresa de pé quando tudo desmorona.

A Omega Brasil ajuda sua empresa a montar o plano de resposta e as camadas de defesa contra ransomware. Fale com nosso time de segurança.