PRT.5 - Detecção de Ameaças com YARA e Regras Personalizadas

Nota do grupo PRT (Defesa em Profundidade) do Framework CTH, derivada do capítulo 7, seção 7.5 (PRT.5.1 a PRT.5.5), do PDF de referência.
Regras personalizadas convertem inteligência de ameaças em detecção acionável antes que os fornecedores atualizem assinaturas.
A nota cobre o YARA e seus pontos de execução, a anatomia de uma regra, boas práticas de escrita, o ciclo de vida de regras derivadas de CTI, integração com sandboxes e varredura programada e o vínculo com PRT.4 e SIM.4.

1. Contexto e Posicionamento no Framework CTH

Ferramentas comerciais de segurança se apoiam em assinaturas e detecções genéricas, essenciais para o volume, mas estruturalmente lentas para ameaças direcionadas. Quando a CTI identifica um malware novo usado por um grupo relevante para o setor, a organização precisa de um caminho rápido para transformar aquele relatório em detecção própria, em horas e não em semanas. PRT.5 estabelece esse caminho, com repositório versionado de regras YARA e Sigma, processo de desenvolvimento com SLA definido e, no nível avançado, automação de implantação com métricas de eficácia.

O controle é a ponte mais direta entre os dois lados do Framework CTH. De um lado chegam IOCs, TTPs e relatórios de campanha do CTI.x; do outro saem regras que executam nos endpoints de PRT.1, nos uploads do PRT.3, nas imagens do PRT.4 e nas consultas do SIEM do DAT.4. Um programa que coleciona relatórios de inteligência sem converter nada em detecção tem intel de leitura, não de operação, e PRT.5 existe para eliminar exatamente essa lacuna.

2. O que é YARA e Onde Ele Roda

YARA é a linguagem padrão da indústria para descrever e detectar padrões em arquivos e memória, combinando strings, sequências de bytes, expressões regulares e condições lógicas. Uma regra YARA é texto simples, legível por humano e executável por máquina, o que a torna o formato de escolha para compartilhar capacidades de detecção entre equipes e com a comunidade. O Sigma complementa o YARA no domínio dos logs, oferecendo formato genérico de regra convertível em consultas para diferentes plataformas de SIEM, e os dois juntos cobrem o espectro de detecção personalizada descrito no PDF de referência.

O valor do YARA vem da variedade de pontos onde as mesmas regras executam, listados abaixo.

• Varredura de arquivos em disco, de forma pontual ou programada, em estações, servidores e compartilhamentos de rede.
• Memória de processos, para encontrar ferramentas carregadas sem arquivo em disco, como implants e loaders desempacotados.
• Pipeline de gateways de e-mail, verificando anexos e conteúdo decodificado antes da entrega.
• Saída de sandboxes e de análise automática, onde amostras dinâmicas são varridas por regras da organização.
• Produtos de EDR e de segurança que aceitam regras YARA personalizadas, estendendo a detecção do fornecedor.
• Extração de arquivos da telemetria de rede do PRT.2 e uploads capturados na borda web do PRT.3.

Essa ubiquidade explica por que o repositório de regras é um ativo central e não um diretório qualquer. As mesmas regras devem rodar no pipeline de e-mail, nos scans programados de servidores e no motor de runtime do PRT.4, com versionamento único e estado declarado por regra.

3. Anatomia de uma Regra YARA

Uma regra YARA tem três blocos principais. O bloco meta carrega metadados de governança, como autor, data, origem e estado. O bloco strings declara os padrões a buscar, em texto, bytes curingados ou expressões regulares. O bloco condition define a lógica que decide se o objeto casa, combinando os padrões com atributos como tamanho e tipo de arquivo. O exemplo abaixo é uma regra realista e comentada para uma família genérica de loader, escrita a partir de artefatos analisados em sandbox.

/*
  Regra ilustrativa: loader generico com instalacao de servico e
  persistencia em Run. A combinacao de pelo menos tres marcadores
  independentes reduz falso positivo, e o limite de tamanho evita
  casar com instaladores legítimos grandes e empacotados.
*/
rule Generic_Loader_Service_Run_Persistence
{
    meta:
        author = "Equipe de CTI"
        date = "2025-06-10"
        description = "Loader generico com criacao de servico e persistencia em Run"
        reference = "Relatorio interno de campanha CTI 2025-06"
        confidence = "media"
        status = "teste"

    strings:
        $dos_header = { 4D 5A 90 00 }               // assinatura MZ de PE
        $cria_servico = "CreateServiceA" ascii      // instalacao como servico
        $run_key = "Software\\Microsoft\\Windows\\CurrentVersion\\Run" ascii nocase
        $alloc_exec = "VirtualAlloc" ascii          // alocacao de memoria executavel
        $beacon_uri = "POST /gate.php" ascii        // rota de C2 observada

    condition:
        $dos_header at 0 and filesize < 2MB and
        3 of ($cria_servico, $run_key, $alloc_exec, $beacon_uri)
}

Três decisões nessa regra ilustram o que separa uma regra profissional de um experimento. A âncora no header MZ restringe o casamento a executáveis, o limiar de três marcadores independentes exige convergência de evidências em vez de um único padrão fraco, e os metadados registram origem e estado para que o repositório tenha história. Cada campo de meta é preenchido com disciplina, pois é dele que o pipeline de automação e as revisões periódicas vão se alimentar.

4. Boas Práticas de Escrita

Performance é o primeiro critério profissional, porque regras rodam em produção contra volumes grandes de arquivos e memória. Condições de tamanho e de header devem vir primeiro, para descartar rapidamente objetos irrelevantes; expressões regulares amplas e laços custosos devem ser evitados; e o uso de módulos externos deve ser consciente. Uma regra que demora segundos por arquivo inviabiliza a varredura programada de um servidor de arquivos, e o time passa a desligar o scan por falta de planejamento, e não por falta de valor.

O segundo critério é especificidade. Strings genéricas, como mensagens padrão de compilador, nomes comuns de API ou frases de interface, casam com milhares de binários legítimos e inundam a fila de falsos positivos. A prática recomendada é combinar vários sinais fracos, cada um escolhido por estar presente na amostra maliciosa e raro no corpus limpo, e testar o resultado contra os dois lados. O versionamento completo o ciclo: toda regra nasce em estado de teste, promove a produção após validação e se aposenta com registro, nunca é editada silenciosamente.

5. Ciclo de Vida de Regras Derivadas de CTI

O fluxo padrão começa em um relatório de campanha ou em um artefato interno. A equipe de CTI extrai strings, hashes, rotas e comportamentos das amostras, muitas vezes apoiada em sandbox e em desempacotamento manual, e seleciona os padrões estáveis, aqueles que sobrevivem a pequenas recompilações do autor do malware. A regra é escrita, validada contra corpus limpo e contra amostras conhecidas, e só então entra em deploy, com estado de teste inicial e observação da taxa de falso positivo antes da promoção. Cada etapa é registrada no repositório, transformando o histórico de Git em evidência do processo.

O PRT.5.4 define o tempo máximo desse fluxo para ameaças ativas: quatro horas para regras YARA de alta prioridade, quando há ameaça ativa contra a organização, e vinte e quatro horas para as regras Sigma correspondentes no SIEM. O SLA é exequível apenas se o pipeline estiver ensaiado, com templates de regra, corpus de teste preparado e caminho de deploy conhecido. A métrica de tempo entre publicação do relatório e regra em produção é um dos indicadores mais honestos de maturidade de um programa de CTI aplicada.

O fechamento do ciclo é o feedback. Toda regra em produção acumula estatísticas de casamentos, falsos positivos e aposentadorias, que voltam para o CTI.9 e orientam tanto a escrita de novas regras quanto a decisão de manter ou reformular padrões. Regras derivadas de campanhas encerradas precisam de revisão agendada, pois infraestrutura e binários envelhecem rápido.

6. Integração com VT, Sandboxes e Varredura Programada

Serviços de análise de malware multiplicam o alcance do repositório de regras. No VirusTotal, a função de retrohunt executa o conjunto de regras contra o histórico de amostras da plataforma, recuperando famílias relacionadas e variantes anteriores à campanha, e a função de monitoramento contínuo alerta quando novos arquivos casam com as regras da organização. Esses retornos alimentam o CTI.4 com novos artefatos, que podem gerar novas regras, fechando um ciclo produtivo entre inteligência e detecção.

Sandboxes internas e contratadas devem executar o repositório da organização sobre cada amostra analisada, anexando os casamentos ao relatório dinâmico. A varredura programada completa a cobertura, conforme ilustrado nos comandos abaixo, com atenção explícita a performance e registro de resultado.

# Varredura recursiva programada de servidor de arquivos com limite de tempo por regra
yara -r -w -p 60 /opt/yara/rules/index.yar /mnt/fileserver/compartilhamentos 2>>/var/log/yara-scan.log

# index.yar organiza o repositorio com includes por campanha e estado
# include "producao/familias_do_setor.yar"
# include "producao/ferramentas_adversario.yar"
# include "teste/campanha_2025_06.yar"

As opções do comando merecem comentário: o modo recursivo cobre a árvore de diretórios, o limite de tempo por regra protege a janela de execução contra regras custosas, e o log de saída deve ser ingerido pelo SIEM, e não revisado manualmente, para que casamentos gerem casos com contexto de host e horário. O repositório de índices separa explicitamente produção e teste, evitando que regras em estado de teste rodem em varreduras críticas sem supervisão.

7. Limitações Técnicas

Ofuscação e empacotamento são a primeira limitação estrutural do YARA. Malware empacotado com binários únicos por amostra, strings criptografadas em tempo de execução e payloads gerados dinamicamente não deixam padrões estáveis para casar, e uma regra escrita contra a amostra empacotada tende a casar apenas com ela mesma. A mitigação profissional é escrever contra o payload desempacotado, obtido em sandbox ou em dump de memória, e focar em lógica e configuração, que o autor raramente regenera em cada build.

Malware exclusivamente em memória é a segunda limitação, pois não há arquivo para varrer, e a detecção depende de varredura de memória de processos, disponível apenas em alguns pontos de execução. Falsos positivos em binários legítimos, por sua vez, são inevitáveis em escala: instaladores empacotados, binários de sistema com strings suspeitas e aplicações comerciais com padrões parecidos com os do adversário exigem corpus limpo amplo e revisão contínua. A tabela do PDF de referência resume o ajuste de expectativa: YARA é forte para amostras e ferramentas de adversário e fraco para TTPs e comunicação de C2, domínios onde o Sigma e a detecção de rede de PRT.2 são os veículos corretos.

A divisão de trabalho entre as duas linguagens deve ser explícita no plano de detecção da organização, conforme o resumo abaixo.

O resumo evita dois erros opostos de engenharia de detecção: tentar expressar comportamento de ataque em regras de arquivo, quebrando a cada mudança do adversário, e tentar identificar uma família de malware por nome de processo, sinal trivialmente falsificável. Escolher o veículo certo é metade do trabalho de detecção personalizada.

8. Relação com PRT.4 e com Simulação (SIM.4)

Em ambientes cloud-native, o repositório de YARA ganha novos pontos de execução. Imagens de container podem ser varridas em busca de ferramentas de adversário e webshells antes do deploy, o pipeline de CI pode validar artefatos gerados, e o runtime do PRT.4 pode executar regras sobre arquivos extraídos de containers suspeitos. A mesma disciplina de versão, teste e estado aplica-se, e a integração com o scanning de imagem do PRT.4.4 é direta: vulnerabilidades são uma lista, ferramentas de adversário embutidas são outra, e ambas devem bloquear no admission.

O vínculo com o SIM.4 fecha o ciclo de validação. O teste de detecção de IOCs e IOAs executa amostras e comportamentos controlados em ambientes de teste, verificando se a regra dispara na ferramenta correta, no tempo esperado e com o alerta que o SOC sabe triar. Uma regra aprovada no laboratório mas silenciosa na produção é um risco invisível que só o SIM.4 revela, e cada simulação deve atualizar o estado das regras testadas no repositório.

9. Salvaguardas por Nível de Maturidade

As salvaguardas de PRT.5 seguem os três níveis cumulativos do Framework, conforme a tabela consolidada abaixo.

A verificação deve incluir auditoria amostral do repositório, conferindo se metadados, estados e resultados de teste correspondem à realidade. Métricas úteis são o número de regras em produção, a taxa de falso positivo por regra, o número de verdadeiros positivos gerados por mês e o tempo médio entre relatório de CTI e regra em produção.

10. Erros Comuns e Pontos de Atenção

O erro mais frequente é acumular regras sem ciclo de vida. Regras escritas para uma campanha de dois anos atrás seguem em produção casando com falsos positivos, e ninguém se lembra da origem porque o meta nunca foi preenchido. O repositório precisa de revisão periódica com aposentadoria formal, e a automação de PRT.5.5 existe também para impor essa higiene de forma mecânica.

Completam a lista de falhas recorrentes os itens abaixo.

• Regras genéricas demais, com strings comuns que casam com binários legítimos e desacreditam o canal de alertas.
• Validação apenas contra a amostra de origem, sem corpus limpo, descobrindo falsos positivos em produção.
• Expressões regulares custosas em varreduras de produção, tornando os scans inviáveis e desligados por pressão operacional.
• Regras editadas direto no scanner, sem Git, destruindo o histórico e a possibilidade de revisão.
• Dependência de um único ponto de execução, como só o EDR, deixando e-mail, compartilhamentos e imagens sem cobertura.
• Publicação de regras com contexto sensível da organização em canais públicos, sem passar pela contra-inteligência do CTI.10.
• Confusão entre ferramentas, tentando detectar TTP e C2 com YARA onde o veículo correto é Sigma no SIEM ou telemetria de rede.

11. Integração com Outros Controles do Framework CTH

PRT.5 é o estágio final do ciclo entre inteligência e detecção que atravessa o Framework. As fontes do CTI.3 e do CTI.4 alimentam a escrita, o CTI.5 normaliza os indicadores, e o repositório de regras entrega a capacidade para o PRT.1 executar scans, o PRT.2 filtrar arquivos extraídos, o PRT.3 inspecionar uploads e o PRT.4 varrer imagens. As regras Sigma do mesmo repositório sustentam a detecção no SIEM do DAT.4 e alimentam as hipóteses de busca baseada em IOC e IOA do TH.10.

Na verificação, o SIM.4 executa os testes que comprovam a eficácia das regras em produção, e o SIM.5 mede a cobertura resultante por técnica. As métricas de eficácia por regra alimentam o MET.x, e a governança do repositório, com revisões e aposentadorias, integra a rotina do GOV. O resultado esperado é um programa em que cada relatório de inteligência relevante se converte, dentro de horas, em detecção testada, implantada e medida.