Contenção não é erradicação

“Desliga tudo.” “Troca todas as senhas.” “O Domain Admin foi comprometido, então refaz o domínio inteiro.” “Tem backup, está resolvido.” “Resetou o KRBTGT? Acabou o Golden Ticket.”

Já ouvi todas essas frases, e várias na mesma reunião, nos primeiros minutos de um incidente sério com ransomware, Active Directory ou conta privilegiada comprometida. Dá pra entender o desespero. A empresa está parada, a diretoria cobra e alguém precisa fazer alguma coisa agora.

O problema é que resposta a incidente não funciona com receita pronta. DFIR, Digital Forensics and Incident Response, depende de evidência, investigação e contexto, e de saber o que o atacante fez dentro do ambiente, não só o que a ferramenta mostrou. Boa parte dos erros que vejo nasce de tratar uma ação isolada como se ela resolvesse o incidente inteiro.

Uma frase resume isso: contenção não é erradicação. Você pode expulsar o atacante hoje e deixar a porta aberta pra ele voltar amanhã. Reuni abaixo os mitos que mais aparecem no meio dessa crise e o que a documentação da Microsoft e da CISA diz sobre cada um.

Contenção limita o dano, erradicação tira o atacante

Contenção significa limitar o dano e impedir, ou ao menos dificultar, que o incidente continue se espalhando. Erradicação significa remover o que permitiu ao atacante manter acesso. São problemas diferentes, e a pressa costuma misturar os dois.

Dá pra bloquear um IP, derrubar uma VPN, isolar uma máquina no EDR e segmentar uma VLAN, e ainda assim ter uma contenção excelente. O ambiente, porém, pode continuar com:

• credencial comprometida;
• webshell;
• tarefa agendada ou serviço malicioso;
• conta criada pelo atacante;
• chave SSH;
• token de aplicação ou consentimento OAuth malicioso;
• persistência no Active Directory;
• malware em outro endpoint;
• acesso a uma conta SaaS.

Isolar as máquinas infectadas é necessário, mas dar o incidente por encerrado depois disso é um erro clássico. Você conteve uma parte do ataque e não removeu o atacante.

O reflexo de “desligar tudo” tem o mesmo problema. A abordagem da Microsoft para resposta a ransomware orienta isolar os sistemas comprometidos da rede, mas não desativá-los. O guia StopRansomware da CISA explica o motivo: memória do sistema, logs de segurança do Windows e buffers de firewall são evidência volátil, e desligar a máquina joga isso fora.

Active Directory: três reflexos que atrapalham

“Domain Admin comprometido, reconstrói o domínio”

Comprometer uma conta Domain Admin é gravíssimo. A partir dali, o time precisa trabalhar com a hipótese de que o atacante conseguiu alterar quase qualquer coisa no domínio. Isso não significa, de forma automática, destruir o Active Directory e criar outro.

Vale separar quatro situações: comprometimento de credenciais, de máquinas, do plano de controle de identidade e a perda da capacidade de confiar no ambiente. A Microsoft trabalha com um processo chamado Compromise Recovery, que tem o objetivo de remover o controle do atacante e elevar a postura de segurança dentro de um período definido. Conforme o escopo que a investigação encontrar, ele pode incluir isolar controladores de domínio conhecidos como íntegros, reconstruir os sistemas de fato comprometidos, rotacionar credenciais privilegiadas, tratar persistências e redefinir a senha do KRBTGT.

A orientação da Microsoft para recuperação de comprometimentos sistêmicos de identidade deixa claro que a ordem e o momento das ações dependem do resultado da investigação, e que qualquer mecanismo de persistência esquecido pode manter o atacante dentro.

Então Domain Admin comprometido não quer dizer “formate tudo”, e também não quer dizer “troque a senha do administrador e siga a vida”. A pergunta útil é outra: dá pra provar, com nível aceitável de confiança, que o controle do atacante saiu do ambiente?

“Resetamos o KRBTGT, Golden Ticket resolvido”

KRBTGT é a conta do Active Directory cuja chave assina os Ticket Granting Tickets, os TGTs do Kerberos. No Golden Ticket, o atacante que obteve o material criptográfico dessa conta passa a fabricar TGTs válidos. Por isso, em vários cenários de comprometimento do AD, rotacionar a senha do KRBTGT entra na recuperação.

O detalhe está no procedimento. São dois resets, e não dá pra executar um e fazer o outro cinco minutos depois. A documentação da Microsoft manda esperar 10 horas entre os dois, que é o tempo de vida máximo padrão dos tickets, e esse intervalo precisa ser maior se a política de Kerberos tiver sido alterada. O motivo é que a conta guarda as duas senhas mais recentes, então só o segundo reset limpa o histórico. Na orientação de resposta a ransomware, a equipe da Microsoft cita um jeito de encurtar a espera: reduzir o tempo de vida dos tickets antes do primeiro reset e usar um script repetível, com todos os controladores de domínio que serão mantidos online.

Mesmo feito do jeito certo, o reset não remove as outras formas de persistência. Se o atacante criou outra conta privilegiada, alterou ACLs, instalou serviços ou tarefas agendadas, comprometeu contas de serviço ou roubou certificados e segredos, ele continua com caminhos de volta. Eu trato o reset do KRBTGT como uma ação dentro de uma estratégia de recuperação. Botão de expulsar hacker não existe.

“Troca a senha de todo mundo e pronto”

Parece lógico: credencial comprometida, troca todas. Só que a primeira pergunta é se o atacante ainda está dentro. Trocar a senha de uma conta enquanto o endpoint do usuário continua comprometido é entregar a senha nova de bandeja.

Em incidente complexo, a sequência das ações importa. A abordagem da Microsoft começa pela avaliação de escopo (contas, dispositivos, aplicações, logs e sinais de comando e controle ainda ativo) e afirma que a contenção só pode acontecer depois de determinar o que precisa ser contido. Antes de mexer em senha, o time precisa saber:

• quais contas e endpoints foram comprometidos;
• quais sistemas foram acessados;
• quais mecanismos de persistência existem;
• onde há sessões ativas;
• quais credenciais, tokens, certificados ou segredos o atacante pode ter obtido.

Trocar senha pode ser necessário, e a própria Microsoft recomenda desativar sem demora as contas que se acredita comprometidas. Fazer isso sem entender o incidente, porém, só renova a credencial que o atacante vai roubar de novo.

Backup e restauração: duas armadilhas

“Temos backup, estamos seguros”

Backup não é sinônimo de recuperação. A pergunta deixa de ser se existe backup e passa a ser se dá pra restaurar, e se alguém já testou a restauração. Operadores de ransomware sabem que o backup é a última linha de defesa e costumam localizar, corromper ou apagar as cópias antes do impacto final. A Microsoft descreve esse comportamento em ataques conduzidos por humanos, e a CISA recomenda backups offline e criptografados, com disponibilidade e integridade testadas com regularidade.

Existe um segundo problema. Um backup pode estar íntegro e conter a persistência do atacante. Restaurar tudo sem saber quando o comprometimento começou é reconstruir o ambiente junto com o que mantinha o atacante dentro. Backup sem estratégia de recuperação é só uma cópia.

“Restaura tudo agora e investiga depois”

A pressa é compreensível. A empresa está parada, a diretoria quer os sistemas no ar e cada hora custa dinheiro. Só que restaurar sem critério pode destruir evidência valiosa: memória, logs locais, conexões, processos e artefatos temporários desaparecem. A CISA recomenda, sempre que possível, capturar imagem de sistema e de memória de uma amostra dos dispositivos afetados e coletar os logs relevantes antes de reconstruir.

Isso não quer dizer manter a empresa parada uma semana enquanto alguém examina cada byte. A Microsoft trata como parte da investigação descobrir a maneira mais rápida de recolocar os sistemas no ar sem perder as evidências necessárias. Conciliar preservar evidência e recuperar o negócio é o trabalho em que uma equipe experiente de DFIR faz diferença.

Investigação: achar o malware não é entender o ataque

“Achamos o malware, agora sabemos o que aconteceu”

O malware costuma ser só o último estágio visível. Na hora em que os arquivos começam a ser criptografados, o ataque muitas vezes já dura horas, dias ou mais. Antes disso, o atacante passa por acesso inicial, execução, persistência, escalada de privilégio, descoberta, movimento lateral, coleta de credenciais e exfiltração. Analisar só o executável que criptografou os servidores mostra como o ransomware funciona, mas não como o atacante entrou e tomou o ambiente. Por isso DFIR não se resume a análise de malware: é preciso reconstruir a timeline do incidente.

O mesmo vale para o paciente zero. Achar o ponto de entrada é importante, mas causa raiz e raio de impacto são problemas relacionados e diferentes. Saber como o atacante entrou não diz até onde ele chegou, o que acessou, quais credenciais obteve, que dados foram lidos ou exfiltrados, onde deixou persistência e quais sistemas ainda precisam ser tratados como não confiáveis. A Microsoft lembra ainda que o atacante às vezes apaga rastros, então a cadeia completa de eventos pode não ficar evidente.

“O EDR não alertou, então a máquina está limpa”

EDR é uma ferramenta excelente, mas ausência de alerta não prova ausência de comprometimento. Atacantes usam ferramentas legítimas do sistema, credenciais válidas, PowerShell, WMI, RDP e outras técnicas de Living off the Land, que consistem em abusar do que já existe no ambiente. Os mais sofisticados também tentam desativar controles de segurança e logging, comportamento que a Microsoft descreve em ransomware operado por humanos.

Daí a necessidade de correlacionar fontes: EDR, Active Directory, Windows Event Logs, firewall, VPN, proxy, DNS, SIEM, nuvem e identidade. Uma ferramenta isolada quase nunca conta a história inteira.

“Já temos o IOC, é só procurar na rede”

IOC, seja hash, IP, domínio, arquivo ou chave de registro, tem valor, mas o atacante troca de IOC com facilidade. O comportamento é mais difícil de esconder. Se a investigação mostra que ele usou certa técnica pra roubar credencial, fazer movimento lateral ou criar persistência, procurar só aquele hash é pouco. A pergunta passa a ser em que outros sistemas aquele comportamento aconteceu.

É nesse ponto que investigação e threat hunting se encontram. Você encontra um artefato, transforma em hipótese e caça a hipótese no restante do ambiente: se o atacante usou uma técnica neste servidor, em que outros sistemas há evidência dela? É assim que o escopo aparece, e o “servidor comprometido” costuma virar algo bem maior.

Impacto e atribuição

“Criptografou, então o objetivo era esse”

Nem sempre. A criptografia pode ser só a última etapa, precedida por reconhecimento, roubo de credenciais e exfiltração de dados. Isso muda a resposta, porque recuperar os servidores resolve a disponibilidade, mas não a confidencialidade. Dependendo dos dados envolvidos, entram na conversa o jurídico, privacidade, comunicação, clientes, reguladores e a LGPD. O servidor voltar não significa que o incidente terminou.

“DFIR é descobrir quem atacou”

Atribuição é interessante, mas as perguntas urgentes do negócio são outras: como o atacante entrou, o que foi comprometido, até onde chegou, se ainda tem acesso, como remover esse acesso, como recuperar o ambiente com segurança e como impedir que a mesma técnica funcione de novo. Saber o nome do grupo ajuda a entender TTPs e orientar o hunting. Só que descobrir se foi o grupo A, B ou C não pode pesar mais do que recuperar a confiança no ambiente.

Glossário de siglas

Sigla	Significado
DFIR	Digital Forensics and Incident Response
AD	Active Directory
KRBTGT	Conta do Active Directory cuja chave protege e assina os TGTs do Kerberos
TGT	Ticket Granting Ticket
EDR	Endpoint Detection and Response
SIEM	Security Information and Event Management
IOC	Indicator of Compromise
TTP	Tactics, Techniques and Procedures
LGPD	Lei Geral de Proteção de Dados
CISA	Cybersecurity and Infrastructure Security Agency
ACL	Access Control List
WMI	Windows Management Instrumentation
RDP	Remote Desktop Protocol
SSH	Secure Shell
OAuth	Open Authorization
SaaS	Software as a Service
VPN	Virtual Private Network
VLAN	Virtual Local Area Network
DNS	Domain Name System
IP	Internet Protocol

Conclusão: DFIR não é apagar incêndio

Resposta a incidente não é chegar correndo, desligar máquina, trocar senha, formatar servidor e restaurar backup. É um processo investigativo, e cada ação precisa responder a pelo menos uma destas perguntas:

• Fatos: o que aconteceu, quando começou e como aconteceu.
• Escopo: até onde o ataque chegou.
• Presença: se o atacante continua no ambiente.
• Retorno: por onde ele poderia voltar.
• Confiança: o que falta pra confiar de novo no ambiente.

A última é a que mais pesa pra mim. Existe uma diferença enorme entre “o ransomware parou” e “recuperamos o controle do ambiente”. O alerta sumir do dashboard não encerra o trabalho de DFIR, e muitas vezes é ali que a investigação começa.

Na prática, antes do próximo incidente: defina quem investiga, teste a restauração dos backups, confirme que os logs de EDR, Active Directory, VPN e firewall ficam retidos por tempo suficiente e escreva o que o time faz antes de desligar, trocar ou restaurar qualquer coisa. Durante o incidente, registre cada decisão e o motivo dela.

Se você trabalha com DFIR, Active Directory ou resposta a incidentes e quer discutir esses cenários com gente da área, entre no nosso Discord: discord.com/invite/6h6D9W7DFj.

Referências

• Microsoft Learn: AD Forest Recovery, reset the krbtgt password
• Microsoft Learn: Abordagem da Microsoft para resposta a incidentes de ransomware e práticas recomendadas
• Microsoft Security Blog: Advice for incident responders on recovery from systemic identity compromises
• CISA: #StopRansomware Guide