Ransomware em fase inicial: detecte antes da criptografia

Analista de SOC monitorando telas com alertas de detecção de ransomware em fase inicial

Ransomware em fase inicial é a janela em que o adversário já tem acesso, mas ainda não criptografou nada: utilitários nativos do próprio Windows aparecem para deletar cópias de sombra de volume e desativar mecanismos de recuperação, enquanto credenciais roubadas sustentam o movimento lateral. Quem só alerta quando o primeiro arquivo vira criptografia investiga tarde demais. Este guia mostra os sinais que antecedem o impacto, como convertê-los em regras Sigma e como priorizar a resposta no SOC.

A janela antes da criptografia

A cadeia típica de um ataque de extorsão tem etapas observáveis muito antes do impacto. Segundo o MITRE ATT&CK, adversários removem dados e serviços nativos de recuperação do sistema para impedir a restauração, ampliando o efeito da criptografia. Os comandos documentados incluem vssadmin.exe delete shadows /all /quiet para apagar todas as cópias de sombra, wmic shadowcopy delete via WMI, wbadmin.exe delete catalog -quiet para destruir o catálogo de backup do Windows e bcdedit.exe /set {default} recoveryenabled no para desativar a reparação automática na inicialização.

Nenhuma dessas ações depende de ferramenta exótica: tudo acontece com binários assinados do próprio sistema, o que anula antivírus baseado em reputação de arquivo e deixa a linha de comando como principal evidência. Por isso a telemetria de criação de processo (evento 4688 do log de segurança ou Sysmon Event ID 1) é o mínimo necessário para enxergar essa fase.

Antes da criptografia em si, o movimento lateral também denuncia a operação. O ATT&CK registra que malware de criptografia pode apresentar comportamento de verme, propagando-se pela rede com contas válidas, roubo de credenciais e compartilhamentos administrativos SMB — a mesma base de técnicas trabalhada na análise de pass-the-hash e movimento lateral no SOC. Picos de autenticação remota, uso de contas de serviço fora do horário previsto e execução remota em vários hosts em poucos minutos formam um padrão que nenhum desses eventos isolado entrega.

Sinais de alta fidelidade

Nem todo alerta dessa fase vale o mesmo. O critério prático é a relação entre esforço de triagem e probabilidade de ataque real: comandos de destruição de backup quase nunca têm uso legítimo em estações de usuário, enquanto atividade SMB intensa pode ser um job de backup noturno. A tabela ordena os sinais do mais ao menos decisivo.

Sinal pré-criptografia Técnica Telemetria Ação imediata
vssadmin delete shadows /all /quiet ou wmic shadowcopy delete T1490 Processo com linha de comando (4688 / Sysmon 1) Isolar o host e preservar memória
bcdedit /set recoveryenabled no seguido de reinicialização T1490 Linha de comando mais evento de boot Isolar e caçar a origem da sessão
Renomeação em massa de arquivos em compartilhamento T1486 Auditoria de objetos de arquivo e arquivos-isca Desconectar o compartilhamento
Rajada de autenticação remota de conta de serviço Movimento lateral Logs de autenticação (4624, tipos 3 e 10) Suspender a conta e correlacionar hosts

Arquivos-isca merecem destaque: um diretório monitorado com documentos falsos sensíveis transforma a primeira tentativa de criptografia em um alarme de alta confiança, antes que a operação alcance os servidores de arquivo.

Regras Sigma para o pré-impacto

Transformar esses sinais em detecção portável é o papel do Sigma, um formato genérico, aberto e estruturado que permite a equipes de segurança detectar eventos relevantes de log de forma simples e compartilhável, segundo a documentação oficial. A mesma regra é convertida para SPL, KQL ou Lucene sem reescrita manual, o que reduz o custo de manter detecções específicas de ransomware em ambientes heterogêneos. Um exemplo mínimo para o sinal mais decisivo:

title: Shadow Copy Deletion via vssadmin
status: stable
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        CommandLine|contains: 'vssadmin.exe delete shadows'
    condition: selection
level: critical

Uma regra dessas deve nascer com severidade máxima e teste automatizado: se a linha de comando existir no ambiente de validação e o SIEM não disparar, a detecção não existe. Teste, ajuste de falsos positivos e nova versão formam a rotina que separa uma biblioteca de regras viva de uma coleção de arquivos YAML abandonados.

Prioridade de resposta no SOC

Quando um sinal de pré-criptografia dispara, a resposta tem ordem definida:

  1. Isolar o host da rede mantendo-o ligado, para preservar memória volátil e evidências.
  2. Bloquear e redefinir as credenciais usadas na sessão suspeita, inclusive contas de serviço.
  3. Buscar os demais hosts tocados pelas mesmas credenciais nas últimas horas, antes de qualquer limpeza.
  4. Verificar a integridade dos backups: a recomendação da CISA é manter backups offline e criptografados e testá-los com regularidade, porque o adversário tenta destruir cópias online antes do impacto.
  5. Documentar a linha do tempo e só então remediar — apagar a máquina cedo destrói a investigação.

Essa disciplina também reduz o dano de variantes que entram por acesso inicial mais elaborado, como o bypass de MFA usado pelo ransomware Gunra: a porta de entrada muda, mas os sinais de pré-criptografia permanecem os mesmos.

Checklist de preparação

  • Linha de comando completa registrada em todos os hosts (4688 ou Sysmon 1), com auditoria de criação de processo ativada.
  • Regras Sigma ativas para os comandos de destruição de backup, testadas no último trimestre.
  • Arquivos-isca em pelo menos um compartilhamento crítico e nos servidores de arquivos.
  • Backups em segmento isolado, com criptografia ativa e restauração ensaiada.
  • Plano de isolamento de host ensaiado com a equipe de rede, com tempo-alvo medido.

Fontes