Sinais precoces de ransomware no SOC: o que priorizar

Detectar ransomware no SOC antes do estágio de cifra exige olhar para os comandos de preparação que precedem a encriptação em minutos ou horas. A janela entre a interferência na recuperação do sistema e a cifra dos arquivos é o período em que a operação ainda pode conter o incidente com hosts intactos — depois dela, resta negociar restauração a partir de backups. O guia de resposta a incidentes da NIST para cibercrime com ransomware, o NCC-RAI, estruturou exatamente essa sequência de detecção, resposta e recuperação com foco em backups como centro do plano.

O princípio operacional é simples: o ransomware raramente cifra sem primeiro remover as opções de recuperação. Ferramentas nativas do Windows aparecem nessa fase de preparação com uma assinatura conhecida, e é aí que a detecção vale mais. A diferença entre um incidente contido e um desastre de disponibilidade costuma ser o que o SOC fez com os alertas desses comandos.

Sinais que antecipam a cifra

O MITRE ATT&CK cataloga a técnica Inhibit System Recovery (T1490) com o conjunto de utilitários nativos que adversários usam para deletar ou desativar mecanismos de recuperação do Windows. Os comandos aparecem na página da técnica literalmente:

vssadmin.exe delete shadows /all /quiet — apaga todas as cópias de sombra de volume do host;
wmic shadowcopy delete — remove cópias de sombra via WMI, sem depender do executável vssadmin;
wbadmin.exe delete catalog -quiet — deleta o catálogo de backup do Windows;
bcdedit.exe /set {default} recoveryenabled no — desativa a recuperação automática do boot;
diskshadow delete shadows all — alternativa de deleção de shadow copies via diskshadow.

Nenhum desses comandos é, isoladamente, prova de ransomware: administradores legítimos os executam em manutenção. O sinal de valor para o SOC é a combinação — comando nativo de destruição de recuperação, executado por um processo de linha de comando spawned de contexto anômalo (serviço, agendador, sessão de administração remota), seguido de atividade de escrita massiva em pouco tempo. Quando a origem é um compartilhamento de gestão ou um host que acabou de apresentar movimento lateral, a triagem deve presumir ransomware em preparação até que se prove o contrário. A cobertura completa desses hosts comprometidos antes da cifra já foi abordada em detecção de movimento lateral com pass the hash no SOC.

Correlacionar com a matiz ATT&CK

A fase final do ataque é a técnica Data Encrypted for Impact (T1486): a encriptação de dados para interromper disponibilidade, com retenção da chave como forma de extorsão. O valor do mapeamento para o SOC está em ordenar a investigação — se o incidente já chegou à T1486, a pergunta relevante retroage para quais técnicas de preparação passaram despercebidas e em qual regra de detecção faltou cobertura. Esse raciocínio de transformar cobertura ATT&CK em regras validadas é o mesmo método do ciclo de melhoria de detecção aplicado ao SOC, e vale também para ransomware: cada técnica T1490 e T1486 precisa de pelo menos uma regra ativa, testada e com dono definido.

Para ESXi, o ATT&CK registra que adversários deletam ou encriptam snapshots de máquinas virtuais para impedir que sirvam de backup — em ataques reais isso destrói a rota de recuperação mais rápida de um ambiente virtualizado inteiro, com um único comando em vez de milhass de hosts.

O que o SOC prioriza agora

A orientação pública consolidada nos EUA resume prioridades de defesa que o SOC pode traduzir em telemetria e procedimento: manter backups offline, encriptados e testados regularmente, conduzir varredura de vulnerabilidades para reduzir superfície exposta e aplicar patches de software e sistemas operacionais. Isso alimenta três frentes de monitoramento: inventário de backup com alerta sobre qualquer exclusão ou desativação de job, monitoramento de exposição de serviços de gestão e correlação de exploração de vulnerabilidades conhecidas com o catálogo KEV. Casos reais recentes de ransomware em operação — como a análise técnica do ransomware Gunra e sua resposta no SOC — mostram essa cadeia completa, do acesso inicial à interferência em recuperação.

Procedimento de resposta em cinco etapas

Quando o primeiro sinal de T1490 dispara, a sequência recomendada para o analista de plantão é:

Conter o host de origem: isolar da rede antes de investigar — cada minuto de conexão é oportunidade de propagação.
Preservar evidência: coletar logs de eventos de segurança, linha de comando completa e linha do tempo de processos antes de qualquer reinício.
Verificar alcance: buscar os mesmos comandos e artefatos nos hosts acessíveis com as credenciais da conta comprometida.
Proteger backups primeiro: confirmar integridade e isolamento dos backups offline antes de qualquer restauração — adversários desativam notificações de recuperação antes de corromper backups.
Reportar e acionar o plano: vitimas devem reportar a incidentes por canais competentes e acionar o playbook de resposta; essa orientação é parte da recomendação pública consolidada.

Sinais que merecem alerta imediato

Uma matriz de priorização simples ajuda a triagem a decidir em segundos o que é ruído e o que é ransomware em preparação:

Sinal observado	Prioridade	Ação imediata
vssadmin ou wmic deletando shadow copies	Crítica	Isolar host e abrir incidente
bcdedit desativando recovery no boot	Crítica	Isolar host e preservar evidência
Job de backup desativado ou catálogo deletado	Alta	Verificar integridade dos backups
Escrita massiva e renomeação de arquivos	Crítica	Cifra em andamento — contenção em massa
Login administrativo anômalo antes desses eventos	Alta	Rever origem das credenciais e escopo

O ganho real está em enxergar esses sinais como uma sequência, não como alertas isolados: exclusão de recuperação, escrita massiva e queda de serviços formam o padrão de um ataque em curso. Quem trata cada um em silo perde a janela de contenção — e a recuperação volta a depender só do backup que sobrou.