IR.3 - Contenção e Erradicação

Nota do grupo RES (Resposta a Incidentes Integrada) da seção 15 do Framework CTH.
Deriva do Capítulo 16 do PDF de referência, controle IR.3, com os subcontroles IR.3.1 a IR.3.5.
Separa contenção, que freia o dano, de erradicação, que remove a raiz, com estratégias por cenário, riscos de cada ação, decisões por tipo de ameaça, verificação de limpeza e registro das decisões tomadas sob pressão.

1. Contexto e Posicionamento no Framework CTH

A contenção rápida limita o dano ao impedir que o adversário se propague para outros sistemas, e a erradicação completa remove a presença dele do ambiente, impedindo recomprometimento. Contenção lenta multiplica o dano por cada hora de liberdade, e erradicação incompleta garante retorno do adversário, às vezes pela mesma porta, às vezes por persistência que ninguém procurou. Incidentes com reinfecção repetida são quase sempre falha de erradicação ou de fechamento do vetor, e não de azar.

No framework, o IR.3 executa a ação física da resposta sobre hosts, identidades e rede, apoiado nas capacidades do PRT.x (EDR, NDR, WAF) e orquestrado pelo AUT.5 quando há playbook aprovado. O controle opera em duas dimensões, contenção de rede e contenção de endpoint, coordenadas entre equipes de rede, endpoint e forense para que a pressa não destrua evidência que o IR.4 e eventual processo legal vão exigir.

2. Contenção versus Erradicação: Duas Frentes Distintas

Contenção é frear o dano: isolar, bloquear, revogar e cortar caminhos que o adversário usa agora. Erradicação é remover a raiz: apagar persistência, resetar credenciais, fechar o vetor de entrada e corrigir a vulnerabilidade explorada. A distinção importa porque têm ritmos, riscos e donos diferentes, e misturá-las produz o pior dos mundos, que é contenção demorada para discutir erradicação e erradicação apressada sobre ambiente ainda ativo.

A sequência recomendada é decidir contenção em minutos com critério predefinido, preservar evidência antes de ações destrutivas quando o cenário permite, e só então entrar em erradicação com lista de artefatos e escopo confirmados. Em ransomware e exfiltração em curso, a contenção antecede quase tudo; em APT silenciosa, a evidência pode anteceder a contenção. Ter esse juízo escrito antes do incidente é exatamente o que o IR.3.1 exige com os procedimentos por categoria.

3. Estratégias de Contenção por Cenário e Seus Riscos

Cada ação de contenção tem efeito colateral, e o gestor de incidente precisa conhecê-los de cabeça no momento da decisão. A tabela abaixo consolida as ações típicas, o mecanismo que as executa e o risco operacional de cada uma.

Bloqueios de IOC são rápidos e reversíveis, com implantação de regra emergencial em menos de dez segundos via API, e por isso são a primeira linha, mas têm durabilidade curta porque o adversário troca infraestrutura com facilidade. Isolamento de endpoint é o inverso: mais disruptivo, porém definitivo para o caminho de propagação que passa pela máquina. A combinação certa depende do tipo de ameaça, que é o tema da próxima seção.

A ordem entre contenção e preservação de evidência deve estar predefinida por cenário, e não decidida no calor do momento. Cenários com adversário ativo e dano crescente priorizam contenção imediata; cenários de investigação silenciosa priorizam coleta de memória e artefatos voláteis antes de qualquer isolamento. O workflow do IR.3.3 mostra como a sequência coordenada fica automatizada quando o alerta de comprometimento é confirmado.

Workflow de contenção automatizada (IR.3.3)
Gatilho:  alerta confirmado de comprometimento com evidência forte
Passo 1:  consultar lista de isenção do AUT.5 antes de qualquer ação
          |__ alvo protegido: parar workflow e escalar para humano
Passo 2:  preservar evidência volátil conforme política do cenário
          (coleta remota de processos, conexões e arquivos modificados)
Passo 3:  bloquear IOC de rede no IDS/IPS via API (IP, domínio, hash)
Passo 4:  isolar endpoint comprometido no XDR, mantendo canal de gestão
Passo 5:  desativar contas de usuário suspeitas vinculadas ao alerta
Passo 6:  criar caso na plataforma DFIR com evidências, ações executadas,
          carimbos de tempo e link para o alerta de origem
Saída:    notificação ao plantão com resumo, reversão documentada por
          passo e verificação pós-contenção registrada como task

4. Decisões por Tipo de Ameaça

A postura de contenção muda com o adversário, e a tabela abaixo resume as decisões típicas por família de ameaça. O princípio geral é que velocidade, visibilidade e custo operacional para o adversário são variáveis em tensão, e cada tipo pende para um lado.

O caso APT merece ênfase porque contraria o instinto de isolar tudo na hora. Contenção que alerta o adversário custa a investigação inteira: ele rotaciona infraestrutura, apaga logs e retorna por outro ponto, e a organização fica sem saber o que foi levado. A decisão de contenção silenciosa, com monitoramento aumentado e coleta paralela, deve estar predefinida em procedimento, com gatilhos claros de quando a contenção silenciosa é abandonada em favor da agressiva, por exemplo exfiltração detectada ou movimento para ativo crítico novo.

5. Erradicação Completa

Erradicação é a fase que decide se o incidente termina ou se recomeça em duas semanas. Ela exige remover persistência em todos os pontos observados e nos pontos que o padrão da técnica sugere, e não apenas no host índice: tarefas agendadas, serviços, chaves de autorun, contas criadas, chaves SSH autorizadas, regras de encaminhamento de e-mail, aplicações OAuth autorizadas e webshells em servidores web. Reset de credenciais precisa ter grau de profundidade proporcional ao tempo de permanência estimado, cobrindo não só a conta comprometida, mas contas com privilégio sobre ela, tokens e segredos que ela podia ler.

Checklist mínimo de erradicação
Persistência:
  |__ Tarefas agendadas e serviços criados ou alterados na janela do incidente
  |__ Chaves de autorun, WMI subscriptions e DLL hijack observados
  |__ Contas criadas, elevadas ou reativadas; chaves SSH e MFA alteradas
  |__ Regras de caixa postal, encaminhamentos e apps OAuth autorizados
Identidades:
  |__ Reset de senha da conta comprometida e de contas adjacentes privilegiadas
  |__ Revogação de tokens, sessões e certificados emitidos na janela
  |__ Rotação de segredos acessíveis pela conta (API, banco, cofre)
Vetor de entrada:
  |__ Causa raiz identificada (phishing, vulnerabilidade, credencial vazada, fornecedor)
  |__ Vetor fechado: patch aplicado, conta desativada, mensagem recolhida, acesso revogado
Vulnerabilidade explorada:
  |__ Correção validada em produção antes da restauração
  |__ Compensação temporária documentada quando patch não existe
Sistemas:
  |__ Varredura com antimalware e YARA no escopo completo
  |__ Reinstalação de imagem quando indicado, com base em critério, e não em comodidade

Fechamento do vetor de entrada é item que separa erradicação de maquiagem: reinstalação de imagem de host sem fechar a porta que o adversário usou é agendar o retorno. A análise de causa raiz deve rodar em paralelo, identificando o vetor inicial, a técnica ATT&CK empregada e a vulnerabilidade explorada, conforme o IR.3.5, para que a correção preceda a restauração dos sistemas.

6. Verificação da Erradicação

Ninguém declara ambiente limpo por bom senso; declara por busca. A verificação combina busca programada por artefatos conhecidos do incidente em todo o parque, com hunting de confirmação sobre hipóteses de persistência ainda não observadas, e só depois disso a recuperação do IR.4 começa. A consulta abaixo exemplifica a busca por artefatos de um incidente real na telemetria do SIEM, aplicável a qualquer janela e escopo definido no caso.

Exemplo KQL de verificação: artefatos do incidente em todo o parque
let janela = datetime(2025-03-01) .. datetime(2025-03-12);
let hash_malicioso = "d41d8cd98f00b204e9800998ecf8427e";
let dominio_c2 = "cdn-updates-logistics.com";
DeviceFileEvents
| where Timestamp in janela and SHA256 == hash_malicioso
| project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessFileName
DeviceNetworkEvents
| where Timestamp in janela and RemoteUrl contains dominio_c2
| project Timestamp, DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName
IdentityLogonEvents
| where Timestamp in janela and AccountUpn =~ "usuario.alvo@empresa.com.br"
        and IPAddress !in~ (range_ips_corporativos)
| project Timestamp, AccountUpn, IPAddress, DeviceName, LogonType

Resultado vazio não encerra a verificação sozinho: revisa-se cobertura de telemetria com o DAT.5, porque ausência de dado pode ser ausência de agente, e não ausência de mal. Hunting de confirmação para TTPs do incidente, usando as técnicas do grupo HNT, reduz o risco de persistência desconhecida, e o registro formal da verificação entra no caso como evidência de que a erradicação foi auditada, e não declarada.

7. Comunicação e Registro de Decisões

Decisões de contenção são decisões de negócio tomadas sob pressão, e o registro delas protege a organização e o gestor. Toda ação disruptiva deve registrar no caso o que foi decidido, por quem, com base em qual evidência, qual risco se aceitou e qual é o caminho de reversão, conforme a matriz de reversibilidade adotada pelo AUT.5. A comunicação segue a matriz de escalada do IR.2, com mensagens pré-aprovadas para os níveis crítico e alto, e regras de OPSEC explícitas, porque detalhes de contenção divulgados cedo demais chegam ao adversário e ajustam sua conduta.

Turnos precisam de protocolo de passagem estruturado, com estado atual, ações pendentes e riscos conhecidos registrados no caso, e não passados verbalmente. O registro consistente dessas decisões também alimenta o post-mortem do IR.4, que só consegue reconstruir a linha do tempo verdadeira quando as escolhas de contenção foram documentadas no calor do momento.

8. Implementação e Salvaguardas por Nível

O salto crítico é do IR.3.2 para o IR.3.3, quando a contenção passa a ser executada por máquina: antes dele, a lista de isenção precisa estar populada, o rollback testado e o drill executado com a ferramenta real, como exige a governança do AUT.5. Procedimento documentado que nunca foi exercitado no ambiente real falha exatamente no dia em que é mais necessário, e a simulação do grupo SIM.x é o campo de prova recomendado.

9. Erros Comuns e Pontos de Atenção

• Reinstalação de imagem sem erradicar o vetor: máquina nova em ambiente com a mesma vulnerabilidade é reinfecção agendada; feche o vetor antes de devolver qualquer host.
• Contenção que alerta o adversário: bloqueio ruidoso em cenário APT queima a investigação; defina gatilhos para alternar entre contenção silenciosa e agressiva.
• Erradicação pelo caminho mais curto: apagar malware sem caçar persistência e credenciais acumuladas garante retorno; siga o checklist completo com escopo proporcional ao dwell time.
• Evidência destruída pela pressa: isolamento que derruba sessão, memória e artefatos voláteis sem coleta prévia pode custar a quantificação do dano; alinhe contenção com forense por cenário.
• Bloqueio bruto com dano colateral: bloquear faixa de IP de provedor grande ou CDN interrompe serviços legítimos; prefira domínio, URL ou hash quando couber.
• Escopo de reset insuficiente: resetar apenas a conta visível ignora credenciais adjacentes, tokens e segredos acessados; o grau de profundidade segue o tempo de permanência estimado.
• Verificação por declaração: ambiente limpo porque ninguém encontrou nada sem checar cobertura de telemetria é conclusão sem base; registre o que foi buscado, onde e com qual cobertura.
• Verificação pós-contenção ausente: contenção que ninguém confirma pode estar furada, com beacon novo para destino diferente; a verificação obrigatória do IR.3.1 existe por isso.
• Comunicação por canal informal: decisão de contenção anunciada só em chat de plantão perde aprovador, horário e racional; o registro formal no caso é o que sustenta a decisão na revisão e na auditoria.

10. Integração com Outros Controles do Framework CTH

O IR.3 consome as capacidades de resposta do PRT.1 para isolamento de endpoint, do PRT.2 para bloqueio de rede, e a orquestração do AUT.5, que executa ações com guardrails e auditoria. Depende do INS.1 para a lista de ativos críticos que merecem contenção seletiva, e do DAT.x para telemetria que sustenta tanto a decisão quanto a verificação da limpeza. Suas evidências e a linha do tempo alimentam o IR.4, que recupera e conduz o post-mortem, e os IOC e TTPs observados alimentam o CTI.9 e o PLT.x, transformando cada ação de contenção em material de inteligência para a próxima defesa.