Um ataque de ransomware quase sempre ensaia o golpe antes de executá-lo: minutos ou horas antes de criptografar arquivos, o invasor executa comandos administrativos nativos do Windows para destruir cópias de sombra, apagar o catálogo de backup e desligar a recuperação automática. Esses comandos — vssadmin delete shadows, wmic shadowcopy delete, wbadmin delete catalog e bcdedit com recoveryenabled no — são o momento mais barato de detectar e conter o ataque, porque a criptografia em massa ainda não começou e os backups ainda existem.
O problema do SOC não é falta de sinais: é que esses comandos aparecem em meio a milhares de eventos de administração legítima. Este artigo organiza os principais comandos preparatórios, mostra a regra Sigma pública que os detecta, explica como Wazuh transforma a detecção em resposta automática e propõe um protocolo de contenção que cabe numa folha A4. É um recorte complementar ao material do site sobre detecção e resposta a ransomware no SOC e ao guia sobre detecção de movimento lateral.
Por que os preparatórios valem ouro
A técnica MITRE ATT&CK Inhibit System Recovery (T1490, versão 1.6) descreve exatamente esse comportamento: adversários deletam ou removem dados nativos e desligam serviços projetados para ajudar na recuperação de um sistema corrompido, negando acesso a backups e opções de restauração. A página da técnica documenta que vssadmin.exe pode ser usado para deletar todas as cópias de sombra de um sistema com o comando vssadmin.exe delete shadows /all /quiet, que o WMI pode deletar cópias com wmic shadowcopy delete e que bcdedit.exe desabilita a recuperação automática modificando os dados de configuração de boot. A mesma página lista dezenas de famílias que usam esses comandos na prática, de Akira a BlackCat e Conti.
O detalhe operacional que interessa ao analista: esses comandos rodam na fase de impacto, imediatamente antes da técnica Data Encrypted for Impact (T1486, versão 1.5), em que o adversário criptografa dados para interromper a disponibilidade. Quem detecta T1490 em tempo real ganha uma janela em que o agressor já revelou intenção destrutiva, mas o dano ainda é reversível. Quem só percebe depois da criptografia está administrando um incidente de perda de dados.
Tabela dos comandos e do risco
| Comando | O que destrói | Impacto se passar despercebido |
|---|---|---|
| vssadmin delete shadows /all /quiet | Todas as cópias de sombra do volume | Perda das restaurações locais mais rápidas |
| wmic shadowcopy delete | Cópias de sombra via WMI | Mesma perda, por caminho alternativo ao vssadmin |
| wbadmin delete catalog -quiet | Catálogo de backup do Windows | Backups ficam órfãos e difíceis de restaurar |
| bcdedit /set recoveryenabled no | Recuperação automática de boot | Servidor não entra em reparo automático após dano |
| diskshadow delete shadows all | Cópias de sombra via ferramenta diskshadow | Rota menos monitorada que o vssadmin |
A leitura prática da tabela: qualquer um desses comandos em host de produção, fora de janela de mudança e executado por sessão que não seja a conta de backup conhecida, deve ser tratado como incidente em andamento e não como falso positivo administrativo.
Como o Sigma detecta isso
A regra pública da SigmaHQ Shadow Copies Deletion Using Operating Systems Utilities (id c947b146-0abc-4c87-9c64-b17e9d7274a2, level high) cobre praticamente a tabela inteira em uma só lógica: ela dispara quando powershell.exe, pwsh.exe, wmic.exe, vssadmin.exe ou diskshadow.exe recebe linha de comando contendo shadow e delete; quando wbadmin.exe recebe delete, catalog e quiet juntos; e quando vssadmin.exe executa resize shadowstorage com unbounded ou /MaxSize=, variante que destrói cópias redimensionando o armazenamento em vez de apagar. A regra está marcada com as tags attack.t1490 e attack.t1070, level high, e o próprio arquivo alerta para falsos positivos de administradores legítimos e do LANDesk LDClient.
Dois cuidados na implantação. Primeiro, a regra casa pelo nome do processo e pela linha de comando, então ela depende de logs de criação de processo (Event ID 4688 no Windows ou o equivalente do seu EDR); sem esse logsource alimentado, a regra nunca dispara. Segundo, o adversário sabe que a regra existe: renomear binários ou usar OriginalFileName dribla casamentos por Image, por isso a regra também cobre OriginalFileName e vale acompanhar as atualizações do repositório.
Da detecção à resposta automática
Detectar não é conter. A documentação do Active Response do Wazuh descreve um módulo que executa scripts em endpoints monitorados quando um alerta de rule ID, level ou rule group específico dispara, incluindo scripts prontos para bloquear acesso de rede malicioso e deletar arquivos maliciosos, com respostas do tipo stateless (uma ação única) ou stateful (revertida após um período). É esse gatilho que amarra o circuito: a regra de shadow copy dispara, o active response isola o host ou mata a sessão ofensiva antes do próximo comando de criptografia.
Um desenho que funciona em produção tem três camadas: a regra Sigma convertida para o formato do seu pipeline (Wazuh, Splunk, Sentinel ou Elastic); um nível de alerta que chegue ao topo da fila sem passar por triagem de baixa prioridade; e uma ação automática proporcional — matar o processo ofensivo é reversível, isolar o host é mais invasivo, e a escolha depende do seu risco de falso positivo. Se a taxa de falsos positivos de admin legítimo ainda for alta, comece com alerta e notificação imediata ao dono do servidor antes de liberar contenção automática.
Protocolo de cinco passos
- Confirme o contexto: quem executou, de qual host, em qual horário e se há mudança aprovada na janela. Comando destrutivo fora de contexto é incidente presumido.
- Verifique backups imediatamente: se o catálogo ou as cópias de sombra foram atingidos, acione o backup imutável ou externo antes de qualquer outra ação — o objetivo do adversário é exatamente essa destruição.
- Contenha a sessão: mate o processo e a conta responsável, suspenda credenciais associadas e isole o host da rede se houver sinais de movimento lateral.
- Preserve evidência: capture logs de criação de processo, linha de comando completa, hashes e timeline antes de reiniciar ou limpar a máquina.
- Hunte o padrão em toda a frota: o mesmo comando raramente roda em um host só; procure a assinatura shadow+delete nos últimos sete dias para achar outros hosts preparados.
O erro clássico é parar no primeiro alerta contido. A execução de T1490 indica que o adversário já tem administração do host; a pergunta certa não é se o comando foi bloqueado, mas como ele chegou lá — e essa investigação conecta diretamente com o trabalho de caça descrito no guia de detecção de ransomware com bypass de MFA.
