Detecção de Ransomware no SOC: TTPs e Regras que Importam

Tela de computador bloqueada por ransomware em mesa de trabalho

Ransomware aparece em 48% de todas as violações registradas no Verizon DBIR 2026, e o ataque só vira um incidente de criptografia depois de horas — às vezes dias — de movimento lateral, roubo de credenciais e destruição de backups. A boa notícia para quem opera um SOC é simples: toda cadeia de ransomware deixa rastreios detectáveis antes da criptografia. Este artigo mapeia as técnicas que precedem o impacto final e mostra como transformá-las em regras de detecção que um analista consegue realmente triar.

Resumo: pontos-chave para o SOC

  • O alvo é cedo, não tarde. T1486 (criptografia para impacto) é o último passo. As técnicas anteriores — T1490 (inibir recuperação), T1078 (contas válidas) e T1566 (phishing) — são onde a detecção salva o ambiente.
  • O ataque sobe. O primeiro trimestre de 2026 registrou alta de 126% em relação ao ano anterior, segundo dados agregados de mercado — o maior pico trimestral já medido.
  • LOLBins entregam o golpe. vssadmin, wbadmin e bcdedit são a assinatura mais confiável de fase final. Uma regra Sigma bem escrita pega isso em segundos.
  • Comportamento vence IOC. Regras baseadas em comportamento (Sigma/YARA) detectam variantes novas antes mesmo de um hash ser publicado.

Por que ransomware domina o SOC

O dado que mais assusta quem monta turno de detecção não é o volume — é a velocidade. Um incidente de ransomware custa em média US$ 4,4 milhões por evento, segundo o relatório de custo da IBM citado pela Huntress, e 88% das pequenas e médias empresas já sofreram violações associadas a ransomware, conforme levantamento da Guardz. A consequência prática para o analista de SOC é brutal: o tempo entre o primeiro indicador rastreável e a criptografia encolheu, e a janela de resposta útil depende quase inteiramente da qualidade das regras que estão rodando no SIEM e no EDR.

O relatório Verizon DBIR 2026 confirma a tendência: ransomware passou de 44% para 48% de todas as violações analisadas. Traduzindo para o chão do SOC, isso significa mais turnos saturados de triagem e mais pressão para separar sinal de ruído. Ignorar o problema não é mais opção — a pergunta certa é onde concentrar a cobertura de detecção para obter o maior retorno por hora de analista investida.

As técnicas que antecedem a criptografia

O Center for Threat-Informed Defense compilou as dez técnicas MITRE ATT&CK mais associadas a ransomware, e essa lista é o melhor ponto de partida para priorizar cobertura. A inteligência por trás dela vem de casos reais, não de teoria. A tabela abaixo reúne as técnicas que mais rendem regra de detecção acionável para um time de blue team.

Técnica MITRE Nome O que o atacante faz Sinal mais forte para o SOC
T1486 Data Encrypted for Impact Criptografa arquivos em disco Rajada de I/O de escrita em muitos arquivos (já é tarde)
T1490 Inhibit System Recovery Apaga shadow copies e backups vssadmin delete shadows, wbadmin delete catalog
T1078 Valid Accounts Usa credenciais roubadas para se mover Login fora de horário, de geografia nova ou em host atípico
T1566 Phishing Entrega o acesso inicial via e-mail Anexo com macro, URL recém-registrada, regra de inbox suspeita
T1489 Service Stop Para serviços de segurança antes de atacar EDR, antivírus ou backup interrompidos em série
T1485 Data Destruction Destroi dados para pressionar a vítima Muitas chamadas de exclusão em curto intervalo

A leitura correta dessa tabela muda a forma como o time prioriza. Quem concentra todo o esforço de detecção em T1486 — a criptografia em si — está reagindo quando o prejuízo já é material. As técnicas que realmente importam para o SOC são as que antecedem o impacto, porque é nelas que uma resposta rápida ainda impede o desastre. A cobertura de detecção precisa espelhar a cadeia de ataque, não só o seu último estágio.

Sinais de recuperação inibida no SOC

A técnica T1490 (Inhibit System Recovery) é, na minha opinião de operação, a mais importante de toda a lista — não porque seja a mais sofisticada, mas porque é barata de detectar e carrega valor preditivo altíssimo. A pesquisa da Intel471 sobre inibição de backup e recuperação documenta exatamente este padrão: além do vssadmin, os atacantes usam wbadmin e bcdedit para neutralizar a capacidade de recuperação, e a auditoria de criação de processos é suficiente para flagar o comportamento.

O catálogo de detecção da Elastic descreve a regra clássica: qualquer execução de vssadmin.exe que delete ou redimensione shadow copies deve gerar alerta de alta severidade em endpoints Windows. Combine isso com o monitoramento de bcdedit /set recoveryenabled No e wbadmin delete catalog e você fecha a janela mais explorada por famílias como LockBit e variantes derivadas. Esses três comandos, executados fora de uma janela de manutenção documentada, são um alerta que justifica escalar mesmo antes de confirmar a intenção.

Contas válidas e movimento lateral

T1078 (Valid Accounts) é o vetor que mais derruba SOCs que ainda confiam em detecção por perímetro. O atacante entra com credencial legítima — roubada por phishing, comprada em mercado ou vazada — e praticamente todas as regras tradicionais passam a tratá-lo como usuário autorizado. A saída é pensar em comportamento, não em identidade isolada: login de administrador às 3h da manhã, autenticação de um serviço que nunca saiu de um data center vinda de um IP residencial, ou acesso RDP a um host fora do padrão desse usuário.

A detecção de movimento lateral é o complemento natural. Ferramentas legítimas como PsExec, WMI e RDP são abusadas para espalhar o payload — e quem já montou regra de detecção para esses caminhos conhece a importância de correlacionar processo-pai com linhagem de comando. Vale revisitar o material interno sobre movimento lateral com PsExec, WMI e RDP e sobre detecção comportamental com UEBA, porque é exatamente nesse ponto que uma regra bem afinada separa o analista que contém o incidente do que só documenta o desastre.

Regras Sigma e YARA na prática

A diferença entre um SOC que detecta e um que apenas coleta logs costuma se resumir à qualidade das regras. Sigma descreve comportamentos em logs (o que é mais útil para SIEM) e YARA faz casamento de padrões em arquivos e memória (mais útil para EDR e forense). Regras baseadas em comportamento, em vez de simples hashes, detectam variantes novas antes mesmo de um IOC ser publicado, conforme explica a comparação da SOC Prime entre Sigma e indicadores de comprometimento.

Uma boa regra Sigma para a fase final de ransomware combina três elementos: processo de linhagem de sistema (vssadmin.exe, wbadmin.exe, bcdedit.exe), argumento destrutivo (delete, recoveryenabled No) e contexto de execução fora de janela de manutenção. O time deve manter essas regras versionadas e testá-las com dados de ataque simulado — exatamente o ciclo descrito no guia de engenharia de detecção com MITRE ATT&CK e na abordagem de threat hunting para o que a detecção automatizada deixa passar já publicado aqui. Regra que nunca passou por um teste de falso positivo e de detecção real é uma aposta, não uma defesa.

Da detecção à contenção em minutos

Detectar é metade do trabalho; conter a tempo é o que define o custo do incidente. A literatura de mercado estabelece que o tempo médio de resposta de um SOC de alta maturidade varia de 30 minutos a 4 horas, enquanto a média empresarial ainda fica entre 6 e 24 horas, segundo a análise de métricas da Simbian sobre MTTR em cibersegurança. Em ransomware, cada hora a mais de exposição multiplica o número de hosts afetados — por isso a contenção automatizada via SOAR precisa estar conectada às regras de detecção, não ser um módulo separado que ninguém opera.

O fluxo prático que recomendo é direto: a regra de T1490 dispara, o alerta entra com severidade crítica, e o playbook isola o host na rede antes mesmo de o analista de Nível 2 abrir o ticket. Quem ainda trata isolamento de host como decisão exclusivamente humana está perdendo a corrida contra a criptografia. Converse com o time sobre os playbooks de resposta a incidentes e garanta que a automação de resposta — tema detalhado no guia de SOAR no SOC — esteja acionada para as técnicas mais letais, não só para as mais barulhentas.

Referências