YARA no SOC: como escrever regras de detecção de malware

Regras YARA transformam padrões observados em arquivos suspeitos em detecções repetíveis: YARA é a ferramenta usada por pesquisadores de malware para identificar e classificar amostras a partir de padrões textuais ou binários descritos em regras. Para um SOC pequeno, ela preenche o vão entre o antivírus do endpoint e o SIEM: quando um anexo de phishing chega à triagem, uma regra bem escrita diz em segundos se aquele binário carrega marcadores de uma família conhecida, sem esperar assinatura de fornecedor e sem detonar a amostra. O resultado alimenta o mesmo fluxo de investigação usado em casos como o movimento lateral com hash roubado, em que identificar o artefato cedo define o tamanho do incidente.

O que YARA resolve no SOC

O antivírus decide o que bloquear; YARA responde a outra pergunta: este arquivo se parece com algo que a operação já viu? É uma pergunta de triagem e de caça, não de prevenção. Em uma equipe enxuta, os usos que pagam a conta são três: confirmar a família de uma amostra isolada antes de escalar, varrer diretórios de escrita temporária atrás de arquivos da mesma campanha e converter inteligência textual (nomes de mutex, URLs de comando e controle, strings de configuração) em detecção verificável. A ferramenta funciona em Windows, Linux e Mac OS X, tanto pela interface de linha de comando quanto por scripts Python com a extensão yara-python, o que permite encaixar a varredura em playbooks já existentes sem comprar nada. Onde a regra Sigma descreve eventos de log, a regra YARA descreve o conteúdo do arquivo: são camadas complementares, não concorrentes.

Anatomia de uma regra

Segundo a documentação oficial do projeto, toda regra YARA é composta por um conjunto de strings e por uma expressão booleana que define a lógica de correspondência. As strings descrevem o que procurar — sequências de bytes em hexadecimal, texto claro, expressões regulares — e a condição decide quando a regra dispara. Um esqueleto mínimo, com valores inventados para fins de exemplo, fica assim:

rule exemplo_loader_sintetico
{
    meta:
        author = "equipe soc"
        descricao = "exemplo didatico com strings sinteticas"
    strings:
        $config = "s3rv3r.evil-exemplo.test" ascii
        $mutex = "Global\\ExemploMutex01"
        $blob = { 4D 5A 90 00 03 00 [200-400] 55 8B EC }
    condition:
        uint16(0) == 0x5A4D and 2 of ($config, $mutex, $blob)
}

Três escolhas desse esqueleto valem mais que a sintaxe. Primeiro, a condição pede dois dos três marcadores, não apenas um: combinadores com “N of” reduzem falso positivo sem endurecer tanto a regra que ela morra. Segundo, a checagem de cabeçalho (aqui, a assinatura de executável) evita gastar avaliação em arquivo que nunca vai casar. Terceiro, os marcadores vêm de comportamento estável da família (configuração, mutex), não de bytes que mudam a cada build. Os exemplos deste guia usam apenas strings sintéticas criadas em laboratório próprio; regra de produção nasce de amostras que a equipe tem direito de analisar.

Do laboratório para a operação

O caminho curto para colocar a primeira regra em produção segue cinco passos:

1. Monte um corpus mínimo com amostras da família-alvo e um conjunto de benignos representativos do ambiente (instaladores, scripts internos, binários assinados).
2. Extraia marcadores estáveis — configuração em texto claro, mutex, nomes de seção incomuns, sequências de bytes constantes entre builds.
3. Escreva a regra com condição combinada e valide-a com o binário yara contra o corpus inteiro, registrando o resultado de cada arquivo.
4. Meça falso positivo sobre os benignos. Se houver qualquer batida, corte ou estreite as strings antes de continuar.
5. Promova a regra para o fluxo de triagem (varredura do diretório de anexos ou chamada pela automação de resposta) e registre autor, data e o caso que a motivou.

Antes de escrever do zero, vale conferir o que a comunidade já publicou: a YARAify, mantida pela abuse.ch em parceria com a Spamhaus, examina arquivos suspeitos contra um grande repositório de regras YARA, e o serviço expõe API para varredura e consulta em lote. Regra de terceiro entra pela mesma porta do passo quatro: nenhuma regra sobrevive ao ambiente sem passar pelo corpus de benignos local. Quando a varredura confirma uma família de ransomware, o próximo passo é o fluxo do guia de detecção e resposta ao ransomware Gunra, que assume exatamente esse artefato confirmado como ponto de partida.

Falsos positivos e limites

Os erros que quebram regras YARA em produção são conhecidos. Strings genéricas são a maior fonte de falso positivo: versões de navegador, caminhos de biblioteca padrão e até trechos de licença aparecem em milhares de binários legítimos e fazem a regra disparar para tudo. O oposto também incomoda: bytes de código empacotado mudam a cada compilação, então casar trecho do empacotador identifica o empacotador, não a família. E existe o limite estrutural — YARA olha o arquivo como está; amostra empacotada que só revela strings na memória depois de executada exige varredura de dump de memória, não de disco. Nenhuma regra garante detecção: ela é uma evidência a mais para a triagem, com taxa de acerto que depende do corpus com que foi testada.

Fontes

• YARA — The pattern matching swiss knife for malware researchers (VirusTotal)
• YARAify — YARA Scan Engine (abuse.ch)